Network Working Group                                  M. Boucadair, Ed.
Internet-Draft                                              C. Jacquenet
Intended status: Standards Track                            JL. Grimault
Expires: August 28, 2010                                 M. Kassi-Lahlou
                                                                P. Levis
                                                          France Telecom
                                                           D. Cheng, Ed.
                                           Huawei Technologies Co., Ltd.
                                                             Y. Lee, Ed.
                                                                 Comcast
                                                       February 24, 2010


          Deploying Dual-Stack Lite (DS-Lite) in IPv6 Network
                 draft-boucadair-dslite-interco-v4v6-03

Abstract

   This document describes a proposal to enhance dual-stack lite
   solution with an additional feature to ease interconnection between
   IPv4 and IPv6 realms.  When deployed, no 'dual-stack'-enabled network
   is required for the delivery of both IPv4 and IPv6 connectivity
   services to customers.  IPv6 transfer capabilities are used for the
   transfer of IPv4-addressed packets in a completely stateless scheme
   between the interconnection nodes and the dual-stack lite AFTR
   node(s).  The proposed dual-stack lite extension is meant to
   encourage (if not accelerate) IPv6 deployment in networks.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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



Boucadair, et al.        Expires August 28, 2010                [Page 1]


Internet-Draft              Extended DS-lite               February 2010


   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.

   This Internet-Draft will expire on August 28, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

















Boucadair, et al.        Expires August 28, 2010                [Page 2]


Internet-Draft              Extended DS-lite               February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Addressing . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  DS-Lite AFTR . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Provisioning . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Procedure  . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  IPv6-IPv4 Interconnection Function (ICXF)  . . . . . . . . . . 11
     5.1.  Provisioning . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Procedure  . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Routing Architecture and Considerations  . . . . . . . . . . . 12
     6.1.  Forwarding Packets from ICXF Router to AFTR  . . . . . . . 12
       6.1.1.  Static Routing . . . . . . . . . . . . . . . . . . . . 13
       6.1.2.  Dynamic Routing  . . . . . . . . . . . . . . . . . . . 13
     6.2.  Forwarding Packets from AFTR to ICXF Router  . . . . . . . 13
       6.2.1.  Static Routing . . . . . . . . . . . . . . . . . . . . 13
       6.2.2.  Dynamic Routing  . . . . . . . . . . . . . . . . . . . 13
   7.  Multicast Considerations . . . . . . . . . . . . . . . . . . . 15
   8.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     13.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  What's New Compared To RFC5565  . . . . . . . . . . . 18
   Appendix B.  Changes Since 02  . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19





















Boucadair, et al.        Expires August 28, 2010                [Page 3]


Internet-Draft              Extended DS-lite               February 2010


1.  Introduction

   Dual-stack lite (a.k.a., DS-Lite)
   [I-D.ietf-softwire-dual-stack-lite], as one IPv6 migration technique,
   directly connects users to IPv6 networks but at the same time
   provides IPv4 services by tunneling IPv4 packets over an IPv6
   network.

   AFTR element, as defined in the DS-Lite architecture, is the
   combination of an IPv4-in-IPv6 tunnel end-point and an IPv4-IPv4 NAT
   implemented in the same node.  In addition, the specification assumes
   that an AFTR is directly connected to the IPv4 network.

   In some deployments, for example, where the service provider wants to
   deploy AFTR in to the IPv6 core network.  AFTR nodes may not be
   directly connected to the IPv4 network.  In this scenario, IPv4
   packets after NAT44 function applied on an AFTR node need to be
   transported over the IPv6 core network to the IPv4 network, and vice
   versa.  This document proposes a framework for this scenario as an
   extension to the DS-Lite specification.

   In this specification, we define a new stateless IPv6-IPv4
   interconnection function (referred to as IPv6-IPv4 ICXF), in a border
   node located at the boundaries between the IPv6 and IPv4 networks.
   The ICXF encapsulates IPv4 packets into IPv6 ones and vice versa.

   The ICXF may be hosted in an ASBR (Autonomous System Border Router)
   or a dedicated node located at the interconnection between IPv6 and
   IPv4 domains.  A router that hosts the ICXF is referred to as an ICXF
   router.

   A customer's outbound IPv4 packet is de-capsulated from IPv4-in-IPv6
   tunnel and then normal NAT44 function is applied on an AFTR.  Since
   an AFTR does not directly connect to the IPv4 network, AFTR will
   encapsulate the IPv4 packet in an IPv4-in-IPv6 packet, with an IPv4-
   Embedded IPv6 destination address [I-D.ietf-behave-address-format],
   and forward it to an ICXF router located in the same IPv6 network but
   with direct connection to the IPv4 network (Note that the traffic is
   received by an ICXF only if the destination IPv4 address is not
   managed by other AFTR nodes in the same IPv6 domain, otherwise
   encapsulated traffic will be handled by an AFTR node).  When the ICXF
   router receives the IPv4-Embedded IPv6 packet, it will de-capsulate
   the packet and forward the IPv4 packet based on the IPv4 destination
   address as usual.

   For an inbound IPv4 packet, the ICXF router will encapsulate the IPv4
   packet into IPv6 packet with the IPv4-Embedded IPv6 address and
   forward it to the appropriate DS-Lite AFTR node, which de-capsulates



Boucadair, et al.        Expires August 28, 2010                [Page 4]


Internet-Draft              Extended DS-lite               February 2010


   the IPv4 packet and then follows the normal procedure defined by DS-
   Lite architecture as if the IPv4 packet is received from a directly
   connected IPv4 network.

   Figure 1 provides an overview of the global architecture.  Customers
   are connected to the service domain via a CPE device.  Several DS-
   Lite AFTR nodes are deployed to manage the traffic sent and received
   by the end-user terminal devices.  The service domain is IPv6 only
   and interconnection with adjacent IPv4 realms is implemented using
   IPv6-IPv4 ICXF.  The distributed deployment mode of AFTR nodes is
   motivated by several reasons such as optimizing intra-domain paths,
   avoiding single point of failure, minimizing the impact on geo-
   localization services, minimizing the amount of customers to be
   impacted by an AFTR node failure, etc.  AFTR deployment model varies
   from service provider to service provider and it is out of scope of
   this specification.

   Note in this architecture, the DS-Lite B4 element (located in a CPE)
   and AFTR still behave exactly as defined in
   [I-D.ietf-softwire-dual-stack-lite], but with additional functions
   added to the AFTR when it does not directly connect to the IPv4
   network.  A new ICXF function is introduced to perform stateless
   IPv6- IPv4 interconnection.  This specification defines new
   requirements on addressing scheme and routing.  More details are
   provided in the following sections.


























Boucadair, et al.        Expires August 28, 2010                [Page 5]


Internet-Draft              Extended DS-lite               February 2010


                 +--------------------------------+
                 |      Service Domain            |         +-----------
  +----+         |                           +---------+    |   IPv4
  |CPE1|---------|                           |IPv6-IPv4|----|  Domain A
  +----+         |                           |  ICXF   |    |
                 |                           +---------+    +-----------
                 |   +-------+                    |
                 |   |DS-Lite|                    |         +-----------
  +----+         |   |AFTR A |               +---------+    |  IPv4
  |CPE2|---------|   +-------+               |IPv6-IPv4|----| Domain B
  +----+         |                           |  ICXF   |    |
                 |                           +---------+    +-----------
                 |   +-------+                    | |
                 |   |DS-Lite|                    | |       +-----------
  +----+         |   |AFTR B |                    | |       | IPv4
  |CPEi|---------|   +-------+                    | +-------| Domain C
  +----+         |                                |         |
                 |                                |         +-----------
                 +--------------------------------+

    |<---IPv6----------->|<-----IPv6------------->|<---IPv4----


                       Figure 1: Global Architecture


2.  Terminology

   This memo defines the following terms:

   o  IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF): refers to the
      function that de-capsulates (resp., encapsulates) the IPv6 (resp.,
      IPv4) packet from DS-Lite AFTR node(s) and forwards the IPv4
      (resp., IPv6) packets to the IPv4 (resp., IPv6) networks.

   o  ICXF router: refers to the border router implemented with IPv6-
      IPv4 ICXF.

   o  DS-Lite AFTR node: refers to the AFTR node whose behavior is
      specified in [I-D.ietf-softwire-dual-stack-lite].  This node
      embeds a Carrier Grade-NAT (CGN) function.  In addition, this
      specification assumes that the DS-Lite AFTR node is only connected
      to an IPv6 network.  In this specification, the AFTR will
      encapsulate the IPv4 packet in an IPv6 packet (IPv4-in-IPv6) after
      the NAT44 function.  The encapsulated IPv6 packet will be
      forwarded to the ICXF router.  This IPv4-inIPv6 encapsulation is
      stateless.




Boucadair, et al.        Expires August 28, 2010                [Page 6]


Internet-Draft              Extended DS-lite               February 2010


   o  Access segment: This segment encompasses both the IP access to the
      customers and to the service provider's network.

   o  Interconnection segment: Includes all nodes and resources which
      are deployed at the border of a given AS (Autonomous System) a la
      BGP.

   o  Core segment: Denotes a set of IP networking capabilities and
      resources which are located between the interconnection and the
      access segments.

   o  IP connectivity information: A set of information (e.g., IP
      address, default gateway, etc.) required to access IP transfer
      delivery service.

   o  Pref6: An IPv6 prefix assigned by LIR.  This prefix is configured
      on both ICXF and AFTR.

   o  FROM-AFTR Address: An IPv4-Embedded IPv6 address that combines an
      IPv6 prefix Pref6 and the destination IPv4 address as defined in
      [I-D.ietf-behave-address-format].

   o  TO-AFTR Address: An IPv4-Embedded IPv6 address
      [I-D.ietf-behave-address-format] that combines an IPv6 prefix
      Pref6 and a destination IPv4 address which configured in an AFTR
      NAT pool.


3.  Addressing

   When a DS-Lite AFTR does not directly connect to the IPv4 network,
   IPv4 packets sent to and received from the IPv4 network by the AFTR,
   must be encapsulated in IPv6 packets.

   For outbound IPv4 packets, the AFTR performs encapsulation and the
   ICXF router performs de-capsulation (if the traffic is destined to
   destination which is not managed by an AFTR router attached to the
   same IPv6 network), and for inbound IPv4 packets, the ICXF router
   performs IPv4-in-IPv6 encapsulation and an AFTR performs de-
   capsulation.

   When an AFTR forwards an IPv6 packet with an IPv4 payload to an ICXF
   router, the source IPv6 address is one of the AFTR's IPv6 address,
   which is normally a global IPv6 address configured on an interface of
   the node (e.g., an address of a loopback interface), and the
   destination IPv6 address is the FROM-AFTR Address.

   When an ICXF router receives an IPv4 packet, it encapsulate the IPv4



Boucadair, et al.        Expires August 28, 2010                [Page 7]


Internet-Draft              Extended DS-lite               February 2010


   packet with an IPv6 header where the source IPv6 address is the ICXF
   router's global IPv6 address and the destination IPv6 address is the
   TO-AFTR address.  The TO-AFTER address is constructed by combining
   the Pref6 and the destination IPv4 address in the IPv4 packet.  The
   destination IPv4 address is one of the addresses configured in the
   AFTR NAT pool.

   In both cases, the Pref6 is an IPv6 prefix assigned by the service
   provider, and is used to construct an IPv4-Embedded IPv6 address, as
   described in [I-D.ietf-behave-address-format].  Figure 2 gives an
   example of the address format.

   In this example, Pref6 is 2a01:c::/20 and the IPv4_Addr is
   193.51.145.206.  Then, the corresponding IPv6 prefix is: 2a01:cc13:
   391c:e0::/56.


     2a01:c::11000001001100111001000111001110 = 2a01:cc13:391c:e0::/56
    |Pref6 | <--------193.51.145.206-------->


            Figure 2: Example for an IPv4-Embedded IPv6 Prefix

   In the example, we use a /20 prefix for Pref6.  However, an operator
   can decide to use a longer prefix.  More examples about IPv4-Embedded
   IPv6 addresses can found at [I-D.ietf-behave-address-format].


4.  DS-Lite AFTR

   The AFTR function is defined in [I-D.ietf-softwire-dual-stack-lite].
   To support the extension as defined in this document, additional
   provisioning and functions are required as described in the following
   sub-sections.

4.1.  Provisioning

   The provisioning of an AFTR is according to that described in
   [I-D.ietf-softwire-dual-stack-lite], including a set of global IPv4
   addresses that are used for its NAT44 operations.  In addition, an
   IPv6 prefix (i.e., Pref6) is configured in the AFTR.  The Pref6 is
   used to construct FROM-AFTR addresses.  These IPv6 addresses are used
   as destination addresses of IPv4-in-IPv6 packets.

   In practice, , the set of global IPv4 addresses is aggregatable,
   leading to a set of aggregated IPv4-Embedded IPv6 prefixes, for the
   sake of routing scalability, as described in Section 6.




Boucadair, et al.        Expires August 28, 2010                [Page 8]


Internet-Draft              Extended DS-lite               February 2010


4.2.  Procedure

   Figure 3 shows the input and output of a DS-Lite AFTR node.



                           +-------------------+
              ----IPv6---\ |                   |----IPv6---\
              ----IPv4---\\|                   |----IPv4---\\
              -----------//|                   |-----------//
              -----------/ |                   |-----------/
     Customer              |      DS-Lite      |            Core Node Interface
               /----IPv6---|       AFTR        | /----IPv6---
              //---IPv4----|                   |//---IPv4----
              \\-----------|                   |\\-----------
               \-----------|                   | \-----------
                           +-------------------+


                      Figure 3: Modified DS-Lite AFTR

   Two main (logical) interfaces may be distinguished in a DS-Lite AFTR
   node as follows:

   a.  Interface with the customer device, i.e.- DS-Lite interface per
       [I-D.ietf-softwire-dual-stack-lite].

   b.  Interface with core nodes.  Note that the DS-Lite AFTR does not
       directly connect to an IPv4 domain.

   The processing of the IPv4 traffic received from a customer device is
   as follows.

      Processing Ingress Traffic from Customer Interface



      1.  De-capsulate the IPv6 header from the IPv4-in-IPv6 packets
          (sent by the customer device) 2.

      2.  NAT the IPv4 packet and create an entry in the NAT binding
          table

      3.  Encapsulate the NAT-ed IPv4 packets in IPv6 with a destination
          IPv6 address built according to the addressing scheme
          described in Section 3.  Encapsulated packet is forwarded
          based on the FROM-AFTR IPv6 address by standard routing.
          Depending on the target IPv4 address, the destination can be



Boucadair, et al.        Expires August 28, 2010                [Page 9]


Internet-Draft              Extended DS-lite               February 2010


          an AFTR node inside the service provider's domain if the IPv4
          address is one of the addresses owned by another AFTR (See
          Figure 4).  Or, the destination can be an ICXF router if the
          IPv4 address is external.

      Processing Ingress Traffic from Core Interface



      1.  De-capsulate the IPv6 header and extract the IPv4 packet.

      2.  Process the embedded IPv4 packet according to
          [I-D.ietf-softwire-dual-stack-lite].

      3.  Forward the resulting IPv6 packet to the corresponding B4.


+------+           +---------+                 +---------+           +------+
|      |--IPv6---\ |         |------IPv6-----\ |         |---IPv6--\ |      |
|      |--IPv4---\\|         |-----IPv4------\\|         |---IPv4--\\|      |
|      |---------//|         |---------------//|         |---------//|      |
|      |---------/ |         |---------------/ |         |---------/ |      |
| CPE 1|           | DS-Lite |                 | DS-Lite |           | CPE2 |
|      | /---IPv6--| AFTR A  | /-----IPv6------| AFTR B  | /---IPv6--|      |
|      |//---IPv4--|         |//----IPv4-------|         |//--IPv4---|      |
|      |\\---------|         |\\---------------|         |\\---------|      |
|      | \---------|         | \---------------|         | \---------|      |
+------+           +---------+                 +---------+           +------+



   Note that hosts connected to each CPE are not represented in the
   figure.

     Figure 4: Flow Example involving two devices attached to distinct
                                   AFTRs















Boucadair, et al.        Expires August 28, 2010               [Page 10]


Internet-Draft              Extended DS-lite               February 2010


   The following figure illustrates an example of CPE connected to a DS-
   Lite AFTR node, which establishes a communication with a remote host
   (referred to as RH) which is on an IPv4 network.

+------+           +---------+                 +---------+          +------+
|      |--IPv6---\ |         |------IPv6-----\ |         |          |      |
|      |--IPv4---\\|         |-----IPv4------\\|         |---IPv4--\|      |
|      |---------//|         |---------------//|         |---------/|      |
|      |---------/ |         |---------------/ |         |          |      |
| CPE 1|           | DS-Lite |                 |IPv6-IPv4|          |  RH  |
|      | /---IPv6--| AFTR A  | /-----IPv6------|   ICXF  |          |      |
|      |//---IPv4--|         |//----IPv4-------|         |/--IPv4---|      |
|      |\\---------|         |\\---------------|         |\---------|      |
|      | \---------|         | \---------------|         |          |      |
+------+           +---------+                 +---------+          +------+



   Note that host connected to CPE1 are not represented in the figure.

    Figure 5: Flow Example involving only one device attached to a DS-
                            lite enabled domain


5.  IPv6-IPv4 Interconnection Function (ICXF)

   ICXF is a border element that encapsulate IPv4 packets from external
   IPv4 network to AFTR and de-capsulate IPv6 packets from AFTR to
   external IPv4 network

   The following sub-sections provide more information about the
   behavior of this function.

5.1.  Provisioning

   An IPv6-IPv4 ICXF router is provisioned with an IPv6 prefix (i.e.,
   Pref6).  Pref6 is used to build TO-AFTR addresses as described in
   Section 3.

   The ICXF is connected to IPv4 network.  It maintains IPv4 routing
   information of the IPv4 networks.  The routing information can be
   provisioned statically or dynamically.

5.2.  Procedure

   Figure 6 shows the input and output of an IPv6-IPv4 ICXF.





Boucadair, et al.        Expires August 28, 2010               [Page 11]


Internet-Draft              Extended DS-lite               February 2010


                              +-------------------+
                 ----IPv6---\ |                   |
                 ----IPv4---\\|                   |----IPv4---\
                 -----------//|                   |-----------/
                 -----------/ |                   |
                              |    IPv6-IPv4      |
                  /----IPv6---|       ICXF        |
                 //---IPv4----|                   |/---IPv4----
                 \\-----------|                   |\-----------
                  \-----------|                   |
                              +-------------------+


                 Figure 6: IPv6-IPv4 Interworking Function

   When the ICXF router receives an IPv4 packet from an external IPv4
   domain, it encapsulates the IPv4 packet in IPv6 packet using the
   following information:

   o  Source IPv6 address: One of its own IPv6 addresses.

   o  Destination IPv6 address: TO-AFTR Address which is an IPv4-
      Embedded IPv6 address using the Pref6 and destination IPv4 address
      of the encapsulated IPv4 packet.

   As for the outbound IPv6 packets, an ICXF router performs de-
   capsulation and forwards the embedded IPv4 packets to the connected
   IPv4 networks according to IPv4 routing rule.


6.  Routing Architecture and Considerations

   This section describes the routing consideration to support this
   specification, i.e.- how an IPv6 packet with an IPv4-Embedded IPv6
   destination address is forwarded from a DS-Lite AFTR to an ICXF
   router, and vice versa, in the IPv6 network.

6.1.  Forwarding Packets from ICXF Router to AFTR

   When an ICXF router forwards IPv4-in-IPv6 packets to a DS-Lite AFTR,
   the destination IPv6 address is an IPv4-Embedded IPv6 address, where
   the Pref6 is an IPv6 prefix assigned to the service provider and the
   IPv4 address is in the AFTR IPv4 NAT address pool.  The ICXF must
   have the routing information of the IPv4-Embedded IPv6 addresses.
   The routing information can be configured statically or dynamically.






Boucadair, et al.        Expires August 28, 2010               [Page 12]


Internet-Draft              Extended DS-lite               February 2010


6.1.1.  Static Routing

   Each ICXF router is configured with static routes, and each static
   route points to an IPv4-Embedded IPv6 prefix.

6.1.2.  Dynamic Routing

   Dynamic routing may be more desirable especially when there are
   multiple ICXF routers and AFTRs, where each ICXF router learns how to
   forward IPv4-in-IPv6 packets to corresponding AFTRs without
   provisioning static routes.

   To achieve dynamic routing, each DS-Lite AFTR (or the upstream router
   of the DS-Lite AFTR) advertises the set of IPv4-Embedded IPv6
   addresses and/or prefixes it manages by IPv6 IGP (e.g., OSPFv3) in
   the IPv6 network.  The ICXF router will learn the prefixes via IPv6
   IGP and install the prefixes in the IPv6 routing table.  Note that
   these prefixes MUST NOT be advertised outside the IPv6 domain, e.g.-
   to adjacent e-BGP peers.

6.2.  Forwarding Packets from AFTR to ICXF Router

   When a DS-Lite AFTR forwards IPv4-in-IPv6 packets to an ICXF router,
   the destination IPv6 address is an IPv4-Embedded IPv6 address, where
   the Pref6 is an IPv6 prefix assigned to the service provider and the
   IPv4 address is reachable through one or more ICXF routers.  The
   forwarding decision can be made based on static configuration or
   dynamic routing.

6.2.1.  Static Routing

   The AFTR is configured with static routes, and each static route
   points to an IPv4-Embedded IPv6 prefix.  Alternatively, the AFTR can
   contain a default route where the default is the ICXF.

6.2.2.  Dynamic Routing

   Dynamic routing is more desirable for the deployments where there are
   multiple DS-Lite AFTRs and ICXF routers.  This specification suggests
   four dynamic routing options as documented below:

      Option 1:

         AFTRs and ICXF routers are configured as a softwire mesh
         [RFC5565] and i-BGP is used to exchange IPv4 reachability
         information.  AFTR and ICXF will peer with each other over
         i-BGP and exchange their IPv4 reachability.  Each AFTR and ICXF
         will compute an IPv4 routing table based upon the BGP table.



Boucadair, et al.        Expires August 28, 2010               [Page 13]


Internet-Draft              Extended DS-lite               February 2010


         Given an IPv4 network managed by the AFTR or ICXF, the next-hop
         of this network is the IPv6 address of the AFTR or ICXF.

         This routing option offers an optimized forwarding for IPv4-in-
         IPv6 packets in the IPv6 network with the cost of running i-BGP
         on all DS-Lite AFTRs and ICXF routers, and storing BGP routers
         on all these nodes.

         Note when this option is used, the mechanism described in
         Section 6.1.2 must not be used in the same network.

      Option 2:



         ICXF router advertises its IPv4 reachability information in
         IGP.  This routing option does not require AFTRs and ICXFs to
         be i-BGP peers, it also doesn't require AFTR to maintain an
         IPv4 routing table.  For the AFTR IPv6 routing table, it
         contains all FROM_AFTR prefixes and the ICXF IPv4 reachability
         information in the form on IPv4-Embedded IPv6 prefixes (i.e.,
         Pref6 + ICXF IPv4 routing information).  Given that the ICXF
         advertises all its IPv4 network reachability in IPv6 network,
         the AFTR can choose the best path to forward the packet.
         However, this optimization has a drawback: ICXF routers are
         required to advertise its full IPv4 reachability to in IGP.  As
         such, IPv6 routers will maintain the full IPv4 reachability in
         its IPv6 routing table.

      Option 3:

         With this option, each ICXF router advertises a Pref6
         (Section 5.1) in the IPv6 IGP.  An AFTR forwards an IPv4-in-
         IPv6 packet always to a nearest ICXF router, which, after the
         de-capsulation, will then forward the IPv4 packet according to
         its IPv4 routing table.

         Note in this case, the ICXF router, which is the nearest to the
         AFTR, may not have the best route (if there is a route at all)
         to the final destination in the IPv4 network, comparing to
         other ICXF routers that may be present, depending on the actual
         IPv4 network in question, which is beyond the scope of this
         document.

         This routing option does not create any overhead in the IPv6
         network nor on DS-Lite AFTR, and the forwarding path for IPv4-
         in-IPv6 packets is also optimized, with the cost of possible
         sub-optimization when forwarding IPv4 packets after de-



Boucadair, et al.        Expires August 28, 2010               [Page 14]


Internet-Draft              Extended DS-lite               February 2010


         capsulation on ICXF routers.

      Option 4:

         Option 4 requires every router in the IPv6 network to learn the
         IPv4-Embedded IPv6 prefixes advertised by the AFTR and ICXF.
         These prefixes are only meaningful to the AFTR and ICXF, other
         IPv6 routers may not be interested in them.  To address this
         issue, a separate topology ([I-D.boucadair-ospf-v4v6-ospfv3-mt]
         or [I-D.boucadair-isis-v4v6-mt]) that is dedicated to the
         reachability of IPv4-Embedded IPv6 prefixes can be used.

         This option requires the ICXF router and AFTR advertise the
         IPv4-Embedded IPv6 prefixes in the IPv4-Embedded IPv6 topology.
         This topology contains only the IPv4-Embedded IPv6 prefixes.
         Regular IPv6 routers will not participate this topology.

         With this option, each ICXF router advertises in the IPv6
         network a set of IPv4-Embedded IPv6 addresses and/or prefixes,
         where each embedded IPv4 address or prefix represents an IPv6
         destination or (sub)network that is reachable through the ICXF
         router, respectively.  Also, the mechanism as described in
         Section 6.1.2 is used but with separate IGP topology or
         instance, i.e.- each DS-Lite AFTR advertises in the IPv6
         network a set of IPv4-Embedded IPv6 addresses and/or prefixes,
         where each embedded IPv4 address or prefix represents a global
         IPv4 address or the aggregation of a set of IPv4 addresses,
         respectively.

         This option is very similar to Option 2.  The major advantage
         for multi-topology is to create a separate an IPv4-Embedded
         IPv6 network that only AFTR and ICXF install the prefixes in
         the IPv6 routing table.  However, ICXF still advertises its
         IPv4 reachability into IGP.

         Similar to Option 3, ICXF can advertise only the Pref6 in the
         IPv6 IGP.  AFTR will install only a default to the closest
         ICXF.  Since the closet ICXF may not contain the best path for
         the destination IPv4 address, sub-optimal routing is possible
         for the destination IPv4 network.


7.  Multicast Considerations

   This document describes an IPv4-IPv6 inter-connection extension to
   DS-Lite [I-D.ietf-softwire-dual-stack-lite], which currently limits
   the scope to transporting unicast IPv4 traffic over IPv6 network
   only.  Considerations on transporting multicast IPv4 traffic over



Boucadair, et al.        Expires August 28, 2010               [Page 15]


Internet-Draft              Extended DS-lite               February 2010


   IPv6 network is out of scope.


8.  Fragmentation

   Tunneling IPv4 over IPv6 between AFTR and ICXF reduce the effective
   MTU size by the size of an IPv6 header.  Since ICXF tunnel is
   stateless, the tunnel endpoint can't fragment and re-assumable the
   oversized IPv4 packet.  A service provider may increase the MTU size
   by 40-bytes on the IPv6 network.  If this is not possible, AFTR and
   ICXF may use IPv6 Path MTU discovery.

   ICXF nodes are stateless and do not need to implement any re-assembly
   function (for IPv4 fragments) which is performed by the AFTR as
   defined in the base DS-Lite architecture.  This stateless
   characteristic of the ICXF is aligned with inter-domain route
   asymmetry behaviour, e.g.- even fragments of a specific inbound
   (towards AFTRs) traffic flow may be transmitted by different ICXF
   routers, the same AFTR would receive those fragments, since ICXF does
   not need any transport-related information (e.g., TCP/UDP port
   number) which may not be in a given fragment, but only the
   destination IPv4 address for its operation (i.e., build an IPv4-
   Embedded IPv6 address and encapsulate the received IPv4 datagram in
   an IPv6 one destined to that IPv4-Embedded IPv6 address.


9.  Conclusions

   This document describes the mechanism to extend DS-Lite to operate an
   IPv6-only network while offering:

   o  Global IPv6 <==> IPv6 communications.

   o  Global IPv4 <==> IPv4 communications.

   o  A remote IPv6 host would reach a host connected to the DS-Lite
      enabled domain using IPv6.

   o  A remote IPv4 host would reach a host connected to the DS-Lite
      enabled domain using IPv4-in-IPv6.


10.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.



Boucadair, et al.        Expires August 28, 2010               [Page 16]


Internet-Draft              Extended DS-lite               February 2010


11.  Security Considerations

   Security considerations defined in
   [I-D.ietf-softwire-dual-stack-lite] should be taken into account.  In
   addition, current interconnection practices for ingress traffic
   filtering should be enforced in the interconnection points (ICXF).


12.  Acknowledgements

   The authors would like to thank Eric Burgey for his support and
   suggestions.


13.  References

13.1.  Normative References

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-03 (work in progress),
              February 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

13.2.  Informative References

   [I-D.boucadair-isis-v4v6-mt]
              Boucadair, M., Jacquenet, C., Cheng, D., and Y. Lee,
              "Multi-Topology/Multi-Instance ISIS for IPv4-Embedded
              IPv6", draft-boucadair-isis-v4v6-mt-02 (work in progress),
              February 2010.

   [I-D.boucadair-ospf-v4v6-ospfv3-mt]
              Boucadair, M., Jacquenet, C., Cheng, D., and Y. Lee,
              "Multi-Topology/Multi-Instance OSPFv3 for IPv4-Embedded
              IPv6", draft-boucadair-ospf-v4v6-ospfv3-mt-02 (work in
              progress), February 2010.

   [I-D.ietf-behave-address-format]
              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",



Boucadair, et al.        Expires August 28, 2010               [Page 17]


Internet-Draft              Extended DS-lite               February 2010


              draft-ietf-behave-address-format-04 (work in progress),
              January 2010.

   [RFC4277]  McPherson, D. and K. Patel, "Experience with the BGP-4
              Protocol", RFC 4277, January 2006.

   [RFC5565]  Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
              Framework", RFC 5565, June 2009.


Appendix A.  What's New Compared To RFC5565

   One of the two scenarios softwire mesh [RFC5565] covers is IPv4
   tunneling through an IPv6-only backbone.  Mesh defines an
   interconnection function at the backbone's edge routers called AFBR.
   All AFBRs exchange i-BGP routes.  When an IPv4 datagram arrives at an
   AFBR, it uses a BGP-distributed route to retrieve the IPv6
   destination address of the distant softwire endpoint.  The AFBRs will
   form a mesh network tunneling the IPv4 datagrams over softwire.  The
   AFBRs must maintain a stateful mapping table for encapsulation and
   de-capsulation purposes.

   This document covers a slightly different IPv4 over IPv6 scenario.
   This scenario is asymmetric.  On one side of the IPv6 backbone, there
   are AFTRs, and on the other side of the IPv6 backbone there are IPv4
   Internet access points.  At each IPv4 Internet access point we define
   an interconnection function called ICXF.  All ICXFs exchange i-BGP
   information.  In some scenarios, AFTRs do not participate in the
   i-BGP exchanges (since IGP may be used, see Section 6 for more
   details).

   Unlike [RFC5565], the encapsulation at both sides is stateless: the
   IPv6 destination address of the distant softwire endpoint is
   automatically generated, based on the IPv4 destination address of the
   IPv4 datagram only, there is no need to refer to any route.  The
   forwarding of the encapsulated datagrams is ensured by the
   installation of appropriate routes by i-BGP between ICXFs.


Appendix B.  Changes Since 02

   The following changes have been made since the last version:

   1.  Add a new section to define addressing scheme;

   2.  Add a new section to list all routing options in the IPv6
       network;




Boucadair, et al.        Expires August 28, 2010               [Page 18]


Internet-Draft              Extended DS-lite               February 2010


   3.  Various editorial changes.


Authors' Addresses

   Mohamed Boucadair (editor)
   France Telecom
   3, Av Francois Chateaux
   Rennes  35000
   France

   Email: mohamed.boucadair@orange-ftgroup.com


   Christian Jacquenet
   France Telecom

   Email: christian.jacquenet@orange-ftgroup.com


   Jean-Luc Grimault
   France Telecom
   France

   Email: jeanluc.grimault@orange-ftgroup.com


   Mohammed Kassi-Lahlou
   France Telecom

   Email: mohamed.kassilahlou@orange-ftgroup.com


   Pierre Levis
   France Telecom

   Email: pierre.levis@orange-ftgroup.com


   Dean Cheng (editor)
   Huawei Technologies Co., Ltd.

   Email: Chengd@huawei.com
   URI:   http://www.huawei.com







Boucadair, et al.        Expires August 28, 2010               [Page 19]


Internet-Draft              Extended DS-lite               February 2010


   Yiu L. Lee (editor)
   Comcast

   Email: yiu_lee@cable.comcast.com
   URI:   http://www.comcast.com














































Boucadair, et al.        Expires August 28, 2010               [Page 20]