Internet Draft                                               M. Lind
   <draft-ietf-v6ops-isp-scenarios-analysis-02.txt>         TeliaSonera
                                                             V. Ksinant
                                                  Thales Communications
                                                                S. Park
                                                    Samsung Electronics
                                                              A. Baudot
                                                         France Telecom
                                                              P. Savola

   Expires: August October 2004                                   February                                     April 2004

       Scenarios and Analysis for Introducing IPv6 into ISP Networks

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at


   This document first describes different scenarios for the
   introduction of IPv6 into an ISP's existing IPv4 network without
   disrupting the IPv4 service. Then, this document analyses these
   scenarios and evaluates the relevance of the already defined
   transition mechanisms in this context. Known challenges are also

Table of Contents

   1.   Introduction................................................2
      1.1  Goal and Scope of the Document...........................2
   2.   Brief Description of a Generic ISP Network..................3
   3.   Transition Scenarios........................................4
      3.1  Identification of Stages and Scenarios...................4
      3.2  Stages...................................................5
      3.2.1  Stage 1 Scenarios: Launch..............................5
      3.2.2  Stage 2a Scenarios: Backbone...........................6
      3.2.3  Stage 2b Scenarios: Customer Connection................6
      3.2.4  Stage 3 Scenarios: Complete............................6
      3.2.5  Stages 2a and 3: Combination Scenarios.................7
      3.3  Transition Scenarios.....................................7
      3.4  Actions Needed When Deploying IPv6 in an ISP's network...7
   4.   Backbone Transition Actions.................................8
      4.1  Steps in Transitioning the Transition of Backbone Networks.................8 Networks.............8
      4.1.1  MPLS Backbone..........................................9
      4.2  Configuration of Backbone Equipment.....................10
      4.3  Routing.................................................10
      4.3.1  IGP...................................................10
      4.3.2  EGP...................................................11  EGP...................................................12
      4.3.3  Transport of Routing Protocols........................12
      4.4  Multicast...............................................12
   5.   Customer Connection Transition Actions.....................12
      5.1  Steps in Transitioning the Transition of Customer Connection Networks.....12 Networks.12
      5.1.1  Small end sites.......................................14
      5.1.2  Large end sites.......................................14
      5.2  Access  User Authentication/Access Control Requirements.............................14 Requirements.........15
      5.3  Configuration of Customer Equipment.....................15
      5.4  Requirements for Traceability...........................16
      5.5  Ingress Filtering in the Customer Connection Network....16
      5.6  Multi-Homing............................................16  Multihoming.............................................16
      5.7  Quality of Service......................................16 Service......................................17
   6.   Network and Service Operation Actions......................17
   7.   Future Stages..............................................17 Stages..............................................18
   8.   Example Networks...........................................18
      8.1  Example 1...............................................19
      8.2  Example 2...............................................21
      8.3  Example 3...............................................21
   9.   Security Considerations....................................22
   10.  Acknowledgements...........................................22
   11.  Informative References.....................................22

1. Introduction

1.1 Goal and Scope of the Document
   When an ISP deploys IPv6, its goal is to provide IPv6 connectivity
   and global address space to its customers. The new IPv6 service must
   be added to an already existing IPv4 service, and the introduction of
   IPv6 must not interrupt this IPv4 service.

   An ISP offering IPv4 service will find different ways to add IPv6 to
   this service. This document discusses a small set of scenarios for
   the introduction of IPv6 into an ISP's IPv4 network. It evaluates the
   relevance of the existing transition mechanisms in the context of
   these deployment scenarios, and points out the lack of functionality essential
   functionality in these methods to the ISP's operation of an IPv6

   The present document is focused on services that include both IPv6
   and IPv4 and does not cover issues surrounding IPv6-only service.
   It is also outside the scope of this document to describe different
   types of access or network technologies.

2. Brief Description of a Generic ISP Network

   A generic network topology for an ISP can be divided into two main
   parts: the backbone network and the customer connection networks
   connecting the customers. networks. It
   includes, in addition to these, some other building blocks such as
   network and service operations. The additional building blocks used
   in this document are defined as follows:

   "CPE"         : Customer Premises Equipment

   "PE"          : Provider Edge equipment

   "Network and service operation"
                 : This is the part of the ISP's network that hosts the
                   services required for the correct operation of the
                   ISP's network. These services usually include
                   management, supervision, accounting, billing, and
                   customer management applications.

   "Customer connection"
                 : This is the part of the network used by a customer
                   when connecting to an ISP's network. It includes the
                   CPE, the last hop link and the parts of the PE
                   interfacing to the last hop link.

   "Backbone"    : This is the rest of the ISP's network infrastructure.
                   It includes the parts of the PE interfacing to the
                   core, the core routers of the ISP, and the border
                   routers used to exchange routing information with
                   other ISPs (or other administrative entities).

   "Dual-stack network":
                   A network that supports natively both IPv4 and

   It is noted that, in some cases (e.g., incumbent national or
   regional operators), a given customer connection network may have
   to be shared between or among different ISPs. According to the type
   of customer connection network used (e.g., one involving only layer 2
   devices or one involving non-IP technology), this constraint may
   result in architectural considerations relevant to this document.

   The basic components in the ISP's network are depicted in Figure 1.

         ------------    ----------
        | Network and|  |          |
        |  Service   |--| Backbone |
        | Operation  |  |          |\
         ------------    ----------  \
            .             / |  \      \
            .            /  |   \      \_Peering( Direct and IX )
            .           /   |    \
            .          /    |     \
            .         /     |      \
      ----------     /   ---------- \     ----------
     | Customer |   /   | Customer | \   | Customer |
     |Connection|--/    |Connection|  \--|Connection|
     |     1    |       |     2    |     |     3    |
      ----------         ----------       ----------
           |                  |               |         ISP's Network
           |                  |               |     Customers' Networks
      +--------+        +--------+      +--------+
      |        |        |        |      |        |
      |Customer|        |Customer|      |Customer|
      |        |        |        |      |        |
      +--------+        +--------+      +--------+
       Figure 1: ISP Network Topology.

3. Transition Scenarios

3.1   Identification of Stages and Scenarios

   This section describes different stages an ISP might consider when
   introducing IPv6 connectivity into its existing IPv4 network and the
   different scenarios that might occur in the respective stages.

   The stages here are snapshots of the ISP's network with respect to
   IPv6 maturity. Because the ISP's network is continually evolving, a
   stage is a measure of how far along the ISP has come in terms of
   implementing the functionality necessary to offer IPv6 to the its

   It is possible to for a transition to occur freely between different
   stages. Although a network segment can only be in one stage at a
   time, the ISP's network as a whole can be in different stages.
   Different transition paths can be followed from the first to the
   final stage. The transition between two stages does not have to be
   instantaneous; it can occur gradually.

   Each stage has different IPv6 properties. An ISP can, therefore,
   based on its requirements, decide which set of stages it will follow
   and in what order to transform its network.

   This document is not aimed to cover at covering small ISPs, hosting providers,
   or data centers; only the scenarios applicable to ISPs eligible for
   at least a /32 IPv6 prefix allocation from a RIR are covered.

3.2  Stages

   The stages are derived from the generic description of an ISP's
   network in Section 2. Combinations of different building blocks
   that constitute an ISP's environment lead to a number of scenarios
   from which the ISP can choose.  The scenarios most relevant for to this
   document are the ones those that maximize ISP's ability to offer IPv6 to its
   customers in the most efficient and feasible way. The assumption in
   all stages is that the ISP's goal is to offer both IPv4 and IPv6 to
   the customer.

   The four most probable stages are:

         o Stage 1      Launch
         o Stage 2a     Backbone
         o Stage 2b     Customer connection
         o Stage 3      Complete

   Generally, an ISP is able to upgrade a current IPv4 network to an
   IPv4/IPv6 dual-stack network via Stage 2b, but the IPv6 service can
   also be implemented at a small cost by adding simple tunnel
   mechanisms to the existing configuration. When designing a new
   network, Stage 3 might be the first and last step, because there are
   no legacy concerns. Nevertheless, the absence of IPv6 capability in
   the network equipment can still be a limiting factor.

   Note that in every stage except Stage 1, the ISP can offer both IPv4
   and IPv6 services to its customers.

3.2.1 Stage 1 Scenarios: Launch
   The first stage is an IPv4-only ISP with an IPv4 customer. This is
   the most common case today and the natural starting point for the
   introduction of IPv6.  From this stage, the ISP can move (transition) (undergo a
   transition) from Stage 1 to any other stage with the goal of offering
   IPv6 to its customer.

   The immediate first step consists of getting obtaining a prefix allocation
   (typically a /32) from the appropriate RIR (e.g. AfriNIC, APNIC,
   ARIN, LACNIC, RIPE, ...) according to allocation procedures.

3.2.2 Stage 2a Scenarios: Backbone

   Stage 2a consists of deal with an ISP with IPv4-only customer connection networks
   and a backbone that supports both IPv4 and IPv6. In particular, the
   ISP has the possibility of making the backbone IPv6-
   capable IPv6-capable through
   either software upgrades, hardware upgrades, or a combination of

   Since the customer connections are have not yet been upgraded, a
   tunneling mechanism has to be used to provide IPv6 connectivity
   through the IPv4 customer connection networks. The customer can
   terminate the tunnel at the CPE (if it has IPv6 support) or at each individual
   device. In the former case, some
   set of devices internal to its network. That is, either the CPE will then or a
   device inside the network could provide global IPv6 connectivity to all
   the rest of the devices in the customer's network.

3.2.3 Stage 2b Scenarios: Customer Connection

   Stage 2b consists of an ISP with an IPv4 backbone network and a
   customer connection network that supports both IPv4 and IPv6. Because
   the service to the customer is native IPv6, the customer is not
   required to support both IPv4 and IPv6. This is the biggest
   difference in comparison with to the previous stage. The need to exchange
   IPv6 traffic still exists but might be more complicated than in the
   previous case, because the backbone is not IPv6-enabled. After
   completing Stage 2b, the original IPv4 backbone is unchanged. This
   means that the IPv6 traffic is transported by either tunnelling by tunneling over
   the existing IPv4 backbone, or in an IPv6 overlay network more or
   less separated from the IPv4 backbone.

   Normally the ISP will continue to provide IPv4 connectivity; in
   many cases connectivity using
   private (NATted by the ISP) or public IPv4 addresses address; in many cases,
   the customer also has a NAT of his/her own, and NATs will continue if so, this likely
   continues to be used. used for IPv4 connectivity.

3.2.4 Stage 3 Scenarios: Complete

   Stage 3 can be said to be the final step in introducing IPv6, at
   least within the scope of this document. This stage consists of
   ubiquitous IPv6 service with native support for IPv6 and IPv4 in both
   backbone and customer connection networks. This stage It is identical to the
   previous stage from the customer's perspective, because the customer
   connection network has not changed. The requirement for exchanging
   IPv6 traffic is identical to Stage 2.

3.2.5 Stages 2a and 3: Combination Scenarios

   Some ISPs may use different access technologies of varying IPv6
   maturity. This may result in a combination of the Stages 2a and 3:
   some customer connections do not support IPv6, but others do; in both
   cases the backbone is dual-stack.

   This scenario is equivalent to Stage 2a, but it requires support for
   native IPv6 customer connections on some access technologies.

3.3  Transition Scenarios

   Given the different stages, it is clear that an ISP has to be able
   to make a transition from one stage to another. The initial stage, stage in
   document, document is IPv4-only service and network. The end stage is dual
   IPv4/IPv6 service and network.

   The transition starts with an IPv4 ISP and then moves in one of
   three directions.  This choice corresponds to the different
   transition scenarios. Stage 2a consists of upgrading the backbone
   first. Stage 2b consists of upgrading the customer connection
   network. Finally, Stage 3 consists of introducing IPv6 in both the
   backbone and customer connections as needed.

   Because most of ISPs continually evolve their ISP backbone IPv4 networks continually evolve (firmware
   replacements in routers, new routers, etc.), they will can be
   able to get them made ready
   for IPv6 without additional investment (except staff training). This
   may be a slower but still useful transition path, because it allows
   for IPv6 the introduction of IPv6 without any actual customer demand. This
   process may be superior to doing everything at the last minute, which
   may entail a higher investment. However, it is important to start considering consider
   (and requesting to request from the vendors) IPv6 features in all new equipment from
   the start. outset. Otherwise, the time and effort required to remove non-IPv6-capable non-
   IPv6-capable hardware from the network
   will may be significant.

3.4  Actions Needed When Deploying IPv6 in an ISP's network

   Examination of the transitions described above reveals that it
   is possible to split the work required for each transition into a
   small set of actions. Each action is largely independent from of the
   others, and some actions may be common to multiple transitions.

   Analysis of the possible transitions leads to a small list of

     * Actions required for backbone transition:

        - Connect dual-stack customer connection networks to other
          IPv6 networks through an IPv4 backbone.

        - Transform an IPv4 backbone into a dual-stack one. This
          action can be performed directly or through intermediate

     * Actions required for customer connection transition:

        - Connect IPv6 customers to an IPv6 backbone through an IPv4

        - Transform an IPv4 customer connection network into a dual-
          stack one.

     * Actions required for network and service operation transition:

        - Configure IPv6 functions into network components.

        - Upgrade regular network management and monitoring
          applications to take IPv6 into account.

        - Extend customer management (e.g., RADIUS) mechanisms
          to be able to supply IPv6 prefixes and other information
          to customers.

        - Enhance accounting, billing, etc. to work with IPv6
          as needed. (Note: if dual-stack service is offered, this
          may not be necessary.)

        - Implement security for network and service operation.

   Sections 4, 5, and 6 contain detailed descriptions of each action.

4.  Backbone Transition Actions

4.1 Steps in Transitioning the Transition of Backbone Networks

   In terms of physical equipment, backbone networks consist mainly of
   high-speed core and edge routers. Border routers provide peering
   with other providers. Filtering, routing policy, and policing
   functions are generally managed on border routers.

   The initial step is

   In the beginning, an ISP has an IPv4-only backbone, and backbone. In the final step end, the
   backbone is a completely dual-stack backbone. dual-stack. In between, intermediate steps may
   be identified:

                     Tunnels         Tunnels
   IPv4-only ---->      or      --->   or         +  DS -----> Full DS
                  dedicated IPv6   dedicated IPv6  routers
                      links           links
          Figure 2: Migration Transition Path.

   The first step involves tunnels or dedicated links but leaves
   existing routers unchanged. Only a small set of routers then have
   IPv6 capabilities. Using The use of configured tunnels is adequate during
   this step.

   In the second step, some dual stack dual-stack routers are added, progressively,
   to this network.

   The final step is reached when all or almost all routers are dual-

   For many reasons (technical, financial, etc.), the ISP may progress
   step by step or jump directly to the final one. One of the 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 would might
   require a software upgrade 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 or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, 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. More analysis is needed, case by case, to determine consideration; the best approach or approaches: approaches seem to be:

        1) Require that MPLS networks deploy native IPv6 support or
           use configured tunneling for IPv6. routing and
           forwarding support.

        2) Require that MPLS networks support native routing and setting
           up of IPv6 LSPs,
           and set up used for IPv6 connectivity by using either these or
           configured tunneling. connectivity.

        3) Use only configured tunneling over IPv4 LSPs; this seems
           practical with small-scale deployments having few tunnels. LSPs.

        4) Use [BGPTUNNEL] or something comparable to perform IPv6-over-
           IPv4/MPLS IPv6-over-IPv4/MPLS encapsulation
           for IPv6 connectivity.

   Approaches 1

   1) and 2 2) are clearly the most attractive if the ISP is willing to
   perform an upgrade to the MPLS network. Approach 3 does not require
   any upgrades but may lack scalability. Approach 4 best target approaches. However, 1) may be economically
   attractive for an operator who does
   not wish to upgrade be possible if the MPLS
   network and has a large-scale deployment.

   MPLS networks have typically been deployed ISP is not willing to facilitate services
   such as Provider-Provisioned VPNs. Software upgrades are commonplace add IPv6 support in MPLS networks. No particular reason exists to avoid adding
   the network, or if the installed equipment is not capable of high
   performance native IPv6
   functionality, except forwarding.  2) may not be possible if the vendor
   ISP is unable not willing or able to provide sufficient add IPv6 forwarding capability (e.g., line-speed) LSP set-up support in the existing
   hardware (independent of the capabilities for handling MPLS frames).
   Therefore, recommending mechanisms like [BGPTUNNEL]
   control plane.

   Approach 4) can be used as an interim mechanism where other options
   are unfeasible or undesirable for the final
   solution might reasons discussed above.

   Approach 3) is roughly equivalent to 4) except that it does not be such a good idea.
   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, ACLs, etc.

   These IPv6 parameters are not supposed need to be configured
   automatically. manually.

4.3 Routing

   ISPs need routing protocols to advertise reachability and to
   find the shortest working paths, both internally and externally.

   Either OSPFv2 and or IS-IS are is typically used as an the IPv4 IGP. RIPv2 is
   typically usually used in operator service provider networks. 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
   results in having 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 less not
   appropriate in many most contexts and is therefore not discussed here. The
   IGP typically includes the routers' point-to-point and loop-back

   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. On the other hand, separation provides a certain measure
   of assurance that if problems arise with IPv6 routing, they will not
   affect IPv4 the IPv4 routing protocol at all.  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

   Thus the possible combinations are:

     - 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 multiple-topology IS-IS
   extensions [MTISIS] have been implemented. 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
   even incongruent IPv4/IPv6 topologies "convex."

   Therefore, the use of same process The convexity problem
   is recommended especially for
   large ISPs intending to deploy, explained in more detail with an example in Appendix A.

   When deploying full dual-stack in the short-term, a fully dual-
   stack backbone infrastructure.  If the topologies will not using single-
   topology IS-IS is recommended. This may be similar
   in the short term, applicable particularly
   for some larger ISPs. In other scenarios, determining between one or
   two separate processes (or Multi-topology IS-IS
   extensions) are recommended.

   The IGP is not typically used often depends on the perceived risk to carry customer prefixes the
   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 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 such other routing

   Because some
   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 RIPng. In some cases cases, therefore, it may
   be necessary to run RIPng in addition to one of the above IGPs, at
   least in a limited fashion, and somehow 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 Multi-protocol multiprotocol extensions [RFC 2858] can be used for IPv6
   [RFC 2545]. These extensions enable exchanging both the exchange of IPv6 routing
   information and establishing 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
   and IPv6 prefixes between two peers. However, typically, the most common
   practice today is to use separate BGP sessions are used. 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 logical topology and the IPv6 one 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 used.
         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 using the PIM-SM and PIM-SSM protocols. These also work with

   Information about multicast sources is exchanged 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 Transitioning 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. 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. Basically, public
   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 this
   infrastructure 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 as a first careful step taken by an ISP to provide
   IPv6 services to its IPv4 customers. In addition, some ISPs may also
   choose to provide IPv6 services to customers who get their IPv4
   services service independently from another ISP.

   This the regular IPv4

   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, Teredo, etc.

   The selection Some of one candidate depends largely 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.

   A key factor is the presence or absence of NATs between the two
   tunnel end-points and whether the
   user's IPv4 tunnel end-point address is static or dynamic. end-points. In most cases, 6to4 and ISATAP are incompatible
   with NATs, and UDP encapsulation for configured tunnels has not been

   However, NAT traversal can

   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 avoided if more difficult to deploy at the NAT supports
   forwarding protocol-41 [PROTO41]. 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 these types tunnels of tunnels. 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.

   In practice, an ISP has two kinds of customers in its customer
   connection networks: small

5.1.1 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. sites

   Tunneling consideration considerations for small end sites are discussed in
   [UNMANCON] and
   [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; Teredo -- they provide "short-cuts" between
   nodes using the same mechanisms and are available without contracts
   with the ISP.

   The ISP may offer opportunistic services, mainly a 6to4 relay,
   especially as a test when no "real" actual service is offered yet. At the
   later phases, ISPs might also deploy 6to4 relays or and Teredo servers
   (or similar) to optimize their customers' connectivity to 6to4 or and
   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
   option, a form of tunneling must be used. When configured tunneling
   is not an option (e.g., due to dynamic IPv4 addressing), some form of
   automation has to be used. The Basically, the options are basically either to
   deploy an L2TP architecture (whereby the customers would run L2TP
   clients and PPP over it to initiate IPv6 sessions) or to deploy a
   tunnel configuration service. The prime candidates for tunnel
   configuration are STEP [STEP] and TSP [TSP], which are not both also work in
   the presence of NATs. Neither is analyzed further in this document.

   For connecting larger customers:


5.1.2 Large end sites

   Large end sites are usually running managed network.

   Dual-stack access service is often a realistic possibility since the
   customer network is managed.

   * 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

   * A tunnel

   Tunnel brokering solution, solutions, to help facilitate the set-up of a
     bi-directional bi-
   directional tunnel, has have been proposed: the Tunnel Set-up
     Protocol. Whether this is the right approach needs to be

   * Automatic tunneling proposed. Such mechanisms such are typically
   unnecessary for large end-sites, as 6to4 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.

   Teredo are is not
     suggested applicable in this scenario.

   Other ISPs may take a more direct approach and avoid the use of
   tunnels as much scenario as possible.

   Note that when customers use dynamic IPv4 addresses, the
   tunneling techniques may be more difficult it can only provide IPv6
   connectivity to deploy at the ISP's
   end, especially if a protocol including authentication (like PPP for
   IPv6) single host, not the whole site. 6to4 is not used. This may need
   recommended due to be considered in more detail
   with tunneling mechanisms. its reliance on the relays and provider-
   independent address space, which make it impossible to guarantee the
   required service quality and manageability large sites typically

5.2 Access User Authentication/Access Control Requirements

   Access control is usually required in ISP networks, because the ISPs

   User authentication can be used to control to whom they are granting access. For instance, it is
   important to check whether who can use the user IPv6
   connectivity service in the first place or who tries to connect is really a
   valid customer. In some cases, it can access specific
   IPv6 services (e.g., NNTP servers meant for customers only, etc.).
   The former is also important described at more length below.  The latter can be
   achieved by ensuring that for billing.

   However, IPv6-specific all the service-specific IPv4 access control
   lists, there are also equivalent IPv6 access lists.

   IPv6-specific user authentication is not always required.
   This An example
   is the case, for instance, when a customer of the IPv4 service
   has automatically having access to the
   IPv6 service. Then, 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 in 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 traffic related to IPv6 service can be transported over

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 or
   more. The configuration of CPE is, in general, is a difficult task for the ISP, and
   it is even more so in this case, because configuration 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:

         - The network prefix delegated by the ISP,
         - The address of the Domain Name System server (DNS),
         - Possibly other parameters, e.g., the address of a an NTP

   When user identification is required on the ISP's network, DHCPv6 may
   be used to provide configurations otherwise configurations; otherwise, either DHCPv6 or a
   stateless mechanism can be used. This is discussed in more detail in

   Note that when the customer connection network is shared between the
   users or the ISPs, and not just a point-to-point link, authenticating
   the configuration of the parameters (esp. (especially prefix delegation)
   requires further study.

   As long as IPv4 service is available alongside of IPv6, no critical
   need exists to be able IPv6 it is not
   required to autoconfigure auto configure IPv6 parameters (except for
   the prefix) in the CPE-- CPE, except the
   prefix, because the IPv4 settings work as well. 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,
   which means
   meaning that a specific IPv6 address or prefix has to be tied to a
   certain customer, or that records of which customer had which
   address or prefix must be maintained. 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 this 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 towards the customers, everywhere,
   to ensure traceability, to prevent DoS attacks using spoofed
   addresses, to prevent illegitimate access to the management
   infrastructure, etc.

   Ingress filtering can be done, for example, by using access lists or
   Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
   described in [BCP38UPD].

5.6 Multi-Homing Multihoming
   Customers may desire multi-homing multihoming or multi-connecting for a number of
   reasons [RFC3582].


   Mechanisms for multihoming to more than one ISP is a subject are still under debate.
   Deploying multiple addresses from each ISP
   discussion. One working model could be to deploy at least one prefix
   per ISP, and using to choose the addresses
   of prefix from the ISP when sending traffic to that ISP which traffic is at least one working
   model; in
   sent. In addition, tunnels may be used for robustness [RFC3178].
   Currently, there are no provider-independent addresses for end-
   sites. end-sites.
   Such addresses would enable IPv4-style multihoming, with associated

   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
   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

   Naturally, the introduction of IPv6 should not impair existing
   Service Level Agreements (SLAs) or similar quality reassurances.

   Depending on assurances.

   During the deployment of the IPv6 service, the service could be best-effort, at least initially, best-
   effort or similar even if the IPv4 service had has a SLA.

   Both In the end both
   IP version should be treated equally.

   IntServ and DiffServ are equally applicable in to IPv6 as well as
   in to IPv4 and
   work in a similar fashion. fashion independent of IP version. Of these,
   typically only DiffServ has been implemented.

6. Network and Service Operation Actions

   The network and service operation actions fall into different
   categories as listed below:

       - 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 IPv6 native transport layer to
   be available, whereas 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 over IPv4 transport.

   Nevertheless, some monitoring functions require the availability of
   IPv6 transport. This is the case, for instance, when ICMPv6 messages
   are used by the monitoring applications.

   The current inability on many platforms to get retrieve separate IPv4 and
   IPv6 traffic statistics from dual-stack interfaces for management
   purposes by using SNMP separately from dual-stack
   interfaces 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 might want to transition to a service that is
   IPv6 only, at least in certain parts of its network.  This Such a
   transition creates a lot of many new cases into which it must factor how
   to maintain continued maintenance of
   the IPv4 service. 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 phase out of IPv4 are left
   for a subsequent document.

8.  Example Networks

   In this section, a number of different network examples example networks are
   presented. These are only example networks and will not necessarily
   match any existing networks. Nevertheless, the examples match any existing networks but
   are intended to be useful even in cases in which they do not match
   correspond to specific target networks. The purpose of the example networks these examples
   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 all network examples.
   The network examples
   These should be viewed as specific representations of a generic
   network with a limited number of network devices. A small number of
   routers have been used in the network 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 as well as with another ISP. The connection to another ISP can
   be either direct or through an exchange point. In addition to these
   connections, a number of customer connection networks are also
   connected to the routers. Customer connection networks can be, for
   example, xDSL or cable network equipment.

                       ISP1 | ISP2
                  +------+  |  +------+
                  |      |  |  |      |
                  |      |  |  |      |
                  +------+  |  +------+
                  /      \  +-----------------------
                 /        \
                /          \
            +------+    +------+
            |      |    |      |
            |      |    |      |
            +------+    +------+\
                |           |    \             | Exchange point
            +------+    +------+  \  +------+  |  +------+
            |      |    |      |   \_|      |  |  |      |--
            |      |    |      |     |      |  |  |      |--
            +------+   /+------+     +------+  |  +------+
                |     /     |                  |
            +-------+/  +-------+              |
            |       |   |       |
            |Access1|   |Access2|
            |       |   |       |
            +-------+   +-------+
              |||||       |||||  ISP Network
                |           |    Customer Networks
            +--------+  +--------+
            |        |  |        |
            |Customer|  |Customer|
            |        |  |        |
            +--------+  +--------+
                  Figure 3: ISP Sample Network Layout.

8.1 Example 1

   Example 1 presents a network built according to the sample network
   layout with a native IPv4 backbone. The backbone is running IS-IS and
   IBGP as routing protocols for internal and external routes,
   respectively. MBGP Multiprotocol BGP is used to exchange routes over the
   connections to ISP2 and the exchange point. Multicast using PIM-SM
   routing is present. QoS using DiffServ is deployed.

   Access 1 is xDSL connected to the backbone through an access router.
   The xDSL equipment, except for the access router, is considered to be
   layer 2 only, e.g., Ethernet or ATM. IPv4 addresses are dynamically
   assigned to the customer using DHCP. No routing information is
   exchanged with the customer. Access control and traceability are preformed
   performed in the access router. Customers are separated into VLANs or
   separate ATM PVCs up to the access router.

   Access 2 is Fiber "fiber to the building or home home" (FTTB/H) connected
   directly to the backbone router. This connection is considered to be
   layer-3-aware, because it is using layer 3 switches and it performs
   access control and traceability through its layer 3 awareness by
   using DHCP snooping. IPv4 addresses are dynamically assigned to the
   customers using DHCP. No routing information is exchanged with the

   The actual IPv6 deployment might start by enabling IPv6 on a couple
   of backbone routers, configuring tunnels between them (if not
   adjacent), and connecting to a few peers or upstream providers
   (either through tunnels or at an internet exchange).

   After a trial period, the rest of the backbone is upgraded to dual-
   stack, and IS-IS without multi-topology extensions (the upgrade order
   is considered with care) is used as an IPv6 and IPv4 IGP. When
   upgrading, it's important to note that until IPv6 customers are
   connected behind a backbone router, the convexity requirement is not
   critical: the routers just will just not be able to be reached reachable using IPv6.  That
   is, a software supporting IPv6 could be installed even though the
   routers would not be used for (customer) IPv6 traffic yet.  That way,
   IPv6 could be enabled in the backbone on a need-to-enable basis when

   Separate IPv6 BGP sessions are built, similar to IPv4. Multicast
   (through SSM and Embedded-RP) and DiffServ are offered at a later
   phase of the network, e.g., after a year of stable IPv6 unicast

   Customers (with some exceptions) are not connected using a tunnel
   broker, because offering

   Offering native service faster as quickly as possible is considered more
   important -- and then there will not be unnecessary parallel
   infrastructures to tear down later on. most
   important. However, a 6to4 relay is may be provided in the meantime for
   optimized 6to4 connectivity. connectivity and it may also be combined with a tunnel
   broker for extended functionality. xDSL equipment, operating as
   bridges at Layer 2 only, do does not require changes in CPE: IPv6
   connectivity can be offered to the customers by upgrading the PE
   router to IPv6. In the initial phase, only Router Advertisements are
   used; DHCPv6 Prefix Delegation can be added as the next step if no
   other mechanisms are available.

   The FTTB/H access has to be upgraded to support access control and
   traceability in the switches, probably by using DHCP snooping or a
   similar IPv6 capability, but it also has to be compatible with prefix
   delegation and not just address assignment. This could, however, lead
   to the need to use DHCPv6 for address assignment.

8.2 Example 2

   In example 2 the backbone is running IPv4 with MPLS and is using OSPF
   and IBGP are for internal and external routes respectively. The
   connections to ISP2 and the exchange point run BGP to exchange
   routes. Multicast and QoS are not deployed.

   Access 1 is a fixed line, e.g., fiber, connected directly to the
   backbone. Routing information is in some cases exchanged with CPE at
   the customer's site; otherwise static routing is used. Access 1 can
   also be connected to a BGP/MPLS-VPN running in the backbone.

   Access 2 is xDSL connected directly to the backbone router. The xDSL
   is layer 2 only, and access control and traceability are achieved
   through PPPoE/PPPoA. PPP also provides address assignment. No routing
   information is exchanged with the customer.

   IPv6 deployment might start with an upgrade of a couple of PE routers
   to support [BGPTUNNEL], because this will allow large-scale IPv6
   support without hardware or software upgrades in the core. In a later
   phase, perhaps years later,
   phase native IPv6 traffic or IPv6 LSPs would run natively be used in the whole
   network. In that case IS-IS or OSPF could be used for the internal
   routing, and a separate IPv6 BGP session would be run.

   For the fixed-line customers customers, the CPE has to be upgraded and prefix
   delegation using DHCPv6 or static assignment would be used. An IPv6
   MBGP session would be used when routing information has to be
   exchanged. In the xDSL case the same conditions for IP-tunneling as
   in Example 1 apply. In addition to IP-tunneling an additional PPP
   session can be used to offer IPv6 access to a limited number of
   customers. Later, when clients and servers have been updated, the
   IPv6 PPP session can be replaced with a combined PPP session for both
   IPv4 and IPv6. PPP has to be used for address and prefix assignment.

8.3 Example 3

   A transit provider offers IP connectivity to other providers, but
   not to end users or enterprises. IS-IS and IBGP are used internally
   and BGP externally. Its accesses connect Tier-2 provider cores. No
   multicast or QoS is used.

   Even though the RIR policies on getting IPv6 prefixes require the
   assignment of at least 200 /48 prefixes to the customers, this type
   of transit provider obtains an allocation nonetheless, as the number
   of customers their customers serve is significant. The whole backbone
   can be upgraded to dual-stack in a reasonably rapid pace after
   trialing it a
   trial with a couple of routers. IPv6 routing is performed using the
   same IS-IS process and separate IPv6 BGP sessions.

   The ISP provides IPv6 transit to its customers for free, as a
   competitive advantage. It also provides, at the first phase only, a
   configured tunnel service with BGP peering to the significant sites
   and customers (those with an AS number) which are the customers of
   its customers whenever its own customer networks are not offering
   IPv6. This is done both to introduce them to IPv6 and to create a
   beneficial side-effect: a bit of extra revenue is generated from its
   direct customers as the total amount of transited traffic grows.

9. Security Considerations

   This document analyses scenarios and identifies some transition
   mechanisms that could be used for the scenarios. It does not
   introduce any new security issues. Security considerations of each
   mechanism are described in the respective documents.

   However, a few generic observations are in order.

        o introducing IPv6 adds new classes of security threats or
          requires adopting new protocols or operational models
          than with IPv6; IPv4; typically these are generic issues, and
          to be further discussed in other documents, for example,

        o the more complex the transition mechanisms employed become,
          the more difficult it will be to manage or analyze their
          impact on security; consequently, security. Consequently, simple mechanisms are to
          be preferred.

        o this document has identified a number of requirements for
          analysis or further work which should be explicitly considered
          when adopting IPv6: how to perform access control over
          shared media or shared ISP customer connection media,
          how to manage the configuration management security on such
          environments (e.g., DHCPv6 authentication keying), and
          how to manage customer traceability if stateless address
          autoconfiguration is used.

10. Acknowledgements

   This draft has greatly benefited from inputs by Marc Blanchet, Jordi
   Palet, Francois Le Faucheur Faucheur, Ronald van der Pol and Cleve Mickles.
   Special thanks to Richard Graveman and Michael Lambert for
   proofreading the document.

11. Informative References

   [EMBEDRP]       Savola, P., Haberman, B., "Embedding the Address of
                   RP in IPv6 Multicast Address" -
                   Work in progress

   [MTISIS]        Przygienda, T., Naiming Shen, Nischal Sheth, "M-
                   ISIS: Multi Topology (MT) Routing in IS-IS"
                   Work in progress

   [RFC 2858]      T. Bates, Y. Rekhter, R. Chandra, D. Katz,
                   "Multiprotocol Extensions for BGP-4"
                   RFC 2858

   [RFC 2545]      P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol
                   Extensions for IPv6 Inter-Domain Routing"
                   RFC 2545

   [BCP38UPD]      F. Baker, P. Savola "Ingress Filtering for
                   Multihomed Networks"
                   Work in progress

   [RFC3582]      J. Abley, B. Black, V. Gill, "Goals for IPv6 Site-
                  Multihoming Architectures"
                  RFC 3582

   [RFC3178]      J. Hagino, H. Snyder, "IPv6 Multihoming Support at
                  Site Exit Routers"
                  RFC 3178

   [BGPTUNNEL]    J. De Clercq, G. Gastaud, D. Ooms, S. Prevost,
                  F. Le Faucheur "Connecting IPv6 Islands across IPv4
                  Clouds with BGP"
                  Work in progress

   [DUAL ACCESS]  Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi
                  "A Model of IPv6/IPv4 Dual Stack Internet Access
                  Work in progress

   [UNMANCON]     T.Chown, R. van der Pol,

   [STEP]         P. Savola, "Considerations
                  for IPv6 Tunneling Solutions "Simple IPv6-in-IPv4 Tunnel Establishment
                  Procedure (STEP)"
                  Work in Small End Sites" progress

   [TSP]          M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup
                  Protocol (TSP)"
                  Work in progress

   [TUNREQS]      A. Durand, F. Parent "Requirements for assisted
                  Work in progress
   [UNMANEVA]     C. Huitema, R. Austein, S. Satapati, R. van der Pol,
                  "Evaluation of Transition Mechanisms for Unmanaged
                  Work in progress

   [PROTO41]      J. Palet, C. Olvera, D. Fernandez, "Forwarding
                  Protocol 41 in NAT Boxes"
                  Work in progress

   [V6SEC]        P. Savola, "IPv6 Transition/Co-existence Security
                  Work in progress

Authors' Addresses

   Mikael Lind
   Vitsandsgatan 9B
   SE-12386 Farsta, Sweden

   Vladimir Ksinant
   6WIND S.A.
   Immeuble Central Gare - Bat.C
   1, place Charles
   Thales Communications
   160, boulevard  de Gaulle
   78180, Montigny-Le-Bretonneux - Valmy
   92704 Colombes, France
   Phone: +33 1 39 30 92 36

   Soohong Daniel Park
   Mobile Platform Laboratory, SAMSUNG Electronics.
   416, Maetan-3dong, Paldal-Gu,
   Suwon, Gyeonggi-do, Korea

   Alain Baudot
   France Telecom R&D
   42, rue des coutures
   14066 Caen - FRANCE

   Pekka Savola
   Espoo, Finland

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

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

   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.