[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 RFC 4029

  Internet-Draft                                                M. Lind
  <draft-ietf-v6ops-isp-scenarios-analysis-00.txt>          TeliaSonera
  Expires : May 2004                                         V. Ksinant
                                                                  6WIND
                                                                D. Park
                                                    Samsung Electronics
                                                              A. Baudot
                                                         France Telecom
                                                          December 2003
  
  
  
         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-
     Drafts.
  
     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
     http://www.ietf.org/ietf/1id-abstracts.txt
  
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
  
  
  Abstract
  
     This document first describes different scenarios for the
     introduction of IPv6 into an existing IPv4 ISP network without
     disrupting the IPv4 service. Then, this document analyses these
     scenarios and evaluates the suitability of the already defined
     transition mechanisms in this context. Known challenges are also
     identified.
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 1]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  Table of Contents
  
  1.   Introduction..................................................3
        1.1  Goal and scope of the document..........................3
        1.2  Terminology used........................................3
  2.   Brief description of a generic ISP network....................4
  3.   Transition scenarios..........................................6
        3.1  Identification of scenarios.............................6
        3.1.1  Assumptions............................................6
        3.1.2  Customer requirements and ISP offerings................7
        3.1.3  Stage 1 Scenarios: Launch..............................8
        3.1.4  Stage 2a Scenarios: Backbone...........................8
        3.1.5  Stage 2b Scenarios: Customer connection................8
        3.1.6  Stage 3 scenarios: Complete............................9
        3.1.7  Stage 2a and 3 combination scenarios...................9
        3.2  Transition Scenarios....................................9
        3.3  Actions needed when deploying IPv6 in an ISP network...10
  4.   Backbone transition actions..................................11
        4.1  Steps in transitioning backbone networks...............11
        4.2  Configuration of backbone equipment....................13
        4.3  Routing................................................13
        4.3.1  IGP...................................................13
        4.3.2  EGP...................................................14
        4.3.3  Routing protocols transport...........................15
        4.4  Multicast..............................................15
  5.   Customer connection transition actions.......................15
        5.1  Steps in transitioning customer connection networks....15
        5.2  Access control requirements............................17
        5.3  Configuration of customer equipment....................17
        5.4  Requirements for Traceability..........................18
        5.5  Multi-homing...........................................18
        5.6  Ingress filtering in the customer connection network...19
  6.   Network and service operation actions........................19
  7.   Future Stages................................................20
  8.   Example networks.............................................20
        8.1  Example 1..............................................22
        8.2  Example 2..............................................22
        8.3  Example 3..............................................23
  9.   Security Considerations......................................23
  10.  Acknowledgements.............................................23
  11.  Informative references.......................................23
  
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 2]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  1. Introduction
  
  1.1 Goal and scope of the document
  
     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
     existing IPv4 service and the introduction of the IPv6 must not
     interrupt this IPv4 service. The case of an IPv6-only service
     provider is not addressed in this document.
  
     An ISP offering an IPv4 service will find that there are different
     ways to add IPv6 to this service. This document discusses a small
     set of scenarios for the introduction of IPv6 in an ISP IPv4
     network. It evaluates the suitability of the existing transition
     mechanisms in the context of these deployment scenarios, and it
     points out the lack of functionality essential to the ISP operation
     of an IPv6 service..
  
  
     The present document is focused on services that include both IPv6
     and IPv4 and does not cover issues surrounding an IPv6-only service.
     It is also outside the scope of this document to describe different
     types of access or network technologies.
  
  1.2 Terminology used
  
     This section defines and clarifies the terminology used in this
     document:
  
     "CPE"         : Customer Premise Equipment
  
     "PE"          : Provider Edge equipment
  
     "Network and service operation":
                   : This is the part of the ISP network which hosts the
                     services required for the correct operation of the
                     ISP network. These services usually include
                     management, supervision, accounting, billing and
                     customer management applications.
  
     "Customer connection":
                   : This is the part of the network which is used by a
                     customer when connecting to an ISP network. It
                     includes the CPEs, the last hop links and the parts
  
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 3]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
                     of the PE interfacing to the last hop links.
  
     "Backbone"    :
                     This is the rest of the ISP network infrastructure.
                     It includes the parts of the PE interfacing to the
                     core, the core routers of the ISP and the
                     border routers used in order to exchange routing
                     information with other ISPs (or other administrative
                     entities).
  
     "Dual-stack network":
                     A network which supports natively both IPv4 and
                     IPv6.
  
  2. Brief description of a generic ISP network
  
     A generic ISP network topology can be divided into two main parts;
     the backbone network and the customer connection networks connecting
     the customers.
  
     The backbone is the part of the network that interconnects the
     different customer connection networks and provides transport to the
     rest of the Internet via exchange points or other means. The
     backbone network can be built on different technologies but in this
     document the only interest is whether it is capable of carrying IPv6
     traffic natively or not. Since there is no clear definition of
     "backbone", it is defined in this document as being all routers that
     are a part of the same routed domain in the transport network. This
     means that all routers up to (and including, at least partially) the
     PE router are a part of the backbone.
  
     The customer connection networks provide connectivity to enterprise
     and private customers. Other ISPs might as well be customers and
     connected to the ISP's customer connection network. As with the
     backbone the absence or presence of native IPv6 capability is the
     only thing of real interest in the customer connection network
     technology.
  
     It is noticeable that, in some cases (e.g. incumbent national or
     regional operators), a given customer connection network may have
     to be shared between different ISPs. According to the type of the
     customer connection network used (e.g. involving only layer 2
     devices, or involving non-IP technology), this constraint may result
     in architectural considerations that may be relevant in this
     document.
  
  
  Lind, et al.              Expires - May 2004                  [Page 4]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
     "Network and service operation" building blocks refer to the basic
     main functions needed for a regular backbone operation. This
     building block is dealing with: network management, customers'
     authentication and accounting, address assignment and naming. It
     represents the minimum functions needed to provide a customer
     service, referring to both network infrastructure operation, and
     administrative management of customers.
  
     It doesn't matter if these customer networks have a single node or a
     large routed network. What is of interest is if routing information
     is exchanged or not since it will affect the ISP's network. The
     existence of customer premise equipment will also affect how a
     service can be delivered. In addition to the ISP's actual network
     components there are a lot of support and backend systems that have
     to be considered.
  
     The basic components in an ISP network are depicted in Figure 1.
  
          ------------    ----------
         | Network and|  |          |
         |  service   |--| Backbone |
         | operation  |  |          |\
          ------------    ----------  \
             .             / |  \       \
             .            /  |   \       \_Peering( Direct & IX )
             .           /   |    \
             .          /    |     \
             .         /     |      \
       ----------     /   ---------- \     -----------
      | Customer |   /   | Customer | \   | Customer |
      |Connection|--/    |Connection|  \--|Connection|
      |     1    |       |     2    |     |     3    |
       ----------         ----------       ----------
           |                  |               |         ISP Network
       -------------------------------------------------------
           |                  |               |     Customer Networks
       +--------+        +--------+      +--------+
       |        |        |        |      |        |
       |Customer|        |Customer|      |Customer|
       |        |        |        |      |        |
       +--------+        +--------+      +--------+
        Figure 1: ISP network topology
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 5]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
  
  3. Transition scenarios
  3.1 Identification of scenarios
  
     This section describes different stages an ISP might consider when
     introducing IPv6 connectivity in the existing IPv4 network and the
     different scenarios that might occur in the respective stages.
  
     The stages here are snapshots of an ISP's network with respect to
     IPv6 maturity. Since an ISP's network is constantly evolving, a
     stage is a measure of how far an ISP has come in turn of
     implementing necessary functionality to offer IPv6 to the customers.
  
     It is possible to freely transition between different stages.
     However, a network segment can only be in one stage at a time but an
     ISP network as a whole can be in different stages. There are
     different transition paths between the first and final stage. The
     transition between two stages does not have to be immediate but can
     occur gradually.
  
     Each stage has different IPv6 properties. An ISP can therefore,
     based on the requirements it has, decide into which stage it will
     transform its network.
  
     This document is not aimed to cover very small or small ISPs or
     hosting providers/data centers; only the scenarios applicable to the
     ISPs eligible for a /32 IPv6 prefix allocation from a RIR are
     covered.
  
  3.1.1 Assumptions
  
     The stages are derived from the generic description of an ISP
     network in section 2. A combination of different building blocks
     that constitute an ISP environment will lead to a number of
     scenarios, which an ISP can choose from.  The scenarios of most
     relevance to this document are considered to be the ones that in the
     most efficient and feasible way maximize the ability for an ISP to
     offer IPv6 to its customers.
  
     The most predominant case today is considered to be an operator with
     a core and access IPv4 network delivering IPv4 service to a customer
     that is running IPv4 as well.  At some point in the future, it is
     expected that the customer will want to have an IPv6 service, in
  
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 6]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     addition to the already existing IPv4 service. This IPv6 service may
     be offered by the same ISP, or by a different one. Anyway the
     challenge for the ISP is to deliver the requested IPv6 service over
     the existing infrastructure and at the same time keep the IPv4
     service intact.
  
  3.1.2 Customer requirements and ISP offerings
  
     Looking at the scenarios from the end customer's perspective there
     might be a demand for three different services; the customer might
     demand IPv4 service, IPv6 service or both services. This can lead to
     two scenarios depending on the stage the ISP's network is in.
  
     If an ISP only offers IPv4 or IPv6 service and a customer wants to
     connect a device or network that only supports one service and if
     that service is not offered, it will lead to a dead-end. If the
     customer or ISP instead connects a dual stack device it is possible
     to circumvent the lack of the missing service in the customer
     connection network by using some kind of tunneling mechanism. This
     scenario will only be considered in the perspective of the ISP
     offering a mechanism to bridge the customer connection and reach the
     IPv6 backbone.
  
     In the case where the customer connects a single stack device to a
     corresponding single stack customer connection network or when the
     customer connects a single stack device to a dual stack customer
     connection network is covered by the all over dual stack case.
     Therefore, neither of these cases need further be explored
     separately in this document but can be seen as a part of a full dual
     stack case.
  
     After eliminating a number of cases explained above, there are four
     stages that are most probable and where an ISP will find its network
     in. Which stage a network is in depends on whether or not some part
     of the network previously has been upgraded to support IPv6 or if it
     is easier to enable IPv6 in one part or another. For instance,
     routers in the backbone might have IPv6 support or might be easily
     upgradeable, while the hardware in the customer connection network
     might have to be completely replaced in order to handle IPv6
     traffic.
  
     Note that in every stage except Stage 1, the ISP can offer both IPv4
     and IPv6 services to the customer.
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 7]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     The four most probable stages are:
  
           o Stage 1      Launch
           o Stage 2a     Backbone
           o Stage 2b     Customer connection
           o Stage 3      Complete
  
     Generally the ISP is able to upgrade current IPv4 network to
     IPv4/IPv6 dual-stack network via Stage 2b but the IPv6 service can
     also be implemented at a small cost with simple tunnel mechanisms on
     the existing system. When designing a new network, Stage 3 might be
     the first and last step since there are no legacy concerns. Absence
     of IPv6 capability in the network equipment can still be a limiting
     factor nevertheless.
  
  3.1.3 Stage 1 Scenarios: Launch
  
     The first stage is an IPv4 only ISP with an IPv4 customer. This is
     the most common case today and has to be the starting point for the
     introduction of IPv6.  From this stage, an ISP can move (transition)
     to any other stage with the goal to offer IPv6 to its customer.
  
     The immediate first step consists of getting a prefix allocation
     (typically a /32) from the appropriate RIR according to allocation
     procedures.
  
  3.1.4 Stage 2a Scenarios: Backbone
  
     Stage 2a is an ISP with customer connection networks that are IPv4
     only and a backbone that supports both IPv4 and IPv6. In particular,
     the ISP considers it possible to make the backbone IPv6 capable
     either through software or hardware upgrade, or a combination of
     both. In this stage the customer should have support for both IPv4
     and IPv6. The ISP has to provide IPv6 connectivity through its IPv4
     customer connection networks.
  
     In particular, the existence of NATs and firewalls in the path (at
     the CPE, or in the customer's network) need to be considered.
  
  3.1.5 Stage 2b Scenarios: Customer connection
  
     Stage 2b is an ISP with a backbone network that is IPv4 and an
     customer connection network that supports both IPv4 and IPv6. Since
     the service to the customer is native IPv6 there is no requirement
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 8]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     for the customer to support both IPv4 and IPv6. This is the biggest
     difference in comparison to the previous stage.  The need to
     exchange IPv6 traffic or similar still exists but might be more
     complicated than in the previous case since the backbone isn't IPv6
     enabled. After completing stage 2b the original IPv4 backbone still
     is unchanged. This doesn't imply that there is no IPv6 backbone just
     that the IPv6 backbone is an overlay to or partially separated from
     the IPv4 backbone.
  
     Generally, the ISP will continue providing IPv4 connectivity; in
     many cases private addresses and NATs will continue to be used.
  
  3.1.6 Stage 3 scenarios: Complete
  
     Stage 3 can be said to be the final step in introducing IPv6, at
     least in the scope of this document. This is an all over IPv6
     service with native support for IPv6 and IPv4 in both backbone and
     customer connection networks. This stage is identical to the
     previous stage in the customer's perspective since the customer
     connection network hasn't changed. The requirement for exchanging
     IPv6 traffic is identical to stage 2.
  
  3.1.7 Stage 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 some do; and the
     backbone is dual-stack.
  
     This is equivalent to stage 2a, but requiring support for native
     IPv6 customer connections on some access technologies.
  
  
  3.2 Transition Scenarios
  
     Given the different stages it is clear that the ISP has to be able
     to transition from one stage to another. The initial stage, in this
     document, is the IPv4 only service and network. The end stage is the
     dual IPv4/IPv6 service and network. As mentioned in the scope, this
     document does not cover the IPv6 only service and network and its
     implications on IPv4 customers. This has nothing to do with the
     usability of an IPv6 only service.
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                  [Page 9]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     The transition starts out with the IPv4 ISP and then moves to one of
     three choices.  These choices are the different transition
     scenarios. One way would be to upgrade the backbone first which
     leads to stage 2a. Another way to go could be to upgrade the
     customer connection network which leads to stage 2b. The final
     possibility is to introduce IPv6 in both the backbone and customer
     connections as needed which would lead to stage 3.
  
     The choice is dependent on many different issues. For example it
     might not be possible to upgrade the backbone or the customer
     connection network without large investments in new equipment which
     could lead to any of the two first choices. In another case it might
     be easier to take the direct step to a complete IPv6/IPv4 network
     due to routing protocol issues or similar.
  
     If a partially upgraded network (stage 2a or 2b) was chosen as the
     first step, a second step remains before the network is all over
     native IPv6/IPv4. This is the transition to an all over dual stack
     network.  This step is perhaps not necessary for stage 2b with an
     already native IPv6 service to the customer but might still occur
     when the timing is right. For stage 2a it is more obvious that a
     transition to a dual stack network is necessary since it has to be
     done to offer a native IPv6 service.
  
     As most of the ISPs keep evolving continuously their backbone IPv4
     networks (new firmware versions in the routers, new routers), they
     will be able to get them IPv6 ready, without additional investment,
     except the staff training. It may be a slower transition path, but
     useful since it allows an IPv6 introduction without any actual
     customer demand. This will probably be better than making everything
     at the last minute with a higher investment.
  
  3.3 Actions needed when deploying IPv6 in an ISP network
  
     When looking at the transitions described above, it appears that it
     is possible to split the work required by each transition in a small
     set of actions. Each action is mostly independent from the others
     and some actions may be common to several transitions.
  
     The analysis of the possible transitions leads to a small list of
     actions:
  
        * backbone transition actions:
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 10]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
           - 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
             steps,
  
  
        * customer connection transition actions:
  
           - Connect IPv6 customers to an IPv6 backbone through an IPv4
             network,
  
           - Transform an IPv4 customer connection network into a dual-
             stack one,
  
        * network and service operation transition actions:
           - configure IPv6 functions into either backbone or network
             and service operation devices
           - upgrade regular network management and monitoring
             applications to take IPv6 into account
           - [Network and service operation actions - To be completed.]
  
        More detailed descriptions of each action follow.
  
  4. Backbone transition actions
  
  4.1  Steps in transitioning backbone networks
  
     In terms of physical equipment, backbone networks consist mainly in
     core and edge high-speed routers. Border routers provide peering
     with other providers. Filtering, routing policy and policing type
     functions are generally managed on border routers.
  
     The initial step is an IPv4-only backbone, and the final step is a
     whole dual-stack backbone. In between, intermediate steps may be
     identified:
  
  
  
                         Tunnels         Tunnels
       IPv4-only ---->      or      --->   or         + DS -----> Full DS
                      IPv6 dedicated   IPv6 dedicated  routers
                           links          links
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 11]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
     The first step involves tunnels or dedicated links but existing
     routers are left unchanged. Only a small set of routers then have
     IPv6 capabilities. Configured tunnels are adequate for use during
     this step.
  
     When MPLS is already deployed in the backbone, it may be desirable
     to provide IPv6-over-MPLS connectivity. However, the problem is that
     setting up an IPv6 Label Switched Path (LSP) requires some signaling
     through the MPLS network; both LDP and RSVP-TE can set up IPv6 LSPs,
     but this would require a software upgrade in the MPLS core network.
     A workaround is to use BGP for signaling and/or to perform IPv6-
     over-IPv4/MPLS or IPv6-over-IPv4-over-IPv4/MPLS encapsulation, for
     example, as described in [BGPTUNNEL]. There seem to be multiple
     possibilities, some of which may be more preferable than others.
     More analysis is needed in order to determine which are the best
     approach(es):
  
            1) require that MPLS networks deploy native IPv6 support or
               use configured tunneling for IPv6.
  
            2) require that MPLS networks support setting up IPv6 LSPs,
               and IPv6 connectivity is set up using them, or configured
               tunneling is used.
  
            3) use only configured tunneling over the IPv4 LSPs; this
               seems practical with small-scale deployments when the
               number of tunnels is low.
  
            4) use something like [BGPTUNNEL] to perform IPv6-over-
               IPv4/MPLS encapsulation for IPv6 connectivity.
  
     In the second step, some dual stack routers are added in this
     network in a progressive manner.
  
     The final stage is reached when all or most routers are dual-stack.
  
     According to many reasons (technical, financial, etc), an ISP may
     move forward from step to step or reach directly the final one. One
     of the important criteria in this evolution is the number of IPv6
     customers the ISP gets on its initial deployments. If few customers
     connect to the first IPv6 infrastructure, then the ISP is likely to
     remain on the initial steps for a long time.
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 12]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     In short, each step remains possible, but no one is mandatory.
  
  4.2  Configuration of backbone equipment
  
     In the backbone, the number of devices is small and IPv6
     configuration mainly deals with routing protocols parameters,
     interface addresses, loop-back addresses, ACLs...
  
     These IPv6 parameters are not supposed to be automatically
     configured.
  
  4.3  Routing
  
     ISPs need routing protocols to advertise the reachability and to
     find the shortest working paths both internally and externally.
  
     OSPFv2 and IS-IS are typically used as an IPv4 IGP.
     RIPv2 is typically not in use in operator networks.
     BGP is the only IPv4 EGP.  Static routes are used in both.
  
     Note that it is possible to configure a given network so that it
     results in having an IPv6 topology different from the 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 while some
     others maybe single stacked (IPv4 or IPv6). In this case, the
     routing must be able to manage 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
     appropriate in many contexts and is not discussed here. The IGP
     typically includes the routers' point-to-point and loop-back
     addresses.
  
     The most important decision to make is whether one wishes to have
     separate routing protocol processes for IPv4 and IPv6. Having them
     separate requires more memory and CPU for route calculations e.g.
     when the links flap. On the other hand, the separation provides a
     better reassurance that if problems come up with IPv6 routing, they
     will not affect IPv4 routing protocol at all.  In the first phases
     if it is uncertain whether joint IPv4/IPv6 networks work as
     intended, having separate processes may be desirable and easier to
     manage.
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 13]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
     Thus the combinations are:
  
       - 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
  
       - 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.  In simpler networks or
     with careful planning of IS-IS link costs, it is possible to keep
     even non-congruent IPv4/IPv6 topologies "convex".
  
     Therefore, the use of same process is recommended especially for
     large ISPs which intend to deploy, in the short-term, a fully dual-
     stack backbone  infrastructure.  If the topologies are not similar
     in the short term, two processes (or Multi-topology IS-IS
     extensions) are recommended.
  
     The IGP is not typically used to carry customer prefixes or external
     routes. Internal BGP (iBGP), as described in the next section, is
     most often deployed in all routers to spread the other routing
     information.
  
     As some of the simplest devices, e.g. CPE routers, may not implement
     other routing protocols than RIPng, in some cases it may be
     necessary to also run RIPng in a limited fashion in addition to
     another IGP, and somehow redistribute the routing information to the
     other routing protocol(s).
  
  4.3.2 EGP
  
     BGP is used for both internal BGP and external BGP sessions.
  
     BGP can be used for IPv6 with Multi-protocol extensions [RFC 2858],
     [RFC 2545].  These enable exchanging both IPv6 routing information
     as establishing BGP sessions using TCP over IPv6.
  
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 14]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     It is possible to use a single BGP session to advertise both IPv4
     and IPv6 prefixes between two peers. However, typically, separate
     BGP sessions are used.
  
  4.3.3 Routing protocols transport
  
     IPv4 routing information should be carried by IPv4 transport and
     IPv6 one by IPv6 for several reasons:
  
         * The IPv6 connectivity may work when the IPv4 one 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 may be different
            because, the administrator may want to use different metric
            values for one physical link for load balancing or tunnels
            may be used.
  
  4.4  Multicast
  
     Currently, IPv6 multicast is not a strong concern for most ISPs.
     However, some of them consider deploying it. Multicast is achieved
     using PIM-SM and PIM-SSM protocols. These also work with IPv6.
  
     Information about multicast sources is exchanged using MSDP in IPv4,
     but it is not defined, on purpose, for IPv6. An alternative
     mechanism is to use only PIM-SSM or an alternative mechanism for
     conveying the information [EMBEDRP].
  
     To be completed.  send feedback/text!
  
  5. Customer connection transition actions
  
  5.1  Steps in transitioning customer connection networks
  
     customer connection networks are generally composed of a large
     number of CPEs connected to a small set of PEs. Transitioning this
     infrastructure to IPv6 can be made in several steps, but some ISPs
     may avoid some of the steps depending on their perception of risks.
  
     Connecting IPv6 customers to an IPv6 backbone through an IPv4
     network can be considered as a first careful step taken by an ISP in
     order to provide IPv6 services to its IPv4 customers. More, some
     ISPs also provide IPv6 services to customers who get their IPv4
     services from another ISP.
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 15]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
     This 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 an IPv6 specific CPE or even on a host).
  
     Several tunneling techniques have already been defined: configured
     tunnels with tunnel broker, 6to4, Teredo...
  
     The selection of one candidate depends largely on the presence or
     not of NATs between the two tunnel end-points, and whether the
     user's IPv4 tunnel end-point address is static or dynamic. In most
     cases, 6to4 and ISATAP are incompatible with NATs and an UDP
     encapsulation for configured tunnels has not been specified.
  
     Firewalls in the way can also break these types of tunnels. The
     administrator of the firewall will have to create a hole for the
     tunnel. It is not a big deal as long as the firewall is controlled
     either by the customer or the ISP, which is almost always the case.
  
     An ISP has practically two kinds of customers in the customer
     connection networks: small end users (mostly "unmanaged networks";
     home and SOHO users), and others. The former category typically has
     a dynamic IPv4 address which is often NATted; 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 configuring the NAT may be required to reach an
     internal IPv6 access router, though.
  
     Tunneling consideration for small and end sites are discussed in
     [UNMANCON], that may identify solutions relevant to the first
     category of unmanaged network. These solutions will be further
     discussed within an ISP context, when available.
  
     For the second category, usually:
  
     * Configured tunnels as-is are a good solution when an NAT is not in
     the way and the IPv4 end-point addresses are static. A mechanism to
     punch through NATs or to forward packets through it may be desirable
     in some scenarios. If fine-grained access control is needed, an
     authentication protocol needs to be used.
  
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 16]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     * 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 way needs to be determined.
  
     * Automatic tunneling mechanisms such as 6to4 or Teredo are not
     applicable in this scenario.
  
     Some other ISPs may take a more direct approach and avoid the use of
     tunnels as much as possible.
  
     Note that when the customers use dynamic IPv4 addresses, the
     tunneling techniques may be more difficult at the ISP's end,
     especially if a protocol not including authentication (like PPP for
     IPv6) is not used. This may need to be considered in more detail
     with tunneling mechanisms.
  
  5.2  Access control requirements
  
     Access control is usually required in ISP networks because the ISPs
     need to control to who they are giving access. For instance, it is
     important to check if the user who tries to connect is really a
     valid customer. In some cases, it is also important for billing
     purposes.
  
     However, an IPv6 specific access control is not always required.
     This is for instance the case when a customer of the IPv4 service
     has automatically access to the IPv6 service. Then, the IPv4 access
     control also gives access to the IPv6 services.
  
     When the provider does not wish to give to its IPv4 customers
     automatically access to IPv6 services, a specific access control for
     IPv6 must be performed in parallel to the IPv4 one. It does not mean
     that a different user authentication must be performed for IPv6, but
     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 an IPv6 service can be transported over
     IPv4.
  
  5.3  Configuration of customer equipment
  
     The customer connection networks are composed of CPEs and PEs.
     Usually, each PE connects a large number of CPEs to the backbone
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 17]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     network infrastructure. This number may reach tens of thousands or
     more. The configuration of CPEs is an heavy task for the ISP and
     this is even made harder as the configuration must be done remotely.
     In this context, the use of auto-configuration mechanisms is very
     beneficial, even if manual configuration is still an option.
  
     The parameters that usually need to be automatically provided to the
     customers are:
  
           - The network prefix delegated by the ISP,
           - The address of the Domain Name System server (DNS),
           - Some other parameters such as the address of an NTP server
     may also be needed sometimes.
  
     When access control is required on the ISP network, DHCPv6 can
     provide the configuration parameters. This is discussed more in
     details in [DUAL ACCESS].
  
     When access control is not required (unusual case), a stateless
     mechanism could be used, but no standard definition exists at the
     moment.
  
  5.4 Requirements for Traceability
  
     Most ISPs have some kind of mechanism to trace the origin of traffic
     in their networks. This has also to be available for IPv6 traffic.
     This means that specific IPv6 address or prefix has to be tied to a
     certain customer, or that records of which customer had which
     address/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 in a database. It can also be
     done by assigning a static address or refix to the customer.
  
     For any traceability to be useful, ingress filtering must be
     deployed towards all the customers.
  
  5.5  Multi-homing
  
     Customers may desire multihoming or multi-connecting for a number of
     reasons [RFC3582].
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 18]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     Multihoming to more than one ISP is a subject still under debate.
     Deploying multiple addresses from each ISP and using the addresses
     of the ISP when sending traffic to that ISP is at least one working
     model; in addition, tunnels may be used for robustness [RFC3178].
     Currently, there are no provider-independent addresses for end-
     sites.
  
     Multi-connecting more than once to just one ISP is a simple
     practice, and this can be done e.g. with BGP with public or private
     AS numbers and a prefix assigned to the customer.
  
     To be further defined as the multihoming situation gets clearer.
  
  5.6  Ingress filtering in the customer connection network
  
     Ingress filtering must be deployed everywhere towards the customers,
     to ensure traceability, prevent DoS attacks using spoofed addresses,
     prevent illegitimate access to the management infrastructure, etc.
  
     The ingress filtering can be done for example using access lists or
     Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
     described in [BCP38UPD].
  
  6. Network and service operation actions
  
     The network and service operation actions fall into different
     categories listed below:
  
         - IPv6 network devices configuration: for initial configuration
           and updates
         - IPv6 Network Management
         - IPv6 Monitoring
         - IPv6 customer management
         - built-in "network and service operation" IPv6 security
  
     Some of these actions will require an IPv6 native transport layer to
     be available, while some other will not.
  
     In a first step, network devices configuration and regular network
     management operations can be performed over an IPv4 transport, as
     IPv6 MIBs are also available over IPv4 transport.
  
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 19]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     Nevertheless, some monitoring functions require IPv6 transport
     availability. This is for instance the case when ICMP messages are
     used by the monitoring applications.
  
     In a second step, IPv6 transport can be provided for any of these
     network and service operation facilities.
  
     [To be completed, send feedback/text!]
  
  7. Future Stages
  
     After a while the ISP might want to transition to a service that is
     IPv6 only, at least in certain parts of the network.  This
     transition creates a lot of new cases in which to factor in how to
     maintain the IPv4 service.  Providing an IPv6 only service is not
     much different than the dual IPv4/IPv6 service described in stage 3
     except from the need to phase out the IPv4 service.  The delivery of
     IPv4 services over an IPv6 network and the phase out is left for a
     future document.
  
  8. Example networks
  
     In this section, a number of different network examples are
     presented. They are only example networks and will not necessary
     match to any existing networks. Nevertheless, the examples will
     hopefully be useful even in the cases when they do not match the
     target networks. The purpose of the example networks is to exemplify
     the applicability of the transition mechanisms described in this
     document on a number of different example networks with different
     prerequisites.
  
     The example network layout will be the same in all network examples.
     The networks examples are to be seen as a specific representation of
     the generic network with a limited number of network devices. An
     arbitrary number (in this case 7) of routers have been selected to
     represent the network examples. However, since the network examples
     follow the implementation strategies recommended for the generic
     network scenario, it should be possible to scale the example to fit
     a network with an arbitrary number, e.g. several hundreds or
     thousands, of routers.
  
     The routers in the example are interconnected with each other as
     well as with another ISP. The connection to another ISP can either
     be a direct connection or through an exchange point. In addition to
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 20]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     these connections, there are also a number of customer connection
     networks connected to the routers. customer connection networks are
     normally connected to the backbone via access routers, but can in
     some cases be directly connected to the backbone routers. As
     described earlier in the generic network scenarios, the customer
     connection networks are used to connect the customers. customer
     connection networks can, for example, be xDSL or cable network
     equipment.
                         |
                    ISP1 | ISP2
               +------+  |  +------+
               |      |  |  |      |
               |Router|--|--|Router|
               |      |  |  |      |
               +------+  |  +------+
               /      \  +-----------------------
              /        \
             /          \
         +------+    +------+
         |      |    |      |
         |Router|----|Router|
         |      |    |      |
         +------+    +------+\
             |           |    \             | Exchange point
         +------+    +------+  \  +------+  |  +------+
         |      |    |      |   \_|      |  |  |      |--
         |Router|----|Router|----\|Router|--|--|Switch|--
         |      |    |      |     |      |  |  |      |--
         +------+   /+------+     +------+  |  +------+
             |     /     |                  |
         +-------+/  +-------+              |
         |       |   |       |
         |Access1|   |Access2|
         |       |   |       |
         +-------+   +-------+
           |||||       |||||  ISP Network
         ----|-----------|----------------------
             |           |    Customer Networks
         +--------+  +--------+
         |        |  |        |
         |Customer|  |Customer|
         |        |  |        |
         +--------+  +--------+
               Figure 2: ISP network example
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 21]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
  
  8.1 Example 1
  
     In example 1 a network built according to the example topology is
     present with a native IPv4 backbone, the routers. The backbone is
     running IS-IS and IBGP as routing protocol for internal and external
     routes respectively. In the connection to ISP2 and the exchange
     point MBGP is used to exchange routes. Multicast is present and is
     using PIM-SM routing. QoS is present and is using DiffServ.
  
     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 is done in the access router. Customers are separated
     in VLANs or separate ATM PVCs up to the access router.
  
     Access 2 is Fiber to the building/home connected directly to the
     backbone router. The FTTB/H is considered to be layer 3 aware and
     performs access control and traceability through its layer 3
     awareness. IPv4 addresses are dynamically assigned to the customers
     using DHCP. No routing information is exchanged with the customer.
  
  
  8.2 Example 2
  
     In example 2 the backbone is running IPv4 with MPLS. Routing
     protocols used are OSPF and IBGP for internal and external routes.
     In the connection to ISP2 and the exchange point BGP is used to
     exchange routes. Multicast and QoS are not present.
  
     Access 1 is a fixed line access, e.g. fiber, connected directly to
     the backbone. CPE is present at the customer and routing information
     is in some cases exchanged otherwise static routing is used. Access
     1 can also be connected to BGP/MPLS-VPN running in the backbone.
  
     Access 2 is xDSL connected directly to the backbone router. The xDSL
     is layer 3 aware. Addresses are dynamically assigned using DHCP.
     Access control is achieved on the physical layer and traceability is
     achieved using DHCP snooping. No routing information is exchanged
     with the customer.
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 22]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
  
  8.3 Example 3
  
     A transit provider offers IP connectivity to other providers, but
     not to end users or enterprises. IS-IS and IBGP is used internally
     and BGP externally. Its accesses connect Tier-2 provider cores. No
     multicast or QoS is used.
  
  
  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.
  
  
  
  10.  Acknowledgements
  
     This draft has greatly benefited from inputs by Pekka Savola, Marc
     Blanchet, Jordi Palet.
  
  
  11.  Informative references
  
     [EMBEDRP]       Savola, P., Haberman, B., "Embedding the Address of
                     RP in IPv6 Multicast Address" -
                     draft-ietf-mboned-embeddedrp-00.txt
  
     [MTISIS]        Przygienda, T., Naiming Shen, Nischal Sheth, "M-
                     ISIS: Multi Topology (MT) Routing in IS-IS"
                     draft-ietf-isis-wg-multi-topology-06.txt
  
     [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"
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 23]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
                     draft-savola-bcp38-multihoming-update-01.txt
  
     [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"
                    draft-ooms-v6ops-bgp-tunnel-00.txt
  
     [DUAL ACCESS]  Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi
                    "A Model of IPv6/IPv4 Dual Stack Internet Access
                    Service"
                    draft-shirasaki-dualstack-service-02.txt
  
     [UNMANCON]     T.Chown, R. van der Pol, P. Savola, "Considerations
                    for IPv6 Tunneling Solutions in Small End Sites"
                    draft-chown-v6ops-unmanaged-connectivity-00
  
  
  Authors' Addresses
  
     Mikael Lind
     TeliaSonera
     Vitsandsgatan 9B
     SE-12386 Farsta, Sweden
     Email: mikael.lind@teliasonera.com
  
     Vladimir Ksinant
     6WIND S.A.
     Immeuble Central Gare - Bat.C
     1, place Charles de Gaulle
     78180, Montigny-Le-Bretonneux - France
     Phone: +33 1 39 30 92 36
     Email: vladimir.ksinant@6wind.com
  
  
     Soohong Daniel Park
     Mobile Platform Laboratory, SAMSUNG Electronics.
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 24]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     416, Maetan-3dong, Paldal-Gu,
     Suwon, Gyeonggi-do, Korea
     Email: soohong.park@samsung.com
  
     Alain Baudot
     France Telecom R&D
     42, rue des coutures
     14066 Caen - FRANCE
     Email: alain.baudot@rd.francetelecom.com
  
  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
     Director.
  
  
  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
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 25]


  Internet-Draft    Introducing IPv6 in ISP Networks       December 2003
  
  
  
     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
     English.
  
     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
     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
     BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  Lind, et al.              Expires - May 2004                 [Page 26]
  

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/