[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: Informational                              JL. Grimault
Expires: November 19, 2009                               M. Kassi Lahlou
                                                                P. Levis
                                                          France Telecom
                                                                D. Cheng
                                           Huawei Technologies Co., Ltd.
                                                            May 18, 2009


Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment
                 draft-boucadair-dslite-interco-v4v6-01

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 November 19, 2009.

Copyright Notice



Boucadair, et al.       Expires November 19, 2009               [Page 1]


Internet-Draft              Extended DS-lite                    May 2009


   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 DS-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.  Only
   IPv6 is required to be deployed in core and access networks.
   Particularly, IPv6 transfer capabilities are used for the transfer of
   IPv4-addressed packets in a completely stateless scheme between the
   interconnection segment and the DS-lite CGN node(s).

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 November 19, 2009               [Page 2]


Internet-Draft              Extended DS-lite                    May 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Context  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Contribution of this draft . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Procedure  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Overall Procedure  . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Customer Attachment Device . . . . . . . . . . . . . . . .  7
     3.3.  DS-lite CGN Node . . . . . . . . . . . . . . . . . . . . .  8
       3.3.1.  Provisioning Information . . . . . . . . . . . . . . .  8
       3.3.2.  Routing Considerations . . . . . . . . . . . . . . . .  8
       3.3.3.  Processing Operations  . . . . . . . . . . . . . . . .  8
     3.4.  IPv6-IPv4 Interconnection Function . . . . . . . . . . . . 11
       3.4.1.  Provisioning Information . . . . . . . . . . . . . . . 11
       3.4.2.  Routing Considerations . . . . . . . . . . . . . . . . 11
       3.4.3.  Processing Operations  . . . . . . . . . . . . . . . . 12
   4.  Design Considerations  . . . . . . . . . . . . . . . . . . . . 12
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

























Boucadair, et al.       Expires November 19, 2009               [Page 3]


Internet-Draft              Extended DS-lite                    May 2009


1.  Introduction

1.1.  Context

   It is commonly agreed that IPv4 address shortage is a fact.  Several
   solutions have been proposed to cope with this sensitive issue.  All
   these solutions are based on IP address sharing and differ in where
   the IP address sharing function is enforced.

   The first category is denoted as Port Range
   [I-D.boucadair-port-range] or A+P solutions [I-D.ymbk-aplusp].  The
   spirit of this category is to assign the same public IP address to
   several customers' devices (called also port restricted devices)
   together with a Port Range.  Communications issued/destined to a
   port-restricted device can be established only if the ports belong to
   the provisioned Port Range.  Dedicated means to provision the Port
   Range have been proposed (see [I-D.bajko-pripaddrassign] and
   [I-D.boucadair-pppext-portrange-option] for instance).

   The second category is known as CGN (for Carrier Grade NAT).  Two
   main CGN flavors can be distinguished.  Double NAT, in which two
   levels of NAT are cascaded: one in the CPE and one in the network
   (i.e.  CGN).  And DS-lite [I-D.ietf-softwire-dual-stack-lite] which
   gets rid of the CPE NAT level.  This solution requires a Dual Stack
   CPE.  Thus, a given CPE is assigned with an IPv6 prefix to be used
   for its native IPv6 communications and also to encapsulate the IPv4
   packets into IPv6 ones between the CPE and the DS-lite CGN.  Note
   that the deployment of DS-lite CGN equipment is not necessarily
   centralized and several DS-lite CGN nodes may be deployed to handle
   traffic issued/destined from/to end-user devices.

   Current DS-lite specification does not solve the IPv4-IPv6
   Interconnection issue.  This is one of the motivations of the effort
   documented in this memo.

1.2.  Contribution of this draft

   This memo proposes an extended DS-lite approach to solve both IPv4
   address shortage and also to allow stateless IPv4-IPv6
   interconnection.  More precisely, this memo proposes to update DS-
   lite nodes with new encapsulation and de-encapsulation capabilities
   to be applied on the interface to core network of a given service
   provider.  Furthermore, a new function embedded in IPv6-IPv4
   interconnection nodes (e.g.  ASBR or a dedicated node) is also
   introduced.  The activation of the proposed solution allows a service
   provider to operate a network which is IPv6-only.

   In this memo, a stateless IPv6-IPv4 Interconnection Function (IPv6-



Boucadair, et al.       Expires November 19, 2009               [Page 4]


Internet-Draft              Extended DS-lite                    May 2009


   IPv4 ICXF) is explicitly defined.  An ICXF-capable node resides in an
   IPv6-only network but also connects to one or more IPv4 networks.  It
   can encapsulate IPv4 datagrams received from a connected IPv4 network
   in IPv6 and then send the IPv4-inferred IPv6 datagram towards a DS-
   Lite CGN device located in the IPv6 network.  The ICXF-capable router
   can also de-capsulate an IPv4 datagram from an IPv6 datagram, and
   then forward the IPv4 datagram accordingly.  The encapsulation/
   de-capsulation capabilities are facilitated by an IPv4-inferred IPv6
   address scheme which is further detailed in this document.  Specific
   forwarding capabilities are also described in this memo.

   Some enhancements are added to a DS-lite CGN node.  A DS-lite CGN
   node may not directly connect to an IPv4 network and in this case, an
   IPv4 datagram originated from customer side and applied with NAT
   logic, is encapsulated in an IPv6 datagram and forwarded in the IPv6
   network further towards an ICXF-capable router.  And upon receiving
   an IPv4-inferred IPv6 datagram, it would de-capsulate the IPv4
   datagram, apply NAT logic and then forward the packet to the DS-lite
   interface with the same behavior as defined in
   [I-D.ietf-softwire-dual-stack-lite].

   Other functions are also described in this memo, so as to strengthen
   the operation of DS-Lite extensions.  Multiple DS-lite CGN nodes
   and/or ICXF-capable routers may be deployed in a single IPv6 network,
   where while the former is desirably closer to customers, the latter
   can reside on ASBR closer to IPv4 networks.


2.  Terminology

   This memo makes use of the following terms:

   o  DS-lite CGN node: refers to the CGN node which behaviour is
      specified in [I-D.ietf-softwire-dual-stack-lite].  This node
      embedded a CGN function.

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

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

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





Boucadair, et al.       Expires November 19, 2009               [Page 5]


Internet-Draft              Extended DS-lite                    May 2009


   o  Customer Attachment Device: A customer may use a terminal or a CPE
      to access its subscribed services.  This device is referred to as
      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 updated DS-lite solution.

3.1.  Overall Procedure

   The overall proposed procedure is summarised hereafter:

   o  A new IPv6-IPv4 Interconnection function (IPv6-IPv4 ICXF) is
      introduced.  This function may be hosted in an ASBR 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 ones and de-encapsulating IPv4-in-IPv6
      datagrams.

   o  DS-lite CGN nodes are deployed in the access network.  These nodes
      are compliant with [I-D.ietf-softwire-dual-stack-lite].  In
      addition, these nodes are enhanced with new IPv4-in-IPv6
      encapsulation and de-encapsulation functions.  These newly
      introduced functions are stateless.  Once these functions are
      enabled, a given DS-lite node is responsible to handle IPv4-in-
      IPv6 traffic in all its interfaces.  No plain IPv4 traffic is
      sent/received by the DS-lite CGN in all its interfaces.  Only
      IPv4-in-IPv6 packets are handled.  As a result this enhancement, a
      DS-lite CGN node may not directly connect to an IPv4 domain.

   o  Customer Attachment Devices are provisioned with an IPv6 prefix
      that will not only be used for native IPv6 communication, but also
      to encapsulate IPv4 datagrams.  The proposed solution does not
      require any modification on the customers side compared to what
      has been listed in [I-D.ietf-softwire-dual-stack-lite].











Boucadair, et al.       Expires November 19, 2009               [Page 6]


Internet-Draft              Extended DS-lite                    May 2009


   This figure provides an overview of the overall environment.
   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 end user device.  The local domain is IPv6 only and
   interconnection with adjacent IPv4 realms is implemented using IPv6-
   IPv4 ICXF.
                 +--------------------------------+
                 |      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: Environment Overview

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

3.2.  Customer Attachment Device

   The Customer Attachment Device is provisioned with an IPv6 prefix and
   the IPv6 address of a DS-lite CGN, by means of DHCPv6 for example.
   For robustness reasons, the IPv6 address of a DS-Lite CGN is
   recommended to be an anycast address.

   A Customer Attachment Device encapsulates the privately addressed
   IPv4 traffic in IPv6 datagrams.  These messages are then forwarded
   (without any NAT operation) towards a DS-lite CGN node.

   As for incoming traffic, a Customer Attachment Device proceeds to de-
   encapsulation operation.  De-encapsulated datagrams are handled
   locally or are forwarded to the appropriate machine connected to the



Boucadair, et al.       Expires November 19, 2009               [Page 7]


Internet-Draft              Extended DS-lite                    May 2009


   LAN behind the Customer Attachment Device.

   The current specification does not require any modification on a DS-
   lite compliant CPE.

3.3.  DS-lite CGN Node

3.3.1.  Provisioning Information

   In addition to the required configuration information to activate DS-
   lite mode described in [I-D.ietf-softwire-dual-stack-lite], DS-lite
   CGN nodes are provisioned with:

   o  WKIPv6: an IPv6 prefix that can be assigned by IANA or extracted
      from the prefix assigned to the service provider.  This prefix is
      used to build an IPv4-inferred IPv6 address.  More information are
      provided in Section 3.3.3.

   o  A set of IPv6 prefixes which are structured as WKIPv6+IPv4_addr:

      *  WKIPv6: the same as the one mentioned in the previous bullet.

      *  IPv4_addr is an IPv4 address used by the DS-lite CGN to enforce
         its NAT44 operations.

      *  Several IPv4 addresses may be configured on a DS-lite node.
         These IPv4 addresses may be aggregated, leading to aggregated
         WKIPv6+IPv4_addr prefixes.

      *  Each IPv4 address here is served as an IPv4 source address for
         IPv4 hosts behind CPE (after applying NAT44 logic) in order to
         communicate with other hosts located in remote IPv4 domains
         (refer to Figure 1).

3.3.2.  Routing Considerations

   A DS-lite node (or a third party) advertises in IGP the IPv6 prefixes
   it manages (i.e. the set of WKIPv6+IPv4_addr prefixes described
   above).  Such announcement is required so that all traffic destined
   to an IPv6 address belonging to an IPv6 prefix configured on the DS-
   lite CGN node MUST be forwarded to the DS-Lite node.

3.3.3.  Processing Operations

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






Boucadair, et al.       Expires November 19, 2009               [Page 8]


Internet-Draft              Extended DS-lite                    May 2009


                              +-------------------+
                 ----IPv6---\ |                   |----IPv6---\
                 ----IPv4---\\|                   |----IPv4---\\
                 -----------//|                   |-----------//
                 -----------/ |                   |-----------/
                              |      DS-Lite      |
                  /----IPv6---|       CGN         | /----IPv6---
                 //---IPv4----|                   |//---IPv4----
                 \\-----------|                   |\\-----------
                  \-----------|                   | \-----------
                              +-------------------+


                      Figure 2: Modified DS-lite CGN

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

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

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

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

   IPv4-in-IPv6 packets are de-encapsulated and then NAT operation is
   applied.  Once this operation is performed, the DS-lite node
   encapsulates the NATed IPv4 datagrams in IPv6 ones 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: WKIPv6+Original IPv4 address (i.e. the
      destination IPv4 address contained in the encapsulated datagrams).

   Encapsulated traffic is then forwarded until reaching 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.  See Figure 3),
      it de-encapsulates 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 4), it
      proceeds to a de-encapsulation operation and then the traffic is



Boucadair, et al.       Expires November 19, 2009               [Page 9]


Internet-Draft              Extended DS-lite                    May 2009


      forwarded to the next IPv4 destination according to installed IPv4
      routes.

   As illustrated in the figure, the communications between two CPEs
   attached to a DS-lite enabled domain are implemented using IPv6 only
   capabilities.  IPv4 datagrams are encapsulated in IPv6 ones.  The NAT
   function is implemented by DS-lite CGN nodes.

+------+           +---------+                 +---------+           +------+
|      |--IPv6---\ |         |------IPv6-----\ |         |---IPv6--\ |      |
|      |--IPv4---\\|         |-----IPv4------\\|         |---IPv4--\\|      |
|      |---------//|         |---------------//|         |---------//|      |
|      |---------/ |         |---------------/ |         |---------/ |      |
| CPE 1|           | DS-lite |                 | DS-lite |           | CPE2 |
|      | /---IPv6--|  CGN A  | /-----IPv6------|  CGN B  | /---IPv6--|      |
|      |//---IPv4--|         |//----IPv4-------|         |//--IPv4---|      |
|      |\\---------|         |\\---------------|         |\\---------|      |
|      | \---------|         | \---------------|         | \---------|      |
+------+           +---------+                 +---------+           +------+



   Machines behind each CPE are not represented in the figure.

   Figure 3: Flow Example involving two devices attached to the same DS-
                            lite enabled domain

   The following figure illustrates an example of a CPE, located behind
   a DS-lite CGN node, which establishes a communication with a remote
   machine (referred to as RM) which is IPv4-only.

+------+           +---------+                 +---------+          +------+
|      |--IPv6---\ |         |------IPv6-----\ |         |          |      |
|      |--IPv4---\\|         |-----IPv4------\\|         |---IPv4--\|      |
|      |---------//|         |---------------//|         |---------/|      |
|      |---------/ |         |---------------/ |         |          |      |
| CPE 1|           | DS-lite |                 |IPv6-IPv4|          |  RM  |
|      | /---IPv6--|  CGN A  | /-----IPv6------|   ICXF  |          |      |
|      |//---IPv4--|         |//----IPv4-------|         |/--IPv4---|      |
|      |\\---------|         |\\---------------|         |\---------|      |
|      | \---------|         | \---------------|         |          |      |
+------+           +---------+                 +---------+          +------+



   Machines located behind CPE1 are not represented in the figure.

    Figure 4: Flow Example involving only one device attached to a DS-



Boucadair, et al.       Expires November 19, 2009              [Page 10]


Internet-Draft              Extended DS-lite                    May 2009


                            lite enabled domain

3.4.  IPv6-IPv4 Interconnection Function

   As mentioned above, a dedicated node called IPv6-IPv4 Interconnection
   function (IPv6-IPv4 ICXF) is required to interconnect an IPv6-only
   domain (which hosts a DS-lite CGN function) and an IPv4 one.  This
   function is required to interconnect both realms without introducing
   any additional NAT operation in the path.

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

3.4.1.  Provisioning Information

   An IPv6-IPv4 Interconnection node is provisioned with a WKIPv6 which
   is an IPv6 prefix that can be assigned by IANA or be part of the
   service provider's prefix.  This prefix is used to build IPv4-
   inferred IPv6 addresses (structured as WKIPv6+IPv4_addr).  IPv4_addr
   refers to an IPv4 address (or network) that can be reached through
   the IPv6-IPv4 Interworking node.  These IPv4 addresses may be static
   or dynamic (e.g. learned via a dedicated protocol such as BGP).

3.4.2.  Routing Considerations

   Two modes may be envisaged:

   o  Static mode: IPv4-inferred IPv6 prefixes, structured as WKIPv6+
      IPv4_addr, are provided to IPv6-IPv4 ICXF through a dedicated
      configuration means (e.g.  CLI).

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

   The IPv4-inferred IPv6 reachability information will be dynamically
   advertised within the domain, to make sure that IPv4-addressed
   traffic that will be encapsulated in IPv6 datagrams will be forwarded
   to the relevant IPv4-IPv6 ICXF-enabled router.  For scalability
   reasons, IPv4-inferred IPv6 reachability information may be
   advertised using i-BGP to avoid redistributing BGP routes in IGP.

   Note that the IPv6-IPv4 ICXF-capable node does not assign those
   addresses to its interfaces.






Boucadair, et al.       Expires November 19, 2009              [Page 11]


Internet-Draft              Extended DS-lite                    May 2009


3.4.3.  Processing Operations

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

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


                 Figure 5: IPv6-IPv4 Interworking Function

   Concretely, when the interconnection node receives IPv4 traffic from
   an adjacent 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: WKIPv6+Original IPv4 address.

   The traffic is then 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 IPv6 received traffic, an Interconnection node proceeds to
   a de-encapsulation 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 far (from the access network) in the network
   since this would create a concentrator and then may be considered as
   a single point of failure.  Furthermore, the routing would not be
   optimal, particularly for intra-domain traffic.





Boucadair, et al.       Expires November 19, 2009              [Page 12]


Internet-Draft              Extended DS-lite                    May 2009


5.  Conclusions

   This proposal allows to migrate toward 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.

   Since end user's devices are DS(-lite), the appropriate connectivity
   protocol (IPv4 or IPv6) is selected to issue outgoing traffic.
   Therefore, IPv4-to-IPv6 and IPv6-to-IPv4 communications are not
   considered as valid scenarios within the proposed architecture.


6.  IANA Considerations

   This document makes no request of IANA.

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


7.  Security Considerations

   TBC


8.  Acknowledgements

   TBC


9.  References

9.1.  Normative References

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-ietf-softwire-dual-stack-lite-00 (work
              in progress), March 2009.



Boucadair, et al.       Expires November 19, 2009              [Page 13]


Internet-Draft              Extended DS-lite                    May 2009


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

9.2.  Informative References

   [I-D.bajko-pripaddrassign]
              Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
              "Port Restricted IP Address Assignment",
              draft-bajko-pripaddrassign-01 (work in progress),
              March 2009.

   [I-D.boucadair-port-range]
              Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
              "IPv4 Connectivity Access in the Context of IPv4 Address
              Exhaustion", draft-boucadair-port-range-01 (work in
              progress), January 2009.

   [I-D.boucadair-pppext-portrange-option]
              Boucadair, M., Levis, P., Grimault, J., and A.
              Villefranque, "Port Range Configuration Options for PPP
              IPCP", draft-boucadair-pppext-portrange-option-00 (work in
              progress), February 2009.

   [I-D.ymbk-aplusp]
              Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L.
              Cittadini, "The A+P Approach to the IPv4 Address
              Shortage", draft-ymbk-aplusp-03 (work in progress),
              March 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





Boucadair, et al.       Expires November 19, 2009              [Page 14]


Internet-Draft              Extended DS-lite                    May 2009


   Jean Luc GRIMAULT
   France Telecom


   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
   Huawei Technologies Co., Ltd.


   Phone:
   Fax:
   Email: Chengd@huawei.com
   URI:






















Boucadair, et al.       Expires November 19, 2009              [Page 15]


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