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).
Abstract
This 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.
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. . . . . . . . . . . . . . . . . . . 28
1. Introduction
1.1. Goal and Scope of the Document
When an ISP deploys IPv6, its goal is to provide IPv6 connectivity
and global address space to its customers. The new IPv6 service must
be added to an existing IPv4 service, and the introduction of IPv6
must not interrupt this IPv4 service.
An ISP offering IPv4 service will find different ways to add IPv6 to
this service. This document discusses a small set of scenarios for
the introduction of IPv6 into an ISP’s IPv4 network. It evaluates
the relevance of the existing transition mechanisms in the context of
these deployment scenarios and points out the lack of essential
functionality in these methods.
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.
2. Brief Description of a Generic ISP Network
A generic network topology for an ISP can be divided into two main
parts: the backbone network and customer connection networks. In
addition, it includes building blocks such as network and service
operations. The additional building blocks used in this document are
defined as follows:
"CPE" : Customer Premises Equipment
"PE" : Provider Edge Equipment
"Network and service operation"
: This is the part of the ISP’s network that hosts the
services required for the correct operation of the
ISP’s network. These services usually include
management, supervision, accounting, billing, and
customer management applications.
"Customer connection"
: This is the part of the network used by a customer
when connecting to an ISP’s network. It includes the
CPE, the last hop link, and the parts of the PE
interfacing to the last hop link.
"Backbone" : This is the rest of the ISP’s network infrastructure.
It includes the parts of the PE interfacing to the
core, the core routers of the ISP, 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 (e.g., incumbent national or regional operators), a
given customer connection network may have to be shared between or
among different ISPs. According to the type of customer connection
network used (e.g., one involving only layer 2 devices or one
involving non-IP technology), this constraint may result in
architectural considerations relevant to this document.
The basic components in the ISP’s network are depicted 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 Topology
3. Transition Scenarios
3.1. Identification of Stages and Scenarios
This section describes different stages an ISP might consider when
introducing IPv6 connectivity into its existing IPv4 network and the
different scenarios of what might occur in the respective stages.
The stages here are snapshots of the ISP’s network with respect to
IPv6 maturity. Because the ISP’s network is continually evolving, a
stage is a measure of how far along the ISP has come in terms of
implementing the functionality necessary to offer IPv6 to its
customers.
It is possible for a transition to occur freely between different
stages. Although a network segment can only be in one stage at a
time, the ISP’s network as a whole can be in different stages.
Different transition paths can be followed from the first to the
final stage. The transition between two stages does not have to be
instantaneous; it can occur gradually.
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.
3.2. Stages
The stages are derived from the generic description of an ISP’s
network in 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.
3.2.1. Stage 1 Scenarios: Launch
The first stage is an IPv4-only ISP with an IPv4 customer. This is
the most common case today and is the natural starting point for the
introduction of IPv6. From this stage, the ISP can move (undergo a
transition) from Stage 1 to any other stage with the goal of offering
IPv6 to its customer.
The immediate first step consists of obtaining a prefix allocation
(typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC,
ARIN, LACNIC, RIPE) according to allocation procedures.
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.
3.2.2. Stage 2a Scenarios: Backbone
Stage 2a deals with an ISP with IPv4-only customer connection
networks and a backbone that supports both IPv4 and IPv6. In
particular, the ISP has the possibility of making the backbone IPv6-
capable through software upgrades, hardware upgrades, or a
combination of both.
Since the customer connections have not yet been upgraded, 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 internal to its network. That is, 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 consists of 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 might be more complicated than in the
previous case because the backbone is not IPv6-enabled. After
completing Stage 2b, the original IPv4 backbone is unchanged. This
means that the IPv6 traffic is transported either by tunneling over
the existing IPv4 backbone, or in an IPv6 overlay network more or
less separated from the IPv4 backbone.
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.
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 consists of
ubiquitous IPv6 service with native support for IPv6 and IPv4 in both
backbone and customer connection networks. From the customer’s
perspective, it is identical to the previous stage because the
customer connection network has not 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 of varying IPv6
maturity. This may result in a combination of the Stages 2a and 3:
some customer connections do not 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 the different stages, it is clear that an ISP has to be able to
make a transition from one stage to another. The initial stage in
this document is an IPv4-only service and network. 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. This choice corresponds to the different transition
scenarios. Stage 2a consists of upgrading the backbone first. Stage
2b consists of upgrading the customer connection network. Finally,
Stage 3 consists of introducing IPv6 in both the backbone and
customer connections as needed.
Because most ISP backbone IPv4 networks continually evolve (firmware
replacements in routers, new routers, etc.), they can be made ready
for IPv6 without additional investment (except staff training). This
transition path may be slower but still useful, as it allows for the
introduction of IPv6 without any actual customer demand. This
approach may be superior to doing everything at the last minute,
which may entail a higher investment. However, it is important to
consider (and to request from vendors) IPv6 features in all new
equipment from the outset. Otherwise, the time and effort required
to remove non-IPv6-capable hardware from the network may be
significant.
3.4. Actions Needed When Deploying IPv6 in an ISP’s Network
Examination of the transitions described above reveals that it is
possible to split the work required for each transition into a small
set of actions. Each action is largely independent of the others,
and some actions may be common to multiple transitions.
Analysis of the possible transitions leads to a small list of
actions:
* 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 contain detailed descriptions of each action.
4. Backbone Transition Actions
4.1. Steps in the Transition of Backbone Networks
In terms of physical equipment, backbone networks mainly consist of
high-speed core and edge routers. Border routers provide peering
with other providers. Filtering, routing policy, and policing
functions are generally managed on 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 Path