RFC 4029
Scenarios and Analysis for Introducing IPv6 into ISP Networks
RFC 4029: Scenarios and Analysis for Introducing IPv6 into ISP Networks 🎀✨
okay bestie, this one is all about how an ISP can add IPv6 to its existing IPv4 network without breaking anything people already use 💅 it's giving careful planning, no chaos!
The document is from March 2005 and sits in the Network Working Group 🌸 it was written by M. Lind (TeliaSonera), V. Ksinant (Thales Communications), S. Park (SAMSUNG Electronics), A. Baudot (France Telecom), and P. Savola (CSC/Funet). It's Informational, so it's giving advice and analysis, not a standard 🧚 it doesn't obsolete or update anything (nothing is listed in its header).
Status of This Memo ✨
this memo is just here to inform the Internet community 💜 it doesn't specify an Internet standard of any kind, and it can be shared as much as you want.
Copyright Notice 🌈
Copyright (C) The Internet Society (2005).
Abstract 🦋
so the whole point is different ways an ISP can bring in IPv6 while its IPv4 service keeps running smoothly 😭 the doc looks at scenarios, checks out which transition mechanisms that already exist are actually relevant, and calls out the known challenges too. honest and iconic 👑
Table of Contents 🍓
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. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 281. Introduction 🌷
1.1. Goal and Scope of the Document 💖
okay so when an ISP rolls out IPv6, the goal is to give its customers IPv6 connectivity and global address space 🌍 the new IPv6 service has to be added on top of the existing IPv4 service, and bringing in IPv6 must not interrupt that IPv4 service. no drama allowed 🙅♀️
an ISP that already offers IPv4 has a bunch of ways to add IPv6 to it ✨ this document talks through a small set of scenarios for putting IPv6 into an ISP's IPv4 network. it checks how relevant the existing transition mechanisms are in these deployment scenarios, and it points out where those methods are missing essential functionality 🧐
the document focuses on services that include both IPv6 and IPv4. it does not cover issues around IPv6-only service, and it's also out of scope to describe the different types of access or network technologies 🙅
2. Brief Description of a Generic ISP Network 🗺️
so a generic ISP network can be split into two main parts: the backbone network and the customer connection networks 🦋 on top of that there are building blocks like network and service operations. here's what the extra building blocks mean for this doc:
CPE: Customer Premises EquipmentPE: Provider Edge EquipmentNetwork and service operation: the part of the ISP's network that hosts the services needed for the ISP's network to run properly. these usually include management, supervision, accounting, billing, and customer management applications 💼Customer connection: the part of the network a customer uses when connecting to an ISP's network. it includes the CPE, the last hop link, and the parts of the PE that interface with the last hop link 🔌Backbone: the rest of the ISP's network infrastructure 🌐 it includes the parts of the PE that interface with the core, the ISP's core routers, and the border routers used to exchange routing information with other ISPs (or other administrative entities) 🛣️Dual-stack network: a network that natively supports both IPv4 and IPv6 🌈
in some cases (like incumbent national or regional operators), a given customer connection network may have to be shared between or among different ISPs 🤝 depending on the type of customer connection network (for example, one with only layer 2 devices, or one involving non-IP technology), this constraint may bring up architectural considerations that matter for this document 🧠
the basic components of the ISP's network are shown in 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 Topology3. Transition Scenarios 🦄
3.1. Identification of Stages and Scenarios 🔍
this section covers the different stages an ISP might think about when it brings IPv6 connectivity into its existing IPv4 network, plus what might happen in each stage 📅
the stages are like snapshots of the ISP's network when it comes to IPv6 maturity 📸 since the ISP's network keeps evolving, a stage tells you how far along the ISP is in building the functionality it needs to offer IPv6 to its customers 💪
a transition can happen freely between different stages 🌊 a network segment can only be in one stage at a time, but the ISP's network as a whole can be spread across different stages. there are different transition paths from the first stage to the final one 🛤️ and the move from one stage to another doesn't have to be instant; it can happen gradually 🐢
every stage has different IPv6 properties, so based on its requirements, an ISP can decide which set of stages it wants to follow and in what order to change its network 🧩
this document isn't aimed at small ISPs, hosting providers, or data centers 🙅 it only covers the scenarios that apply to ISPs eligible for at least a /32 IPv6 prefix allocation from an RIR 💅
3.2. Stages 🎢
the stages come from the generic description of an ISP's network in Section 2 💫 different combinations of the building blocks that make up an ISP's environment lead to a bunch of scenarios the ISP can pick from. the scenarios most relevant to this document are the ones that maximize an ISP's ability to offer IPv6 to its customers in the most efficient and feasible way 🏆 in every stage, the assumption is that the ISP's goal is to offer both IPv4 and IPv6 to the customer 🫶
the four most probable stages are:
- Stage 1 Launch 🚀
- Stage 2a Backbone 🦴
- Stage 2b Customer connection 🔗
- Stage 3 Complete 🌟
generally, an ISP can upgrade its current IPv4 network to an IPv4/IPv6 dual-stack network through Stage 2b 💖 but IPv6 can also be set up for a small cost by adding simple tunnel mechanisms to the existing configuration 🎀 when a brand new network is designed, Stage 3 might be the first or the last step, because there are no legacy concerns 🧁 still, the lack of IPv6 capability in the network equipment can definitely still be a limiting factor 😬
and just so you know: in every stage except Stage 1, the ISP can offer both IPv4 and IPv6 services to its customers 🌈✨
3.2.1. Stage 1 Scenarios: Launch 🚀
Okay so Stage 1 is an IPv4-only ISP with an IPv4 customer 🌸. This is the most common setup right now, so it's the natural starting point for bringing in IPv6 ✨. From here, the ISP can transition from Stage 1 to any other stage, all with the goal of offering IPv6 to its customer 💖.
The very first step is getting a prefix allocation (typically a /32) from the appropriate RIR (AfriNIC, APNIC, ARIN, LACNIC, RIPE), following their allocation procedures 📋.
The ISP also needs IPv6 connectivity to its upstream providers and peers. It is of utmost importance to require IPv6 transit when negotiating IP transit deals with upstream ISPs 🔥. If the upstream isn't providing IPv6 yet, temporary connectivity might be possible from a nearby ISP, maybe over a short configured tunnel 🧚. BUT the longer-term goal has to be requiring and getting IPv6 connectivity from the transit ISPs, because otherwise the quality of IPv6 connectivity will likely be poor 💀.
Peering can usually happen directly or at Internet Exchange Points (IX) 🦋. Most IXs make IPv6 easy to use, and many already have infrastructure for IPv6 peerings. Those peerings can be done natively over IPv6. Peerings over IPv6-in-IPv4 tunnels are also possible, but they're not recommended, at least in the long term 🙈. Direct connectivity to peers may be feasible when there's direct IPv4 connectivity to that peer.
3.2.2. Stage 2a Scenarios: Backbone 🦴
Stage 2a is the ISP with IPv4-only customer connection networks but a backbone that supports both IPv4 and IPv6 💜. The ISP can make its backbone IPv6-capable through software upgrades, hardware upgrades, or a mix of both ✨.
Since the customer connections haven't been upgraded yet, a tunneling mechanism has to be used to provide IPv6 connectivity through the IPv4 customer connection networks 🎀. The customer can terminate the tunnel at the CPE (if it has IPv6 support) or at some set of devices inside its network. So either the CPE or a device inside the network could provide global IPv6 connectivity to the rest of the devices in the customer's network 👑.
3.2.3. Stage 2b Scenarios: Customer Connection 🌈
Stage 2b is an ISP with an IPv4 backbone network and a customer connection network that supports both IPv4 and IPv6 💅. Because the service to the customer is native IPv6, the customer is not required to support both IPv4 and IPv6. This is the biggest difference from the previous stage 😭. The need to exchange IPv6 traffic still exists, but it might be more complicated than in the previous case because the backbone isn't IPv6-enabled 🙃.
After completing Stage 2b, the original IPv4 backbone is unchanged. So the IPv6 traffic is carried either by tunneling over the existing IPv4 backbone, or in an IPv6 overlay network that's more or less separated from the IPv4 backbone 🧁.
Normally, the ISP keeps providing IPv4 connectivity using either private (NATted by the ISP) or public IPv4 addresses. In lots of cases the customer also has a NAT of their own. If so, that NAT likely keeps being used for IPv4 connectivity 🌸.
3.2.4. Stage 3 Scenarios: Complete 🏁
Stage 3 could be considered the final step in introducing IPv6, at least within the scope of this document 👑. This stage is ubiquitous IPv6 service, with native support for IPv6 and IPv4 in both the backbone and the customer connection networks ✨. From the customer's perspective it's identical to the previous stage, because the customer connection network hasn't changed. The requirement for exchanging IPv6 traffic is identical to that of Stage 2 🫶.
3.2.5. Stages 2a and 3: Combination Scenarios 🧩
Some ISPs may use different access technologies with varying levels of IPv6 maturity 🦋. This can lead to a combination of Stages 2a and 3: some customer connections don't support IPv6, but others do. In both cases the backbone is dual-stack 💖.
This scenario is equivalent to Stage 2a, but it requires support for native IPv6 customer connections on some access technologies 🔥.
3.3. Transition Scenarios 🦋
Given all those different stages, it's clear that an ISP has to be able to move from one stage to another 🌈. The initial stage in this document is an IPv4-only service and network, and the end stage is a dual IPv4/IPv6 service and network 💜.
The transition starts with an IPv4 ISP and then moves in one of three directions, and that choice is what sets apart the different transition scenarios 🧚. Stage 2a means upgrading the backbone first. Stage 2b means upgrading the customer connection network. And Stage 3 means introducing IPv6 in both the backbone and the customer connections, as needed 💅.
Here's the thing: most ISP backbone IPv4 networks are constantly evolving (firmware replacements in routers, new routers, etc.) 🛠️. That means they can be made ready for IPv6 without additional investment, except for staff training 💸. This path may be slower, but it's still useful, because it allows IPv6 to be introduced without any actual customer demand 🌸. It may even be superior to doing everything at the last minute, which can end up entailing a higher investment 😬.
However, it's important to consider (and to request from vendors) IPv6 features in all new equipment from the outset 🔥. Otherwise, the time and effort needed to remove non-IPv6-capable hardware from the network may be significant 💀.
3.4. Actions Needed When Deploying IPv6 in an ISP's Network 🛠️
Looking at the transitions above, it's possible to split the work for each transition into a small set of actions ✨. Each action is largely independent of the others, and some actions may be shared by multiple transitions 🫶.
Here's the little list of actions, bestie 📋:
- Actions required for backbone transition:
- Connect dual-stack customer connection networks to other IPv6 networks through an IPv4 backbone.
- Transform an IPv4 backbone into a dual-stack one. This action can be performed directly or through intermediate steps.
- Actions required for customer connection transition:
- Connect IPv6 customers to an IPv6 backbone through an IPv4 network.
- Transform an IPv4 customer connection network into a dual-stack one.
- Actions required for network and service operation transition:
- Set up IPv6 connectivity to upstream providers and peers.
- Configure IPv6 functions into network components.
- Upgrade regular network management and monitoring applications to take IPv6 into account.
- Extend customer management (e.g., RADIUS) mechanisms to be able to supply IPv6 prefixes and other information to customers.
- Enhance accounting, billing, and so on to work with IPv6 as needed. (Note: If dual-stack service is offered, this may not be necessary.)
- Implement security for network and service operation.
Sections 4, 5, and 6 go into detail on each action 📖.
4. Backbone Transition Actions 🦴
4.1. Steps in the Transition of Backbone Networks
Okay so in terms of physical equipment, backbone networks are mostly high-speed core and edge routers 🖥️. Border routers handle peering with other providers, and filtering, routing policy, and policing functions are generally managed on the border routers 🚧.
In the beginning, an ISP has an IPv4-only backbone. In the end, the backbone is completely dual-stack 🌈. In between, intermediate steps may be identified:
Tunnels Tunnels Dual Full
IPv4-only ----> or ---> or + Stack --> Dual Stack
dedicated IPv6 dedicated IPv6 routers
links links
Figure 2: Transition PathThe first step involves tunnels or dedicated links but leaves the existing routers unchanged. So only a small set of routers has IPv6 capabilities at this point. Configured tunnels are adequate during this step 🧚.
In the second step, some dual-stack routers are added, progressively, to the network 🦋.
The final step is reached when all or almost all routers are dual-stack 👑.
For lots of reasons (technical, financial, etc.), the ISP may progress step by step or jump straight to the final one 💅. One important factor in planning this evolution is the number of IPv6 customers the ISP expects during its initial deployments. If only a few customers connect to the original IPv6 infrastructure, the ISP is likely to stay in the initial steps for a long time 🙈.
In short, each intermediate step is possible, but none is mandatory ✨.
4.1.1. MPLS Backbone 🏷️
If MPLS is already deployed in the backbone, it may be desirable to provide IPv6-over-MPLS connectivity 💜. However, setting up an IPv6 Label Switched Path (LSP) requires signaling through the MPLS network. Both LDP and RSVP-TE can set up IPv6 LSPs, but this might require an upgrade or 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 look like this 🧩:
- Require that MPLS networks deploy native IPv6 routing and forwarding support.
- Require that MPLS networks support native routing and setting up of IPv6 LSPs, used for IPv6 connectivity.
- Use only configured tunneling over IPv4 LSPs.
- 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 isn't willing to add IPv6 support to the network, or if the installed equipment isn't 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 to the MPLS control plane 🙃.
Approach 4 can be used as an interim mechanism when the other options are unfeasible or undesirable for the reasons discussed above ⏳.
Approach 3 is roughly equivalent to approach 4, except that it doesn't need additional mechanisms. It may lack scalability in larger networks, though, especially if IPv6 is widely deployed 📉.
4.2. Configuration of Backbone Equipment ⚙️
In the backbone, the number of devices is small, so IPv6 configuration mainly deals with routing protocol parameters, interface addresses, loop-back addresses, access control lists, and so on 🧁.
These IPv6 parameters need to be configured manually 🫶.
4.3. Routing 🗺️✨
okay so ISPs need routing protocols to advertise reachability and to find the shortest working paths, both internally and externally 💅
Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is not usually used in service provider networks, bc OSPF and IS-IS are superior IGPs 🙄 BGP is the only IPv4 EGP. Static routes also get used in both cases 🧚
ngl this part is lowkey important: it's possible to set up a network so the IPv6 topology is different from the IPv4 topology 🦋 For example, some links or interfaces might be dedicated to IPv4-only or IPv6-only traffic, or some routers might be dual-stack while others are IPv4-only or IPv6-only. In this case, routing protocols must be able to understand and cope with multiple topologies 🔥
4.3.1. IGP 🌸
Once the IPv6 topology has been figured out, you have to pick the IPv6 IGP: either OSPFv3 or IS-IS for IPv6. RIPng is not appropriate in most contexts, because RIPv2 isn't appropriate for IPv4 either, so it's not discussed here 🙈 The IGP typically includes the routers' point-to-point and loop-back addresses.
The most important decision is whether you want separate routing protocol processes for IPv4 and IPv6. Separating them takes more memory and CPU for route calculations, e.g., when the links flap 😭 But separation gives you a measure of assurance that if problems come up with IPv6 routing, they won't affect the IPv4 routing protocol 🫶 In the early phases, if it's uncertain whether joint IPv4-IPv6 networking is working as intended, running separate processes may be desirable and easier to manage 💜
The possible combinations are as follows:
- With separate processes:
- OSPFv2 for IPv4, IS-IS for IPv6 (only)
- OSPFv2 for IPv4, OSPFv3 for IPv6, or
- IS-IS for IPv4, OSPFv3 for IPv6
- With the same process:
- IS-IS for both IPv4 and IPv6
⚠️ Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6 topologies must be "convex", unless the multiple-topology IS-IS extensions [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's 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 especially 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 you want to keep them separate for the time being. If that's not a factor, using a single process is usually preferable for operational reasons: you don't have to manage two protocols and topologies 🎀
The IGP is typically only used to carry loopback and point-to-point addresses, and it 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 🥺 So in some cases, 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, redistribute routing information between the routing protocols. Main character problems, honestly 💀
4.3.2. EGP 💜
BGP is used for both internal and external BGP sessions 🌐
BGP with multiprotocol extensions [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's 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 🙌
4.3.3. Transport of Routing Protocols 🚚
IPv4 routing information should be carried by IPv4 transport and, similarly, IPv6 routing information by IPv6, for several reasons:
- IPv6 connectivity may work when IPv4 connectivity is down (or vice-versa) 🫠
- The best route for IPv4 is not always the best one for IPv6 👀
- The IPv4 and IPv6 logical topologies may be different, because the administrator may want to assign different metrics to a physical link for load balancing, or because tunnels may be in use 🦋
4.4. Multicast 📡
Currently, IPv6 multicast isn't a major concern for most ISPs. However, some of them are considering deploying it 👀 Multicast is achieved by using the PIM-SM and PIM-SSM protocols. These also work with IPv6 ✨
Information about multicast sources is exchanged using MSDP in IPv4, but MSDP is intentionally not defined for IPv6 🙅♀️ Instead, one should use only PIM-SSM or an alternative mechanism for conveying the information [EMBEDRP].
5. Customer Connection Transition Actions 🎀
5.1. Steps in the Transition of Customer Connection Networks 🛠️
Customer connection networks are generally made up of a small set of PEs connected to a large set of CPEs, and they may be based on different technologies depending on the customer type or size, as well as the required bandwidth or even quality of service 💅 Small unmanaged connection networks used for public customers usually rely on different technologies (e.g., dial-up or DSL) than the ones used for large customers, which typically run managed networks. Transitioning these infrastructures to IPv6 can be done in several steps, but some ISPs, depending on their perception of the risks, may skip some of the steps 🫶
Connecting IPv6 customers to an IPv6 backbone through an IPv4 network can be considered a first careful step an ISP takes to provide IPv6 services to its IPv4 customers 🐣 Some ISPs may also choose to provide IPv6 service independently from the regular IPv4 service 🌸
In any case, IPv6 service can be provided using tunneling techniques 🚇 The tunnel may terminate at the CPE corresponding to the IPv4 service, or in some other part of the customer's infrastructure (for instance, on IPv6-specific CPE or even on a host) 🧚
Several tunneling techniques have already been defined: configured tunnels with tunnel broker, 6to4 [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 whether or not there are 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 harder 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 a lot, avoiding the NAT and firewall traversal 🥰 If that approach is adopted, the CPE has to support the tunneling mechanism used, or be upgraded to do so ⭐
5.1.1. Small End Sites 🏡
Tunneling considerations for small end sites are discussed in [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 they're 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 🧪 In 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 😬
Honestly the most interesting ones 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 🫶
5.1.2. Large End Sites 🏢
Large end sites usually have a managed network 👑
Dual-stack access service is often a possibility, as the customer network is managed (although CPE upgrades may be necessary) 💖
Configured tunnels, as-is, are a good solution when a NAT is not in the way and the IPv4 end-point addresses are static. In this scenario, NAT traversal is not typically required. If fine-grained access control is needed, an authentication protocol needs to be implemented 🔐
Tunnel brokering solutions have been proposed to help facilitate the set-up of a bi-directional tunnel. Such mechanisms are typically unnecessary for large end-sites, as simple configured tunneling or native access can be used instead. However, if such mechanisms would already be deployed, large sites starting to deploy IPv6 might benefit from them in any case 🤝
Teredo is not applicable in this scenario, as it can only provide IPv6 connectivity to a single host, not the whole site 🙅♀️ 6to4 is not recommended, due to its reliance on relays and provider-independent address space, which makes it impossible to guarantee the service quality and manageability that large sites typically want 😭🌈
5.2. User Authentication/Access Control Requirements ✨
okay so user authentication can be used to decide who gets to use the IPv6 connectivity service in the first place, or who can reach specific IPv6 services (like NNTP servers that are only for customers 🧚). the first one gets more detail below. for the second one, the trick is making sure that for every service-specific IPv4 access list, there's a matching IPv6 access list too 💅
IPv6-specific user authentication isn't always needed 🫶 for example, if a customer of the IPv4 service automatically gets access to the IPv6 service, then the IPv4 access control already covers the IPv6 services too. no extra work, iykyk 💖
when a provider does not want its IPv4 customers to get automatic access to IPv6 services, then specific IPv6 access control must be performed in parallel with the IPv4 access control. this doesn't mean you have to run a different user authentication for IPv6. it just means the authentication process may give different results for IPv4 and IPv6 access 🦋
access control traffic can use IPv4 or IPv6 transport 🌸 for instance, RADIUS [RFC2865] traffic related to the IPv6 service can be carried over IPv4.
5.3. Configuration of Customer Equipment 🎀
the customer connection networks are made up of PEs and CPE(s) 🌈 usually each PE connects multiple CPE components to the backbone network infrastructure. this number can reach tens of thousands of customers, or even more 😭 configuring CPE is hard for the ISP, and it's even harder when it has to be done remotely. so auto-configuration mechanisms are a huge help here, even though manual configuration is still an option 🍓
the parameters that usually need to be handed to customers automatically are:
- The network prefix delegated by the ISP
- The address of the Domain Name System server (DNS)
- Possibly other parameters (e.g., the address of an NTP server)
when user identification is required on the ISP's network, DHCPv6 may be used to provide configurations. otherwise, either DHCPv6 or a stateless mechanism may be used 💜 this is talked about in more detail in [DUAL-ACCESS].
note that when the customer connection network is shared between users or 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, the CPE doesn't need to auto-configure IPv6 parameters, except for the prefix, because the IPv4 settings can be used instead ✨
5.4. Requirements for Traceability 🔍
most ISPs have some kind of mechanism to trace where traffic came from in their networks 💅 this has to work for IPv6 traffic too. that means a specific IPv6 address or prefix has to be tied to a certain customer, or records have to be kept about which customer had which address or prefix. this also applies to customers with tunneled connectivity 🦋
for example, this can be done 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 🌷
5.5. Ingress Filtering in the Customer Connection Network 🛡️
ingress filtering must be deployed toward the customers, everywhere 🔥 this is for traceability, to prevent DoS attacks using spoofed addresses, to prevent illegitimate access to the management infrastructure, and so on 💀
ingress filtering can be done, for example, by using access lists or Unicast Reverse Path Forwarding (uRPF). the mechanisms for these are described in [RFC3704] 🧠
5.6. Multihoming 🌐
customers may want multihoming or multi-connecting for a bunch of reasons [RFC3582] 🍓
mechanisms for multihoming to more than one ISP are still being discussed 🙈 one working model would deploy at least one prefix per ISP and choose the prefix from the ISP that traffic is sent to. on top of that, tunnels may be used for robustness [RFC3178]. right now, there are no provider-independent addresses for end-sites. addresses like that would enable IPv4-style multihoming, but with the usual disadvantages that come with it 😅
multi-connecting more than once to one ISP is a simple practice 💖 this can be done, for example, by using BGP with public or private AS numbers and a prefix assigned to the customer.
5.7. Quality of Service 💎
in most networks, quality of service in one form or another matters a lot 🌸
obviously, introducing IPv6 should not impair existing Service Level Agreements (SLAs) or similar quality assurances 🫶
during the deployment of the IPv6 service, the service could be best effort or something similar, even if the IPv4 service has an SLA. in the end, both IP versions should be treated equally ⭐
IntServ and DiffServ are equally applicable to IPv6 and IPv4, and they work similarly regardless of IP version 🦋 of the two, typically only DiffServ has been implemented.
a lot of bandwidth provisioning systems operate with IPv4 assumptions 😬 for example, they take an IPv4 address (or a set of prefixes) for which traffic is reserved or preferred. these systems need special attention when IPv6 support is introduced into the networks 🔧
6. Network and Service Operation Actions 🛠️
the network and service operation actions fall into these different categories:
- Set up IPv6 connectivity to upstream providers and peers
- IPv6 network device configuration: for initial configuration and updates
- IPv6 network management
- IPv6 monitoring
- IPv6 customer management
- IPv6 network and service operation security
some of these items will require an available IPv6 native transport layer, and others won't 🌈
as a first step, network device configuration and regular network management operations can be done over an IPv4 transport, because IPv6 MIBs are also available 🎀 still, some monitoring functions require IPv6 transport to be available. this is the case, for instance, when ICMPv6 messages are used by the monitoring applications 👀
on many platforms, the current inability to retrieve separate IPv4 and IPv6 traffic statistics from dual-stack interfaces for management purposes using SNMP is an issue 😤
as a second step, IPv6 transport can be provided for any of these network and service operation facilities 💅
7. Future Stages 🚀
at some point, an ISP may want to switch to a service that is IPv6 only, at least in certain parts of its network 🦋 this transition creates many new cases where continued maintenance of the IPv4 service has to be factored in. providing an IPv6-only service isn't that different from the dual IPv4/IPv6 service described in stage 3, except that the IPv4 service has to be phased out. delivering IPv4 services over an IPv6 network, and phasing out IPv4, are issues left for a later document 📚 note that some services will need to keep IPv4 connectivity, e.g., authoritative and some recursive DNS servers [DNSGUIDE] 🌷
8. Requirements for Follow-On Work 📝
this section tries to sum up the potential items that might need specifying in the IETF 💜
work items where an approach wasn't yet apparent as of this writing are:
- A tunnel server/broker mechanism, for the cases where the customer connection networks cannot be upgraded, needs to be specified [TUNREQS].
- An IPv6 site multihoming mechanism (or multiple ones) needs to be developed.
work items that were already well underway as of this writing are:
- 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's possible to use alternative methods to get the same result, so specifying this is not strictly required 🙃
9. Example Networks 🗺️
this section presents a bunch of different example networks 🌈 they won't necessarily match any existing networks, but they're meant to be useful even when they don't correspond to a specific target network. the point is to show how the transition mechanisms described in this document apply to lots of different situations with different prerequisites 💖
the sample network layout is the same in each network example 🎀 think of it as a specific representation of a generic network with a limited number of network devices. only a small number of routers are used in the examples. but because the network examples follow the implementation strategies recommended for the generic network scenario, it should be possible to scale the examples up to a network with an arbitrary number of routers, e.g., several hundreds or thousands 🧚
the routers in the sample network layout are interconnected with each other and with another ISP 🌐 the connection to the other 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 Layout9.1. Example 1 💖
okay so Example 1 is a network built on the sample network layout with a native IPv4 backbone 🦋. the backbone runs IS-IS for internal routes and IBGP for external routes (ngl, that split is clean 💅). Multiprotocol BGP swaps routes over the connections to ISP2 and the exchange point. multicast with PIM-SM is present, and QoS using DiffServ is deployed. slay ✨
Access 1 is xDSL connected to the backbone through an access router. all the xDSL gear except that access router counts as layer 2 only, like Ethernet or ATM 🧚. IPv4 addresses get dynamically assigned to the customer with DHCP, and no routing info gets exchanged with the customer. access control and traceability happen in the access router, and customers are separated into VLANs or separate ATM PVCs all the way up to it 🎀.
Access 2 is "fiber to the building or home" (FTTB/H) connected directly to the backbone router. this one is layer-3-aware 👑 because it uses layer 3 switches and does access control and traceability through that awareness by using DHCP snooping. IPv4 addresses are dynamically assigned to the customers with DHCP again, and no routing info is exchanged with the customer 🌸.
the actual IPv6 deployment might kick off by enabling IPv6 on a couple of backbone routers, setting up tunnels between them (if they aren't adjacent), and connecting to a few peers or upstream providers, either through tunnels or at an internet exchange 🍓.
after a trial period, the rest of the backbone goes dual-stack, and IS-IS (without multi-topology extensions, since the upgrade order is considered with care) becomes the IPv6 and IPv4 IGP 💜. during an upgrade, until IPv6 customers are connected behind a backbone router, the convexity requirement isn't critical. the routers just won't be reachable over IPv6 💀. software that supports IPv6 can be installed even though the routers aren't used for (customer) IPv6 traffic yet, so IPv6 can be turned on in the backbone as needed 🫶.
separate IPv6 BGP sessions get built similarly to IPv4. multicast (through SSM and Embedded-RP) and DiffServ are offered at a later phase, like after a year of stable IPv6 unicast operations 🌈.
getting native service out as fast as possible is important 😭. in the meantime, a 6to4 relay may be provided for optimized 6to4 connectivity, and it may also be combined with a tunnel broker for extended functionality. because the xDSL equipment operates as a bridge at Layer 2 only, it doesn't need any CPE changes. IPv6 connectivity can be offered to customers just 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. it also has to be compatible with prefix delegation, not just address assignment 💅. this could, however, lead to needing DHCPv6 for address assignment 🙈.
9.2. Example 2 🦋
in Example 2, the backbone runs IPv4 with MPLS, using OSPF for internal routes and IBGP for external routes 🌸. the connections to ISP2 and the exchange point run BGP to exchange routes. multicast and QoS are not deployed, so this one keeps it simple 🍓.
Access 1 is a fixed line, like fiber, connected directly to the backbone. routing info is sometimes exchanged with the CPE at the customer's site, and otherwise static routing is used 💜. Access 1 can also be connected to a BGP/MPLS-VPN running in the backbone 👑.
Access 2 is xDSL connected directly to the backbone router. the xDSL is layer 2 only, and access control and traceability are achieved through PPPoE/PPPoA. PPP also handles address assignment, and no routing info is exchanged with the customer 🎀.
IPv6 deployment might start by upgrading a couple of PE routers to support [BGPTUNNEL]. this allows large-scale IPv6 support without hardware or software upgrades in the core, which is giving efficiency ✨. in a later phase, native IPv6 traffic or IPv6 LSPs would be used across the whole network. in that case, IS-IS or OSPF could handle the internal routing, and a separate IPv6 BGP session would run 🧚.
for the fixed-line customers, the CPE has to be upgraded. 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 IP-tunneling conditions apply as in Example 1. on top of IP-tunneling, a PPP session can be used to offer IPv6 access to a limited number of customers 💅. later, once 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 🌈.
9.3. Example 3 🌸
a transit provider offers IP connectivity to other providers, but not to end users or enterprises 💖. IS-IS and IBGP are used internally, and BGP is used externally. its accesses connect Tier-2 provider cores. no multicast or QoS is used 🍓.
since this type of transit provider has a bunch of customers, who each have a large number of customers in turn, it gets an address allocation from an RIR 👑. the whole backbone can be upgraded to dual-stack in a reasonably short time after a trial with a couple of routers ✨. IPv6 routing is done using the same IS-IS process and separate IPv6 BGP sessions 🦋.
the ISP gives its customers IPv6 transit for free as a competitive advantage 💅. at the first phase only, it also provides a configured tunnel service with BGP peering to the significant sites and customers (those with an AS number) who are customers of its customers, whenever its own customer networks aren't offering IPv6 🫶. this is done both to introduce them to IPv6 and to create a beneficial side effect: a bit of extra revenue comes from its direct customers as the total amount of transited traffic grows 🤑.
10. Security Considerations 🔒
this document analyzes scenarios and identifies transition mechanisms that could be used for those scenarios 🦋. it does not introduce any new security issues. the security considerations of each mechanism are described in the respective documents.
however, a few generic observations are in order 👀.
- Introducing IPv6 adds new classes of security threats or requires adopting new protocols or operational models than those for IPv4; typically these are generic issues, to be discussed further in other documents, for example, [V6SEC].
- 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.
- 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 🚨.
this part is serious bestie 💀. the security stuff is no joke, so read those bullets twice before you deploy anything 🔥.
11. Acknowledgments 🫶
this document has greatly benefited from input by Marc Blanchet, Jordi Palet, Francois Le Faucheur, Ronald van der Pol, and Cleve Mickles 💜.
special thanks to Richard Graveman and Michael Lambert for proofreading the document 🌷.
12. Informative References 📚
[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.Appendix A: Convexity Requirements in Single Topology IS-IS ✨
okay so this appendix is the IS-IS convexity deep dive 🫶 from the IPv4/6 point of view, the single-topology IS-IS convexity requirements could be summarized like this:
- "any IP-independent path from an IPv4 router to any other IPv4 router must only go through routers which are IPv4-capable", and
- "any IP-independent path from an IPv6 router to any other IPv6 router must only go through routers which are IPv6-capable".
ngl these are not trivially accomplished 💀 because IS-IS is based upon CLNS. single-topology IS-IS builds paths that are agnostic of IP versions, so it doesn't care which version is which 🙈
let's look at an example scenario with three IPv4/IPv6-capable routers and an IPv4-only router 🦋
cost 5 R4 cost 5
,------- [v4/v6] -----.
/ \
[v4/v6] ------ [ v4 ] -----[v4/v6]
R1 cost 3 R3 cost 3 R2the second requirement would not hold here 😭 IPv6 packets from R1 to R2 (or vice versa) would go through R3, which does not support IPv6, and the packets would get discarded. 💀 by reversing the costs between R1-R3, R3-R2 and R1-R4,R4-R2, the traffic would work in the normal case. but if a link fails and the routing changes to go through R3, the packets would start being discarded again. main character problem, honestly 👑
Authors' Addresses
okay bestie, here are the authors and how to reach them 💌
Mikael Lind
TeliaSonera
Vitsandsgatan 9B
SE-12386 Farsta, Sweden
EMail: mikael.lind@teliasonera.comVladimir Ksinant
Thales Communications
160, boulevard de Valmy
92704 Colombes, France
EMail: vladimir.ksinant@fr.thalesgroup.comSoohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics.
416, Maetan-3dong, Paldal-Gu,
Suwon, Gyeonggi-do, Korea
EMail: soohong.park@samsung.comAlain Baudot
France Telecom R&D Division
42, rue des coutures
14066 Caen - FRANCE
EMail: alain.baudot@francetelecom.comPekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fiFull 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 on 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 on the extent to which any license under such rights might or might not be available. it also doesn't claim to have made any independent effort to identify any such rights. info on the procedures for rights in RFC documents is 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 to get a general license or permission for implementers or users of this specification to use these proprietary rights, can be found in 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 required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🫶
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society. 🎀 thank you, legends 🌈
📦 where this page comes from
- ietf: rfc4029 2005-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms