NETLMM Working Group R. Wakikawa
Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli
Expires: July 24, 2009 Cisco
January 20, 2009
IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-09.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 1]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Abstract
This document specifies extensions to 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. 2) allowing the mobility entities in the Proxy Mobile IPv6
domain to exchange signaling messages over an IPv4 transport network.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 2]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 18
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18
3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22
3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23
3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 25
3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2. DHCP Relay Agent co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 29
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38
4.2.1. Extensions to Binding Update List Entry . . . . . . . 38
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 42
5.1. Local Mobility Anchor - Configuration Variables . . . . . 42
5.2. Mobile Access Gateway - Configuration Variables . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
Wakikawa & Gundavelli Expires July 24, 2009 [Page 3]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Wakikawa & Gundavelli Expires July 24, 2009 [Page 4]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 in dual-stack mode and additionally 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 when the network between the local mobility anchor and the mobile
access gateway is an IPv4 or an IPv6 network. The motivation and
scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and
all those requirements apply to Proxy Mobile IPv6 protocol as well.
The Proxy Mobile IPv6 protocol [RFC-5213] 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 extends IPv4 support to the Proxy Mobile IPv6 protocol
[RFC-5213].
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 has an IPv4
stack 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 for enabling 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 and furthermore the
mobile access gateway may be using an IPv4 private address and
with NAT [RFC-3022] translation devices on the path to the local
mobility anchor.
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 any one or both of these features as
required.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 5]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
IPv4-LMAA1 -> | | <-- LMAA2
| |
\\ //\\
(NAT) // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
(IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2)
(IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3)
{MN1} {MN3}
Figure 1: IPv4 support for Proxy Mobile IPv6
1.1. Stated Assumptions
The following are the configuration requirements from the mobility
entities in the Proxy Mobile IPv6 domain for supporting the
extensions defined in this document.
o The local mobility anchor and the mobile access gateway are both
IPv4 and 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 [RFC-5213].
o The local mobility anchor and the mobile access gateway MUST be
configured with IPv6 globally unique addresses, even when they are
in IPv4-only network. These addresses can be of the type Unique
Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address
[RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using
IPv4 transport, it is not required that there is IPv6 routing
enabled between the local mobility anchor and the mobile access
gateway. However, they must be able to receive any IPv6 packets
sent to the configured IPv6 addresses, after removing the outer
IPv4 encapsulation header.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 6]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. Based on what is enabled for a mobile node, it should
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
address(es) 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
needs to 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 [RFC-2131], IPCP [RFC-1332],
IKEv2 [RFC-4306] or static address configuration.
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.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 7]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
2. Conventions & Terminology
2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119].
2.2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC-3775]
and Proxy Mobile IPv6 specification [RFC-5213]. 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. However, if the configured address is a private IPv4
address and with a NAT device in the path to the local mobility
anchor, the care-of address as seen by the local mobility anchor
will be the address allocated by the NAT device for that flow.
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)
This is the IPv4 home address assigned to the mobile node's
attached interface. This address is topologically anchored at the
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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 8]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
It is a procedure for partial de-registration of all the addresses
that belong to one address family, i.e., de-registration of either
IPv4 home address, or all of the IPv6 home network prefixes.
Encapsulation Modes
This document uses the following terms when referring to the
different encapsulation modes.
IPv4-over-IPv6
IPv4 packet carried as a payload of an IPv6 packet
IPv4-over-IPv4
IPv4 packet carried as a payload of an IPv4 packet
IPv4-over-IPv4-UDP
IPv4 packet carried as a payload in an UDP header of an IPv4
packet
IPv4-over-IPv4-UDP-TLV
IPv4 packet carried as a payload in an IPv4 packet with UDP and
TLV headers
Wakikawa & Gundavelli Expires July 24, 2009 [Page 9]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 interface and be able to retain that
address configuration even after changing its point of attachment in
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 [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], 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, however
there needs to be some interactions 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 for 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
an 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.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 10]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 an IPv4 home address from different subnets. In such
scenario, there will be multiple Binding Cache entries for the mobile
node on the local mobility anchor. All the address (IPv4/IPv6)
assigned to a given interface will be managed as part of one mobility
session, as specified in Section 5.4 of [RFC-5213].
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 be
extended with the following additional 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.
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 [RFC-5213] are
applied for processing the received Proxy Binding Update message.
However, if the received Proxy Binding Update message has an IPv4
Home Address option [ID-DSMIP6], the following considerations MUST be
applied additionally.
o If there is an IPv4 Home Address option [ID-DSMIP6] present in the
received Proxy Binding Update message, but if there is no Home
Network Prefix option [RFC-5213] present in the request, the local
mobility anchor MUST NOT reject the request as specified in
Section 5.3.1 of [RFC-5213]. At least one instance of any of
these two options MUST be present. If there is not a single
instance of any of these two options present in the request, the
local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to
MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213].
Wakikawa & Gundavelli Expires July 24, 2009 [Page 11]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
o If there is at least one instance of Home Network Prefix option
[RFC-5213] present in the received Proxy Binding Update message,
but either if the mobile node is not IPv6 enabled, or if IPv6
routing 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_HOME_NETWORK_PREFIX (mobile node not
authorized for the requesting IPv6 home network prefix).
o If there are more than one instance of the IPv4 Home Address
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 assignment not supported).
o If the prefix request(P) flag in the IPv4 Home Address option is
set to a value of 1, then the local mobility anchor MUST reject
the request and send a Proxy Binding Acknowledgement message with
the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4
prefix assignment not supported).
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 [RFC-5213] with a NON_ZERO prefix value, or, if there is
an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address
in the option set to ALL_ZERO, considerations from Section
5.4.1 of [RFC-5213] MUST be applied.
* If there is an IPv4 Home Address option [ID-DSMIP6] 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
[RFC-5213] present in the request, considerations from Section
5.3.2 of [RFC-5213] 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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 12]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
request is re-registration or a de-registration request and the
respective considerations from the below sections 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 and with the request to extend 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 option [ID-DSMIP6] 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 option [ID-DSMIP6] with the IPv4
address in the option set to a NON_ZERO value, the local mobility
anchor before accepting the request MUST ensure the address is
topologically anchored on the local mobility anchor and
furthermore 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). It MUST also include the IPv4
Address Acknowledgement option [ID-DSMIP6] 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 Address
Acknowledgement option [ID-DSMIP6] 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 [ID-
DSMIP6], 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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 13]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 bi-directional tunnel
to the mobile access gateway and with the encapsulation mode set
to the negotiated mode for carrying the IPv4 payload traffic.
When using IPv6 transport, the encapsulation mode is IPv4-over-
IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When
using IPv4 transport, the encapsulation mode is as specified in
Section 4.0.
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 [RFC-5213] MUST be
applied.
3.1.2.4. Binding Lifetime Extension (After handoff)
o If there is no Home Network Prefix option(s) [RFC-5213] 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 option [ID-
DSMIP6] 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
bi-directional 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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 14]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
handoff.
o The local mobility anchor MUST create a bi-directional tunnel to
the mobile access gateway that sent the request (if there is no
existing bi-directional 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 [RFC-
5213] 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.0 MUST be applied.
3.1.2.5. Binding De-Registration
All the considerations from Section 5.3.5 of [RFC-5213] MUST be
applied. Additionally, for removing the IPv4 state as part of the
Binding Cache entry deletion, the IPv4 host route and the dynamically
created bi-directional 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 with respect to those addresses MUST be deleted.
3.1.2.6. 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 [RFC-5213].
Additionally, the following considerations MUST be applied.
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option [RFC-
5213] 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 option [ID-
DSMIP6] and did 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 [RFC-5213]
or the IPv4 Address Acknowledgement option [ID-DSMIP6] present in
the Proxy Binding Acknowledgement message.
o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be
present in the Proxy Binding Acknowledgement message.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 15]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 Address Acknowledgement option [ID-DSMIP6]
corresponding to the IPv4 Home Address option [ID-DSMIP6]
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 Address
Acknowledgement option for carrying 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
allocated address. The status field value in the option must
be set to 0 (Success).
o The IPv4 Default-Router Address option MUST be present, if the
Status field value in the Proxy Binding Acknowledgement message is
set to 0 (Proxy Binding Update Accepted). 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 [RFC-5213] requires the Home Network Prefix [RFC-5213] as
the key parameter for identifying the Binding Cache entry. When
using an IPv4 address with a NON_ZERO value, the exact same
considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be
applied, with the exception of using an IPv4 home address in place of
an IPv6 home network prefix.
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
be able to receive packets that are sent to the mobile node's IPv4
home address. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for
the mobile node's IPv4 home address or for its home subnet. This
essentially enables IPv4 routers in that network to detect the
local mobility anchor as the last-hop router for that subnet.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 16]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Forwarding Packets to the Mobile Node:
o On receiving a packet from a correspondent node with the
destination address matching the mobile node's IPv4 home address,
the local mobility anchor MUST forward the packet through the bi-
directional 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 LMA to 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.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 Acknowledgment message.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 17]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 [RFC-5213] MUST be
extended with the following additional fields.
Extensions to the mandatory section of the policy profile:
o This field identifies all the IP protocol 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 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
[RFC-5213] MUST be applied with the following exceptions.
o The IPv4 Home Address option [ID-DSMIP6] 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 option [ID-DSMIP6] with the
IPv4 home address and the prefix length fields in the option
Wakikawa & Gundavelli Expires July 24, 2009 [Page 18]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
set to that specific address and its prefix length.
Furthermore, the (P) flag in the option MUST be set to 0.
* 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 ALL_ZERO value. Furthermore, the (P) flag in the
option MUST be set to 0. This essentially 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 [RFC-5213]. However, the Home Network
Prefix option(s) [RFC-5213] 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 for carrying the signaling messages, the
related considerations from section 4.0 MUST be applied
additionally.
3.2.3.2. Receiving Proxy Binding Acknowledgement
All the considerations from section 6.9.1.2 of [RFC-5213] 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_HOME_ADDRESS(The
mobile node is not authorized for IPv4 home address), the mobile
access gateway SHOULD NOT send a Proxy Binding Update message
including the IPv4 Home Address option [ID-DSMIP6] till an
administrative action is taken.
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 for the
same address again, but MAY request the local mobility anchor to
do the assignment of address by including exactly one instance of
IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
and the prefix length fields in the option set to ALL_ZERO value.
o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6]
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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 19]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
skipped.
o If the received Proxy Binding Acknowledgement message has the
Status field value in the IPv4 Address Acknowledgement Option [ID-
DSMIP6] set to a value that indicates that the request was
rejected by the local mobility anchor, the mobile access gateway
MUST NOT enable forwarding for that specific IPv4 home address.
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 Address Acknowledgement Option [ID-DSMIP6] set to a
value that indicates that the request was accepted by the local
mobility anchor, the mobile access gateway MUST establish a bi-
directional tunnel to the local mobility anchor (if there is no
existing bi-directional tunnel to that local mobility anchor) and
with the encapsulation mode set to IPv4-over-IPv6 (IPv4 packet
carried as a payload of an IPv6 packet). Considerations from
Section 5.6.1 of [RFC-5213] MUST be applied for managing the
dynamically created bi-directional tunnel. However, when using
IPv4 transport, the encapsulation mode MUST be set to the
negotiated encapsulation mode, as specified in Section 4 of this
specification.
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 bi-directional 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 MAY configure
this address on its interface and respond to any ARP requests sent
by the mobile node for resolving the hardware address of the
default-router. It MAY also use this address as the source
address for any datagrams sent to the mobile node and originated
by the mobile access gateway itself. It MAY also use this address
in the DHCP Router option [RFC-2132] in the DHCP messages.
o If there is an IPv4 DHCP Support Mode option 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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 20]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 for extending the lifetime
of a mobility session or for de-registering the mobility session, the
respective considerations from [RFC-5213] 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
option [ID-DSMIP6] 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. The (P) flag in the option MUST be set to 0.
o If there was no IPv4 home address requested in the initial Proxy
Binding Update message, but if it is determined that the IPv4 home
address MUST be requested subsequently, then there MUST be exactly
one instance of the IPv4 Home Address option [ID-DSMIP6] 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(s) [RFC-5213]. It MUST include exactly one instance of
the IPv4 Home Address option [ID-DSMIP6] 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) [RFC-5213] MUST NOT be present
if the same option(s) was not present in the initial Proxy Binding
Update message. Otherwise considerations from [RFC-5213] with
respect to this option MUST be applied.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 21]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
3.2.4. Routing Considerations for the Mobile Access Gateway
o On receiving a packet from the bi-directional 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 Considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect the local routing and on the use of
EnableMAGLocalRouting flag.
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 bi-directional tunnel established with the local
mobility anchor. The encapsulation considerations specified in
section 3.1.3 MUST be applied. However, before 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.
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 Default-Router Address Option
A new option, IPv4 Default-Router Address Option is defined for using
it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
local mobility anchor to the mobile access gateway. This option can
be used for sending 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wakikawa & Gundavelli Expires July 24, 2009 [Page 22]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Figure 3: IPv4 Default-Router Address Option
Type
IANA
Length
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 8-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 four-byte field containing the mobile node's default router
address.
3.3.2. IPv4 DHCP Support Mode
A new option, IPv4 DHCP Support Mode Option is defined for using it
in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
local mobility anchor to the mobile access gateway. This option can
be used for notifying the mobile access gateway, if 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 4: IPv4 DHCP Support Mode Option
Wakikawa & Gundavelli Expires July 24, 2009 [Page 23]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Type
IANA
Length
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 if 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.3. Status Codes
This document defines the following new Status values for use in the
Proxy Binding Acknowledgement message [RFC-5213]. These values are
to be allocated from the same numbering space, as defined in Section
6.1.8 of [RFC-3775].
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network
prefix(es).
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
Multiple IPv4 home address assignment not supported
IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED
Wakikawa & Gundavelli Expires July 24, 2009 [Page 24]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
IPv4 prefix assignment 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 can be
either the IPv4 Proxy Care-of Address or 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 potentially an IPv4
link-local address [RFC-3927] 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 The DHCP server identifies the DHCP client either from the client
identifier or the client hardware address (chaddr) [RFC-2131]. A
mobile node in a Proxy Mobile IPv6 domain may present any of these
identifiers to the DHCP server as long as the identifier remains
the same through out the mobile node's attachment in that Proxy
Mobile IPv6 domain. If the client hardware address is used as the
identifier and if the mobile node performs an handoff between two
interfaces, this hardware identifier will change and the DHCP
server will not be able to identify the mobile node. Thus, it is
recommended that the DHCP client on the mobile node, which
performs mobility session handoff across interfaces in a Proxy
Mobile IPv6 domain, is configured to use a stable client
identifier that does not change during the active life of its DHCP
session.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 25]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 (Ex: 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.
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
| | |
* DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling
* (Step-2 to Step-4) may happen in parallel and in no specific order
* Tunnel/Route setup(Step-4) and the subsequent steps will happen in
* in the specified order.
Figure 5: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment:
o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the
DHCP server 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. 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 support for the mobile node on that
access link.
o After a 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 [RFC-2131] to the mobile
node. The offered address will be the mobile node's IPv4 home
Wakikawa & Gundavelli Expires July 24, 2009 [Page 26]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
address, assigned by the local mobility anchor. The server
address, 'siaddr' field of the DHCPOFFER message, will be set to
the mobile node's default-router address. The DHCPOFFER message
will be unicasted to the mobile node.
o If the mobile node sends the DHCPREQUEST message, the DHCP server
will send DHCPACK message, as per [RFC-2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state [RFC-
2131], 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 'server
identifier' field 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 a different DHCP server (After
Handoff):
When the mobile node goes into the DHCP RENEWING state [RFC-2131], 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 updates the DHCP
server address and uses the address of the DHCP server that is co-
located with the new mobile access gateway. Any of the following
approaches can be adopted to ensure the mobile node uses the DHCP
server on the attached link.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 27]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
1. The use of fixed DHCP server address on all DHCP servers
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK or DHCPNACK
| : |
2. The use of FORCERENEW message to notify the address change
MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA)
|<---------------| 2. FORCERENEW
|--------------->| 3. DHCPREQUEST*b (IPv4 HoA)
BOUND<-------------| 4. DHCPACK or DHCPNACK
| : |
*a DHCPREQUEST sent to oMAG
*b DHCPREQUEST sent to nMAG
Figure 6: Address renewal with a different DHCP server
o If a fixed address such as the IPv4 default-router address of the
mobile node is used as the DHCP server Id on any of the links in
that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the
mobile node for renewing the address will be received by the new
mobile access gateway on the attached link. 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 IPv6 signaling or
is unable to acquire the same IPv4 address as requested by the
mobile node, it will send a DHCPNACK message [RFC-2131] to the
mobile node, as shown in Figure 6-1).
o If the mobile access gateway on the access link receives any DHCP
messages from the mobile node unicasted to a server address that
is not locally configured, the mobile access gateway can unicast
FORCERENEW message [RFC-3203] to the mobile node as shown in
Figure 6-2). This will force the mobile node to update the DHCP
server address with the address of the mobile access gateway on
the new link. However, if the FORCERENEW message [RFC-3203] is
also not supported by the DHCP server on the mobile access
gateway, then that DHCPREQUEST message can be ignored. This will
force the mobile node to enter the DHCP REBINDING state [RFC-2131]
and start the DHCPDISCOVER phase again.
Additional Operation:
Wakikawa & Gundavelli Expires July 24, 2009 [Page 28]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 can send the unicast FORCERENEW message
[RFC-3203] to the mobile node to force it to change its DHCP state
to the RENEW state. Furthermore, it MUST remove forwarding for
the mobile node's IPv4 home address.
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 7 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 (IPv4HoA)
| |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK via DHCP-R
| | |
* The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the
DHCPDISCOVER phase (Step-4) may occur in any order. However,
the DHCPOFFER (Step-5) and the following steps will occur in
the specified order and after the Tunnel/Route Setup (Step-3).
Figure 7: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment:
o When the mobile access gateway receives a DHCPDISCOVER message
from a mobile node, it can 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 has to complete the
Proxy Mobile IPv6 signaling with the local mobility anchor by
sending a Proxy Binding Update message.
o If the Proxy Binding Update message is rejected by the local
mobility anchor for any reason, the local mobility anchor will
discard the DHCPDISCOVER messages from the mobile node.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 29]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
o If the Proxy Binding Update message is accepted by the local
mobility anchor and if there is an assigned IPv4 home address for
the mobile node, the DHCP messages will be forwarded to the DHCP
server.
o The DHCP relay agent on the mobile access gateway will add the
DHCP relay agent information option [RFC-3046] 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 needs 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 needs to
have route towards the DHCP server.
IPv4 Home Address Renewal to the same DHCP server: (No Handover)
o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
directly unicasts DHCPREQUEST message to the DHCP server. The
DHCP relay agent may not detect these unicasted DHCPREQUEST
messages for renewing the address. Thus, any of the following
approaches can be adopted.
* The DHCP relay agent can intercept all the DHCP packets
regardless of the destination address. 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 [RFC-5107] to be in path for all the DHCP
message flows. The DHCP client uses the DHCP server address
which is overridden by the DHCP relay agent address as a
destination address of DHCPREQUEST. The DHCP Server Identifier
Wakikawa & Gundavelli Expires July 24, 2009 [Page 30]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 The DHCP Relay agent on detecting the DHCPREQUEST message from the
mobile node, will verify if the address in the DHCPREQUEST message
is the address assigned by the local mobility anchor for that
mobile node. If the requesting IPv4 home address is not
registered to the local mobility anchor, the mobile access gateway
will drop the packet. Once the address verification is
successfully completed, the DHCP relay agent will forward the
DHCPREQUEST message to the DHCP server. However, the mobile
access gateway is not required to perform this check, if the DHCP
server is co-located with the local mobility anchor, as that check
will be performed by the local mobility anchor in such scenario.
The mobile access gateway can determine the co-location of the
DHCP server and the local mobility anchor by comparing the source
address of the DHCPOFFER message with the address of the mobile
node's local mobility anchor.
IPv4 Address Release Triggers from the mobile node:
o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC-2131]. When the mobile
access gateway detects the DHCPRELEASE message sent by the mobile
node and for releasing its assigned IPv4 home address, the mobile
access gateway should consider this as a trigger for de-
registering the mobile node's IPv4 home address. It MUST apply
the considerations specified in section 3.2.3.3 for performing the
de-registration procedure. However, this operation should not
release any IPv6 home network prefix(es) assigned to the mobile
node.
Additional Operations:
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 can send the unicast FORCERENEW message
[RFC-3203] to the mobile node to force it to change its DHCP state
to RENEW state. Furthermore, it MUST remove forwarding for the
mobile node IPv4 home address.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 31]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling
messages exchanged between the local mobility anchor and the mobile
access gateway to be over an IPv6 transport. The extensions defined
in this section allow the exchange of signaling messages over an IPv4
transport when the local mobility anchor and the mobile access
gateway are separated by an IPv4 network and are reachable using only
IPv4 addresses.
IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + |
+--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+
+ - - - - - - +
Figure 8: 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. Additionally,
both entities are also IPv6 enabled and have configured IPv6
addresses on their interfaces, as specified in [RFC-5213], but are
reachable only over an IPv4 transport.
o The mobile access gateway can be potentially in a private IPv4
network behind a NAT [RFC-3022] device, with a private IPv4
address configured on its egress interface. But, the local
mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address. However, both the local mobility
anchor and the mobile access gateway can be in the same private
IPv4 routing domain, i.e., when both are configured with private
IPv4 addresses and with no need for NAT translation between them.
o The IPv6 address configuration requirement on the mobile access
gateway does not imply there needs to be IPv6 routing enabled
Wakikawa & Gundavelli Expires July 24, 2009 [Page 32]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
between the local mobility anchor and the mobile access gateway.
It just requires each of the mobile access gateways and local
mobility anchors in a Proxy Mobile IPv6 domain to be configured
with a globally unique IPv6 address.
o The Proxy Mobile IPv6 signaling messages exchanged between the
local mobility anchor and the mobile access gateway for
negotiating the IPv4 transport will be encapsulated and carried as
IPv4 packets. However, these signaling messages are fundamentally
IPv6 messages using the mobility header and the related semantics
as specified in base Proxy Mobile IPv6 specification [RFC-5213],
but carried as a payload in an IPv4 packet. The supported
encapsulation modes for the signaling messages are either native
IPv4 or IPv4 with UDP header.
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 IPv4 tunnel established between the local mobility anchor and
the mobile access gateway (with any of the supported encapsulation
modes over IPv4 transport) will be used for carrying the mobile
node's IPv4 and IPv6 traffic. The supported encapsulation modes
for carrying mobile node's IPv4 or IPv6 packets when using IPv4
transport are as shown below.
* IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet)
* IPv4-UDP (Payload packet carried in an IPv4 packet with UDP
header).
* IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP
and TLV header). Refer to [ID-DSMIP6].
* IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP
and ESP headers). Refer to [RFC-3948].
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 [RFC-5213] MUST be
extended with the following additional parameters.
o This is the IPv4 Proxy Care-of Address configured on the mobile
access gateway that sent the Proxy Binding Update message. This
address can be obtained from the IPv4 Care-of Address option [ID-
Wakikawa & Gundavelli Expires July 24, 2009 [Page 33]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
DSMIP6], present in the received 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
MUST be set to ALL_ZERO value.
o The IPv4 NAT translated address of the mobile access gateway. If
the mobile access gateway is not behind a NAT [RFC-3022], this
address will be the same as the address configured on the egress
interface of the mobile access gateway. This address can be
obtained from the IPv4 header of the received Proxy Binding Update
message. However, if the received Proxy Binding Update message is
not sent as an IPv4 packet, this field MUST be set to 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 [RFC-5213] 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.
4.1.3.1. Processing Proxy Binding Updates
o If the received Proxy Binding Update message was sent encapsulated
in IPv4 or IPv4-UDP header, the message MUST be authenticated
after removing the outer encapsulation (IPv4 or IPv4-UDP) header.
Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the request.
o All the considerations from Section 5.3.1 of [RFC-5213] MUST be
applied on the encapsulated Proxy Binding Update message, after
removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in
the request and if the outer encapsulation header is IPv4-UDP,
then the NAT presence detection procedure specified in Section
4.1.3.3 MUST be used for detecting the NAT in the path.
o Upon accepting the request, the local mobility anchor MUST set up
an IPv4 bi-directional tunnel to the mobile access gateway. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 34]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
The encapsulation mode MUST be determined from the below
considerations.
* If the received Proxy Binding Update message was sent with IPv4
encapsulated header, then the encapsulation mode for the bi-
directional tunnel MUST be set to IPv4. Otherwise, the
following considerations apply.
* If NAT is detected on the path, or 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.
* If NAT is not detected on the path and 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 [ID-DSMIP6] in the Proxy Binding Update message
is set to value of 1, then the encapsulation mode MUST be set
to IPv4-UDP-TLV.
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 [RFC-5213]. However, if
the received Proxy Binding Update message was encapsulated in an IPv4
packet or as a payload in the UDP header of an IPv4 packet, the
following additional considerations MUST be applied.
o The Proxy Binding Acknowledgement message MUST be encapsulated in
an IPv4 packet. However, if the received Proxy Binding Update
message was sent encapsulated in the UDP header of an IPv4 packet,
then the Proxy Binding Acknowledgement message MUST be
encapsulated in the UDP header of an IPv4 packet.
o The source address in the IPv4 header of the message MUST be set
to the destination IPv4 address of the received request.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 35]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
o If the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security
association that is based of IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
MUST be protected using IPsec ESP [RFC-4301] mode. There is no
need to apply IPsec ESP header to the IPv6 packet. In all other
cases, the Proxy Binding Acknowledgement message MUST be protected
using IPsec prior to the IPv4 or IPv4-UDP encapsulation.
o The NAT Detection option [ID-DSMIP6] MUST be present only if there
is an IPv4 Care-of Address option [ID-DSMIP6] present in the
received Proxy Binding Update message and if the NAT detection
procedure resulted in detecting a NAT on path. However, if the
received Proxy Binding Update message was not sent encapsulated in
IPv4 UDP header, then the option MUST NOT be present.
Furthermore, in all other cases, the option MUST NOT be present.
o The IPv4 DHCP Support Mode option MAY be present. If this option
is not present, the mobile access gateway will enable the default
behavior and function as a DHCP Relay for the mobile node.
o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 packet and protected using IPv6 security
association. The UDP header MUST be present only if the received
Proxy Binding Update message was sent with IPv4-UDP encapsulation
header.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/
/* IPv6 PBA Packet protected with ESP header */
Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated
in IPv4 header
4.1.3.3. NAT Presence Detection
When the transport network between the local mobility anchor and the
mobile access gateway is an IPv4 network and if the received Proxy
Binding Update message was sent encapsulated in IPv4 UDP header, the
local mobility anchor performs the NAT Presence Detection as
specified below.
On receiving the Proxy Binding Update message encapsulated in an IPv4
UDP packet, the local mobility anchor, if it detects a NAT on the
path, will send the Proxy Binding Acknowledgment message with the NAT
Detection Option. The presence of this option in the Proxy Binding
Wakikawa & Gundavelli Expires July 24, 2009 [Page 36]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Acknowledgment is an indication to the mobile access gateway about
the presence of NAT in the path. On detecting any NAT in the path,
both the local mobility anchor and the mobile access gateway will set
the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation.
The specific details around the NAT detection and the related logic
are described in DSMIPv6 specification [ID-DSMIP6].
However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to a value of 0, the
mobile access gateway will not use IPv4 UDP encapsulation for Proxy
Binding Update messages and hence the local mobility anchor will not
perform this NAT Presence Detection procedure on these messages that
are not sent in IPv4 UDP packet.
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 bi-directional tunnel set up for
that mobile node.
o The format of the tunneled packet is shown below.
IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */
[UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA)
OR
IPv4 header (src= CN, dst= IPv4 MN-HoA)
Figure 10: Tunneled IPv4 Packet from LMA to MAG
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
Wakikawa & Gundavelli Expires July 24, 2009 [Page 37]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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 Considerations
The ECN considerations specified in Section 5.6.3 of [RFC-5213] 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.
4.1.4.3. Bi-Directional Tunnel Management
The Tunnel Management considerations specified in section 5.6.1 of
[RFC-5213] 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 [RFC-5213] 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.
o The IPv4 address of the mobile access gateway. This is the
address configured on the egress interface of the mobile access
gateway and is registered with the mobile node's local mobility
anchor as the IPv4 Proxy-CoA. However, if the mobile access
gateway is in a private IPv4 network and behind a NAT, the address
that is registered with the mobile node's local mobility anchor is
the NAT translated public IPv4 address.
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 [RFC-5213]. However, if the mobile access
gateway is in an IPv4-only access network, the following additional
considerations MUST be applied.
o The Proxy Binding Update message MUST be encapsulated in an IPv4
packet. However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
Wakikawa & Gundavelli Expires July 24, 2009 [Page 38]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
Binding Update message MUST be encapsulated in an UDP header of an
IPv4 packet.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The
IPv4 address in the option MUST be set to the mobile access
gateway's IPv4-Proxy-CoA.
o The packet MUST be constructed as specified in Section 4.2.3.
o When sending a Proxy Binding message for extending the lifetime of
a currently existing mobility session or for de-registering the
mobility session, the Proxy Binding Update message MUST be
constructed as the initial request.
Receiving Proxy Binding Acknowledgement
o If the received Proxy Binding Acknowledgement message is
encapsulated in IPv4 or IPv4 UDP packet, the message MUST be
authenticated after removing the outer IPv4 or IPv4-UDP header.
Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the message.
o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be
applied on the encapsulated Proxy Binding Acknowledgement message,
after removing the outer IPv4 UDP header.
o If the Status field indicates Success, the mobile access gateway
MUST setup a bi-directional tunnel to the local mobility anchor.
o Upon accepting the request, the mobile access gateway MUST set up
an IPv4 bi-directional tunnel to the local mobility anchor. The
tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA.
The encapsulation mode MUST be determined from the below
considerations.
* The encapsulation mode for the bi-directional tunnel MUST be
set to IPv4. However, if the value of the configuration
variable, UseIPv4UDPEncapForSignalingMessages, is set to 1,
then the following considerations MUST be applied.
* If there is a NAT Detection option [ID-DSMIP6] in the received
Proxy Binding Acknowledgement message and if the value of the
configuration flag, UseIPv4UDPEncapForSignalingMessages, is set
to value of 1, then the encapsulation mode for the tunnel MUST
be set to IPv4-UDP. Otherwise the encapsulation mode MUST be
set to IPv4.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 39]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
* If the (T) flag in the Proxy Binding Acknowledgement message is
set to value of 1, then the encapsulation mode MUST be set to
IPv4-UDP-TLV.
4.2.2.1. Constructing the Proxy Binding Update Message
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 The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The
address MUST be set to the mobile access gateway's IPv4-Proxy-CoA.
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 the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security
associated that is based of IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement
message) MUST be protected using IPsec ESP [RFC-4301] mode and
additionally there is no need to apply ESP header on the IPv6
packet. In all other cases, the Proxy Binding Update message MUST
be protected on the IPv6 packet of the Proxy Binding Update
message, prior to the IPv4 encapsulation.
o The format of the Proxy Binding Update message encapsulated in an
IPv4 or IPv4-UDP packet with no IPsec protection:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/
/* IPv6 PBU Packet protected with ESP header */
Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4
UDP header
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. However, considerations from Section 6.10.3 of [RFC-
Wakikawa & Gundavelli Expires July 24, 2009 [Page 40]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
5213] 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=DSMIPv6, dst port=Z] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */
/* 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
o Forwarding Packets received from the bi-directional tunnel:
o On receiving a packet from the bi-directional 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.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 41]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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, even if there is no NAT detected in the path.
The default value for this flag is set to value of 0, indicating
that the local mobility anchor MUST NOT accept IPv4 UDP
encapsulation request when NAT is not detected in the path.
When the value for this flag is set to value of 1, the local
mobility anchor MUST accept IPv4 UDP encapsulation request even
when NAT is not detected in the path.
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.
UseIPv4UDPEncapForSignalingMessages
This flag indicates whether or not the mobile access gateway
should use IPv4-UDP encapsulation mode for the signaling messages.
The default value for this flag is set to value of 0, indicating
that the mobile access gateway MUST NOT use IPv4-UDP encapsulation
mode, but MUST use native IPv4 encapsulation mode for sending the
Proxy Mobile IPv6 signaling messages.
When the value for this flag is set to value of 1, the mobile
access gateway MUST use IPv4-UDP encapsulation mode for sending
the Proxy Mobile IPv6 signaling messages.
ForceIPv4UDPEncapsulationSupport
Wakikawa & Gundavelli Expires July 24, 2009 [Page 42]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
This flag indicates whether or not the mobile access gateway
should request the mobile node's local mobility anchor for forcing
IPv4 UDP encapsulation support for the mobile node's data traffic,
even when NAT is not detected in the path.
The default value for this flag is set to value of 0, indicating
that the mobile access gateway MUST NOT request the mobile node's
local mobility anchor for forcing IPv4 UDP encapsulation support
even when NAT is not detected in path.
When the value for this flag is set to value of 1, the mobile
access gateway MUST force the mobile node's local mobility anchor
for IPv4 UDP encapsulation support.
This flag is applicable only when the flag
UseIPv4UDPEncapForSignalingMessages is set to a value of 1.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 43]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
6. IANA Considerations
This document defines a new Mobility Header option, IPv4 Default
Router Address option. This option is described in Section 3.3.1.
The Type value for this option needs to be assigned from the same
numbering space as allocated for the other mobility options, as
defined in [RFC-3775].
This document also defines new Binding Acknowledgement status values,
as described in Section 3.3.2. The status values MUST be assigned
from the same number space used for Binding Acknowledgement status
values, as defined in [RFC-3775]. The allocated values for each of
these status values must be greater than 128.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 44]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
7. Security Considerations
All the security considerations from the base Proxy Mobile IPv6
protocol [RFC-5213] apply when using the extensions defined in this
document. Additionally, the following security considerations need
to be applied.
This document defines news mobility options for supporting the IPv4
Home Address assignment and IPv4 Transport Support features. It also
uses some of the mobility options from DSMIPv6 specification [ID-
DSMIP6]. 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
the signaling messages between the local mobility anchor and the
mobile access gateway. These signaling messages are fundamentally
IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4
packets. The encapsulated inner IPv6 message is still protected
using IPsec, using the established security association and this
offers the same level of security as when the messages are routed
natively as IPv6 packets. The use of outer IPv4 header does not
introduce any new security vulnerabilities.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 45]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
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
Sangjin Jeong
sjjeong@etri.re.kr
Basavaraj Patil
basavaraj.patil@nsn.com
Myungki Shin
myungki.shin@gmail.com
9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like
to thank all the authors of the document and acknowledge that initial
work.
Thanks to Alper Yegin, Behcet Sarikaya, Charles Perkins, Damic
Damjan, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana
Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati, Vidya
Narayanan, Yingzhe Wu and Zu Qiang for their helpful review of this
document.
10. References
10.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 46]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004.
[RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast
Addresses", RFC-4193, October 2005.
[RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC-4291, February 2006.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
November 2007.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-07.txt, December 2008.
10.2. Informative References
[RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January
2001.
[RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
[RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link-
Local Addresses", RFC 3927, May 2005.
[RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP
Packets", RFC 3948, January 2005.
[RFC-4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Wakikawa & Gundavelli Expires July 24, 2009 [Page 47]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 January 2009
[RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
Mobility", RFC 4977, August 2007.
[RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp,
"DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
Authors' Addresses
Ryuji Wakikawa
Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Wakikawa & Gundavelli Expires July 24, 2009 [Page 48]
