Operations Area Y. Lee Internet-Draft Comcast Intended status: Informational V. Kuarsingh Expires: March 23, 2011 Rogers Communications September 19, 2010 IPv6 Transition Cable Access Network Use Cases draft-lee-v4v6tran-usecase-cable-00 Abstract This memo describes some use cases to transition to IPv6 in cable access network. This memo discusses enabling dual-stack to users over various types of network infrastructures. It also describes impacts to network, operation, CPE, and applications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 23, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lee & Kuarsingh Expires March 23, 2011 [Page 1] Internet-Draft IPv6 Transition Cable Use Cases September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Offer Dual-Stack on Top of Existing Access Network . . . . . . 3 2.1. IPv4-only Access Network . . . . . . . . . . . . . . . . . 4 2.1.1. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1.1. Deployment Requirements . . . . . . . . . . . . . 4 2.1.1.2. Network Impact . . . . . . . . . . . . . . . . . . 5 2.1.1.3. Operation Impact . . . . . . . . . . . . . . . . . 5 2.1.1.4. CPE Impact . . . . . . . . . . . . . . . . . . . . 6 2.1.1.5. Application Impact . . . . . . . . . . . . . . . . 6 2.1.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Native Dual-Stack Use Case . . . . . . . . . . . . . . . . 6 2.2.1. IPv6 Address Design . . . . . . . . . . . . . . . . . 7 2.2.2. Provisioning . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Advertising Customer's Prefixes to the Access Network . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Benefits of Native Dual Stack . . . . . . . . . . . . 7 2.3. Native Dual-Stack with Shared IPv4 Addresses Use Case . . 8 3. Offer Dual-Stack on IPv6-only Access Network . . . . . . . . . 8 3.1. Shared IPv4 Address Use Case . . . . . . . . . . . . . . . 8 3.1.1. DS-lite . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1.1. Deployment Requirements . . . . . . . . . . . . . 8 3.1.1.2. Network Impact . . . . . . . . . . . . . . . . . . 9 3.1.1.3. Operation Impact . . . . . . . . . . . . . . . . . 9 3.1.1.4. CPE Impact . . . . . . . . . . . . . . . . . . . . 10 3.1.1.5. Application Impact . . . . . . . . . . . . . . . . 10 3.2. Public IPv4 Address Use Case . . . . . . . . . . . . . . . 11 3.2.1. IPv4 Over IPv6 . . . . . . . . . . . . . . . . . . . . 11 3.2.1.1. Deployment Requirements . . . . . . . . . . . . . 11 3.2.1.2. Network Impact . . . . . . . . . . . . . . . . . . 12 3.2.1.3. Operation Impact . . . . . . . . . . . . . . . . . 12 3.2.1.4. CPE Impact . . . . . . . . . . . . . . . . . . . . 12 3.2.1.5. Application Impact . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Lee & Kuarsingh Expires March 23, 2011 [Page 2] Internet-Draft IPv6 Transition Cable Use Cases September 2010 1. Introduction The Cable access network primarily uses DOCSIS technology defined by CableLabs to deliver IP services to users. DOCSIS provides an abstraction to deliver IP packets over coxial cable. DOCSIS is a shared media technology and use Ethernet for Layer-2, it doesn't use PPP or ATM for encapsulation. A Cable Modem which is a DOCSIS enabled modem is the device to transmit the user's Ethernet frames over DOCSIS to the Cable Modem Termination System (CMTS) in the cable operator's network. DOCSIS has gone through few generations. The most current version is DOCSIS 3.0. By specifications, DOCSIS 2.0 and DOCSIS 3.0 both support IPv6 for cable modem management and user's traffic. However, DOCSIS 1.x specification and some older DOCSIS 2.0's implementations do not. Cable operators will take time to retire all the legacy cable modems and replace them to the newer version of cable modems. So there will be a transition period to upgrade all the equipments to support IPv6. The complexity of upgrading the regional and core network to dual- stack is relatively low compared to upgrading the access network to support IPv6 for thousands of CMTSes and millions of cable modems and CPEs. So this memo focuses on use cases to enable IPv6 in the cable access network. The transition methodology is to provide dual-stack to the users regardless the underneath technology inside a cable operator. When IPv6 services become majority and IPv4 services gradually diminish, the operator may consider to provide only IPv6 to users and provide IPv4-IPv6 translation in the network when users access IPv4 services. This memo describes use cases to provide dual- stack to users because we have more experience. We divide the use cases into two primary categories. The first category describes dual-stack deployment to the users using the existing access network. The access network could be IPv4-only or dual-stack. The second category describes dual-stack deployment to the users using IPv6-only access network. The goal of these use cases is providing service continuity during the transition. 2. Offer Dual-Stack on Top of Existing Access Network We discuss three use cases that offer dual-stack to users. The first use case describes the scenario where the access network is IPv4-only and operators utilize tunneling technologies to give dual-stack access to users. The second use case describes the standard native dual-stack deployment model. The third use cases describes native dua-stack where the IPv4 connection may be provided using shared public IPv4 addresses (NAT444). Lee & Kuarsingh Expires March 23, 2011 [Page 3] Internet-Draft IPv6 Transition Cable Use Cases September 2010 2.1. IPv4-only Access Network According to [I-D.arkko-ipv6-transition-guidelines], native dual- stack is the simplest model for transition. However, this requires the entire network to be dual-stack. Moreover, the provisioning system and other support systems must be upgraded to support IPv6. Most operators will need to upgrade the network in phases along with the provisioning system(s) and supporting systems. During the transition period, there will be IPv4-only islands. In order to offer dual-stack access to users over IPv4 islands, operators may consider the use of tunneling technologies such as 6rd and MPLS. There are incentives to offer IPv6 to users before completing the upgrade. For example: early IPv6 adopters can start experiencing IPv6 services and have connectivity to IPv6-only content should it be available. Operational groups can also being to familiarize themselves with IPv6 and being troubleshooting IPv6. Application developers and content providers can start providing services over IPv6. In the end, this may help to speedup the overall IPv6 adoption. 2.1.1. 6rd 2.1.1.1. Deployment Requirements 6rd [RFC5969] is a technology that provides IPv6 connectivity over the existing IPv4 access network. The idea is simple, it leverages the 6to4 model [RFC3056] and uses the provider's specific prefix instead of the IANA assigned well-known prefix. This will give the operator's control of both ingress and egress flows. This technology has been proven to be successful in real operator deployments [RFC5569]. 6rd is comprised of two elements: 6rd-CE and 6rd-BR. 6rd-CE initiates an IPv6-in-IP tunnel to the 6rd-BR. 6rd-BR terminates the tunnel and forward the IPv6 packets to the IPv6 Internet. Similar to 6to4, 6rd uses the IPv4 address provisioned to the user to construct the IPv6 address. Since the IPv4 address is stored in the IPv6 prefix, the address translation is stateless. 6rd works when a user was provisioned with a public IPv4 address. It also works with [RFC1918] address when it is combined with a provider NAT44 function in the network. In this use case, we discuss only the public IPv4 address model. Lee & Kuarsingh Expires March 23, 2011 [Page 4] Internet-Draft IPv6 Transition Cable Use Cases September 2010 2.1.1.2. Network Impact This describes the egress connection from the 6rd-CE to the IPv6 Internet. After the IPv6 packet was encapsulated in an IPv4 packet by 6rd-CE, the network will forward the packet similar to any other IPv4 packet. 6rd model is transparent to the IPv4 network. The packet will eventually arrive in the closest 6rd-BR for decapsulation, then it will be forwarded to IPv6 destination. The "closest" 6rd-BR is defined by the IP address used in combination with network routing conditions. This describes the ingress connection from the IPv6 Internet to 6rd-CE. IPv6 packet with 6rd prefix in the destination address will be forwarded normally and arrive to the closest 6rd-BR. The 6rd-BR extracts the IPv4 information from the IPv6 address and encapsulates the IPv6 packet in an IPv4 packet. Then, it will forward the encapsulated packet to the IPv4 network. The 6rd prefix is advertised by the 6rd-BR or by an upstream router on it's behalf. The operator will advertise this prefix within their network and towards the Internet and other neighboring peers. The operator also needs to assign an anycast address to the 6rd-BR. This anycast address will be shared by all the 6rd-BR and will be advertised in the operator's IPv4 serving IGP. The 6rd-CE will send the encapsulated packets to this anycast address. IPv6 packets are delivered on the IPv6-in-IP tunnel. MTU is a common consideration for any tunnel technology. Since 6rd is a stateless technology, the tunnel endpoints cannot perform fragmentation. The simplest solution is to increase default MTU size larger than 1500 bytes in the access network. More discussion can be found in [RFC5969]. Hosts behind the 6rd-CE may not be able to dynamically learn any DNS server via SLAAC, so they may query DNS from a DNS server in the IPv4 network. The DNS server in the IPv4 network should be configured process AAAA records. 2.1.1.3. Operation Impact 6rd is a stateless technology. It greatly simplifies the network design for scalability and high availability. Traffic engineering of the tunnels is not explicitly required since the 6rd-BRs are known via an IGP (or IGP assisted path). Operators can add or remove 6rd-BR in the network without transferring service states from one 6rd-BR to another 6rd-BR. Operators also need not assign any particular 6rd-BR to a 6rd-CE. 6rd-CE will rely on routing to find the closest 6rd-BR. Lee & Kuarsingh Expires March 23, 2011 [Page 5] Internet-Draft IPv6 Transition Cable Use Cases September 2010 6rd is similar to VPN technology. 6rd packets are encapsulated and transparent to the network. Operator can operate, monitor and troubleshoot the 6rd network independently. Considerations for 6rd include any in-line service or network device that monitors, controls or assists with traffic flows. Since 6rd sends IPv6 packets insider an IPv4 tunnel, all such systems must be 6rd aware to continue to supply the same functions for this new traffic type. Additionally, if an operator has enabled dynamic Q0S within their access network, the overall detection, policy and enforcement infrastructure will need to be able to manage the control of IPv6 flows within an IPv4 tunnel. 2.1.1.4. CPE Impact CPE is required to implement the 6rd-CE specification. 6rd-CE must be the first device connecting to the cable modem and is responsible for learning the 6rd prefix and construct the 6rd delegated prefix. The CPE is also responsible to advertise the 6rd delegated prefix to hosts behind the CPE. If the CPE implements SLAAC, the hosts behind the CPE learns the prefix and default gateway via Router Advertisement. As with the network portion, any service information, including QoS, will need to be carefully managed to support the IPv6- in-IP function. 2.1.1.5. Application Impact Applications will have dual-stack and should behave identically as of running on a native dual-stack host Application which are served via IPv6 will add additional load to BRs within the network. The operator may want to take this under consideration if they are planning to deploy high bandwidth services over IPv6. The operator may choose to offer some services over IPv4 in this case to lower the load on the BRs and allow for more efficient traffic delivery inside the network (since the BR and application systems may not share network locations). 2.1.2. MPLS TBD 2.2. Native Dual-Stack Use Case Providing native dual-stack to user may be the simplest for transition to IPv6, but it requires operators to upgrade the network, provisioning systems, and supporting systems to give production grade service to users. In this memo, native dual-stack means to provision a public IPv4 address, a global IPv6 address, and a global IPv6 Lee & Kuarsingh Expires March 23, 2011 [Page 6] Internet-Draft IPv6 Transition Cable Use Cases September 2010 prefix to a user. 2.2.1. IPv6 Address Design In general, most of the IPv4 address architecture rules still apply to the IPv6 address architecture. For example: each service (e.g. VoIP vs. IPTV) should use different prefixes. Also, operators should use two separate prefixes for network infrastructure and customer services. Due to the high utilization and the allocation policies of IPv4 prefixes, the result is each organization got many discontinuous blocks of prefixes rather than a large aggregate. The drawback is a fairly large Internet routing table. The overall IPv6 address pool is 128-bit long. Operators are normally given a prefix that contains an enormous number of addresses. If an operator carefully plans for address allocation and aggregation, it should only advertise the provider's prefix to the IPv6 Internet routing table. For example: each regional network should be a suffix of the overall provider's prefix. The result should be a smaller and more organized Internet routing table. In contrast, bad IPv6 address design may result a divided routing table and unnecessarily bubble its size. 2.2.2. Provisioning TBD 2.2.3. Advertising Customer's Prefixes to the Access Network Apart from an IPv6 address assignment to the CPE, the network will also delegate a prefix to the CPE for the hosts behind the CPE. This prefix is normally assigned by a DHCP server. The access network will need to learn the prefix and the associated cable modem and CPE. [I-D.droms-dhc-dhcpv6-agentopt-delegate] suggests that the DHCP Relay Agent which is the CMTS can query the DHCP server and learn the prefix. Then, it installs the prefix into its routing table. Another way is the DHCP Relay Agent inspects the DHCP IA_PD reply from the DHCP server and installs the prefix to the routing table. This topic remains open and more development is coming. 2.2.4. Benefits of Native Dual Stack Utilizing a native dual stack option for IPv4 and IPv6 connectivity includes the overall integration ease for the provider. Although this option requires the deployment of IPv6, it is the more understood and support option. Other then standard IPv6 functionality within the network providers space and in the CPE, no new options are necessarily needed. Many inline services will need Lee & Kuarsingh Expires March 23, 2011 [Page 7] Internet-Draft IPv6 Transition Cable Use Cases September 2010 to support IPv6, but are likely to support IPv6 native before newer connectivity options which includes DS-lite, 6rd and other such tunneling modes. 2.3. Native Dual-Stack with Shared IPv4 Addresses Use Case This use case is an extension of the previous native dual stack option. In this particular case, all the IPv6 deployment considerations are made with an added complexity of shared IPv4 access. Shared IPv4 connectivity with a provider controlled NAT44 function may be required for dual stack deployments after IPv4 exhaustion. This option provides many of the same advantages as the native dual stack option which includes in the clear IPv4 and IPv6 flows. The provider can still utilize existing systems that support native IPv4 and IPv6 flows, but will need to add in network functionally related to the NAT44 function. 3. Offer Dual-Stack on IPv6-only Access Network When the access network is IPv6-only, IPv6 traffic can be delivered natively over IPv6. So, there is no new requirement to enable IPv6. However, the access network will not be able to deliver IPv4 services. We provide two use cases to give dual-stack to users in an IPv6-only access network. 3.1. Shared IPv4 Address Use Case When IPv4 addresses are limited, operators may consider multiplexing IPv4 addresses among internal users. Users will not be provisioned with a public IPv4 address. Instead, users will share a pool of public IPv4 addresses in the network. DS-lite [I-D.ietf-softwire-dual-stack-lite] is a technology that provides IPv4 access over an IPv6-only access network. This also provides NAT44 functionality in the operator's network to multiplex a pool of public IPv4 addresses amongst users. 3.1.1. DS-lite 3.1.1.1. Deployment Requirements DS-lite is composed of two elements: B4 element and AFTR element. B4 element initiates an IP-in-IPv6 tunnel to the AFTR. AFTR terminates the tunnel and performs NAT44. B4 element can be implemented in a CPE or in a host. For this use case, we only discuss the CPE B4 element model. Lee & Kuarsingh Expires March 23, 2011 [Page 8] Internet-Draft IPv6 Transition Cable Use Cases September 2010 An operator is required to deploy B4 to user premises. B4 will replace the existing CPE and must be the first network device in front of the cable modem. The operator will provision an IPv6 address to the B4 element. It will not provision any IPv4 address to the B4. Operator will also provision an IPv6 Prefix to the B4 and B4 will advertise this IPv6 prefix to the hosts behind it so that IPv6- capable hosts will have native IPv6 services. B4 will run as DHCP server to the hosts behind it. It also acts as IPv4 default gateway and DNS proxy to the hosts. IPv4 packets will be delivered over the IP-in-IPv6 tunnel between the B4 and AFTR. From the host perspective, it will be provisioned with dual-stack and the applications running on the host can decide to use IPv4 or IPv6. An operator is required to deploy a set of AFTR elements in the network. The AFTR should be dual-stack to terminate the IP-in-IPv6 tunnel from B4 elements and deliver NAT-ed packets to IPv4 Internet. 3.1.1.2. Network Impact DS-lite requires the access network to support IPv6. This requires the CMTS and cable modem to be IPv6 enabled. It also requires to deploy a set of AFTR elements in the operator network. AFTR is a stateful network device, it inherits the cost to manage a stateful network device inside the network. IPv4 packets are delivered on the IP-in-IPv6 tunnel. This reduces the effective MTU side. Neither hosts behind the B4 element nor services in front of the AFTR are aware of the tunnel. The operator can increase the MTU size in the access network. However, many cable modem implementations do not support MTU larger than default 1500 bytes, so the B4 and AFTR elements must handle fragmentation caused by the tunnel overhead. The AFTR owns the NAT pool, it will be the aggregation point of the IPv4 addresses defined in the NAT pool. AFTR must advertise the NAT pool prefix to the IPv4 Internet. In contrast, the IPv6 tunnel interface should stay only inside the operator's IGP and should not be advertised to the IPv6 Internet. 3.1.1.3. Operation Impact DS-lite identifies a user by IPv6 address. Operators should be trained to understand how to map a user from an IPv6 address in the AFTR. AFTR is a NAT device, operator should maintain the NAT binding information to satisfy the government regulations. This is standard procedure for operating any NAT44 device. Lee & Kuarsingh Expires March 23, 2011 [Page 9] Internet-Draft IPv6 Transition Cable Use Cases September 2010 DS-Lite introduces the operational mode where historical IPv4 connectivity (as experienced) is now totally dependent on IPv6. This significant change in operating conditions must be well understood by the operator. If DS-lite is introduced during deployment infancy in the operators IPv6 network, it will require careful attention to operational practices and capabilities to maintain the IPv6 network. AFTR is critical to continuously offer IPv4 access in IPv6-only access network. Operator should scale AFTR to provide non- interruptive access to users. Operators should closely monitor two AFTR's resources: (1) Network Capacity and (2) Port Utilization. When network capacity is reached, the operator should decide to upgrade the AFTR to higher network capacity or to deploy a new AFTR to balance the workload. When port utilization is high, the operator should increase the NAT pool size. AFTR is stateful, it will complicate the high-availability (HA) design. Operators should apply the standard HA design (e.g. cold or hot) which best fits to their network operations. 3.1.1.4. CPE Impact CPE is required to implement the B4 element specification. Also, port-forwarding and UPnP IGD protocol will no longer function. IETF PCP Working Group was formed to address the port-forwarding and UPnP IGD issues. CPE must know the IPv6 address of the AFTR tunnel interface. This information can be obtained from DHCP. Since there is only IPv6 access to the B4 element. Any IPv4 network service learned from DHCP must be proxy by the B4 element. If the operator cannot increase the access network MTU size, the B4 element must handle fragmentation to ensure IPv4 service using maximum MTU size won't be affected by the tunnel overhead. 3.1.1.5. Application Impact 3.1.1.5.1. Egress Connection Since hosts behind B4 are provisioned with dual-stack, the application can decide to use IPv4 or IPv6. If the external service is also dual-stack, the host will automatically prefer IPv6 over IPv4 if the host O/S has implemented [RFC3484]. If the host prefers IPv4 due to application logic, it will use the private IPv4 address provisioned by the B4 element. For applications expecting to use specific source port will be impacted because the AFTR inside the network won't be able to allocate a specific source port. Lee & Kuarsingh Expires March 23, 2011 [Page 10] Internet-Draft IPv6 Transition Cable Use Cases September 2010 Applications use random source port will continue to function without modification. 3.1.1.5.2. Ingress Connection Similar to traditional NAT, ingress connection will be blocked by default. The current techniques such as port-forwarding and UPnP IGD are required modification. Technically this could be done. But this will requires some changes in user's procedure to enable the service. It also adds cost to operators to offer port-forwarding service. 3.2. Public IPv4 Address Use Case Some applications requires specific source port and some applications requires ingress connection. Users using those applications may want to be provisioned with a public IPv4 address to ease the potential challenges caused by NAT in the network. IPv4-over-IPv6 (4over6) [I-D.cui-softwire-host-4over6] is a simple technology to provision a public IPv4 address to a user and provide IPv4 access over an IPv6- only network. 3.2.1. IPv4 Over IPv6 3.2.1.1. Deployment Requirements 4over6 consists of two elements: 4over6 Initiator and 4over6 Tunnel Concentrator (TC). 4over6 is similar to DS-lite except two features: (1) Unlike B4 element, 4over6 Initiator will be provisioned with a public IPv4 address. (1) 4over6 TC only terminates the IP-in-IPv6 tunnel and won't perform any NAT44 function. 4over6 supports both host and CPE models. We will only discuss the 6over6 CPE model. An operator is required to deploy 4over6 Initiator in premises. The 4over6 initiator will replace the existing CPE and must be the first network device in front of the cable modem. The operator will provide an IPv6 address and an IPv6 prefix to the CPE. The procedure is similar to Native IPv6 use case and DS-lite use case. 4over6 Initiator is very similar to the B4 element. It serves as DHCP server, IPv4 default gateway and DNS server to hosts behind it. The only difference is 4over6 will be provisioned with a public IPv4 address while B4 element will not. Once 4over6 Initiator discovers the 4over6 TC, it will issue standard DHCP request over the tunnel to the 4over6 TC. The 4over6 TC either relays the DHCP request to a centralized DHCP server or replies to the request if it is the authoritative DHCP server for the 4over6 service. Once the CPE Lee & Kuarsingh Expires March 23, 2011 [Page 11] Internet-Draft IPv6 Transition Cable Use Cases September 2010 acquires the public IPv4 address, the user can run all his legacy IPv4 applications similar to what he is doing with a regular IPv4 home gateway. 3.2.1.2. Network Impact Similar to DS-lite, the access network must support IPv6. This requires the CMTS and cable modem must be IPv6 enabled. It also requires the operator to deploy a set of 4over6 TC in the network. Despite no NAT in the 6over4 TC, 6over4 TC is required to maintain the 4over6 Initiate IPv6 address (tunnel-id) and IPv4 address binding. Also, the 4over6 TC must advertise the IPv4 prefix to the Internet. It is the aggregation point of the IPv4 address prefix. 4over6 suffers the same MTU limitation which is common to any tunnel protocols. Please refer to Section 3.1.1.2 for details. 3.2.1.3. Operation Impact Since each user will be assigned a public IPv4 address, it doesn't require operator to log any binding. Operator should be able to identify a user by either IPv4 or IPv6 address. Similar to AFTR, network capacity and IPv4 address utilization are critical resources to 4over6 TC. Operator must closely monitor the resources to ensure continuous IPv4 access. Operators also need to coordinate the IPv4 address space in the DHCP server and the 4over6 Initiator which manages the space. This requires careful coordination and management. 3.2.1.4. CPE Impact CPE is required to implement the 4over6 TC specification. Unlike B4 element, port-forwarding and the UPnP IGD will work without modification. 3.2.1.5. Application Impact Applications will have dual-stack and should behave identically as of running on a native dual-stack host. 4. Security Considerations TBD Lee & Kuarsingh Expires March 23, 2011 [Page 12] Internet-Draft IPv6 Transition Cable Use Cases September 2010 5. Acknowledgements TBD 6. IANA Considerations This memo includes no request to IANA. 7. References 7.1. Normative References [I-D.arkko-ipv6-transition-guidelines] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", draft-arkko-ipv6-transition-guidelines-06 (work in progress), August 2010. [I-D.cui-softwire-host-4over6] Cui, Y., Wu, J., and P. Wu, "Host 4over6 for IPv6 host connecting IPv4 Internet", draft-cui-softwire-host-4over6-01 (work in progress), July 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 7.2. Informative References [I-D.droms-dhc-dhcpv6-agentopt-delegate] Droms, R., "DHCP Relay Agent Assignment Notification Option", draft-droms-dhc-dhcpv6-agentopt-delegate-00 (work in progress), November 2005. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", Lee & Kuarsingh Expires March 23, 2011 [Page 13] Internet-Draft IPv6 Transition Cable Use Cases September 2010 BCP 5, RFC 1918, February 1996. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. Authors' Addresses Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 U.S.A. Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: victor.kuarsingh@rci.rogers.com URI: http://www.rogers.com Lee & Kuarsingh Expires March 23, 2011 [Page 14]