The first step involves tunnels or dedicated links but leaves
existing routers unchanged. Only a small set of routers then have
IPv6 capabilities. The use of configured tunnels is adequate during
this step.
In the second step, some dual-stack routers are added, progressively,
to this network.
The final step is reached when all or almost all routers are
dual-stack.
For many reasons (technical, financial, etc.), the ISP may progress
step by step or jump directly to the final one. One important
criterion 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.
In short, each intermediate step is possible, but none is mandatory.
4.1.1. MPLS Backbone
If MPLS is already deployed in the backbone, it may be desirable to
provide IPv6-over-MPLS connectivity. However, setting up an IPv6
Label Switched Path (LSP) requires signaling through the MPLS
network; both LDP and RSVP-TE can set up IPv6 LSPs, but this might
require upgrade/change in the MPLS core network.
An alternative approach is to use BGP for signaling or to perform;
for example, IPv6-over-IPv4/MPLS, as described in [BGPTUNNEL]. Some
possibilities are preferable to others, depending on the specific
environment under consideration. The approaches seem to be as
follows:
1) Require that MPLS networks deploy native IPv6 routing and
forwarding support.
2) Require that MPLS networks support native routing and
setting up of IPv6 LSPs, used for IPv6 connectivity.
3) Use only configured tunneling over IPv4 LSPs.
4) Use [BGPTUNNEL] to perform IPv6-over-IPv4/MPLS encapsulation
for IPv6 connectivity.
Approaches 1) and 2) are clearly the best target approaches.
However, approach 1) may not be possible if the ISP is not willing to
add IPv6 support in the network, or if the installed equipment is not
capable of high performance native IPv6 forwarding. Approach 2) may
not be possible if the ISP is unwilling or unable to add IPv6 LSP
set-up support in the MPLS control plane.
Approach 4) can be used as an interim mechanism when other options
are unfeasible or undesirable for the reasons discussed above.
Approach 3) is roughly equivalent to approach 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
In the backbone, the number of devices is small, and IPv6
configuration mainly deals with routing protocol parameters,
interface addresses, loop-back addresses, access control lists, and
so on.
These IPv6 parameters need to be configured manually.
4.3. Routing
ISPs need routing protocols to advertise reachability and to find the
shortest working paths, both internally and externally.
Either OSPFv2 or IS-IS is typically used as the IPv4 IGP. RIPv2 is
not usually used in service provider networks, as OSPF and IS-IS are
superior IGPs. BGP is the only IPv4 EGP. Static routes also are
used in both cases.
Note that it is possible to configure a given network so that it has
an IPv6 topology different from its IPv4 topology. For example, some
links or interfaces may be dedicated to IPv4-only 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 be able to
understand and cope with multiple topologies.
4.3.1. IGP
Once the IPv6 topology has been determined, the choice of IPv6 IGP
must be made: either OSPFv3 or IS-IS for IPv6. RIPng is not
appropriate in most contexts, due to RIPv2 not being appropriate for
IPv4 either, and is therefore not discussed here. The IGP typically
includes the routers’ point-to-point and loop-back addresses.
The most important decision is whether one wishes to have separate
routing protocol processes for IPv4 and IPv6. Separating them
requires more memory and CPU for route calculations, e.g., when the
links flap. But separation provides a measure of assurance that
should problems arise with IPv6 routing, they will not affect the
IPv4 routing protocol. In the initial phases, if it is uncertain
whether joint IPv4-IPv6 networking is working as intended, running
separate processes may be desirable and easier to manage.
The possible combinations are as follows:
- With separate processes:
o OSPFv2 for IPv4, IS-IS for IPv6 (only)
o OSPFv2 for IPv4, OSPFv3 for IPv6, or
o IS-IS for IPv4, OSPFv3 for IPv6
- With the same process:
o IS-IS for both IPv4 and IPv6
Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6
topologies must be "convex", unless the multiple-topology IS-IS
extensions [MTISIS] have been implemented (using IS-IS for only IPv4
or only IPv6 requires no convexity). In simpler networks or with
careful planning of IS-IS link costs, it is possible to keep even
incongruent IPv4/IPv6 topologies "convex". The convexity problem is
explained in more detail with an example in Appendix A.
When deploying full dual-stack in the short-term, using single-
topology IS-IS is recommended. This may be particularly applicable
for some larger ISPs. In other scenarios, choosing between one or
two separate processes often depends on the perceived risk to the
IPv4 routing infrastructure, i.e., whether one wishes to keep them
separate for the time being. If this is not a factor, using a single
process is usually preferable for operational reasons: not having to
manage two protocols and topologies.
The IGP is typically only used to carry loopback and point-to-point
addresses and doesn’t include customer prefixes or external routes.
Internal BGP (iBGP), as described in the next section, is most often
deployed in all routers (PE and core) to distribute routing
information about customer prefixes and external routes.
Some of the simplest devices (e.g., CPE routers) may not implement
routing protocols other than RIPng. In some cases, therefore, it may
be necessary to run RIPng in addition to one of the above IGPs, at
least in a limited fashion, and then, by some mechanism, to
redistribute routing information between the routing protocols.
4.3.2. EGP
BGP is used for both internal and external BGP sessions.
BGP with multiprotocol extensions [RFC2858] can be used for IPv6
[RFC2545]. These extensions enable the exchange of IPv6 routing
information and the establishment of BGP sessions using TCP over
IPv6.
It is possible to use a single BGP session to advertise both IPv4 and
IPv6 prefixes between two peers. However, the most common practice
today is to use separate BGP sessions.
4.3.3. Transport of Routing Protocols
IPv4 routing information should be carried by IPv4 transport and,
similarly, IPv6 routing information by IPv6 for several reasons:
* IPv6 connectivity may work when IPv4 connectivity is down (or
vice-versa).
* The best route for IPv4 is not always the best one for IPv6.
* The IPv4 and IPv6 logical topologies may be different because
the administrator may want to assign different metrics to a
physical link for load balancing or because tunnels may be in
use.
4.4. Multicast
Currently, IPv6 multicast is not a major concern for most ISPs.
However, some of them are considering deploying it. Multicast is
achieved by using the PIM-SM and PIM-SSM protocols. These also work
with IPv6.
Information about multicast sources is exchanged by using MSDP in
IPv4, but MSDP is intentionally not defined for IPv6. Instead, one
should use only PIM-SSM or an alternative mechanism for conveying the
information [EMBEDRP].
5. Customer Connection Transition Actions
5.1. Steps in the Transition of Customer Connection Networks
Customer connection networks are generally composed of a small set of
PEs connected to a large set of CPEs and may be based on different
technologies depending on the customer type or size, as well as the
required bandwidth or even quality of service. Small unmanaged
connection networks used for public customers usually rely on
different technologies (e.g., dial-up or DSL) than the ones used for
large customers, which typically run managed networks. Transitioning
these infrastructures to IPv6 can be 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 network
can be considered a first careful step taken by an ISP to provide
IPv6 services to its IPv4 customers. Some ISPs may also choose to
provide IPv6 service independently from the regular IPv4 service.
In any case, IPv6 service can be provided by using tunneling
techniques. The tunnel may terminate at the CPE corresponding to the
IPv4 service or in some other part of the customer’s infrastructure
(for instance, on IPv6-specific CPE or even on a host).
Several tunneling techniques have already been defined: configured
tunnels with tunnel broker, 6to4 [RFC3056], Teredo [TEREDO], and so
on. Some of these are based on a specific addressing plan
independent of the ISP’s allocated prefix(es), while others use a
part of the ISP’s prefix. In most cases, using the ISP’s address
space is preferable.
A key factor is the presence or absence of NATs between the two
tunnel end-points. In most cases, 6to4 and ISATAP are incompatible
with NATs, and UDP encapsulation for configured tunnels has not been
specified.
Dynamic and non-permanent IPv4 address allocation is another factor a
tunneling technique may have to deal with. In this case, the
tunneling techniques may be 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.
However, NAT traversal can be avoided if the NAT supports forwarding
protocol-41 [PROTO41] and is configured to do so.
Firewalls in the path can also break tunnels of these types. The
administrator of the firewall needs to create a hole for the tunnel.
This is usually manageable, as long as the firewall is controlled by
either the customer or the ISP, which is almost always the case.
When the CPE is performing NAT or firewall functions, terminating the
tunnels directly at the CPE typically simplifies the scenario
considerably, avoiding the NAT and firewall traversal. If such an
approach is adopted, the CPE has to support the tunneling mechanism
used, or be upgraded to do so.
5.1.1. Small End Sites
Tunneling considerations for small end sites are discussed in
[UNMANEVA]. These identify solutions relevant to the first category
of unmanaged networks. The tunneling requirements applicable in
these scenarios are described in [TUNREQS].
The connectivity mechanisms can be categorized as "managed" or
"opportunistic". The former consist of native service or a
configured tunnel (with or without a tunnel broker); the latter
include 6to4 and, e.g., Teredo -- they provide "short-cuts" between
nodes using the same mechanisms and are available without contracts
with the ISP.
The ISP may offer opportunistic services, mainly a 6to4 relay,
especially as a test when no actual service is offered yet. At the
later phases, ISPs might also deploy 6to4 relays and Teredo servers
(or similar) to optimize their customers’ connectivity to 6to4 and
Teredo nodes.
Opportunistic services are typically based on techniques that don’t
use IPv6 addresses from the ISP’s allocated prefix(es), and the
services have very limited functions to control the origin and the
number of customers connected to a given relay.
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. Basically, the options are either to
deploy an L2TP architecture (whereby the customers would run L2TP
clients and PPP over it to initiate IPv6 sessions) or to deploy a
tunnel configuration service. The prime candidates for tunnel
configuration are STEP [STEP] and TSP [TSP], which both also work in
the presence of NATs. Neither is analyzed further in this document.
5.1.2. Large End Sites
Large end sites usually have a managed network.
Dual-stack access service is often a possibility, as the customer
network is managed (although CPE upgrades may be necessary).
Configured tunnels, as-is, are a good solution when a NAT is not in
the way and the IPv4 end-point addresses are static. In this
scenario, NAT traversal is not typically required. If fine-grained
access control is needed, an authentication protocol needs to be
implemented.
Tunnel brokering solutions have been proposed to help facilitate the
set-up of a bi-directional tunnel. Such mechanisms are typically
unnecessary for large end-sites, as simple configured tunneling or
native access can be used instead. However, if such mechanisms would
already be deployed, large sites starting to deploy IPv6 might
benefit from them in any case.
Teredo is not applicable in this scenario, as it can only provide
IPv6 connectivity to a single host, not the whole site. 6to4 is not
recommended due to its reliance on the relays and provider-
independent address space, which makes it impossible to guarantee the
required service quality and manageability large sites typically
want.
5.2. User Authentication/Access Control Requirements
User authentication can be used to control who can use the IPv6
connectivity service in the first place or who can access specific
IPv6 services (e.g., NNTP servers meant for customers only). 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.
IPv6-specific user authentication is not always required. An example
would be a customer of the IPv4 service automatically having access
to the IPv6 service. In this case, the IPv4 access control also
provides access to the IPv6 services.
When a provider does not wish to give its IPv4 customers automatic
access to IPv6 services, specific IPv6 access control must be
performed parallel with the IPv4 access control. This does not imply
that different user authentication must be performed for IPv6, but
merely that the authentication process may lead to different results
for IPv4 and IPv6 access.
Access control traffic may use IPv4 or IPv6 transport. For instance,
RADIUS [RFC2865] traffic related to IPv6 service can be transported
over IPv4.
5.3. Configuration of Customer Equipment
The customer connection networks are composed of PE and CPE(s).
Usually, each PE connects multiple CPE components to the backbone
network infrastructure. This number may reach tens of thousands of
customers, or more. The configuration of CPE is difficult for the
ISP, and it is even more difficult when it must be done remotely. In
this context, the use of auto-configuration mechanisms is beneficial,
even if manual configuration is still an option.
The parameters that usually need to be provided to customers
automatically are as follows:
- The network prefix delegated by the ISP
- The address of the Domain Name System server (DNS)
- Possibly other parameters (e.g., the address of an NTP
server)
When user identification is required on the ISP’s network, DHCPv6 may
be used to provide configurations; otherwise, either DHCPv6 or a
stateless mechanism may be used. This is discussed in more detail in
[DUAL-ACCESS].
Note that when the customer connection network is shared between the
users or the ISPs and is not just a point-to-point link,
authenticating the configuration of the parameters (especially prefix
delegation) requires further study.
As long as IPv4 service is available alongside IPv6, it is not
required to auto configure IPv6 parameters in the CPE, except the
prefix, because the IPv4 settings may be used.
5.4. Requirements for Traceability
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,
meaning that a specific IPv6 address or prefix has to be tied to a
certain customer, or that records must be maintained of which
customer had which address or prefix. This also applies to the
customers with tunneled connectivity.
This can be done, for example, by mapping a DHCP response to a
physical connection and storing the result in a database. It can
also be done by assigning a static address or prefix to the customer.
A tunnel server could also provide this mapping.
5.5. Ingress Filtering in the Customer Connection Network
Ingress filtering must be deployed toward the customers, everywhere,
to ensure traceability, to prevent DoS attacks using spoofed
addresses, to prevent illegitimate access to the management
infrastructure, and so on.
Ingress filtering can be done, for example, by using access lists or
Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
described in [RFC3704].
5.6. Multihoming
Customers may desire multihoming or multi-connecting for a number of
reasons [RFC3582].
Mechanisms for multihoming to more than one ISP are still under
discussion. One working model would deploy at least one prefix per
ISP and choose the prefix from the ISP to which traffic is sent. In
addition, tunnels may be used for robustness [RFC3178]. Currently,
there are no provider-independent addresses for end-sites. Such
addresses would enable IPv4-style multihoming, with associated
disadvantages.
Multi-connecting more than once to one ISP is a simple practice, and
this can be done, for example, by using BGP with public or private AS
numbers and a prefix assigned to the customer.
5.7. Quality of Service
In most networks, quality of service in one form or another is
important.
Naturally, the introduction of IPv6 should not impair existing
Service Level Agreements (SLAs) or similar quality assurances.
During the deployment of the IPv6 service, the service could be best
effort or similar, even if the IPv4 service has an SLA. In the end,
both IP versions should be treated equally.
IntServ and DiffServ are equally applicable to IPv6 and IPv4 and work
similarly regardless of IP version. Of the two, typically only
DiffServ has been implemented.
Many bandwidth provisioning systems operate with IPv4 assumptions,
e.g., taking an IPv4 address or (set of) prefixes for which traffic
is reserved or preferred. These systems require special attention
when introducing IPv6 support in the networks.
6. Network and Service Operation Actions
The network and service operation actions fall into different
categories as listed below:
- Set up IPv6 connectivity to upstream providers and peers
- IPv6 network device configuration: for initial configuration
and updates
- IPv6 network management
- IPv6 monitoring
- IPv6 customer management
- IPv6 network and service operation security
Some of these items will require an available IPv6 native transport
layer and others will not.
As a first step, network device configuration and regular network
management operations can be performed over an IPv4 transport,
because IPv6 MIBs are also available. 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.
On many platforms, the current inability to retrieve separate IPv4
and IPv6 traffic statistics from dual-stack interfaces for management
purposes by using SNMP is an issue.
As a second step, IPv6 transport can be provided for any of these
network and service operation facilities.
7. Future Stages
At some point, an ISP may want to change to a service that is IPv6
only, at least in certain parts of its network. This transition
creates many new cases into which continued maintenance of the IPv4
service must be factored. Providing an IPv6-only service is not much
different from the dual IPv4/IPv6 service described in stage 3 except
for the need to phase out the IPv4 service. The delivery of IPv4
services over an IPv6 network and the phaseout of IPv4 are issues
left for a subsequent document. Note that there are some services
which will need to maintain IPv4 connectivity (e.g., authorative and
some recursive DNS servers [DNSGUIDE]).
8. Requirements for Follow-On Work
This section tries to summarize the potential items requiring
specification in the IETF.
Work items for which an approach was not yet apparent as of this
writing are as follows:
- A tunnel server/broker mechanism, for the cases where the customer
connection networks cannot be upgraded, needs to be specified
[TUNREQS].
- An IPv6 site multihoming mechanism (or multiple ones) needs to be
developed.
Work items which were already fast in progress, as of this writing,
are as follows:
- 6PE for MPLS was identified as a required mechanism, and this is
already in progress [BGPTUNNEL].
- IS-IS for Multiple Topologies was noted as a helpful mechanism in
certain environments; however, it is possible to use alternative
methods to achieve the same end, so specifying this is not
strictly required.
9. Example Networks
This section presents a number of different example networks. These
will not necessarily match any existing networks but are intended to
be useful even when they do not correspond to specific target
networks. The purpose is to exemplify the applicability of the
transition mechanisms described in this document to a number of
different situations with different prerequisites.
The sample network layout will be the same in each network example.
This should be viewed as a specific representation of a generic
network with a limited number of network devices. A small number of
routers have been used in the examples. However, because the network
examples follow the implementation strategies recommended for the
generic network scenario, it should be possible to scale the examples
to fit a network with an arbitrary number, e.g., several hundreds or
thousands of routers.
The routers in the sample network layout are interconnected with each
other and with another ISP. The connection to another ISP can be
either direct or through an exchange point. A number of customer
connection networks are also connected to the routers. Customer
connection networks can be, for example, xDSL or cable network
equipment.
ISP1 | ISP2
+------+ | +------+
| | | | |
|Router|--|--|Router|
| | | | |
+------+ | +------+
/ \ +-----------------------
/ \
/ \
+------+ +------+
| | | |
|Router|----|Router|
| | | |
+------+ +------+\
| | \ | Exchange point
+------+ +------+ \ +------+ | +------+
| | | | \_| | | | |--