draft-ietf-v6ops-isp-scenarios-analysis-03.txt   rfc4029.txt 
Internet Draft M. Lind Network Working Group M. Lind
<draft-ietf-v6ops-isp-scenarios-analysis-03.txt> TeliaSonera Request for Comments: 4029 TeliaSonera
V. Ksinant Category: Informational V. Ksinant
Thales Thales Communications
Communications
S. Park S. Park
Samsung Electronics SAMSUNG Electronics
A. Baudot A. Baudot
France Telecom France Telecom
P. Savola P. Savola
CSC/Funet CSC/Funet
Expires: December 2004 June 2004 March 2005
Scenarios and Analysis for Introducing IPv6 into ISP Networks Scenarios and Analysis for Introducing IPv6 into ISP Networks
Status of this Memo Status of This Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than a "work in progress".
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2005).
http://www.ietf.org/shadow.html
Abstract Abstract
This document first describes different scenarios for the This document describes different scenarios for the introduction of
introduction of IPv6 into an ISP's existing IPv4 network without IPv6 into an ISP's existing IPv4 network without disrupting the IPv4
disrupting the IPv4 service. Then, the scenarios for introducing IPv6 service. The scenarios for introducing IPv6 are analyzed, and the
are analyzed and the relevance of already defined transition relevance of already defined transition mechanisms are evaluated.
mechanisms are evaluated. Known challenges are also identified. Known challenges are also identified.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Goal and Scope of the Document...........................2 1.1. Goal and Scope of the Document. . . . . . . . . . . . . 2
2. Brief Description of a Generic ISP Network..................3 2. Brief Description of a Generic ISP Network. . . . . . . . . . 3
3. Transition Scenarios........................................4 3. Transition Scenarios. . . . . . . . . . . . . . . . . . . . . 4
3.1 Identification of Stages and Scenarios...................4 3.1. Identification of Stages and Scenarios. . . . . . . . . 4
3.2 Stages...................................................5 3.2. Stages. . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Stage 1 Scenarios: Launch..............................5 3.2.1. Stage 1 Scenarios: Launch . . . . . . . . . . . 5
3.2.2 Stage 2a Scenarios: Backbone...........................6 3.2.2. Stage 2a Scenarios: Backbone. . . . . . . . . . 6
3.2.3 Stage 2b Scenarios: Customer Connection................6 3.2.3. Stage 2b Scenarios: Customer Connection . . . . 6
3.2.4 Stage 3 Scenarios: Complete............................7 3.2.4. Stage 3 Scenarios: Complete . . . . . . . . . . 7
3.2.5 Stages 2a and 3: Combination Scenarios.................7 3.2.5. Stages 2a and 3: Combination Scenarios. . . . . 7
3.3 Transition Scenarios.....................................7 3.3. Transition Scenarios. . . . . . . . . . . . . . . . . . 7
3.4 Actions Needed When Deploying IPv6 in an ISP's network...8 3.4. Actions Needed When Deploying IPv6 in an ISP's Network. 8
4. Backbone Transition Actions.................................9 4. Backbone Transition Actions . . . . . . . . . . . . . . . . . 9
4.1 Steps in the Transition of Backbone Networks.............9 4.1. Steps in the Transition of Backbone Networks. . . . . . 9
4.1.1 MPLS Backbone.........................................10 4.1.1. MPLS Backbone . . . . . . . . . . . . . . . . . 9
4.2 Configuration of Backbone Equipment.....................10 4.2. Configuration of Backbone Equipment . . . . . . . . . . 10
4.3 Routing.................................................10 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1 IGP...................................................11 4.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2 EGP...................................................12 4.3.2. EGP . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3 Transport of Routing Protocols........................12 4.3.3. Transport of Routing Protocols. . . . . . . . . 12
4.4 Multicast...............................................13 4.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 13
5. Customer Connection Transition Actions.....................13 5. Customer Connection Transition Actions. . . . . . . . . . . . 13
5.1 Steps in the Transition of Customer Connection Networks.13 5.1. Steps in the Transition of Customer Connection Networks 13
5.1.1 Small end sites.......................................14 5.1.1. Small End Sites . . . . . . . . . . . . . . . . 14
5.1.2 Large end sites.......................................15 5.1.2. Large End Sites . . . . . . . . . . . . . . . . 15
5.2 User Authentication/Access Control Requirements.........15 5.2. User Authentication/Access Control Requirements . . . . 15
5.3 Configuration of Customer Equipment.....................16 5.3. Configuration of Customer Equipment . . . . . . . . . . 16
5.4 Requirements for Traceability...........................16 5.4. Requirements for Traceability . . . . . . . . . . . . . 16
5.5 Ingress Filtering in the Customer Connection Network....17 5.5. Ingress Filtering in the Customer Connection Network. . 17
5.6 Multihoming.............................................17 5.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . 17
5.7 Quality of Service......................................17 5.7. Quality of Service. . . . . . . . . . . . . . . . . . . 17
6. Network and Service Operation Actions......................18 6. Network and Service Operation Actions . . . . . . . . . . . . 18
7. Future Stages..............................................18 7. Future Stages . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Requirements for Follow-On Work............................19 8. Requirements for Follow-On Work . . . . . . . . . . . . . . . 19
9. Example Networks...........................................19 9. Example Networks. . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Example 1...............................................20 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 21
9.2 Example 2...............................................22 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 22
9.3 Example 3...............................................22 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations....................................23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements...........................................23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. Informative References.....................................24 12. Informative References. . . . . . . . . . . . . . . . . . . . 24
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
1.1 Goal and Scope of the Document 1.1. Goal and Scope of the Document
When an ISP deploys IPv6, its goal is to provide IPv6 connectivity When an ISP deploys IPv6, its goal is to provide IPv6 connectivity
and global address space to its customers. The new IPv6 service must and global address space to its customers. The new IPv6 service must
be added to an already existing IPv4 service, and the introduction of be added to an existing IPv4 service, and the introduction of IPv6
IPv6 must not interrupt this IPv4 service. must not interrupt this IPv4 service.
An ISP offering IPv4 service will find different ways to add IPv6 to An ISP offering IPv4 service will find different ways to add IPv6 to
this service. This document discusses a small set of scenarios for this service. This document discusses a small set of scenarios for
the introduction of IPv6 into an ISP's IPv4 network. It evaluates the the introduction of IPv6 into an ISP's IPv4 network. It evaluates
relevance of the existing transition mechanisms in the context of the relevance of the existing transition mechanisms in the context of
these deployment scenarios, and points out the lack of essential these deployment scenarios and points out the lack of essential
functionality in these methods to the ISP's operation of an IPv6 functionality in these methods.
service.
The document is focused on services that include both IPv6 and IPv4 The document is focused on services that include both IPv6 and IPv4
and does not cover issues surrounding IPv6-only service. It is also and does not cover issues surrounding IPv6-only service. It is also
outside the scope of this document to describe different types of outside the scope of this document to describe different types of
access or network technologies. access or network technologies.
2. Brief Description of a Generic ISP Network 2. Brief Description of a Generic ISP Network
A generic network topology for an ISP can be divided into two main A generic network topology for an ISP can be divided into two main
parts: the backbone network and customer connection networks. It parts: the backbone network and customer connection networks. In
includes, in addition to these, some other building blocks such as addition, it includes building blocks such as network and service
network and service operations. The additional building blocks used operations. The additional building blocks used in this document are
in this document are defined as follows: defined as follows:
"CPE" : Customer Premises Equipment "CPE" : Customer Premises Equipment
"PE" : Provider Edge equipment "PE" : Provider Edge Equipment
"Network and service operation" "Network and service operation"
: This is the part of the ISP's network that hosts the : This is the part of the ISP's network that hosts the
services required for the correct operation of the services required for the correct operation of the
ISP's network. These services usually include ISP's network. These services usually include
management, supervision, accounting, billing, and management, supervision, accounting, billing, and
customer management applications. customer management applications.
"Customer connection" "Customer connection"
: This is the part of the network used by a customer : This is the part of the network used by a customer
when connecting to an ISP's network. It includes the when connecting to an ISP's network. It includes the
CPE, the last hop link and the parts of the PE CPE, the last hop link, and the parts of the PE
interfacing to the last hop link. interfacing to the last hop link.
"Backbone" : This is the rest of the ISP's network infrastructure. "Backbone" : This is the rest of the ISP's network infrastructure.
It includes the parts of the PE interfacing to the It includes the parts of the PE interfacing to the
core, the core routers of the ISP, and the border core, the core routers of the ISP, and the border
routers used to exchange routing information with routers used to exchange routing information with
other ISPs (or other administrative entities). other ISPs (or other administrative entities).
"Dual-stack network": "Dual-stack network"
A network that supports natively both IPv4 and : A network that natively supports both IPv4 and IPv6.
IPv6.
It is noted that, in some cases (e.g., incumbent national or In some cases (e.g., incumbent national or regional operators), a
regional operators), a given customer connection network may have given customer connection network may have to be shared between or
to be shared between or among different ISPs. According to the type among different ISPs. According to the type of customer connection
of customer connection network used (e.g., one involving only layer 2 network used (e.g., one involving only layer 2 devices or one
devices or one involving non-IP technology), this constraint may involving non-IP technology), this constraint may result in
result in architectural considerations relevant to this document. architectural considerations relevant to this document.
The basic components in the ISP's network are depicted in Figure 1. The basic components in the ISP's network are depicted in Figure 1.
------------ ---------- ------------ ----------
| Network and| | | | Network and| | |
| Service |--| Backbone | | Service |--| Backbone |
| Operation | | |\ | Operation | | |\
------------ ---------- \ ------------ ---------- \
/ | \ \ / | \ \
/ | \ \_Peering( Direct and / | \ \_Peering( Direct and
skipping to change at page 4, line 41 skipping to change at page 4, line 28
| 1 | | 2 | | 3 | | 1 | | 2 | | 3 |
---------- ---------- ---------- ---------- ---------- ----------
| | | ISP's Network | | | ISP's Network
------------------------------------------------------- -------------------------------------------------------
| | | Customers' Networks | | | Customers' Networks
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | | | | | | | |
|Customer| |Customer| |Customer| |Customer| |Customer| |Customer|
| | | | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1: ISP Network Topology.
Figure 1: ISP Network Topology
3. Transition Scenarios 3. Transition Scenarios
3.1 Identification of Stages and Scenarios 3.1. Identification of Stages and Scenarios
This section describes different stages an ISP might consider when This section describes different stages an ISP might consider when
introducing IPv6 connectivity into its existing IPv4 network and the introducing IPv6 connectivity into its existing IPv4 network and the
different scenarios that might occur in the respective stages. different scenarios of what might occur in the respective stages.
The stages here are snapshots of the ISP's network with respect to The stages here are snapshots of the ISP's network with respect to
IPv6 maturity. Because the ISP's network is continually evolving, a 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 stage is a measure of how far along the ISP has come in terms of
implementing the functionality necessary to offer IPv6 to its implementing the functionality necessary to offer IPv6 to its
customers. customers.
It is possible for a transition to occur freely between different It is possible for a transition to occur freely between different
stages. Although a network segment can only be in one stage at a 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. time, the ISP's network as a whole can be in different stages.
Different transition paths can be followed from the first to the Different transition paths can be followed from the first to the
final stage. The transition between two stages does not have to be final stage. The transition between two stages does not have to be
instantaneous; it can occur gradually. instantaneous; it can occur gradually.
Each stage has different IPv6 properties. An ISP can, therefore, Each stage has different IPv6 properties. Therefore, based on its
based on its requirements, decide which set of stages it will follow requirements, an ISP can decide which set of stages it will follow
and in what order to transform its network. and in what order to transform its network.
This document is not aimed at covering small ISPs, hosting providers, This document is not aimed at covering small ISPs, hosting providers,
or data centers; only the scenarios applicable to ISPs eligible for or data centers; only the scenarios applicable to ISPs eligible for
at least a /32 IPv6 prefix allocation from a RIR are covered. at least a /32 IPv6 prefix allocation from an RIR are covered.
3.2 Stages 3.2. Stages
The stages are derived from the generic description of an ISP's The stages are derived from the generic description of an ISP's
network in Section 2. Combinations of different building blocks network in Section 2. Combinations of different building blocks that
that constitute an ISP's environment lead to a number of scenarios constitute an ISP's environment lead to a number of scenarios from
from which the ISP can choose. The scenarios most relevant to this which the ISP can choose. The scenarios most relevant to this
document are those that maximize ISP's ability to offer IPv6 to its document are those that maximize an ISP's ability to offer IPv6 to
customers in the most efficient and feasible way. The assumption in its customers in the most efficient and feasible way. The assumption
all stages is that the ISP's goal is to offer both IPv4 and IPv6 to in all stages is that the ISP's goal is to offer both IPv4 and IPv6
the customer. to the customer.
The four most probable stages are: The four most probable stages are as follows:
o Stage 1 Launch o Stage 1 Launch
o Stage 2a Backbone o Stage 2a Backbone
o Stage 2b Customer connection o Stage 2b Customer connection
o Stage 3 Complete o Stage 3 Complete
Generally, an ISP is able to upgrade a current IPv4 network to an 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 IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can
also be implemented at a small cost by adding simple tunnel also be implemented at a small cost by adding simple tunnel
mechanisms to the existing configuration. When designing a new mechanisms to the existing configuration. When a new network is
network, Stage 3 might be the first and last step, because there are designed, Stage 3 might be the first or last step because there are
no legacy concerns. Nevertheless, the absence of IPv6 capability in no legacy concerns. Nevertheless, the absence of IPv6 capability in
the network equipment can still be a limiting factor. the network equipment can still be a limiting factor.
Note that in every stage except Stage 1, the ISP can offer both IPv4 Note that in every stage except Stage 1, the ISP can offer both IPv4
and IPv6 services to its customers. and IPv6 services to its customers.
3.2.1 Stage 1 Scenarios: Launch 3.2.1. Stage 1 Scenarios: Launch
The first stage is an IPv4-only ISP with an IPv4 customer. This is The first stage is an IPv4-only ISP with an IPv4 customer. This is
the most common case today and the natural starting point for the 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 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 transition) from Stage 1 to any other stage with the goal of offering
IPv6 to its customer. IPv6 to its customer.
The immediate first step consists of obtaining a prefix allocation The immediate first step consists of obtaining a prefix allocation
(typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC, (typically a /32) from the appropriate RIR (e.g., AfriNIC, APNIC,
ARIN, LACNIC, RIPE, ...) according to allocation procedures. ARIN, LACNIC, RIPE) according to allocation procedures.
The ISP will also need to establish IPv6 connectivity to its upstream The ISP will also need to establish IPv6 connectivity to its upstream
providers and peers; it is of utmost importance to require IPv6 providers and peers; it is of utmost importance to require IPv6
transit when negotiating IP transit deals with the upstream ISPs. If transit when negotiating IP transit deals with the upstream ISPs. If
the upstream is not providing IPv6 connectivity at the moment, it may the upstream is not providing IPv6 connectivity at the moment, it may
be possible to temporarily obtain connectivity from some other ISP be possible to obtain temporary connectivity from a nearby ISP,
nearby, possibly using a short configured tunnel. However, the possibly using a short configured tunnel. However, the longer-term
longer-term goal must be requiring and obtaining IPv6 connectivity goal must be to require and to obtain IPv6 connectivity from the
from the transit ISPs, because otherwise the quality of IPv6 transit ISPs, because otherwise the quality of IPv6 connectivity will
connectivity will likely be poor. likely be poor.
Connectivity to peers can be typically established either directly or Connectivity to peers can typically be established either directly or
at Internet Exchange Points (IX). Most IXs are using techniques at Internet Exchange Points (IX). Most IXs use techniques where IPv6
where IPv6 is easy to use, and many IXs already provide is easy to use, and many IXs already provide infrastructure for IPv6
infrastructure for IPv6 peerings. Such peerings can be done natively peerings. Such peerings can be done natively by using IPv6.
using IPv6. Peerings over IPv6-in-IPv4 tunnels is also possible but Peerings over IPv6-in-IPv4 tunnels is also possible but not
not recommended at least in the long term. Direct connectivity to recommended, at least in the long term. Direct connectivity to peers
peers may be feasible when there is direct connectivity to the peer may be feasible when there is direct connectivity to the peer for
for IPv4. IPv4.
3.2.2 Stage 2a Scenarios: Backbone 3.2.2. Stage 2a Scenarios: Backbone
Stage 2a deal with an ISP with IPv4-only customer connection networks Stage 2a deals with an ISP with IPv4-only customer connection
and a backbone that supports both IPv4 and IPv6. In particular, the networks and a backbone that supports both IPv4 and IPv6. In
ISP has the possibility of making the backbone IPv6-capable through particular, the ISP has the possibility of making the backbone IPv6-
either software upgrades, hardware upgrades, or a combination of capable through software upgrades, hardware upgrades, or a
both. combination of both.
Since the customer connections have not yet been upgraded, a Since the customer connections have not yet been upgraded, a
tunneling mechanism has to be used to provide IPv6 connectivity tunneling mechanism has to be used to provide IPv6 connectivity
through the IPv4 customer connection networks. The customer can through the IPv4 customer connection networks. The customer can
terminate the tunnel at the CPE (if it has IPv6 support) or at some 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 set of devices internal to its network. That is, either the CPE or a
device inside the network could provide global IPv6 connectivity to device inside the network could provide global IPv6 connectivity to
the rest of the devices in the customer's network. the rest of the devices in the customer's network.
3.2.3 Stage 2b Scenarios: Customer Connection 3.2.3. Stage 2b Scenarios: Customer Connection
Stage 2b consists of an ISP with an IPv4 backbone network and a Stage 2b consists of an ISP with an IPv4 backbone network and a
customer connection network that supports both IPv4 and IPv6. Because customer connection network that supports both IPv4 and IPv6.
the service to the customer is native IPv6, the customer is not Because the service to the customer is native IPv6, the customer is
required to support both IPv4 and IPv6. This is the biggest not required to support both IPv4 and IPv6. This is the biggest
difference in comparison to the previous stage. The need to exchange difference from the previous stage. The need to exchange IPv6
IPv6 traffic still exists but might be more complicated than in the traffic still exists but might be more complicated than in the
previous case, because the backbone is not IPv6-enabled. After previous case because the backbone is not IPv6-enabled. After
completing Stage 2b, the original IPv4 backbone is unchanged. This completing Stage 2b, the original IPv4 backbone is unchanged. This
means that the IPv6 traffic is transported either by tunneling over means that the IPv6 traffic is transported either by tunneling over
the existing IPv4 backbone, or in an IPv6 overlay network more or the existing IPv4 backbone, or in an IPv6 overlay network more or
less separated from the IPv4 backbone. less separated from the IPv4 backbone.
Normally the ISP will continue to provide IPv4 connectivity using Normally, the ISP will continue to provide IPv4 connectivity by using
private (NATted by the ISP) or public IPv4 address; in many cases, private (NATted by the ISP) or public IPv4 address. In many cases,
the customer also has a NAT of his/her own, and if so, this likely the customer also has a NAT of his/her own; if so, this likely
continues to be used for IPv4 connectivity. continues to be used for IPv4 connectivity.
3.2.4 Stage 3 Scenarios: Complete 3.2.4. Stage 3 Scenarios: Complete
Stage 3 can be said to be the final step in introducing IPv6, at Stage 3 could be considered the final step in introducing IPv6, at
least within the scope of this document. This stage consists of least within the scope of this document. This stage consists of
ubiquitous IPv6 service with native support for IPv6 and IPv4 in both ubiquitous IPv6 service with native support for IPv6 and IPv4 in both
backbone and customer connection networks. It is identical to the backbone and customer connection networks. From the customer's
previous stage from the customer's perspective, because the customer perspective, it is identical to the previous stage because the
connection network has not changed. The requirement for exchanging customer connection network has not changed. The requirement for
IPv6 traffic is identical to Stage 2. exchanging IPv6 traffic is identical to that of Stage 2.
3.2.5 Stages 2a and 3: Combination Scenarios 3.2.5. Stages 2a and 3: Combination Scenarios
Some ISPs may use different access technologies of varying IPv6 Some ISPs may use different access technologies of varying IPv6
maturity. This may result in a combination of the Stages 2a and 3: 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 some customer connections do not support IPv6, but others do; in both
cases the backbone is dual-stack. cases the backbone is dual-stack.
This scenario is equivalent to Stage 2a, but it requires support for This scenario is equivalent to Stage 2a, but it requires support for
native IPv6 customer connections on some access technologies. native IPv6 customer connections on some access technologies.
3.3 Transition Scenarios 3.3. Transition Scenarios
Given the different stages, it is clear that an ISP has to be able Given the different stages, it is clear that an ISP has to be able to
to make a transition from one stage to another. The initial stage in make a transition from one stage to another. The initial stage in
this document is IPv4-only service and network. The end stage is dual this document is an IPv4-only service and network. The end stage is
IPv4/IPv6 service and network. a dual IPv4/IPv6 service and network.
The transition starts with an IPv4 ISP and then moves in one of The transition starts with an IPv4 ISP and then moves in one of three
three directions. This choice corresponds to the different directions. This choice corresponds to the different transition
transition scenarios. Stage 2a consists of upgrading the backbone scenarios. Stage 2a consists of upgrading the backbone first. Stage
first. Stage 2b consists of upgrading the customer connection 2b consists of upgrading the customer connection network. Finally,
network. Finally, Stage 3 consists of introducing IPv6 in both the Stage 3 consists of introducing IPv6 in both the backbone and
backbone and customer connections as needed. customer connections as needed.
Because most ISP backbone IPv4 networks continually evolve (firmware Because most ISP backbone IPv4 networks continually evolve (firmware
replacements in routers, new routers, etc.), they can be made ready replacements in routers, new routers, etc.), they can be made ready
for IPv6 without additional investment (except staff training). This for IPv6 without additional investment (except staff training). This
may be a slower but still useful transition path, because it allows transition path may be slower but still useful, as it allows for the
for the introduction of IPv6 without any actual customer demand. This introduction of IPv6 without any actual customer demand. This
process may be superior to doing everything at the last minute, which approach may be superior to doing everything at the last minute,
may entail a higher investment. However, it is important to consider which may entail a higher investment. However, it is important to
(and to request from vendors) IPv6 features in all new equipment from consider (and to request from vendors) IPv6 features in all new
the outset. Otherwise, the time and effort required to remove non- equipment from the outset. Otherwise, the time and effort required
IPv6-capable hardware from the network may be significant. to remove non-IPv6-capable hardware from the network may be
significant.
3.4 Actions Needed When Deploying IPv6 in an ISP's network 3.4. Actions Needed When Deploying IPv6 in an ISP's Network
Examination of the transitions described above reveals that it Examination of the transitions described above reveals that it is
is possible to split the work required for each transition into a possible to split the work required for each transition into a small
small set of actions. Each action is largely independent of the set of actions. Each action is largely independent of the others,
others, and some actions may be common to multiple transitions. and some actions may be common to multiple transitions.
Analysis of the possible transitions leads to a small list of Analysis of the possible transitions leads to a small list of
actions: actions:
* Actions required for backbone transition: * Actions required for backbone transition:
- Connect dual-stack customer connection networks to other - Connect dual-stack customer connection networks to other
IPv6 networks through an IPv4 backbone. IPv6 networks through an IPv4 backbone.
- Transform an IPv4 backbone into a dual-stack one. This - Transform an IPv4 backbone into a dual-stack one. This
skipping to change at page 8, line 52 skipping to change at page 8, line 43
* Actions required for network and service operation transition: * Actions required for network and service operation transition:
- Set up IPv6 connectivity to upstream providers and peers. - Set up IPv6 connectivity to upstream providers and peers.
- Configure IPv6 functions into network components. - Configure IPv6 functions into network components.
- Upgrade regular network management and monitoring - Upgrade regular network management and monitoring
applications to take IPv6 into account. applications to take IPv6 into account.
- Extend customer management (e.g., RADIUS) mechanisms - Extend customer management (e.g., RADIUS) mechanisms to be
to be able to supply IPv6 prefixes and other information able to supply IPv6 prefixes and other information to
to customers. customers.
- Enhance accounting, billing, etc. to work with IPv6 - Enhance accounting, billing, and so on to work with IPv6 as
as needed. (Note: if dual-stack service is offered, this needed. (Note: If dual-stack service is offered, this may
may not be necessary.) not be necessary.)
- Implement security for network and service operation. - Implement security for network and service operation.
Sections 4, 5, and 6 contain detailed descriptions of each action. Sections 4, 5, and 6 contain detailed descriptions of each action.
4. Backbone Transition Actions 4. Backbone Transition Actions
4.1 Steps in the Transition of Backbone Networks 4.1. Steps in the Transition of Backbone Networks
In terms of physical equipment, backbone networks consist mainly of In terms of physical equipment, backbone networks mainly consist of
high-speed core and edge routers. Border routers provide peering high-speed core and edge routers. Border routers provide peering
with other providers. Filtering, routing policy, and policing with other providers. Filtering, routing policy, and policing
functions are generally managed on border routers. functions are generally managed on border routers.
In the beginning, an ISP has an IPv4-only backbone. In the end, the In the beginning, an ISP has an IPv4-only backbone. In the end, the
backbone is completely dual-stack. In between, intermediate steps may backbone is completely dual-stack. In between, intermediate steps
be identified: may be identified:
Tunnels Tunnels Dual Full Tunnels Tunnels Dual Full
IPv4-only ----> or ---> or + Stack --> Dual Stack IPv4-only ----> or ---> or + Stack --> Dual Stack
dedicated IPv6 dedicated IPv6 routers dedicated IPv6 dedicated IPv6 routers
links links links links
Figure 2: Transition Path.
Figure 2: Transition Path
The first step involves tunnels or dedicated links but leaves The first step involves tunnels or dedicated links but leaves
existing routers unchanged. Only a small set of routers then have existing routers unchanged. Only a small set of routers then have
IPv6 capabilities. The use of configured tunnels is adequate during IPv6 capabilities. The use of configured tunnels is adequate during
this step. this step.
In the second step, some dual-stack routers are added, progressively, In the second step, some dual-stack routers are added, progressively,
to this network. to this network.
The final step is reached when all or almost all routers are dual- The final step is reached when all or almost all routers are
stack. dual-stack.
For many reasons (technical, financial, etc.), the ISP may progress For many reasons (technical, financial, etc.), the ISP may progress
step by step or jump directly to the final one. One important step by step or jump directly to the final one. One important
criterion in planning this evolution is the number of IPv6 customers criterion in planning this evolution is the number of IPv6 customers
the ISP expects during its initial deployments. If few customers the ISP expects during its initial deployments. If few customers
connect to the original IPv6 infrastructure, then the ISP is likely connect to the original IPv6 infrastructure, then the ISP is likely
to remain in the initial steps for a long time. to remain in the initial steps for a long time.
In short, each intermediate step is possible, but none is mandatory. In short, each intermediate step is possible, but none is mandatory.
4.1.1 MPLS Backbone 4.1.1. MPLS Backbone
If MPLS is already deployed in the backbone, it may be desirable If MPLS is already deployed in the backbone, it may be desirable to
to provide IPv6-over-MPLS connectivity. However, setting up an IPv6 provide IPv6-over-MPLS connectivity. However, setting up an IPv6
Label Switched Path (LSP) requires signaling through the MPLS Label Switched Path (LSP) requires signaling through the MPLS
network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might
require upgrade/change in the MPLS core network. require upgrade/change in the MPLS core network.
An alternative approach is to use BGP for signaling or to perform, An alternative approach is to use BGP for signaling or to perform;
for example IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some of for example, IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some
the multiple possibilities are preferable to others depending on the possibilities are preferable to others, depending on the specific
specific environment under consideration; the approaches seem to be: environment under consideration. The approaches seem to be as
follows:
1) Require that MPLS networks deploy native IPv6 routing and 1) Require that MPLS networks deploy native IPv6 routing and
forwarding support. forwarding support.
2) Require that MPLS networks support native routing and setting 2) Require that MPLS networks support native routing and
up of IPv6 LSPs, used for IPv6 connectivity. setting up of IPv6 LSPs, used for IPv6 connectivity.
3) Use only configured tunneling over IPv4 LSPs. 3) Use only configured tunneling over IPv4 LSPs.
4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation 4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation
for IPv6 connectivity. for IPv6 connectivity.
Approaches 1) and 2) are clearly the best target approaches. However, Approaches 1) and 2) are clearly the best target approaches.
approach 1) may not be possible if the ISP is not willing to add IPv6 However, approach 1) may not be possible if the ISP is not willing to
support in the network, or if the installed equipment is not capable add IPv6 support in the network, or if the installed equipment is not
of high performance native IPv6 forwarding. Approach 2) may not be capable of high performance native IPv6 forwarding. Approach 2) may
possible if the ISP is not willing or able to add IPv6 LSP set-up not be possible if the ISP is unwilling or unable to add IPv6 LSP
support in the MPLS control plane. set-up support in the MPLS control plane.
Approach 4) can be used as an interim mechanism where other options Approach 4) can be used as an interim mechanism when other options
are unfeasible or undesirable for the reasons discussed above. are unfeasible or undesirable for the reasons discussed above.
Approach 3) is roughly equivalent to approach 4) except that it does Approach 3) is roughly equivalent to approach 4) except that it does
not require additional mechanisms but may lack scalability in the not require additional mechanisms but may lack scalability in the
larger networks especially if IPv6 is widely deployed. larger networks, especially if IPv6 is widely deployed.
4.2 Configuration of Backbone Equipment 4.2. Configuration of Backbone Equipment
In the backbone, the number of devices is small and IPv6 In the backbone, the number of devices is small, and IPv6
configuration mainly deals with routing protocol parameters, configuration mainly deals with routing protocol parameters,
interface addresses, loop-back addresses, access control lists, etc. interface addresses, loop-back addresses, access control lists, and
so on.
These IPv6 parameters need to be configured manually. These IPv6 parameters need to be configured manually.
4.3 Routing 4.3. Routing
ISPs need routing protocols to advertise reachability and to
find the shortest working paths, both internally and externally. 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 Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is
not usually used in service provider networks due to OSPF and IS-IS not usually used in service provider networks, as OSPF and IS-IS are
being far superior IGPs. BGP is the only IPv4 EGP. Static routes also superior IGPs. BGP is the only IPv4 EGP. Static routes also are
are used in both cases. used in both cases.
Note that it is possible to configure a given network so that it Note that it is possible to configure a given network so that it has
results in having an IPv6 topology different from its IPv4 topology. an IPv6 topology different from its IPv4 topology. For example, some
For example, some links or interfaces may be dedicated to IPv4-only links or interfaces may be dedicated to IPv4-only or IPv6-only
or IPv6-only traffic, or some routers may be dual-stack whereas traffic, or some routers may be dual-stack whereas others may be
others may be IPv4- or IPv6-only. In this case, routing protocols IPv4- or IPv6-only. In this case, routing protocols must be able to
must be able to understand and cope with multiple topologies. understand and cope with multiple topologies.
4.3.1 IGP 4.3.1. IGP
Once the IPv6 topology has been determined, the choice of IPv6 IGP Once the IPv6 topology has been determined, the choice of IPv6 IGP
must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not
appropriate in most contexts, due to RIPv2 not being appropriate appropriate in most contexts, due to RIPv2 not being appropriate for
for IPv4 either, and is therefore not discussed here. The IGP IPv4 either, and is therefore not discussed here. The IGP typically
typically includes the routers' point-to-point and loop-back includes the routers' point-to-point and loop-back addresses.
addresses.
The most important decision is whether one wishes to have separate The most important decision is whether one wishes to have separate
routing protocol processes for IPv4 and IPv6. Separating them routing protocol processes for IPv4 and IPv6. Separating them
requires more memory and CPU for route calculations, e.g., when the requires more memory and CPU for route calculations, e.g., when the
links flap. On the other hand, separation provides a certain measure links flap. But separation provides a measure of assurance that
of assurance that if problems arise with IPv6 routing, they will not should problems arise with IPv6 routing, they will not affect the
affect the IPv4 routing protocol at all. In the initial phases, if IPv4 routing protocol. In the initial phases, if it is uncertain
it is uncertain whether joint IPv4-IPv6 networking is working as whether joint IPv4-IPv6 networking is working as intended, running
intended, running separate processes may be desirable and easier to separate processes may be desirable and easier to manage.
manage.
Thus the possible combinations are: The possible combinations are as follows:
- with separate processes: - With separate processes:
o OSPFv2 for IPv4, IS-IS for IPv6 (only) o OSPFv2 for IPv4, IS-IS for IPv6 (only)
o OSPFv2 for IPv4, OSPFv3 for IPv6, or o OSPFv2 for IPv4, OSPFv3 for IPv6, or
o IS-IS for IPv4, OSPFv3 for IPv6 o IS-IS for IPv4, OSPFv3 for IPv6
- with the same process: - With the same process:
o IS-IS for both IPv4 and IPv6 o IS-IS for both IPv4 and IPv6
Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/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 topologies must be "convex", unless the multiple-topology IS-IS
extensions [MTISIS] have been implemented (note that using IS-IS for extensions [MTISIS] have been implemented (using IS-IS for only IPv4
only IPv4 or only IPv6 requires no convexity). In simpler networks or or only IPv6 requires no convexity). In simpler networks or with
with careful planning of IS-IS link costs, it is possible to keep careful planning of IS-IS link costs, it is possible to keep even
even incongruent IPv4/IPv6 topologies "convex." The convexity problem incongruent IPv4/IPv6 topologies "convex". The convexity problem is
is explained in more detail with an example in Appendix A. explained in more detail with an example in Appendix A.
When deploying full dual-stack in the short-term, using single- When deploying full dual-stack in the short-term, using single-
topology IS-IS is recommended. This may be applicable particularly topology IS-IS is recommended. This may be particularly applicable
for some larger ISPs. In other scenarios, determining between one or for some larger ISPs. In other scenarios, choosing between one or
two separate processes often depends on the perceived risk to the two separate processes often depends on the perceived risk to the
IPv4 routing infrastructure, i.e., whether one wishes to keep them IPv4 routing infrastructure, i.e., whether one wishes to keep them
separate for the time being. If that is not a factor, using a single separate for the time being. If this is not a factor, using a single
process is usually preferable due to operational reasons: not having process is usually preferable for operational reasons: not having to
to manage two protocols and topologies. manage two protocols and topologies.
The IGP is typically only used to carry loopback and point-to-point The IGP is typically only used to carry loopback and point-to-point
addresses and doesn't include customer prefixes or external routes. addresses and doesn't include customer prefixes or external routes.
Internal BGP (iBGP), as described in the next section, is most often Internal BGP (iBGP), as described in the next section, is most often
deployed in all routers (PE and core) to distribute routing deployed in all routers (PE and core) to distribute routing
information about customer prefixes and external routes. information about customer prefixes and external routes.
Some of the simplest devices, e.g., CPE routers, may not implement Some of the simplest devices (e.g., CPE routers) may not implement
routing protocols other than RIPng. In some cases, therefore, it may 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 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 least in a limited fashion, and then, by some mechanism, to
redistribute routing information between the routing protocols. redistribute routing information between the routing protocols.
4.3.2 EGP 4.3.2. EGP
BGP is used for both internal and external BGP sessions. BGP is used for both internal and external BGP sessions.
BGP with multiprotocol extensions [RFC 2858] can be used for IPv6 BGP with multiprotocol extensions [RFC 2858] can be used for IPv6
[RFC 2545]. These extensions enable the exchange of IPv6 routing [RFC 2545]. These extensions enable the exchange of IPv6 routing
information as well as the establishment of BGP sessions using TCP information and the establishment of BGP sessions using TCP over
over IPv6. 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.
4.3.3 Transport of Routing Protocols 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.
IPv4 routing information should be carried by IPv4 transport and 4.3.3. Transport of Routing Protocols
similarly IPv6 routing information by IPv6 for several reasons:
* IPv6 connectivity may work when IPv4 connectivity is down IPv4 routing information should be carried by IPv4 transport and,
(or vice-versa). 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 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 * 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 is not a major concern for most ISPs. Currently, IPv6 multicast is not a major concern for most ISPs.
However, some of them are considering deploying it. Multicast is However, some of them are considering deploying it. Multicast is
achieved using the PIM-SM and PIM-SSM protocols. These also work with achieved by using the PIM-SM and PIM-SSM protocols. These also work
IPv6. with IPv6.
Information about multicast sources is exchanged using MSDP in IPv4, Information about multicast sources is exchanged by using MSDP in
but MSDP is intentionally not defined for IPv6. Instead, one should IPv4, but MSDP is intentionally not defined for IPv6. Instead, one
use only PIM-SSM or an alternative mechanism for conveying the should use only PIM-SSM or an alternative mechanism for conveying the
information [EMBEDRP]. information [EMBEDRP].
5. Customer Connection Transition Actions 5. Customer Connection Transition Actions
5.1 Steps in the Transition of Customer Connection Networks 5.1. Steps in the Transition of Customer Connection Networks
Customer connection networks are generally composed of a small set of Customer connection networks are generally composed of a small set of
PEs connected to a large set of CPEs, and may be based on different PEs connected to a large set of CPEs and may be based on different
technologies depending on the customer type or size, as well as the technologies depending on the customer type or size, as well as the
required bandwidth or even quality of service. Basically, public required bandwidth or even quality of service. Small unmanaged
customers or small/unmanaged networks connection networks usually connection networks used for public customers usually rely on
rely on a different technologies (e.g. dial-up or DSL) than the ones different technologies (e.g., dial-up or DSL) than the ones used for
used for large customers typically running managed networks. large customers, which typically run managed networks. Transitioning
Transitioning these infrastructures to IPv6 can be accomplished in these infrastructures to IPv6 can be accomplished in several steps,
several steps, but some ISPs, depending on their perception of the but some ISPs, depending on their perception of the risks, may avoid
risks, may avoid some of the steps. some of the steps.
Connecting IPv6 customers to an IPv6 backbone through an IPv4 network Connecting IPv6 customers to an IPv6 backbone through an IPv4 network
can be considered as a first careful step taken by an ISP to provide can be considered a first careful step taken by an ISP to provide
IPv6 services to its IPv4 customers. In addition, some ISPs may also IPv6 services to its IPv4 customers. Some ISPs may also choose to
choose to provide IPv6 service independently from the regular IPv4 provide IPv6 service independently from the regular IPv4 service.
service.
In any case, IPv6 service can be provided by using tunneling In any case, IPv6 service can be provided by using tunneling
techniques. The tunnel may terminate at the CPE corresponding to the techniques. The tunnel may terminate at the CPE corresponding to the
IPv4 service or in some other part of the customer's infrastructure IPv4 service or in some other part of the customer's infrastructure
(for instance, on IPv6-specific CPE or even on a host). (for instance, on IPv6-specific CPE or even on a host).
Several tunneling techniques have already been defined: configured Several tunneling techniques have already been defined: configured
tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], etc. tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], and so
Some of them are based on a specific addressing plan independent of on. Some of these are based on a specific addressing plan
the ISP's allocated prefix(es), while some others use a part of the independent of the ISP's allocated prefix(es), while others use a
ISP's prefix. In most cases using ISP's address space is preferable. 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 A key factor is the presence or absence of NATs between the two
tunnel end-points. In most cases, 6to4 and ISATAP are incompatible tunnel end-points. In most cases, 6to4 and ISATAP are incompatible
with NATs, and UDP encapsulation for configured tunnels has not been with NATs, and UDP encapsulation for configured tunnels has not been
specified. specified.
Dynamic and non-permanent IPv4 address allocation is another factor a Dynamic and non-permanent IPv4 address allocation is another factor a
tunneling technique may have to deal with. In this case the tunneling tunneling technique may have to deal with. In this case, the
techniques may be more difficult to deploy at the ISP's end, tunneling techniques may be more difficult to deploy at the ISP's
especially if a protocol including authentication (like PPP for IPv6) end, especially if a protocol including authentication (like PPP for
is not used. This may need to be considered in more detail. IPv6) is not used. This may need to be considered in more detail.
However, NAT traversal can be avoided if the NAT supports forwarding However, NAT traversal can be avoided if the NAT supports forwarding
protocol-41 [PROTO41] and is configured to do so. protocol-41 [PROTO41] and is configured to do so.
Firewalls in the path can also break tunnels of these types. The Firewalls in the path can also break tunnels of these types. The
administrator of the firewall needs to create a hole for the tunnel. administrator of the firewall needs to create a hole for the tunnel.
This is usually manageable, as long as the firewall is controlled by This is usually manageable, as long as the firewall is controlled by
either the customer or the ISP, which is almost always the case. either the customer or the ISP, which is almost always the case.
When the CPE is performing NAT or firewall functions, terminating the When the CPE is performing NAT or firewall functions, terminating the
tunnels directly at the CPE typically simplifies the scenario tunnels directly at the CPE typically simplifies the scenario
considerably, avoiding the NAT and firewall traversal. If such an considerably, avoiding the NAT and firewall traversal. If such an
approach is adopted, the CPE has to support the tunneling mechanism approach is adopted, the CPE has to support the tunneling mechanism
used, or be upgraded to do so. used, or be upgraded to do so.
5.1.1 Small end sites 5.1.1. Small End Sites
Tunneling considerations for small end sites are discussed in Tunneling considerations for small end sites are discussed in
[UNMANEVA]. These identify solutions relevant to the first category [UNMANEVA]. These identify solutions relevant to the first category
of unmanaged networks. The tunneling requirements applicable in these of unmanaged networks. The tunneling requirements applicable in
scenarios are described in [TUNREQS] these scenarios are described in [TUNREQS].
The connectivity mechanisms can be categorized as "managed" or The connectivity mechanisms can be categorized as "managed" or
"opportunistic." The former consist of native service or a "opportunistic". The former consist of native service or a
configured tunnel (with or without a tunnel broker); the latter configured tunnel (with or without a tunnel broker); the latter
include 6to4 and, e.g., Teredo -- they provide "short-cuts" between include 6to4 and, e.g., Teredo -- they provide "short-cuts" between
nodes using the same mechanisms and are available without contracts nodes using the same mechanisms and are available without contracts
with the ISP. with the ISP.
The ISP may offer opportunistic services, mainly a 6to4 relay, The ISP may offer opportunistic services, mainly a 6to4 relay,
especially as a test when no actual service is offered yet. At the especially as a test when no actual service is offered yet. At the
later phases, ISPs might also deploy 6to4 relays and Teredo servers later phases, ISPs might also deploy 6to4 relays and Teredo servers
(or similar) to optimize their customers' connectivity to 6to4 and (or similar) to optimize their customers' connectivity to 6to4 and
Teredo nodes. Teredo nodes.
It is to be noticed that opportunistic services are typically based Opportunistic services are typically based on techniques that don't
on techniques that don't use IPv6 addresses out of the ISP's use IPv6 addresses from the ISP's allocated prefix(es), and the
allocated prefix(es), and that the services have very limited services have very limited functions to control the origin and the
functions to control the origin and the number of customers connected number of customers connected to a given relay.
to a given relay.
Most interesting are the managed services. When dual-stack is not an Most interesting are the managed services. When dual-stack is not an
option, a form of tunneling must be used. When configured tunneling 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 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 automation has to be used. Basically, the options are either to
deploy an L2TP architecture (whereby the customers would run L2TP deploy an L2TP architecture (whereby the customers would run L2TP
clients and PPP over it to initiate IPv6 sessions) or to deploy a clients and PPP over it to initiate IPv6 sessions) or to deploy a
tunnel configuration service. The prime candidates for tunnel tunnel configuration service. The prime candidates for tunnel
configuration are STEP [STEP] and TSP [TSP], which both also work in configuration are STEP [STEP] and TSP [TSP], which both also work in
the presence of NATs. Neither is analyzed further in this document. the presence of NATs. Neither is analyzed further in this document.
5.1.2 Large end sites 5.1.2. Large End Sites
Large end sites usually have a managed network. Large end sites usually have a managed network.
Dual-stack access service is often a realistic possibility since the Dual-stack access service is often a possibility, as the customer
customer network is managed (although CPE upgrades may be necessary). network is managed (although CPE upgrades may be necessary).
Configured tunnels, as-is, are a good solution when a NAT is not in 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 the way and the IPv4 end-point addresses are static. In this
scenario, NAT traversal is not typically required. If fine-grained scenario, NAT traversal is not typically required. If fine-grained
access control is needed, an authentication protocol needs to be access control is needed, an authentication protocol needs to be
implemented. implemented.
Tunnel brokering solutions, to help facilitate the set-up of a bi- Tunnel brokering solutions have been proposed to help facilitate the
directional tunnel, have been proposed. Such mechanisms are typically set-up of a bi-directional tunnel. Such mechanisms are typically
unnecessary for large end-sites, as simple configured tunneling or unnecessary for large end-sites, as simple configured tunneling or
native access can be used instead. However, if such mechanisms would native access can be used instead. However, if such mechanisms would
already be deployed, large sites starting to deploy IPv6 might be already be deployed, large sites starting to deploy IPv6 might
able to benefit from them in any case. benefit from them in any case.
Teredo is not applicable in this scenario as it can only provide IPv6 Teredo is not applicable in this scenario, as it can only provide
connectivity to a single host, not the whole site. 6to4 is not IPv6 connectivity to a single host, not the whole site. 6to4 is not
recommended due to its reliance on the relays and provider- recommended due to its reliance on the relays and provider-
independent address space, which make it impossible to guarantee the independent address space, which makes it impossible to guarantee the
required service quality and manageability large sites typically required service quality and manageability large sites typically
want. want.
5.2 User Authentication/Access Control Requirements 5.2. User Authentication/Access Control Requirements
User authentication can be used to control who can use the IPv6 User authentication can be used to control who can use the IPv6
connectivity service in the first place or who can access specific connectivity service in the first place or who can access specific
IPv6 services (e.g., NNTP servers meant for customers only, etc.). IPv6 services (e.g., NNTP servers meant for customers only). The
The former is described at more length below. The latter can be former is described at more length below. The latter can be achieved
achieved by ensuring that for all the service-specific IPv4 access by ensuring that for all the service-specific IPv4 access lists,
lists, there are also equivalent IPv6 access lists. there are also equivalent IPv6 access lists.
IPv6-specific user authentication is not always required. An example IPv6-specific user authentication is not always required. An example
is a customer of the IPv4 service automatically having access to the would be a customer of the IPv4 service automatically having access
IPv6 service. In this case the IPv4 access control also provides to the IPv6 service. In this case, the IPv4 access control also
access to the IPv6 services. provides access to the IPv6 services.
When a provider does not wish to give its IPv4 customers When a provider does not wish to give its IPv4 customers automatic
automatic access to IPv6 services, specific IPv6 access control must access to IPv6 services, specific IPv6 access control must be
be performed in parallel with the IPv4 access control. This does not performed parallel with the IPv4 access control. This does not imply
imply that different user authentication must be performed for IPv6, that different user authentication must be performed for IPv6, but
but merely that the authentication process may lead to different merely that the authentication process may lead to different results
results for IPv4 and IPv6 access. for IPv4 and IPv6 access.
Access control traffic may use IPv4 or IPv6 transport. For instance, Access control traffic may use IPv4 or IPv6 transport. For instance,
RADIUS [RADIUS] traffic related to IPv6 service can be transported RADIUS [RFC2865] traffic related to IPv6 service can be transported
over IPv4. over IPv4.
5.3 Configuration of Customer Equipment 5.3. Configuration of Customer Equipment
The customer connection networks are composed of PE and CPE(s). The customer connection networks are composed of PE and CPE(s).
Usually, each PE connects multiple CPE components to the backbone Usually, each PE connects multiple CPE components to the backbone
network infrastructure. This number may reach tens of thousands or network infrastructure. This number may reach tens of thousands of
more. The configuration of CPE is a difficult task for the ISP, and customers, or more. The configuration of CPE is difficult for the
it is even more difficult when it must be done remotely. In this ISP, and it is even more difficult when it must be done remotely. In
context, the use of auto-configuration mechanisms is beneficial, even this context, the use of auto-configuration mechanisms is beneficial,
if manual configuration is still an option. even if manual configuration is still an option.
The parameters that usually need to be provided to customers The parameters that usually need to be provided to customers
automatically are: automatically are as follows:
- The network prefix delegated by the ISP, - The network prefix delegated by the ISP
- The address of the Domain Name System server (DNS), - The address of the Domain Name System server (DNS)
- Possibly other parameters, e.g., the address of an NTP - Possibly other parameters (e.g., the address of an NTP
server. server)
When user identification is required on the ISP's network, DHCPv6 may When user identification is required on the ISP's network, DHCPv6 may
be used to provide configurations; otherwise, either DHCPv6 or a be used to provide configurations; otherwise, either DHCPv6 or a
stateless mechanism can be used. This is discussed in more detail in stateless mechanism may be used. This is discussed in more detail in
[DUAL ACCESS]. [DUAL-ACCESS].
Note that when the customer connection network is shared between the Note that when the customer connection network is shared between the
users or the ISPs, and not just a point-to-point link, authenticating users or the ISPs and is not just a point-to-point link,
the configuration of the parameters (especially prefix delegation) authenticating the configuration of the parameters (especially prefix
requires further study. delegation) requires further study.
As long as IPv4 service is available alongside IPv6 it is not As long as IPv4 service is available alongside IPv6, it is not
required to auto configure IPv6 parameters in the CPE, except the required to auto configure IPv6 parameters in the CPE, except the
prefix, because the IPv4 settings may be used. prefix, because the IPv4 settings may be used.
5.4 Requirements for Traceability 5.4. Requirements for Traceability
Most ISPs have some kind of mechanism to trace the origin of traffic Most ISPs have some kind of mechanism to trace the origin of traffic
in their networks. This also has to be available for IPv6 traffic, in their networks. This also has to be available for IPv6 traffic,
meaning that a specific IPv6 address or prefix has to be tied to a meaning that a specific IPv6 address or prefix has to be tied to a
certain customer, or that records of which customer had which certain customer, or that records must be maintained of which
address or prefix must be maintained. This also applies to the customer had which address or prefix. This also applies to the
customers with tunneled connectivity. customers with tunneled connectivity.
This can be done, for example, by mapping a DHCP response to a 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 physical connection and storing the result in a database. It can
be done by assigning a static address or prefix to the customer. A also be done by assigning a static address or prefix to the customer.
tunnel server could also provide this mapping. A tunnel server could also provide this mapping.
5.5 Ingress Filtering in the Customer Connection Network 5.5. Ingress Filtering in the Customer Connection Network
Ingress filtering must be deployed towards the customers, everywhere, Ingress filtering must be deployed toward the customers, everywhere,
to ensure traceability, to prevent DoS attacks using spoofed to ensure traceability, to prevent DoS attacks using spoofed
addresses, to prevent illegitimate access to the management addresses, to prevent illegitimate access to the management
infrastructure, etc. infrastructure, and so on.
Ingress filtering can be done, for example, by using access lists or Ingress filtering can be done, for example, by using access lists or
Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
described in [RFC3704]. described in [RFC3704].
5.6 Multihoming 5.6. Multihoming
Customers may desire multihoming or multi-connecting for a number of Customers may desire multihoming or multi-connecting for a number of
reasons [RFC3582]. reasons [RFC3582].
Mechanisms for multihoming to more than one ISP are still under Mechanisms for multihoming to more than one ISP are still under
discussion. One working model could be to deploy at least one prefix discussion. One working model would deploy at least one prefix per
per ISP, and to choose the prefix from the ISP to which traffic is ISP and choose the prefix from the ISP to which traffic is sent. In
sent. In addition, tunnels may be used for robustness [RFC3178]. addition, tunnels may be used for robustness [RFC3178]. Currently,
Currently, there are no provider-independent addresses for end-sites. there are no provider-independent addresses for end-sites. Such
Such addresses would enable IPv4-style multihoming, with associated addresses would enable IPv4-style multihoming, with associated
disadvantages. disadvantages.
Multi-connecting more than once to just one ISP is a simple Multi-connecting more than once to one ISP is a simple practice, and
practice, and this can be done, e.g., by using BGP with public or this can be done, for example, by using BGP with public or private AS
private AS numbers and a prefix assigned to the customer. numbers and a prefix assigned to the customer.
5.7 Quality of Service 5.7. Quality of Service
In most networks, quality of service in one form or another is In most networks, quality of service in one form or another is
important. important.
Naturally, the introduction of IPv6 should not impair existing Naturally, the introduction of IPv6 should not impair existing
Service Level Agreements (SLAs) or similar quality assurances. Service Level Agreements (SLAs) or similar quality assurances.
During the deployment of the IPv6 service, the service could be best- During the deployment of the IPv6 service, the service could be best
effort or similar even if the IPv4 service has a SLA. In the end both effort or similar, even if the IPv4 service has an SLA. In the end,
IP version should be treated equally. both IP versions should be treated equally.
IntServ and DiffServ are equally applicable to IPv6 as to IPv4 and IntServ and DiffServ are equally applicable to IPv6 and IPv4 and work
work in a similar fashion independent of IP version. Of these, similarly regardless of IP version. Of the two, typically only
typically only DiffServ has been implemented. DiffServ has been implemented.
Many bandwidth provisioning systems operate with IPv4 assumptions, Many bandwidth provisioning systems operate with IPv4 assumptions,
e.g., taking an IPv4 address or (set of) prefixes for which traffic e.g., taking an IPv4 address or (set of) prefixes for which traffic
is reserved or preferred. These systems require special attention is reserved or preferred. These systems require special attention
when introducing IPv6 support in the networks. when introducing IPv6 support in the networks.
6. Network and Service Operation Actions 6. Network and Service Operation Actions
The network and service operation actions fall into different The network and service operation actions fall into different
categories as listed below: categories as listed below:
- Set up IPv6 connectivity to upstream providers and peers. - Set up IPv6 connectivity to upstream providers and peers
- IPv6 network device configuration: for initial configuration - IPv6 network device configuration: for initial configuration
and updates and updates
- IPv6 network management - IPv6 network management
- IPv6 monitoring - IPv6 monitoring
- IPv6 customer management - IPv6 customer management
- IPv6 network and service operation security - IPv6 network and service operation security
Some of these items will require an IPv6 native transport layer to Some of these items will require an available IPv6 native transport
be available, whereas others will not. layer and others will not.
As a first step, network device configuration and regular network As a first step, network device configuration and regular network
management operations can be performed over an IPv4 transport, management operations can be performed over an IPv4 transport,
because IPv6 MIBs are also available over IPv4 transport. because IPv6 MIBs are also available. Nevertheless, some monitoring
Nevertheless, some monitoring functions require the availability of functions require the availability of IPv6 transport. This is the
IPv6 transport. This is the case, for instance, when ICMPv6 messages case, for instance, when ICMPv6 messages are used by the monitoring
are used by the monitoring applications. applications.
The current inability on many platforms to retrieve separate IPv4 and On many platforms, the current inability to retrieve separate IPv4
IPv6 traffic statistics from dual-stack interfaces for management and IPv6 traffic statistics from dual-stack interfaces for management
purposes by using SNMP is an issue. purposes by using SNMP is an issue.
As a second step, IPv6 transport can be provided for any of these As a second step, IPv6 transport can be provided for any of these
network and service operation facilities. network and service operation facilities.
7. Future Stages 7. Future Stages
At some point, an ISP might want to transition to a service that is At some point, an ISP may want to change to a service that is IPv6
IPv6 only, at least in certain parts of its network. Such a only, at least in certain parts of its network. This transition
transition creates many new cases into which continued maintenance of creates many new cases into which continued maintenance of the IPv4
the IPv4 service must be factored. Providing an IPv6-only service is service must be factored. Providing an IPv6-only service is not much
not much different from the dual IPv4/IPv6 service described in stage different from the dual IPv4/IPv6 service described in stage 3 except
3 except for the need to phase out the IPv4 service. The delivery of for the need to phase out the IPv4 service. The delivery of IPv4
IPv4 services over an IPv6 network and the phase out of IPv4 are left services over an IPv6 network and the phaseout of IPv4 are issues
for a subsequent document. Note that there are some services which left for a subsequent document. Note that there are some services
will need to maintain IPv4 connectivity (e.g., authorative and some which will need to maintain IPv4 connectivity (e.g., authorative and
recursive DNS servers [DNSGUIDE]). some recursive DNS servers [DNSGUIDE]).
8. Requirements for Follow-On Work 8. Requirements for Follow-On Work
This section tries to summarize the potential items requiring This section tries to summarize the potential items requiring
specification in the IETF. specification in the IETF.
Work items for which concrete specifications for which an approach Work items for which an approach was not yet apparent as of this
was not yet apparent as of this writing are: writing are as follows:
- A tunnel server/broker mechanisms for the cases where the customer - A tunnel server/broker mechanism, for the cases where the customer
connection networks cannot be upgraded needs to be specified connection networks cannot be upgraded, needs to be specified
[TUNREQS]. [TUNREQS].
- An IPv6 site multihoming mechanism (or multiple ones) need to be - An IPv6 site multihoming mechanism (or multiple ones) needs to be
developed. developed.
Work items which were already fast in progress, as of this writing, Work items which were already fast in progress, as of this writing,
are: are as follows:
- 6PE for MPLS was identified as a required mechanism, and this is - 6PE for MPLS was identified as a required mechanism, and this is
already in progress [BGPTUNNEL] already in progress [BGPTUNNEL].
- IS-IS for Multiple Topologies was noted as a helpful mechanism in - IS-IS for Multiple Topologies was noted as a helpful mechanism in
certain environments; however, it is possible to use alternative certain environments; however, it is possible to use alternative
methods to achieve the same end, so specifying this is not strictly methods to achieve the same end, so specifying this is not
required. strictly required.
- Any-source Multicast can be accomplished using Embedded-RP
[EMBEDRP], already in progress.
9. Example Networks 9. Example Networks
In this section, a number of different example networks are This section presents a number of different example networks. These
presented. These will not necessarily match any existing networks but will not necessarily match any existing networks but are intended to
are intended to be useful even in cases in which they do not be useful even when they do not correspond to specific target
correspond to specific target networks. The purpose of these examples networks. The purpose is to exemplify the applicability of the
is to exemplify the applicability of the transition mechanisms transition mechanisms described in this document to a number of
described in this document to a number of different situations with different situations with different prerequisites.
different prerequisites.
The sample network layout will be the same in all network examples. The sample network layout will be the same in each network example.
These should be viewed as specific representations of a generic This should be viewed as a specific representation of a generic
network with a limited number of network devices. A small number of network with a limited number of network devices. A small number of
routers have been used in the examples. However, because the network routers have been used in the examples. However, because the network
examples follow the implementation strategies recommended for the examples follow the implementation strategies recommended for the
generic network scenario, it should be possible to scale the examples generic network scenario, it should be possible to scale the examples
to fit a network with an arbitrary number, e.g. several hundreds or to fit a network with an arbitrary number, e.g., several hundreds or
thousands, of routers. thousands of routers.
The routers in the sample network layout are interconnected with each The routers in the sample network layout are interconnected with each
other as well as with another ISP. The connection to another ISP can other and with another ISP. The connection to another ISP can be
be either direct or through an exchange point. In addition to these either direct or through an exchange point. A number of customer
connections, a number of customer connection networks are also connection networks are also connected to the routers. Customer
connected to the routers. Customer connection networks can be, for connection networks can be, for example, xDSL or cable network
example, xDSL or cable network equipment. equipment.
ISP1 | ISP2 ISP1 | ISP2
+------+ | +------+ +------+ | +------+
| | | | | | | | | |
|Router|--|--|Router| |Router|--|--|Router|
| | | | | | | | | |
+------+ | +------+ +------+ | +------+
/ \ +----------------------- / \ +-----------------------
/ \ / \
/ \ / \
skipping to change at page 20, line 46 skipping to change at page 20, line 46
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
||||| ||||| ISP Network ||||| ||||| ISP Network
----|-----------|---------------------- ----|-----------|----------------------
| | Customer Networks | | Customer Networks
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
|Customer| |Customer| |Customer| |Customer|
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
Figure 3: ISP Sample Network Layout.
9.1 Example 1 Figure 3: ISP Sample Network Layout
9.1. Example 1
Example 1 presents a network built according to the sample network Example 1 presents a network built according to the sample network
layout with a native IPv4 backbone. The backbone is running IS-IS and layout with a native IPv4 backbone. The backbone is running IS-IS
IBGP as routing protocols for internal and external routes, and IBGP as routing protocols for internal and external routes,
respectively. Multiprotocol BGP is used to exchange routes over the respectively. Multiprotocol BGP is used to exchange routes over the
connections to ISP2 and the exchange point. Multicast using PIM-SM connections to ISP2 and the exchange point. Multicast using PIM-SM
routing is present. QoS using DiffServ is deployed. routing is present. QoS using DiffServ is deployed.
Access 1 is xDSL connected to the backbone through an access router. Access 1 is xDSL connected to the backbone through an access router.
The xDSL equipment, except for the access router, is considered to be The xDSL equipment, except for the access router, is considered to be
layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically
assigned to the customer using DHCP. No routing information is assigned to the customer with DHCP. No routing information is
exchanged with the customer. Access control and traceability are exchanged with the customer. Access control and traceability are
performed in the access router. Customers are separated into VLANs or performed in the access router. Customers are separated into VLANs
separate ATM PVCs up to the access router. or separate ATM PVCs up to the access router.
Access 2 is "fiber to the building or home" (FTTB/H) connected Access 2 is "fiber to the building or home" (FTTB/H) connected
directly to the backbone router. This connection is considered to be directly to the backbone router. This connection is considered
layer-3-aware, because it is using layer 3 switches and it performs layer-3-aware, because it uses layer 3 switches and performs access
access control and traceability through its layer 3 awareness by control and traceability through its layer 3 awareness by using DHCP
using DHCP snooping. IPv4 addresses are dynamically assigned to the snooping. IPv4 addresses are dynamically assigned to the customers
customers using DHCP. No routing information is exchanged with the with DHCP. No routing information is exchanged with the customer.
customer.
The actual IPv6 deployment might start by enabling IPv6 on a couple The actual IPv6 deployment might start by enabling IPv6 on a couple
of backbone routers, configuring tunnels between them (if not of backbone routers, configuring tunnels between them (if not
adjacent), and connecting to a few peers or upstream providers adjacent) and connecting to a few peers or upstream providers (either
(either through tunnels or at an internet exchange). through tunnels or at an internet exchange).
After a trial period, the rest of the backbone is upgraded to dual- After a trial period, the rest of the backbone is upgraded to dual-
stack, and IS-IS without multi-topology extensions (the upgrade order stack, and IS-IS, without multi-topology extensions (the upgrade
is considered with care) is used as an IPv6 and IPv4 IGP. When order is considered with care), is used as an IPv6 and IPv4 IGP.
upgrading, it's important to note that until IPv6 customers are During an upgrade until IPv6 customers are connected behind a
connected behind a backbone router, the convexity requirement is not backbone router, the convexity requirement is not critical: The
critical: the routers will just not be reachable using IPv6. That routers will just not be reachable with IPv6. Software supporting
is, software supporting IPv6 could be installed even though the IPv6 could be installed even though the routers would not be used for
routers would not be used for (customer) IPv6 traffic yet. That way, (customer) IPv6 traffic yet. That way, IPv6 could be enabled in the
IPv6 could be enabled in the backbone on a need-to-enable basis when backbone as needed.
needed.
Separate IPv6 BGP sessions are built, similar to IPv4. Multicast Separate IPv6 BGP sessions are built similarly to IPv4. Multicast
(through SSM and Embedded-RP) and DiffServ are offered at a later (through SSM and Embedded-RP) and DiffServ are offered at a later
phase of the network, e.g., after a year of stable IPv6 unicast phase of the network, e.g., after a year of stable IPv6 unicast
operations. operations.
Offering native service as quickly as possible is considered most Offering native service as quickly as possible is important. In the
important. However, a 6to4 relay may be provided in the meantime for meantime, however, a 6to4 relay may be provided in the meantime for
optimized 6to4 connectivity and it may also be combined with a tunnel optimized 6to4 connectivity and may also be combined with a tunnel
broker for extended functionality. xDSL equipment, operating as broker for extended functionality. Operating as bridges at Layer 2
bridges at Layer 2 only, does not require changes in CPE: IPv6 only, xDSL equipment does not require changes in CPE: IPv6
connectivity can be offered to the customers by upgrading the PE connectivity can be offered to the customers by upgrading the PE
router to IPv6. In the initial phase, only Router Advertisements are router to IPv6. In the initial phase, only Router Advertisements are
used; DHCPv6 Prefix Delegation can be added as the next step if no used; DHCPv6 Prefix Delegation can be added as the next step if no
other mechanisms are available. other mechanisms are available.
The FTTB/H access has to be upgraded to support access control and The FTTB/H access has to be upgraded to support access control and
traceability in the switches, probably by using DHCP snooping or a traceability in the switches, probably by using DHCP snooping or a
similar IPv6 capability, but it also has to be compatible with prefix similar IPv6 capability, but it also has to be compatible with prefix
delegation and not just address assignment. This could, however, lead delegation, not just address assignment. This could, however, lead
to the need to use DHCPv6 for address assignment. to the necessity to use DHCPv6 for address assignment.
9.2 Example 2 9.2. Example 2
In example 2 the backbone is running IPv4 with MPLS and is using OSPF In example 2, the backbone is running IPv4 with MPLS and is using
and IBGP are for internal and external routes respectively. The OSPF and IBGP for internal and external routes, respectively. The
connections to ISP2 and the exchange point run BGP to exchange connections to ISP2 and the exchange point run BGP to exchange
routes. Multicast and QoS are not deployed. routes. Multicast and QoS are not deployed.
Access 1 is a fixed line, e.g., fiber, connected directly to the Access 1 is a fixed line, e.g., fiber, connected directly to the
backbone. Routing information is in some cases exchanged with CPE at backbone. Routing information is in some cases exchanged with CPE at
the customer's site; otherwise static routing is used. Access 1 can the customer's site; otherwise static routing is used. Access 1 can
also be connected to a BGP/MPLS-VPN running in the backbone. also be connected to a BGP/MPLS-VPN running in the backbone.
Access 2 is xDSL connected directly to the backbone router. The xDSL Access 2 is xDSL connected directly to the backbone router. The xDSL
is layer 2 only, and access control and traceability are achieved is layer 2 only, and access control and traceability are achieved
through PPPoE/PPPoA. PPP also provides address assignment. No routing through PPPoE/PPPoA. PPP also provides address assignment. No
information is exchanged with the customer. routing information is exchanged with the customer.
IPv6 deployment might start with an upgrade of a couple of PE routers IPv6 deployment might start with an upgrade of a couple of PE routers
to support [BGPTUNNEL], because this will allow large-scale IPv6 to support [BGPTUNNEL], as this will allow large-scale IPv6 support
support without hardware or software upgrades in the core. In a later without hardware or software upgrades in the core. In a later phase,
phase native IPv6 traffic or IPv6 LSPs would be used in the whole native IPv6 traffic or IPv6 LSPs would be used in the whole network.
network. In that case IS-IS or OSPF could be used for the internal In this case, IS-IS or OSPF could be used for the internal routing,
routing, and a separate IPv6 BGP session would be run. and a separate IPv6 BGP session would be run.
For the fixed-line customers, the CPE has to be upgraded and prefix For the fixed-line customers, the CPE has to be upgraded, and prefix
delegation using DHCPv6 or static assignment would be used. An IPv6 delegation using DHCPv6 or static assignment would be used. An IPv6
MBGP session would be used when routing information has to be MBGP session would be used when routing information has to be
exchanged. In the xDSL case the same conditions for IP-tunneling as exchanged. In the xDSL case, the same conditions for IP-tunneling
in Example 1 apply. In addition to IP-tunneling an additional PPP apply as in Example 1. In addition to IP-tunneling, a PPP session
session can be used to offer IPv6 access to a limited number of can be used to offer IPv6 access to a limited number of customers.
customers. Later, when clients and servers have been updated, the Later, when clients and servers have been updated, the IPv6 PPP
IPv6 PPP session can be replaced with a combined PPP session for both session can be replaced with a combined PPP session for both IPv4 and
IPv4 and IPv6. PPP has to be used for address and prefix assignment. IPv6. PPP has to be used for address and prefix assignment.
9.3 Example 3 9.3. Example 3
A transit provider offers IP connectivity to other providers, but A transit provider offers IP connectivity to other providers, but not
not to end users or enterprises. IS-IS and IBGP are used internally to end users or enterprises. IS-IS and IBGP are used internally, and
and BGP externally. Its accesses connect Tier-2 provider cores. No BGP is used externally. Its accesses connect Tier-2 provider cores.
multicast or QoS is used. No multicast or QoS is used.
As this type of transit provider has a number of customers, which in As this type of transit provider has a number of customers, who have
turn have a large number of customers, it obtains an address a large number of customers in turn, it obtains an address allocation
allocation from a RIR. The whole backbone can be upgraded to dual- from an RIR. The whole backbone can be upgraded to dual-stack in a
stack in a reasonably rapid pace after a trial with a couple of reasonably short time after a trial with a couple of routers. IPv6
routers. IPv6 routing is performed using the same IS-IS process and routing is performed by using the same IS-IS process and separate
separate IPv6 BGP sessions. IPv6 BGP sessions.
The ISP provides IPv6 transit to its customers for free, as a The ISP provides IPv6 transit to its customers for free, as a
competitive advantage. It also provides, at the first phase only, a competitive advantage. It also provides, at the first phase only, a
configured tunnel service with BGP peering to the significant sites configured tunnel service with BGP peering to the significant sites
and customers (those with an AS number) which are the customers of and customers (those with an AS number) who are the customers of its
its customers whenever its own customer networks are not offering customers whenever its own customer networks are not offering IPv6.
IPv6. This is done both to introduce them to IPv6 and to create a This is done both to introduce them to IPv6 and to create a
beneficial side-effect: a bit of extra revenue is generated from its beneficial side effect: A bit of extra revenue is generated from its
direct customers as the total amount of transited traffic grows. direct customers as the total amount of transited traffic grows.
10. Security Considerations 10. Security Considerations
This document analyses scenarios and identifies some transition This document analyzes scenarios and identifies transition mechanisms
mechanisms that could be used for the scenarios. It does not that could be used for the scenarios. It does not introduce any new
introduce any new security issues. Security considerations of each security issues. Security considerations of each mechanism are
mechanism are described in the respective documents. described in the respective documents.
However, a few generic observations are in order. However, a few generic observations are in order.
o introducing IPv6 adds new classes of security threats or o Introducing IPv6 adds new classes of security threats or
requires adopting new protocols or operational models requires adopting new protocols or operational models than
than with IPv4; typically these are generic issues, and those for IPv4; typically these are generic issues, to be
to be further discussed in other documents, for example, discussed further in other documents, for example, [V6SEC].
[V6SEC].
o the more complex the transition mechanisms employed become, o The more complex the transition mechanisms employed become, the
the more difficult it will be to manage or analyze their more difficult it will be to manage or analyze their impact on
impact on security. Consequently, simple mechanisms are to security. Consequently, simple mechanisms are preferable.
be preferred.
o this document has identified a number of requirements for o This document has identified a number of requirements for
analysis or further work which should be explicitly considered analysis or further work that should be explicitly considered
when adopting IPv6: how to perform access control over when adopting IPv6: how to perform access control over shared
shared media or shared ISP customer connection media, media or shared ISP customer connection media, how to manage
how to manage the configuration management security on such the configuration management security on such environments
environments (e.g., DHCPv6 authentication keying), and (e.g., DHCPv6 authentication keying), and how to manage
how to manage customer traceability if stateless address customer traceability if stateless address autoconfiguration is
autoconfiguration is used. used.
11. Acknowledgements 11. Acknowledgments
This draft has greatly benefited from inputs by Marc Blanchet, Jordi This document has greatly benefited from input by Marc Blanchet,
Palet, Francois Le Faucheur, Ronald van der Pol and Cleve Mickles. Jordi Palet, Francois Le Faucheur, Ronald van der Pol, and Cleve
Mickles.
Special thanks to Richard Graveman and Michael Lambert for Special thanks to Richard Graveman and Michael Lambert for
proofreading the document. proofreading the document.
12. Informative References 12. Informative References
[EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of [EMBEDRP] Savola, P. and B. Haberman, "Embedding the Rendezvous
RP in IPv6 Multicast Address" - Point (RP) Address in an IPv6 Multicast Address", RFC
Work in progress 3956, November 2004.
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-ISIS:
ISIS: Multi Topology (MT) Routing in IS-IS" Multi Topology (MT) Routing in IS-IS", Work in
Work in progress Progress.
[RFC2858] Bates, T., Rekhter, Y., Chandra, R., Katz, D., [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
"Multiprotocol Extensions for BGP-4" "Multiprotocol Extensions for BGP-4", RFC 2858, June
RFC 2858 2000.
[RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing" Extensions for IPv6 Inter-Domain Routing", RFC 2545,
RFC 2545 March 1999.
[BCP3704] Baker, F., Savola, P., "Ingress Filtering for [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks" Multihomed Networks", BCP 84, RFC 3704, March 2004.
RFC 3704
[RFC3582] Abley, J., Black, B., Gill, V., "Goals for IPv6 Site- [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6
Multihoming Architectures" Site-Multihoming Architectures", RFC 3582, August
RFC 3582 2003.
[RFC3178] Hagino, J., Snyder, H., "IPv6 Multihoming Support at [RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at
Site Exit Routers" Site Exit Routers", RFC 3178, October 2001.
RFC 3178
[RFC3056] Carpenter, B., Moore, K., "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
via IPv4 Clouds" Domains via IPv4 Clouds", RFC 3056, February 2001.
RFC 3056
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865 RFC 2865, June 2000.
[BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., [BGPTUNNEL] De Clercq, J., Gastaud, G., Ooms, D., Prevost, S., Le
Le Faucheur, F., "Connecting IPv6 Islands across IPv4 Faucheur, F., "Connecting IPv6 Islands across IPv4
Clouds with BGP" Clouds with BGP", Work in Progress.
Work in progress
[DUAL ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., [DUAL-ACCESS] Shirasaki, Y., Miyakawa, S., Yamasaki, T., Takenouchi,
Takenouchi, A. A., "A Model of IPv6/IPv4 Dual Stack Internet Access
"A Model of IPv6/IPv4 Dual Stack Internet Access Service", Work in Progress.
Service"
Work in progress
[STEP] Savola, P. "Simple IPv6-in-IPv4 Tunnel Establishment [STEP] Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment
Procedure (STEP)" Procedure (STEP)", Work in Progress.
Work in progress
[TSP] Blanchet, M. "IPv6 Tunnel broker with Tunnel Setup [TSP] Blanchet, M., "IPv6 Tunnel Broker with Tunnel Setup
Protocol (TSP)" Protocol (TSP)", Work in Progress.
Work in progress
[TUNREQS] Durand, A., Parent, F. "Requirements for assisted [TUNREQS] Palet, J., Nielsen, K., Parent, F., Durand, A.,
tunneling" Suryanarayanan, R., and P. Savola, "Goals for
Work in progress Tunneling Configuration", Work in Progress, February
2005.
[UNMANEVA] Huitema, C., Austein, R., Satapati, S., [UNMANEVA] Huitema, C., Austein, R., Satapati, S., van der Pol,
van der Pol, R. R., "Evaluation of Transition Mechanisms for Unmanaged
"Evaluation of Transition Mechanisms for Unmanaged Networks", Work in Progress.
Networks"
Work in progress
[PROTO41] Palet, J., Olvera, C., Fernandez, D. "Forwarding [PROTO41] Palet, J., Olvera, C., Fernandez, D., "Forwarding
Protocol 41 in NAT Boxes" Protocol 41 in NAT Boxes", Work in Progress.
Work in progress
[V6SEC] Savola, P. "IPv6 Transition/Co-existence Security [V6SEC] Savola, P., "IPv6 Transition/Co-existence Security
Considerations" Considerations", Work in Progress.
Work in progress
[DNSGUIDE] Durand, A., Ihren, J. "DNS IPv6 transport operational [DNSGUIDE] Durand, A., Ihren, J., "DNS IPv6 transport operational
guidelines" guidelines", Work in Progress.
Work in progress
[TEREDO] Huitema, C. "Teredo: Tunneling IPv6 over UDP through [TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs" NATs", Work in Progress.
Work in progress
Appendix A: Convexity Requirements in Single Topology IS-IS
The single-topology IS-IS convexity requirements could be summarized,
from IPv4/6 perspective, as follows:
1) "any IP-independent path from an IPv4 router to any other IPv4
router must only go through routers which are IPv4-capable", and
2) "any IP-independent path from an IPv6 router to any other IPv6
router must only go through routers which are IPv6-capable".
As IS-IS is based upon CLNS, these are not trivially accomplished.
The single-topology IS-IS builds paths which are agnostic of IP
versions.
Consider an example scenario of 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 R2
Here the second requirement would not hold. 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.
Authors' Addresses Authors' Addresses
Mikael Lind Mikael Lind
TeliaSonera TeliaSonera
Vitsandsgatan 9B Vitsandsgatan 9B
SE-12386 Farsta, Sweden SE-12386 Farsta, Sweden
Email: mikael.lind@teliasonera.com
EMail: mikael.lind@teliasonera.com
Vladimir Ksinant Vladimir Ksinant
Thales Communications Thales Communications
160, boulevard de Valmy 160, boulevard de Valmy
92704 Colombes, France 92704 Colombes, France
Email: vladimir.ksinant@fr.thalesgroup.com
EMail: vladimir.ksinant@fr.thalesgroup.com
Soohong Daniel Park Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics. Mobile Platform Laboratory, SAMSUNG Electronics.
416, Maetan-3dong, Paldal-Gu, 416, Maetan-3dong, Paldal-Gu,
Suwon, Gyeonggi-do, Korea Suwon, Gyeonggi-do, Korea
Email: soohong.park@samsung.com
EMail: soohong.park@samsung.com
Alain Baudot Alain Baudot
France Telecom R&D France Telecom R&D Division
42, rue des coutures 42, rue des coutures
14066 Caen - FRANCE 14066 Caen - FRANCE
Email: alain.baudot@rd.francetelecom.com
EMail: alain.baudot@francetelecom.com
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo, Finland
EMail: psavola@funet.fi EMail: psavola@funet.fi
Intellectual Property Statement 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Acknowledgement
Copyright (C) The Internet Society (2004). 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."
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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.
Appendix A: Convexity Requirements in Single Topology IS-IS
The single-topology IS-IS convexity requirements could be summarized,
from IPv4/6 perspective, as follows:
1) "any IP-independent path from an IPv4 router to any other IPv4
router must only go through routers which are IPv4-capable", and
2) "any IP-independent path from an IPv6 router to any other IPv6
router must only go through routers which are IPv6-capable".
As IS-IS is based upon CLNS, these are not trivially accomplished.
The single-topology IS-IS builds paths which are agnostic of IP
versions.
Consider an example scenario of 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 R2
Here the second requirement would not hold. IPv6 packets from R1 to Funding for the RFC Editor function is currently provided by the
R2 (or vice versa) would go through R3, which does not support IPv6, Internet Society.
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.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/