RFC 5844
IPv4 Support for Proxy Mobile IPv6
Pages: 49
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 16
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 IPv6Abstract
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.
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
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 . . . . . . . . . . . . . . . . . . 481. 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.
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 IPv61.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.
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
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.
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
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.
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.
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
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.
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.
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.
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.
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
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].
(next page on part 2)