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]