draft-ietf-v6ops-isp-scenarios-analysis-00.txt   draft-ietf-v6ops-isp-scenarios-analysis-01.txt 
Internet-Draft M. Lind Internet Draft M. Lind
<draft-ietf-v6ops-isp-scenarios-analysis-00.txt> TeliaSonera <draft-ietf-v6ops-isp-scenarios-analysis-01.txt> TeliaSonera
Expires : May 2004 V. Ksinant V. Ksinant
6WIND 6WIND
D. Park S. Park
Samsung Electronics Samsung Electronics
A. Baudot A. Baudot
France Telecom France Telecom
December 2003 P. Savola
CSC/Funet
Expires: August 2004 February 2004
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
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document first describes different scenarios for the This document first describes different scenarios for the
introduction of IPv6 into an existing IPv4 ISP network without introduction of IPv6 into an ISP's existing IPv4 network without
disrupting the IPv4 service. Then, this document analyses these disrupting the IPv4 service. Then, this document analyses these
scenarios and evaluates the suitability of the already defined scenarios and evaluates the relevance of the already defined
transition mechanisms in this context. Known challenges are also transition mechanisms in this context. Known challenges are also
identified. identified.
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction................................................2
1.1 Goal and scope of the document..........................3 1.1 Goal and Scope of the Document...........................2
1.2 Terminology used........................................3 2. Brief Description of a Generic ISP Network..................3
2. Brief description of a generic ISP network....................4 3. Transition Scenarios........................................4
3. Transition scenarios..........................................6 3.1 Identification of Stages and Scenarios...................4
3.1 Identification of scenarios.............................6 3.2 Stages...................................................5
3.1.1 Assumptions............................................6 3.2.1 Stage 1 Scenarios: Launch..............................5
3.1.2 Customer requirements and ISP offerings................7 3.2.2 Stage 2a Scenarios: Backbone...........................6
3.1.3 Stage 1 Scenarios: Launch..............................8 3.2.3 Stage 2b Scenarios: Customer Connection................6
3.1.4 Stage 2a Scenarios: Backbone...........................8 3.2.4 Stage 3 Scenarios: Complete............................6
3.1.5 Stage 2b Scenarios: Customer connection................8 3.2.5 Stages 2a and 3: Combination Scenarios.................7
3.1.6 Stage 3 scenarios: Complete............................9 3.3 Transition Scenarios.....................................7
3.1.7 Stage 2a and 3 combination scenarios...................9 3.4 Actions Needed When Deploying IPv6 in an ISP's network...7
3.2 Transition Scenarios....................................9 4. Backbone Transition Actions.................................8
3.3 Actions needed when deploying IPv6 in an ISP network...10 4.1 Steps in Transitioning Backbone Networks.................8
4. Backbone transition actions..................................11 4.1.1 MPLS Backbone..........................................9
4.1 Steps in transitioning backbone networks...............11 4.2 Configuration of Backbone Equipment.....................10
4.2 Configuration of backbone equipment....................13 4.3 Routing.................................................10
4.3 Routing................................................13 4.3.1 IGP...................................................10
4.3.1 IGP...................................................13 4.3.2 EGP...................................................11
4.3.2 EGP...................................................14 4.3.3 Transport of Routing Protocols........................12
4.3.3 Routing protocols transport...........................15 4.4 Multicast...............................................12
4.4 Multicast..............................................15 5. Customer Connection Transition Actions.....................12
5. Customer connection transition actions.......................15 5.1 Steps in Transitioning Customer Connection Networks.....12
5.1 Steps in transitioning customer connection networks....15 5.2 Access Control Requirements.............................14
5.2 Access control requirements............................17 5.3 Configuration of Customer Equipment.....................15
5.3 Configuration of customer equipment....................17 5.4 Requirements for Traceability...........................16
5.4 Requirements for Traceability..........................18 5.5 Ingress Filtering in the Customer Connection Network....16
5.5 Multi-homing...........................................18 5.6 Multi-Homing............................................16
5.6 Ingress filtering in the customer connection network...19 5.7 Quality of Service......................................16
6. Network and service operation actions........................19 6. Network and Service Operation Actions......................17
7. Future Stages................................................20 7. Future Stages..............................................17
8. Example networks.............................................20 8. Example Networks...........................................18
8.1 Example 1..............................................22 8.1 Example 1...............................................19
8.2 Example 2..............................................22 8.2 Example 2...............................................21
8.3 Example 3..............................................23 8.3 Example 3...............................................21
9. Security Considerations......................................23 9. Security Considerations....................................22
10. Acknowledgements.............................................23 10. Acknowledgements...........................................22
11. Informative references.......................................23 11. Informative References.....................................22
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
to its customers. The new IPv6 service must be added to an already to its customers. The new IPv6 service must be added to an already
existing IPv4 service and the introduction of the IPv6 must not existing IPv4 service, and the introduction of IPv6 must not
interrupt this IPv4 service. The case of an IPv6-only service interrupt this IPv4 service.
provider is not addressed in this document.
An ISP offering an IPv4 service will find that there are different An ISP offering IPv4 service will find different ways to add IPv6 to
ways to add IPv6 to this service. This document discusses a small this service. This document discusses a small set of scenarios for
set of scenarios for the introduction of IPv6 in an ISP IPv4 the introduction of IPv6 into an ISP's IPv4 network. It evaluates the
network. It evaluates the suitability of the existing transition relevance of the existing transition mechanisms in the context of
mechanisms in the context of these deployment scenarios, and it these deployment scenarios, and points out the lack of functionality
points out the lack of functionality essential to the ISP operation essential to the ISP's operation of an IPv6 service.
of an IPv6 service..
The present document is focused on services that include both IPv6 The present document is focused on services that include both IPv6
and IPv4 and does not cover issues surrounding an IPv6-only service. and IPv4 and does not cover issues surrounding IPv6-only service.
It is also outside the scope of this document to describe different It is also outside the scope of this document to describe different
types of access or network technologies. types of access or network technologies.
1.2 Terminology used 2. Brief Description of a Generic ISP Network
This section defines and clarifies the terminology used in this A generic network topology for an ISP can be divided into two main
document: parts: the backbone network and the customer connection networks
connecting the customers. It includes, in addition to these, some
other building blocks such as network and service operations. The
additional building blocks used in this document are defined as
follows:
"CPE" : Customer Premise 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 network which 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 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 which is used by a : This is the part of the network used by a customer
customer when connecting to an ISP network. It when connecting to an ISP's network. It includes the
includes the CPEs, the last hop links and the parts CPE, the last hop link and the parts of the PE
of the PE interfacing to the last hop links. interfacing to the last hop link.
"Backbone" : "Backbone" : This is the rest of the ISP's network infrastructure.
This is the rest of the ISP 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 core, the core routers of the ISP, and the border
border routers used in order to exchange routing routers used to exchange routing information with
information with other ISPs (or other administrative other ISPs (or other administrative entities).
entities).
"Dual-stack network": "Dual-stack network":
A network which supports natively both IPv4 and A network that supports natively both IPv4 and
IPv6. IPv6.
2. Brief description of a generic ISP network It is noted that, in some cases (e.g., incumbent national or
A generic ISP network topology can be divided into two main parts;
the backbone network and the customer connection networks connecting
the customers.
The backbone is the part of the network that interconnects the
different customer connection networks and provides transport to the
rest of the Internet via exchange points or other means. The
backbone network can be built on different technologies but in this
document the only interest is whether it is capable of carrying IPv6
traffic natively or not. Since there is no clear definition of
"backbone", it is defined in this document as being all routers that
are a part of the same routed domain in the transport network. This
means that all routers up to (and including, at least partially) the
PE router are a part of the backbone.
The customer connection networks provide connectivity to enterprise
and private customers. Other ISPs might as well be customers and
connected to the ISP's customer connection network. As with the
backbone the absence or presence of native IPv6 capability is the
only thing of real interest in the customer connection network
technology.
It is noticeable that, in some cases (e.g. incumbent national or
regional operators), a given customer connection network may have regional operators), a given customer connection network may have
to be shared between different ISPs. According to the type of the to be shared between or among different ISPs. According to the type
customer connection network used (e.g. involving only layer 2 of customer connection network used (e.g., one involving only layer 2
devices, or involving non-IP technology), this constraint may result devices or one involving non-IP technology), this constraint may
in architectural considerations that may be relevant in this result in architectural considerations relevant to this document.
document.
"Network and service operation" building blocks refer to the basic
main functions needed for a regular backbone operation. This
building block is dealing with: network management, customers'
authentication and accounting, address assignment and naming. It
represents the minimum functions needed to provide a customer
service, referring to both network infrastructure operation, and
administrative management of customers.
It doesn't matter if these customer networks have a single node or a
large routed network. What is of interest is if routing information
is exchanged or not since it will affect the ISP's network. The
existence of customer premise equipment will also affect how a
service can be delivered. In addition to the ISP's actual network
components there are a lot of support and backend systems that have
to be considered.
The basic components in an ISP 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 & IX ) . / | \ \_Peering( Direct and IX )
. / | \ . / | \
. / | \ . / | \
. / | \ . / | \
---------- / ---------- \ ----------- ---------- / ---------- \ ----------
| Customer | / | Customer | \ | Customer | | Customer | / | Customer | \ | Customer |
|Connection|--/ |Connection| \--|Connection| |Connection|--/ |Connection| \--|Connection|
| 1 | | 2 | | 3 | | 1 | | 2 | | 3 |
---------- ---------- ---------- ---------- ---------- ----------
| | | ISP Network | | | ISP's Network
------------------------------------------------------- -------------------------------------------------------
| | | Customer Networks | | | Customers' Networks
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | | | | | | | |
|Customer| |Customer| |Customer| |Customer| |Customer| |Customer|
| | | | | | | | | | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 1: ISP network topology Figure 1: ISP Network Topology.
3. Transition scenarios
3.1 Identification of scenarios
This section describes different stages an ISP might consider when
introducing IPv6 connectivity in the existing IPv4 network and the
different scenarios that might occur in the respective stages.
The stages here are snapshots of an ISP's network with respect to
IPv6 maturity. Since an ISP's network is constantly evolving, a
stage is a measure of how far an ISP has come in turn of
implementing necessary functionality to offer IPv6 to the customers.
It is possible to freely transition between different stages.
However, a network segment can only be in one stage at a time but an
ISP network as a whole can be in different stages. There are
different transition paths between the first and final stage. The
transition between two stages does not have to be immediate but can
occur gradually.
Each stage has different IPv6 properties. An ISP can therefore,
based on the requirements it has, decide into which stage it will
transform its network.
This document is not aimed to cover very small or small ISPs or
hosting providers/data centers; only the scenarios applicable to the
ISPs eligible for a /32 IPv6 prefix allocation from a RIR are
covered.
3.1.1 Assumptions 3. Transition Scenarios
The stages are derived from the generic description of an ISP 3.1 Identification of Stages and Scenarios
network in section 2. A combination of different building blocks
that constitute an ISP environment will lead to a number of
scenarios, which an ISP can choose from. The scenarios of most
relevance to this document are considered to be the ones that in the
most efficient and feasible way maximize the ability for an ISP to
offer IPv6 to its customers.
The most predominant case today is considered to be an operator with This section describes different stages an ISP might consider when
a core and access IPv4 network delivering IPv4 service to a customer introducing IPv6 connectivity into its existing IPv4 network and the
that is running IPv4 as well. At some point in the future, it is different scenarios that might occur in the respective stages.
expected that the customer will want to have an IPv6 service, in
addition to the already existing IPv4 service. This IPv6 service may
be offered by the same ISP, or by a different one. Anyway the
challenge for the ISP is to deliver the requested IPv6 service over
the existing infrastructure and at the same time keep the IPv4
service intact.
3.1.2 Customer requirements and ISP offerings The stages here are snapshots of the ISP's network with respect to
IPv6 maturity. Because the ISP's network is continually evolving, a
stage is a measure of how far along the ISP has come in terms of
implementing the functionality necessary to offer IPv6 to the
customers.
Looking at the scenarios from the end customer's perspective there It is possible to transition freely between different stages.
might be a demand for three different services; the customer might Although a network segment can only be in one stage at a time, the
demand IPv4 service, IPv6 service or both services. This can lead to ISP's network as a whole can be in different stages. Different
two scenarios depending on the stage the ISP's network is in. transition paths can be followed from the first to the final stage.
The transition between two stages does not have to be instantaneous;
it can occur gradually.
If an ISP only offers IPv4 or IPv6 service and a customer wants to Each stage has different IPv6 properties. An ISP can, therefore,
connect a device or network that only supports one service and if based on its requirements, decide which set of stages it will follow
that service is not offered, it will lead to a dead-end. If the to transform its network.
customer or ISP instead connects a dual stack device it is possible
to circumvent the lack of the missing service in the customer
connection network by using some kind of tunneling mechanism. This
scenario will only be considered in the perspective of the ISP
offering a mechanism to bridge the customer connection and reach the
IPv6 backbone.
In the case where the customer connects a single stack device to a This document is not aimed to cover small ISPs, hosting providers, or
corresponding single stack customer connection network or when the data centers; only the scenarios applicable to ISPs eligible for a
customer connects a single stack device to a dual stack customer /32 IPv6 prefix allocation from a RIR are covered.
connection network is covered by the all over dual stack case.
Therefore, neither of these cases need further be explored
separately in this document but can be seen as a part of a full dual
stack case.
After eliminating a number of cases explained above, there are four 3.2 Stages
stages that are most probable and where an ISP will find its network
in. Which stage a network is in depends on whether or not some part
of the network previously has been upgraded to support IPv6 or if it
is easier to enable IPv6 in one part or another. For instance,
routers in the backbone might have IPv6 support or might be easily
upgradeable, while the hardware in the customer connection network
might have to be completely replaced in order to handle IPv6
traffic.
Note that in every stage except Stage 1, the ISP can offer both IPv4 The stages are derived from the generic description of an ISP's
and IPv6 services to the customer. network in Section 2. Combinations of different building blocks
that constitute an ISP's environment lead to a number of scenarios
from which the ISP can choose. The scenarios most relevant for this
document are the ones that maximize ISP's ability to offer IPv6 to
its customers in the most efficient and feasible way. The assumption
in all stages is that the ISP's goal is to offer both IPv4 and IPv6
to the customer.
The four most probable stages are: The four most probable stages are:
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 the ISP is able to upgrade current IPv4 network to 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 with simple tunnel mechanisms on also be implemented at a small cost by adding simple tunnel
the existing system. When designing a new network, Stage 3 might be mechanisms to the existing configuration. When designing a new
the first and last step since there are no legacy concerns. Absence network, Stage 3 might be the first and last step, because there are
of IPv6 capability in the network equipment can still be a limiting no legacy concerns. Nevertheless, the absence of IPv6 capability in
factor nevertheless. the network equipment can still be a limiting factor.
3.1.3 Stage 1 Scenarios: Launch Note that in every stage except Stage 1, the ISP can offer both IPv4
and IPv6 services to its customers.
The first stage is an IPv4 only ISP with an IPv4 customer. This is 3.2.1 Stage 1 Scenarios: Launch
the most common case today and has to be the starting point for the
introduction of IPv6. From this stage, an ISP can move (transition) The first stage is an IPv4-only ISP with an IPv4 customer. This is
to any other stage with the goal to offer IPv6 to its customer. the most common case today and the natural starting point for the
introduction of IPv6. From this stage, the ISP can move (transition)
from Stage 1 to any other stage with the goal of offering IPv6 to its
customer.
The immediate first step consists of getting a prefix allocation The immediate first step consists of getting a prefix allocation
(typically a /32) from the appropriate RIR according to allocation (typically a /32) from the appropriate RIR according to allocation
procedures. procedures.
3.1.4 Stage 2a Scenarios: Backbone 3.2.2 Stage 2a Scenarios: Backbone
Stage 2a is an ISP with customer connection networks that are IPv4 Stage 2a consists of an ISP with IPv4-only customer connection
only and a backbone that supports both IPv4 and IPv6. In particular, networks and a backbone that supports both IPv4 and IPv6. In
the ISP considers it possible to make the backbone IPv6 capable particular, the ISP has the possibility of making the backbone IPv6-
either through software or hardware upgrade, or a combination of capable through either software upgrades, hardware upgrades, or a
both. In this stage the customer should have support for both IPv4 combination of both.
and IPv6. The ISP has to provide IPv6 connectivity through its IPv4
customer connection networks.
In particular, the existence of NATs and firewalls in the path (at Since the customer connections are not yet upgraded, a tunneling
the CPE, or in the customer's network) need to be considered. mechanism has to be used to provide IPv6 connectivity through the
IPv4 customer connection networks. The customer can terminate the
tunnel at the CPE (if it has IPv6 support) or at each individual
device. In the former case, the CPE will then provide global IPv6
connectivity to all devices in the customer's network.
3.1.5 Stage 2b Scenarios: Customer connection 3.2.3 Stage 2b Scenarios: Customer Connection
Stage 2b is an ISP with a backbone network that is IPv4 and an Stage 2b consists of an ISP with an IPv4 backbone network and a
customer connection network that supports both IPv4 and IPv6. Since customer connection network that supports both IPv4 and IPv6. Because
the service to the customer is native IPv6 there is no requirement the service to the customer is native IPv6, the customer is not
for the customer to support both IPv4 and IPv6. This is the biggest required to support both IPv4 and IPv6. This is the biggest
difference in comparison to the previous stage. The need to difference in comparison with the previous stage. The need to
exchange IPv6 traffic or similar still exists but might be more exchange IPv6 traffic still exists but might be more complicated than
complicated than in the previous case since the backbone isn't IPv6 in the previous case, because the backbone is not IPv6-enabled. After
enabled. After completing stage 2b the original IPv4 backbone still completing Stage 2b, the original IPv4 backbone is unchanged. This
is unchanged. This doesn't imply that there is no IPv6 backbone just means that the IPv6 traffic is transported by either tunnelling over
that the IPv6 backbone is an overlay to or partially separated from the existing IPv4 backbone, or in an IPv6 overlay network more or
the IPv4 backbone. less separated from the IPv4 backbone.
Generally, the ISP will continue providing IPv4 connectivity; in Normally the ISP will continue to provide IPv4 connectivity; in
many cases private addresses and NATs will continue to be used. many cases private IPv4 addresses and NATs will continue to be used.
3.1.6 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 can be said to be the final step in introducing IPv6, at
least in the scope of this document. This is an all over IPv6 least within the scope of this document. This consists of ubiquitous
service with native support for IPv6 and IPv4 in both backbone and IPv6 service with native support for IPv6 and IPv4 in both backbone
customer connection networks. This stage is identical to the and customer connection networks. This stage is identical to the
previous stage in the customer's perspective since the customer previous stage from the customer's perspective, because the customer
connection network hasn't changed. The requirement for exchanging connection network has not changed. The requirement for exchanging
IPv6 traffic is identical to stage 2. IPv6 traffic is identical to Stage 2.
3.1.7 Stage 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 some do; and the some customer connections do not support IPv6, but others do; in both
backbone is dual-stack. cases the backbone is dual-stack.
This is equivalent to stage 2a, but requiring support for native This is equivalent to Stage 2a, but it requires support for native
IPv6 customer connections on some access technologies. IPv6 customer connections on some access technologies.
3.2 Transition Scenarios 3.3 Transition Scenarios
Given the different stages it is clear that the ISP has to be able Given the different stages, it is clear that an ISP has to be able
to transition from one stage to another. The initial stage, in this to transition from one stage to another. The initial stage, in this
document, is the IPv4 only service and network. The end stage is the document, is IPv4-only service and network. The end stage is dual
dual IPv4/IPv6 service and network. As mentioned in the scope, this IPv4/IPv6 service and network.
document does not cover the IPv6 only service and network and its
implications on IPv4 customers. This has nothing to do with the
usability of an IPv6 only service.
The transition starts out with the IPv4 ISP and then moves to one of
three choices. These choices are the different transition
scenarios. One way would be to upgrade the backbone first which
leads to stage 2a. Another way to go could be to upgrade the
customer connection network which leads to stage 2b. The final
possibility is to introduce IPv6 in both the backbone and customer
connections as needed which would lead to stage 3.
The choice is dependent on many different issues. For example it
might not be possible to upgrade the backbone or the customer
connection network without large investments in new equipment which
could lead to any of the two first choices. In another case it might
be easier to take the direct step to a complete IPv6/IPv4 network
due to routing protocol issues or similar.
If a partially upgraded network (stage 2a or 2b) was chosen as the The transition starts with an IPv4 ISP and then moves in one of
first step, a second step remains before the network is all over three directions. This choice corresponds to the different
native IPv6/IPv4. This is the transition to an all over dual stack transition scenarios. Stage 2a consists of upgrading the backbone
network. This step is perhaps not necessary for stage 2b with an first. Stage 2b consists of upgrading the customer connection
already native IPv6 service to the customer but might still occur network. Finally, Stage 3 consists of introducing IPv6 in both the
when the timing is right. For stage 2a it is more obvious that a backbone and customer connections as needed.
transition to a dual stack network is necessary since it has to be
done to offer a native IPv6 service.
As most of the ISPs keep evolving continuously their backbone IPv4 Because most of ISPs continually evolve their backbone IPv4 networks
networks (new firmware versions in the routers, new routers), they (firmware replacements in routers, new routers, etc.), they will be
will be able to get them IPv6 ready, without additional investment, able to get them ready for IPv6 without additional investment
except the staff training. It may be a slower transition path, but (except staff training). This may be a slower but still useful
useful since it allows an IPv6 introduction without any actual transition path, because it allows for IPv6 introduction without any
customer demand. This will probably be better than making everything actual customer demand. This may be superior to doing everything
at the last minute with a higher investment. at the last minute, which may entail a higher investment. However, it
is important to start considering (and requesting from the vendors)
IPv6 features in all new equipment from the start. Otherwise, the
time and effort to remove non-IPv6-capable hardware from the network
will be significant.
3.3 Actions needed when deploying IPv6 in an ISP network 3.4 Actions Needed When Deploying IPv6 in an ISP's network
When looking at the transitions described above, it appears that it Examination of the transitions described above reveals that it
is possible to split the work required by each transition in a small is possible to split the work required for each transition into a
set of actions. Each action is mostly independent from the others small set of actions. Each action is largely independent from the
and some actions may be common to several transitions. others, and some actions may be common to multiple transitions.
The analysis of the possible transitions leads to a small list of Analysis of the possible transitions leads to a small list of
actions: actions:
* backbone transition actions: * 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
action can be performed directly or through intermediate action can be performed directly or through intermediate
steps, steps.
* customer connection transition actions: * Actions required for customer connection transition:
- Connect IPv6 customers to an IPv6 backbone through an IPv4 - Connect IPv6 customers to an IPv6 backbone through an IPv4
network, network.
- Transform an IPv4 customer connection network into a dual- - Transform an IPv4 customer connection network into a dual-
stack one, stack one.
* network and service operation transition actions: * Actions required for network and service operation transition:
- configure IPv6 functions into either backbone or network
and service operation devices
- upgrade regular network management and monitoring
applications to take IPv6 into account
- [Network and service operation actions - To be completed.]
More detailed descriptions of each action follow. - Configure IPv6 functions into network components.
4. Backbone transition actions - Upgrade regular network management and monitoring
applications to take IPv6 into account.
4.1 Steps in transitioning backbone networks - Extend customer management (e.g., RADIUS) mechanisms
to be able to supply IPv6 prefixes and other information
to customers.
In terms of physical equipment, backbone networks consist mainly in - Enhance accounting, billing, etc. to work with IPv6
core and edge high-speed routers. Border routers provide peering as needed. (Note: if dual-stack service is offered, this
with other providers. Filtering, routing policy and policing type may not be necessary.)
- Implement security for network and service operation.
Sections 4, 5, and 6 contain detailed descriptions of each action.
4. Backbone Transition Actions
4.1 Steps in Transitioning Backbone Networks
In terms of physical equipment, backbone networks consist mainly of
high-speed core and edge routers. Border routers provide peering
with other providers. Filtering, routing policy, and policing
functions are generally managed on border routers. functions are generally managed on border routers.
The initial step is an IPv4-only backbone, and the final step is a The initial step is an IPv4-only backbone, and the final step is a
whole dual-stack backbone. In between, intermediate steps may be completely dual-stack backbone. In between, intermediate steps may be
identified: identified:
Tunnels Tunnels Tunnels Tunnels
IPv4-only ----> or ---> or + DS -----> Full DS IPv4-only ----> or ---> or + DS -----> Full DS
IPv6 dedicated IPv6 dedicated routers dedicated IPv6 dedicated IPv6 routers
links links links links
The first step involves tunnels or dedicated links but existing Figure 2: Migration Path.
routers are left unchanged. Only a small set of routers then have
IPv6 capabilities. Configured tunnels are adequate for use during The first step involves tunnels or dedicated links but leaves
existing routers unchanged. Only a small set of routers then have
IPv6 capabilities. Using configured tunnels is adequate during
this step. this step.
When MPLS is already deployed in the backbone, it may be desirable In the second step, some dual stack routers are added, progressively,
to provide IPv6-over-MPLS connectivity. However, the problem is that to this network.
setting up an IPv6 Label Switched Path (LSP) requires some signaling
through the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs,
but this would require a software upgrade in the MPLS core network.
A workaround is to use BGP for signaling and/or to perform IPv6-
over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, for
example, as described in [BGPTUNNEL]. There seem to be multiple
possibilities, some of which may be more preferable than others.
More analysis is needed in order to determine which are the best
approach(es):
1) require that MPLS networks deploy native IPv6 support or The final step is reached when all or almost all routers are dual-
use configured tunneling for IPv6. stack.
2) require that MPLS networks support setting up IPv6 LSPs, For many reasons (technical, financial, etc.), the ISP may progress
and IPv6 connectivity is set up using them, or configured step by step or jump directly the final one. One of the important
tunneling is used. criteria in planning this evolution is the number of IPv6
customers the ISP expects during its initial deployments. If few
customers connect to the original IPv6 infrastructure, then the ISP
is likely to remain in the initial steps for a long time.
3) use only configured tunneling over the IPv4 LSPs; this In short, each intermediate step is possible, but none is mandatory.
seems practical with small-scale deployments when the
number of tunnels is low.
4) use something like [BGPTUNNEL] to perform IPv6-over- 4.1.1 MPLS Backbone
IPv4/MPLS encapsulation for IPv6 connectivity.
In the second step, some dual stack routers are added in this If MPLS is already deployed in the backbone, it may be desirable
network in a progressive manner. to provide IPv6-over-MPLS connectivity. However, setting up an IPv6
Label Switched Path (LSP) requires signaling through the MPLS
network; both LDP and RSVP-TE can set up IPv6 LSPs, but this would
require a software upgrade in the MPLS core network. An alternative
approach is to use BGP for signaling or to perform, for example,
IPv6-over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation,
as described in [BGPTUNNEL]. Some of the multiple possibilities are
preferable to others depending on the specific environment under
consideration. More analysis is needed, case by case, to determine
the best approach or approaches:
The final stage is reached when all or most routers are dual-stack. 1) Require that MPLS networks deploy native IPv6 support or
use configured tunneling for IPv6.
According to many reasons (technical, financial, etc), an ISP may 2) Require that MPLS networks support setting up IPv6 LSPs,
move forward from step to step or reach directly the final one. One and set up IPv6 connectivity by using either these or
of the important criteria in this evolution is the number of IPv6 configured tunneling.
customers the ISP gets on its initial deployments. If few customers
connect to the first IPv6 infrastructure, then the ISP is likely to
remain on the initial steps for a long time.
In short, each step remains possible, but no one is mandatory. 3) Use only configured tunneling over IPv4 LSPs; this seems
practical with small-scale deployments having few tunnels.
4.2 Configuration of backbone equipment 4) Use [BGPTUNNEL] or something comparable to perform IPv6-over-
IPv4/MPLS encapsulation for IPv6 connectivity.
Approaches 1 and 2 are the most attractive if the ISP is willing to
perform an upgrade to the MPLS network. Approach 3 does not require
any upgrades but may lack scalability. Approach 4 may be economically
attractive for an operator who does not wish to upgrade the MPLS
network and has a large-scale deployment.
MPLS networks have typically been deployed to facilitate services
such as Provider-Provisioned VPNs. Software upgrades are commonplace
in MPLS networks. No particular reason exists to avoid adding IPv6
functionality, except if the vendor is unable to provide sufficient
IPv6 forwarding capability (e.g., line-speed) in the existing
hardware (independent of the capabilities for handling MPLS frames).
Therefore, recommending mechanisms like [BGPTUNNEL] as the final
solution might not be such a good idea.
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 protocols parameters, configuration mainly deals with routing protocol parameters,
interface addresses, loop-back addresses, ACLs... interface addresses, loop-back addresses, ACLs, etc.
These IPv6 parameters are not supposed to be automatically These IPv6 parameters are not supposed to be configured
configured. automatically.
4.3 Routing 4.3 Routing
ISPs need routing protocols to advertise the reachability and to ISPs need routing protocols to advertise reachability and to
find the shortest working paths both internally and externally. find the shortest working paths, both internally and externally.
OSPFv2 and IS-IS are typically used as an IPv4 IGP. OSPFv2 and IS-IS are typically used as an IPv4 IGP. RIPv2 is not
RIPv2 is typically not in use in operator networks. typically used in operator networks. BGP is the only IPv4 EGP.
BGP is the only IPv4 EGP. Static routes are used in both. Static routes also are 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
results in having an IPv6 topology different from the IPv4 topology. results in having an IPv6 topology different from its IPv4 topology.
For example, some links or interfaces may be dedicated to IPv4-only For example, some links or interfaces may be dedicated to IPv4-only
or IPv6-only traffic, or some routers may be dual-stack while some or IPv6-only traffic, or some routers may be dual-stack whereas
others maybe single stacked (IPv4 or IPv6). In this case, the others may be IPv4 or IPv6 only. In this case, routing protocols must
routing must be able to manage multiple topologies. be able to 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 less must be made: either OSPFv3 or IS-IS for IPv6. RIPng is less
appropriate in many contexts and is not discussed here. The IGP appropriate in many contexts and is not discussed here. The IGP
typically includes the routers' point-to-point and loop-back typically includes the routers' point-to-point and loop-back
addresses. addresses.
The most important decision to make is whether one wishes to have The most important decision is whether one wishes to have separate
separate routing protocol processes for IPv4 and IPv6. Having them routing protocol processes for IPv4 and IPv6. Separating them
separate requires more memory and CPU for route calculations e.g. requires more memory and CPU for route calculations, e.g., when the
when the links flap. On the other hand, the separation provides a links flap. On the other hand, separation provides a certain measure
better reassurance that if problems come up with IPv6 routing, they of assurance that if problems arise with IPv6 routing, they will not
will not affect IPv4 routing protocol at all. In the first phases affect IPv4 the routing protocol at all. In the initial phases, if
if it is uncertain whether joint IPv4/IPv6 networks work as it is uncertain whether joint IPv4-IPv6 networking is working as
intended, having separate processes may be desirable and easier to intended, running separate processes may be desirable and easier to
manage. manage.
Thus the combinations are: Thus the possible combinations are:
- 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
- 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. In simpler networks or extensions [MTISIS] have been implemented. In simpler networks or
with careful planning of IS-IS link costs, it is possible to keep with careful planning of IS-IS link costs, it is possible to keep
even non-congruent IPv4/IPv6 topologies "convex". even incongruent IPv4/IPv6 topologies "convex."
Therefore, the use of same process is recommended especially for Therefore, the use of same process is recommended especially for
large ISPs which intend to deploy, in the short-term, a fully dual- large ISPs intending to deploy, in the short-term, a fully dual-
stack backbone infrastructure. If the topologies are not similar stack backbone infrastructure. If the topologies will not be similar
in the short term, two processes (or Multi-topology IS-IS in the short term, two processes (or Multi-topology IS-IS
extensions) are recommended. extensions) are recommended.
The IGP is not typically used to carry customer prefixes or external The IGP is not typically used to carry customer prefixes or external
routes. Internal BGP (iBGP), as described in the next section, is routes. Internal BGP (iBGP), as described in the next section, is
most often deployed in all routers to spread the other routing most often deployed in all routers to distribute such other routing
information. information.
As some of the simplest devices, e.g. CPE routers, may not implement Because some of the simplest devices, e.g., CPE routers, may not
other routing protocols than RIPng, in some cases it may be implement routing protocols other than RIPng, in some cases it may
necessary to also run RIPng in a limited fashion in addition to also be necessary to run RIPng in addition to one of the above IGPs,
another IGP, and somehow redistribute the routing information to the at least in a limited fashion, and somehow to redistribute routing
other routing protocol(s). 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 BGP and external BGP sessions. BGP with Multi-protocol extensions [RFC 2858] can be used for IPv6
[RFC 2545]. These extensions enable exchanging both IPv6 routing
BGP can be used for IPv6 with Multi-protocol extensions [RFC 2858], information and establishing BGP sessions using TCP over IPv6.
[RFC 2545]. These enable exchanging both IPv6 routing information
as establishing BGP sessions using TCP over IPv6.
It is possible to use a single BGP session to advertise both IPv4 It is possible to use a single BGP session to advertise both IPv4
and IPv6 prefixes between two peers. However, typically, separate and IPv6 prefixes between two peers. However, typically, separate
BGP sessions are used. BGP sessions are used.
4.3.3 Routing protocols transport 4.3.3 Transport of Routing Protocols
IPv4 routing information should be carried by IPv4 transport and IPv4 routing information should be carried by IPv4 transport and
IPv6 one by IPv6 for several reasons: similarly IPv6 routing information by IPv6 for several reasons:
* The IPv6 connectivity may work when the IPv4 one is down (or * IPv6 connectivity may work when IPv4 connectivity is down
vice-versa). (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 logical topology and the IPv6 one may be different * The IPv4 logical topology and the IPv6 one may be different,
because, the administrator may want to use different metric because the administrator may want to assign different metrics
values for one physical link for load balancing or tunnels to a physical link for load balancing or tunnels may be used.
may be used.
4.4 Multicast 4.4 Multicast
Currently, IPv6 multicast is not a strong concern for most ISPs. Currently, IPv6 multicast is not a major concern for most ISPs.
However, some of them consider deploying it. Multicast is achieved However, some of them are considering deploying it. Multicast is
using PIM-SM and PIM-SSM protocols. These also work with IPv6. achieved using the PIM-SM and PIM-SSM protocols. These also work with
IPv6.
Information about multicast sources is exchanged using MSDP in IPv4, Information about multicast sources is exchanged using MSDP in IPv4,
but it is not defined, on purpose, for IPv6. An alternative but MSDP is intentionally not defined for IPv6. Instead, one should
mechanism is to use only PIM-SSM or an alternative mechanism for use only PIM-SSM or an alternative mechanism for conveying the
conveying the information [EMBEDRP]. information [EMBEDRP].
To be completed. send feedback/text!
5. Customer connection transition actions 5. Customer Connection Transition Actions
5.1 Steps in transitioning customer connection networks 5.1 Steps in Transitioning Customer Connection Networks
customer connection networks are generally composed of a large Customer connection networks are generally composed of a small set of
number of CPEs connected to a small set of PEs. Transitioning this PEs connected to a large set of CPEs. Transitioning this
infrastructure to IPv6 can be made in several steps, but some ISPs infrastructure to IPv6 can be accomplished in several steps, but some
may avoid some of the steps depending on their perception of risks. ISPs, depending on their perception of the risks, may avoid some of
the steps.
Connecting IPv6 customers to an IPv6 backbone through an IPv4 Connecting IPv6 customers to an IPv6 backbone through an IPv4
network can be considered as a first careful step taken by an ISP in network can be considered as a first careful step taken by an ISP to
order to provide IPv6 services to its IPv4 customers. More, some provide IPv6 services to its IPv4 customers. In addition, some
ISPs also provide IPv6 services to customers who get their IPv4 ISPs may also provide IPv6 services to customers who get their IPv4
services from another ISP. services from another ISP.
This IPv6 service can be provided by using tunneling techniques. The This IPv6 service can be provided by using tunneling techniques. The
tunnel may terminate at the CPE corresponding to the IPv4 service or tunnel may terminate at the CPE corresponding to the IPv4 service or
in some other part of the customer's infrastructure (for instance, in some other part of the customer's infrastructure (for instance,
on an IPv6 specific CPE or even on a host). 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, Teredo... tunnels with tunnel broker, 6to4, Teredo, etc.
The selection of one candidate depends largely on the presence or The selection of one candidate depends largely on the presence or
not of NATs between the two tunnel end-points, and whether the absence of NATs between the two tunnel end-points and whether the
user's IPv4 tunnel end-point address is static or dynamic. In most user's IPv4 tunnel end-point address is static or dynamic. In most
cases, 6to4 and ISATAP are incompatible with NATs and an UDP cases, 6to4 and ISATAP are incompatible with NATs, and UDP
encapsulation for configured tunnels has not been specified. encapsulation for configured tunnels has not been specified.
Firewalls in the way can also break these types of tunnels. The However, NAT traversal can be avoided if the NAT supports
administrator of the firewall will have to create a hole for the forwarding protocol-41 [PROTO41].
tunnel. It is not a big deal as long as the firewall is controlled
either by the customer or the ISP, which is almost always the case.
An ISP has practically two kinds of customers in the customer Firewalls in the path can also break these types of tunnels. The
connection networks: small end users (mostly "unmanaged networks"; administrator of the firewall needs to create a hole for the
home and SOHO users), and others. The former category typically has tunnel. This is usually manageable, as long as the firewall is
a dynamic IPv4 address which is often NATted; a reasonably static controlled by either the customer or the ISP, which is almost always
address is also possible. The latter category typically has static the case.
IPv4 addresses, and at least some of them are public; however, NAT
traversal or configuring the NAT may be required to reach an
internal IPv6 access router, though.
Tunneling consideration for small and end sites are discussed in When the CPE is performing NAT or firewall functions, terminating the
[UNMANCON], that may identify solutions relevant to the first tunnels directly at the CPE typically simplifies the scenario
category of unmanaged network. These solutions will be further considerably, avoiding the NAT and firewall traversal. If such an
discussed within an ISP context, when available. approach is adopted, the CPE has to support the tunneling mechanism
used, or be upgraded to do so.
For the second category, usually: In practice, an ISP has two kinds of customers in its customer
connection networks: small end users (mostly unmanaged networks--
home and SOHO users) and others. The former category typically uses
a dynamic IPv4 address, which is often non-routable; a reasonably
static address is also possible. The latter category typically has
static IPv4 addresses, and at least some of them are public; however,
NAT traversal or configuration may be required to reach an internal
IPv6 access router.
* Configured tunnels as-is are a good solution when an NAT is not in Tunneling consideration for small end sites are discussed in
the way and the IPv4 end-point addresses are static. A mechanism to [UNMANCON] and [UNMANEVA]. These identify solutions relevant to the
punch through NATs or to forward packets through it may be desirable first category of unmanaged networks.
in some scenarios. If fine-grained access control is needed, an
authentication protocol needs to be used. The connectivity mechanisms can be categorized as "managed" or
"opportunistic." The former consist of native service or a
configured tunnel (with or without a tunnel broker); the latter
include 6to4 and, e.g., Teredo; they provide "short-cuts" between
nodes using the same mechanisms and are available without contracts
with the ISP.
The ISP may offer opportunistic services, mainly a 6to4 relay,
especially as a test when no "real" service is offered yet. At the
later phases, ISPs might also deploy 6to4 relays or Teredo servers
(or similar) to optimize their customers' connectivity to 6to4 or
Teredo nodes.
Most interesting are the managed services. When dual-stack is not an
option, a form of tunneling must be used. When configured tunneling
is not an option (e.g., due to dynamic IPv4 addressing), some form of
automation has to be used. The options are basically either to deploy
an L2TP architecture (whereby the customers would run L2TP clients
and PPP over it to initiate IPv6 sessions) or to deploy a tunnel
configuration service. The prime candidates for tunnel configuration
are STEP [STEP] and TSP [TSP], which are not analyzed further in this
document.
For connecting larger customers:
* Dual-stack access service is often a realistic possibility since
the customer network is managed.
* Configured tunnels, as-is, are a good solution when a NAT is not in
the way and the IPv4 end-point addresses are static. In this
scenario, NAT traversal is not typically required. If fine-grained
access control is needed, an authentication protocol needs to be
used.
* A tunnel brokering solution, to help facilitate the set-up of a * A tunnel brokering solution, to help facilitate the set-up of a
bi-directional tunnel, has been proposed: the Tunnel Set-up bi-directional tunnel, has been proposed: the Tunnel Set-up
Protocol. Whether this is the right way needs to be determined. Protocol. Whether this is the right approach needs to be
determined.
* Automatic tunneling mechanisms such as 6to4 or Teredo are not * Automatic tunneling mechanisms such as 6to4 or Teredo are not
applicable in this scenario. suggested in this scenario.
Some other ISPs may take a more direct approach and avoid the use of Other ISPs may take a more direct approach and avoid the use of
tunnels as much as possible. tunnels as much as possible.
Note that when the customers use dynamic IPv4 addresses, the Note that when customers use dynamic IPv4 addresses, the
tunneling techniques may be more difficult at the ISP's end, tunneling techniques may be more difficult to deploy at the ISP's
especially if a protocol not including authentication (like PPP for end, especially if a protocol including authentication (like PPP for
IPv6) 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
with tunneling mechanisms. with tunneling mechanisms.
5.2 Access control requirements 5.2 Access Control Requirements
Access control is usually required in ISP networks because the ISPs Access control is usually required in ISP networks, because the ISPs
need to control to who they are giving access. For instance, it is need to control to whom they are granting access. For instance, it is
important to check if the user who tries to connect is really a important to check whether the user who tries to connect is really a
valid customer. In some cases, it is also important for billing valid customer. In some cases, it is also important for billing.
purposes.
However, an IPv6 specific access control is not always required. However, IPv6-specific access control is not always required.
This is for instance the case when a customer of the IPv4 service This is the case, for instance, when a customer of the IPv4 service
has automatically access to the IPv6 service. Then, the IPv4 access has automatically access to IPv6 service. Then, the IPv4 access
control also gives access to the IPv6 services. control also provides access to the IPv6 services.
When the provider does not wish to give to its IPv4 customers When a provider does not wish to give its IPv4 customers
automatically access to IPv6 services, a specific access control for automatic access to IPv6 services, specific IPv6 access control must
IPv6 must be performed in parallel to the IPv4 one. It does not mean be performed in parallel with the IPv4 access control. This does not
that a different user authentication must be performed for IPv6, but imply that different user authentication must be performed for IPv6,
the authentication process may lead to different results for IPv4 but merely that the authentication process may lead to different
and IPv6 access. results 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 traffic related to an IPv6 service can be transported over Radius traffic related to IPv6 service can be transported over
IPv4. IPv4.
5.3 Configuration of customer equipment 5.3 Configuration of Customer Equipment
The customer connection networks are composed of CPEs and PEs. The customer connection networks are composed of PE and CPE(s).
Usually, each PE connects a large number of CPEs 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 or
more. The configuration of CPEs is an heavy task for the ISP and more. The configuration of CPE is, in general, a difficult task for
this is even made harder as the configuration must be done remotely. the ISP, and even more so in this case, because configuration must be
In this context, the use of auto-configuration mechanisms is very done remotely. In this context, the use of auto-configuration
beneficial, even if manual configuration is still an option. mechanisms is beneficial, even if manual configuration is still an
option.
The parameters that usually need to be automatically provided to the The parameters that usually need to be provided to customers
customers are: automatically are:
- 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),
- Some other parameters such as the address of an NTP server - Possibly other parameters, e.g., the address of a NTP server.
may also be needed sometimes.
When access control is required on the ISP network, DHCPv6 can When user identification is required on the ISP's network, DHCPv6 may
provide the configuration parameters. This is discussed more in be used to provide configurations otherwise either DHCPv6 or a
details in [DUAL ACCESS]. stateless mechanism can be used. This is discussed in more detail in
[DUAL ACCESS].
When access control is not required (unusual case), a stateless Note that when the customer connection network is shared between the
mechanism could be used, but no standard definition exists at the users or the ISPs, and not just a point-to-point link, authenticating
moment. the configuration of the parameters (esp. prefix delegation) requires
further study.
As long as IPv4 service is available alongside of IPv6, no critical
need exists to be able to autoconfigure IPv6 parameters (except for
the prefix) in the CPE-- IPv4 settings work as well.
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 has also to be available for IPv6 traffic. in their networks. This also has to be available for IPv6 traffic,
This means that specific IPv6 address or prefix has to be tied to a which means that a specific IPv6 address or prefix has to be tied to
certain customer, or that records of which customer had which a certain customer, or that records of which customer had which
address/prefix must be maintained. This also applies to the address or prefix must be maintained. 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 this in a database. It can also be physical connection and storing this in a database. It can also be
done by assigning a static address or refix to the customer. done by assigning a static address or prefix to the customer.
For any traceability to be useful, ingress filtering must be 5.5 Ingress Filtering in the Customer Connection Network
deployed towards all the customers.
5.5 Multi-homing Ingress filtering must be deployed towards the customers, everywhere,
to ensure traceability, to prevent DoS attacks using spoofed
addresses, to prevent illegitimate access to the management
infrastructure, etc.
Customers may desire multihoming or multi-connecting for a number of Ingress filtering can be done, for example, by using access lists or
Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
described in [BCP38UPD].
5.6 Multi-Homing
Customers may desire multi-homing or multi-connecting for a number of
reasons [RFC3582]. reasons [RFC3582].
Multihoming to more than one ISP is a subject still under debate. Multi-homing to more than one ISP is a subject still under debate.
Deploying multiple addresses from each ISP and using the addresses Deploying multiple addresses from each ISP and using the addresses
of the ISP when sending traffic to that ISP is at least one working of the ISP when sending traffic to that ISP is at least one working
model; in addition, tunnels may be used for robustness [RFC3178]. model; in addition, tunnels may be used for robustness [RFC3178].
Currently, there are no provider-independent addresses for end- Currently, there are no provider-independent addresses for end-
sites. sites.
Multi-connecting more than once to just one ISP is a simple Multi-connecting more than once to just one ISP is a simple
practice, and this can be done e.g. with BGP with public or private practice, and this can be done, e.g., by using BGP with public or
AS numbers and a prefix assigned to the customer. private AS numbers and a prefix assigned to the customer.
To be further defined as the multihoming situation gets clearer. 5.7 Quality of Service
5.6 Ingress filtering in the customer connection network In most networks, quality of service in one form or another is
important.
Ingress filtering must be deployed everywhere towards the customers, Naturally, the introduction of IPv6 should not impair existing
to ensure traceability, prevent DoS attacks using spoofed addresses, Service Level Agreements (SLAs) or similar quality reassurances.
prevent illegitimate access to the management infrastructure, etc.
The ingress filtering can be done for example using access lists or Depending on the deployment of the IPv6 service, the service could
Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are be best-effort, at least initially, even if the IPv4 service had a
described in [BCP38UPD]. SLA.
6. Network and service operation actions Both IntServ and DiffServ are equally applicable in IPv6 as well as
in IPv4 and work in a similar fashion. Of these, typically only
DiffServ has been implemented.
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 listed below: categories as listed below:
- IPv6 network devices 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
- built-in "network and service operation" IPv6 security - IPv6 network and service operation security
Some of these actions will require an IPv6 native transport layer to Some of these items will require an IPv6 native transport layer to
be available, while some other will not. be available, whereas others will not.
In a first step, network devices configuration and regular network As a first step, network device configuration and regular network
management operations can be performed over an IPv4 transport, as management operations can be performed over an IPv4 transport,
IPv6 MIBs are also available over IPv4 transport. because IPv6 MIBs are also available over IPv4 transport.
Nevertheless, some monitoring functions require the availability of
IPv6 transport. This is the case, for instance, when ICMPv6 messages
are used by the monitoring applications.
Nevertheless, some monitoring functions require IPv6 transport The current inability to get IPv4 and IPv6 traffic statistics for
availability. This is for instance the case when ICMP messages are management purposes by using SNMP separately from dual-stack
used by the monitoring applications. interfaces is an issue.
In 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.
[To be completed, send feedback/text!]
7. Future Stages 7. Future Stages
After a while the ISP might want to transition to a service that is At some point, an ISP might want to transition to a service that is
IPv6 only, at least in certain parts of the network. This IPv6 only, at least in certain parts of its network. This
transition creates a lot of new cases in which to factor in how to transition creates a lot of new cases into which it must factor how
maintain the IPv4 service. Providing an IPv6 only service is not to maintain the IPv4 service. Providing an IPv6-only service is not
much different than the dual IPv4/IPv6 service described in stage 3 much different from the dual IPv4/IPv6 service described in stage 3
except from the need to phase out the IPv4 service. The delivery of except for the need to phase out the IPv4 service. The delivery of
IPv4 services over an IPv6 network and the phase out is left for a IPv4 services over an IPv6 network and the phase out of IPv4 are left
future document. for a subsequent document.
8. Example networks 8. Example Networks
In this section, a number of different network examples are In this section, a number of different network examples are
presented. They are only example networks and will not necessary presented. These are only example networks and will not necessarily
match to any existing networks. Nevertheless, the examples will match any existing networks. Nevertheless, the examples are intended
hopefully be useful even in the cases when they do not match the be useful even in cases in which they do not match specific target
target networks. The purpose of the example networks is to exemplify networks. The purpose of the example networks is to exemplify
the applicability of the transition mechanisms described in this the applicability of the transition mechanisms described in this
document on a number of different example networks with different document to a number of different situations with different
prerequisites. prerequisites.
The example network layout will be the same in all network examples. The sample network layout will be the same in all network examples.
The networks examples are to be seen as a specific representation of The network examples should be viewed as specific representations of
the generic network with a limited number of network devices. An a generic network with a limited number of network devices. A small
arbitrary number (in this case 7) of routers have been selected to number of routers have been used in the network examples. However,
represent the network examples. However, since the network examples because the network examples follow the implementation strategies
follow the implementation strategies recommended for the generic recommended for the generic network scenario, it should be possible
network scenario, it should be possible to scale the example to fit to scale the examples to fit a network with an arbitrary number, e.g.
a network with an arbitrary number, e.g. several hundreds or several hundreds or thousands, of routers.
thousands, of routers.
The routers in the sample network layout are interconnected with each
other as well as with another ISP. The connection to another ISP can
be either direct or through an exchange point. In addition to these
connections, a number of customer connection networks are also
connected to the routers. Customer connection networks can be, for
example, xDSL or cable network equipment.
The routers in the example are interconnected with each other as
well as with another ISP. The connection to another ISP can either
be a direct connection or through an exchange point. In addition to
these connections, there are also a number of customer connection
networks connected to the routers. customer connection networks are
normally connected to the backbone via access routers, but can in
some cases be directly connected to the backbone routers. As
described earlier in the generic network scenarios, the customer
connection networks are used to connect the customers. customer
connection networks can, for example, be xDSL or cable network
equipment.
|
ISP1 | ISP2 ISP1 | ISP2
+------+ | +------+ +------+ | +------+
| | | | | | | | | |
|Router|--|--|Router| |Router|--|--|Router|
| | | | | | | | | |
+------+ | +------+ +------+ | +------+
/ \ +----------------------- / \ +-----------------------
/ \ / \
/ \ / \
+------+ +------+ +------+ +------+
skipping to change at page 21, line 47 skipping to change at page 19, line 39
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
||||| ||||| ISP Network ||||| ||||| ISP Network
----|-----------|---------------------- ----|-----------|----------------------
| | Customer Networks | | Customer Networks
+--------+ +--------+ +--------+ +--------+
| | | | | | | |
|Customer| |Customer| |Customer| |Customer|
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
Figure 2: ISP network example Figure 3: ISP Sample Network Layout.
8.1 Example 1 8.1 Example 1
In example 1 a network built according to the example topology is Example 1 presents a network built according to the sample network
present with a native IPv4 backbone, the routers. The backbone is layout with a native IPv4 backbone. The backbone is running IS-IS and
running IS-IS and IBGP as routing protocol for internal and external IBGP as routing protocols for internal and external routes,
routes respectively. In the connection to ISP2 and the exchange respectively. MBGP is used to exchange routes over the connections to
point MBGP is used to exchange routes. Multicast is present and is ISP2 and the exchange point. Multicast using PIM-SM routing is
using PIM-SM routing. QoS is present and is using DiffServ. present. QoS using DiffServ is deployed.
Access 1 is xDSL, connected to the backbone through an access Access 1 is xDSL connected to the backbone through an access
router. The xDSL equipment, except for the access router, is router. The xDSL equipment, except for the access router, is
considered to be layer 2 only, e.g. Ethernet or ATM. IPv4 addresses considered to be layer 2 only, e.g., Ethernet or ATM. IPv4 addresses
are dynamically assigned to the customer using DHCP. No routing are dynamically assigned to the customer using DHCP. No routing
information is exchanged with the customer. Access control and information is exchanged with the customer. Access control and
traceability is done in the access router. Customers are separated traceability are preformed in the access router. Customers are
in VLANs or separate ATM PVCs up to the access router. separated into VLANs or separate ATM PVCs up to the access router.
Access 2 is Fiber to the building/home connected directly to the Access 2 is Fiber to the building or home (FTTB/H) connected directly
backbone router. The FTTB/H is considered to be layer 3 aware and to the backbone router. This is considered to be layer-3-aware,
performs access control and traceability through its layer 3 because it is using layer 3 switches and it performs access control
awareness. IPv4 addresses are dynamically assigned to the customers and traceability through its layer 3 awareness by using DHCP
snooping. IPv4 addresses are dynamically assigned to the customers
using DHCP. No routing information is exchanged with the customer. using DHCP. No routing information is exchanged with the customer.
The actual IPv6 deployment might start by enabling IPv6 on a couple
of backbone routers, configuring tunnels between them (if not
adjacent), and connecting to a few peers or upstream providers
(either through tunnels or at an internet exchange).
After a trial period, the rest of the backbone is upgraded to dual-
stack, and IS-IS without multi-topology extensions (the upgrade order
is considered with care) is used as an IPv6 and IPv4 IGP. When
upgrading, it's important to note that until IPv6 customers are
connected behind a backbone router, the convexity requirement is not
critical: the routers just will not be able to be reached using IPv6.
That is, a software supporting IPv6 could be installed even though
the routers would not be used for (customer) IPv6 traffic yet. That
way, IPv6 could be enabled in the backbone on a need-to-enable basis
when needed.
Separate IPv6 BGP sessions are built, similar to IPv4. Multicast
(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
operations.
Customers (with some exceptions) are not connected using a tunnel
broker, because offering native service faster is considered more
important -- and then there will not be unnecessary parallel
infrastructures to tear down later on. However, a 6to4 relay is
provided in the meantime for optimized 6to4 connectivity. xDSL
equipment, operating as bridges at Layer 2 only, do not require
changes in CPE: IPv6 connectivity can be offered to the customers by
upgrading the PE router to IPv6. In the initial phase, only Router
Advertisements are used; DHCPv6 Prefix Delegation can be added as the
next step if no other mechanisms are available.
The FTTB/H access has to be upgraded to support access control and
traceability in the switches, probably by using DHCP snooping or a
similar IPv6 capability, but it also has to be compatible with prefix
delegation and not just address assignment. This could, however, lead
to the need to use DHCPv6 for address assignment.
8.2 Example 2 8.2 Example 2
In example 2 the backbone is running IPv4 with MPLS. Routing In example 2 the backbone is running IPv4 with MPLS and is using OSPF
protocols used are OSPF and IBGP for internal and external routes. and IBGP are for internal and external routes respectively. The
In the connection to ISP2 and the exchange point BGP is used to connection to ISP2 and the exchange point run BGP to exchange routes.
exchange routes. Multicast and QoS are not present. Multicast and QoS are not deployed.
Access 1 is a fixed line access, e.g. fiber, connected directly to Access 1 is a fixed line, e.g., fiber, connected directly to the
the backbone. CPE is present at the customer and routing information backbone. Routing information is in some cases exchanged with CPE at
is in some cases exchanged otherwise static routing is used. Access the customer's site; otherwise static routing is used. Access 1 can
1 can also be connected to BGP/MPLS-VPN running in the backbone. also be connected to 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 3 aware. Addresses are dynamically assigned using DHCP. is layer 2 only, and access control and traceability are achieved
Access control is achieved on the physical layer and traceability is through PPPoE/PPPoA. PPP also provides address assignment. No routing
achieved using DHCP snooping. No routing information is exchanged information is exchanged with the customer.
with the customer.
IPv6 deployment might start with an upgrade of a couple of PE routers
to support [BGPTUNNEL], because this will allow large-scale IPv6
support without hardware or software upgrades in the core. In a later
phase, perhaps years later, IPv6 traffic would run natively in the
whole network. In that case IS-IS or OSPF could be used for the
internal routing, and a separate IPv6 BGP session would be run.
For the fixed-line customers the CPE has to be upgraded and prefix
delegation using DHCPv6 or static assignment would be used. An IPv6
MBGP session would be used when routing information has to be
exchanged. In the xDSL case the same conditions for IP-tunneling as
in Example 1 apply. In addition to IP-tunneling an additional PPP
session can be used to offer IPv6 access to a limited number of
customers. Later, when clients and servers have been updated, the
IPv6 PPP session can be replaced with a combined PPP session for both
IPv4 and IPv6. PPP has to be used for address and prefix assignment.
8.3 Example 3 8.3 Example 3
A transit provider offers IP connectivity to other providers, but A transit provider offers IP connectivity to other providers, but
not to end users or enterprises. IS-IS and IBGP is used internally not to end users or enterprises. IS-IS and IBGP are used internally
and BGP externally. Its accesses connect Tier-2 provider cores. No and BGP externally. Its accesses connect Tier-2 provider cores. No
multicast or QoS is used. multicast or QoS is used.
Even though the RIR policies on getting IPv6 prefixes require the
assignment of at least 200 /48 prefixes to the customers, this type
of transit provider obtains an allocation nonetheless, as the number
of customers their customers serve is significant. The whole backbone
can be upgraded to dual-stack in a reasonably rapid pace after
trialing it with a couple of routers. IPv6 routing is performed
using the same IS-IS and separate IPv6 BGP sessions.
The ISP provides IPv6 transit to its customers for free, as a
competitive advantage. It also provides, at the first phase only, a
configured tunnel service with BGP peering to the significant sites
and customers (those with an AS number) which are the customers of
its customers whenever its own customer networks are not offering
IPv6. 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
direct customers as the total amount of transited traffic grows.
9. Security Considerations 9. Security Considerations
This document analyses scenarios and identifies some transition This document analyses scenarios and identifies some transition
mechanisms that could be used for the scenarios. It does not mechanisms that could be used for the scenarios. It does not
introduce any new security issues. Security considerations of each introduce any new security issues. Security considerations of each
mechanism are described in the respective documents. mechanism are described in the respective documents.
However, a few generic observations are in order.
o introducing IPv6 adds new classes of security threats or
requires adopting new protocols or operational models
than with IPv6; typically these are generic issues, and
to be further discussed in other documents, for example,
[V6SEC].
o the more complex the transition mechanisms employed become,
the more difficult it will be to manage or analyze their
impact on security; consequently, simple mechanisms are to
be preferred.
o this document has identified a number of requirements for
analysis or further work which should be explicitly considered
when adopting IPv6: how to perform access control over
shared media or shared ISP customer connection media,
how to manage the configuration management security on such
environments (e.g., DHCPv6 authentication keying), and
how to manage customer traceability if stateless address
autoconfiguration is used.
10. Acknowledgements 10. Acknowledgements
This draft has greatly benefited from inputs by Pekka Savola, Marc This draft has greatly benefited from inputs by Marc Blanchet, Jordi
Blanchet, Jordi Palet. Palet, Francois Le Faucheur and Cleve Mickles. Special thanks to
Richard Graveman for proofreading the document.
11. Informative references 11. Informative References
[EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of [EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of
RP in IPv6 Multicast Address" - RP in IPv6 Multicast Address" -
draft-ietf-mboned-embeddedrp-00.txt Work in progress
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M- [MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-
ISIS: Multi Topology (MT) Routing in IS-IS" ISIS: Multi Topology (MT) Routing in IS-IS"
draft-ietf-isis-wg-multi-topology-06.txt Work in progress
[RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz, [RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz,
"Multiprotocol Extensions for BGP-4" "Multiprotocol Extensions for BGP-4"
RFC 2858 RFC 2858
[RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol [RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing" Extensions for IPv6 Inter-Domain Routing"
RFC 2545 RFC 2545
[BCP38UPD] F. Baker, P. Savola "Ingress Filtering for [BCP38UPD] F. Baker, P. Savola "Ingress Filtering for
Multihomed Networks" Multihomed Networks"
draft-savola-bcp38-multihoming-update-01.txt Work in progress
[RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site- [RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site-
Multihoming Architectures" Multihoming Architectures"
RFC 3582 RFC 3582
[RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at [RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at
Site Exit Routers" Site Exit Routers"
RFC 3178 RFC 3178
[BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost, [BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost,
F. Le Faucheur "Connecting IPv6 Islands across IPv4 F. Le Faucheur "Connecting IPv6 Islands across IPv4
Clouds with BGP" Clouds with BGP"
draft-ooms-v6ops-bgp-tunnel-00.txt draft-ooms-v6ops-bgp-tunnel-00.txt
[DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi [DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi
"A Model of IPv6/IPv4 Dual Stack Internet Access "A Model of IPv6/IPv4 Dual Stack Internet Access
Service" Service"
draft-shirasaki-dualstack-service-02.txt Work in progress
[UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations [UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations
for IPv6 Tunneling Solutions in Small End Sites" for IPv6 Tunneling Solutions in Small End Sites"
draft-chown-v6ops-unmanaged-connectivity-00 Work in progress
[UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol,
"Evaluation of Transition Mechanisms for Unmanaged
Networks"
Work in progress
[PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding
Protocol 41 in NAT Boxes"
Work in progress
[V6SEC] P. Savola, "IPv6 Transition/Co-existence Security
Considerations"
Work in progress
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
skipping to change at page 25, line 15 skipping to change at page 24, line 36
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
42, rue des coutures 42, rue des coutures
14066 Caen - FRANCE 14066 Caen - FRANCE
Email: alain.baudot@rd.francetelecom.com Email: alain.baudot@rd.francetelecom.com
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
Intellectual Property Statement Intellectual Property Statement
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 or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described 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; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
 End of changes. 

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