Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: April 15, 2010 Huawei USA
M. Boucadair
France Telecom
October 12, 2009
A+P for Proxy Mobile IPv6
draft-sarikaya-aplusp-pmip-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 15, 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 15, 2010 [Page 1]
Internet-Draft A+P for PMIPv6 October 2009
Abstract
This memo specifies how to use IPv6 a+p technique in mobile networks
for Proxy Mobile IPv6 (PMIPv6). Mobile node which is a dual-stack
node can receive a shared IPv4 Home Address together with a port
range from the Local Mobility Agent (LMA). LMA is co-located with
Port Range Router (PRR). Mobile Access Gateway (MAG) encapsulates
IPv4 datagrams in IPv6 which are decapsulated at the LMA. In the
binding mode, LMA as PRR receives incoming IPv4 datagrams, determines
the routing identifier, 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.
Mobile network could be WiMAX network or 3GPP Long Term Evolution
(LTE) network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Contribution of This Memo . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Port-Range-based PMIPv6 Solution . . . . . . . . . . . . 4
3.1. Overall Procedure . . . . . . . . . . . . . . . . . . . . 4
3.2. IPv4 Data Flow . . . . . . . . . . . . . . . . . . . . . . 7
4. IPv6 Port-Range-based Mobile IPv6 Solution: stateless mode . . 8
5. Extensions to Proxy Mobile IPv6 . . . . . . . . . . . . . . . 9
5.1. Proxy Binding Update Extensions . . . . . . . . . . . . . 9
5.2. Proxy Binding Acknowledgement Extensions . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative references . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Sarikaya, et al. Expires April 15, 2010 [Page 2]
Internet-Draft A+P for PMIPv6 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 presents a mobility port-range solution combining the
port range for Proxy Mobile IPv6 (PMIPv6, [RFC5213]). For Proxy
Mobile IPv6, we use the router-based architecture of DS-lite. In
this case MAG is the softwire initiator and it encapsulates IPv4
datagrams in IPv6 and sends them to the port range router which is
Sarikaya, et al. Expires April 15, 2010 [Page 3]
Internet-Draft A+P for PMIPv6 October 2009
co-located with the local mobility anchor. Port range router
functionality replaces DS-Lite Carrier Grade NAT (CGN). Inbound
datagrams are received by the Port Range Router whose binding table
is integrated with the binding cache of LMA. LMA then searches its
binding cache and finds IPv6 care-of address and then encapsulates
the datagram and sends it to the MAG which decapsulates it and sends
it to MN.
Proxy Mobile IPv6 defines other scenarios as well in
[I-D.ietf-netlmm-pmip6-ipv4-support]. Scenarios such as MAG behind a
NAT which requires NAT traversal mechanisms. Using port range and
DS-lite router-based architecture, the need for these more
complicated operations is eliminated.
Proxy Mobile IPv6 is defined to provide network-based mobility
support without any mobility signaling from the mobile nodes. Proxy
Mobile IPv6 is expected to work on unmodified hosts. The solution
proposed below in Section 3 however requires mobile nodes to be able
to request port range IPv4 addresses. Mobile node modification is
inherent in this solution.
2. Terminology
This document uses the terminology defined in
[I-D.ietf-softwire-dual-stack-lite], [I-D.boucadair-port-range] and
[I-D.bajko-pripaddrassign], [RFC5213] and
[I-D.ietf-netlmm-pmip6-ipv4-support].
3. Basic Port-Range-based PMIPv6 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 4 describes an
alternative in which this binding is not required.
3.1. Overall Procedure
IPv4-enabled dual-stack MN can get an IPv4 Home Address. The
simplest scenario is as follows: to register MN with LMA, MAG sends
an IPv6 Binding Update to LMA. MAG MUST include IPv4 Home Address
option defined in [RFC5555] extended with port range value and mask
in the Proxy Binding Update (PBU) and set the address to 0.0.0.0.
LMA assigns an IPv4 Home Address and port range and returns it in a
Proxy Binding Acknowledgement (PBA) using an extended IPv4 Home
Address option called IPv4 Home Address and Port Range (HoA-PR)
Sarikaya, et al. Expires April 15, 2010 [Page 4]
Internet-Draft A+P for PMIPv6 October 2009
defined in Section 5. MN sends IPv4 datagrams to MAG. then, MAG
tunnels (IPv4-in-IPv6) datagrams to LMA.
We will describe two more scenarios for IPv4 home address
configuration.
MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER(OPTION-IPv4-PRA)
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA-PR)
| |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (OPTION-IPv4-PRA)
|------>| | 6. DHCPREQUEST (OPTION-IPv4-PRA)
|<------| | 7. DHCPACK
Figure 1: Mobile Node IPv4 Address Configuration - 1
Figure 1 illustrates the overall flow exchange to retrieve a shared
IPv4 address. Concretely, the experienced behaviour is as follows:
1. MN enters the network. MN sends DHCPDISCOVER message to DHCP
Proxy/Server [I-D.ietf-netlmm-pmip6-ipv4-support]. The message
will contain OPTION-IPv4-PRA option with the sub-opt type
indicating port mask (value = 1) [I-D.bajko-pripaddrassign].
2. MAG registers this MN by sending a Proxy Binding Update message
to LMA. MAG adds IPv4 Home Address Option with port range value
and range and sets IPv4 Home Address field in the option to
0.0.0.0.
3. LMA assigns a shared IPv4 Home Address and a port range address
for this MN. LMA sends Proxy Binding Acknowledgement with IPv4
Address Acknowledgement and Port Range option. If MN is dual-
stack, LMA assigns Home Network Prefix(es) for MN and includes
them in the PBA. LMA creates a binding in its binding cache for
IPv4 HoA (and MN HNP if MN is dual-stack). In the binding cache,
together with IPv4 HoA, the port range and port mask MUST also be
included. LMA acting as Port Range Router also assigns MAG's
IPv6 address (Proxy-CoA) (in the source address of PBU) as the
binding identifier for MN. HA adds an entry containing (IPv4
HoA, port mask, port range, Proxy-CoA) to the binding table for
this MN [I-D.boucadair-port-range].
4. A tunnel is established between MAG and LMA. This is DS-Lite
tunnel between IPv6 address of the interface of MAG towards LMA
and IPv6 address of the interface of LMA towards MAG.
5. MN receives DHCP OFFER message with the 'yiaddr' (client IP
address) field set to 0.0.0.0 and with OPTION-IPv4-PRA option
with the sub-opt type indicating port mask (value = 1). The
Sarikaya, et al. Expires April 15, 2010 [Page 5]
Internet-Draft A+P for PMIPv6 October 2009
option contains the shared IPv4 address and port range and mask.
DHCP Proxy/Server MUST assign the IPv4 address and port range
received in Step 3 to the MN.
6. MN sends DHCP REQUEST message. MN 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. MN receives DHCP ACK message with OPTION-IPv4-PRA. MN uses this
address as its IPv4 address.
MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA-PR)
| |========| | 3. Tunnel/Route Setup
|------>|-------------->| 4. DHCPDISCOVER (OPTION-IPv4-PRA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (OPTION-IPv4-PRA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (OPTION-IPv4-PRA) via DHCP-R
|<------|<--------------| 7. DHCPACK via DHCP-R
Figure 2: Mobile Node IPv4 Address Configuration - 2
The mobile node address configuration in Figure 2 has the following
steps:
1. MN enters the network. MAG registers this MN by sending a Proxy
Binding Update message to LMA. MAG adds IPv4 Home Address Option
with port range value and range and sets IPv4 Home Address field
in the option to 0.0.0.0.
2. LMA assigns a shared IPv4 Home Address and a port range address
for this MN. LMA sends Proxy Binding Acknowledgement with IPv4
Address Acknowledgement and Port Range Option. If MN is dual-
stack, LMA assigns Home Network Prefix(es) for MN and includes
them in the PBA. LMA creates a binding in its binding cache for
IPv4 HoA (and MN HNP if MN is dual-stack). In the binding cache,
together with IPv4 HoA, the port range and port mask MUST also be
included. LMA acting as Port Range Router also assigns MAG's
IPv6 address (Proxy-CoA) (in the source address of PBU) as the
binding identifier for MN. HA adds an entry containing (IPv4
HoA, port mask, port range, Proxy-CoA) to the binding table for
this MN [I-D.boucadair-port-range].
3. A tunnel is established between MAG and LMA. This is DS-Lite
tunnel between IPv6 address of the interface of MAG towards LMA
and IPv6 address of the interface of LMA towards MAG.
Sarikaya, et al. Expires April 15, 2010 [Page 6]
Internet-Draft A+P for PMIPv6 October 2009
4. MN sends DHCPDISCOVER message to DHCP Relay Agent
[I-D.ietf-netlmm-pmip6-ipv4-support]. The message will contain
OPTION-IPv4-PRA Option with the sub-opt type indicating port mask
(value = 1) [I-D.bajko-pripaddrassign]. DHCPv4 Relay sends this
message to DHCP server.
5. MN receives DHCP OFFER message with the 'yiaddr' (client IP
address) field set to 0.0.0.0 and with OPTION-IPv4-PRA Option
with the sub-opt type indicating port mask (value = 1). The
option contains the shared IPv4 address and port range and mask.
DHCP Server MUST assign the IPv4 address and port range received
in Step 2 to the MN.
6. MN sends DHCP REQUEST message. MN 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. MN receives DHCP ACK message with OPTION-IPv4-PRA. MN uses this
address as its IPv4 address.
MN sends IPv4 datagrams to MAG. LMA tunnels these datagrams are
tunneled to LMA using IPv4-in-IPv6 encapsulation scheme. Internal
IPv4 packet's source address is IPv4 HoA. Internal IPv4 packet's
source port MUST be within range defined by the port range and mask
sent by LMA.
MN handoffs and gets connected to a different network. MN sends DHCP
RENEW message to DHCP Proxy/Server or Relay Agent which is colocated
with the new MAG. The new MAG sends a PBU to LMA to register this
move. DHCP RENEW MUST include IPv4 Home Address and Port Range
Options. LMA modifies the binding cache with the new Proxy-CoA for
this MN. LMA MUST modify the binding table by changing the binding
identifier for this IPv4 address and port range.
3.2. IPv4 Data Flow
Port Range Router collocated in LMA 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 mask and port range. If an entry is
found then the binding identifier (Proxy-CoA) is determined. Next
LMA searches the binding cache for IPv4 HoA and port range to verify
that there is a binding cache entry for this MN. HA tunnels the
received IPv4 datagram to the MAG at the destination address of
Proxy-CoA.
When MN has IPv4 data to send MN always sends the datagram in IPv4 to
Sarikaya, et al. Expires April 15, 2010 [Page 7]
Internet-Draft A+P for PMIPv6 October 2009
the MAG it is currently connected. MAG encapsulates IPv4 datagrams
in IPv6 and sends them to LMA in the MAG-LMA tunnel. LMA
decapsulates the datagram. LMA 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.
4. IPv6 Port-Range-based Mobile IPv6 Solution: stateless mode
If the network is configured as DS-lite network
[I-D.ietf-softwire-dual-stack-lite] the following two implications
should be taken into account:
In the scenario in Figure 2, it is not possible for DHCPv4 Relay
Agent to communicate with DHCPv4 Server in IPv4. Mobile Access
Gateway (collocated with DHCPv4 Relay) has to encapsulate DHCPv4
messages in IPv6 before sending them to DHCPv4 Server.
Alternatively, 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].
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.
For outgoing communications, the same behaviour as described in
Section 3.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
behaviour.
This mode is completely stateless (except for the mobility management
aspects), i.e. no binding table is needed.
Sarikaya, et al. Expires April 15, 2010 [Page 8]
Internet-Draft A+P for PMIPv6 October 2009
5. Extensions to Proxy Mobile IPv6
5.1. Proxy Binding Update Extensions
IPv4 Home Address Option defined in [RFC5555] is extended to also
carry the port range value and mask and this new option is called
IPv4 Home Address and Port Range Option.
This option is included in the mobility header, including the proxy
binding update message sent from the mobile access gateway to the
local mobility anchor.
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 3: 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]
IPv4 home address
As defined in [RFC5555]. Mobile access gateway MUST set this
field to 0.0.0.0.
Sarikaya, et al. Expires April 15, 2010 [Page 9]
Internet-Draft A+P for PMIPv6 October 2009
Port Range Value
16-bit field that indicates the value of the mask to be applied.
Mobile access gateway 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 access gateway must set this field
to all zeros.
5.2. Proxy Binding Acknowledgement Extensions
IPv4 Home Address Acknowledgement option defined in [RFC5555] is
extended to also carry the port range value and 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 4: IPv4 Home Address and Port Range Acknowledgement Option
Type
TBA2 for Type
Length
10
Prefix-len
As defined in [RFC5555]
Res
As defined in [RFC5555]
IPv4 home address
As defined in [RFC5555]. Local mobility anchor sets this field to
the value that it will use in the binding cache entry. This
address is a public address.
Sarikaya, et al. Expires April 15, 2010 [Page 10]
Internet-Draft A+P for PMIPv6 October 2009
Port Range Value
16-bit field that indicates the value of the mask to be applied.
Local mobility anchor 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. Local mobility anchor 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
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgements
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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",
Sarikaya, et al. Expires April 15, 2010 [Page 11]
Internet-Draft A+P for PMIPv6 October 2009
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.ymbk-aplusp]
Bush, R., "The A+P Approach to the IPv4 Address Shortage",
draft-ymbk-aplusp-04 (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.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Sarikaya, et al. Expires April 15, 2010 [Page 12]
Internet-Draft A+P for PMIPv6 October 2009
9.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.
[3GPP29275]
"3GPP TS 29.275. Proxy Mobile IPv6 (PMIPv6) based
Mobility and Tunnelling protocols; Stage 3",
September 2009.
[WiMAXnwg]
"WiMAX Forum Networking Working Group Stage 3
Specification Release 1.5.", March 2009.
Sarikaya, et al. Expires April 15, 2010 [Page 13]
Internet-Draft A+P for PMIPv6 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 15, 2010 [Page 14]