draft-ietf-v6ops-isp-scenarios-analysis-01.txt   draft-ietf-v6ops-isp-scenarios-analysis-02.txt 
Internet Draft M. Lind Internet Draft M. Lind
<draft-ietf-v6ops-isp-scenarios-analysis-01.txt> TeliaSonera <draft-ietf-v6ops-isp-scenarios-analysis-02.txt> TeliaSonera
V. Ksinant V. Ksinant
6WIND Thales 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: August 2004 February 2004
Expires: October 2004 April 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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............................6 3.2.4 Stage 3 Scenarios: Complete............................6
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...7 3.4 Actions Needed When Deploying IPv6 in an ISP's network...7
4. Backbone Transition Actions.................................8 4. Backbone Transition Actions.................................8
4.1 Steps in Transitioning Backbone Networks.................8 4.1 Steps in the Transition of Backbone Networks.............8
4.1.1 MPLS Backbone..........................................9 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...................................................10 4.3.1 IGP...................................................10
4.3.2 EGP...................................................11 4.3.2 EGP...................................................12
4.3.3 Transport of Routing Protocols........................12 4.3.3 Transport of Routing Protocols........................12
4.4 Multicast...............................................12 4.4 Multicast...............................................12
5. Customer Connection Transition Actions.....................12 5. Customer Connection Transition Actions.....................12
5.1 Steps in Transitioning Customer Connection Networks.....12 5.1 Steps in the Transition of Customer Connection Networks.12
5.2 Access Control Requirements.............................14 5.1.1 Small end sites.......................................14
5.1.2 Large end sites.......................................14
5.2 User Authentication/Access Control Requirements.........15
5.3 Configuration of Customer Equipment.....................15 5.3 Configuration of Customer Equipment.....................15
5.4 Requirements for Traceability...........................16 5.4 Requirements for Traceability...........................16
5.5 Ingress Filtering in the Customer Connection Network....16 5.5 Ingress Filtering in the Customer Connection Network....16
5.6 Multi-Homing............................................16 5.6 Multihoming.............................................16
5.7 Quality of Service......................................16 5.7 Quality of Service......................................17
6. Network and Service Operation Actions......................17 6. Network and Service Operation Actions......................17
7. Future Stages..............................................17 7. Future Stages..............................................18
8. Example Networks...........................................18 8. Example Networks...........................................18
8.1 Example 1...............................................19 8.1 Example 1...............................................19
8.2 Example 2...............................................21 8.2 Example 2...............................................21
8.3 Example 3...............................................21 8.3 Example 3...............................................21
9. Security Considerations....................................22 9. Security Considerations....................................22
10. Acknowledgements...........................................22 10. Acknowledgements...........................................22
11. Informative References.....................................22 11. Informative References.....................................22
1. Introduction 1. Introduction
skipping to change at page 2, line 50 skipping to change at page 3, line 4
8.1 Example 1...............................................19 8.1 Example 1...............................................19
8.2 Example 2...............................................21 8.2 Example 2...............................................21
8.3 Example 3...............................................21 8.3 Example 3...............................................21
9. Security Considerations....................................22 9. Security Considerations....................................22
10. Acknowledgements...........................................22 10. Acknowledgements...........................................22
11. Informative References.....................................22 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 and global address space to its customers. The new IPv6 service must
existing IPv4 service, and the introduction of IPv6 must not be added to an already existing IPv4 service, and the introduction of
interrupt this IPv4 service. IPv6 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 the
relevance of the existing transition mechanisms in the context of relevance of the existing transition mechanisms in the context of
these deployment scenarios, and points out the lack of functionality these deployment scenarios, and points out the lack of essential
essential to the ISP's operation of an IPv6 service. functionality in these methods to the ISP's operation 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 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.
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 the customer connection networks parts: the backbone network and customer connection networks. It
connecting the customers. It includes, in addition to these, some includes, in addition to these, some other building blocks such as
other building blocks such as network and service operations. The network and service operations. The additional building blocks used
additional building blocks used in this document are defined as in this document are defined as follows:
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
skipping to change at page 4, line 51 skipping to change at page 5, line 4
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 that 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 the implementing the functionality necessary to offer IPv6 to its
customers. customers.
It is possible to transition freely between different stages. It is possible for a transition to occur freely between different
Although a network segment can only be in one stage at a time, the stages. Although a network segment can only be in one stage at a
ISP's network as a whole can be in different stages. Different time, the ISP's network as a whole can be in different stages.
transition paths can be followed from the first to the final stage. Different transition paths can be followed from the first to the
The transition between two stages does not have to be instantaneous; final stage. The transition between two stages does not have to be
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. An ISP can, therefore,
based on its requirements, decide which set of stages it will follow based on its requirements, decide which set of stages it will follow
to transform its network. and in what order to transform its network.
This document is not aimed to cover small ISPs, hosting providers, or This document is not aimed at covering small ISPs, hosting providers,
data centers; only the scenarios applicable to ISPs eligible for a or data centers; only the scenarios applicable to ISPs eligible for
/32 IPv6 prefix allocation from a RIR are covered. at least a /32 IPv6 prefix allocation from a 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 constitute an ISP's environment lead to a number of scenarios that constitute an ISP's environment lead to a number of scenarios
from which the ISP can choose. The scenarios most relevant for this from which the ISP can choose. The scenarios most relevant to this
document are the ones that maximize ISP's ability to offer IPv6 to document are those that maximize ISP's ability to offer IPv6 to its
its customers in the most efficient and feasible way. The assumption customers in the most efficient and feasible way. The assumption in
in all stages is that the ISP's goal is to offer both IPv4 and IPv6 all stages is that the ISP's goal is to offer both IPv4 and IPv6 to
to the customer. 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, 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
skipping to change at page 5, line 50 skipping to change at page 6, line 4
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 designing a new
network, Stage 3 might be the first and last step, because there are network, Stage 3 might be the first and 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 the natural starting point for the
introduction of IPv6. From this stage, the ISP can move (transition) introduction of IPv6. From this stage, the ISP can move (undergo a
from Stage 1 to any other stage with the goal of offering IPv6 to its transition) from Stage 1 to any other stage with the goal of offering
customer. IPv6 to its customer.
The immediate first step consists of getting a prefix allocation The immediate first step consists of obtaining a prefix allocation
(typically a /32) from the appropriate RIR according to allocation (typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC,
procedures. ARIN, LACNIC, RIPE, ...) according to allocation procedures.
3.2.2 Stage 2a Scenarios: Backbone 3.2.2 Stage 2a Scenarios: Backbone
Stage 2a consists of an ISP with IPv4-only customer connection Stage 2a deal with an ISP with IPv4-only customer connection networks
networks and a backbone that supports both IPv4 and IPv6. In and a backbone that supports both IPv4 and IPv6. In particular, the
particular, the ISP has the possibility of making the backbone IPv6- ISP has the possibility of making the backbone IPv6-capable through
capable through either software upgrades, hardware upgrades, or a either software upgrades, hardware upgrades, or a combination of
combination of both. both.
Since the customer connections are not yet upgraded, a tunneling Since the customer connections have not yet been upgraded, a
mechanism has to be used to provide IPv6 connectivity through the tunneling mechanism has to be used to provide IPv6 connectivity
IPv4 customer connection networks. The customer can terminate the through the IPv4 customer connection networks. The customer can
tunnel at the CPE (if it has IPv6 support) or at each individual terminate the tunnel at the CPE (if it has IPv6 support) or at some
device. In the former case, the CPE will then provide global IPv6 set of devices internal to its network. That is, either the CPE or a
connectivity to all devices in the customer's network. device inside the network could provide global IPv6 connectivity to
the rest of the devices in the customer's network.
3.2.3 Stage 2b Scenarios: Customer Connection 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. Because
the service to the customer is native IPv6, the customer is not the service to the customer is native IPv6, the customer is not
required to support both IPv4 and IPv6. This is the biggest required to support both IPv4 and IPv6. This is the biggest
difference in comparison with the previous stage. The need to difference in comparison to the previous stage. The need to exchange
exchange IPv6 traffic still exists but might be more complicated than IPv6 traffic still exists but might be more complicated than in the
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 by either tunnelling 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; in Normally the ISP will continue to provide IPv4 connectivity using
many cases private IPv4 addresses and NATs will continue to be used. 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
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 can be said to be the final step in introducing IPv6, at
least within the scope of this document. This consists of ubiquitous least within the scope of this document. This stage consists of
IPv6 service with native support for IPv6 and IPv4 in both backbone ubiquitous IPv6 service with native support for IPv6 and IPv4 in both
and customer connection networks. This stage is identical to the backbone and customer connection networks. It is identical to the
previous stage from the customer's perspective, because the customer previous stage from the customer's perspective, because the customer
connection network has not 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.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 is equivalent to Stage 2a, but it requires support for native This scenario is equivalent to Stage 2a, but it requires support for
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 transition from one stage to another. The initial stage, in this to make a transition from one stage to another. The initial stage in
document, is IPv4-only service and network. The end stage is dual this document is IPv4-only service and network. The end stage is dual
IPv4/IPv6 service and network. 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 directions. This choice corresponds to the different three directions. This choice corresponds to the different
transition scenarios. Stage 2a consists of upgrading the backbone transition scenarios. Stage 2a consists of upgrading the backbone
first. Stage 2b consists of upgrading the customer connection first. Stage 2b consists of upgrading the customer connection
network. Finally, Stage 3 consists of introducing IPv6 in both the network. Finally, Stage 3 consists of introducing IPv6 in both the
backbone and customer connections as needed. backbone and customer connections as needed.
Because most of ISPs continually evolve their backbone IPv4 networks Because most ISP backbone IPv4 networks continually evolve (firmware
(firmware replacements in routers, new routers, etc.), they will be replacements in routers, new routers, etc.), they can be made ready
able to get them ready for IPv6 without additional investment for IPv6 without additional investment (except staff training). This
(except staff training). This may be a slower but still useful may be a slower but still useful transition path, because it allows
transition path, because it allows for IPv6 introduction without any for the introduction of IPv6 without any actual customer demand. This
actual customer demand. This may be superior to doing everything process may be superior to doing everything at the last minute, which
at the last minute, which may entail a higher investment. However, it may entail a higher investment. However, it is important to consider
is important to start considering (and requesting from the vendors) (and to request from vendors) IPv6 features in all new equipment from
IPv6 features in all new equipment from the start. Otherwise, the the outset. Otherwise, the time and effort required to remove non-
time and effort to remove non-IPv6-capable hardware from the network IPv6-capable hardware from the network may be significant.
will 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 possible to split the work required for each transition into a is possible to split the work required for each transition into a
small set of actions. Each action is largely independent from the small set of actions. Each action is largely independent of the
others, and some actions may be common to multiple transitions. others, 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.
skipping to change at page 8, line 41 skipping to change at page 8, line 46
- Enhance accounting, billing, etc. to work with IPv6 - Enhance accounting, billing, etc. to work with IPv6
as needed. (Note: if dual-stack service is offered, this as needed. (Note: if dual-stack service is offered, this
may not be necessary.) may 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 Transitioning 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 consist mainly 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.
The initial step is an IPv4-only backbone, and the final step is a In the beginning, an ISP has an IPv4-only backbone. In the end, the
completely dual-stack backbone. In between, intermediate steps may be backbone is completely dual-stack. In between, intermediate steps may
identified: be identified:
Tunnels Tunnels Tunnels Tunnels
IPv4-only ----> or ---> or + DS -----> Full DS IPv4-only ----> or ---> or + DS -----> Full DS
dedicated IPv6 dedicated IPv6 routers dedicated IPv6 dedicated IPv6 routers
links links links links
Figure 2: Migration 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. Using 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 dual-
stack. 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 the final one. One of the important step by step or jump directly to the final one. One important
criteria in planning this evolution is the number of IPv6 criterion in planning this evolution is the number of IPv6 customers
customers the ISP expects during its initial deployments. If few the ISP expects during its initial deployments. If few customers
customers connect to the original IPv6 infrastructure, then the ISP connect to the original IPv6 infrastructure, then the ISP is likely
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 provide IPv6-over-MPLS connectivity. However, setting up an IPv6 to 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 would network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might
require a software upgrade in the MPLS core network. An alternative require upgrade/change in the MPLS core network.
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:
1) Require that MPLS networks deploy native IPv6 support or An alternative approach is to use BGP for signaling or to perform,
use configured tunneling for IPv6. for example IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some of
the multiple possibilities are preferable to others depending on the
specific environment under consideration; the approaches seem to be:
2) Require that MPLS networks support setting up IPv6 LSPs, 1) Require that MPLS networks deploy native IPv6 routing and
and set up IPv6 connectivity by using either these or forwarding support.
configured tunneling.
3) Use only configured tunneling over IPv4 LSPs; this seems 2) Require that MPLS networks support native routing and setting
practical with small-scale deployments having few tunnels. up of IPv6 LSPs, used for IPv6 connectivity.
4) Use [BGPTUNNEL] or something comparable to perform IPv6-over- 3) Use only configured tunneling over IPv4 LSPs.
IPv4/MPLS encapsulation for IPv6 connectivity.
Approaches 1 and 2 are the most attractive if the ISP is willing to 4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation
perform an upgrade to the MPLS network. Approach 3 does not require for IPv6 connectivity.
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 1) and 2) are clearly the best target approaches. However, 1) may
such as Provider-Provisioned VPNs. Software upgrades are commonplace not be possible if the ISP is not willing to add IPv6 support in
in MPLS networks. No particular reason exists to avoid adding IPv6 the network, or if the installed equipment is not capable of high
functionality, except if the vendor is unable to provide sufficient performance native IPv6 forwarding. 2) may not be possible if the
IPv6 forwarding capability (e.g., line-speed) in the existing ISP is not willing or able to add IPv6 LSP set-up support in the MPLS
hardware (independent of the capabilities for handling MPLS frames). control plane.
Therefore, recommending mechanisms like [BGPTUNNEL] as the final
solution might not be such a good idea. Approach 4) can be used as an interim mechanism where other options
are unfeasible or undesirable for the reasons discussed above.
Approach 3) is roughly equivalent to 4) except that it does not
require additional mechanisms but may lack scalability in the 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, ACLs, etc. interface addresses, loop-back addresses, ACLs, etc.
These IPv6 parameters are not supposed to be configured These IPv6 parameters need to be configured manually.
automatically.
4.3 Routing 4.3 Routing
ISPs need routing protocols to advertise 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. RIPv2 is not Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is
typically used in operator networks. BGP is the only IPv4 EGP. not usually used in service provider networks. BGP is the only IPv4
Static routes also are used in both cases. EGP. 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 its 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 whereas or IPv6-only traffic, or some routers may be dual-stack whereas
others may be IPv4 or IPv6 only. In this case, routing protocols must others may be IPv4 or IPv6 only. In this case, routing protocols must
be able to understand and cope with 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 not
appropriate in many contexts and is not discussed here. The IGP appropriate in most contexts and is therefore not discussed here. The
typically includes the routers' point-to-point and loop-back IGP typically 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. On the other hand, separation provides a certain measure
of assurance that if problems arise with IPv6 routing, they will not of assurance that if problems arise with IPv6 routing, they will not
affect IPv4 the routing protocol at all. In the initial phases, if affect the IPv4 routing protocol at all. In the initial phases, if
it is uncertain whether joint IPv4-IPv6 networking is working as it is uncertain whether joint IPv4-IPv6 networking is working as
intended, running separate processes may be desirable and easier to intended, running separate processes may be desirable and easier to
manage. manage.
Thus the possible combinations are: Thus the possible combinations are:
- 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. In simpler networks or extensions [MTISIS] have been implemented (note that using IS-IS for
only IPv4 or only IPv6 requires no convexity). In simpler networks or
with careful planning of IS-IS link costs, it is possible to keep with careful planning of IS-IS link costs, it is possible to keep
even incongruent IPv4/IPv6 topologies "convex." even incongruent IPv4/IPv6 topologies "convex." The convexity problem
is explained in more detail with an example in Appendix A.
Therefore, the use of same process is recommended especially for When deploying full dual-stack in the short-term, using single-
large ISPs intending to deploy, in the short-term, a fully dual- topology IS-IS is recommended. This may be applicable particularly
stack backbone infrastructure. If the topologies will not be similar for some larger ISPs. In other scenarios, determining between one or
in the short term, two processes (or Multi-topology IS-IS two separate processes often depends on the perceived risk to the
extensions) are recommended. 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
process is usually preferable due to operational reasons: not having
to manage two protocols and topologies.
The IGP is not typically used to carry customer prefixes or external The IGP is typically only used to carry loopback and point-to-point
routes. Internal BGP (iBGP), as described in the next section, is addresses and doesn't include customer prefixes or external routes.
most often deployed in all routers to distribute such other routing Internal BGP (iBGP), as described in the next section, is most often
information. deployed in all routers (PE and core) to distribute routing
information about customer prefixes and external routes.
Because some of the simplest devices, e.g., CPE routers, may not Some of the simplest devices, e.g., CPE routers, may not implement
implement routing protocols other than RIPng, in some cases it may routing protocols other than RIPng. In some cases, therefore, it may
also be necessary to run RIPng in addition to one of the above IGPs, be necessary to run RIPng in addition to one of the above IGPs, at
at least in a limited fashion, and somehow to redistribute routing least in a limited fashion, and then, by some mechanism, to
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 Multi-protocol extensions [RFC 2858] can be used for IPv6 BGP with multiprotocol extensions [RFC 2858] can be used for IPv6
[RFC 2545]. These extensions enable exchanging both IPv6 routing [RFC 2545]. These extensions enable the exchange of IPv6 routing
information and establishing BGP sessions using TCP over IPv6. information as well as the establishment of 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, the most common
BGP sessions are used. practice today is to use separate BGP sessions.
4.3.3 Transport of Routing Protocols 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
similarly IPv6 routing information by IPv6 for several reasons: similarly IPv6 routing information by IPv6 for several reasons:
* IPv6 connectivity may work when IPv4 connectivity is down * IPv6 connectivity may work when IPv4 connectivity is down
(or 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 and IPv6 logical topologies may be different,
because the administrator may want to assign different metrics because the administrator may want to assign different metrics
to a physical link for load balancing or tunnels may be used. to a physical link for load balancing or because tunnels may be
in use.
4.4 Multicast 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 using the PIM-SM and PIM-SSM protocols. These also work with
IPv6. IPv6.
Information about multicast sources is exchanged using MSDP in IPv4, Information about multicast sources is exchanged using MSDP in IPv4,
but MSDP is intentionally not defined for IPv6. Instead, one should but MSDP is intentionally not defined for IPv6. Instead, one should
use only PIM-SSM or an alternative mechanism for conveying the 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 Transitioning 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. Transitioning this PEs connected to a large set of CPEs, and may be based on different
infrastructure to IPv6 can be accomplished in several steps, but some technologies depending on the customer type or size, as well as the
ISPs, depending on their perception of the risks, may avoid some of required bandwidth or even quality of service. Basically, public
the steps. customers or small/unmanaged networks connection networks usually
rely on a different technologies (e.g. dial-up or DSL) than the ones
used for large customers typically running managed networks.
Transitioning these infrastructures to IPv6 can be accomplished in
several steps, but some 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
network can be considered as a first careful step taken by an ISP to can be considered as a first careful step taken by an ISP to provide
provide IPv6 services to its IPv4 customers. In addition, some IPv6 services to its IPv4 customers. In addition, some ISPs may also
ISPs may also provide IPv6 services to customers who get their IPv4 choose to provide IPv6 service independently from the regular IPv4
services from another ISP. service.
This IPv6 service can be provided by using tunneling techniques. The In any case, IPv6 service can be provided by using tunneling
tunnel may terminate at the CPE corresponding to the IPv4 service or techniques. The tunnel may terminate at the CPE corresponding to the
in some other part of the customer's infrastructure (for instance, IPv4 service or in some other part of the customer's infrastructure
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, Teredo, etc. tunnels with tunnel broker, 6to4, Teredo, etc. Some of them are based
on a specific addressing plan independent of the ISP's allocated
prefix(es), while some others use a part of the ISP's prefix. In most
cases using ISP's address space is preferable.
The selection of one candidate depends largely on the presence or A key factor is the presence or absence of NATs between the two
absence of NATs between the two tunnel end-points and whether the tunnel end-points. In most cases, 6to4 and ISATAP are incompatible
user's IPv4 tunnel end-point address is static or dynamic. In most with NATs, and UDP encapsulation for configured tunnels has not been
cases, 6to4 and ISATAP are incompatible with NATs, and UDP specified.
encapsulation for configured tunnels has not been specified.
However, NAT traversal can be avoided if the NAT supports Dynamic and non-permanent IPv4 address allocation is another factor a
forwarding protocol-41 [PROTO41]. tunneling technique may have to deal with. In this case the tunneling
techniques may be more difficult to deploy at the ISP's end,
especially if a protocol including authentication (like PPP for IPv6)
is not used. This may need to be considered in more detail.
Firewalls in the path can also break these types of tunnels. The However, NAT traversal can be avoided if the NAT supports forwarding
administrator of the firewall needs to create a hole for the protocol-41 [PROTO41] and is configured to do so.
tunnel. This is usually manageable, as long as the firewall is
controlled by either the customer or the ISP, which is almost always Firewalls in the path can also break tunnels of these types. The
the case. administrator of the firewall needs to create a hole for the tunnel.
This is usually manageable, as long as the firewall is controlled by
either the customer or the ISP, which is almost always the case.
When the CPE is performing NAT or firewall functions, terminating the 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.
In practice, an ISP has two kinds of customers in its customer 5.1.1 Small end sites
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.
Tunneling consideration for small end sites are discussed in Tunneling considerations for small end sites are discussed in
[UNMANCON] and [UNMANEVA]. These identify solutions relevant to the [UNMANEVA]. These identify solutions relevant to the first category
first category of unmanaged networks. of unmanaged networks. The tunneling requirements applicable in 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 "real" 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 or Teredo servers later phases, ISPs might also deploy 6to4 relays and Teredo servers
(or similar) to optimize their customers' connectivity to 6to4 or (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
on techniques that don't use IPv6 addresses out of the ISP's
allocated prefix(es), and that the services have very limited
functions to control the origin and the number of customers connected
to a given relay.
Most interesting are the managed services. When dual-stack is not an 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. The options are basically either to deploy automation has to be used. Basically, the options are either to
an L2TP architecture (whereby the customers would run L2TP clients deploy an L2TP architecture (whereby the customers would run L2TP
and PPP over it to initiate IPv6 sessions) or to deploy a tunnel clients and PPP over it to initiate IPv6 sessions) or to deploy a
configuration service. The prime candidates for tunnel configuration tunnel configuration service. The prime candidates for tunnel
are STEP [STEP] and TSP [TSP], which are not analyzed further in this configuration are STEP [STEP] and TSP [TSP], which both also work in
document. the presence of NATs. Neither is analyzed further in this document.
For connecting larger customers: 5.1.2 Large end sites
* Dual-stack access service is often a realistic possibility since Large end sites are usually running managed network.
the customer network is managed.
* Configured tunnels, as-is, are a good solution when a NAT is not in Dual-stack access service is often a realistic possibility since the
customer network is managed (although CPE upgrades may be necessary).
Configured tunnels, as-is, are a good solution when a NAT is not in
the way and the IPv4 end-point addresses are static. In this 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
used. implemented.
* A tunnel brokering solution, to help facilitate the set-up of a
bi-directional tunnel, has been proposed: the Tunnel Set-up
Protocol. Whether this is the right approach needs to be
determined.
* Automatic tunneling mechanisms such as 6to4 or Teredo are not
suggested in this scenario.
Other ISPs may take a more direct approach and avoid the use of Tunnel brokering solutions, to help facilitate the set-up of a bi-
tunnels as much as possible. directional tunnel, have been proposed. Such mechanisms are typically
unnecessary for large end-sites, as simple configured tunneling or
native access can be used instead. However, if such mechanisms would
already be deployed, large sites starting to deploy IPv6 might be
able to benefit from them in any case.
Note that when customers use dynamic IPv4 addresses, the Teredo is not applicable in this scenario as it can only provide IPv6
tunneling techniques may be more difficult to deploy at the ISP's connectivity to a single host, not the whole site. 6to4 is not
end, especially if a protocol including authentication (like PPP for recommended due to its reliance on the relays and provider-
IPv6) is not used. This may need to be considered in more detail independent address space, which make it impossible to guarantee the
with tunneling mechanisms. required service quality and manageability large sites typically
want.
5.2 Access Control Requirements 5.2 User Authentication/Access Control Requirements
Access control is usually required in ISP networks, because the ISPs User authentication can be used to control who can use the IPv6
need to control to whom they are granting access. For instance, it is connectivity service in the first place or who can access specific
important to check whether the user who tries to connect is really a IPv6 services (e.g., NNTP servers meant for customers only, etc.).
valid customer. In some cases, it is also important for billing. The former is described at more length below. The latter can be
achieved by ensuring that for all the service-specific IPv4 access
lists, there are also equivalent IPv6 access lists.
However, IPv6-specific access control is not always required. IPv6-specific user authentication is not always required. An example
This is the case, for instance, when a customer of the IPv4 service is a customer of the IPv4 service automatically having access to the
has automatically access to IPv6 service. Then, the IPv4 access IPv6 service. In this case the IPv4 access control also provides
control also provides access to the IPv6 services. 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 access to IPv6 services, specific IPv6 access control must automatic access to IPv6 services, specific IPv6 access control must
be performed in parallel with the IPv4 access control. This does not be performed in parallel with the IPv4 access control. This does not
imply that different user authentication must be performed for IPv6, imply that different user authentication must be performed for IPv6,
but merely that the authentication process may lead to different but merely that the authentication process may lead to different
results for IPv4 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 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 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 or
more. The configuration of CPE is, in general, a difficult task for more. The configuration of CPE is a difficult task for the ISP, and
the ISP, and even more so in this case, because configuration must be it is even more difficult when it must be done remotely. In this
done remotely. In this context, the use of auto-configuration context, the use of auto-configuration mechanisms is beneficial, even
mechanisms is beneficial, even if manual configuration is still an if manual configuration is still an option.
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:
- 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 a NTP server. - Possibly other parameters, e.g., the address of an NTP
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 can 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 not just a point-to-point link, authenticating
the configuration of the parameters (esp. prefix delegation) requires the configuration of the parameters (especially prefix delegation)
further study. requires further study.
As long as IPv4 service is available alongside of IPv6, no critical As long as IPv4 service is available alongside IPv6 it is not
need exists to be able to autoconfigure IPv6 parameters (except for required to auto configure IPv6 parameters in the CPE, except the
the prefix) in the CPE-- IPv4 settings work as well. 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,
which means that a specific IPv6 address or prefix has to be tied to meaning that a specific IPv6 address or prefix has to be tied to a
a certain customer, or that records of which customer had which certain customer, or that records of which customer had which
address or 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 the result in a database. It can also
done by assigning a static address or prefix to the customer. be done by assigning a static address or prefix to the customer. A
tunnel server could also provide this mapping.
5.5 Ingress Filtering in the Customer Connection Network 5.5 Ingress Filtering in the Customer Connection Network
Ingress filtering must be deployed towards the customers, everywhere, Ingress filtering must be deployed towards 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, etc.
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 [BCP38UPD]. described in [BCP38UPD].
5.6 Multi-Homing 5.6 Multihoming
Customers may desire multihoming or multi-connecting for a number of
Customers may desire multi-homing or multi-connecting for a number of
reasons [RFC3582]. reasons [RFC3582].
Multi-homing to more than one ISP is a subject still under debate. Mechanisms for multihoming to more than one ISP are still under
Deploying multiple addresses from each ISP and using the addresses discussion. One working model could be to deploy at least one prefix
of the ISP when sending traffic to that ISP is at least one working per ISP, and to choose the prefix from the ISP to which traffic is
model; in addition, tunnels may be used for robustness [RFC3178]. sent. 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. Such addresses would enable IPv4-style multihoming, with associated
disadvantages.
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., by using BGP with public or practice, and this can be done, e.g., by using BGP with public or
private AS numbers and a prefix assigned to the customer. private AS 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 reassurances. Service Level Agreements (SLAs) or similar quality assurances.
Depending on the deployment of the IPv6 service, the service could During the deployment of the IPv6 service, the service could be best-
be best-effort, at least initially, even if the IPv4 service had a effort or similar even if the IPv4 service has a SLA. In the end both
SLA. IP version should be treated equally.
Both IntServ and DiffServ are equally applicable in IPv6 as well as IntServ and DiffServ are equally applicable to IPv6 as to IPv4 and
in IPv4 and work in a similar fashion. Of these, typically only work in a similar fashion independent of IP version. Of these,
DiffServ has been implemented. typically only DiffServ has been implemented.
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:
- 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
skipping to change at page 17, line 34 skipping to change at page 18, line 4
- 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 IPv6 native transport layer to
be available, whereas others will not. be available, whereas 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 over IPv4 transport.
Nevertheless, some monitoring functions require the availability of Nevertheless, some monitoring functions require the availability of
IPv6 transport. This is the case, for instance, when ICMPv6 messages IPv6 transport. This is the case, for instance, when ICMPv6 messages
are used by the monitoring applications. are used by the monitoring applications.
The current inability to get IPv4 and IPv6 traffic statistics for The current inability on many platforms to retrieve separate IPv4 and
management purposes by using SNMP separately from dual-stack IPv6 traffic statistics from dual-stack interfaces for management
interfaces 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 might want to transition to a service that is
IPv6 only, at least in certain parts of its network. This IPv6 only, at least in certain parts of its network. Such a
transition creates a lot of new cases into which it must factor how transition creates many new cases into which continued maintenance of
to maintain the IPv4 service. Providing an IPv6-only service is not the IPv4 service must be factored. Providing an IPv6-only service is
much different from the dual IPv4/IPv6 service described in stage 3 not much different from the dual IPv4/IPv6 service described in stage
except for the need to phase out the IPv4 service. The delivery of 3 except for the need to phase out the IPv4 service. The delivery of
IPv4 services over an IPv6 network and the phase out of IPv4 are left IPv4 services over an IPv6 network and the phase out of IPv4 are left
for a subsequent 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 example networks are
presented. These are only example networks and will not necessarily presented. These will not necessarily match any existing networks but
match any existing networks. Nevertheless, the examples are intended are intended to be useful even in cases in which they do not
be useful even in cases in which they do not match specific target correspond to specific target networks. The purpose of these examples
networks. The purpose of the example networks is to exemplify is to exemplify the applicability of the transition mechanisms
the applicability of the transition mechanisms described in this described in this document to a number of different situations with
document to a number of different situations with different different prerequisites.
prerequisites.
The sample network layout will be the same in all network examples. The sample network layout will be the same in all network examples.
The network examples should be viewed as specific representations of These should be viewed as specific representations of a generic
a generic network with a limited number of network devices. A small network with a limited number of network devices. A small number of
number of routers have been used in the network examples. However, routers have been used in the examples. However, because the network
because the network examples follow the implementation strategies examples follow the implementation strategies recommended for the
recommended for the generic network scenario, it should be possible generic network scenario, it should be possible to scale the examples
to scale the examples to fit a network with an arbitrary number, e.g. to fit 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 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 as well as with another ISP. The connection to another ISP can
be either direct or through an exchange point. In addition to these be either direct or through an exchange point. In addition to these
connections, a number of customer connection networks are also connections, a number of customer connection networks are also
connected to the routers. Customer connection networks can be, for connected to the routers. Customer connection networks can be, for
example, xDSL or cable network equipment. example, xDSL or cable network equipment.
ISP1 | ISP2 ISP1 | ISP2
+------+ | +------+ +------+ | +------+
skipping to change at page 19, line 46 skipping to change at page 19, line 46
|Customer| |Customer| |Customer| |Customer|
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
Figure 3: ISP Sample Network Layout. Figure 3: ISP Sample Network Layout.
8.1 Example 1 8.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 and
IBGP as routing protocols for internal and external routes, IBGP as routing protocols for internal and external routes,
respectively. MBGP is used to exchange routes over the connections to respectively. Multiprotocol BGP is used to exchange routes over the
ISP2 and the exchange point. Multicast using PIM-SM routing is connections to ISP2 and the exchange point. Multicast using PIM-SM
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 Access 1 is xDSL connected to the backbone through an access router.
router. The xDSL equipment, except for the access router, is The xDSL equipment, except for the access router, is considered to be
considered to be layer 2 only, e.g., Ethernet or ATM. IPv4 addresses layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically
are dynamically assigned to the customer using DHCP. No routing assigned to the customer using DHCP. No routing information is
information is exchanged with the customer. Access control and exchanged with the customer. Access control and traceability are
traceability are preformed in the access router. Customers are performed in the access router. Customers are separated into VLANs or
separated into VLANs or separate ATM PVCs up to the access router. separate ATM PVCs up to the access router.
Access 2 is Fiber to the building or home (FTTB/H) connected directly Access 2 is "fiber to the building or home" (FTTB/H) connected
to the backbone router. This is considered to be layer-3-aware, directly to the backbone router. This connection is considered to be
because it is using layer 3 switches and it performs access control layer-3-aware, because it is using layer 3 switches and it performs
and traceability through its layer 3 awareness by using DHCP access control and traceability through its layer 3 awareness by
snooping. IPv4 addresses are dynamically assigned to the customers using DHCP snooping. IPv4 addresses are dynamically assigned to the
using DHCP. No routing information is exchanged with the customer. customers using DHCP. No routing information is exchanged with the
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 through tunnels or at an internet exchange). (either 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 order
is considered with care) is used as an IPv6 and IPv4 IGP. When is considered with care) is used as an IPv6 and IPv4 IGP. When
upgrading, it's important to note that until IPv6 customers are upgrading, it's important to note that until IPv6 customers are
connected behind a backbone router, the convexity requirement is not connected behind a backbone router, the convexity requirement is not
critical: the routers just will not be able to be reached using IPv6. critical: the routers will just not be reachable using IPv6. That
That is, a software supporting IPv6 could be installed even though is, software supporting IPv6 could be installed even though the
the routers would not be used for (customer) IPv6 traffic yet. That routers would not be used for (customer) IPv6 traffic yet. That way,
way, IPv6 could be enabled in the backbone on a need-to-enable basis IPv6 could be enabled in the backbone on a need-to-enable basis when
when needed. needed.
Separate IPv6 BGP sessions are built, similar to IPv4. Multicast Separate IPv6 BGP sessions are built, similar 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.
Customers (with some exceptions) are not connected using a tunnel Offering native service as quickly as possible is considered most
broker, because offering native service faster is considered more important. However, a 6to4 relay may be provided in the meantime for
important -- and then there will not be unnecessary parallel optimized 6to4 connectivity and it may also be combined with a tunnel
infrastructures to tear down later on. However, a 6to4 relay is broker for extended functionality. xDSL equipment, operating as
provided in the meantime for optimized 6to4 connectivity. xDSL bridges at Layer 2 only, does not require changes in CPE: IPv6
equipment, operating as bridges at Layer 2 only, do not require connectivity can be offered to the customers by upgrading the PE
changes in CPE: IPv6 connectivity can be offered to the customers by router to IPv6. In the initial phase, only Router Advertisements are
upgrading the PE router to IPv6. In the initial phase, only Router used; DHCPv6 Prefix Delegation can be added as the next step if no
Advertisements are used; DHCPv6 Prefix Delegation can be added as the other mechanisms are available.
next step if no 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 and not just address assignment. This could, however, lead
to the need to use DHCPv6 for address assignment. 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 and is using OSPF In example 2 the backbone is running IPv4 with MPLS and is using OSPF
and IBGP are for internal and external routes respectively. The and IBGP are for internal and external routes respectively. The
connection to ISP2 and the exchange point run BGP to exchange routes. connections to ISP2 and the exchange point run BGP to exchange
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 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 routing
information is exchanged with the customer. 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], because this will allow large-scale IPv6
support without hardware or software upgrades in the core. In a later support without hardware or software upgrades in the core. In a later
phase, perhaps years later, IPv6 traffic would run natively in the phase native IPv6 traffic or IPv6 LSPs would be used in the whole
whole network. In that case IS-IS or OSPF could be used for the network. In that case IS-IS or OSPF could be used for the internal
internal routing, and a separate IPv6 BGP session would be run. routing, 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 as
in Example 1 apply. In addition to IP-tunneling an additional PPP 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 session can be used to offer IPv6 access to a limited number of
customers. Later, when clients and servers have been updated, the customers. Later, when clients and servers have been updated, the
IPv6 PPP session can be replaced with a combined PPP session for both 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. 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 are 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 Even though the RIR policies on getting IPv6 prefixes require the
assignment of at least 200 /48 prefixes to the customers, this type assignment of at least 200 /48 prefixes to the customers, this type
of transit provider obtains an allocation nonetheless, as the number of transit provider obtains an allocation nonetheless, as the number
of customers their customers serve is significant. The whole backbone of customers their customers serve is significant. The whole backbone
can be upgraded to dual-stack in a reasonably rapid pace after can be upgraded to dual-stack in a reasonably rapid pace after a
trialing it with a couple of routers. IPv6 routing is performed trial with a couple of routers. IPv6 routing is performed using the
using the same IS-IS and separate IPv6 BGP sessions. same IS-IS process and separate 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) which are the customers of
its customers whenever its own customer networks are not offering its customers whenever its own customer networks are not offering
IPv6. This is done both to introduce them to IPv6 and to create a 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 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.
skipping to change at page 22, line 25 skipping to change at page 22, line 25
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. 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 with IPv6; typically these are generic issues, and than with IPv4; typically these are generic issues, and
to be further discussed in other documents, for example, to be further discussed 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 more difficult it will be to manage or analyze their the more difficult it will be to manage or analyze their
impact on security; consequently, simple mechanisms are to impact on security. Consequently, simple mechanisms are to
be preferred. 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 which should be explicitly considered
when adopting IPv6: how to perform access control over when adopting IPv6: how to perform access control over
shared media or shared ISP customer connection media, shared media or shared ISP customer connection media,
how to manage the configuration management security on such how to manage the configuration management security on such
environments (e.g., DHCPv6 authentication keying), and environments (e.g., DHCPv6 authentication keying), and
how to manage customer traceability if stateless address how to manage customer traceability if stateless address
autoconfiguration is used. autoconfiguration is used.
10. Acknowledgements 10. Acknowledgements
This draft has greatly benefited from inputs by Marc Blanchet, Jordi This draft has greatly benefited from inputs by Marc Blanchet, Jordi
Palet, Francois Le Faucheur and Cleve Mickles. Special thanks to Palet, Francois Le Faucheur, Ronald van der Pol and Cleve Mickles.
Richard Graveman for proofreading the document. Special thanks to Richard Graveman and Michael Lambert 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" -
Work in progress 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"
Work in progress Work in progress
skipping to change at page 23, line 33 skipping to change at page 23, line 34
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 Work in progress
[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"
Work in progress Work in progress
[UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations [STEP] P. Savola, "Simple IPv6-in-IPv4 Tunnel Establishment
for IPv6 Tunneling Solutions in Small End Sites" Procedure (STEP)"
Work in progress
[TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup
Protocol (TSP)"
Work in progress Work in progress
[TUNREQS] A. Durand, F. Parent "Requirements for assisted
tunneling"
Work in progress
[UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol, [UNMANEVA] C. Huitema, R. Austein, S. Satapati, R. van der Pol,
"Evaluation of Transition Mechanisms for Unmanaged "Evaluation of Transition Mechanisms for Unmanaged
Networks" Networks"
Work in progress Work in progress
[PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding [PROTO41] J. Palet, C. Olvera, D. Fernandez, "Forwarding
Protocol 41 in NAT Boxes" Protocol 41 in NAT Boxes"
Work in progress Work in progress
[V6SEC] P. Savola, "IPv6 Transition/Co-existence Security [V6SEC] P. Savola, "IPv6 Transition/Co-existence Security
Considerations" Considerations"
Work in progress 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
skipping to change at page 24, line 17 skipping to change at page 24, line 26
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
6WIND S.A. Thales Communications
Immeuble Central Gare - Bat.C 160, boulevard de Valmy
1, place Charles de Gaulle 92704 Colombes, France
78180, Montigny-Le-Bretonneux - France Email: vladimir.ksinant@fr.thalesgroup.com
Phone: +33 1 39 30 92 36
Email: vladimir.ksinant@6wind.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
42, rue des coutures 42, rue des coutures
skipping to change at line 1179 skipping to change at page 25, line 49
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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
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.
 End of changes. 

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