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]