idnits 2.17.00 (12 Aug 2021) /tmp/idnits51263/draft-lee-v4v6tran-usecase-cable-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2010) is 4255 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 599, but no explicit reference was found in the text == Outdated reference: draft-arkko-ipv6-transition-guidelines has been published as RFC 6180 == Outdated reference: A later version (-06) exists of draft-cui-softwire-host-4over6-01 == Outdated reference: draft-ietf-softwire-dual-stack-lite has been published as RFC 6333 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Y. Lee 3 Internet-Draft Comcast 4 Intended status: Informational V. Kuarsingh 5 Expires: March 23, 2011 Rogers Communications 6 September 19, 2010 8 IPv6 Transition Cable Access Network Use Cases 9 draft-lee-v4v6tran-usecase-cable-00 11 Abstract 13 This memo describes some use cases to transition to IPv6 in cable 14 access network. This memo discusses enabling dual-stack to users 15 over various types of network infrastructures. It also describes 16 impacts to network, operation, CPE, and applications. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 23, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Offer Dual-Stack on Top of Existing Access Network . . . . . . 3 54 2.1. IPv4-only Access Network . . . . . . . . . . . . . . . . . 4 55 2.1.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1.1.1. Deployment Requirements . . . . . . . . . . . . . 4 57 2.1.1.2. Network Impact . . . . . . . . . . . . . . . . . . 5 58 2.1.1.3. Operation Impact . . . . . . . . . . . . . . . . . 5 59 2.1.1.4. CPE Impact . . . . . . . . . . . . . . . . . . . . 6 60 2.1.1.5. Application Impact . . . . . . . . . . . . . . . . 6 61 2.1.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Native Dual-Stack Use Case . . . . . . . . . . . . . . . . 6 63 2.2.1. IPv6 Address Design . . . . . . . . . . . . . . . . . 7 64 2.2.2. Provisioning . . . . . . . . . . . . . . . . . . . . . 7 65 2.2.3. Advertising Customer's Prefixes to the Access 66 Network . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.2.4. Benefits of Native Dual Stack . . . . . . . . . . . . 7 68 2.3. Native Dual-Stack with Shared IPv4 Addresses Use Case . . 8 69 3. Offer Dual-Stack on IPv6-only Access Network . . . . . . . . . 8 70 3.1. Shared IPv4 Address Use Case . . . . . . . . . . . . . . . 8 71 3.1.1. DS-lite . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1.1.1. Deployment Requirements . . . . . . . . . . . . . 8 73 3.1.1.2. Network Impact . . . . . . . . . . . . . . . . . . 9 74 3.1.1.3. Operation Impact . . . . . . . . . . . . . . . . . 9 75 3.1.1.4. CPE Impact . . . . . . . . . . . . . . . . . . . . 10 76 3.1.1.5. Application Impact . . . . . . . . . . . . . . . . 10 77 3.2. Public IPv4 Address Use Case . . . . . . . . . . . . . . . 11 78 3.2.1. IPv4 Over IPv6 . . . . . . . . . . . . . . . . . . . . 11 79 3.2.1.1. Deployment Requirements . . . . . . . . . . . . . 11 80 3.2.1.2. Network Impact . . . . . . . . . . . . . . . . . . 12 81 3.2.1.3. Operation Impact . . . . . . . . . . . . . . . . . 12 82 3.2.1.4. CPE Impact . . . . . . . . . . . . . . . . . . . . 12 83 3.2.1.5. Application Impact . . . . . . . . . . . . . . . . 12 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 The Cable access network primarily uses DOCSIS technology defined by 95 CableLabs to deliver IP services to users. DOCSIS provides an 96 abstraction to deliver IP packets over coxial cable. DOCSIS is a 97 shared media technology and use Ethernet for Layer-2, it doesn't use 98 PPP or ATM for encapsulation. 100 A Cable Modem which is a DOCSIS enabled modem is the device to 101 transmit the user's Ethernet frames over DOCSIS to the Cable Modem 102 Termination System (CMTS) in the cable operator's network. DOCSIS 103 has gone through few generations. The most current version is DOCSIS 104 3.0. By specifications, DOCSIS 2.0 and DOCSIS 3.0 both support IPv6 105 for cable modem management and user's traffic. However, DOCSIS 1.x 106 specification and some older DOCSIS 2.0's implementations do not. 107 Cable operators will take time to retire all the legacy cable modems 108 and replace them to the newer version of cable modems. So there will 109 be a transition period to upgrade all the equipments to support IPv6. 111 The complexity of upgrading the regional and core network to dual- 112 stack is relatively low compared to upgrading the access network to 113 support IPv6 for thousands of CMTSes and millions of cable modems and 114 CPEs. So this memo focuses on use cases to enable IPv6 in the cable 115 access network. The transition methodology is to provide dual-stack 116 to the users regardless the underneath technology inside a cable 117 operator. When IPv6 services become majority and IPv4 services 118 gradually diminish, the operator may consider to provide only IPv6 to 119 users and provide IPv4-IPv6 translation in the network when users 120 access IPv4 services. This memo describes use cases to provide dual- 121 stack to users because we have more experience. 123 We divide the use cases into two primary categories. The first 124 category describes dual-stack deployment to the users using the 125 existing access network. The access network could be IPv4-only or 126 dual-stack. The second category describes dual-stack deployment to 127 the users using IPv6-only access network. The goal of these use 128 cases is providing service continuity during the transition. 130 2. Offer Dual-Stack on Top of Existing Access Network 132 We discuss three use cases that offer dual-stack to users. The first 133 use case describes the scenario where the access network is IPv4-only 134 and operators utilize tunneling technologies to give dual-stack 135 access to users. The second use case describes the standard native 136 dual-stack deployment model. The third use cases describes native 137 dua-stack where the IPv4 connection may be provided using shared 138 public IPv4 addresses (NAT444). 140 2.1. IPv4-only Access Network 142 According to [I-D.arkko-ipv6-transition-guidelines], native dual- 143 stack is the simplest model for transition. However, this requires 144 the entire network to be dual-stack. Moreover, the provisioning 145 system and other support systems must be upgraded to support IPv6. 146 Most operators will need to upgrade the network in phases along with 147 the provisioning system(s) and supporting systems. During the 148 transition period, there will be IPv4-only islands. In order to 149 offer dual-stack access to users over IPv4 islands, operators may 150 consider the use of tunneling technologies such as 6rd and MPLS. 152 There are incentives to offer IPv6 to users before completing the 153 upgrade. For example: early IPv6 adopters can start experiencing 154 IPv6 services and have connectivity to IPv6-only content should it be 155 available. Operational groups can also being to familiarize 156 themselves with IPv6 and being troubleshooting IPv6. Application 157 developers and content providers can start providing services over 158 IPv6. In the end, this may help to speedup the overall IPv6 159 adoption. 161 2.1.1. 6rd 163 2.1.1.1. Deployment Requirements 165 6rd [RFC5969] is a technology that provides IPv6 connectivity over 166 the existing IPv4 access network. The idea is simple, it leverages 167 the 6to4 model [RFC3056] and uses the provider's specific prefix 168 instead of the IANA assigned well-known prefix. This will give the 169 operator's control of both ingress and egress flows. This technology 170 has been proven to be successful in real operator deployments 171 [RFC5569]. 173 6rd is comprised of two elements: 6rd-CE and 6rd-BR. 6rd-CE initiates 174 an IPv6-in-IP tunnel to the 6rd-BR. 6rd-BR terminates the tunnel and 175 forward the IPv6 packets to the IPv6 Internet. Similar to 6to4, 6rd 176 uses the IPv4 address provisioned to the user to construct the IPv6 177 address. Since the IPv4 address is stored in the IPv6 prefix, the 178 address translation is stateless. 180 6rd works when a user was provisioned with a public IPv4 address. It 181 also works with [RFC1918] address when it is combined with a provider 182 NAT44 function in the network. In this use case, we discuss only the 183 public IPv4 address model. 185 2.1.1.2. Network Impact 187 This describes the egress connection from the 6rd-CE to the IPv6 188 Internet. After the IPv6 packet was encapsulated in an IPv4 packet 189 by 6rd-CE, the network will forward the packet similar to any other 190 IPv4 packet. 6rd model is transparent to the IPv4 network. The 191 packet will eventually arrive in the closest 6rd-BR for 192 decapsulation, then it will be forwarded to IPv6 destination. The 193 "closest" 6rd-BR is defined by the IP address used in combination 194 with network routing conditions. 196 This describes the ingress connection from the IPv6 Internet to 197 6rd-CE. IPv6 packet with 6rd prefix in the destination address will 198 be forwarded normally and arrive to the closest 6rd-BR. The 6rd-BR 199 extracts the IPv4 information from the IPv6 address and encapsulates 200 the IPv6 packet in an IPv4 packet. Then, it will forward the 201 encapsulated packet to the IPv4 network. 203 The 6rd prefix is advertised by the 6rd-BR or by an upstream router 204 on it's behalf. The operator will advertise this prefix within their 205 network and towards the Internet and other neighboring peers. The 206 operator also needs to assign an anycast address to the 6rd-BR. This 207 anycast address will be shared by all the 6rd-BR and will be 208 advertised in the operator's IPv4 serving IGP. The 6rd-CE will send 209 the encapsulated packets to this anycast address. 211 IPv6 packets are delivered on the IPv6-in-IP tunnel. MTU is a common 212 consideration for any tunnel technology. Since 6rd is a stateless 213 technology, the tunnel endpoints cannot perform fragmentation. The 214 simplest solution is to increase default MTU size larger than 1500 215 bytes in the access network. More discussion can be found in 216 [RFC5969]. 218 Hosts behind the 6rd-CE may not be able to dynamically learn any DNS 219 server via SLAAC, so they may query DNS from a DNS server in the IPv4 220 network. The DNS server in the IPv4 network should be configured 221 process AAAA records. 223 2.1.1.3. Operation Impact 225 6rd is a stateless technology. It greatly simplifies the network 226 design for scalability and high availability. Traffic engineering of 227 the tunnels is not explicitly required since the 6rd-BRs are known 228 via an IGP (or IGP assisted path). Operators can add or remove 229 6rd-BR in the network without transferring service states from one 230 6rd-BR to another 6rd-BR. Operators also need not assign any 231 particular 6rd-BR to a 6rd-CE. 6rd-CE will rely on routing to find 232 the closest 6rd-BR. 234 6rd is similar to VPN technology. 6rd packets are encapsulated and 235 transparent to the network. Operator can operate, monitor and 236 troubleshoot the 6rd network independently. 238 Considerations for 6rd include any in-line service or network device 239 that monitors, controls or assists with traffic flows. Since 6rd 240 sends IPv6 packets insider an IPv4 tunnel, all such systems must be 241 6rd aware to continue to supply the same functions for this new 242 traffic type. Additionally, if an operator has enabled dynamic Q0S 243 within their access network, the overall detection, policy and 244 enforcement infrastructure will need to be able to manage the control 245 of IPv6 flows within an IPv4 tunnel. 247 2.1.1.4. CPE Impact 249 CPE is required to implement the 6rd-CE specification. 6rd-CE must be 250 the first device connecting to the cable modem and is responsible for 251 learning the 6rd prefix and construct the 6rd delegated prefix. The 252 CPE is also responsible to advertise the 6rd delegated prefix to 253 hosts behind the CPE. If the CPE implements SLAAC, the hosts behind 254 the CPE learns the prefix and default gateway via Router 255 Advertisement. As with the network portion, any service information, 256 including QoS, will need to be carefully managed to support the IPv6- 257 in-IP function. 259 2.1.1.5. Application Impact 261 Applications will have dual-stack and should behave identically as of 262 running on a native dual-stack host Application which are served via 263 IPv6 will add additional load to BRs within the network. The 264 operator may want to take this under consideration if they are 265 planning to deploy high bandwidth services over IPv6. The operator 266 may choose to offer some services over IPv4 in this case to lower the 267 load on the BRs and allow for more efficient traffic delivery inside 268 the network (since the BR and application systems may not share 269 network locations). 271 2.1.2. MPLS 273 TBD 275 2.2. Native Dual-Stack Use Case 277 Providing native dual-stack to user may be the simplest for 278 transition to IPv6, but it requires operators to upgrade the network, 279 provisioning systems, and supporting systems to give production grade 280 service to users. In this memo, native dual-stack means to provision 281 a public IPv4 address, a global IPv6 address, and a global IPv6 282 prefix to a user. 284 2.2.1. IPv6 Address Design 286 In general, most of the IPv4 address architecture rules still apply 287 to the IPv6 address architecture. For example: each service (e.g. 288 VoIP vs. IPTV) should use different prefixes. Also, operators should 289 use two separate prefixes for network infrastructure and customer 290 services. 292 Due to the high utilization and the allocation policies of IPv4 293 prefixes, the result is each organization got many discontinuous 294 blocks of prefixes rather than a large aggregate. The drawback is a 295 fairly large Internet routing table. The overall IPv6 address pool 296 is 128-bit long. Operators are normally given a prefix that contains 297 an enormous number of addresses. If an operator carefully plans for 298 address allocation and aggregation, it should only advertise the 299 provider's prefix to the IPv6 Internet routing table. For example: 300 each regional network should be a suffix of the overall provider's 301 prefix. The result should be a smaller and more organized Internet 302 routing table. In contrast, bad IPv6 address design may result a 303 divided routing table and unnecessarily bubble its size. 305 2.2.2. Provisioning 307 TBD 309 2.2.3. Advertising Customer's Prefixes to the Access Network 311 Apart from an IPv6 address assignment to the CPE, the network will 312 also delegate a prefix to the CPE for the hosts behind the CPE. This 313 prefix is normally assigned by a DHCP server. The access network 314 will need to learn the prefix and the associated cable modem and CPE. 315 [I-D.droms-dhc-dhcpv6-agentopt-delegate] suggests that the DHCP Relay 316 Agent which is the CMTS can query the DHCP server and learn the 317 prefix. Then, it installs the prefix into its routing table. 318 Another way is the DHCP Relay Agent inspects the DHCP IA_PD reply 319 from the DHCP server and installs the prefix to the routing table. 320 This topic remains open and more development is coming. 322 2.2.4. Benefits of Native Dual Stack 324 Utilizing a native dual stack option for IPv4 and IPv6 connectivity 325 includes the overall integration ease for the provider. Although 326 this option requires the deployment of IPv6, it is the more 327 understood and support option. Other then standard IPv6 328 functionality within the network providers space and in the CPE, no 329 new options are necessarily needed. Many inline services will need 330 to support IPv6, but are likely to support IPv6 native before newer 331 connectivity options which includes DS-lite, 6rd and other such 332 tunneling modes. 334 2.3. Native Dual-Stack with Shared IPv4 Addresses Use Case 336 This use case is an extension of the previous native dual stack 337 option. In this particular case, all the IPv6 deployment 338 considerations are made with an added complexity of shared IPv4 339 access. Shared IPv4 connectivity with a provider controlled NAT44 340 function may be required for dual stack deployments after IPv4 341 exhaustion. This option provides many of the same advantages as the 342 native dual stack option which includes in the clear IPv4 and IPv6 343 flows. The provider can still utilize existing systems that support 344 native IPv4 and IPv6 flows, but will need to add in network 345 functionally related to the NAT44 function. 347 3. Offer Dual-Stack on IPv6-only Access Network 349 When the access network is IPv6-only, IPv6 traffic can be delivered 350 natively over IPv6. So, there is no new requirement to enable IPv6. 351 However, the access network will not be able to deliver IPv4 352 services. We provide two use cases to give dual-stack to users in an 353 IPv6-only access network. 355 3.1. Shared IPv4 Address Use Case 357 When IPv4 addresses are limited, operators may consider multiplexing 358 IPv4 addresses among internal users. Users will not be provisioned 359 with a public IPv4 address. Instead, users will share a pool of 360 public IPv4 addresses in the network. 362 DS-lite [I-D.ietf-softwire-dual-stack-lite] is a technology that 363 provides IPv4 access over an IPv6-only access network. This also 364 provides NAT44 functionality in the operator's network to multiplex a 365 pool of public IPv4 addresses amongst users. 367 3.1.1. DS-lite 369 3.1.1.1. Deployment Requirements 371 DS-lite is composed of two elements: B4 element and AFTR element. B4 372 element initiates an IP-in-IPv6 tunnel to the AFTR. AFTR terminates 373 the tunnel and performs NAT44. B4 element can be implemented in a 374 CPE or in a host. For this use case, we only discuss the CPE B4 375 element model. 377 An operator is required to deploy B4 to user premises. B4 will 378 replace the existing CPE and must be the first network device in 379 front of the cable modem. The operator will provision an IPv6 380 address to the B4 element. It will not provision any IPv4 address to 381 the B4. Operator will also provision an IPv6 Prefix to the B4 and B4 382 will advertise this IPv6 prefix to the hosts behind it so that IPv6- 383 capable hosts will have native IPv6 services. 385 B4 will run as DHCP server to the hosts behind it. It also acts as 386 IPv4 default gateway and DNS proxy to the hosts. IPv4 packets will 387 be delivered over the IP-in-IPv6 tunnel between the B4 and AFTR. 388 From the host perspective, it will be provisioned with dual-stack and 389 the applications running on the host can decide to use IPv4 or IPv6. 391 An operator is required to deploy a set of AFTR elements in the 392 network. The AFTR should be dual-stack to terminate the IP-in-IPv6 393 tunnel from B4 elements and deliver NAT-ed packets to IPv4 Internet. 395 3.1.1.2. Network Impact 397 DS-lite requires the access network to support IPv6. This requires 398 the CMTS and cable modem to be IPv6 enabled. It also requires to 399 deploy a set of AFTR elements in the operator network. AFTR is a 400 stateful network device, it inherits the cost to manage a stateful 401 network device inside the network. 403 IPv4 packets are delivered on the IP-in-IPv6 tunnel. This reduces 404 the effective MTU side. Neither hosts behind the B4 element nor 405 services in front of the AFTR are aware of the tunnel. The operator 406 can increase the MTU size in the access network. However, many cable 407 modem implementations do not support MTU larger than default 1500 408 bytes, so the B4 and AFTR elements must handle fragmentation caused 409 by the tunnel overhead. 411 The AFTR owns the NAT pool, it will be the aggregation point of the 412 IPv4 addresses defined in the NAT pool. AFTR must advertise the NAT 413 pool prefix to the IPv4 Internet. In contrast, the IPv6 tunnel 414 interface should stay only inside the operator's IGP and should not 415 be advertised to the IPv6 Internet. 417 3.1.1.3. Operation Impact 419 DS-lite identifies a user by IPv6 address. Operators should be 420 trained to understand how to map a user from an IPv6 address in the 421 AFTR. AFTR is a NAT device, operator should maintain the NAT binding 422 information to satisfy the government regulations. This is standard 423 procedure for operating any NAT44 device. 425 DS-Lite introduces the operational mode where historical IPv4 426 connectivity (as experienced) is now totally dependent on IPv6. This 427 significant change in operating conditions must be well understood by 428 the operator. If DS-lite is introduced during deployment infancy in 429 the operators IPv6 network, it will require careful attention to 430 operational practices and capabilities to maintain the IPv6 network. 432 AFTR is critical to continuously offer IPv4 access in IPv6-only 433 access network. Operator should scale AFTR to provide non- 434 interruptive access to users. Operators should closely monitor two 435 AFTR's resources: (1) Network Capacity and (2) Port Utilization. 436 When network capacity is reached, the operator should decide to 437 upgrade the AFTR to higher network capacity or to deploy a new AFTR 438 to balance the workload. When port utilization is high, the operator 439 should increase the NAT pool size. 441 AFTR is stateful, it will complicate the high-availability (HA) 442 design. Operators should apply the standard HA design (e.g. cold or 443 hot) which best fits to their network operations. 445 3.1.1.4. CPE Impact 447 CPE is required to implement the B4 element specification. Also, 448 port-forwarding and UPnP IGD protocol will no longer function. IETF 449 PCP Working Group was formed to address the port-forwarding and UPnP 450 IGD issues. 452 CPE must know the IPv6 address of the AFTR tunnel interface. This 453 information can be obtained from DHCP. Since there is only IPv6 454 access to the B4 element. Any IPv4 network service learned from DHCP 455 must be proxy by the B4 element. 457 If the operator cannot increase the access network MTU size, the B4 458 element must handle fragmentation to ensure IPv4 service using 459 maximum MTU size won't be affected by the tunnel overhead. 461 3.1.1.5. Application Impact 463 3.1.1.5.1. Egress Connection 465 Since hosts behind B4 are provisioned with dual-stack, the 466 application can decide to use IPv4 or IPv6. If the external service 467 is also dual-stack, the host will automatically prefer IPv6 over IPv4 468 if the host O/S has implemented [RFC3484]. If the host prefers IPv4 469 due to application logic, it will use the private IPv4 address 470 provisioned by the B4 element. For applications expecting to use 471 specific source port will be impacted because the AFTR inside the 472 network won't be able to allocate a specific source port. 474 Applications use random source port will continue to function without 475 modification. 477 3.1.1.5.2. Ingress Connection 479 Similar to traditional NAT, ingress connection will be blocked by 480 default. The current techniques such as port-forwarding and UPnP IGD 481 are required modification. Technically this could be done. But this 482 will requires some changes in user's procedure to enable the service. 483 It also adds cost to operators to offer port-forwarding service. 485 3.2. Public IPv4 Address Use Case 487 Some applications requires specific source port and some applications 488 requires ingress connection. Users using those applications may want 489 to be provisioned with a public IPv4 address to ease the potential 490 challenges caused by NAT in the network. IPv4-over-IPv6 (4over6) 491 [I-D.cui-softwire-host-4over6] is a simple technology to provision a 492 public IPv4 address to a user and provide IPv4 access over an IPv6- 493 only network. 495 3.2.1. IPv4 Over IPv6 497 3.2.1.1. Deployment Requirements 499 4over6 consists of two elements: 4over6 Initiator and 4over6 Tunnel 500 Concentrator (TC). 4over6 is similar to DS-lite except two features: 501 (1) Unlike B4 element, 4over6 Initiator will be provisioned with a 502 public IPv4 address. (1) 4over6 TC only terminates the IP-in-IPv6 503 tunnel and won't perform any NAT44 function. 505 4over6 supports both host and CPE models. We will only discuss the 506 6over6 CPE model. 508 An operator is required to deploy 4over6 Initiator in premises. The 509 4over6 initiator will replace the existing CPE and must be the first 510 network device in front of the cable modem. The operator will 511 provide an IPv6 address and an IPv6 prefix to the CPE. The procedure 512 is similar to Native IPv6 use case and DS-lite use case. 514 4over6 Initiator is very similar to the B4 element. It serves as 515 DHCP server, IPv4 default gateway and DNS server to hosts behind it. 516 The only difference is 4over6 will be provisioned with a public IPv4 517 address while B4 element will not. Once 4over6 Initiator discovers 518 the 4over6 TC, it will issue standard DHCP request over the tunnel to 519 the 4over6 TC. The 4over6 TC either relays the DHCP request to a 520 centralized DHCP server or replies to the request if it is the 521 authoritative DHCP server for the 4over6 service. Once the CPE 522 acquires the public IPv4 address, the user can run all his legacy 523 IPv4 applications similar to what he is doing with a regular IPv4 524 home gateway. 526 3.2.1.2. Network Impact 528 Similar to DS-lite, the access network must support IPv6. This 529 requires the CMTS and cable modem must be IPv6 enabled. It also 530 requires the operator to deploy a set of 4over6 TC in the network. 532 Despite no NAT in the 6over4 TC, 6over4 TC is required to maintain 533 the 4over6 Initiate IPv6 address (tunnel-id) and IPv4 address 534 binding. Also, the 4over6 TC must advertise the IPv4 prefix to the 535 Internet. It is the aggregation point of the IPv4 address prefix. 537 4over6 suffers the same MTU limitation which is common to any tunnel 538 protocols. Please refer to Section 3.1.1.2 for details. 540 3.2.1.3. Operation Impact 542 Since each user will be assigned a public IPv4 address, it doesn't 543 require operator to log any binding. Operator should be able to 544 identify a user by either IPv4 or IPv6 address. 546 Similar to AFTR, network capacity and IPv4 address utilization are 547 critical resources to 4over6 TC. Operator must closely monitor the 548 resources to ensure continuous IPv4 access. 550 Operators also need to coordinate the IPv4 address space in the DHCP 551 server and the 4over6 Initiator which manages the space. This 552 requires careful coordination and management. 554 3.2.1.4. CPE Impact 556 CPE is required to implement the 4over6 TC specification. Unlike B4 557 element, port-forwarding and the UPnP IGD will work without 558 modification. 560 3.2.1.5. Application Impact 562 Applications will have dual-stack and should behave identically as of 563 running on a native dual-stack host. 565 4. Security Considerations 567 TBD 569 5. Acknowledgements 571 TBD 573 6. IANA Considerations 575 This memo includes no request to IANA. 577 7. References 579 7.1. Normative References 581 [I-D.arkko-ipv6-transition-guidelines] 582 Arkko, J. and F. Baker, "Guidelines for Using IPv6 583 Transition Mechanisms during IPv6 Deployment", 584 draft-arkko-ipv6-transition-guidelines-06 (work in 585 progress), August 2010. 587 [I-D.cui-softwire-host-4over6] 588 Cui, Y., Wu, J., and P. Wu, "Host 4over6 for IPv6 host 589 connecting IPv4 Internet", 590 draft-cui-softwire-host-4over6-01 (work in progress), 591 July 2010. 593 [I-D.ietf-softwire-dual-stack-lite] 594 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 595 Stack Lite Broadband Deployments Following IPv4 596 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 597 in progress), August 2010. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 603 Infrastructures (6rd) -- Protocol Specification", 604 RFC 5969, August 2010. 606 7.2. Informative References 608 [I-D.droms-dhc-dhcpv6-agentopt-delegate] 609 Droms, R., "DHCP Relay Agent Assignment Notification 610 Option", draft-droms-dhc-dhcpv6-agentopt-delegate-00 (work 611 in progress), November 2005. 613 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 614 E. Lear, "Address Allocation for Private Internets", 615 BCP 5, RFC 1918, February 1996. 617 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 618 via IPv4 Clouds", RFC 3056, February 2001. 620 [RFC3484] Draves, R., "Default Address Selection for Internet 621 Protocol version 6 (IPv6)", RFC 3484, February 2003. 623 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 624 Infrastructures (6rd)", RFC 5569, January 2010. 626 Authors' Addresses 628 Yiu L. Lee 629 Comcast 630 One Comcast Center 631 Philadelphia, PA 19103 632 U.S.A. 634 Email: yiu_lee@cable.comcast.com 635 URI: http://www.comcast.com 637 Victor Kuarsingh 638 Rogers Communications 639 8200 Dixie Road 640 Brampton, Ontario L6T 0C1 641 Canada 643 Email: victor.kuarsingh@rci.rogers.com 644 URI: http://www.rogers.com