[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
PROPOSED STANDARD
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