v6ops V. Kuarsingh, Ed. Internet-Draft Rogers Communications Intended status: Informational L. Howard Expires: May 30, 2012 Time Warner Cable November 27, 2011 Wireline Incremental IPv6 draft-ietf-v6ops-wireline-incremental-ipv6-00 Abstract Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face challenges related to both IPv6 introduction along with a growing risk of IPv4 run out within their organizations. The overall problem for many operators will be to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices and systems with a depleting supply of IPv4 addresses. The overall transition will take most networks from an IPv4-Only environment to a dual stack network environment and potentially an IPv6-Only operating mode. This document helps provide a framework for Wireline providers who may be faced with many of these challenges as they consider what IPv6 transition technologies to use, how to use the selected technologies and when to use them. 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 May 30, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Kuarsingh & Howard Expires May 30, 2012 [Page 1]

Internet-Draft Wireline Incremental IPv6 November 2011 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. Kuarsingh & Howard Expires May 30, 2012 [Page 2]

Internet-Draft Wireline Incremental IPv6 November 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Operator Assumptions . . . . . . . . . . . . . . . . . . . . . 4 3. Reasons and Considerations for a Phased Approach . . . . . . . 5 3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 5 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 3.3. IPv6 Introduction and Maturity . . . . . . . . . . . . . . 6 3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7 3.5. Sub-Optimal Operation of Transition Technologies . . . . . 7 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 8 4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 8 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 8 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 9 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 11 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 11 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 11 5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 12 5.1.3. Phase 0 - Foundation: Network Policy and Security . . 12 5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 12 5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 13 5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 13 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 14 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 16 5.3.1. Native Dual Stack Deployment Considerations . . . . . 16 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 17 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 18 5.5. Phase 3 - Tunnelled IPv4 . . . . . . . . . . . . . . . . . 19 5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Kuarsingh & Howard Expires May 30, 2012 [Page 3]

Internet-Draft Wireline Incremental IPv6 November 2011 1 . Introduction RFC6180] which provides guidance on using IPv6 transition mechanisms. This document will show how well defined technologies such as 6RD [RFC5969], DS-Lite [RFC6333] and Carrier Grade NAT (NAT44 without tunnelling as distinct from DS- Lite) used with native dual stack to deliver effective IPv4 and IPv6 services in an evolving wireline network. 2 . Operator Assumptions Kuarsingh & Howard Expires May 30, 2012 [Page 4]

Internet-Draft Wireline Incremental IPv6 November 2011 minimize the cost of IPv6 transition technologies by containing the scale required by the relevant systems. 3 . Reasons and Considerations for a Phased Approach 3.1 . Relevance of IPv6 and IPv4 Kuarsingh & Howard Expires May 30, 2012 [Page 5]

Internet-Draft Wireline Incremental IPv6 November 2011 the home network will demand both IPv4 and IPv6 for some time. 3.2 . IPv4 Resource Challenges RFC1918]. These measures are tactical and do not support a longer term strategic option. The lack of new IPv4 addresses will therefore force operators to support some form of IPv4 address sharing and may impact technological options for transition once the operator runs out of new IPv4 addresses for assignment. 3.3 . IPv6 Introduction and Maturity Kuarsingh & Howard Expires May 30, 2012 [Page 6]

Internet-Draft Wireline Incremental IPv6 November 2011 DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, along with other systems. Although the base technological capabilities exist to enable and run IPv6 in most environments, it may not be as robust as IPv4, and until such time as each key technical member of an operator's organization can identify IPv6, understand its relevance to the IP Service offering, how it operates and how to troubleshoot it - it's still maturing. 3.4 . Service Management 3.5 . Sub-Optimal Operation of Transition Technologies Kuarsingh & Howard Expires May 30, 2012 [Page 7]

Internet-Draft Wireline Incremental IPv6 November 2011 When IPv6 tunnelling is used, an operator may not want to enable IPv6 for their services, especially high traffic services. Likewise, when CGN is deployed, the operation may wish to promote IPv6 access. 4 . IPv6 Transition Technology Analysis 4.1 . Automatic Tunnelling using 6to4 and Teredo RFC3056] which is most commonly used with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely by many Internet hosts. Documents such as [RFC6343] have been written to help operators understand observed problems and provide guidelines on how to manage such protocols. An Operator may want to provide local relays for 6to4 and/or Teredo to help improve the protocol's performance for ambient traffic utilizing these IPv6 connectivity methods. Experiences such as those described in [I-D.jjmb-v6ops-comcast-ipv6- experiences] show that local relays have proved beneficial to 6to4 protocol performance. Operators should also be aware of breakage cases for 6to4 if non- RFC1918 address are used for CGN zones. Many off the shelf CPEs and operating systems may turn on 6to4 without a valid return path to the originating (local) host. This particular use is likely to occur if any space other than [RFC1918] is used, including Shared CGN Space[I- D.weil-shared-transition-space-request] or space registered to another organization (squatted space). The operator can use 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to block 6to4 operation entirely by blocking 2002::/16 at its edges. 4.2 . Carrier Grade NAT (NAT444) I-D.ietf-behave-lsn-requirements], may prove beneficial for those operators who offer Dual Stack services to customer endpoints Kuarsingh & Howard Expires May 30, 2012 [Page 8]

Internet-Draft Wireline Incremental IPv6 November 2011 once they exhaust their pools of IPv4 addresses. CGNs, and address sharing overall, are known to cause certain challenges for the IPv4 service [RFC6269], but will often be necessary for a time. In a network where IPv4 address availability is low, CGN may provide continued access to IPv4 endpoints. Other technologies (4rd, IVI) may also be used in place of the NAT444 model with CGN. Some of the advantages of using CGN include the similarities in provisioning and activation of IPv4 hosts within a network and operational procedures in managing such hosts or CPEs (i.e. DHCPv6, DNSv4, TFTP, TR-069 etc). When considered in the overall IPv6 transition, CGN may play a vital role in the delivery of Internet services. 4.3 . 6RD RFC5969] does provide a quick and effective way to deliver IPv6 services to customers who do not yet support Native. 6RD provides tunnelled connectivity for IPv6 over the existing IPv4 path. As the access edge is upgraded and customer premise equipment is replaced, 6RD can be superseded by Native IPv6 access. 6RD can be delivered along with CGN, but then no traffic would be native; all traffic would be intermediated. 6RD may also be advantageous during the early transition while IPv6 traffic volumes are low. During this period, the operator can gain experience with IPv6 on the core and improve their peering framework to match those of the IPv4 service. 6RD scales easily by adding relays. As IPv6 traffic volume grows, the operator can gradually replace 6RD with native IPv6. 6RD client support is required, but most currently deployed CPEs do not have 6RD client functionality built into them and may not be upgradable. 6RD deployments would most likely require the replacement of the home CPE. An advantage of this technology over DS-Lite is that the WAN side interface does not need to implement IPv6 to function correctly which may make it easier to deploy to field hardware which is restricted in memory footprint, processing power and storage space. 6RD will also require parameter configuration which can be powered by the operator through DHCPv4, manually provisioned on the CPE or automatically through some other means. Manual provisioning would likely limit deployment scale. 4.4 . Native Dual Stack Kuarsingh & Howard Expires May 30, 2012 [Page 9]

Internet-Draft Wireline Incremental IPv6 November 2011 already used in many existing IPv6 deployments. Native Dual Stack does however require that Native IPv6 be delivered to the customer premise. This technology option is desirable in many cases and can be used immediately if the access network and customer premise equipment supports Native IPv6 to the operator's access network. An operator who runs out of IPv4 addresses to assign to customers will not be able to provide Native Dual Stack. For a sub-set of the IPv6 Native Customers, operators may include IPv4 through a CGN. Delivering Native Dual Stack would require the operator's core and access network support IPv6. Additionally, other systems like DHCPv6, DNS, and diagnostic/management facilities need to be upgraded to support IPv6. The upgrade of such systems may often not be trivial. 4.5 . DS-Lite RFC6333]) provides IPv4 services to customer networks which are only addressed with IPv6. DS-Lite provides tunnelled connectivity for IPv4 over an IPv6 path between the customer's network device and a provider managed gateway (AFTR). DS-Lite can only be used where there is native IPv6 connectivity between the AFTR and the customer premise endpoint. This may mean that the technology's use may not be viable during early transition. The operator may also not want to subject the customers' IPv4 connection to the IPv6 path. The provider may also want to make sure that most of their internal services, and external content is available over IPv6 before deploying DS-Lite. This would lower the overall load on the AFTR devices helping reduce. By sharing IPv4 addresses among multiple endpoints, like a CGN, DS- Lite can facilitate continued growth of IPv4 services even at runout. There are some functional considerations [draft-donley-nat444-impacts]. Similar to 6RD, DS-Lite requires client support on the CPE to function. Client functionality is likely to be more prevalent in the future as IPv6 capable (WAN side) CPEs begin to penetrate the market. This includes both retail and operator provided gateways. 4.6 . NAT64 RFC6146] provides the ability to connect IPv6-Only connected clients and hosts to IPv4 Servers (or other like hosts). NAT64 requires that the host and home network supports IPv6-Only modes of operation. This type of environment is not considered typical in Kuarsingh & Howard Expires May 30, 2012 [Page 10]

Internet-Draft Wireline Incremental IPv6 November 2011 most traditional Wireline connections. In the future, NAT64 may become more viable for Wireline providers as home networking environments support IPv6-Only. In the meantime, DS- Lite provides in-home IPv4 services over an IPv6-Only network (WAN). 5 . IPv6 Transition Phases RFC6180]. Also, guidance on incremental CGN for IPv6 transition can also be found in [RFC6264]. 5.1 . Phase 0 - Foundation 5.1.1 . Phase 0 - Foundation: Training Kuarsingh & Howard Expires May 30, 2012 [Page 11]

Internet-Draft Wireline Incremental IPv6 November 2011 Customer support staff would require much more basic, but large scale training as many organizations have massive call centres to support the customer base. 5.1.2 . Phase 0 - Foundation: Routing 5.1.3 . Phase 0 - Foundation: Network Policy and Security RFC4942], [RFC6092], [RFC6169], for instance) are excellent resources. 5.1.4 . Phase 0 - Foundation: Transition Architecture Kuarsingh & Howard Expires May 30, 2012 [Page 12]

Internet-Draft Wireline Incremental IPv6 November 2011 equipment is suited to support those modes of operation. This is important for both network gear and customer premise equipment. 5.1.5 . Phase 0- Foundation: Tools and Management 5.2 . Phase 1 - Tunnelled IPv6 RFC5969]. Note that 6to4 and Teredo have different address selection behaviours from 6RD [RFC3484]. Additional guidelines on deploying and supporting 6to4 can be found in [RFC6343]. The operator can deploy 6RD relays easily and scale them as needed to meet the early customer needs of IPv6. Since 6RD requires the upgrade or replacement of CPE gateways, the operator may want ensure that the gateways support not just 6RD but Native Dual Stack and other tunnelling technologies if possible. 6RD clients are now available in some retail channel products and within the OEM market. Retail availability of 6RD is important since not all operators control or have influence over what equipment is deployed in the consumer home network. Kuarsingh & Howard Expires May 30, 2012 [Page 13]

Internet-Draft Wireline Incremental IPv6 November 2011 +--------+ ----- | | / \ Encap IPv6 Flow | 6RD | | IPv6 | - - -> | BR | <- > | Net | +---------+ / | | \ / | | / +--------+ ----- | 6RD + <----- ----- | | / \ | Client | IPv4 Flow | IPv4 | | + < - - - - - - - - - - - - - - -> | Net | | | \ / +---------+ ----- Figure 1: 6RD Basic Model 6RD used as an initial phase technology also provides the added benefit of a deterministic IPv6 prefix which is based on the IPv4 assigned address. Many operational tools are available or have been built to identify what IPv4 (often dynamic) address was assigned to a customer host/CPE. So a simple tool and/or method can be built to help the operational staff in an organization know that the IPv6 prefix is for 6RD based on knowledge of the IPv4 address. An operator may choose to not offer internal services over IPv6 if such services generate a large amount of traffic. This mode of operation should avoid the need to greatly increase the scale of the 6RD Relay environment. 5.2.1 . 6RD Deployment Considerations Kuarsingh & Howard Expires May 30, 2012 [Page 14]

Internet-Draft Wireline Incremental IPv6 November 2011 operator anticipate massive scaling of the environment. This way, the operator has multiple vectors by which to scale the service. +--------+ | | IPv4 Addr.X | 6RD | - - - > | BR | +-----------+ / | | | Client A | <- - - +--------+ +-----------+ Separate IPv4 Service Addresses +-----------+ | Client B | < - - +--------+ +-----------+ \ | | - - - > | 6RD | IPv4 Addr.Y | BR | | | +--------+ Figure 2: 6RD Multiple IPv4 Service Address Model +--------+ | | IPv4 Addr.X | 6RD | - - - > | BR | +-----------+ / | | | Client A |- - - - +--------+ +-----------+ Common (Anycast) IPv4 Service Addresses +-----------+ | Client B | - - - +--------+ +-----------+ \ | | - - - > | 6RD | IPv4 Addr.X | BR | | | +--------+ Figure 3: 6RD Anycast IPv4 Service Address Model Provisioning of the endpoints is affected by the deployment model chosen (i.e. anycast vs. specific service IPs). Using multiple IPs may require more planning and management as customer equipment will have different sets of data to be provisioned into the devices. The Kuarsingh & Howard Expires May 30, 2012 [Page 15]

Internet-Draft Wireline Incremental IPv6 November 2011 operator may use DHCPv4, manual provisioning or other mechanisms to provide parameters to customer equipment. If the operator manages the CPE, support personnel will need tools able to report the status of the 6RD tunnel. Usage information can be counted on the operator edge, but if it requires source/ destination flow details, data must be collected after the 6RD relay (IPv6 side of connection). +---------+ IPv4 Encapsulation +------------+ | +- - - - - - - - - - - + | | 6RD +----------------------+ 6RD +--------- | | IPv6 Packet | Relay | IPv6 Packet | Client +----------------------+ +--------- | +- - - - - - - - - - - + | ^ +---------+ ^ +------------+ | | | | | IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis Figure 4: 6RD Tools and Flow Management 5.3 . Phase 2: Native Dual Stack RFC3484] the IPv6 address delivered via Native IPv6 (assumed to be a Delegated Prefix as per [RFC3769]). Native Dual Stack is the best option, and should be sought as soon as possible. During this phase, the operator can confidently move both internal and external services to IPv6. Since there are no translation devices needed for this mode of operation, it transports both protocols (IPv6 and IPv4) efficiently within the network. 5.3.1 . Native Dual Stack Deployment Considerations Kuarsingh & Howard Expires May 30, 2012 [Page 16]

Internet-Draft Wireline Incremental IPv6 November 2011 and support systems such as DHCPv6, DNS and other functions which support the customer's IPv6 Internet connection need to be in place. The operator must treat IPv6 connectivity as seriously as IPv4. Poor IPv6 service may be worse than not offering an IPv6 service at all, since users will disable IPv6, which will be difficult for the operator to reverse. New code and IPv6 functionality may cause instability at first. The operator will need to monitor, troubleshoot and resolve issues promptly. Prefix assignment and routing are new for common residential services. Prefix assignment is straightforward (DHCPv6 using IA_PDs), but installation and propagation of routing information for the prefix, especially during access layer instability, is often poorly understood. The Operator should develop processes for renumbering customers who they move to a new Access nodes. Operators need to keep track of both the dynamically assigned IPv4 and IPv6 addresses. Any additional dynamic elements, such as auto- generated DNS names, need to be considered and planned for. 5.4 . Intermediate Phase for CGN Kuarsingh & Howard Expires May 30, 2012 [Page 17]

Internet-Draft Wireline Incremental IPv6 November 2011 extending connectivity for the IPv4 path while the IPv6 path remains native. For endpoints operating in a IPv6+CGN model the Native IPv6 path is available for higher quality connectivity helping host operation over the network while the CGN path may offer a less then optimal performance. +--------+ ----- | | / \ IPv4 Flow | CGN | | IPv4 | - - -> + + < -> | Net | +---------+ / | | \ / | | <- - - / +--------+ ------- | Dual | | Stack | ----- | CPE | IPv6 Flow / IPv6 \ | | <- - - - - - - - - - - - - - - > | Net | |---------+ \ / ----- Figure 6: Dual Stack with CGN CGN deployments may make use of a number of address options which include RFC1918 or Shared CGN Address Space [I-D.weil-shared- transition-space-request]. It is also possible that operators may use part of their own RIR assigned address space for CGN zone addressing if RFC918 addresses pose technical challenges in their network. It is not recommended that operators use squat space as it may pose additional challenges with filtering and policy control. 5.4.1 . CGN Deployment Considerations Kuarsingh & Howard Expires May 30, 2012 [Page 18]

Internet-Draft Wireline Incremental IPv6 November 2011 +--------+ ----- | | / \ | CGN | | | - - -> + + < -> | | +---------+ / | | | | | CPE | <- - - / +--------+ | IPv4 | | | ^ | | |---------+ | | Net | +--------+ Centralized | | +---------+ | | CGN | | | | | CGN | | | | CPE | <- > + + <- - - - - - - > | | |---------+ | | \ / +--------+ ----- ^ | Distributed CGN Figure 7: CGN Deployment: Centralized vs. Distributed The operator may be required to log translation information [draft-sivakumar-behave-nat-logging]. This logging may require significant investment in external systems which ingest, aggregate and report on such information [draft-donley-behave-deterministic-cgn]. Since CGN has impacts on some applications [draft-donley-nat444-impacts], operators may deploy CGN only for those customers who do not use affected applications. Affected customers could be selected by observing usage, or by offering CGN and Native IPv4 for different prices. 5.5 . Phase 3 - Tunnelled IPv4 Kuarsingh & Howard Expires May 30, 2012 [Page 19]

Internet-Draft Wireline Incremental IPv6 November 2011 +--------+ ----- | | / \ Encap IPv4 Flow | AFTR | | IPv4 | -------+ +---+ Net | +---------+ / | | \ / | | / +--------+ ----- | DS-Lite +------- ----- | | / \ | Client | IPv6 Flow | IPv6 | | +-------------------------------| Net | | | \ / +---------+ ----- Figure 8: DS-Lite Basic Model If the operator was forced to enable CGN for a NAT444 deployment, they may be able to co-locate the AFTR and CGN functions within the network to simplify capacity management and the engineering of flows. DS-Lite however requires configuration of the CPE and the implementation of the AFTR. 5.5.1 . DS-Lite Deployment Considerations Kuarsingh & Howard Expires May 30, 2012 [Page 20]

Internet-Draft Wireline Incremental IPv6 November 2011 points, how they interact with each other at the CPE, and how they will be provisioned. As an example, an operator may use 6RD in the outset of the transition, then move to Native Dual Stack followed by DS-Lite. 6 . IANA Considerations 7 . Security Considerations 8 . Acknowledgements 9 . References 9.1 . Normative References I-D.ietf-v6ops-v4v6tran-framework] Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for IP Version Transition Scenarios", draft-ietf-v6ops-v4v6tran-framework-02 (work in progress), July 2011. [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011. 9.2 . Informative References I-D.donley-nat444-impacts] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. Colorado, "Assessing the Impact of Carrier-Grade NAT on Network Applications", draft-donley-nat444-impacts-03 (work in progress), November 2011. [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., Kuarsingh & Howard Expires May 30, 2012 [Page 21]

Internet-Draft Wireline Incremental IPv6 November 2011 Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US Email: lee.howard@twcable.com URI: http://www.timewarnercable.com Kuarsingh & Howard Expires May 30, 2012 [Page 24]