[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-boucadair-softwire-dslite-v6only

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


             Deploying Dual-Stack lite in IPv6-only Network
                 draft-boucadair-dslite-interco-v4v6-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  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.

   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.

   This Internet-Draft will expire on April 8, 2010.



Boucadair, et al.         Expires April 8, 2010                 [Page 1]


Internet-Draft              Extended DS-lite                October 2009


Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memo describes a proposal to enhance Dual-Stack lite (DS-lite)
   [I-D.ietf-softwire-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 to customers.  IPv6 transfer
   capabilities are used for the transfer of IPv4-addressed datagrams in
   a completely stateless scheme between the interconnection segment and
   the DS-lite CGN node(s).  The proposed DS-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].























Boucadair, et al.         Expires April 8, 2010                 [Page 2]


Internet-Draft              Extended DS-lite                October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  IPv4 Address Exhaustion  . . . . . . . . . . . . . . . . .  4
     1.2.  Dual-Stack lite  . . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Contribution of this draft . . . . . . . . . . . . . . . .  4
     1.4.  What's new compared to RFC5565 . . . . . . . . . . . . . .  5
     1.5.  Changes since 01 . . . . . . . . . . . . . . . . . . . . .  6
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Procedure  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Global Architecture  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Customer Attachment Device . . . . . . . . . . . . . . . .  8
     3.3.  DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1.  Provisioning Information . . . . . . . . . . . . . . .  9
       3.3.2.  Routing Considerations . . . . . . . . . . . . . . . . 10
       3.3.3.  Processing Operations  . . . . . . . . . . . . . . . . 10
     3.4.  IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 12
       3.4.1.  Provisioning Information . . . . . . . . . . . . . . . 13
       3.4.2.  Routing Considerations . . . . . . . . . . . . . . . . 13
       3.4.3.  BGP Behavior . . . . . . . . . . . . . . . . . . . . . 14
       3.4.4.  Processing Operations  . . . . . . . . . . . . . . . . 15
   4.  Design Considerations  . . . . . . . . . . . . . . . . . . . . 15
   5.  Multicast Considerations . . . . . . . . . . . . . . . . . . . 16
   6.  Applicability in the context of A+P  . . . . . . . . . . . . . 16
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18



















Boucadair, et al.         Expires April 8, 2010                 [Page 3]


Internet-Draft              Extended DS-lite                October 2009


1.  Introduction

1.1.  IPv4 Address Exhaustion

   IPv4 addresses are finite resources.  The current prediction is that
   RIRs will allocate their last /8s in 2012.  Detailed information is
   available at http://www.potaroo.net/tools/ipv4.  To address this
   problem, IETF has defined IPv6 Protocol [RFC2460] which extends the
   32-bit address space to 128-bit address space.  Unfortunately, IPv4
   and IPv6 are incompatible.  IPv6-only CPEs cannot reach IPv4 services
   w/o address family translation.  Consider the fact that the Internet
   will take time to fully migrate to IPv6, the IETF community is
   actively discussing techniques to make sure IPv4-to-IPv4
   communications can still be established in IPv6 access network where
   global IPv4 addresses have become a scarce resource that will be
   shared between several customers.  Dual-Stack lite (DS-lite)
   [I-D.ietf-softwire-dual-stack-lite] is one of the potential
   techniques.

1.2.  Dual-Stack lite

   DS-lite solution contains two major components: the DS-lite CPE
   client which initiates the IPv4-in-IPv6 softwire towards the DS-lite
   CGN node, and the DS-lite CGN node which terminates the IPv4-in-IPv6
   softwire and performs NAT44 function on the IPv4 datagram.  Hosts
   connected to the CPE use RFC1918 addresses to source IPv4 datagrams.
   The CPE forwards the IPv4 datagrams over the IPv4-in-IPv6 softwire
   towards the DS-lite CGN node.  The CGN receives the IPv4 datagrams,
   performs NAT44 on them, and forwards them to the IPv4 Internet.  The
   DS-lite CGN is configured with a pool of public IPv4 addresses that
   will be shared by multiple customers.  Note that the deployment of
   DS-lite CGN capabilities is not necessarily centralized and several
   nodes may be deployed for load-balancing, redundancy and other
   scalability considerations.

   Current DS-lite specification defines that the DS-lite CGN nodes
   communicate to both IPv4 and IPv6 networks.  Consider the deployment
   model where CGN nodes are deployed in the edge of the network, the
   CGN nodes MUST connect to an IPv4 core network to forward IPv4
   datagrams.

1.3.  Contribution of this draft

   This memo proposes an extended solution that allows the DS-lite CGN
   node to be deployed in an IPv6-only network.  More precisely, this
   memo proposes to extend DS-lite CGN node with a new stateless
   encapsulation/decapsulation capability that delivers the NAT-ed IPv4
   datagram in an IPv4-inferred IPv6 datagram after the NAT44 function.



Boucadair, et al.         Expires April 8, 2010                 [Page 4]


Internet-Draft              Extended DS-lite                October 2009


   Furthermore, this document proposes a new stateless IPv6-IPv4
   Interconnection Function (IPv6-IPv4 ICXF) in the border element of
   the IPv6 network that will translate IPv6 datagrams into IPv4
   datagrams for the sake of IPv4 connectivity.

   In this memo, the DS-lite CGN node is not directly connected to an
   IPv4 network.  After performing IPv4-in-IPv6 de-capsulation and NAT
   operation, the DS-lite CGN node will encapsulate the NAT-ed IPv4
   datagram in an IPv4-in-IPv6 datagram and forward the datagram in the
   IPv6 network towards an ICXF-capable router located in the network
   border.

   The stateless IPv6-IPv4 Interconnection Function (IPv6-IPv4 ICXF) is
   introduced.  This function may be hosted in an ASBR (Autonomous
   System Border Router) or a dedicated node located at the
   interconnection between IPv6 and IPv4 domains.  This function is
   responsible for encapsulating all received IPv4 datagrams in IPv6
   datagrams and de-encapsulating IPv4-in-IPv6 datagrams.  An ICXF-
   capable router refers to the border router implemented with IPv6-IPv4
   ICXF.  It resides in the border of an IPv6-only network but also
   connects to one or more IPv4 networks.  When the ICXF-capable router
   receives the IPv4-inferred IPv6 datagram from a DS-lite CGN node, it
   will de-capsulate the datagram and forward the IPv4 datagram based on
   the IPv4 destination address in the header.  For incoming IPv4
   traffic, the ICXF router will encapsulate the IPv4 datagram into an
   IPv6 datagram with the IPv4-inferred IPv6 address and forward it to
   the appropriate DS-lite CGN node.

1.4.  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 CGNs, 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, CGNs do not participate in the i-BGP
   exchanges (since IGP may be used, see Section 3.3.2 for more
   details).



Boucadair, et al.         Expires April 8, 2010                 [Page 5]


Internet-Draft              Extended DS-lite                October 2009


   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.

1.5.  Changes since 01

   The following changes have been made since the last version:

   1.  A new co-author has joined the draft's team;

   2.  Add a new section to position the proposed solution versus
       RFC5565;

   3.  Add a new section to describe in detail the routing
       considerations;

   4.  Add a new section on multicast considerations;

   5.  Various editorial changes.


2.  Terminology

   This memo defines the following terms:

   o  DS-lite CGN node: refers to the CGN node whose behavior is
      specified in [I-D.ietf-softwire-dual-stack-lite].  This node
      embeds a CGN function.  In addition, this draft makes the
      assumption that the DS-lite CGN node is only connected to an IPv6
      network.  Within this draft, the CGN design scheme assumes that
      only IPv6 traffic will be forwarded in the backbone that embeds
      DS-lite capabilities, including IPv6 traffic that conveys
      encapsulated IPv4 datagrams and which is sent to ICXF-enabled
      routers.  This encapsulation is stateless.

   o  IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF): refers to the
      function that de-capsulates (resp., encapsulates) the IPv6 (resp.,
      IPv4) datagram from DS-lite CGN node(s) and forwards the IPv4
      (resp., IPv6) datagrams to the IPv4 (resp., IPv6) networks.

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

   o  Access segment: This segment encompasses both the IP access and
      backhaul network.



Boucadair, et al.         Expires April 8, 2010                 [Page 6]


Internet-Draft              Extended DS-lite                October 2009


   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  Customer Attachment Device: A customer may use a terminal or a CPE
      to access the he/she has subscribed to.  This device is referred
      to as Customer Attachment Device.  This device is standard DS-lite
      client device.  This extension does not introduce any new
      functionality to that device.  In this memo, CPE refers to
      Customer Attachment Device.

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


3.  Procedure

   This section describes an extension of the DS-lite approach.

3.1.  Global Architecture

   Figure 1 provides an overview of the global architecture.  Customers
   are connected to the service domain via a CPE device.  Several DS-
   lite CGN nodes are deployed to manage the traffic issued/destined
   from/to the end-user terminal devices.  The service domain is IPv6
   only and interconnection with adjacent IPv4 realms is implemented
   using IPv6-IPv4 ICXF.



















Boucadair, et al.         Expires April 8, 2010                 [Page 7]


Internet-Draft              Extended DS-lite                October 2009


                 +--------------------------------+
                 |      Service Domain            |         +-----------
  +----+         |                           +---------+    |   IPv4
  |CPE1|---------|                           |IPv6-IPv4|----|  Domain A
  +----+         |                           |  ICXF   |    |
                 |                           +---------+    +-----------
                 |   +-------+                    |
                 |   |DS-lite|                    |         +-----------
  +----+         |   | CGN A |               +---------+    |  IPv4
  |CPE2|---------|   +-------+               |IPv6-IPv4|----| Domain B
  +----+         |                           |  ICXF   |    |
                 |                           +---------+    +-----------
                 |   +-------+                    | |
                 |   |DS-lite|                    | |       +-----------
  +----+         |   | CGN B |                    | |       | IPv4
  |CPEi|---------|   +-------+                    | +-------| Domain C
  +----+         |                                |         |
                 |                                |         +-----------
                 +--------------------------------+

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


                       Figure 1: Global Architecture

   The following sub-sections provide more details about the proposed
   solution.

3.2.  Customer Attachment Device

   The Customer Attachment Device is (dynamically) assigned an IPv6
   prefix and also acquires IPv6 reachability information to forward
   IPv6 traffic outside of the customer premises.  The Customer
   Attachment Device also supports DS-lite-specific capabilities (namely
   an encapsulation scheme to convey privately-addressed IPv4 traffic
   into IPv6 datagrams that will be sent to one of the available CGN
   devices located in the network).  DS-lite CGN IPv6 reachability
   information is also (dynamically) provisioned to the Customer
   Attachment Device, e.g. by means of a specific DHCPv6
   option[I-D.dhankins-softwire-tunnel-option].  To reach a CGN, a FQDN
   may be provided to the Customer Attachment Device instead of an IPv6
   address.

   For outbound IPv6 datagrams, the Customer Attachment Device routes
   them natively in the service domain.  For outbound IPv4 datagrams,
   the Customer Attachment Device encapsulates the private-addressed
   IPv4 datagrams in IPv6 ones.  These datagrams are forwarded (without
   any NAT operation) towards a DS-lite CGN node.



Boucadair, et al.         Expires April 8, 2010                 [Page 8]


Internet-Draft              Extended DS-lite                October 2009


   For inbound IPv6 datagram, the Customer Attachment device routes them
   natively to the hosts connected to it.  For inbound IPv4 datagrams,
   the Customer Attachment Device proceeds to de-encapsulation
   operation.  De-encapsulated datagrams are routed locally and
   forwarded to the hosts connected to the Customer Attachment Device.

   This is standard DS-lite client behavior defined in
   [I-D.ietf-softwire-dual-stack-lite].  This memo does not add new
   requirement.

3.3.  DS-lite CGN Node

3.3.1.  Provisioning Information

   DS-lite CGN nodes are provisioned with:

   o  Pref6: An IPv6 prefix which may be assigned by IANA or by LIR as
      described in [I-D.ietf-behave-address-format].  This prefix is
      used to construct an IPv4-inferred IPv6 address.  More information
      are provided in Section 3.3.3.  The choice between IANA and LIR is
      left to service provider's engineering policies.

   o  A set of IPv6 prefixes which are structured as Pref6+IPv4_Addr:

      *  Pref6 is the IPv6 prefix dedicated to the IPv4-IPv6
         interconnection.

      *  IPv4_Addr is a public IPv4 address used by the DS-lite CGN to
         enforce its NAT44 operations.

         +  Several IPv4_Addrs may be configured on a DS-lite node.
            These IPv4_Addrs SHOULD be aggregated, leading to aggregated
            Pref6+IPv4_Addr prefixes.

         +  Each IPv4_Addr represents multiple IPv4 customers served by
            the DS-lite CGN node.

   Figure 2 gives an example of address format.  For more information
   about mapping address format, refer to
   [I-D.ietf-behave-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.







Boucadair, et al.         Expires April 8, 2010                 [Page 9]


Internet-Draft              Extended DS-lite                October 2009


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


            Figure 2: Example for an IPv4-Inferred IPv6 Prefix

3.3.2.  Routing Considerations

   To enable stateless de-/encapsulation in the ICXF router, the DS-lite
   CGN nodes MUST use the aforementioned Pref6 to construct the IPv4-
   Inferred IPv6 address when forwarding datagrams received from a
   customer device.

   A DS-lite node (or the upstream router of the DS-lite node)
   advertises the IPv6 prefix it manages (i.e., the set of Pref6+
   IPv4_Addr prefix described above) by IGP (e.g.  OSPFv3).  Such
   announcement is required so that all traffic sent to an IPv6 address
   belonging to the IPv6 prefix managed by the DS-lite CGN node MUST be
   forwarded to the appropriate DS-lite node.  These prefixes MUST NOT
   be advertised to external peers (e.g., e-BGP peers).

3.3.3.  Processing Operations

   Figure 3 shows the input and output of a DS-lite CGN node.



                              +-------------------+
                 ----IPv6---\ |                   |----IPv6---\
                 ----IPv4---\\|                   |----IPv4---\\
                 -----------//|                   |-----------//
                 -----------/ |                   |-----------/
        Customer              |      DS-lite      |
                  /----IPv6---|       CGN         | /----IPv6---
                 //---IPv4----|                   |//---IPv4----
                 \\-----------|                   |\\-----------
                  \-----------|                   | \-----------
                              +-------------------+

              DS-lite Interface                   Core Node Interface


                      Figure 3: Modified DS-lite CGN

   Two main interfaces may be distinguished in a DS-lite CGN node:

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



Boucadair, et al.         Expires April 8, 2010                [Page 10]


Internet-Draft              Extended DS-lite                October 2009


   b.  Interface with core nodes.  Note that the DS-lite CGN node does
       not directly connect to an IPv4 domain.

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

   IPv4-in-IPv6 datagrams (issued by the customer device) are de-
   encapsulated and then NAT operation is applied.  Once this operation
   is performed, the DS-lite node encapsulates the NAT-ed IPv4 datagrams
   in IPv6 using the following information:

   o  Source IPv6 address: One of the DS-lite node IPv6 addresses.  This
      source IPv6 address is a global IPv6 address configured on an
      interface of the DS-lite CGN (e.g., loopback).

   o  Destination IPv6 address: Pref6+IPv4_Addr destination address
      (i.e., the destination IPv4 address contained in the encapsulated
      datagrams).

   Encapsulated traffic is forwarded until it reaches another DS-lite
   CGN node, if the traffic remains in the same domain, or an IPv6-IPv4
   Interconnection equipment.

   o  If datagrams are received by a DS-lite node (e.g., Figure 4), it
      de-capsulates them and handles the embedded IPv4 ones according to
      [I-D.ietf-softwire-dual-stack-lite].

   o  If received by an Interconnection node (e.g., See Figure 5), it
      proceeds to a de-capsulation operation and then the traffic is
      forwarded to the next IPv4 destination according to the installed
      IPv4 routes.

   As illustrated in Figure 4, the communications between two CPEs
   attached to a DS-lite domain are implemented using IPv6 transfer
   capabilities only.  IPv4 datagrams are encapsulated in IPv6 ones.
















Boucadair, et al.         Expires April 8, 2010                [Page 11]


Internet-Draft              Extended DS-lite                October 2009


+------+           +---------+                 +---------+           +------+
|      |--IPv6---\ |         |------IPv6-----\ |         |---IPv6--\ |      |
|      |--IPv4---\\|         |-----IPv4------\\|         |---IPv4--\\|      |
|      |---------//|         |---------------//|         |---------//|      |
|      |---------/ |         |---------------/ |         |---------/ |      |
| CPE 1|           | DS-lite |                 | DS-lite |           | CPE2 |
|      | /---IPv6--|  CGN A  | /-----IPv6------|  CGN 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
                                   CGNs

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

+------+           +---------+                 +---------+          +------+
|      |--IPv6---\ |         |------IPv6-----\ |         |          |      |
|      |--IPv4---\\|         |-----IPv4------\\|         |---IPv4--\|      |
|      |---------//|         |---------------//|         |---------/|      |
|      |---------/ |         |---------------/ |         |          |      |
| CPE 1|           | DS-lite |                 |IPv6-IPv4|          |  RH  |
|      | /---IPv6--|  CGN 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

3.4.  IPv6-IPv4 Interconnection Function

   A dedicated node called IPv6-IPv4 Interconnection Function (IPv6-IPv4
   ICXF) is required to interconnect an IPv6-only network (which hosts a
   DS-lite CGN function) and an IPv4 network.  This function is required



Boucadair, et al.         Expires April 8, 2010                [Page 12]


Internet-Draft              Extended DS-lite                October 2009


   to interconnect both realms to receive and forward IPv4 datagrams
   from the DS-lite clients and IPv4 Internet.

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

3.4.1.  Provisioning Information

   An IPv6-IPv4 Interconnection node is provisioned with a Pref6.  This
   prefix is used to build IPv4-inferred IPv6 addresses (structured as
   Pref6+IPv4_Addr).  IPv4_Addr refers to an IPv4 address (or network)
   that can be reached through the IPv6-IPv4 interconnection node.  IPv4
   addresses may be statically configured or dynamically learned (IPv4
   peers).

3.4.2.  Routing Considerations

   Two modes may be considered:

   o  Static mode: IPv4-inferred IPv6 prefixes, structured as Pref6+
      IPv4_Addr, are manually configured in the IPv6-IPv4 ICXF router.

   o  Dynamic mode: IPv6-IPv4 ICXF router is responsible to build IPv4-
      inferred IPv6 prefixes which are structured as Pre6+IPv4_addr.
      These addresses represent IPv4 reachable destinations in the IPv6-
      only realm.

   IPv4 traffic encapsulated in IPv6 datagrams will be forwarded to ICXF
   routers.  The selection of the appropriate ICXF router is based upon
   the computation of the best (shortest) IPv4 route towards the IPv4
   destination.  There are several ways to proceed.  As examples, we
   describe two solutions: a one-step process and a two-step process.

   The one-step process can be achieved using softwire mesh ([RFC5565]).
   ICXF routers and CGNs exchange i-BGP information.  Particularly, the
   CGNs receive and process the i-BGP advertisements.  From the i-BGP
   information, CGNs build IPv4 routes where the next hop is the IPv6
   address of the ICXF router which has the best route to the IPv4
   destination.  Whenever a CGN has to encapsulate an IPv4 datagram into
   IPv6, it looks up the IPv6 destination in its BGP-distributed routes.
   The IPv6 datagram is then directly routed from the CGN to the
   relevant ICXF router, in a one-step process.  In this scenario, CGNs
   maintain a full BGP IPv4 routing table, and the IPv4-in-IPv6
   encapsulation is stateful.

   In the two-step process, ICXF routers exchange i-BGP information as
   in the previous scenario, but, contrary to the previous scenario,
   CGNs do not participate to the i-BGP mesh.  Furthermore, each ICXF



Boucadair, et al.         Expires April 8, 2010                [Page 13]


Internet-Draft              Extended DS-lite                October 2009


   router advertises a route to Pref6 in IPv6 IGP.  Whenever a CGN has
   to encapsulate an IPv4 datagram into IPv6, it dynamically builds the
   IPv6 destination address from the IPv4 destination address: Pref6+
   IPv4_Addr.  The IPv6 datagram is then routed to the nearest ICXF
   router.  This ICXF router then forwards, if necessary, the IPv6
   datagram to the ICXF router which has the best route to the IPv4
   destination.  Thus, IPv6 datagram may be routed in a two-step
   process.  In this scenario, CGNs do not maintain any IPv4 BGP routing
   table, and the IPv4-in-IPv6 encapsulation is stateless.

   IPv4-inferred IPv6 reachability information (received from adjacent
   domains) should be advertised using i-BGP between ICXF routers, to
   avoid a full redistribution of BGP routes into IGP.  Recursive
   routing lookup will be then executed to select the appropriate IXCF
   (exit point).  The engineering of the relationship between IGP and
   i-BGP would follow best practices as those documented in [RFC4277].

   Note that the ICXF router does not assign Pref6 + IPv4_Addr IPv6
   addresses to its interfaces.

3.4.3.  BGP Behavior

   This section provides a description of the BGP behavior when IPv4-
   inferred IPv6 routes are to be injected in i-BGP.

   The following steps are to be followed:

   o  e-BGP session is maintained between an ICXF router and its IPv4
      peer.  IPv4 routes are exchanged between these two peers.
      Particularly, ICXF router advertises to its peers a set of
      reachable IPv4 networks through its attached domain (e.g., AS).
      These IPv4 networks include the IPv4 addresses used by CGN
      devices.

   o  No new capability BGP attribute is required with the context of
      stateless IPv4-IPv6 interconnection.

   o  Each ICXF router is configured with a dedicated IPv6 prefix
      (Pref6) which is to be used to build IPv4-inferred IPv6 prefixes
      (e.g., IPv4-inferred IPv6 prefix=Pref6+IPv4 net).

   o  For each route towards an IPv4 network, a corresponding IPv6
      prefix is built as per the method described in Section 3.3.3.
      These routes are then injected in i-BGP to all internal peers to
      synchronise the overall BGP routing table and avoid loops.






Boucadair, et al.         Expires April 8, 2010                [Page 14]


Internet-Draft              Extended DS-lite                October 2009


3.4.4.  Processing Operations

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


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


                 Figure 6: IPv6-IPv4 Interworking Function

   When the interconnection node receives IPv4 traffic from an IPv4
   domain, it encapsulates IPv4 datagrams in IPv6 using the following
   information:

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

   o  Destination IPv6 address: Prefix6+IPv4 Destination address.  The
      IPv4 destination address is part of the DS-lite node address
      space.

   The traffic is received by a DS-lite CGN node which de-encapsulates
   the traffic and handles the embedded IPv4 one according to current
   DS-lite specification [I-D.ietf-softwire-dual-stack-lite].

   As for the incoming IPv6 received traffic, an Interconnection node
   proceeds to a de-capsulation operation and then the traffic is
   forwarded to the next IPv4 destination according to installed IPv4
   routes.


4.  Design Considerations

   The aforementioned functions (i.e., DS-lite CGN and IPv6-IPv4 ICXF)
   may be hosted in the same node or distinct ones according to the
   underlying topology constraints and dimensioning considerations.
   Nevertheless for scalability reasons, it is not recommended to deploy
   a DS-lite CGN function upstream and far from the customer premises
   since this would create a concentrator and then may be considered as



Boucadair, et al.         Expires April 8, 2010                [Page 15]


Internet-Draft              Extended DS-lite                October 2009


   a single point of failure.  Furthermore, the routing would not be
   optimal, particularly for intra-domain traffic.


5.  Multicast Considerations

   To access IPv4 multicast-based content via the CGN, the following
   behaviour MAY be implemented:

   o  IPv4-inferred IPv6 multicast addresses are built based on IPv4
      multicast address.  An IPv4 multicast address is embedded in an
      IPv6 multicast one.

   o  The ICMP proxy function embedded in a DS-lite CPE forwards ICMP
      Report messages towards a DS-lite CGN.  These ICMP Report messages
      are encapsulated in IPv6 by the CPE and forwarded to the DS-lite
      CGN.

   o  The CGN is then able to connect that CPE to the corresponding IPv6
      multicast tree using the IPv4-inferred IPv6 multicast address.

   This document recommends the migration of IPv4 multicast-based
   services to IPv6 and CGN device to be restricted to process unicast
   IPv4 traffic.


6.  Applicability in the context of A+P

   The procedure defined in this memo may also apply in the context of
   PRR (Port Range Router, [I-D.boucadair-port-range]) instead of DS-
   lite CGN.  In the last case the customer attachment device should do
   the classification of outbound IPv4 packet between A+P and DS-lite
   mode and the IPv6-IPv4 interconnection function should do the
   classification of inbound IPv4 datagrams.  In this case a specific
   prefix (Prefix6) may be allocated for each mode.


7.  Conclusions

   This memo 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.



Boucadair, et al.         Expires April 8, 2010                [Page 16]


Internet-Draft              Extended DS-lite                October 2009


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


8.  IANA Considerations

   This document makes no request of IANA.

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


9.  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).


10.  Acknowledgements

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


11.  References

11.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-01 (work in progress),
              July 2009.

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

11.2.  Informative References

   [I-D.boucadair-port-range]
              Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
              "IPv4 Connectivity Access in the Context of IPv4 Address



Boucadair, et al.         Expires April 8, 2010                [Page 17]


Internet-Draft              Extended DS-lite                October 2009


              Exhaustion: Port  Range based IP Architecture",
              draft-boucadair-port-range-02 (work in progress),
              July 2009.

   [I-D.dhankins-softwire-tunnel-option]
              Hankins, D., "Dynamic Host Configuration Protocol Option
              for Dual-Stack Lite",
              draft-dhankins-softwire-tunnel-option-03 (work in
              progress), March 2009.

   [I-D.ietf-behave-address-format]
              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-00 (work in progress),
              August 2009.

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


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






Boucadair, et al.         Expires April 8, 2010                [Page 18]


Internet-Draft              Extended DS-lite                October 2009


   Mohammed Kassi-Lahlou
   France Telecom

   Email: mohamed.kassilahlou@orange-ftgroup.com


   Pierre Levis
   France Telecom

   Email: pierre.levis@orange-ftgroup.com


   Dean Cheng
   Huawei Technologies Co., Ltd.

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


   Yiu L. Lee
   Comcast

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



























Boucadair, et al.         Expires April 8, 2010                [Page 19]


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