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]