v6ops V. Kuarsingh, Ed. Internet-Draft Rogers Communications Intended status: Informational July 5, 2011 Expires: January 6, 2012 Wireline Incremental IPv6 draft-kuarsingh-wireline-incremental-ipv6-00 Abstract Operators are currently challenged with enabling IPv6 within their networks while maintaing IPv4 connectivity beyond IPv4 address depletion. In the Wireline world, this will often require the replacement of access network equipment and consumer equipment along with the uplift of the core network. During the transition from the IPv4-Only service environment to the IPv6/IPv4 dual service environment, operators may often need to use multiple transition technologies and mechanisms to maintain services for their customer base. This draft is set up to show how some Wireline provides (including Cable, DSL and Fibre) may accomplish this using tunnelling, translation and native IPv6 services. 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 January 6, 2012. Copyright Notice Copyright (c) 2011 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 Kuarsingh Expires January 6, 2012 [Page 1] Internet-Draft Wireline Incremental IPv6 July 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Reasons for a Phased Approach . . . . . . . . . . . . . . . . 4 3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 4 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 4 3.3. IPv6 Introduction and Maturity . . . . . . . . . . . . . . 5 3.4. Impact to Operators . . . . . . . . . . . . . . . . . . . 5 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 6 4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 6 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 7 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 9 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 9 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 9 5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 10 5.1.3. Phase 0 - Foundation: Network Policy and Security . . 10 5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 10 5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 10 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 11 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 12 5.5. Phase 3 - Tunnelled IPv4 . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Kuarsingh Expires January 6, 2012 [Page 2] Internet-Draft Wireline Incremental IPv6 July 2011 1. Introduction IPv6 represents the strategic IP protocol version which will meet the addressing needs of the Internet into the future. Many operators are already working to implement IPv6 within their networks, and many others may just be starting this process. A solid IPv6 plan will need to include both the baseline requirements to enable IPv6 within the network, but must also include facilities to provide continuance for IPv4 connectivity. Given the vast number of technological options now available to operators for transition to IPv6, the task may seem daunting when attempting to identify which technologies are appropriate for a given network, and how these technologies can be introduced. This draft sets out to help operators who may be just starting the evaluation process by identifying which technologies can be used in an incremental fashion to transition from an IPv4-only environment to an efficient IPv6/IPv4 environment. Although no single plan will work for for all operators, generically, those listed herein provide a baseline which can be included in many plans. This draft is specifically catered towards wireline environments which may use technologies such as Cable, DSL and/or Fibre as the access method to the end consumer. This draft also attempts to follow the methodologies set out in [I-D.ietf-v6ops-v4v6tran- framework] to identify how the technologies can be used. This document also attempts to follow the principles laid out in [RFC6180] which provides guidance on using transition mechanisms. This document will show how tunnelling using 6RD and DS-Lite as well as translation via CGN can be used with native IPv6 to deliver effective dual stack services in an evolving wireline network. 2. Motivation Wireline Operators are increasingly becoming aware of the need to support IPv6. The depletion of unassigned IPv4 addresses within IANA and the RIRs has highlighted the need to move beyond IPv4. In many operator environments, the main task will be the addition of IPv6 into the network. As straightforward as this task may seem, it will require forethought and planning. However, of greater concern is that the introduction of IPv6 may need to take place in a volatile environment where IPv4 resources are depleted complicating what technologies can be used, and how dual stack services may be offered to customers. Operators will want to understand which of the prevailing technologies can be used in a changing network environment while Kuarsingh Expires January 6, 2012 [Page 3] Internet-Draft Wireline Incremental IPv6 July 2011 adapting to the needs and conditions of the network. The Operator's main goal will be to maintain quality IP services to Internet customers while the world moves from a predominately IPv4 centric system to a dual stack IPv6/IPv4 system and eventually to an IPv6 centric world. 3. Reasons for a Phased Approach Operators may want to consider a phased approach to IPv6 service introduction for a number of reasons. These reasons include the relevance of both IPv4 and IPv6 services in the new ecosystem over the next few years. Both protocols will play a key role in providing a holistic service to customers in various ways. IPv4 resources will likely become depleted in many networks during the IPv6 transition inhibiting the general use of traditional dual stack. Additionally, IPv6 will often be a new protocol for operators and their staff further challenging their task and potentially limiting how quickly they can move to full IPv6 dependence. 3.1. Relevance of IPv6 and IPv4 The reality for operators over the next few years will be that both IPv4 and IPv6 will play a role in the Internet experience. Although many IPv6 advocates seek to move the Internet to IPv6 quickly, the fact that many older operating systems and hardware support IPv4-only operating modes will need to be accepted. Additionally, the Internet is made of of many interconnecting systems, networks and various content sources all of which will move to IPv6 at different rates. The Operator's mandate during this time of transition will be to support connectivity to both IPv6 and IPv4 through various technological means. 3.2. IPv4 Resource Challenges Since connectivity to IPv4-only endpoints and/or content will remain a reality for a period of time, IPv4 resource challenges are of key concern to operators. The lack of new IPv4 addressees for additional endpoints means that growth in some networks will be based on address sharing. Networks are growing at different rates based on a number of factors which may be related to emerging markets and/or proliferation of Internet based services. Given the reality that growth on the Internet will continue, IPv4 address constraints will likely impact many if not most operators at some point. This will play an important role when considering what technologies are viable as the Kuarsingh Expires January 6, 2012 [Page 4] Internet-Draft Wireline Incremental IPv6 July 2011 transition period moves on. Of note will be any use of technologies which rely on IPv4 as the mechanism to supply IPv6 services such as 6RD. Also, if native dual stack is considered by the operator, challenges on the IPv4 path is also of concern. 3.3. IPv6 Introduction and Maturity Operators will want to or be forced to support IPv6 at some point. The introduction of IPv6 will require the operationalization of IPv6. The IPv4 environment we have today was built over time and was matured by experience. Although many of these experiences are transferable from IPv4 to IPv6, new experience is necessary for IPv6 nonetheless. Engineering and Operational staff will need to become acclimatized to IPv6 which will take time as experience is gained. During this ramp up period, Operators will need to be aware that instability may occur and should be taking this into account when selecting what technologies are viable during early transition. Operators may not want to subject their mature IPv4 service to a "new IPv6" path initially while it may be going through growing pains. This plays a role during initial transition when considering technologies which require IPv6 to support IPv4 services such as DS-Lite. Of consideration as well will be the reality that some of these technologies are new and/or are still under development and refinement. Deployment experience may be needed to vet these technologies out and stabilize them in production environments. Many supporting systems are also under development and have newly developed IPv6 functionality including vendor implementations of 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; until such time as each key technical member of an operator's organization can identify IPv6, understand it's relevance to the IP Service offering, how it operates and how to troubleshoot it - it's still maturing. 3.4. Impact to Operators The lack of new IPv4 addresses related to depletion and the relative maturity state of IPv6 within the operator network will both impact what technologies can be used, when they can be used and how they can be used. Operators are welcome to evaluate the impact of these challenges on their own, but some considerations are highlighted herein. Kuarsingh Expires January 6, 2012 [Page 5] Internet-Draft Wireline Incremental IPv6 July 2011 The lack of IPv4 addresses will surely mean that any service requiring it's use as a method to deliver just IPv4, or a vehicle to deliver IPv6 may be short lived. This may also limited their usefulness to initial transition phases. Nothing precludes an operator from using technologies for longer periods of time, but the relative impacts need to be considered. Also, some technologies based on native IPv6 delivery will need to be weighed as well. This includes traditional dual stack and more importantly technologies like DS-Lite which require a native IPv6 path to the customer premise The operator may want to wait until a certain maturity level is reached with respect to IPv6 before making IPv6 connectivity mandatory to service IPv4 flows given the potential for failure at the outset. 4. IPv6 Transition Technology Analysis Understanding the main IPv6 transition technologies and those related to dealing with IPv4 run out should be a primary goal of any operator. Although this draft is not designed to list all options or to provide a full technical analysis of each of the identified technologies, it provides a brief description and explains how they can or may be used in a transitioning operator network. 4.1. Automatic Tunnelling using 6to4 and Teredo Operators may not be actively deploying IPv6, but automatic mechanisms do exist on deployed operating systems and hardware that should be of note. Such technologies include 6to4 described within [RFC3056] which is mostly commonly used in a deployment mode using anycast relays as described in [RFC3068]. Additionally, Teredo [RFC4380] is also used widely by many Internet hosts as a means to reach the IPv6 world when no native or operator provided path is made available. The operator may not want or have intended for these technologies to be active in their networks, but should be aware that the traffic exists and may be inclined to provide the best possible experience for these endpoints. Drafts such as [I-D.ietf-v6ops-6to4-advisory] have been written to help operators understand observed problems and provide guidelines on how to manage such protocols. An Operator may want to incrementally provide local relays for 6to4 and/or Teredo to help improve the protocol's performance for ambient traffic utilizing these 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. Kuarsingh Expires January 6, 2012 [Page 6] Internet-Draft Wireline Incremental IPv6 July 2011 4.2. Carrier Grade NAT (NAT444) Carrier Grade NAT (GGN), specifically as deployed in a NAT444 scenario [I-D.ietf-behave-lsn-requirements], is also a relevant technology. CGN/NAT444 is not a IPv6 specific function, but may prove beneficial for those operators who offer dual stack services to endpoints. CGNs are known to cause certain challenges for the IPv4 service path as described in documents like [I-D.donley-nat444- impacts], but may often be necessary for a time. In a network where IPv4 address availability is low or no new addressees can be assigned to Internet hosts, a CGN/NAT444 deployment may be a viable way to provide continued access to the IPv4 path. Other technologies may also be used, but a provider may choose to use this method earlier on since it's a well understood method of delivering IPv4 connectivity - notwithstanding the challenges of NAT444. When considered in the overall IPv6 transition, CGN/NAT444 may play a vital role in delivery Internet services. 4.3. 6RD 6RD as described in [RFC5969] does provide a quick and effective way to deliver IPv6 services to access network endpoints which do not yet support IPv6. 6RD provides tunnelled connectivity to IPv6 over the existing IPv4 path. The lack of native IPv6 for a customer premise may be related to technological challenges of delivering IPv6 on a give access type or related to other operational or technical impediments that may existing in an operator's environment. 6RD defiantly offers a solid early transition option to operators by eliminating the bottle neck of needing to deploy native IPv6 to the access edge. Over time, as the access edge is upgraded, 6RD can be replaced by native IPv6 access. 6RD can be delivered along with CGN/ NAT444, but this would be a sub-optimal way of delivering service since the operator would then need to relay all IPv6 traffic as well as provide NAT functionally for IPv4 flows. 6RD may also be seen as advantageous during 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 meet those of the IPv4 service. Scaling of 6RD may be required by adding relays to the operator's network, but since 6RD is stateless, this task is quite manageable. In the case where CGN/ NAT444 is used, there are stateful considerations to be made on the NAT444 path. Operators may want to use 6RD, as noted, while traffic volumes are low and while internal services are mainly on IPv4. As higher Kuarsingh Expires January 6, 2012 [Page 7] Internet-Draft Wireline Incremental IPv6 July 2011 capacities are reached on the IPv6 path, the operator may want to move away from delivering heavy loads on a tunnelled connection. 6RD can continue to run indefinitely if the operator wishes to continue this service, but over time, native IPv6 would be a much more efficient way of delivering robust IPv6 services. 4.4. Native Dual Stack Native Dual Stack is often referred to as the "Gold Standard" of IPv6 and IPv4 delivery. It is a method of service delivery which is already used in some deployments. Native Dual Stack does however require that Native IPv6 be delivered to the customer premise. This technology option is most desirable in many cases and can be used immediately if the access network and customer premise equipment supports IPv6, or can also be used incrementally to tunnelling options such as 6RD over time. As time progresses, Native Dual Stack may be challenging to deliver if more IPv4 addresses are not available on the IPv4 path. For a sub-set of the IPv6 Native Dual Stack Customers, operators may include CGN/NAT444 as an assist technology. Delivering Native Dual Stack would require the operator's core and access network support IPv6 with the required assisting systems like DHCPv6, DNS, and diagnostic/management facilities to help maintain the IPv6 connection. 4.5. DS-Lite DS-Lite, as described in [I-D.ietf-softwire-dual-stack-lite], is an architecturally desirable way of delivery both IPv4 and IPv6 services in an IPv4 constrained environment. DS-Lite is able to provide IPv4 services to customer networks which are only addressed with IPv6. DS-Lite uses tunnelling mechanisms to pass IPv4 traffic between the customer's network device (often a CPE) and the IPv4 internet using a provider managed AFTR. DS-Lite however can only be used where there are native IPv6 facilities to the customer permise endpoint. This may mean that the technology's use may not be viable during early transition. The operator may also not want to use DS-Lite immediately after IPv6 introduction as the organization may be development and maturing their IPv6 environment and may not want to subject the customers IPv4 connection to the IPv6 path. This is likely an early transition consideration and would diminish over time as IPv6 service delivery is matured. The provider may also want to make sure that most of their internal services, and external provider content is available over IPv6 before deploying DS-Lite. This would lower the overall load on the AFTR devices helping reduce cost and load on that layer Kuarsingh Expires January 6, 2012 [Page 8] Internet-Draft Wireline Incremental IPv6 July 2011 of the network. Nothing precludes an operator from using DS-Lite earlier in the transition, but the operator needs to be aware of the challenges that can arise. If DS-Lite is used during early transition the operator will face scenario where they have support personnel learning to troubleshoot IPv6 while this new protocol is supporting the legacy IPv4 service. One of the strongest benefits of DS-Lite is the ability to continue to grow IPv4 services if required without the need to deploy more IPv4 addressees to customer endpoints. This is quite advantageous as the transition period progresses and IPv4 resources become more and more challenging to secure. 5. IPv6 Transition Phases The Phases described below are not provided as a ridged set of stops but as a guideline which can be considered by the operator. The phases reflect the need to support IPv4 and IPv6 during transition as well as the premise that some technologies may prove beneficial at various periods during the IPv6 transition. Operators may want to follow all these steps, skip some steps if possible or develop their own plans should they have other considerations which may be of relevance to them. The main goal however should be a set of phases that helps introduce IPv6, and allows for both protocols to work for a period of time as the Internet as whole moves to IPv6, followed by a declining need to add more IPv4 support. Additional guidelines and information on utilizing IPv6 transition mechanisms can also be found in [RFC6180]. 5.1. Phase 0 - Foundation Before moving an organization to support IPv6 services, a foundation needs to be made to support IPv6. This foundation includes the following basic (non-exhaustive) list of items. 5.1.1. Phase 0 - Foundation: Training Training may seem to be the most obvious step, but needs to be done effectively and widely across key technical personnel. Unlike IPv4 which had existed for a long period of time before it became "mission critical" for many organizations, IPv6 is being introduced at a time when IP services are vial for most many Internet users. This should not be taken likely and organizations need to commit to training their staff. Staff may also have far less if any experience with Kuarsingh Expires January 6, 2012 [Page 9] Internet-Draft Wireline Incremental IPv6 July 2011 IPv6 which is not the same as with IPv4. This means the little expose they get in their training may be all they have to lean on as they seek to support IPv6 at the outset. 5.1.2. Phase 0 - Foundation: Routing The network will all need to be in place to support IPv6. This includes the routed infrastructure along with addressing principles, routing principles, peering and related network functions. Since IPv6 is quite different from IPv4 in the number of addresses which are made available, careful attention to a scalable and manageable architecture needs to be made. Also, given that customer environments will no longer receive a token single address as is common in IPv4, operators will need to understand the impacts of delegating larges sums of addresses (Prefixes) to consumer endpoints. Delegating prefixes can be of specific importance in Cable environments where downstream customers often move between access nodes, raising the concern of frequent renumbering and/or managing movement of routed prefixes within the network. 5.1.3. Phase 0 - Foundation: Network Policy and Security Like many principles, network policy and security need to be considered for IPv6. It is possible that many of the IPv4 policies may transfer over to the IPv6 world, others may not be applicable. There is also a potential that new policies need to be made to deal with issues specifically related to IPv6. This document does not highlight these specific issues, but raises the awareness they are of consideration and should be addressed. 5.1.4. Phase 0 - Foundation: Transition Architecture The operator may want plan out their transition architecture in advance (with obvious room for flexibility) to help optimize how they will build out and scale their networks. If the operator should want to use multiple technologies like CGN/NAT444, DS-Lite and 6RD, they may want to plan out where such equipment may be located and potentially choose locations which can be used for all three roles. This would allow for the least disruption as the operator evolves the transition environment to meet the needs of the network. 5.2. Phase 1 - Tunnelled IPv6 During the initial phase of transition the operator may want to support IPv6 before native IPv6 services are possible on the access network. During this period of time, tunnelled access to IPv6 is likely a very viable and desirable option. Providers can deploy relays for automatic tunnelling technologies like 6to4 and Teredo, Kuarsingh Expires January 6, 2012 [Page 10] Internet-Draft Wireline Incremental IPv6 July 2011 and can more importantly deploy technologies like 6RD. It should be noted that technologies like 6to4 and Teredo do not share the same address selection behaviours as those like 6RD as per address selection [RFC3484]. The operator can deploy 6RD relays quite easily and scale them as needed to meet the early customer needs of IPv6. Since 6RD requires the upgrade or replacement of most CPEs, the operator may want ensure that the CPEs support not just 6RD but Native Dual Stack and other tunnelling technologies if possible. 6RD client side deployments are now available in the retail channel products and within the OEM market making it a viable option for a wide range of operations. Retail availability of 6RD is important since not all operators control or have influence over what is deployed in the consumer site. If the operator does not have the access network challenge of deploying Naive IPv6, they may want to skip this phase. However, the operator may still want to deploy 6to4 and/or Teredo relays to help the automatic tunnelling technology operation while Native IPv6 is deployed. This initial phase also provides the added benefit of allow the operational folks to deterministically know what the IPv6 prefix assignment is based on the IPv4 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 folks in an organization know what the IPv6 prefix is for 6RD based on to knowledge of the IPv4 address. 5.3. Phase 2: Native Dual Stack As a follow-up phase to "Tunnelled IPv6" or as an initial step, the operator may deploy Native IPv6 to the customer premise. This phase would then allow for both IPv6 and IPv4 to be natively access by the customer equipment. It is also possible that the second phase be enabled in pockets of the network while the access network is undergoing upgrades. As one of the most desirable options, Native Dual Stack should be sought as soon as possible if the operator's network allows. During this phase, the operator can confidently work with content providers and internal groups to move content to IPv6. Since there are no translation devices needed for this mode of operation, it allows both protocols (IPv6 and IPv4) to work efficiently within the network. Efficiency in this context refers to the need (or lack there of) to translate, incrementally route or relay customer traffic within the operator's network. Kuarsingh Expires January 6, 2012 [Page 11] Internet-Draft Wireline Incremental IPv6 July 2011 5.4. Intermediate Phase for CGN During the first two phases, acquiring more IPv4 addresses may become challenging, therefore CGN may be required. The CGN/NAT444 infrastructure can be enabled if needed during either phase. CGN/ NAT444 is less optimal in a 6RD deployment (if used with 6RD to a given endpoint) since all traffic must transverse some type of operator equipment. In the case of Native Dual Stack, CGN/NAT444 can be used to assist in extending connectivity for the IPv4 path. During this time, for endpoints subject to the CGN/NAT444 function, the Native IPv6 path is available for higher quality connectivity. It would be the expectation that the IPv6 path becomes better utilized by the customer over time by virtue of IPv6 support in the home network and within the content provider's realm. 5.5. Phase 3 - Tunnelled IPv4 Over time, the operator will mature IPv6 and have more ubiquitous coverage within the network. Once the operator is familiar with IPv6, tools have been developed and operational procedures refined, more efficient modes of connectivity can be enabled. Once such technology is DS-Lite. DS-Lite allows the operator to grow the IPv4 customer base if needed without the need to deploy more IPv4 addresses to customers. DS-Lite still requires IPv4 address sharing, but this is seen as no worse and often more advantageous then NAT444 and other address sharing options give a single NAT layer. The operator can also move endpoints (Dual Stack) to DS-Lite retroactively in an attempt to reclaim IPv4 addresses for redeployment. Redeployment of addressees may be desirable if IPv4 resources are needed for legacy equipment which cannot be upgraded to IPv4 and no new IPv4 addressees can be acquired otherwise. The operator may want to have already moved most external content and internal content to IPv6 before this phase implemented. By having a significant amount of traffic on IPv6, the operator would limit the amount of translation resources which are needed at the AFTR layer to support IPv4 flows. This would also be a benefit to the customer as their traffic need not be translated by a operator device improving performance. 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. This phase can also co-exist with Native Dual Stack if desired since the same basic foundation is needed for both technologies on the IPv6 side. DS-Lite however requires incremental functions in the network Kuarsingh Expires January 6, 2012 [Page 12] Internet-Draft Wireline Incremental IPv6 July 2011 such as the programming of the CPE and the implementation of the AFTRs'. 6. IANA Considerations No IANA considerations are defined at this time. 7. Security Considerations No Additional Security Considerations are made in this document. 8. Acknowledgements Thanks to the following people for their textual contributions and/or guidance on IPv6 deployment considerations: John Brzozowski, Lee Howard, Jason Weil, Nik Lavorato, John Cianfarani, and Chris Donley. 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-01 (work in progress), February 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., Chandrasekaran, A., and V. Ganti, "Assessing the Impact of NAT444 on Network Applications", draft-donley-nat444-impacts-01 (work in progress), October 2010. [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", draft-ietf-behave-lsn-requirements-01 (work in progress), March 2011. Kuarsingh Expires January 6, 2012 [Page 13] Internet-Draft Wireline Incremental IPv6 July 2011 [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-11 (work in progress), May 2011. [I-D.ietf-v6ops-6to4-advisory] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", draft-ietf-v6ops-6to4-advisory-02 (work in progress), June 2011. [I-D.jjmb-v6ops-comcast-ipv6-experiences] Brzozowski, J., "Comcast IPv6 Experiences", draft-jjmb-v6ops-comcast-ipv6-experiences-00 (work in progress), March 2011. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. Author's Address Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: victor.kuarsingh@rci.rogers.com URI: http://www.rogers.com Kuarsingh Expires January 6, 2012 [Page 14]