diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5844.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5844.txt')
| -rw-r--r-- | doc/rfc/rfc5844.txt | 2747 |
1 files changed, 2747 insertions, 0 deletions
diff --git a/doc/rfc/rfc5844.txt b/doc/rfc/rfc5844.txt new file mode 100644 index 0000000..2b1b512 --- /dev/null +++ b/doc/rfc/rfc5844.txt @@ -0,0 +1,2747 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Wakikawa +Request for Comments: 5844 Toyota ITC +Category: Standards Track S. Gundavelli +ISSN: 2070-1721 Cisco + May 2010 + + + IPv4 Support for Proxy Mobile IPv6 + +Abstract + + This document specifies extensions to the Proxy Mobile IPv6 protocol + for adding IPv4 protocol support. The scope of IPv4 protocol support + is two-fold: 1) enable IPv4 home address mobility support to the + mobile node, and 2) allow the mobility entities in the Proxy Mobile + IPv6 domain to exchange signaling messages over an IPv4 transport + network. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5844. + +Copyright Notice + + Copyright (c) 2010 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Wakikawa & Gundavelli Standards Track [Page 1] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +Table of Contents + + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 5 + 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 + 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8 + 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 9 + 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 9 + 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 10 + 3.1.3. Routing Considerations for the Local Mobility + Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3.1.4. ECN and Payload Fragmentation Considerations . . . . . 16 + 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 + 3.2.1. Extensions to Binding Update List Entry . . . . . . . 17 + 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17 + 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17 + 3.2.4. Routing Considerations for the Mobile Access + Gateway . . . . . . . . . . . . . . . . . . . . . . . 21 + 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22 + 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 22 + 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 23 + 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25 + 3.3.4. IPv4 DHCP Support Mode Option . . . . . . . . . . . . 25 + 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 26 + 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 27 + 3.4.1. DHCP Server Co-Located with the Mobile Access + Gateway . . . . . . . . . . . . . . . . . . . . . . . 28 + 3.4.2. DHCP Relay Agent Co-Located with the Mobile Access + Gateway . . . . . . . . . . . . . . . . . . . . . . . 31 + 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 33 + 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 35 + 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 37 + 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 37 + 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 37 + 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 37 + 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39 + 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40 + 4.2.1. Extensions to Binding Update List Entry . . . . . . . 40 + 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40 + 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 43 + 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 43 + 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 43 + 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44 + 5.1. Local Mobility Anchor - Configuration Variables . . . . . 44 + 5.2. Mobile Access Gateway - Configuration Variables . . . . . 44 + + + +Wakikawa & Gundavelli Standards Track [Page 2] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 48 + +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 network infrastructure. Thus, it is reasonable to assume that a + mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4- + only, IPv6-only, or dual-stack mode, and the network between the + mobile access gateway and a local mobility anchor may be an IPv4 or + an IPv6 network. It is also reasonable to expect the same mobility + infrastructure in the Proxy Mobile IPv6 domain to provide mobility to + the mobile nodes operating in IPv4, IPv6, or in dual mode and whether + the transport network is IPv4 or IPv6 network. The motivation and + scope of IPv4 support in Mobile IPv6 is summarized in [RFC4977], and + all those requirements apply to Proxy Mobile IPv6 protocol as well. + + The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for + providing IPv6 home address mobility support to a mobile node in a + Proxy Mobile IPv6 domain. The protocol requires IPv6 transport + network between the mobility entities. The extensions defined in + this document specify IPv4 support to the Proxy Mobile IPv6 protocol + [RFC5213]. + + The scope of IPv4 support in Proxy Mobile IPv6 includes the support + for the following two features: + + o IPv4 Home Address Mobility Support: A mobile node that is dual- + stack or IPv4-only enabled will be able to obtain an IPv4 address + and be able to use that address from any of the access networks in + that Proxy Mobile IPv6 domain. The mobile node is not required to + be allocated or assigned an IPv6 address to enable IPv4 home + address support. + + o IPv4 Transport Network Support: The mobility entities in the Proxy + Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 + signaling messages over an IPv4 transport. + + These two features, the IPv4 home address mobility support and the + IPv4 transport support features, are independent of each other, and + deployments may choose to enable either one or both of these features + as required. + + + +Wakikawa & Gundavelli Standards Track [Page 3] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + Figure 1 shows a typical Proxy Mobile IPv6 domain with an IPv4 + transport network and with IPv4 enabled mobile nodes. The terms used + in this illustration are explained in the Terminology section. + + +----+ +----+ + |LMA1| |LMA2| + +----+ +----+ + IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA + | | + \\ //\\ + \\ // \\ + \\ // \\ + +---\\------------- //------\\----+ + ( \\ IPv4/IPv6 // \\ ) + ( \\ Network // \\ ) + +------\\--------//------------\\-+ + \\ // \\ + \\ // \\ + \\ // \\ + IPv4-Proxy-CoA --> | | <-- Proxy-CoA + +----+ +----+ + |MAG1|-----{MN2} |MAG2| + +----+ | +----+ + (MN-HoA) | | | <-- (MN-HoA) + (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA) + {MN1} {MN3} + + Figure 1: IPv4 Support for Proxy Mobile IPv6 + +1.1. Stated Assumptions + + The following are the system and configuration requirements from the + mobility entities in the Proxy Mobile IPv6 domain for supporting the + extensions defined in this document. + + o Both the mobility entities, the local mobility anchor and the + mobile access gateway are dual-stack (IPv4/IPv6) enabled. + Irrespective of the type of transport network (IPv4 or IPv6) + separating these two entities, the mobility signaling is always + based on Proxy Mobile IPv6 protocol [RFC5213]. + + o A deployment where a mobile access gateway uses an IPv4 private + address with NAT [RFC3022] translation devices in the path to a + local mobility anchor is not supported by this specification. + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 4] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The mobile node can be operating in IPv4-only, IPv6-only or in + dual mode. Based on the enabled configuration for a mobile node, + the mobile node should be able to obtain IPv4-only, IPv6-only, or + both IPv4 and IPv6 addresses for its interface and furthermore + achieve mobility support for those addresses. + + o For enabling IPv4 home address mobility support to a mobile node, + it is not required that the IPv6 home address mobility support + need be enabled. However, the respective protocol(s) support, + such as IPv4 or IPv6 packet forwarding, must be enabled on the + access link between the mobile node and the mobile access gateway. + + o The mobile node can obtain an IPv4 address for its attached + interface. Based on the type of link, it may be able to acquire + its IPv4 address configuration using standard IPv4 address + configuration mechanisms such as DHCP [RFC2131], IP Control + Protocol (IPCP) [RFC1332], Internet Key Exchange Protocol version + 2 (IKEv2) [RFC4306], or static address configuration. However, + the details on how IPCP or IKEv2 can be used for address delivery + are outside the scope of this document. + + o The mobile node's IPv4 home subnet is typically a shared address + space. It is not for the exclusive use of any one mobile node. + There can be multiple mobile nodes that are assigned IPv4 + addresses from the same subnet. + + o The mobile access gateway is the IPv4 default router for the + mobile node on its access link. It will be in the forwarding path + for the mobile node's data traffic. Additionally, as specified in + Section 6.9.3 of [RFC5213], all the mobile access gateways in the + Proxy Mobile IPv6 domain MUST use the same link-layer address on + any of the access links wherever the mobile node attaches. + +1.2. Relevance to Dual-Stack Mobile IPv6 + + IPv4 support for Mobile IPv6 is specified in the Dual-Stack Mobile + IPv6 specification [RFC5555]. This document leverages some of the + approaches, messaging options, and processing logic defined in that + document for extending IPv4 support to Proxy Mobile IPv6, except with + deviation in some aspects for obvious reasons of supporting a + network-based mobility model. The following are some of the related + considerations. + + o The Binding Update message flag 'F' and the NAT Detection Option + defined in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this + specification in Proxy Binding Update and Proxy Binding + Acknowledgement messages. Their sole purpose is to allow forcing + + + + +Wakikawa & Gundavelli Standards Track [Page 5] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + of UDP encapsulation between a mobile access gateway and a local + mobility anchor in situations similar to those discussed in + Sections 4.1 and 4.4.1 of [RFC5555]. + + o The necessary extensions to the conceptual data structures, + Binding Cache entry and Binding Update List entry, for storing the + state related to the IPv4 support defined in [RFC5555], will all + be needed and relevant for this document. + + o In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555], + IPsec security associations (SAs) are specific to a single mobile + node; they use the identifier visible to upper-layer protocols + (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to + be updated when the mobile node moves. + + In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec + SAs are specific to the mobile access gateway (and used for a + potentially large number of mobile nodes); they use the locators + used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selectors; + and they are not updated when the mobile node moves. + + This means the IPsec processing for Mobile IPv6 and Proxy Mobile + IPv6 (whether IPv6-only or dual-stack) is very different. + + o The tunneling considerations specified in [RFC5555] for supporting + IPv4 transport are relevant for this document as well. + +2. Conventions and 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 [RFC2119]. + +2.2. Terminology + + All the mobility related terms used in this document are to be + interpreted as defined in the Mobile IPv6 specification [RFC3775] and + Proxy Mobile IPv6 specification [RFC5213]. In addition, this + document introduces the following terms. + + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 6] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) + + The IPv4 address that is configured on the egress-interface of the + mobile access gateway. When using IPv4 transport, this address + will be the registered care-of address in the mobile node's + Binding Cache entry and will also be the transport-endpoint of the + tunnel between the local mobility anchor and a mobile access + gateway. + + IPv4 Local Mobility Anchor Address (IPv4-LMAA) + + The IPv4 address that is configured on the egress-interface of the + local mobility anchor. When using IPv4 transport, the mobile + access gateway sends the Proxy Binding Update messages to this + address and will be the transport-endpoint of the tunnel between + the local mobility anchor and the mobile access gateway. + + Mobile Node's IPv4 Home Address (IPv4-MN-HoA) + + The IPv4 home address assigned to the mobile node's attached + interface. This address is topologically anchored at the mobile + node's local mobility anchor. The mobile node configures this + address on its attached interface. If the mobile node connects to + the Proxy Mobile IPv6 domain via multiple interfaces each of the + interfaces are assigned a unique IPv4 address. All the IPv6 home + network prefixes and the IPv4 home address assigned to a given + interface of a mobile node will be managed under one mobility + session. + + Selective De-registration + + A procedure for partial de-registration of all the addresses that + belong to one address family, i.e., de-registration of either the + IPv4 home address or one or more of the assigned IPv6 home network + prefixes. + + Encapsulation Modes + + This document uses the following terms when referring to the + different encapsulation modes. + + IPv4-or-IPv6-over-IPv6 + + IPv4 or IPv6 packet carried as a payload of an IPv6 packet + + IPv4-or-IPv6-over-IPv4 + + IPv4 or IPv6 packet carried as a payload of an IPv4 packet + + + +Wakikawa & Gundavelli Standards Track [Page 7] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + IPv4-or-IPv6-over-IPv4-UDP + + IPv4 or IPv6 packet carried as a payload in an IPv4 packet with + a UDP header + + IPv4-or-IPv6-over-IPv4-UDP-TLV + + IPv4 or IPv6 packet carried as a payload in an IPv4 packet with + UDP and TLV headers + + IPv4-or-IPv6-over-IPv4-GRE + + IPv4 or IPv6 packet carried as a payload in an IPv4 packet with + a Generic Routing Encapsulation (GRE) header (but no UDP or TLV + header) + +3. IPv4 Home Address Mobility Support + + The IPv4 home address mobility support essentially enables a mobile + node in a Proxy Mobile IPv6 domain to obtain IPv4 home address + configuration for its attached interfaces and be able to retain that + address configuration even after performing a handoff anywhere within + that Proxy Mobile IPv6 domain. This section describes the protocol + operation and the required extensions to Proxy Mobile IPv6 protocol + for extending IPv4 home address mobility support. + + When an IPv4-enabled or a dual-stack-enabled mobile node attaches to + the Proxy Mobile IPv6 domain, the mobile access gateway on the access + link where the mobile node is attached will identify the mobile node + and will initiate the Proxy Mobile IPv6 signaling with the mobile + node's local mobility anchor. The mobile access gateway will follow + the signaling considerations specified in Section 3.2 for requesting + IPv4 home address mobility support. Upon the completion of the + signaling, the local mobility anchor and the mobile access gateway + will establish the required routing states for allowing the mobile + node to use its IPv4 home address from its current point of + attachment. + + The mobile node on the access link using any of the standard IPv4 + address configuration mechanisms supported on that access link, such + as IPCP [RFC1332], IKEv2 [RFC4306], or DHCP [RFC2131], will be able + to obtain an IPv4 home address (IPv4-MN-HoA) for its attached + interface. Although the address configuration mechanisms for + delivering the address configuration to the mobile node is + independent of the Proxy Mobile IPv6 protocol operation, there needs + to be some interaction between these two protocol flows. Section 3.4 + identifies these interactions for supporting DHCP-based address + configuration. + + + +Wakikawa & Gundavelli Standards Track [Page 8] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + The support for IPv4 home address mobility is not dependent on the + IPv6 home address mobility support. It is not required that the IPv6 + home address mobility support needs to be enabled for providing IPv4 + home address mobility support. A mobile node will be able to obtain + IPv4-only, IPv6-only, or dual IPv4/IPv6 address configuration for its + attached interface. The mobile node's policy profile will determine + if the mobile node is entitled to both the protocol versions or a + single protocol version. Based on the policy, only those protocols + will be enabled on the access link. Furthermore, if the mobile node, + after obtaining the address configuration on its interface, performs + a handoff, either by changing its point of attachment over the same + interface or to a different interface, the network will ensure the + mobile node will be able to use the same IPv4 address configuration + after the handoff. + + Additionally, if the mobile node connects to the Proxy Mobile IPv6 + domain, through multiple interfaces and simultaneously through + different access networks, each of the connected interfaces will + obtain a unique IPv4 home address. In such a scenario, there will be + multiple Binding Cache entries for the mobile node on the local + mobility anchor. All the addresses (IPv4/IPv6) assigned to a given + interface will be managed as part of one mobility session, as + specified in Section 5.4 of [RFC5213]. + +3.1. Local Mobility Anchor Considerations + +3.1.1. Extensions to Binding Cache Entry + + To support this feature, the conceptual Binding Cache entry data + structure maintained by the local mobility anchor needs to include + the following parameters. + + o The IPv4 home address assigned to the mobile node's interface and + registered by the mobile access gateway. The IPv4 home address + entry also includes the corresponding subnet mask. It is to be + noted that this parameter is defined in [RFC5555] and is presented + here for completeness. + + o The IPv4 default router address assigned to the mobile node. + + + + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 9] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +3.1.2. Signaling Considerations + +3.1.2.1. Processing Proxy Binding Updates + + The processing rules specified in Section 5.3 of [RFC5213] are + applied for processing the received Proxy Binding Update message. + However, if the received Proxy Binding Update message has an IPv4 + Home Address Request option, the following considerations MUST be + applied additionally. + + o If there is an IPv4 Home Address Request option (Section 3.3.1) + present in the received Proxy Binding Update message, but no Home + Network Prefix option [RFC5213] present in the received Proxy + Binding Update message, the local mobility anchor MUST NOT reject + the request as specified in Section 5.3.1 of [RFC5213]. At least + one instance of either of these two options, either the IPv4 Home + Address Request option or the Home Network Prefix option, MUST be + present. If there is not a single instance of either of these two + options present in the request, the local mobility anchor MUST + reject the request and send a Proxy Binding Acknowledgement + message with the Status field set to + MISSING_HOME_NETWORK_PREFIX_OPTION (missing the mobile node's home + network prefix option) [RFC5213]. + + o If there is at least one instance of the Home Network Prefix + option [RFC5213] present in the received Proxy Binding Update + message, but it is known from the mobile node's policy profile + that the mobile node is not authorized for IPv6 service, or IPv6 + routing in not enabled in the home network, the local mobility + anchor MUST reject the request and send a Proxy Binding + Acknowledgement message with the Status field set to + NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not + authorized for IPv6 mobility service; see Section 3.3.5). + + o If there is an IPv4 Home Address Request option present in the + received Proxy Binding Update message, but it is known from the + mobile node's policy profile that the mobile node is not + authorized for IPv4 service, or if IPv4 routing is not enabled in + the home network, the local mobility anchor MUST reject the + request and send a Proxy Binding Acknowledgement message with the + Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE + (mobile node not authorized for IPv4 mobility service; see + Section 3.3.5). + + o If there is more than one instance of the IPv4 Home Address + Request option present in the request, then the local mobility + anchor MUST reject the request and send a Proxy Binding + + + + +Wakikawa & Gundavelli Standards Track [Page 10] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + Acknowledgement message with the Status field set to + MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 + home address assignments not supported; see Section 3.3.5). + + o For associating the received Proxy Binding Update message to an + existing mobility session, the local mobility anchor MUST perform + the Binding Cache entry existence test by applying the following + considerations. + + * If there is at least one instance of the Home Network Prefix + option [RFC5213] with a NON_ZERO prefix value, or, if there is + an IPv4 Home Address Request option with the IPv4 address in + the option set to ALL_ZERO, considerations from Section 5.4.1 + of [RFC5213] MUST be applied. + + * If there is an IPv4 Home Address Request option present in the + request with the IPv4 address value in the option set to a + NON_ZERO value, considerations from Section 3.1.2.7 MUST be + applied. + + o If there is no existing Binding Cache entry that can be associated + with the request, the local mobility anchor MUST consider this + request as an initial binding registration request, and + considerations from Section 3.1.2.2 MUST be applied. + Additionally, if there are one or more Home Network Prefix options + [RFC5213] present in the request, considerations from Section + 5.3.2 of [RFC5213] MUST also be applied. + + o If there exists a Binding Cache entry that can be associated with + the request, the local mobility anchor MUST apply considerations + from Section 5.3.1 of [RFC5213], (point 13), to determine if the + request is a re-registration or a de-registration request. If the + request is a re-registration request, considerations from + Section 3.1.2.3 MUST be applied, and if it is a de-registration + request, considerations from Section 3.1.2.5 MUST be applied. + + o If there exists a Binding Cache entry that can be associated with + the request and if it is determined that the request is a re- + registration request for extending an IPv4 home address mobility + support to the existing IPv6-only mobility session, considerations + from Section 3.1.2.2 MUST be applied with respect to IPv4 support. + + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 11] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +3.1.2.2. Initial Binding Registration (New Mobility Session) + + o If there is an IPv4 Home Address Request option present in the + Proxy Binding Update message with the IPv4 address value in the + option set to ALL_ZERO, the local mobility anchor MUST allocate an + IPv4 home address to the mobile node and associate it with the new + mobility session created for that mobile node. + + o If there is an IPv4 Home Address Request option with the IPv4 + address in the option set to a NON_ZERO value, the local mobility + anchor, before accepting the request, MUST ensure that the address + is topologically anchored on the local mobility anchor and + furthermore that the mobile node is authorized to use that + address. If the mobile node is not authorized for that specific + address, the local mobility anchor MUST reject the request and + send a Proxy Binding Acknowledgement message with the Status field + set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not + authorized for the requesting IPv4 address; see Section 3.3.5). + It MUST also include the IPv4 Home Address Reply option + (Section 3.3.2). in the reply with the Status field value in the + option set to 129 (Administratively prohibited). + + o If the local mobility anchor is unable to allocate an IPv4 address + due to lack of resources, it MUST reject the request and send a + Proxy Binding Acknowledgement message with Status field set to 130 + (Insufficient resources). It MUST also include the IPv4 Home + Address Reply option in the reply with the Status field value in + the option set to 128 (Failure, reason unspecified). + + o Upon accepting the request, the local mobility anchor MUST create + a Binding Cache entry for this mobility session. However, if the + request also contains one or more Home Network Prefix options + [RFC5213], there should still be only one Binding Cache entry that + should be created for this mobility session. The created Binding + Cache entry MUST be used for managing both IPv4 and IPv6 home + address bindings. The fields in the Binding Cache entry MUST be + updated with the accepted values for that session. + + o The local mobility anchor MUST establish a bidirectional tunnel to + the mobile access gateway with the encapsulation mode set to the + negotiated mode for carrying the IPv4 payload traffic. When using + IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over-IPv6 + (IPv4 or IPv6 packet carried as a payload of an IPv6 packet). + When using IPv4 transport, the encapsulation mode is as specified + in Section 4. + + + + + + +Wakikawa & Gundavelli Standards Track [Page 12] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The local mobility anchor MUST create an IPv4 host route (or a + platform-specific equivalent function that sets up the forwarding) + for tunneling the packets received for the mobile node's home + address associated with this mobility session. + + o The local mobility anchor MUST send the Proxy Binding + Acknowledgement message with the Status field set to 0 (Proxy + Binding Update accepted). The message MUST be constructed as + specified in Section 3.1.2.6. + +3.1.2.3. Binding Lifetime Extension (No Handoff) + + All the considerations from Section 5.3.3 of [RFC5213] MUST be + applied. + +3.1.2.4. Binding Lifetime Extension (after Handoff) + + o If there is no Home Network Prefix option [RFC5213] present in the + request, but if the Binding Cache entry associated with this + request has IPv6 home network prefix(es), the local mobility + anchor MUST consider this as a request to extend lifetime only for + the IPv4 home address and not for the IPv6 home network + prefix(es). Hence, the local mobility anchor SHOULD release all + the IPv6 home network prefix(es) assigned to that mobile node and + for that specific attached interface. Similar considerations + apply for the case where there is no IPv4 Home Address Request + option present in the request, but if the Binding Cache entry + associated with that request has both IPv4 home address and IPv6 + home network prefix(es). + + o The local mobility anchor MUST remove the previously created IPv4 + host route (or the forwarding state) and the dynamically created + bidirectional tunnel for carrying the IPv4 payload traffic (if + there are no other mobile nodes for which the tunnel is being + used). This will remove the routing state towards the mobile + access gateway where the mobile node was anchored prior to the + handoff. + + o The local mobility anchor MUST create a bidirectional tunnel to + the mobile access gateway that sent the request (if there is no + existing bidirectional tunnel) and with the encapsulation mode set + to the negotiated mode for carrying the IPv4 payload traffic. An + IPv4 host route for tunneling the packets received for the mobile + node's IPv4 home address MUST also be added. + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 13] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The required forwarding state identified in Section 5.3.6 of + [RFC5213] is for IPv6 payload traffic. Those considerations apply + for IPv4 payload traffic as well. However, if IPv4 transport is + in use, considerations from Section 4 MUST be applied. + +3.1.2.5. Binding De-Registration + + All the considerations from Section 5.3.5 of [RFC5213] MUST be + applied. Additionally, to remove the IPv4 state as part of the + Binding Cache entry deletion, the IPv4 host route and the dynamically + created bidirectional tunnel for carrying the IPv4 payload traffic + (if there are no other mobile nodes for which the tunnel is being + used) MUST be removed. However, if the request is for a selective + de-registration (IPv4 home address only, or all the IPv6 home network + prefixes), the Binding Cache entry MUST NOT be deleted, only the + respective states related to those addresses MUST be deleted. + +3.1.2.6. Constructing the Proxy Binding Acknowledgement Message + + When sending the Proxy Binding Acknowledgement message to the mobile + access gateway, the local mobility anchor MUST construct the message + as specified in Section 5.3.6 of [RFC5213]. Additionally, the + following considerations MUST be applied. + + o Section 5.3.6 of [RFC5213] requires the local mobility anchor to + include at least one instance of the Home Network Prefix option + [RFC5213] in the Proxy Binding Acknowledgement message that it + sends to the mobile access gateway. However, if the received + Proxy Binding Update message has only the IPv4 Home Address + Request option and does not contain the Home Network Prefix + option(s), then the local mobility anchor MUST NOT include any + Home Network Prefix option(s) in the reply. However, there MUST + be at least one instance of either the Home Network Prefix option + [RFC5213] or the IPv4 Home Address Reply option present in the + Proxy Binding Acknowledgement message. + + o The IPv4 Home Address Reply option MUST be present in the Proxy + Binding Acknowledgement message. + + 1. If the Status field is set to a value greater than or equal to + 128, i.e., if the Proxy Binding Update is rejected, then there + MUST be an IPv4 Home Address Reply option corresponding to the + IPv4 Home Address Request option present in the request and + with the IPv4 address value and the prefix length fields in + the option set to the corresponding values in the request. + The Status field value in the option must be set to the + specific error code. + + + + +Wakikawa & Gundavelli Standards Track [Page 14] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + 2. For all other cases, there MUST be an IPv4 Home Address Reply + option to carry the IPv4 home address assigned for that + mobility session and with the value in the option set to the + allocated IPv4 address. The prefix length in the option MUST + be set to the prefix length of the mobile node's IPv4 home + network. The Status field value in the option must be set to + 0 (Success). + + o The IPv4 Default-Router Address option (Section 3.3.3) MUST be + present, if the Status field value in the Proxy Binding + Acknowledgement message is set to 0 (Proxy Binding Update + accepted) [RFC5213]. Otherwise, the option MUST NOT be present. + If the option is present, the default router address in the option + MUST be set to the mobile node's default router address. + +3.1.2.7. Binding Cache Entry Lookup Considerations + + The Binding Cache entry lookup considerations specified in Section + 5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as + the key parameter for identifying the Binding Cache entry. However, + when there is not a single Home Network Prefix option with a NON_ZERO + value present in the request, but there is an IPv4 Home Address + option with a NON_ZERO value present in the request, then the + following considerations MUST be applied. + + o The search rules specified in Section 5.4.1.1 of [RFC5213], which + primarily uses IPv6 home network prefix set as the search key, are + equally valid when using a single IPv4 home address as the key. + When applying those considerations, instead of the IPv6 home + network prefix(es), the IPv4 home address from the IPv4 Home + Address option present in the request MUST be used as the search + key. + + o The rules specified in Section 5.4.1.1 of [RFC5213] assume the + presence of one or more IPv6 home network prefixes in the received + request and also in the Binding Cache entry. But, when using the + IPv4 home address as the search key, these considerations MUST + always assume just one single IPv4 home address, both in the + request and also in the Binding Cache entry. + +3.1.3. Routing Considerations for the Local Mobility Anchor + + Intercepting Packets Sent to the Mobile Node's IPv4 Home Address: + + o When the local mobility anchor is serving a mobile node, it MUST + advertise a connected route into the Routing Infrastructure for + the mobile node's IPv4 home address or for its home subnet, in + order to receive packets that are sent to the mobile node's IPv4 + + + +Wakikawa & Gundavelli Standards Track [Page 15] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + home address. This essentially enables IPv4 routers in that + network to detect the local mobility anchor as the last-hop router + for that subnet. + + Forwarding Packets to the Mobile Node: + + o On receiving a packet from a corresponding node with the + destination address matching the mobile node's IPv4 home address, + the local mobility anchor MUST forward the packet through the + bidirectional tunnel setup for that mobile node. + + o The format of the tunneled packet when payload protection is not + enabled: + + IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ + IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ + Upper-layer protocols /* Packet Content*/ + + Figure 2: Tunneled Packets from the Local Mobility Anchor (LMA) to + the Mobile Access Gateway (MAG) + + Forwarding Packets Sent by the Mobile Node: + + o All the reverse tunneled packets that the local mobility anchor + receives from the mobile access gateway, after removing the tunnel + header, MUST be routed to the destination specified in the inner + IPv4 packet header. These routed packets will have the Source + Address field set to the mobile node's IPv4 home address. + +3.1.4. ECN and Payload Fragmentation Considerations + + The Explicit Congestion Notification (ECN) considerations specified + in Section 5.6.3 of [RFC5213] apply for the IPv4 payload packets as + well. The mobility agents at the tunnel entry and exit points MUST + handle ECN information as specified in that document. + + The mobility agents at the tunnel entry and exit points MUST apply + the IP packet fragmentation considerations as specified in Section 7 + of [RFC2473]; additionally, they MUST apply the considerations + related to tunnel error processing and reporting as specified in + Section 8 of [RFC2473]. + + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 16] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +3.2. Mobile Access Gateway Considerations + +3.2.1. Extensions to Binding Update List Entry + + To support the IPv4 home address mobility feature, the conceptual + Binding Update List entry data structure needs to be extended with + the following additional fields. + + o The IPv4 home address assigned to the mobile node's attached + interface. This IPv4 home address may have been statically + configured in the mobile node's policy profile, or, may have been + dynamically allocated by the local mobility anchor. The IPv4 home + address entry also includes the corresponding subnet mask. + + o The IPv4 default router address of the mobile node. This is + acquired from the mobile node's local mobility anchor through the + received Proxy Binding Acknowledgement message. + +3.2.2. Extensions to Mobile Node's Policy Profile + + To support the IPv4 home address mobility support feature, the mobile + node's policy profile, specified in Section 6.2 of [RFC5213], MUST be + extended with the following additional fields. + + Extensions to the mandatory section of the policy profile: + + o This field identifies all the IP versions for which the home + address mobility support needs to be extended to the mobile node. + The supported modes are IPv4-only, IPv6-only, and dual IPv4/IPv6. + + + Extensions to the optional section of the policy profile: + + o The IPv4 home address assigned to the mobile node's attached + interface. The specific details on how the network maintains the + association between the address and the attached interface is + outside the scope of this document. This address field also + includes the corresponding subnet mask. + +3.2.3. Signaling Considerations + +3.2.3.1. Mobile Node Attachment and Initial Binding Registration + + After detecting a new mobile node on its access link, the mobile + access gateway on the access link MUST determine if IPv4 home address + mobility support needs to be enabled for that mobile node. The + mobile node's policy profile identifies the supported modes (IPv4- + only, IPv6-only, or dual IPv4/IPv6) for that mobile node for which + + + +Wakikawa & Gundavelli Standards Track [Page 17] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + the mobile service needs to be enabled. Based on those policy + considerations and from other triggers such as from the network, if + it is determined that IPv4 home address mobility support needs to be + enabled for the mobile node, considerations from Section 6.9.1.1 of + [RFC5213] MUST be applied with the following exceptions. + + o The IPv4 Home Address Request option MUST be present in the Proxy + Binding Update message. + + * If the mobile access gateway learns the mobile node's IPv4 home + address either from its policy profile or from other means, the + mobile access gateway MAY ask the local mobility anchor to + allocate that specific address by including exactly one + instance of the IPv4 Home Address Request option with the IPv4 + home address and the prefix length fields in the option set to + that specific IPv4 address and the prefix length of the + corresponding home network. + + * The mobile access gateway MAY also ask the local mobility + anchor for dynamic IPv4 home address allocation. It can + include exactly one instance of the IPv4 Home Address option + with the IPv4 home address and the prefix length fields in the + option set to the ALL_ZERO value. Furthermore, the (P) flag in + the option MUST be set to 0. This serves as a request to the + local mobility anchor for the IPv4 home address allocation. + + o The Proxy Binding Update message MUST be constructed as specified + in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix + option(s) [RFC5213] MUST be present in the Proxy Binding Update + only if IPv6 home address mobility support also needs to be + enabled for the mobile node. Otherwise, the Home Network Prefix + option(s) MUST NOT be present. + + o When using IPv4 transport to carry the signaling messages, the + related considerations from Section 4 MUST be applied + additionally. + +3.2.3.2. Receiving Proxy Binding Acknowledgement + + All the considerations from Section 6.9.1.2 of [RFC5213] MUST be + applied with the following exceptions. + + o If the received Proxy Binding Acknowledgement message has the + Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE + (The mobile node is not authorized for IPv4 mobility service), the + mobile access gateway SHOULD NOT send a Proxy Binding Update + message including a IPv4 Home Address Request option until an + administrative action is taken. + + + +Wakikawa & Gundavelli Standards Track [Page 18] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o If the received Proxy Binding Acknowledgement message has the + Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS + (The mobile node is not authorized for the requesting IPv4 home + address), the mobile access gateway SHOULD NOT request the same + IPv4 address again, but MAY request the local mobility anchor to + perform the address assignment by including exactly one instance + of the IPv4 Home Address Request option with the IPv4 home address + and the prefix length fields in the option set to the ALL_ZERO + value. + + o If the received Proxy Binding Acknowledgement message has the + Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE + (The mobile node is not authorized for IPv6 mobility service), the + mobile access gateway SHOULD NOT send a Proxy Binding Update + message including any Home Network Prefix option(s) until an + administrative action is taken. + + o If there is no IPv4 Home Address Reply option present in the + received Proxy Binding Acknowledgement message, the mobile access + gateway MUST NOT enable IPv4 support for the mobile node and the + rest of the considerations from this section can be skipped. + + o If the received Proxy Binding Acknowledgement message has the + Status field value in the IPv4 Home Address Reply option set to a + value that indicates that the request was rejected by the local + mobility anchor, the mobile access gateway MUST NOT enable IPv4 + mobility support. + + o If the received Proxy Binding Acknowledgement message has the + Status field value set to 0 (Proxy Binding Update accepted), the + mobile access gateway MUST update a Binding Update List entry for + that mobile node. The entry MUST be updated with the assigned + IPv4 home address and other accepted registration values. + + o If the received Proxy Binding Acknowledgement message has the + Status field value set to 0 (Proxy Binding Update accepted) and + has the IPv4 Home Address Reply option set to a value that + indicates that the request was accepted by the local mobility + anchor, the mobile access gateway MUST establish a bidirectional + tunnel to the local mobility anchor (if there is no existing + bidirectional tunnel to that local mobility anchor) and with the + encapsulation mode set to IPv4-or-IPv6-over-IPv6 (an IPv4 or IPv6 + packet carried as a payload of an IPv6 packet). Considerations + from Section 5.6.1 of [RFC5213] MUST be applied for managing the + dynamically created bidirectional tunnel. However, when using + IPv4 transport, the encapsulation mode MUST be set to the + negotiated encapsulation mode, as specified in Section 4 of this + document. + + + +Wakikawa & Gundavelli Standards Track [Page 19] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The mobile access gateway MUST set up the route for forwarding the + IPv4 packets received from the mobile node (using its IPv4 home + address) through the bidirectional tunnel set up for that mobile + node. + + o The default router address MUST be obtained from the IPv4 Default- + Router Address option present in the received Proxy Binding + Acknowledgement message. The mobile access gateway SHOULD + configure this address on its interface and respond to any Address + Resolution Protocol (ARP) requests sent by the mobile node to + resolve the hardware address of the default router. However, + since the link between the mobile access gateway and the mobile + node is a point-to-point link, implementations will be able + receive any packets sent to the default router address without + having to explicitly configure the default router address on its + interface. The mobile access gateway MAY also use the default + router address as the source address for any datagrams sent to the + mobile node and originated by the mobile access gateway itself. + It MUST also use this address in the DHCP Router option [RFC2132] + in the DHCP messages. + + o If there is an IPv4 DHCP Support Mode option (Section 3.3.4) + present in the received Proxy Binding Acknowledgement message and + if the (S) flag in the option is set to a value of (1), then the + mobile access gateway MUST function as a DHCP server for the + mobile node. If either the (S) flag in the option is set to a + value of (0), or if the option is not present in the request, then + the mobile access gateway MUST function as a DHCP Relay for the + mobile node. + +3.2.3.3. Binding Re-Registration and De-Registrations + + When sending a Proxy Binding Update either to extend the lifetime of + a mobility session or to de-register the mobility session, the + respective considerations from [RFC5213] MUST be applied. + Furthermore, the following additional considerations MUST also be + applied. + + o If there is an IPv4 home address assigned to the mobility session, + then there MUST be exactly one instance of the IPv4 Home Address + Request option present in the Proxy Binding Update message. The + IPv4 home address and the prefix length fields in the option MUST + be set to that specific address and its corresponding subnet-mask + length. + + o If there was no IPv4 home address requested in the initial Proxy + Binding Update message, but it is determined that the IPv4 home + address MUST be requested subsequently, then there MUST be exactly + + + +Wakikawa & Gundavelli Standards Track [Page 20] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + one instance of the IPv4 Home Address Request option present in + the Proxy Binding Update message. The IPv4 home address in the + option MUST be set to either ALL_ZERO or to a specific address + that is being requested. + + o For performing selective de-registration of IPv4 home address but + still retaining the mobility session with all the IPv6 home + network prefixes, the Proxy Binding Update message with the + lifetime value of (0) MUST NOT include any IPv6 Home Network + Prefix options [RFC5213]. It MUST include exactly one instance of + the IPv4 Home Address Request option with the IPv4 home address + and the prefix length fields in the option set to the IPv4 home + address that is being de-registered. Similarly, for selective de- + registration of all the IPv6 home network prefixes, the Proxy + Binding Update message MUST NOT include the IPv4 Home address + option, it MUST include a Home Network Prefix option for each of + the assigned home network prefixes assigned for that mobility + session and with the prefix value in the option set to that + respective prefix value. + + o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if + the same option(s) was not present in the initial Proxy Binding + Update message. Otherwise, considerations from [RFC5213] with + respect to this option MUST be applied. + + o If at any point the mobile access gateway fails to extend the + binding lifetime with the local mobility anchor for the mobile + node's IPv4 address, it MUST remove any forwarding state set up + for the mobile node's IPv4 home address. + +3.2.4. Routing Considerations for the Mobile Access Gateway + + o On receiving a packet from the bidirectional tunnel established + with the mobile node's local mobility anchor, the mobile access + gateway MUST remove the outer header before forwarding the packet + to the mobile node. + + o On receiving a packet from a mobile node connected to its access + link, the packet MUST be forwarded to the local mobility anchor + through the bidirectional tunnel established with the local + mobility anchor. However, when the EnableMAGLocalRouting flag is + set, considerations from Section 6.10.3 of [RFC5213] MUST be + applied with respect to local routing. + + o When forwarding the packet through the bidirectional tunnel, the + encapsulation considerations as specified in Section 3.1.3 MUST be + applied (except that the source and destination addresses fields + in the outer encapsulation header are reversed). However, before + + + +Wakikawa & Gundavelli Standards Track [Page 21] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + forwarding the packet, the mobile access gateway MUST ensure the + source address in the received packet is the address allocated for + that mobile node and that there is an active binding on the local + mobility anchor for that mobile node. + + o The mobile access gateway SHOULD use the Proxy ARP [RFC0925] to + reply to ARP Requests that it receives from the mobile node + seeking address resolutions for the destinations on the mobile + node's home subnet. When receiving an ARP Request, the mobile + access gateway SHOULD examine the target IP address of the + Request, and if this IP address matches the mobile node's IPv4 + home subnet, it SHOULD transmit a Proxy ARP Reply. However, on + certain types of links, the mobile node does not use ARP for + address resolutions, instead it forwards all the packets to the + mobile access gateway. On such types of links, the mobile access + gateway is not required to support the Proxy ARP function. At the + same time, implementations not supporting the Proxy ARP function + on links where the mobile node uses ARP for seeking address + resolutions for the destinations on the mobile node's home subnet + will result in communication failure. + +3.3. Mobility Options and Status Codes + + To support the IPv4 home address mobility feature, this specification + defines the following new options and status codes. + +3.3.1. IPv4 Home Address Request Option + + A new option, the IPv4 Home Address Request option, is defined for + use with the Proxy Binding Update message sent by the mobile access + gateway to the local mobility anchor. This option is used to request + IPv4 home address assignment for the mobile node. + + The IPv4 Home Address Request option has an alignment requirement of + 4n. Its format is as follows: + + 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 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 home address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: IPv4 Home Address Request Option + + + + + + +Wakikawa & Gundavelli Standards Track [Page 22] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + Type + + 36 + + Length + + An 8-bit unsigned integer indicating the length of the option + in octets, excluding the Type and Length fields. This field + MUST be set to (6). + + Prefix-len + + This 6-bit unsigned integer indicating the prefix length of the + mobile node's IPv4 home network corresponding to the IPv4 home + address contained in the option. + + Reserved + + This 10-bit field is unused for now. The value MUST be + initialized to (0) by the sender and MUST be ignored by the + receiver. + + IPv4 home address + + This 4-byte field containing the IPv4 home address that is + being requested. The value of 0.0.0.0 is used to request that + the local mobility anchor perform the address allocation. + +3.3.2. IPv4 Home Address Reply Option + + A new option, the IPv4 Home Address Reply option, is defined for use + in the Proxy Binding Acknowledgement message sent by the local + mobility anchor to the mobile access gateway. This option can be + used to send the assigned mobile node's IPv4 home address. + + The IPv4 Home Address Reply option has an alignment requirement of + 4n. Its format is as follows: + + 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 |Pref-len |Res| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 home address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: IPv4 Home Address Reply Option + + + + +Wakikawa & Gundavelli Standards Track [Page 23] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + Type + + 37 + + Length + + An 8-bit unsigned integer indicating the length of the option + in octets, excluding the Type and Length fields. This field + MUST be set to (6). + + Status + + Indicates success or failure for the IPv4 home address + assignment. Values from 0 to 127 indicate success. Higher + values (128 to 255) indicate failure. The following Status + values are currently allocated by this document: + + 0 Success + + 128 Failure, reason unspecified + + 129 Administratively prohibited + + 130 Incorrect IPv4 home address + + 131 Invalid IPv4 address + + 132 Dynamic IPv4 home address assignment not available + + Prefix-len + + This 6-bit unsigned integer is used to carry the prefix length + of the mobile node's IPv4 home network corresponding to the + IPv4 home address contained in the option. + + Reserved (Res) + + This 2-bit field is unused for now. The value MUST be + initialized to (0) by the sender and MUST be ignored by the + receiver. + + IPv4 home address + + This 4-byte field is used to carry the IPv4 home address + assigned to the mobile node. + + + + + + +Wakikawa & Gundavelli Standards Track [Page 24] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +3.3.3. IPv4 Default-Router Address Option + + A new option, the IPv4 Default-Router Address option, is defined for + use in the Proxy Binding Acknowledgement message sent by the local + mobility anchor to the mobile access gateway. This option can be + used to send the mobile node's IPv4 default router address. + + The IPv4 Default-Router Address option has an alignment requirement + of 4n. Its format is as follows: + + 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 | Reserved (R) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Default-Router Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: IPv4 Default-Router Address Option + + Type + + 38 + + Length + + An 8-bit unsigned integer indicating the length of the option + in octets, excluding the Type and Length fields. This field + MUST be set to (6). + + Reserved (R) + + This 16-bit field is unused for now. The value MUST be + initialized to (0) by the sender and MUST be ignored by the + receiver. + + IPv4 Default-Router Address + + A 4-byte field containing the mobile node's default router + address. + +3.3.4. IPv4 DHCP Support Mode Option + + A new option, the IPv4 DHCP Support Mode option, is defined for use + in the Proxy Binding Acknowledgement message sent by the local + mobility anchor to the mobile access gateway. This option can be + + + + + +Wakikawa & Gundavelli Standards Track [Page 25] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + used to notify the mobile access gateway as to whether it should + function as a DHCP Server or a DHCP Relay for the attached mobile + node. + + The IPv4 DHCP Support Mode option has no alignment requirement. Its + format is as follows: + + 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 | Reserved (R) |S| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: IPv4 DHCP Support Mode Option + + Type + + 39 + + Length + + An 8-bit unsigned integer indicating the length of the option + in octets, excluding the Type and Length fields. This field + MUST be set to 2. + + Reserved (R) + + This 15-bit field is unused for now. The value MUST be + initialized to (0) by the sender and MUST be ignored by the + receiver. + + DHCP Support Mode (S) + + A 1-bit field that specifies the DHCP support mode. This flag + indicates whether the mobile access gateway should function as + a DHCP Server or a DHCP Relay for the attached mobile node. + The flag value of (0) indicates the mobile access gateway + should act as a DHCP Relay, and the flag value of (1) indicates + it should act as a DHCP Server. + +3.3.5. Status Codes + + This document defines the following new Status values for use in the + Proxy Binding Acknowledgement message. These values are to be + allocated from the same numbering space, as defined in Section 6.1.8 + of [RFC3775]. + + + + + +Wakikawa & Gundavelli Standards Track [Page 26] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170 + + Mobile node not authorized for IPv4 mobility service. + + NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171 + + Mobile node not authorized for the requesting IPv4 home address. + + NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172 + + Mobile node not authorized for IPv6 mobility service. + + MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173 + + Multiple IPv4 home address assignments not supported. + +3.4. Supporting DHCP-Based Address Configuration + + This section explains how DHCP-based address configuration support + can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It + explains the protocol operation, supported DHCP server deployment + configurations, and the protocol interactions between DHCP agents and + mobility entities in each of the supported configurations. + + This specification supports the following two DHCP deployment + configurations. + + o DHCP relay agent co-located with the mobile access gateway. + + o DHCP server co-located in the mobile access gateway. + + The following are the configuration requirements: + + o The DHCP server or the DHCP relay agent configured on the mobile + access gateway is required to have an IPv4 address for exchanging + the DHCP messages with the mobile node. This address is the + mobile node's default router address provided by the local + mobility anchor. Optionally, all the DHCP servers co-located with + the mobile access gateways in the Proxy Mobile IPv6 domain can be + configured with a fixed IPv4 address. This fixed address can be + an IPv4 private address [RFC1918] that can be used for the DHCP + protocol communication on any of the access links. This address + will be used as the server identifier in the DHCP messages. + + o A DHCP server identifies a DHCP interface from the contents of the + DHCP "Client-identifier" option [RFC2132], if present, or from the + client hardware address (chaddr), as specified in [RFC2131]. Note + that the name "Client-identifier" is a misnomer as it actually + + + +Wakikawa & Gundavelli Standards Track [Page 27] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + identifies an interface and not the client. The DHCP server uses + this identity to identify the interface for which the address is + assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach + to the network through multiple interfaces and can obtain address + configuration for each of its interfaces. Additionally, it may + perform handoffs between its interfaces. The following are the + related considerations with respect to the identification + presented to the DHCP server. + + * If the mobile node attaches to the Proxy Mobile IPv6 domain + through multiple physical interfaces, the DHCP server will + uniquely identify each of those interfaces and will perform + address assignment. The DHCP server will identify the + interface as specified in RFC 2131. The mobile node SHOULD + generate and use the "Client-identifier" for each physical + interface according to [RFC4361]. Any time the mobile node + performs a handoff of a physical interface to a different + mobile access gateway, using the same interface, the DHCP + server will always be able to identify the binding using the + presented identifier. The presented identifier (either the + "Client-identifier" or the hardware address) will remain as the + primary key for each binding, just as how they are unique in a + Binding Cache entry. + + * If the mobile node is capable of performing a handoff between + interfaces, as per [RFC5213], a "Client-identifier" value MUST + be used for the attachment point that is not tied to any of the + physical interfaces. The identifier MUST be generated + according to [RFC4361], which guarantees that the identifier is + stable and unique across all "Client-identifier" values in use + in the Proxy Mobile IPv6 domain. + + o All the DHCP servers co-located with the mobile access gateways in + a Proxy Mobile IPv6 domain can be configured with the same set of + DHCP option values (e.g., DNS Server, SIP Server, etc.) to ensure + the mobile node receives the same configuration values on any of + the access links in that Proxy Mobile IPv6 domain. + +3.4.1. DHCP Server Co-Located with the Mobile Access Gateway + + This section explains the operational sequence of home address + assignment operation when the DHCP server is co-located with the + mobile access gateway. + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 28] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + MN MAG(DHCP-S) LMA + |------>| | 1. DHCPDISCOVER + | |------->| 2. Proxy Binding Update + | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) + | |========| 4. Tunnel/Route Setup + |<------| | 5. DHCPOFFER (IPv4 HoA) + |------>| | 6. DHCPREQUEST (IPv4 HoA) + |<------| | 7. DHCPACK + | | | + + Figure 7: Overview of DHCP Server Located at Mobile Access Gateway + + o It is possible that the mobile access gateway may have already + completed the Proxy Mobile IPv6 signaling with the local mobility + anchor to request both IPv6 home network prefix(es) and IPv4 home + address assignment prior to Step 1. In such an event, the Proxy + Mobile IPv6 signaling steps (Steps 2 to 4) above are not relevant. + + o It is possible the mobile access gateway may have initially + completed the Proxy Mobile IPv6 signaling prior to Step 1, but + only for requesting IPv6 home network prefix(es), and it may later + request IPv4 home address assignment after detecting the DHCP + triggers from the mobile node as shown above. + + o The mobile access gateway may choose to ignore the DHCPDISCOVER + messages until the Proxy Mobile IPv6 signaling is successfully + completed, or it may choose to send a delayed response for + reducing the additional delay waiting for a new DHCPDISCOVER + message from the mobile node. + + Initial IPv4 Home Address Assignment: + + o To acquire the mobile node's IPv4 home address from the local + mobility anchor, the mobile access gateway will initiate Proxy + Mobile IPv6 signaling with the local mobility anchor. + + o After the successful completion of the Proxy Mobile IPv6 signaling + and upon acquiring the mobile node's IPv4 home address from the + local mobility anchor, the DHCP server on the mobile access + gateway will send a DHCPOFFER message [RFC2131] to the mobile + node. The offered address will be the mobile node's IPv4 home + address, assigned by the local mobility anchor. The DHCPOFFER + message will also have the Subnet Mask option [RFC2132] and Router + option [RFC2132], with the values in those options set to the + mobile node's IPv4 home subnet mask and default router address, + respectively. Additionally, the Server Identifier option will be + included and with the value in the option set to the default + router address. + + + +Wakikawa & Gundavelli Standards Track [Page 29] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o If the mobile node sends the DHCPREQUEST message, the DHCP server + will send DHCPACK message, as per [RFC2131]. + + IPv4 Home Address Renewal with the DHCP Server (No Handoff): + + o Any time the mobile node goes into the DHCP RENEWING state + [RFC2131], it simply unicasts the DHCPREQUEST message including + the assigned IPv4 home address in the 'Requested IP Address' + option. The DHCPREQUEST is sent to the address specified in the + Server Identifier option of the previously received DHCPOFFER and + DHCPACK messages. + + o The DHCP server will send a DHCPACK to the mobile node to + acknowledge the assignment of the committed IPv4 address. + + IPv4 Home Address Renewal with the DHCP Server (after Handoff): + + When the mobile node goes into the DHCP RENEWING state [RFC2131], it + directly unicasts the DHCPREQUEST message to the DHCP server that + currently provided the DHCP lease. However, if the mobile node + changed its point of attachment and is attached to a new mobile + access gateway, it is required that the mobile node update the DHCP + server address and use the address of the DHCP server that is co- + located with the new mobile access gateway. The following approach + can be adopted to ensure the mobile node uses the DHCP server on the + attached link. + + MN oMAG(DHCP-S) nMAG(DHCP-S) + | : | + RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) + BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK + | : | + * The use of a fixed DHCP server address on all DHCP servers + + Figure 8: Address Renewal with the DHCP Server + + o The use of a stable address, either the IPv4 default router + address of the mobile node or a fixed IPv4 address common in that + Proxy Mobile IPv6 domain, as the DHCP Server Identifier will + ensure the DHCPREQUEST message sent by the mobile node to renew + the address will be received by the new mobile access gateway on + the attached link. + + o The mobile access gateway after completing the Proxy Mobile IPv6 + signaling and upon acquiring the IPv4 home address of the mobile + node will return the address in the DHCPACK message. However, if + the mobile access gateway is unable to complete the Proxy Mobile + + + + +Wakikawa & Gundavelli Standards Track [Page 30] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + IPv6 signaling or is unable to acquire the same IPv4 address as + requested by the mobile node, it will send a DHCPNACK message + [RFC2131] to the mobile node, as shown in Figure 8. + +3.4.2. DHCP Relay Agent Co-Located with the Mobile Access Gateway + + A DHCP relay agent is co-located with each mobile access gateway. A + DHCP server is located somewhere in the Proxy Mobile IPv6 domain + (e.g., is co-located with the local mobility anchor). Figure 9 shows + the sequence of IPv4 home address assignment using DHCP Relay. + + MN MAG(DHCP-R) LMA DHCP-S + | |------->| | 1. Proxy Binding Update * + | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) + | |========| | 3. Tunnel/Route Setup* + |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R + |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R + |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R + |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R + | | | + + Figure 9: Overview of the DHCP Relay Located at Mobile Access Gateway + + o The Proxy Mobile IPv6 signaling (starting at Step 1) and the DHCP + address configuration (starting at Step 4) may start in any order. + However, the DHCPOFFER (Step 5) and the immediate steps following + it will occur in the specified order and only after the Tunnel/ + Route Setup (Step 3). + + o It is possible the mobile access gateway may have initially + completed the Proxy Mobile IPv6 signaling with the local mobility + anchor only to request IPv6 home network prefix(es) and may later + request IPv4 home address assignment after detecting the DHCP + triggers from the mobile node (after Step 4). + + o The mobile access gateway may choose to ignore the DHCPDISCOVER + messages until the Proxy Mobile IPv6 signaling is successfully + completed, or it may choose to send a delayed response for + reducing the additional delay waiting for a new DHCPDISCOVER + message from the mobile node. + + Initial IPv4 Home Address Assignment: + + o To acquire the mobile node's IPv4 home address from the local + mobility anchor, the mobile access gateway will initiate Proxy + Mobile IPv6 signaling with the local mobility anchor. + + + + + +Wakikawa & Gundavelli Standards Track [Page 31] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o After the successful completion of the Proxy Mobile IPv6 signaling + and upon acquiring the mobile node's IPv4 home address from the + local mobility anchor, the mobile access gateway will enable + forwarding for all the DHCP messages between the mobile node and + the DHCP server. + + o The DHCP relay agent on the mobile access gateway will add the + DHCP Relay Agent Information option [RFC3046] to the DHCPDISCOVER + message. The assigned IPv4 home address will be included in the + Agent Remote ID Sub-option of the DHCP Relay Agent Information + option. This sub-option is used as a hint for requesting the DHCP + server to allocate that specific IPv4 address. + + o On receiving a DHCPOFFER message from the DHCP server, the mobile + access gateway will ensure the assigned address is currently + assigned by the local mobility anchor to that mobile node. If + this address is different from what is assigned to the mobile + node, then the mobile access gateway will drop the DHCPOFFER + message and an administrative error message will be logged. + + o When the DHCP messages are sent over administrative boundaries, + the operators need to ensure these messages are secured. All the + DHCP messages relayed by the mobile access gateway can be tunneled + to the local mobility anchor if needed. Alternatively, if the + network in the Proxy Mobile IPv6 domain is secure enough, the + mobile access gateway can just relay the DHCP messages to the + server. To achieve this, all the mobile access gateways need to + have a route towards the DHCP server. + + IPv4 Home Address Renewal to the same DHCP Server: (No Handoff) + + o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it + directly unicasts DHCPREQUEST messages to the DHCP server. The + DHCP relay agent may not detect any changes in the DHCP state. + For example, if the mobile node releases the IPv4 address, the + relay agent would not be aware of it. The following describes + additional mechanisms for the mobile access gateway to detect any + changes in the DHCP state. + + * The DHCP relay agent can intercept all IPv4 DHCP packets + destined to the set of addresses used within the Proxy Mobile + IPv6 domain as DHCP addresses. Since the link between a mobile + node and a mobile access gateway is the point-to-point link, + the mobile access gateway will be in path for all the messages. + + * The DHCP relay agent can use the DHCP Server Identifier + Override Sub-option [RFC5107] to be in path for all the DHCP + message flows. The DHCP client uses the DHCP server address + + + +Wakikawa & Gundavelli Standards Track [Page 32] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + that is overridden by the DHCP relay agent address as a + destination address of DHCPREQUEST. The DHCP Server Identifier + Override Sub-option is recommended only when the fixed DHCP + relay address is configured on all the mobile access gateways. + Otherwise, the DHCP relay agent address is changed when the + mobile node changes the attached mobile access gateway. + + o However, if the DHCP server is co-located with the local mobility + anchor, then the DHCP relay agent is not required to intercept the + unicast DHCP messages between the mobile node and the DHCP server. + This is because the local mobility anchor will ensure that the + DHCP state is consistent with the Proxy Mobile IPv6 binding that + exists for the IPv4 address. + + o Once the mobile access gateway intercepts the DHCP message from + the mobile node to the DHCP server, it can verify if the mobile + node is negotiating the same IPv4 address that the local mobility + anchor allocated for that mobile node. If the address in the + DHCPREQUEST message does not match with the IPv4 address allocated + for the mobile node, then the mobile access gateway SHOULD drop + the DHCP message and an administrative error message can be + logged. + + o Any time the mobile access gateway detects that the mobile node + has released its IPv4 address, it can send a Proxy Binding Update + to the local mobility anchor and de-register the IPv4 mobility + session. + +3.4.3. Common DHCP Considerations + + The following DHCP-related considerations are common to both the + supported configuration modes, specified in Sections 3.4.1 and 3.4.2. + + o When a mobile node sends a DHCPDISCOVER message [RFC2131], the + DHCP server or the relay agent co-located with the mobile access + gateway will trigger the mobile access gateway to complete the + Proxy Mobile IPv6 signaling. This is the required interaction + between these two protocols. The mobile access gateway, on + receiving this trigger, will check if there is already an assigned + IPv4 home address for the mobile node, from the local mobility + anchor. If there is no assigned IPv4 home address assigned for + that mobile node, the mobile access gateway will complete the + Proxy Mobile IPv6 signaling with the local mobility anchor by + sending a Proxy Binding Update message. + + o The mobile node needs to be identified by the MN-Identifier, as + specified in Section 6.6 of [RFC5213]. This identity should be + associated to the DHCP messages sent by the mobile node. + + + +Wakikawa & Gundavelli Standards Track [Page 33] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The mobile access gateway will drop all the DHCPDISCOVER messages + until it completes the Proxy Mobile IPv6 signaling. If the mobile + access gateway is unable to complete the Proxy Mobile IPv6 + signaling, or, if the local mobility anchor does not assign an + IPv4 address for the mobile node, the mobile access gateway MUST + NOT enable IPv4 home address mobility support for the mobile node + on that access link. + + o The trigger for initiating Proxy Mobile IPv6 signaling can also be + delivered to the mobile access gateway as part of a context + transfer from the previous mobile access gateway, or delivered + from the other network elements in the radio network, the details + of which are outside the scope of this document. + + o The DHCPOFFER message [RFC2131] sent to the mobile node MUST + include the Subnet Mask option [RFC2132] and the Router option + [RFC2132]. The values in the Subnet Mask option and Router option + MUST be set to the mobile node's IPv4 home subnet mask and its + default router address, respectively. + + o The DHCPOFFER message [RFC2131] sent to the mobile node MUST + include the Interface MTU option [RFC2132]. The DHCP servers in + the Proxy Mobile IPv6 domain MUST be configured to include the + Interface MTU option. The MTU value SHOULD reflect the tunnel MTU + for the bidirectional tunnel between the mobile access gateway and + the local mobility anchor. + + o The DHCP lease length allocated to the mobile node's IPv4 home + address may be different from the binding lifetime at the local + mobility anchor for that mobile node's session. It is not + possible to keep these lifetimes synchronized, and so its not + required that the configured lifetimes should be kept same in both + DHCP and Proxy Mobile IPv6. + + o When the mobile node performs a handoff from one mobile access + gateway to another, the mobile access gateway on the new link will + initiate the Proxy Mobile IPv6 signaling with the local mobility + anchor. On completing the Proxy Mobile IPv6 signaling, the mobile + access gateway has the proper IPv4 address state that the local + mobility anchor has allocated for the mobile node and that can be + used for supporting DHCP based address configuration on that link. + + o Any time the mobile node detects a link change event due to + handoff, or due to other reasons such as re-establishment of the + link-layer, the following are the mobile node's considerations + with respect to the DHCP protocol. + + + + + +Wakikawa & Gundavelli Standards Track [Page 34] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + * If the mobile node is DNAv4-capable (Detecting Network + Attachment version 4) [RFC4436] and if it performs DNAv4 + procedures after receiving a link change event, it would always + detect the same default router on any of the access links in + that Proxy Mobile IPv6 domain, as the mobile access gateway + configures a fixed link-layer address on all the access links, + as per the base Proxy Mobile IPv6 specification [RFC5213]. The + mobile node will not perform any DHCP operation specifically + due to this event. + + * If the mobile node is not DNAv4-capable [RFC4436], after + receiving the link change event it will enter INIT-REBOOT state + [RFC2131] and will send a DHCPREQUEST message as specified in + Section 3.7 of [RFC2131]. The mobile node will obtain the same + address configuration as before, as the link change does not + result in any change at the network layer. + + o The mobile node may release its IPv4 home address at any time by + sending the DHCPRELEASE message [RFC2131]. When the mobile access + gateway detects the DHCPRELEASE message sent by the mobile node, + it should consider this as a trigger for de-registering the mobile + node's IPv4 home address. It will apply the considerations + specified in Section 3.2.3.3 for performing the de-registration + procedure. However, this operation MUST NOT release any IPv6 home + network prefix(es) assigned to the mobile node. + +4. IPv4 Transport Support + + The Proxy Mobile IPv6 specification [RFC5213] requires the signaling + messages exchanged between the local mobility anchor and the mobile + access gateway to be over an IPv6 transport. However, in some cases, + the local mobility anchor and the mobile access gateway are separated + by an IPv4 network. + + The normal Proxy Mobile IPv6 specification [RFC5213] can be run over + an IPv4 transport without any modifications by using a transition + technology that allows IPv6 hosts to communicate over IPv4 networks. + For example, the mobile access gateway and the local mobility anchor + could have a simple configured IPv6-over-IPv4 tunnel. Instead of + configured tunnels, various mechanisms for automatic tunneling could + be used, too. To these tunnels, Proxy Mobile IPv6 would look just + like any other application traffic running over IPv6. + + However, treating Proxy Mobile IPv6 just like any other IPv6 traffic + would mean an extra layer of encapsulation for the mobile node's + tunneled data traffic, adding 40 octets of overhead for each packet. + + + + + +Wakikawa & Gundavelli Standards Track [Page 35] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + The extensions defined in this section allow the mobile access + gateway and the local mobility anchor to communicate over an IPv4 + network without this overhead. + + IPv4-Proxy-CoA IPv4-LMAA + | + - - - - - - + | + +--+ +---+ / \ +---+ +--+ + |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| + +--+ +---+ \ / +---+ +--+ + + - - - - - - + + + Figure 10: IPv4 Transport Network + + When the local mobility anchor and the mobile access gateway are + configured and reachable using only IPv4 addresses, the mobile access + gateway serving a mobile node can potentially send the signaling + messages over IPv4 transport and register its IPv4 address as the + care-of address in the mobile node's Binding Cache entry. An IPv4 + tunnel (with any of the supported encapsulation modes) can be used + for tunneling the mobile node's data traffic. The following are the + key aspects of this feature. + + o The local mobility anchor and the mobile access gateway are both + configured and reachable using an IPv4 address of the same scope. + + o The IPv4 addresses used can be private IPv4 addresses, but it is + assumed that there is no NAT between the local mobility anchor and + the mobile access gateway. However, it is possible to use UDP + encapsulation if other types of middleboxes are present. + + o The Mobility Header [RFC3775] is carried inside an IPv4 packet + with UDP header (IPv4-UDP-MH), using a UDP port number for Proxy + Mobile IPv6 signaling over IPv4. + + o The mobile node can be an IPv6, IPv4, or a dual IPv4/IPv6 node and + the IPv4 transport support specified in this section is agnostic + to the type of address mobility enabled for that mobile node. + + o The mobile node's data traffic will be tunneled between the local + mobility anchor and the mobile access gateway. There are several + encapsulation modes available: + + * IPv4 (IPv4 or IPv6 payload packet carried in an IPv4 packet). + If payload protection using IPsec is enabled for the tunneled + traffic, the Encapsulating Security Payload (ESP) header + follows the outer tunnel header. + + + + + +Wakikawa & Gundavelli Standards Track [Page 36] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + * IPv4-UDP (payload packet carried in an IPv4 packet with UDP + header, using a UDP port number for Proxy Mobile IPv6 data; + this is different port than is used for signaling). If payload + protection using IPsec is enabled, the ESP header follows the + outer IPv4 header, as explained in Section 4.3. + + * IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP + and TLV header) and IPv4-GRE (Payload packet carried in an IPv4 + packet with GRE header). Refer to [GREKEY]. If payload + protection using IPsec is enabled, the ESP header follows the + outer IPv4 header, as explained in Section 4.3. + +4.1. Local Mobility Anchor Considerations + +4.1.1. Extensions to Binding Cache Entry + + To support this feature, the conceptual Binding Cache entry data + structure maintained by the local mobility anchor [RFC5213] MUST be + extended with the following additional parameters. It is to be noted + that all of these parameters are specified in [RFC5555] and also + required here in the present usage context, and are presented here + only for completeness. + + o The IPv4 Proxy Care-of Address configured on the mobile access + gateway that sent the Proxy Binding Update message. The address + MUST be the same as the source address of the received IPv4 packet + that contains the Proxy Binding Update message. However, if the + received Proxy Binding Update message is not sent as an IPv4 + packet, i.e., when using IPv6 transport, this field in the Binding + Cache entry MUST be set to the ALL_ZERO value. + +4.1.2. Extensions to Mobile Node's Policy Profile + + To support the IPv4 Transport Support feature, the mobile node's + policy profile, specified in Section 6.2 of [RFC5213], MUST be + extended with the following additional fields. These are mandatory + fields of the policy profile required for supporting this feature. + + o The IPv4 address of the local mobility anchor (IPv4-LMAA). + +4.1.3. Signaling Considerations + + This section provides the rules for processing the Proxy Mobile IPv6 + signaling messages received over IPv4 transport. + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 37] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +4.1.3.1. Processing Proxy Binding Updates + + o If the Proxy Binding Update message is protected with IPsec ESP, + IPsec processing happens before the packet is passed to Proxy + Mobile IPv6. + + o All the considerations from Section 5.3.1 of [RFC5213] except Step + 1 (about IPsec) MUST be applied on the encapsulated Proxy Binding + Update message. Note that the Checksum field in Mobility Header + MUST be ignored. + + o Upon accepting the request, the local mobility anchor MUST set up + an IPv4 bidirectional tunnel to the mobile access gateway. The + tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. + The encapsulation mode MUST be determined by applying the + following considerations: + + * If the (F) flag in the received Proxy Binding Update message is + set to the value of (1), but if the configuration flag, + AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of + (0), then the local mobility anchor MUST reject the request + with the Status field value set to 129 (Administratively + prohibited). + + * If the (T) flag is set to (1), or GRE Key option is included, + see [GREKEY]. + + * If the (F) flag in the received Proxy Binding Update message is + set to the value of (1), then the encapsulation mode MUST be + set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set + to IPv4. + + o The local mobility anchor MUST send the Proxy Binding + Acknowledgement message with the Status field value set to (0) + (Proxy Binding Update accepted). The message MUST be constructed + as specified in Section 4.1.3.2. + +4.1.3.2. Constructing the Proxy Binding Acknowledgement Message + + The local mobility anchor when sending the Proxy Binding + Acknowledgement message to the mobile access gateway MUST construct + the message as specified in Section 5.3.6 of [RFC5213]. However, if + the Proxy Binding Update message was received over IPv4, the + following additional considerations MUST be applied. + + o The IPv6 Header is removed, and the Mobility Header containing the + Proxy Binding Acknowledgement is encapsulated in UDP (with source + port set to 5436 and destination port set to the source port of + + + +Wakikawa & Gundavelli Standards Track [Page 38] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + the received Proxy Binding Update message). The Mobility Header + Checksum field MUST be set to zero (and the UDP checksum MUST be + used instead). + + o The source address in the IPv4 header of the message MUST be set + to the destination IPv4 address of the received request. + + o If IPsec ESP is used to protect signaling, the packet is processed + using transport mode ESP as described in Section 4.3. + + o Figure 11 shows the format of the Proxy Binding Acknowledgement + message sent over IPv4 and protected using ESP. + + IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) + ESP header (in transport mode) + UDP header (sport=5436, dport=5436) + Mobility Header (PBA) + + Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over + IPv4 + +4.1.4. Routing Considerations + +4.1.4.1. Forwarding Considerations + + Forwarding Packets to the Mobile Node: + + o On receiving an IPv4 or an IPv6 packet from a correspondent node + with the destination address matching any of the mobile node's + IPv4 or IPv6 home addresses, the local mobility anchor MUST + forward the packet through the bidirectional tunnel set up for + that mobile node. + + o The format of the tunneled packet is shown below. The IPv4-UDP- + TLV and IPv4-GRE encapsulation modes are described in [GREKEY]. + + IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */ + [UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */ + /* IPv6 or IPv4 Payload Packet */ + IPv6 header (src=CN, dst=MN-HOA) + OR + IPv4 header (src=CN, dst=IPv4-MN-HoA) + + Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP + Encapsulation Mode) + + + + + + +Wakikawa & Gundavelli Standards Track [Page 39] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o Forwarding Packets Sent by the Mobile Node: + + * All the reverse tunneled packets (IPv4 and IPv6) that the local + mobility anchor receives from the mobile access gateway, after + removing the tunnel header (i.e., the outer IPv4 header along + with the UDP and TLV header, if negotiated) MUST be routed to + the destination specified in the inner packet header. These + routed packets will have the source address field set to the + mobile node's home address. + +4.1.4.2. ECN and Payload Fragmentation Considerations + + The ECN considerations specified in Section 5.6.3 of [RFC5213] apply + for the IPv4 transport tunnels as well. The mobility agents at the + tunnel entry and exit points MUST handle ECN information as specified + in that document. + + The mobility agents at the tunnel entry and exit points MUST apply + the IP packet fragmentation considerations as specified in [RFC4213]. + Additionally, they MUST also apply the considerations related to + tunnel error processing and reporting as specified in the same + specification. + +4.1.4.3. Bidirectional Tunnel Management + + The Tunnel Management considerations specified in Section 5.6.1 of + [RFC5213] apply for the IPv4 transport tunnels as well, with just one + difference that the encapsulation mode is different. + +4.2. Mobile Access Gateway Considerations + +4.2.1. Extensions to Binding Update List Entry + + To support the IPv4 Transport Support feature, the conceptual Binding + Update List entry data structure maintained by the mobile access + gateway [RFC5213] MUST be extended with the following additional + parameters. + + o The IPv4 address of the local mobility anchor. This address can + be obtained from the mobile node's policy profile. + +4.2.2. Signaling Considerations + + The mobile access gateway, when sending a Proxy Binding Update + message to the local mobility anchor, MUST construct the message as + specified in Section 6.9.1.5 of [RFC5213]. However, if the mobile + access gateway is in an IPv4-only access network, the following + additional considerations MUST be applied. + + + +Wakikawa & Gundavelli Standards Track [Page 40] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The Proxy Binding Update message MUST be sent over IPv4 as + described in Section 4.2.2.1. + + o Just as specified in [RFC5213], when sending a Proxy Binding + Update message for extending the lifetime of a currently existing + mobility session or to de-register the mobility session, the Proxy + Binding Update message MUST be constructed just as the initial + request. + + Receiving Proxy Binding Acknowledgement: + + o If the received Proxy Binding Acknowledgement message is protected + with IPsec ESP, IPsec processing happens before the packet is + passed to Proxy Mobile IPv6. Considerations from Section 4 of + [RFC5213] MUST be applied to authenticate and authorize the + message. + + o All the considerations from Section 6.9.1.2 of [RFC5213] MUST be + applied on the encapsulated Proxy Binding Acknowledgement message. + Note that the Checksum field in Mobility Header MUST be ignored. + + o If the Status field indicates Success, the mobile access gateway + MUST set up a bidirectional tunnel to the local mobility anchor. + + o Upon accepting the request, the mobile access gateway MUST set up + an IPv4 bidirectional tunnel to the local mobility anchor. The + tunnel endpoint addresses are the IPv4-Proxy-CoA and the IPv4- + LMAA. The encapsulation mode MUST be determined from the below + considerations: + + * If the (T) flag is set to (1), or the GRE Key option is + included, see [GREKEY]. + + * If there is a NAT Detection option [RFC5555] in the received + Proxy Binding Acknowledgement message, and the (F) flag is set + to value of (1), the encapsulation mode for the tunnel MUST be + set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set + to IPv4. + +4.2.2.1. Constructing the Proxy Binding Update Message + + o The IPv6 Header is removed, and the Mobility Header containing the + Proxy Binding Update message is encapsulated in UDP (with the + destination port set to 5436). The Mobility Header Checksum field + MUST be set to zero (and UDP checksum MUST be used instead). + + + + + + +Wakikawa & Gundavelli Standards Track [Page 41] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + o The source address in the IPv4 header MUST be set to IPv4-Proxy- + CoA of the mobile access gateway and the destination address MUST + be set to the local mobility anchor's IPv4-LMAA. + + o If the configuration variable ForceIPv4UDPEncapsulationSupport is + set to value of (1), then the (F) flag in the Proxy Binding Update + message MUST be set to value of (1). + + o If IPsec ESP is used to protect signaling, the packet is processed + using transport mode ESP as described in Section 4.3. + + o Figure 13 shows the format of the Proxy Binding Update message + sent over IPv4 and protected using ESP. + + IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) + ESP header (in transport mode) + UDP header (sport=5436, dport=5436) + Mobility Header (PBU) + + Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4 + +4.2.2.2. Forwarding Considerations + + Forwarding Packets Sent by the Mobile Node: + + o On receiving an IPv4 or an IPv6 packet from the mobile node to any + destination, the mobile access gateway MUST tunnel the packet to + the local mobility anchor. The format of the tunneled packet is + shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes + are described in [GREKEY]. However, considerations from Section + 6.10.3 of [RFC5213] MUST be applied with respect the local routing + and on the use of EnableMAGLocalRouting flag. + + IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */ + [UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */ + /* IPv6 or IPv4 Payload Packet */ + IPv6 header (src=MN-HOA, dst=CN) + OR + IPv4 header (src=IPv4-MN-HOA, dst=CN) + + Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP + Encapsulation Mode) + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 42] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + Forwarding Packets Received from the Bidirectional Tunnel: + + o On receiving a packet from the bidirectional tunnel established + with the mobile node's local mobility anchor, the mobile access + gateway MUST remove the outer header before forwarding the packet + to the mobile node. + +4.3. IPsec Considerations + +4.3.1. PBU and PBA + + The following section describes how IPsec is used to protect the + signaling messages and data packets between the local mobility anchor + and mobile access gateway when using IPv4 transport. + + The following are the Security Policy Database (SPD) example entries + to protect PBU and PBA on the local mobility anchor and mobile access + gateway. + + MAG SPD-S: + - IF local_address = IPv4-Proxy-CoA_1 & + remote_address = IPv4-LMAA_1 & proto = UDP & + remote_port = 5436 + Then use SA ESP transport mode + + LMA SPD-S: + - IF local_address = IPv4-LMAA_1 & + remote_address = IPv4-Proxy-CoA_1 & proto = UDP & + local_port = 5436 + Then use SA ESP transport mode + +4.3.2. Payload Packet + + The following are the SPD example entries to protect payload packets + on the local mobility anchor and mobile access gateway. Note that + the example SPDs protect all payload packets sent to and from mobile + nodes. If an operator needs to apply a different security mechanism + per mobile node, they need to create a SPD and a SA entry per mobile + node. + + + + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 43] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + MAG SPD-S: + - IF interface = tunnel to LMAA_1 & + local_address != Proxy-CoA_1 & + remote_address != LMAA_1 & proto=any + Then use SA ESP tunnel mode + + LMA SPD-S: + - IF interface = tunnel to Proxy-CoA_1 & + local_address != LMAA_1 & + remote_address != Proxy-CoA_1 & proto=any + Then use SA ESP tunnel mode + + When payload packets are protected by IPsec, payload packets matching + the SPDs are passed to the IPsec module and encapsulated using the + tunnel mode ESP. The tunnel mode ESP encapsulated payload packets + are then directly sent to the peer mobile access gateway or local + mobility anchor. If IPsec is not applied to payload packets, then + they are encapsulated as shown in Figures 12 and 14. + +5. Protocol Configuration Variables + +5.1. Local Mobility Anchor - Configuration Variables + + The local mobility anchor MUST allow the following variables to be + configured by the system management. The configured values for these + protocol variables MUST survive server reboots and service restarts. + + AcceptForcedIPv4UDPEncapsulationRequest + + This flag indicates whether or not the local mobility anchor + should accept IPv4 UDP encapsulation request for the mobile node's + data traffic. The default value for this flag is set to (0), + indicating that plain IPv4 encapsulation (without UDP) is used for + data traffic. + +5.2. Mobile Access Gateway - Configuration Variables + + The mobile access gateway MUST allow the following variables to be + configured by the system management. The configured values for these + protocol variables MUST survive server reboots and service restarts. + + ForceIPv4UDPEncapsulationSupport + + This flag indicates whether or not the mobile access gateway + should request the mobile node's local mobility anchor to use + IPv4-UDP encapsulation mode for the mobile node's data traffic. + The default value for this flag is set to (0), indicating that + plain IPv4 encapsulation (without UDP) is used for data traffic. + + + +Wakikawa & Gundavelli Standards Track [Page 44] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + +6. IANA Considerations + + This document defines four new Mobility Header options: the IPv4 Home + Address Request option, IPv4 Home Address Reply option, IPv4 Default + Router Address option, and IPv4 DHCP Support Mode option. These + options are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4, + respectively. The Type value for these options has been assigned + from the same number space as allocated for the other mobility + options, as defined in [RFC3775]. + + The IPv4 Home Address Reply option, described in Section 3.3.2 of + this document, introduces a new number space, IPv4 Home Address Reply + status codes. This document currently reserves the following values. + Approval of any new status code values are to be made through IANA + Expert Review. + + o 0 Success + + o 128 Failure, Reason Unspecified + + o 129 Administratively prohibited + + o 130 Incorrect IPv4 home address + + o 131 Invalid IPv4 address + + o 132 Dynamic IPv4 home address assignment not available + + The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this + document, introduces a new number space, IPv4 DHCP Support Mode + Flags. This document reserves the value 0x1 for the (S) flag. + Approval of flag values are to be made through IANA Expert Review. + At this point in time, there are no thoughts on what the new flag + allocations can be, and hence this document leaves this to the + discretion of the Expert Review. + + This document also defines new Status values, used in Proxy Binding + Acknowledgement message, as described in Section 3.3.5. These values + have been assigned from the same number space as allocated for other + status codes [RFC3775]. Each of these allocated values is greater + than 128. + + NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170 + + Mobile node not authorized for IPv4 mobility service. + + + + + + +Wakikawa & Gundavelli Standards Track [Page 45] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171 + + Mobile node not authorized for the requesting IPv4 home + address. + + NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172 + + Mobile node not authorized for IPv6 mobility service. + + MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173 + + Multiple IPv4 home address assignment not supported. + + IANA has assigned two UDP port numbers, 5436 and 5437, for "pmip6- + cntl" and "pmip6-data", respectively. + +7. Security Considerations + + All the security considerations from the base Proxy Mobile IPv6 + [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6 + [RFC5555] specifications apply when using the extensions defined in + this document. Additionally, the following security considerations + need to be applied. + + This document defines new mobility options for supporting the IPv4 + Home Address assignment and IPv4 Transport Support features. These + options are to be carried in Proxy Binding Update and Proxy Binding + Acknowledgement messages. The required security mechanisms specified + in the base Proxy Mobile IPv6 protocol for protecting these signaling + messages are sufficient when carrying these mobility options. + + This specification describes the use of IPv4 transport for exchanging + signaling messages between the local mobility anchor and the mobile + access gateway. These can be protected using IPsec as described in + Section 4.3. + +8. Contributors + + This document reflects discussions and contributions from several + people (in alphabetical order): + + Kuntal Chowdhury + + kchowdhury@starentnetworks.com + + Vijay Devarapalli + + vijay.devarapalli@azairenet.com + + + +Wakikawa & Gundavelli Standards Track [Page 46] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + Pasi Eronen + + Pasi.Eronen@nokia.com + + Sangjin Jeong + + sjjeong@etri.re.kr + + Basavaraj Patil + + basavaraj.patil@nokia.com + + Myungki Shin + + myungki.shin@gmail.com + +9. Acknowledgements + + The IPv4 support for Proxy Mobile IPv6 was initially covered in + "Proxy Mobile IPv6" (March 2007). We would like to thank all the + authors of the document and acknowledge that initial work. + + Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles + Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, + Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, + Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe + Wu, and Zu Qiang for their helpful review of this document. + + Also, we would like to thank Spencer Dawkins, Tim Polk, Menachem + Dodge, Adrian Farrel, and Pekka Savola for their reviews of this + document as part of the IESG review process. Finally, special thanks + to Jouni Korohonen for his support in addressing the IPsec issues. + +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. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, December 1998. + + + +Wakikawa & Gundavelli Standards Track [Page 47] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, January 2001. + + [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support + in IPv6", RFC 3775, June 2004. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", RFC 4213, October 2005. + + [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client + Identifiers for Dynamic Host Configuration Protocol + Version Four (DHCPv4)", RFC 4361, February 2006. + + [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, + "DHCP Server Identifier Override Suboption", RFC 5107, + February 2008. + + [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., + and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. + + [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and + Routers", RFC 5555, June 2009. + +10.2. Informative References + + [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, + October 1984. + + [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and + E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + + [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting + Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. + + [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual + Stack Mobility", RFC 4977, August 2007. + + + + +Wakikawa & Gundavelli Standards Track [Page 48] + +RFC 5844 IPv4 Support for Proxy Mobile IPv6 May 2010 + + + [GREKEY] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, + "GRE Key Option for Proxy Mobile IPv6", Work in Progress, + May 2009. + +Authors' Addresses + + Ryuji Wakikawa + TOYOTA InfoTechnology Center, U.S.A., Inc. + 465 Bernardo Avenue + Mountain View, CA 94043 + USA + + EMail: ryuji@us.toyota-itc.com + + + Sri Gundavelli + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: sgundave@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wakikawa & Gundavelli Standards Track [Page 49] + |