[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                        B. Sarikaya
Internet-Draft                                                    F. Xia
Expires: April 11, 2010                                       Huawei USA
                                                            M. Boucadair
                                                          France Telecom
                                                         October 8, 2009


                     A+P for Dual-Stack Mobile IPv6
                   draft-sarikaya-aplusp-dsmip-00.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   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 11, 2010.

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.







Sarikaya, et al.         Expires April 11, 2010                 [Page 1]


Internet-Draft               A+P for DSMIPv6                October 2009


Abstract

   This memo describes how to use IPv6 Port Range transition technique
   in mobile networks for Dual-Stack Mobile IPv6 (DSMIPv6).  Using the
   client based DSMIPv6, a mobile node (MN) which is a dual-stack node
   can be assigned with a shared IPv4 Home Address (HA) together with a
   port range from the home agent.  HA is co-located with Port Range
   Router (PRR).  IPv4-in-IPv6 encapsulation is used to convey IPv4
   traffic between the network and the mobile node (MN).  HA, acting as
   PRR receives incoming IPv4 datagrams and determines the routing
   identifier (IPv6 address) to use to forward the traffic to the
   appropriate MN among those sharing the same IPv4 address.  In the
   binding mode, HA finds the binding cache entry for this MN and then
   encapsulates the IPv4 datagram in an IPv6 one and forwards the
   encapsulated datagram to MN.  The stateless mode is also described.
   Within this memo, Mobile network could be WiMAX network or 3GPP Long
   Term Evolution (LTE) network.


































Sarikaya, et al.         Expires April 11, 2010                 [Page 2]


Internet-Draft               A+P for DSMIPv6                October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Overall Context  . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Contribution of This Memo  . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  On Port Range Value and Port Range Mask  . . . . . . . . . . .  5
   4.  Basic Port-Range-based Mobile IPv6 Solution  . . . . . . . . .  6
     4.1.  Overall Procedure  . . . . . . . . . . . . . . . . . . . .  6
     4.2.  IPv4 Data Flow . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IPv6 Port-Range-based Mobile IPv6 Solution . . . . . . . . . .  8
     5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Procedure  . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Extensions to DSMIPv6  . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Binding Update Extensions  . . . . . . . . . . . . . . . . 10
     6.2.  Binding Acknowledgement Extensions . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative references . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15




























Sarikaya, et al.         Expires April 11, 2010                 [Page 3]


Internet-Draft               A+P for DSMIPv6                October 2009


1.  Introduction

1.1.  Overall Context

   It is commonly agreed that IPv4 address depletion 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 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.

   The second category is known as CGN (for Carrier Grade NAT).  Two
   main CGN variants 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.  DS-lite 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.

   The main advantage of the a+p solutions compared to the CGN-based
   ones is to avoid maintaining any session-state in the service
   provider's realm.  Hurdles related to the deployment of NAT technique
   in the service domain and constraints to maintain various ALGs are
   avoided.  For more information about the advantage of a+p, the reader
   should refer to [I-D.ymbk-aplusp] and/or [I-D.boucadair-port-range].
   When deployed in the context of mobile networks, the same IPv4
   address can be shared by many mobile nodes but the number of source
   ports they can use are limited.  In the binding mode, Port Range
   Router in the network keeps a binding table containing the routing
   identifier (IPv6 address), IPv4 address and port mask.  Port Range
   Router receives all incoming datagrams for the shared IPv4 addresses
   and searches the binding table to retrieve the routing identifier and
   forwards the IPv4 datagram to the correct host.  In the stateless
   mode, this binding cache is not required.

1.2.  Contribution of This Memo

   This document aims at assessing the validity of the a+p approach in
   the context of Dual-Stack Mobile IPv6 (DSMIPv6 [RFC5555]).  This is
   mainly motivated by the need to avoid maintaining NAT (and therefore,
   no need to deploy ALGs, session states in the service realm, etc.) in
   the path to enhance the overall experienced performance (e.g.,



Sarikaya, et al.         Expires April 11, 2010                 [Page 4]


Internet-Draft               A+P for DSMIPv6                October 2009


   latency).  Mobile Nodes may or may not embed a NAT function.

   This document presents a mobility solution combining the Port Range-
   based architecture and Client Mobile IPv6 [RFC5555].  Both a binding
   mode and stateless mode are described.

   Client Mobile IPv6 defines other scenarios as well in [RFC5555].
   IPv4-only scenario and its variations such as mobile node behind a
   NAT which could be located at the home router and therefore requires
   NAT traversal mechanisms and home agent behind NAT but home agent has
   a globally unique IPv4 address.  Using Port Range-based architecture
   solution over an IPv6-enabled network, the need for these more
   complicated operations is eliminated.


2.  Terminology

   This document uses the terminology defined in
   [I-D.ietf-softwire-dual-stack-lite], [I-D.boucadair-port-range],
   [I-D.bajko-pripaddrassign] and [RFC5555].


3.  On Port Range Value and Port Range Mask

   Devices with shared IPv4 addresses are provisioned also with a port
   range to be used, especially the Port Mask to be applied when
   selecting a port value as a source port.  A Port Mask defines a set
   of ports that all have in common a subset of pre-positioned bits.
   This set of ports is also called Port Range.  Two port numbers are
   said to belong to the same Port Range if and only if, they have the
   same Port Mask.  A Port Mask is composed of a Port Range Value and a
   Port Range Mask:

   o  The Port Range Value indicates the value of the significant bits
      of the Port Mask.  The Port Range Value is coded as follows:
      *  The significant bits may take a value of 0 or 1.
      *  All the other bits (non significant ones) are set to 0.
   o  The Port Range Mask indicates, by the bit(s) set to 1, the
      position of the significant bits of the Port Range Value.

   An example of port range is provided in Figure 1.  Ports belonging to
   this port range must have the first 3 bits equal to 001.  The Port
   Mask is represented as: 001xxxxxxxxxxxxx.








Sarikaya, et al.         Expires April 11, 2010                 [Page 5]


Internet-Draft               A+P for DSMIPv6                October 2009


                0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | | |
 | | | (3 significant bits)
 v v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0| Port Range Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 x x x x x x x x x x x x x| Usable ports (x may take a value of 0 or 1).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         Figure 1: Example of Port Range Mask and Port Range Value

   For more details, refer to [I-D.bajko-pripaddrassign].


4.  Basic Port-Range-based Mobile IPv6 Solution

   This section assumes that the basic Port-Range architecture as
   defined in [I-D.boucadair-port-range] is adopted.  Particularly, a
   binding entry is required to associate an IPv4 address + Port Range
   with an IPv6 address (or IPv6 prefix).  Section 5 describes an
   alternative in which this binding is not required.

4.1.  Overall Procedure

   Dual-stack MN can get an IPv4 home address by sending an IPv6 Binding
   Update (BU) to the Home Agent (HA).  MN MUST include IPv4 Home
   Address Option defined in [RFC5555] in the BU and set the address to
   0.0.0.0.  HA assigns an IPv4 Home Address together with Port Range
   and returns it in a BA using an extended IPv4 Home Address Option
   called IPv4 Home Address and Port Range (HoA-PR) defined in
   Section 6.  MN encapsulates all its IPv4 datagrams into IPv6 ones and
   forwards encapsulated datagrams to HA.  MN does not need to configure
   an IPv4 care-of address as MN uses the IPv6 connectivity.










Sarikaya, et al.         Expires April 11, 2010                 [Page 6]


Internet-Draft               A+P for DSMIPv6                October 2009


            MN       DHCP    HA       DHCP
            |        |        |
            |------->|        |          DHCPv6 Information Request
            |<-------|        |          DHCPv6 Information Reply
            |---------------->|          BU
            |                 |------->| DHCP DISCOVER(OPTION-IPv4-PRA)
            |                 |<-------| DHCP OFFER
            |                 |------->| DHCP REQUEST
            |                 |<-------| DHCP ACK
            |<----------------|          BA (IPv4 HoA-PR)


                Figure 2: Mobile Node Address Configuration

   Figure 2 illustrates the overall flow exchange to retrieve a shared
   IPv4 address.  Concretely, the experienced behaviour is as follows:

   1.  MN enters the network.  MN autoconfigures IPv6 Care-of Address
       (e.g., 2001:0:0:1::1).  MN needs to be provided with an IPv6
       address (e.g., 2001:0:0:2::1) of the HA and an IPv6 Home Address.
       MN sends DHCPv6 Information Request message to DHCP Proxy/Server
       as specified in [I-D.ietf-mip6-hiopt].
   2.  DHCP Proxy/Server sends a Reply message with IPv6 and IPv4
       address of IPv6 HA and Home Network Prefix values for MN.
   3.  MN registers then its IPv6 CoA by sending a BU to HA.  MN adds
       IPv4 Home Address Option and sets IPv4 Home Address field in
       HoA-PR Option to 0.0.0.0.
   4.  HA MAY send DHCP DISCOVER message to DHCPv4 server.  The message
       will contain OPTION-IPv4-PRA Option with the sub-opt type
       indicates port mask (value = 1) [I-D.bajko-pripaddrassign].
   5.  HA receives DHCP OFFER message with the 'yiaddr' (client IP
       address) field set to 0.0.0.0 and with OPTION-IPv4-PRA Option.
       The option contains the shared IPv4 address and Port Range and
       mask.
   6.  HA sends DHCP REQUEST message.  HA MUST NOT include a 'Requested
       IP Address' DHCP Option (code 50) into this DHCPREQUEST and also
       MUST NOT insert the IP address received in OPTION-IPv4-PRA into
       the 'Requested IP Address' DHCP Option (code 50).
   7.  HA receives DHCP ACK message with OPTION-IPv4-PRA.  HA assigns
       the address in IPv4 address field to MN as its Home Address.
   8.  HA sends BA with IPv4 Address Acknowledgement and Port Range
       Option.

   HA assigns a shared IPv4 HoA to MN (a.b.c.d) and sets this value in
   IPv4 Home Address field of BA.  HA also assigns Port Range Value and
   Port Range Mask of BA.  HA creates a binding in its binding cache for
   both MN IPv6 HoA and IPv4 HoA.  In the binding cache, together with
   HoA, the port range value and port range mask MUST also be included.



Sarikaya, et al.         Expires April 11, 2010                 [Page 7]


Internet-Draft               A+P for DSMIPv6                October 2009


   HA acting as Port Range Router also assigns mobile node's IPv6
   Care-of Address (CoA) (in the source address of BU) as the binding
   identifier for MN.  HA adds an entry containing (IPv4 HoA, port range
   mask, port range value, IPv6 CoA) to the binding table for this MN
   [I-D.boucadair-port-range].

   MN sends IPv4 datagrams encapsulated in IPv6.  All datagrams are
   forwarded to HA.  Internal IPv4 packet's source address is IPv4 HoA.
   Internal IPv4 packet's source port MUST be within the Port Range sent
   by HA to the MN.

   MN handoffs and gets connected to a different network.  MN gets
   another IPv6 Care-of-Address, possibly using stateless address
   configuration or using DHCPv6 [RFC3315].  MN sends a BU to HA to
   register its new Care-of-Address.  MN with a shared IPv4 Home Address
   MUST include IPv4 Home Address and Port Range Option.  MN MUST NOT
   start transmitting datagrams before it receives a BA.

4.2.  IPv4 Data Flow

   Port Range Router collocated in HA has to receive the incoming IPv4
   datagrams for all MNs that are assigned a shared IPv4 address.  This
   can be achieved in IGP by advertizing all port shared IPv4 addresses.

   When Port Range Router receives an IPv4 datagram it searches the
   binding table for destination IPv4 address and port for a matching
   entry against IPv4 HoA, port range mask and port range value.  If an
   entry is found then the binding identifier (IPv6 CoA) is determined.
   Next HA searches the binding cache for IPv6 CoA to verify that there
   is a binding cache entry for this MN.  HA tunnels the received IPv4
   datagram to MN.

   When MN has IPv4 data to send MN always encapsulates the datagram in
   IPv6 and sends it to HA.  HA decapsulates the datagram.  HA MUST
   verify the source address and source port in the inner header using
   the tunnel header's source address to find the corresponding binding
   cache entry.


5.  IPv6 Port-Range-based Mobile IPv6 Solution

5.1.  Overview

   If the network is configured as DS-lite network
   [I-D.ietf-softwire-dual-stack-lite] or as specified in
   [I-D.boucadair-behave-ipv6-portrange] the following two implications
   should be taken into account:




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


Internet-Draft               A+P for DSMIPv6                October 2009


   DSMIPv6 Home Agent does not have a DHCPv4 server to get port range
   IPv4 addresses as depicted in Figure 2 in Steps 4-7.  In this case
   Home Agent MUST locally manage IPv4 addresses it assigns to the
   mobile nodes.  DHCPv6 can be used to provision the shared IPv4
   address and the Port Range as defined in
   [I-D.boucadair-dhcpv6-shared-address-option].

   IPv4-enabled mobile nodes make DNS requests in IPv4.  For that
   purpose they need to be configured with the address of an IPv4 DNS
   resolver.  The DNS resolver then forwards the DNS request from the
   mobile nodes over IPv6 to the IPv6 DNS resolver address it has
   received over DHCPv6.  DNS resolver for IPv4 must be a DNS proxy as
   described in [I-D.ietf-softwire-dual-stack-lite].

5.2.  Procedure

   When a stateless mode is adopted, MNs are assigned with an IPv6
   prefix which enclose the shared IPv4 address and the significant bits
   of the Port Range.  The format of the IPv6 prefix is as follows:


      +------------------------+----------+---------+
      |         Pref6          |  @IPv4   |   PRM   |
      +------------------------+----------+---------+


     Figure 3: IPv6 prefix enclosing an IPv4 address and a port range

   1.  Pref6: is a sub-prefix belonging to the service provider or well-
       known prefix allocated by IANA for this service.  The length of
       this field is variable (may be different from a service provider
       to another if not allocated by IANA).
   2.  @IPv4 field encloses the shared IPv4 address.  The length of this
       field is 32 bits;
   3.  PRM field includes the value of the significant bits of the Port
       Range.  The maximum length of this field is 16 bits.

   For outgoing communications, the same behaviour as described in
   Section 4.2 applies.

   For incoming communications, the PRR does not need to maintain any
   binding table to map the shared IPv4 address, port range and an IPv6
   address.  The PRR builds an IPv6 address using the destination IPv4
   address and source number.  The PRR MUST be configured with the
   Pref6.  The IPv4 datagram is then encapsulated in an IPv6 one and
   sent to the aforementioned IPv6 address.  The encapsulated datagram
   is received by the MN which proceeds to a de-capsulation operation.
   Encapsulated IPv4 datagram is then treated according to normal



Sarikaya, et al.         Expires April 11, 2010                 [Page 9]


Internet-Draft               A+P for DSMIPv6                October 2009


   behaviour.

   This mode is completely stateless (except for the mobility management
   aspects), i.e. no binding table is needed.


6.  Extensions to DSMIPv6

6.1.  Binding Update Extensions

   IPv4 Home Address Option defined in [RFC5555] is extended to carry
   the port range value and mask.  This new option is called IPv4 Home
   Address and Port Range Option.

   This option is included in the mobility header, including the binding
   update message sent from the mobile node to a home agent.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |Prefix-len |P|    Reserved     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Home Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Port Range Value          |       Port Range Mask         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             Figure 4: IPv4 Home Address and Port Range Option

   Type

      TBA1 for Type
   Length

      10
   Prefix-len

      As defined in [RFC5555]
   P

      As defined in [RFC5555]
   Reserved

      As defined in [RFC5555]





Sarikaya, et al.         Expires April 11, 2010                [Page 10]


Internet-Draft               A+P for DSMIPv6                October 2009


   IPv4 Home Address

      As defined in [RFC5555].  Mobile node MUST set this field to
      0.0.0.0.
   Port Range Value

      16-bit field that indicates the value of the mask to be applied.
      Mobile node must set this field to all zeros.
   Port Range Mask

      16-bit field that indicates the position of the bits which are
      used to build the mask.  Mobile node must set this field to all
      zeros.

6.2.  Binding Acknowledgement Extensions

   IPv4 Home Address Acknowledgement Option defined in [RFC5555] is
   extended to also carry the Port Range Value and Port Range Mask and
   this new option is called IPv4 Home Address and Port Range
   Acknowledgement Option.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |  Status       |Prefix-len |Res|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     IPv4 Home Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Port Range Value          |       Port Range Mask         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Figure 5: IPv4 Home Address and Port Range Acknowledgement Option

   Type

      TBA2 for Type
   Length

      10
   Prefix-len

      As defined in [RFC5555]







Sarikaya, et al.         Expires April 11, 2010                [Page 11]


Internet-Draft               A+P for DSMIPv6                October 2009


   Res

      As defined in [RFC5555]
   IPv4 Home Address

      As defined in [RFC5555].  Home agent sets this field to the value
      that it will use in the binding cache entry.  This address is a
      public address.
   Port Range Value

      16-bit field that indicates the value of the mask to be applied.
      Home agent must set this field to a valid Port Range Value.
   Port Range Mask

      16-bit field that indicates the position of the bits which are
      used to build the mask.  Home agent must set this field to a valid
      Port Range mask.
   Status

      The following values are allocated in addition to the ones defined
      in [RFC5555].
   o  140 Dynamic IPv4 Home Address assignment with port range feature
   not available
   o  141 No address/port left


7.  Security Considerations

   This document does not by itself introduce any security issues.


8.  IANA Considerations

   TBD.


9.  Acknowledgements

   TBD.


10.  References

10.1.  Normative References

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




Sarikaya, et al.         Expires April 11, 2010                [Page 12]


Internet-Draft               A+P for DSMIPv6                October 2009


   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

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

   [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-dhcpv6-shared-address-option]
              Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
              and G. Bajko, "Dynamic Host Configuration Protocol
              (DHCPv6) Options for Shared IP Addresses  Solutions",
              draft-boucadair-dhcpv6-shared-address-option-00 (work in
              progress), May 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: Port  Range based IP Architecture",
              draft-boucadair-port-range-02 (work in progress),
              July 2009.

   [I-D.boucadair-behave-ipv6-portrange]
              Boucadair, M., Levis, P., Grimault, J., Villefranque, A.,
              Kassi-Lahlou, M., Bajko, G., Lee, Y., and T. Melia,
              "Flexible IPv6 Migration Scenarios in the Context of IPv4
              Address Shortage",
              draft-boucadair-behave-ipv6-portrange-03 (work in
              progress), October 2009.

   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", RFC 5555, June 2009.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
              (work in progress), September 2009.



Sarikaya, et al.         Expires April 11, 2010                [Page 13]


Internet-Draft               A+P for DSMIPv6                October 2009


   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [I-D.ymbk-aplusp]
              Bush, R., "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-04 (work in progress), July 2009.

10.2.  Informative references

   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
              Madanapalli, "Transmission of IPv6 via the IPv6
              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
              February 2008.

   [I-D.ietf-netlmm-grekey-option]
              Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
              "GRE Key Option for Proxy Mobile IPv6",
              draft-ietf-netlmm-grekey-option-09 (work in progress),
              May 2009.

   [I-D.ietf-mip6-hiopt]
              Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
              Options for Home Information Discovery in MIPv6",
              draft-ietf-mip6-hiopt-17 (work in progress), May 2008.

   [3GPP23402]
              "3GPP TS  23.402. Architecture enhancements for non-3GPP
              accesses.", June 2009.

   [3GPP24303]
              "3GPP TS  24.303. Mobility Management Using Dual-Stack
              Mobile IPv6.", March 2009.

   [WiMAXnwg]
              "WiMAX Forum Networking Working Group Stage 3
              Specification Release 1.5.", March 2009.











Sarikaya, et al.         Expires April 11, 2010                [Page 14]


Internet-Draft               A+P for DSMIPv6                October 2009


Authors' Addresses

   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Mohamed Boucadair
   France Telecom
   3, Av Francois Chateau
   Rennes, France  35000

   Email: mohamed.boucadair@orange-ftgroup.com

























Sarikaya, et al.         Expires April 11, 2010                [Page 15]