Network Working Group M. Lind Request for Comments: 4029 TeliaSonera Category: Informational V. Ksinant Thales Communications S. Park SAMSUNG Electronics A. Baudot France Telecom P. Savola CSC/Funet March 2005 Scenarios and Analysis for Introducing IPv6 into ISP Networks Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThis document describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated. Known challenges are also identified. 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Goal and Scope of the Document. . . . . . . . . . . . . 2 2. Brief Description of a Generic ISP Network. . . . . . . . . . 3 3. Transition Scenarios. . . . . . . . . . . . . . . . . . . . . 4 3.1. Identification of Stages and Scenarios. . . . . . . . . 4 3.2. Stages. . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Stage 1 Scenarios: Launch . . . . . . . . . . . 5 3.2.2. Stage 2a Scenarios: Backbone. . . . . . . . . . 6 3.2.3. Stage 2b Scenarios: Customer Connection . . . . 6 3.2.4. Stage 3 Scenarios: Complete . . . . . . . . . . 7 3.2.5. Stages 2a and 3: Combination Scenarios. . . . . 7 3.3. Transition Scenarios. . . . . . . . . . . . . . . . . . 7 3.4. Actions Needed When Deploying IPv6 in an ISP's Network. 8
4. Backbone Transition Actions . . . . . . . . . . . . . . . . . 9 4.1. Steps in the Transition of Backbone Networks. . . . . . 9 4.1.1. MPLS Backbone . . . . . . . . . . . . . . . . . 9 4.2. Configuration of Backbone Equipment . . . . . . . . . . 10 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. EGP . . . . . . . . . . . . . . . . . . . . . . 12 4.3.3. Transport of Routing Protocols. . . . . . . . . 12 4.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 13 5. Customer Connection Transition Actions. . . . . . . . . . . . 13 5.1. Steps in the Transition of Customer Connection Networks 13 5.1.1. Small End Sites . . . . . . . . . . . . . . . . 14 5.1.2. Large End Sites . . . . . . . . . . . . . . . . 15 5.2. User Authentication/Access Control Requirements . . . . 15 5.3. Configuration of Customer Equipment . . . . . . . . . . 16 5.4. Requirements for Traceability . . . . . . . . . . . . . 16 5.5. Ingress Filtering in the Customer Connection Network. . 17 5.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . 17 5.7. Quality of Service. . . . . . . . . . . . . . . . . . . 17 6. Network and Service Operation Actions . . . . . . . . . . . . 18 7. Future Stages . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Requirements for Follow-On Work . . . . . . . . . . . . . . . 19 9. Example Networks. . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 22 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. Informative References. . . . . . . . . . . . . . . . . . . . 24 Appendix A: Convexity Requirements in Single Topology IS-IS . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28
The document is focused on services that include both IPv6 and IPv4 and does not cover issues surrounding IPv6-only service. It is also outside the scope of this document to describe different types of access or network technologies. Figure 1.
------------ ---------- | Network and| | | | Service |--| Backbone | | Operation | | |\ ------------ ---------- \ / | \ \ / | \ \_Peering (Direct and / | \ exchange points) / | \ / | \ ---------- / ---------- \ ---------- | Customer | / | Customer | \ | Customer | |Connection|--/ |Connection| \--|Connection| | 1 | | 2 | | 3 | ---------- ---------- ---------- | | | ISP's Network ------------------------------------------------------- | | | Customers' Networks +--------+ +--------+ +--------+ | | | | | | |Customer| |Customer| |Customer| | | | | | | +--------+ +--------+ +--------+ Figure 1: ISP Network Topology
Each stage has different IPv6 properties. Therefore, based on its requirements, an ISP can decide which set of stages it will follow and in what order to transform its network. This document is not aimed at covering small ISPs, hosting providers, or data centers; only the scenarios applicable to ISPs eligible for at least a /32 IPv6 prefix allocation from an RIR are covered. Section 2. Combinations of different building blocks that constitute an ISP's environment lead to a number of scenarios from which the ISP can choose. The scenarios most relevant to this document are those that maximize an ISP's ability to offer IPv6 to its customers in the most efficient and feasible way. The assumption in all stages is that the ISP's goal is to offer both IPv4 and IPv6 to the customer. The four most probable stages are as follows: o Stage 1 Launch o Stage 2a Backbone o Stage 2b Customer connection o Stage 3 Complete Generally, an ISP is able to upgrade a current IPv4 network to an IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can also be implemented at a small cost by adding simple tunnel mechanisms to the existing configuration. When a new network is designed, Stage 3 might be the first or last step because there are no legacy concerns. Nevertheless, the absence of IPv6 capability in the network equipment can still be a limiting factor. Note that in every stage except Stage 1, the ISP can offer both IPv4 and IPv6 services to its customers.
The ISP will also need to establish IPv6 connectivity to its upstream providers and peers; it is of utmost importance to require IPv6 transit when negotiating IP transit deals with the upstream ISPs. If the upstream is not providing IPv6 connectivity at the moment, it may be possible to obtain temporary connectivity from a nearby ISP, possibly using a short configured tunnel. However, the longer-term goal must be to require and to obtain IPv6 connectivity from the transit ISPs, because otherwise the quality of IPv6 connectivity will likely be poor. Connectivity to peers can typically be established either directly or at Internet Exchange Points (IX). Most IXs use techniques where IPv6 is easy to use, and many IXs already provide infrastructure for IPv6 peerings. Such peerings can be done natively by using IPv6. Peerings over IPv6-in-IPv4 tunnels is also possible but not recommended, at least in the long term. Direct connectivity to peers may be feasible when there is direct connectivity to the peer for IPv4.
Normally, the ISP will continue to provide IPv4 connectivity by using private (NATted by the ISP) or public IPv4 address. In many cases, the customer also has a NAT of his/her own; if so, this likely continues to be used for IPv4 connectivity.
to remove non-IPv6-capable hardware from the network may be significant.
Sections 4, 5, and 6 contain detailed descriptions of each action. Tunnels Tunnels Dual Full IPv4-only ----> or ---> or + Stack --> Dual Stack dedicated IPv6 dedicated IPv6 routers links links Figure 2: Transition Path The first step involves tunnels or dedicated links but leaves existing routers unchanged. Only a small set of routers then have IPv6 capabilities. The use of configured tunnels is adequate during this step. In the second step, some dual-stack routers are added, progressively, to this network. The final step is reached when all or almost all routers are dual-stack. For many reasons (technical, financial, etc.), the ISP may progress step by step or jump directly to the final one. One important criterion in planning this evolution is the number of IPv6 customers the ISP expects during its initial deployments. If few customers connect to the original IPv6 infrastructure, then the ISP is likely to remain in the initial steps for a long time. In short, each intermediate step is possible, but none is mandatory.
network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might require upgrade/change in the MPLS core network. An alternative approach is to use BGP for signaling or to perform; for example, IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some possibilities are preferable to others, depending on the specific environment under consideration. The approaches seem to be as follows: 1) Require that MPLS networks deploy native IPv6 routing and forwarding support. 2) Require that MPLS networks support native routing and setting up of IPv6 LSPs, used for IPv6 connectivity. 3) Use only configured tunneling over IPv4 LSPs. 4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation for IPv6 connectivity. Approaches 1) and 2) are clearly the best target approaches. However, approach 1) may not be possible if the ISP is not willing to add IPv6 support in the network, or if the installed equipment is not capable of high performance native IPv6 forwarding. Approach 2) may not be possible if the ISP is unwilling or unable to add IPv6 LSP set-up support in the MPLS control plane. Approach 4) can be used as an interim mechanism when other options are unfeasible or undesirable for the reasons discussed above. Approach 3) is roughly equivalent to approach 4) except that it does not require additional mechanisms but may lack scalability in the larger networks, especially if IPv6 is widely deployed.
Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is not usually used in service provider networks, as OSPF and IS-IS are superior IGPs. BGP is the only IPv4 EGP. Static routes also are used in both cases. Note that it is possible to configure a given network so that it has an IPv6 topology different from its IPv4 topology. For example, some links or interfaces may be dedicated to IPv4-only or IPv6-only traffic, or some routers may be dual-stack whereas others may be IPv4- or IPv6-only. In this case, routing protocols must be able to understand and cope with multiple topologies. MTISIS] have been implemented (using IS-IS for only IPv4 or only IPv6 requires no convexity). In simpler networks or with careful planning of IS-IS link costs, it is possible to keep even incongruent IPv4/IPv6 topologies "convex". The convexity problem is explained in more detail with an example in Appendix A.
When deploying full dual-stack in the short-term, using single- topology IS-IS is recommended. This may be particularly applicable for some larger ISPs. In other scenarios, choosing between one or two separate processes often depends on the perceived risk to the IPv4 routing infrastructure, i.e., whether one wishes to keep them separate for the time being. If this is not a factor, using a single process is usually preferable for operational reasons: not having to manage two protocols and topologies. The IGP is typically only used to carry loopback and point-to-point addresses and doesn't include customer prefixes or external routes. Internal BGP (iBGP), as described in the next section, is most often deployed in all routers (PE and core) to distribute routing information about customer prefixes and external routes. Some of the simplest devices (e.g., CPE routers) may not implement routing protocols other than RIPng. In some cases, therefore, it may be necessary to run RIPng in addition to one of the above IGPs, at least in a limited fashion, and then, by some mechanism, to redistribute routing information between the routing protocols. RFC2858] can be used for IPv6 [RFC2545]. These extensions enable the exchange of IPv6 routing information and the establishment of BGP sessions using TCP over IPv6. It is possible to use a single BGP session to advertise both IPv4 and IPv6 prefixes between two peers. However, the most common practice today is to use separate BGP sessions.
EMBEDRP]. RFC3056], Teredo [TEREDO], and so on. Some of these are based on a specific addressing plan independent of the ISP's allocated prefix(es), while others use a part of the ISP's prefix. In most cases, using the ISP's address space is preferable. A key factor is the presence or absence of NATs between the two tunnel end-points. In most cases, 6to4 and ISATAP are incompatible with NATs, and UDP encapsulation for configured tunnels has not been specified.
Dynamic and non-permanent IPv4 address allocation is another factor a tunneling technique may have to deal with. In this case, the tunneling techniques may be more difficult to deploy at the ISP's end, especially if a protocol including authentication (like PPP for IPv6) is not used. This may need to be considered in more detail. However, NAT traversal can be avoided if the NAT supports forwarding protocol-41 [PROTO41] and is configured to do so. Firewalls in the path can also break tunnels of these types. The administrator of the firewall needs to create a hole for the tunnel. This is usually manageable, as long as the firewall is controlled by either the customer or the ISP, which is almost always the case. When the CPE is performing NAT or firewall functions, terminating the tunnels directly at the CPE typically simplifies the scenario considerably, avoiding the NAT and firewall traversal. If such an approach is adopted, the CPE has to support the tunneling mechanism used, or be upgraded to do so. UNMANEVA]. These identify solutions relevant to the first category of unmanaged networks. The tunneling requirements applicable in these scenarios are described in [TUNREQS]. The connectivity mechanisms can be categorized as "managed" or "opportunistic". The former consist of native service or a configured tunnel (with or without a tunnel broker); the latter include 6to4 and, e.g., Teredo -- they provide "short-cuts" between nodes using the same mechanisms and are available without contracts with the ISP. The ISP may offer opportunistic services, mainly a 6to4 relay, especially as a test when no actual service is offered yet. At the later phases, ISPs might also deploy 6to4 relays and Teredo servers (or similar) to optimize their customers' connectivity to 6to4 and Teredo nodes. Opportunistic services are typically based on techniques that don't use IPv6 addresses from the ISP's allocated prefix(es), and the services have very limited functions to control the origin and the number of customers connected to a given relay. Most interesting are the managed services. When dual-stack is not an option, a form of tunneling must be used. When configured tunneling is not an option (e.g., due to dynamic IPv4 addressing), some form of
automation has to be used. Basically, the options are either to deploy an L2TP architecture (whereby the customers would run L2TP clients and PPP over it to initiate IPv6 sessions) or to deploy a tunnel configuration service. The prime candidates for tunnel configuration are STEP [STEP] and TSP [TSP], which both also work in the presence of NATs. Neither is analyzed further in this document.
When a provider does not wish to give its IPv4 customers automatic access to IPv6 services, specific IPv6 access control must be performed parallel with the IPv4 access control. This does not imply that different user authentication must be performed for IPv6, but merely that the authentication process may lead to different results for IPv4 and IPv6 access. Access control traffic may use IPv4 or IPv6 transport. For instance, RADIUS [RFC2865] traffic related to IPv6 service can be transported over IPv4. DUAL-ACCESS]. Note that when the customer connection network is shared between the users or the ISPs and is not just a point-to-point link, authenticating the configuration of the parameters (especially prefix delegation) requires further study. As long as IPv4 service is available alongside IPv6, it is not required to auto configure IPv6 parameters in the CPE, except the prefix, because the IPv4 settings may be used.
certain customer, or that records must be maintained of which customer had which address or prefix. This also applies to the customers with tunneled connectivity. This can be done, for example, by mapping a DHCP response to a physical connection and storing the result in a database. It can also be done by assigning a static address or prefix to the customer. A tunnel server could also provide this mapping. RFC3704]. RFC3582]. Mechanisms for multihoming to more than one ISP are still under discussion. One working model would deploy at least one prefix per ISP and choose the prefix from the ISP to which traffic is sent. In addition, tunnels may be used for robustness [RFC3178]. Currently, there are no provider-independent addresses for end-sites. Such addresses would enable IPv4-style multihoming, with associated disadvantages. Multi-connecting more than once to one ISP is a simple practice, and this can be done, for example, by using BGP with public or private AS numbers and a prefix assigned to the customer.
IntServ and DiffServ are equally applicable to IPv6 and IPv4 and work similarly regardless of IP version. Of the two, typically only DiffServ has been implemented. Many bandwidth provisioning systems operate with IPv4 assumptions, e.g., taking an IPv4 address or (set of) prefixes for which traffic is reserved or preferred. These systems require special attention when introducing IPv6 support in the networks.
left for a subsequent document. Note that there are some services which will need to maintain IPv4 connectivity (e.g., authorative and some recursive DNS servers [DNSGUIDE]). TUNREQS]. - An IPv6 site multihoming mechanism (or multiple ones) needs to be developed. Work items which were already fast in progress, as of this writing, are as follows: - 6PE for MPLS was identified as a required mechanism, and this is already in progress [BGPTUNNEL]. - IS-IS for Multiple Topologies was noted as a helpful mechanism in certain environments; however, it is possible to use alternative methods to achieve the same end, so specifying this is not strictly required.
The routers in the sample network layout are interconnected with each other and with another ISP. The connection to another ISP can be either direct or through an exchange point. A number of customer connection networks are also connected to the routers. Customer connection networks can be, for example, xDSL or cable network equipment. ISP1 | ISP2 +------+ | +------+ | | | | | |Router|--|--|Router| | | | | | +------+ | +------+ / \ +----------------------- / \ / \ +------+ +------+ | | | | |Router|----|Router| | | | | +------+ +------+\ | | \ | Exchange point +------+ +------+ \ +------+ | +------+ | | | | \_| | | | |-- |Router|----|Router|----\|Router|--|--|Switch|-- | | | | | | | | |-- +------+ /+------+ +------+ | +------+ | / | | +-------+/ +-------+ | | | | | |Access1| |Access2| | | | | +-------+ +-------+ ||||| ||||| ISP Network ----|-----------|---------------------- | | Customer Networks +--------+ +--------+ | | | | |Customer| |Customer| | | | | +--------+ +--------+ Figure 3: ISP Sample Network Layout
only, xDSL equipment does not require changes in CPE: IPv6 connectivity can be offered to the customers by upgrading the PE router to IPv6. In the initial phase, only Router Advertisements are used; DHCPv6 Prefix Delegation can be added as the next step if no other mechanisms are available. The FTTB/H access has to be upgraded to support access control and traceability in the switches, probably by using DHCP snooping or a similar IPv6 capability, but it also has to be compatible with prefix delegation, not just address assignment. This could, however, lead to the necessity to use DHCPv6 for address assignment. BGPTUNNEL], as this will allow large-scale IPv6 support without hardware or software upgrades in the core. In a later phase, native IPv6 traffic or IPv6 LSPs would be used in the whole network. In this case, IS-IS or OSPF could be used for the internal routing, and a separate IPv6 BGP session would be run. For the fixed-line customers, the CPE has to be upgraded, and prefix delegation using DHCPv6 or static assignment would be used. An IPv6 MBGP session would be used when routing information has to be exchanged. In the xDSL case, the same conditions for IP-tunneling apply as in Example 1. In addition to IP-tunneling, a PPP session can be used to offer IPv6 access to a limited number of customers. Later, when clients and servers have been updated, the IPv6 PPP session can be replaced with a combined PPP session for both IPv4 and IPv6. PPP has to be used for address and prefix assignment.
V6SEC]. o The more complex the transition mechanisms employed become, the more difficult it will be to manage or analyze their impact on security. Consequently, simple mechanisms are preferable. o This document has identified a number of requirements for analysis or further work that should be explicitly considered when adopting IPv6: how to perform access control over shared media or shared ISP customer connection media, how to manage the configuration management security on such environments
(e.g., DHCPv6 authentication keying), and how to manage customer traceability if stateless address autoconfiguration is used. [EMBEDRP] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", Work in Progress. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. [RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le Faucheur, F., "Connecting IPv6 Islands across IPv4 Clouds with BGP", Work in Progress. [DUAL-ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., Takenouchi, A., "A Model of IPv6/IPv4 Dual Stack Internet Access Service", Work in Progress. [STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP)", Work in Progress. [TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup Protocol (TSP)", Work in Progress. [TUNREQS] Palet, J., Nielsen, K., Parent, F., Durand, A., Suryanarayanan, R., and P. Savola, "Goals for Tunneling Configuration", Work in Progress, February 2005. [UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol, R., "Evaluation of Transition Mechanisms for Unmanaged Networks", Work in Progress. [PROTO41] Palet, J., Olvera, C., Fernandez, D., "Forwarding Protocol 41 in NAT Boxes", Work in Progress. [V6SEC] Savola, P., "IPv6 Transition/Co-existence Security Considerations", Work in Progress. [DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational guidelines", Work in Progress. [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", Work in Progress.
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.