NETLMM Working Group R. Wakikawa Internet-Draft Keio University Intended status: Standards Track S. Gundavelli Expires: January 10, 2008 Cisco July 9, 2007 IPv4 Support for Proxy Mobile IPv6 draft-ietf-netlmm-pmip6-ipv4-support-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Wakikawa & Gundavelli Expires January 10, 2008 [Page 1] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 Abstract This document specifies extensions to the Proxy Mobile IPv6 protocol [ID-PMIP6] for supporting IPv4. The scope of the IPv4 support in Proxy Mobile IPv6 includes the support for the mobile node's IPv4 home address mobility and for supporting the scenario where the local mobility anchor and the mobile access gateway are separated by an IPv4 transport network. The solution primarily leverages the extensions defined in Dual Stack Mobile IPv6 specification [ID- DSMIP6] for achieving this. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7 3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7 3.2. Extensions to Conceptual Data Structure . . . . . . . . . 9 3.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 9 3.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 9 3.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 11 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 13 4.1. Mobility Options . . . . . . . . . . . . . . . . . . . . . 13 4.2. Extensions to Conceptual Data Structure . . . . . . . . . 13 4.3. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 14 4.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 16 4.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Wakikawa & Gundavelli Expires January 10, 2008 [Page 2] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Wakikawa & Gundavelli Expires January 10, 2008 [Page 3] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 1. Overview The transition from IPv4 to IPv6 is a long process and during this period of transition, both the protocols will be enabled over the same infrastructure. Thus, it is reasonable to assume that the mobile node, mobile access gateway and the local mobility anchor are both IPv4 and IPv6 enabled and further it is also reasonable to expect the same mobility infrastructure to provide both IPv4 and IPv6 address mobility for a mobile node. The motivation and scope of IPv4 support in Mobile IPv6 is summarized in [ID-DSMIP6-PS]. The Proxy Mobile IPv6 base specification [ID-PMIP6] defines a network-based mobility management protocol. The protocol specifies a solution for providing IPv6 home address mobility for a mobile node and over an IPv6 transport network separating the entities involved in the mobility management. This specification defines extensions to the Proxy Mobile IPv6 protocol for supporting IPv4. The scope of these IPv4 related extensions are the following: o IPv4 Home Address Mobility: A mobile node operating in IPv4-only mode or in a dual-stack mode should be able to obtain an IPv4 home address and roam anywhere in that Proxy Mobile IPv6 domain. o IPv4 Transport Network Support: The transport network between the local mobility anchor and the mobile access gateway is an IPv4 network and further the local mobility anchor or the mobile access gateway may be using IPv4 private addresses and with NAT translation devices on the path The Dual-Stack Mobile IPv6 specification [ID-DSMIP6], extends IPv4 home address mobility and IPv4 transport network support to the Mobile IPv6 protocol [RFC-3775]. The solution specified in this document leverages the DSMIP6 extensions for extending IPv4 support to Proxy Mobile IPv6 protocol. The protocol semantics, processing logic and mobility header options, such as IPv4 home address option, IPv4 address acknowledgment option and NAT detection option, defined in the DSMIP6 specification, are all applied for Proxy Mobile IPv6 protocol. As specified in DSMIPv6, these two features, IPv4 Home Address Mobility support and IPv4 transport support, are independent of each other and implementers may choose to implement any one or both of these features. Unlike in DSMIP6, a mobile node in Proxy Mobile domain is NOT required to have an IPv6 home address for obtaining IPv4 home address mobility. As specified in the Proxy Mobile IPv6 specification [ID-PMIP6], this specification assumes that the link between the mobile access gateway and the local mobility anchor is a point-to-point link. This specification also assumes that the local mobility anchor and the Wakikawa & Gundavelli Expires January 10, 2008 [Page 4] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 mobile access gateway are both IPv6 capable and IPv6 enabled and even when the network between the mobile access gateway and a local mobility anchor is IPv4-only network. The signaling protocol is primarily based on Mobile IPv6 and hence the entities providing the network-based mobility management service must be IPv6 enabled. Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home address mobility and IPv4 transport network features. The mobile nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or dual-stack mode, and the transport network between the local mobility anchor and the mobile access gateway may be an IPv6 network or an IPv4 network. Further, when the transport network is IPv4, either the local mobility anchor or the mobile access gateway, or both can be behind a NAT translation device and configured with an IPv4 private address. +----+ +----+ |LMA1| |LMA2| +----+ +----+ IPv4-LMAA1 -> | | <-- IPv4-LMAA2 | | \\ //\\ [NAT] // \\ \\ // \\ +---\\------------- //------\\----+ ( \\ IPv4/IPv6 // \\ ) ( \\ Network // \\ ) +------\\--------//------------\\-+ \\ // \\ \\ // [NAT] \\ // \\ IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2 +----+ +----+ |MAG1|-----[MN2] |MAG2| +----+ | +----+ | | | IPv4-MN-HoA1 --> | IPv4-MN-HoA2 | <-- IPv4-MN-HoA3 [MN1] [MN3] Figure 1: IPv4 support for Proxy Mobile IPv6 Wakikawa & Gundavelli Expires January 10, 2008 [Page 5] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 2. Conventions & Terminology 2.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 2.2. Terminology All the mobility related terms used in this document are to be interpreted as defined in Mobile IPv6 specification [RFC-3775], DSMIP6 specification [ID-DSMIP6] and Proxy Mobile IPv6 specification [ID-PMIP6]. In addition the document introduces the following terms. IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) The IPv4 Care-of Address that is configured on the interface of the mobile access gateway and is the transport endpoint of the tunnel between a local mobility anchor and a mobile access gateway. However, when the configured address is a private IPv4 address and with a NAT device in the path to the local mobility anchor, the care-of address as seen by the local mobility anchor will be the address allocated by the NAT device for the mobility session. IPv4 Local Mobility Anchor Address (IPv4-LMAA) The global IPv4 address that is typically configured on the interface of a local mobility anchor and is the transport endpoint of the tunnel between a local mobility anchor and a mobile access gateway. This is the address to where a mobile access gateway sends proxy binding update messages. If a local mobility anchor is configured behind NAT, IPv4-LMAA is the IPv6 global address of the NAT box. According to Section 2.1 of [ID-DSMIP6], two options are introduced for the case of the home agent being behind the NAT box. When we interpret this two options for Proxy Mobile IPv6, it goes following. 1) configure a public IPv4 address for each local mobility anchor on the NAT box. 2) configure one public address and make the local mobility anchors share the public address. Wakikawa & Gundavelli Expires January 10, 2008 [Page 6] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 3. IPv4 Home Address Mobility Support Using the extensions defined in this specification, a mobile node operating in an IPv4-only or dual-stack mode will be able to obtain an IPv4 address (IPv4-MN-HoA) and will be able to roam in that Proxy Mobile IPv6 domain using that address. Although IPv6 home address is always required in [ID-DSMIP6], this specification does not mandate IPv6 home address unless a mobile node wants the IPv6 home address. The network will provide mobility to that mobile node in that entire domain. And further, the network will ensure that the mobile node will always be able to obtain the same IPv4 address, as it moves between access links and as long as the mobile node is in the scope of that Proxy Mobile IPv6 domain. 3.1. IPv4 Home Address Assignment A mobile node on attaching to an access link connected to a mobile access gateway, and if the network allows the mobile node for IPv4 home address mobility service, the mobile node using any of the IPv4 address configuration procedures, such as DHCP, IPCP or IKEv2 that are supported on that access link, will be able to obtain its IPv4 home address configuration. The IPv4 home address configuration includes the IPv4 home address, the IPv4 home network prefix and IPv4 home network prefix length. Figure 2 shows the operational sequence of the home address mobility support when a local mobility anchor assigns an IPv4 Home Address dynamically to a mobile node. All mobile access gateways SHOULD support minimal functionality of DHCP server in order to send DHCP offer and and acknowledgment messages to the mobile node in reply to the DHCP discovery and request messages. The mobile access gateway is seen as a DHCP server from a mobile node, but it actually obtains the IPv4 home address for each mobile node from the local mobility anchor during proxy binding procedure (set 0.0.0.0 in the the IPv4 Home Address field of the IPv4 home address option as described in [ID-DSMIP]). The mobile access gateway MUST return its own IP address in the 'server identifier' option when sending DHCP offer message to the mobile node. Thus, whenever the mobile node changes the attached mobile access gateway, this server identifier must be updated. The detail can be found in Section 3.4. Any information carried in DHCP options such as addresses of domain name server, time server, lpr server, etc. MUST be configured in all the mobile access gateway (i.e. DHCP server) if necessary. If IPCP is used for address assignment, DHCP events in Figure 2 are replaced by PPP events. Wakikawa & Gundavelli Expires January 10, 2008 [Page 7] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 MN MAG(DHCPS) LMA |------>| | 1. DHCP discovery | |------->| 2. Proxy Binding Update | |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) | |========| 4. Tunnel/Route Setup* |<------| | 5. DHCP offer (IPv4 HoA) ** |------>| | 6. DHCP request (IPv4 HoA) |<------| | 7. DHCP acknowledgement | | | * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7) are processed in parallel. ** MAG SHOULD return its own IP address in the 'server identifier' option when sending DHCP offer. Figure 2: An example when LMA assigns an IPv4 home address In addition to this, other address configuration mechanisms including static configuration methods specific to the access link or dynamic configuration from the DHCP server (without local mobility anchor involvmenet) may also be in place. Several other assignment schems are listed: o Static IPv4 Home Address Assignment: When a mobile node is configured with a static IPv4 home address, the IPv4 home address information MUST be stored in the mobile node's policy profile. The mobile access gateway where the mobile node attached obtains the static IPv4 home address from the policy profile. The mobile access gateway MUST set the known IPv4 home prefix to the IPv4 Home Address field and the Pref field of the IPv4 home address option [ID-DSMIP6]. This option is carried by a proxy binding update described in [ID-PMIP6]. o Dynamic IPv4 Home Address Assignment from DHCP Server: If DHCP is used for the IPv4 home address allocation, a DHCP server and a DHCP relay agent on the link will ensure the mobile node is assigned an address from its home network prefix. In this case, the local mobility anchor only deals with route setup and tunnel setup for the requested home address. A DHCP relay and a mobile access gateway should be co-located. Otherwise, the mobile access gateway MUST learn the IPv4 home address from the DHCP reply. Meanwhile, it notifies the assigned IPv4 home address by an IPv4 home address option in a proxy binding update to the local mobility anchor. Some remarks can be found in Section 6. Wakikawa & Gundavelli Expires January 10, 2008 [Page 8] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 3.2. Extensions to Conceptual Data Structure There are certain extensions defined in DSMIP specification [DSMIP6] for supporting IPv4 home address mobility support. A mobile node can obtain only IPv4 home address by this specification, while DSMIP requires IPv6 home address for IPv4 home address support. Thus, a mobile access gateway and a local mobility agent MUST create a binding update list and a binding cache only for IPv4 home address assigned to a mobile node. 3.3. Mobility Options For supporting the IPv4 home address mobility, the following options are required from the DSMIPv6 specification [ID-DSMIP6]. o IPv4 Home Address Option defined in section 3.1.1 of [ID-DSMIP6]. This option MUST be present in the Proxy Binding Update message sent by the mobile access gateway to the local mobility anchor, when requesting IPv4 home address support. o IPv4 Address Acknowledgment Option defined in section 3.2.1 of [ID-DSMIP6]. This option MUST be present in the Proxy Binding Acknowledgment, if the local mobility anchor accepts IPv4 home address support. 3.4. Mobile Access Gateway Operation o All the considerations as explained in Section 6.11 of the base Proxy Mobile IPv6 specification apply here. o When a mobile node attached to an access link and attempts to obtain an IPv4 address configuration, using DHCP or other procedures, it will get an IPv4 address as a IPv4 home address from its home network prefix as discussed in Section 3.1. The mobile access gateway on the access link where mobile node is attached, will register this address with the local mobility anchor using the IPv4 Home Address option, defined in Section 3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a proxy binding update as shown in Figure 3. The proxy binding update MUST be protected by IPsec ESP. How to build the IPv4 home address option is varied as follows: * If a mobile access gateway needs to request dynamic IPv4 home address allocation to the local mobility anchor, it MUST set 0.0.0.0 in the the IPv4 Home Address field of the IPv4 home address option as described in [ID-DSMIP] and send this option by the proxy binding update. Wakikawa & Gundavelli Expires January 10, 2008 [Page 9] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 * If a mobile access gateway knows the IPv4 home prefix (or home address) for the mobile node from static mobile node's policy profile or DHCP server, it MUST set the known IPv4 home prefix to the IPv4 Home Address field and the Pref field of the IPv4 home address option. This option is carried by a proxy binding update described in Proxy Mobile IPv6 specification [ID-PMIP6]. IPv6 header (src=PCoA, dst=LMAA) Mobility header -BU /*P flag is set*/ Mobility Options -HNP* /*IPv6 home address*/ -TSO* -IPv4-HAO *HNP: Home Network Prefix Option *TSO: Time Stamp Option Figure 3: Proxy Binding Update for IPv4 Home Address Support o When a mobile node gets IPv4 home address from Local Mobility Anchor through DHCP interaction with MAG that supports DHCP server functionality, the DHCP client in the mobile node recognizes MAG's IP address as DHCP server's IP address. Thus, the DHCP client unicasts DHCP renew to the MAG, when the DHCP client goes into the DHCP RENEWING state [RFC2131]. However, when the mobile node handovers to a new MAG, the mobile node does not know the link change and the DHCP client would unicast DHCP request to the previous MAG whose IP address was acquired from DHCP offer. So, DHCP client in the mobile node needs to reconfigure its local configuration parameters. Therefore, MAG SHOULD discard any DHCP request message that does not belong to the MAG itself, so that the mobile node should go into the DHCP REBINDING state and broadcast DHCP request without server identifier. o A proxy binding acknowledgment will be returned by the local mobility anchor. In the proxy binding acknowledgment, an IPv4 address acknowledgment option MUST be presented in reply to the IPv4 home address option. The processing of this IPv4 home acknowledgment option is found in DSMIP6 specification [ID- DSMIP6]. o After receiving a Proxy Binding Acknowledgment message with the IPv4 Address Acknowledgment Option and if the status code in the Binding Acknowledgment and Status field in the IPv4 Address Wakikawa & Gundavelli Expires January 10, 2008 [Page 10] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 Acknowledgment values are set to Success, the mobile access gateway MUST setup a tunnel to the local mobility anchor and must also add a default route over the tunnel for all the mobile node's IPv4 traffic. The encapsulation modes for the bi-directional tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6 specification [ID-PMIP6] and as in this specification. o If the Status field in the IPv4 Address Acknowledgment Option indicates the rejection of the IPv4 home address mobility service, the mobile access gateway MUST not enable IPv4 routing for the mobile node's IPv4 traffic. 3.5. Local Mobility Anchor Operation o Upon receiving a Proxy Binding Update message with the IPv4 Home Address Option, defined in Section 3.1.1 of DSMIP6 specification [ID-DSMIP6], the local mobility anchor, if it determines that the mobile node is configured for IPv4 home address mobility service, the local mobility anchor MUST send the Proxy Binding Acknowledgment message with the IPv4 Address Acknowledgment Option, defined in Section 3.2.1 of DSMIP6 specification. How to process the IPv4 home address option and how to return the IPv4 address acknowledgment are described in [ID-DSMIP6]. IPv6 header (src=PCoA, dst=LMAA) Mobility header -BA /*P flag is set*/ Mobility Options -HNP* /*IPv6 home address*/ -TSO* -IPv4-ACK -IPv4-DRA *HNP: Home Network Prefix Option *TSO: Time Stamp Option Figure 4: Proxy Binding Acknowledgement for IPv4 Home Address Support o After accepting the registration for the mobile node's IPv4 home address, the local mobility anchor will add an IPv4 host route over the tunnel to the mobile access gateway. Any IPv4 packets that the local mobility anchor receives from a correspondent node will be tunneled to the mobile access gateway over the bi- directional tunnel, and then routed accordingly after removing the tunnel header. The encapsulation modes for the bi-directional tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6 Wakikawa & Gundavelli Expires January 10, 2008 [Page 11] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 specification [ID-PMIP6] and as in this specification. Wakikawa & Gundavelli Expires January 10, 2008 [Page 12] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 4. IPv4 Transport Support As per the Proxy Mobile IPv6 specification [ID-PMIP6], the transport network between the local mobility anchor and the mobile access gateway is an IPv6 network. This specification defines extensions for supporting the scenario where the local mobility anchor and the mobile access gateway may be separated by an IPv4 transport network and further these entities may be configured with IPv4 private addresses and with NAT translation devices in the path. When the network between the local mobility anchor and the mobile access gateway is an IPv4 network, the mobile access gateway can potentially register an IPv4 address with the local mobility anchor, as the care-of address in the mobile node's binding cache entry and thus creating an IPv4 tunnel for carrying all the mobile node's traffic. The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing a mobile node to roam over an IPv4 network and the same solution can be extended to Proxy Mobile IPv6. As explained in Section 4.1, of the DSMIPv6 specification, a mobile access gateway can encapsulate a Proxy Binding Update IPv6 message in an IPv4-UDP packet and route it to the local mobility anchor. The processing logic and the on path NAT detection logic is just as described in Section 4.3. The signaling messages will always be IPv6 messages encapsulated in an IPv4 packet and carried as an IPv4 packet. The data traffic to and from the mobile node will also be encapsulated and carried as IPv4 packets. This specification does not cover the dynamic discovery of the IPv4 address of the local mobility anchor (IPv4-LMAA) and thus it is assumed that the mobile access gateway can learn this address from the mobile node's policy profile or it can obtain this information through other techniques that are beyond the scope of this document. 4.1. Mobility Options For supporting IPv4 transport support, the following options are required from the DSMIP6 specification [ID-DSMIP6]. o NAT detection Option, defined in section 3.2.2 of the DSMIP specification [ID-DSMIP6]. This option MUST be present in the Proxy Binding Acknowledgment when the local mobility anchor detects NAT in the path between mobile access gateway and itself. 4.2. Extensions to Conceptual Data Structure There are certain extensions defined in DSMIP6 specification [ID- DSMIP6] for supporting this feature. Wakikawa & Gundavelli Expires January 10, 2008 [Page 13] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 4.3. NAT Detection The NAT detection logic in Proxy Mobile IPv6 is just as specified in DSMIP6 specification. When the transport network between the local mobility anchor and the mobile access gateway is an IPv4 network, the mobile access gateway must send Proxy Binding Update message encapsulated in an IPv4-UDP packet. On receiving this Proxy Binding Update packet encapsulated in an IPv4-UDP packet, the local mobility anchor if it detects a NAT on the path, will send the Proxy Binding Acknowledgment message with the NAT Detection Option. The presence of this option in the Proxy Binding Acknowledgment is an indication to the mobile access gateway about the presence of NAT in the path. On detecting the NAT in the path, both the local mobility anchor and the mobile access gateway will set the encapsulation mode of the tunnel to IPv4-UDP. The specific details around the NAT detection and the related logic is described in in Dual Stack for Mobile IPv6 specification [ID-DSMIP6]. 4.4. Mobile Access Gateway Operation o All the considerations as explained in Section 6.11 of the base Proxy Mobile IPv6 specification apply here. o If IPv4 transport support is enabled in order to place a mobile access gateway at IPv4 only network, the mobile access gateway MUST have an IPv4 address at the visiting network. In addition to that, the mobile access gateway MUST also obtain IPv6 address configured for the Proxy Mobile IPv6 operation. Even if the mobile access gateway does not have connectivity to the IPv6 network, it MUST configure with an IPv6 address for sending the proxy binding registration to the local mobility anchor. o As explained in Section 4.1, of the DSMIPv6 specification, the mobile access gateway can encapsulate a Proxy Binding Update message and carry it in IPv4 and UDP packet. The processing logic for handling the NAT detection at the mobile node is applicable to the mobile access gateway as described in Section 4.3. An example of proxy binding update sent by mobile access gateway is shown in Figure 5. Note that the source address of the inner IPv6 header MUST set to the IPv6 address assigned to the mobile access gateway and the destination address MUST be the local mobility anchor's IPv6 address (LMAA). The source address of the outer packet MUST be the IPv4-proxy-CoA and the destination MUST be the local mobility anchor's IPv4 address (IPv4-LMAA). For the NAT handling, UDP header MUST be always used for the proxy binding update. The UDP port number is defined in [ID-DSMIP6]. The proxy binding update MUST be protected by IPsec ESP. The security association Wakikawa & Gundavelli Expires January 10, 2008 [Page 14] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 for IPv4 addresses of the mobile access gateway and local mobility anchor are pre-established. IPv4 header (src=IPv4-proxy-CoA, dst=IPv4-LMAA) UDP header IPv6 header (src=v6MAG*, dst=LMAA) Mobility header -BU /*P flag is set*/ Mobility Options -HNP* /*IPv6 home address*/ -TSO* -IPv4-HAO /*if IPv4 HoA is required*/ -NAI /* NAI Option */ *HNP: Home Network Prefix Option *TSO: Time Stamp Option *v6MAG: IPv6 address assigned to the mobile access gateway. *NAI: NAI Option Figure 5: Proxy Binding Update from mobile access gateway in IPv4 network o After receiving a Proxy Binding Acknowledgment message encapsulated in an IPv4 packet, the mobile access gateway MUST verify the Proxy Binding Acknowledgment according to the Section 4.3 of DSMIP6 specification [ID-DSMIP6]. o If the Status field indicates Success, the mobile access gateway MUST setup a tunnel to the local mobility anchor and add a default route over the tunnel for all the mobile node's IPv6 traffic. If the NAT is available and the NAT detection option is presented in the Proxy Binding Acknowledgment, the mobile access gateway MUST use UDP tunnel to traverse the NAT and MUST send a proxy binding update every refresh time specified in the NAT detection option. The detailed operation can be found in DSMIP6 specification [ID- DSMIP6]. o If the Status field in the proxy binding acknowledgment indicates the rejection of the binding registration, the mobile access gateway MUST not enable IPv4 transport for the mobile node's traffic. o On receiving any packets from the mobile node's IPv6 home address and/or IPv4 home address, the mobile access gateway tunnels the packets to local mobility anchor as shown in Figure 6 Wakikawa & Gundavelli Expires January 10, 2008 [Page 15] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) UDP header /*Only if NAT is detected*/ union { /*following either v6 or v4 header */ IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) } Upper layer protocols /*TCP,UDP,SCTP*/ Figure 6: Tunneled Packets from MAG to LMA 4.5. Local Mobility Anchor Operation When a mobile node is attached to a mobile access gateway that is reachable only through an IPv4 transport network, the local mobility anchor must establish an IPv4 tunnel for routing the mobile node's IPv4 and IPv6 home address traffic. The DSMIPv6 specification provides the semantics on how the IPv4 tunnel needs to be negotiated and the detection logic of the NAT devices. This specification leverages the NAT Detection Option, defined in the DSMIP6 specification for the use in Binding Acknowledgment message and extends it to Proxy Binding Acknowledgment messages. The operational steps are defined below. o Upon receiving a Proxy Binding Update message encapsulated in an IPv4 packet, the local mobility anchor MUST send the Proxy Binding Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by using IPv4 encapsulation. If the NAT is detected, the NAT detection option MUST be used in the Proxy Binding Acknowledgment. How to detect NAT is described in Section 4.1 of [ID-DSMIP6] and Section 4.3. o An example of proxy binding acknowledgment sent by local mobility anchor is shown below. The same illustration for Mobile IPv6 can be found in Section 4.1 of [ID-DSMIP6]. The proxy binding acknowledgment MUST be protected by IPsec ESP. The security association for IPv4 addresses of the mobile access gateway and local mobility anchor are pre-established. Wakikawa & Gundavelli Expires January 10, 2008 [Page 16] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 IPv4 header (src=IPv4-LMAA, dst=IPv4-proxy-CoA) UDP header /*Only if NAT is detected*/ IPv6 header (src=LMAA, dst=v6MAG) Mobility header -BA /*P flag is set */ Mobility Options -HNP* /* IPv6-MN-HoA */ -TSO* -IPv4-ACK /* Only if IPv4 HoA is required */ -NAT-DET /* Only if NAT is detected */ -NAI /*NAI Option */ *HNP: Home Network Prefix Option *TSO: Time Stamp Option *v6MAG: IPv6 address assigned to the mobile access gateway. Figure 7: Proxy Binding Acknowledgment in IPv4 network o After accepting the registration from the mobile access gateway locating at the IPv4 only network, the local mobility anchor MUST setup a tunnel to the mobile access gateway. The tunnel is established between the v4-LMAA and the IPv4-Proxy-CoA of the mobile access gateway. If the NAT is available and the NAT detection option is included in the Proxy Binding Acknowledgment, the local mobility anchor MUST use UDP encapsulation for the tunnel. The local mobility anchor also setup a host routes for the IPv4 home address and the IPv6 home address of the mobile node over the tunnel to the mobile access gateway. Any traffic that the local mobility anchor receives from a correspondent node will be tunneled to the mobile access gateway over the bi-directional tunnel and then routed accordingly after removing the tunnel headers. The encapsulation modes for the bi-directional tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6 specification [ID-PMIP6] and as in this specification. o When sending any packets meant to a mobile node's IPv4 home address or IPv6 home address, the local mobility anchor tunnels the packet to mobile access gateway as shown in Figure 8 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) UDP header /*Only if NAT is detected*/ union { /*following either v6 or v4 header */ IPv4 header (src=IPv4-CN, dst=IPv4-HoA) IPv6 header (src=IPv6-CN, dst=IPv6-HoA) } Upper layer protocols /*TCP,UDP,SCTP*/ Wakikawa & Gundavelli Expires January 10, 2008 [Page 17] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 Figure 8: Tunneled Packets from LMA to MAG 4.6. Tunnel Management As specified in the Proxy Mobile IPv6 specification, the bi- directional tunnel between the local mobility anchor and the mobile access gateway, is a shared tunnel and all the considerations from Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport as well. Wakikawa & Gundavelli Expires January 10, 2008 [Page 18] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 5. IANA Considerations This document does not define any new messages. The UDP port number for proxy binding update and acknowledgment will be defined in [ID- DSMIP6]. Wakikawa & Gundavelli Expires January 10, 2008 [Page 19] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 6. Security Considerations This specification describes the use of IPv4 transport network between the local mobility anchor and the mobile access gateway. All the signaling messages exchanged between the mobile access gateway and the local mobility anchor over the IPv4 transport MUST be protected using IPsec, just as the messages must be protected when using IPv6 transport and as specified in the Section 4.0, of the Proxy Mobile IPv6 specification [ID-PMIP6]. When supporting IPv4 address assignment from a DHCP server, all the IPv4 home addresses managed in the DHCP server must be reachable via local mobility anchor so that local mobility anchor intercepts packets meant for an IPv4 home address and tunnels them to the mobile node via corresponding mobile access gateway. Moreover, all the DHCP messages between a DHCP relay and the DHCP server SHOULD be securely exchanged. After receiving a Proxy Binding Update message with an IPv4 Home Address Option, the local mobility anchor MUST be able to verify that the mobile node is authorized to use that address before setting up forwarding for that host route. When supporting dynamic IPv4 address assignment by DHCP and also from local mobility anchor, it should be ensured both the entities are configured with different address pools, so as to avoid both entities do not allocate the same address to different mobile nodes. Wakikawa & Gundavelli Expires January 10, 2008 [Page 20] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 7. Contributors This document reflects discussions and contributions from several people (in alphabetical order): Kuntal Chowdhury kchowdhury@starentnetworks.com Vijay Devarapalli vijay.devarapalli@azairenet.com Sangjin Jeong sjjeong@etri.re.kr Basavaraj Patil basavaraj.patil@nsn.com Myungki Shin myungki.shin@gmail.com 8. Acknowledgments The IPv4 support for Proxy Mobile IPv6 was initially covered in the internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. This document leverages lot of text from that document. We would like to thank all the authors of the document and acknowledge that initial work. 9. References 9.1. Normative References [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wakikawa & Gundavelli Expires January 10, 2008 [Page 21] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for Network-based Localized Mobility Management", September 2006. [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, G., Liebsch, M., "Goals for Network-based Localized Mobility Management", October 2006. [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based Localized Mobility Management", September 2006. [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03.txt ,October 2006. [ID-MIP6-IKEV2] Devarapalli, V. and Dupont, F., "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-08.txt, December 2006. [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-01.txt, December 2007. 9.2. Informative References [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and Wakikawa & Gundavelli Expires January 10, 2008 [Page 22] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 4303, December 2005. [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [ID-DSMIP6-PS] Tsirtsis, G., et.al, "Problem Statement: Dual Stack Mobility", draft-ietf-mip6-dsmip-problem-03.txt, January 2007. Wakikawa & Gundavelli Expires January 10, 2008 [Page 23] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 Authors' Addresses Ryuji Wakikawa Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Email: ryuji@sfc.wide.ad.jp Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Wakikawa & Gundavelli Expires January 10, 2008 [Page 24] Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wakikawa & Gundavelli Expires January 10, 2008 [Page 25]