[Docs] [txt|pdf] [Tracker] [Email] [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: October 31, 2009                                M. Kassi Lahlou
                                                                P. Levis
                                                          France Telecom
                                                          April 29, 2009


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

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 October 31, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the



Boucadair, et al.       Expires October 31, 2009                [Page 1]


Internet-Draft              Extended DS-lite                  April 2009


   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).  This memo
   proposes an IPv4-inferred scheme to build IPv6 addresses.

   The proposed solution allows Service Providers to maintain an IPv6-
   only network.

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 October 31, 2009                [Page 2]


Internet-Draft              Extended DS-lite                  April 2009


Table of Contents

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

























Boucadair, et al.       Expires October 31, 2009                [Page 3]


Internet-Draft              Extended DS-lite                  April 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.

   Whilst the DS-lite solution enhances the Double NAT scenario by
   avoiding a NAT level and the allocation of a specific private IPv4
   address to the CPE, it does not solve the IPv4-IPv6 interworking
   issue.

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.




Boucadair, et al.       Expires October 31, 2009                [Page 4]


Internet-Draft              Extended DS-lite                  April 2009


   [I-D.boucadair-behave-ipv6-portrange] introduces a slightly modified
   IPv4-IPv6 interworking function (which takes into account the port
   number information) compatible with the Port Range based solutions.


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.

   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.




Boucadair, et al.       Expires October 31, 2009                [Page 5]


Internet-Draft              Extended DS-lite                  April 2009


   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.

   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 no
      require any modification on the customers side compared to what
      has been listed in [I-D.ietf-softwire-dual-stack-lite].

   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



Boucadair, et al.       Expires October 31, 2009                [Page 6]


Internet-Draft              Extended DS-lite                  April 2009


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







Boucadair, et al.       Expires October 31, 2009                [Page 7]


Internet-Draft              Extended DS-lite                  April 2009


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.


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

   b.  Interface to core nodes.

   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.

   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



Boucadair, et al.       Expires October 31, 2009                [Page 8]


Internet-Draft              Extended DS-lite                  April 2009


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
















Boucadair, et al.       Expires October 31, 2009                [Page 9]


Internet-Draft              Extended DS-lite                  April 2009


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




Boucadair, et al.       Expires October 31, 2009               [Page 10]


Internet-Draft              Extended DS-lite                  April 2009


   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.

   The aforementioned IPv4-inferred IPv6 prefixes are then advertised in
   IGP.  Thus, IPv4-encapsulated traffic will reach the appropriate
   IPv6-IPv4 ICXF.

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.






Boucadair, et al.       Expires October 31, 2009               [Page 11]


Internet-Draft              Extended DS-lite                  April 2009


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.


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







Boucadair, et al.       Expires October 31, 2009               [Page 12]


Internet-Draft              Extended DS-lite                  April 2009


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.

   [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-behave-ipv6-portrange]
              Boucadair, M., Levis, P., Grimault, J., Villefranque, A.,
              and M. Kassi-Lahlou, "Flexible IPv6 Migration Scenarios in
              the Context of IPv4 Address Shortage",
              draft-boucadair-behave-ipv6-portrange-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



Boucadair, et al.       Expires October 31, 2009               [Page 13]


Internet-Draft              Extended DS-lite                  April 2009


              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


   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










Boucadair, et al.       Expires October 31, 2009               [Page 14]


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