draft-ietf-netlmm-pmip6-ipv4-support-03.txt   draft-ietf-netlmm-pmip6-ipv4-support-04.txt 
NETLMM Working Group R. Wakikawa (Editor) NETLMM Working Group R. Wakikawa
Internet-Draft Keio University Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: November 23, 2008 Cisco Expires: January 15, 2009 Cisco
May 22, 2008 July 14, 2008
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-03.txt draft-ietf-netlmm-pmip6-ipv4-support-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 23, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to Proxy Mobile IPv6 protocol for
supporting IPv4 protocol. The scope of this IPv4 support includes adding IPv4 protocol support. The scope of IPv4 protocol support is
the support for the mobile node's IPv4 home address mobility and for two-fold: 1) For extending IPv4 home address mobility support to the
allowing the mobility entities in the Proxy Mobile IPv6 domain to mobile node. 2) For allowing the mobility entities in the Proxy
exchange signaling messages over an IPv4 transport. Mobile IPv6 domain to exchange signaling messages over an IPv4
transport network.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 7 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 8 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.2.1. Extensions to Binding Update List Entry . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.2.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.3. Routing Considerations for the Local Mobility
3.3. Local Mobility Anchor Considerations . . . . . . . . . . . 15 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 15 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 16
3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 16 3.2.1. Extensions to Binding Update List Entry . . . . . . . 16
3.3.3. Routing Considerations . . . . . . . . . . . . . . . . 18 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 16
3.4. Mobility Options . . . . . . . . . . . . . . . . . . . . . 19 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17
3.4.1. IPv4 Default Router Address Option . . . . . . . . . . 19 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 19
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 19
3.3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . 20
3.4. Supporting DHCP Based Address Configuration . . . . . . . 21
3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2. DHCP Relay Agent co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 25
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 20 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 28
4.1. NAT Support . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 29
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 22 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 29
4.2.1. Extensions to Binding Update List Entry . . . . . . . 22 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 30
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 22 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 30
4.3. Local Mobility Anchor Considerations . . . . . . . . . . . 25 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 32
4.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 25 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 34
4.3.2. Signaling Considerations . . . . . . . . . . . . . . . 25 4.2.1. Extensions to Binding Update List Entry . . . . . . . 34
4.4. Tunnel Management . . . . . . . . . . . . . . . . . . . . 28 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 34
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 38
5.1. Local Mobility Anchor - Configuration Variables . . . . . 38
5.2. Mobile Access Gateway - Configuration Variables . . . . . 38
5.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. DHCP usages for IPv4 home address assignment . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.1. Normative References . . . . . . . . . . . . . . . . . . . 42
10.2. Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a 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 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 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 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 or an IPv6 network. It is also reasonable to expect the same
mobility infrastructure in a Proxy Mobile IPv6 domain to provide mobility infrastructure in the Proxy Mobile IPv6 domain to provide
mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 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 and when the network between the local mobility anchor and the mobile
access gateway is an IPv4 or an IPv6 network. The motivation and 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 scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and
all those requirements apply to Proxy Mobile IPv6 protocol as well. all those requirements apply to Proxy Mobile IPv6 protocol as well.
The Proxy Mobile IPv6 protocol[ID-PMIP6] specifies a mechanism for The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for
providing IPv6 home address mobility support to a mobile node in a providing IPv6 home address mobility support to a mobile node in a
Proxy Mobile IPv6 domain and when there is an IPv6 transport network Proxy Mobile IPv6 domain. The protocol requires IPv6 transport
separating the entities involved in the mobility management. The network between the mobility entities. The extensions defined in
extensions defined in this document are for extending IPv4 support to this document extends IPv4 support to the Proxy Mobile IPv6 protocol
the Proxy Mobile IPv6 protocol [ID-PMIP6]. [RFC-5213].
The scope of IPv4 support in Proxy Mobile IPv6 includes the support The scope of IPv4 support in Proxy Mobile IPv6 includes the support
for the following two features: for the following two features:
o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 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 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 to use that address from any of the access networks in that Proxy
Mobile IPv6 domain. The mobile node is not required to be Mobile IPv6 domain. The mobile node is not required to be
allocated or assigned an IPv6 address for enabling IPv4 home allocated or assigned an IPv6 address for enabling IPv4 home
address support. address support.
o IPv4 Transport Network Support: The mobility entities in the Proxy o IPv4 Transport Network Support: The mobility entities in the Proxy
Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
signaling messages over an IPv4 transport and further the local signaling messages over an IPv4 transport and further the mobile
mobility anchor or the mobile access gateway may be using IPv4 access gateway may be using an IPv4 private address and with NAT
private addresses and with NAT [RFC-3022] translation devices [RFC-3022] translation devices on the path to the local mobility
separating them. anchor.
The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address
mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC-
3775]. The solution specified in this document leverages some of the
options related to IPv4 support and some processing logic for
extending IPv4 support to Proxy Mobile IPv6 protocol. These two
features, the IPv4 Home Address Mobility support and IPv4 transport
support features, are independent of each other and deployments can
choose to enable any one or both of these features.
Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home These two features, the IPv4 Home Address Mobility support and the
address mobility and IPv4 transport support features. The mobile IPv4 transport support features, are independent of each other and
nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or deployments may choose to enable any one or both of these features as
dual-stack mode, and the transport network between the local mobility required.
anchor and the mobile access gateway may be an IPv6 network or an
IPv4 network. Further, when the transport network is IPv4, either
the local mobility anchor or the mobile access gateway, or both can
be behind a NAT [RFC-3022] translation device and configured with an
IPv4 private address.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA1 -> | | <-- LMAA2 IPv4-LMAA1 -> | | <-- LMAA2
| | | |
\\ //\\ \\ //\\
[NAT] // \\ [NAT] // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
skipping to change at page 5, line 42 skipping to change at page 6, line 32
|MAG1|-----{MN2} |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
(IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2)
(IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3)
{MN1} {MN3} {MN1} {MN3}
Figure 1: IPv4 support for Proxy Mobile IPv6 Figure 1: IPv4 support for Proxy Mobile IPv6
1.1. Stated Assumptions 1.1. Stated Assumptions
o This specification requires that the local mobility anchor and the Following are the configuration requirements from the mobility
mobile access gateway are both IPv6 capable and IPv6 enabled. entities in the Proxy Mobile IPv6 domain for supporting the
Irrespective of the type of transport network (IPv4 or IPv6) extensions defined in this document.
separating these two entities (i.e., if the entities are reachable
using an IPv4 or IPv6 transport address), the mobility signaling
is always based on Proxy Mobile IPv6.
o For supporting IPv4/IPv6 home address mobility, the transport o The local mobility anchor and the mobile access gateway are both
network between the local mobility anchor and the mobile access IPv4 and IPv6 enabled. Irrespective of the type of transport
gateway can be an IPv6 network or an IPv4 network. However, for network (IPv4 or IPv6) separating these two entities, the mobility
supporting IPv4 transport network feature, as implied, IPv4 signaling is always based on Proxy Mobile IPv6 [RFC-5213].
transport network is required.
o The mobile node can be operating in IPv4-only, IPv6-only or in o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. If enabled, the mobile node should be able to obtain dual mode. Based on what is enabled for a mobile node, it should
IPv4-only, IPv6-only or both IPv4 and IPv6 address(es) on its be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
interface. However, the respective protocol(s) support must be address(es) for its interface and further achieve mobility support
enabled on the access link between the mobile node and the mobile for those addresses.
access gateway.
o There can be support for multiple IPv4 home network prefixes for o For enabling IPv4 home address mobility support to a mobile node,
the mobile node's attached interface. The mobile node should be it is not required that the IPv6 home address mobility support
able to obtain one or more IPv4 addresses from one or all of its needs to enabled. However, the respective protocol(s) support
IPv4 home network prefixes. Based on the type of link, it may be must be enabled on the access link between the mobile node and the
able to acquire its IPv4 address configuration using DHCP, IPCP, mobile access gateway.
IKEv2 or through other standard address configuration mechanisms.
o The mobile node's IPv4 home network prefix is a shared prefix o The mobile node can obtain one or more IPv4 addresses for its
(unlike its IPv6 home network prefix, which is a shared prefix). attached interface. Based on the type of link, it may be able to
There can be more than one mobile node sharing address(es) from acquire its IPv4 address configuration using DHCP [RFC-2131], IPCP
the same IPv4 home network prefix. [RFC-1332], IKEv2 [RFC-4306], static configuration or through
other standard IPv4 address configuration mechanisms.
o The mobile access gateway is always the IPv4 default-router for o The mobile node's IPv4 home subnet is typically a shared address
the mobile node on its access link. It will always be able to space. Its is not for the exclusive use of any one mobile node.
receive traffic sent to the mobile node's IPv4 default-router There can be more than one mobile node sharing different addresses
address. from the same IPv4 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.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119]. document are to be interpreted as described in RFC 2119 [RFC-2119].
2.2. Terminology 2.2. Terminology
All the mobility related terms used in this document are to be All the mobility related terms used in this document are to be
interpreted as defined in Mobile IPv6 specification [RFC-3775] and interpreted as defined in the Mobile IPv6 specification [RFC-3775]
Proxy Mobile IPv6 specification [ID-PMIP6]. In addition the document and Proxy Mobile IPv6 specification [RFC-5213]. In addition this
introduces the following terms. document introduces the following terms.
IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)
The IPv4 address that is configured on the interface of the mobile The IPv4 address that is configured on the egress-interface of the
access gateway and is the transport endpoint of the tunnel between mobile access gateway. When using IPv4 transport, this address
a local mobility anchor and a mobile access gateway. This address will be the registered care-of address in the mobile node's
will be used as the source address for the signaling messages sent Binding Cache entry and will also be the transport-endpoint of the
by the mobile access gateway to the local mobility anchor and will tunnel between the local mobility anchor and a mobile access
be the registered Care-of address in the mobile node's Binding gateway. However, if the configured address is a private IPv4
Cache entry. However, when the configured address is a private address and with a NAT device in the path to the local mobility
IPv4 address and with a NAT device in the path to the local anchor, the care-of address as seen by the local mobility anchor
mobility anchor, the care-of address as seen by the local mobility will be the address allocated by the NAT device for that flow.
anchor will be the address allocated by the NAT device for that
flow.
IPv4 Local Mobility Anchor Address (IPv4-LMAA) IPv4 Local Mobility Anchor Address (IPv4-LMAA)
The IPv4 address that is configured on the interface of a local The IPv4 address that is configured on the egress-interface of the
mobility anchor and is the transport endpoint of the tunnel local mobility anchor. When using IPv4 transport, the mobile
between the local mobility anchor and the mobile access gateway. access gateway sends the Proxy Binding Update messages to this
This is the address to where the mobile access gateway sends the address and will be the transport-endpoint of the tunnel between
Proxy Binding Update messages when using IPv4 transport. If the the local mobility anchor and the mobile access gateway.
local mobility anchor is configured to be behind a NAT device,
this address will not be directly configured on the local mobility
anchor, but a corresponding mapped private address will be
configured on the local mobility anchor.
Mobile Node's IPv4 Home Network Prefix (IPv4-MN-HNP) Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
This is the IPv4 prefix from which the mobile node obtains its This is the IPv4 home address assigned to the mobile node's
home address(es). This IPv4 home network prefix is topologically attached interface. This IPv4 home address is topologically
anchored at the mobile node's local mobility anchor. The mobile anchored at the local mobility anchor. The mobile node configures
node configures its interface with address(es) from this prefix. this address on its attached interface. There can be more than
one IPv4 home addresses assigned to the mobile node's attached
interface. Further, if the mobile node connects to the Proxy
Mobile IPv6 domain through multiple interfaces and for
simultaneous access, each of the attached interfaces will be
assigned a unique set of IPv4 home addresses and all the IPv4
addresses that are assigned to a given interface of a mobile node
will be managed under one mobility session.
3. IPv4 Home Address Mobility Support Encapsulation Modes
An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6 This document uses the following terms when referring to the
domain, the network will ensure the mobile node will be able to different encapsulation modes.
obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for
the interface attached to the access network in that Proxy Mobile
IPv6 domain. Using the extensions defined in this specification, the
mobile access gateway on the access network will exchange the
signaling messages with the mobile node's local mobility anchor and
will setup the required routing state for that home address.
If the mobile node connects to the Proxy Mobile IPv6 domain, through IPv4-over-IPv6
multiple interfaces and simultaneously through different access
networks, each of the connected interfaces will obtain an address
from a unique IPv4 home network prefix. In such configuration, there
will be multiple Binding Cache entries on the local mobility anchor
for that mobile node and with one entry for each connected interface,
as specified in Section 5.4 [ID-PMIP6].
The support for IPv4 addressing is orthogonal to the IPv6 addressing IPv4 packet carried as a payload of an IPv6 packet
support. Unlike as specified in [ID-DSMIP6], the mobile node is not
required to have an IPv6 home address for obtaining IPv4 home address
mobility. A mobile node attached to an access link in a Proxy Mobile
IPv6 domain will be able to obtain just an IPv4 address configuration
or both IPv4 and IPv6 address configurations on the connected
interface. The mobile nodes' policy profile will determine if the
mobile node is entitled for both the protocols or a single protocol
and based on what is enabled, only those protocols will be enabled on
the access link. Further, when the mobile node after obtaining the
IPv4 or IPv4/IPv6 address configuration on the access link, performs
an inter-technology handoff, the network will ensure the mobile node
will be able to use the same IPv4/IPv6 address configuration on the
new interface. [RYUJI The IPv4 home address MUST be the global IPv4
address. A private IPv4 address assignment as an IPv4 home address
is prohibited. There is no gurantee to assign the IPv4 private home
address which is different from the private address configured at a
mobile access gateway.]
3.1. IPv4 Home Address Assignment IPv4-over-IPv4
A mobile node on attaching to an access link connected to a mobile IPv4 packet carried as a payload of an IPv4 packet
access gateway, and if the network allows the mobile node for IPv4
home address mobility service, the mobile node using any of the IPv4
address configuration procedures, such as DHCP [RFC-2131], IPCP or
IKEv2 that are supported on that access link, will be able to obtain
required information for its IPv4 home address configuration. The
required information includes the IPv4 home address, the IPv4 home
network prefix, IPv4 home network prefix length and the IPv4 default
router address.
When a mobile node is configured with a static IPv4 home address, the IPv4-over-IPv4-UDP
IPv4 home address information SHOULD be stored in the mobile node's
policy profile. The mobile access gateway where the mobile node
attached obtains the static IPv4 home address from the policy
profile. The mobile access gateway MUST use either the obtained IPv4
home address or the obtained IPv4 home subnet address to initialize
the IPv4 Home Address and Pref fields in the IPv4 Home Address option
[ID-DSMIP6]. This option is carried by a proxy binding update
described in [ID-PMIP6].
On the other hand, if DHCP is used for the IPv4 home address IPv4 packet carried as a payload in an UDP header of an IPv4
allocation as specified in [RFC-2131], a DHCP server and/or a DHCP packet
relay agent on the link will ensure the mobile node is assigned an
IPv4 address from its home network subnet. All the IPv4 home
addresses assigned to mobile nodes must be reachable via local
mobility anchor so that local mobility anchor intercepts packets
meant for an IPv4 home address and tunnels them to the mobile node
via corresponding mobile access gateway. There are several
configurations where the DHCP entities are located in a Proxy Mobile
IPv6 domain. This document recommends following two configurations.
The other configurations are explained in Appendix A.
1. DHCP server is co-located with each mobile access gateway IPv4-over-IPv4-UDP-TLV
2. DHCP server is co-located with a local mobility anchor and a DHCP IPv4 packet carried as a payload in an IPv4 packet with UDP and
relay is co-located with each mobile access gateway TLV headers
Figure 2 shows the operational sequence of the home address 3. IPv4 Home Address Mobility Support
assignment when a DHCP server is co-located with each mobile access
gateway. In this scenario, a DHCP server which is also a mobile
access gateway interacts with a DHCP client on a mobile node. All
mobile access gateways SHOULD support minimal functionality of a DHCP
server in order to send DHCP offer and acknowledgment messages to the
mobile node in reply to the DHCP discovery and request messages.
While the mobile access gateway is seen as a DHCP server from a
mobile node, it actually obtains the IPv4 home address for each
mobile node from the local mobility anchor during proxy binding
procedure (set 0.0.0.0 in the the IPv4 Home Address field of the IPv4
home address option as described in [ID-DSMIP6]). After MAG
receiving the assigned IPv4 address from LMA, it assigns the address
to the requesting mobile node. Note that the mobile access gateway
MUST return its own IP address in the 'server identifier' option when
sending DHCP messages to the mobile node. Thus, whenever the mobile
node changes the attached mobile access gateway, this server
identifier must be updated. The detail can be found in
Section 3.2.2. The second scenario does not have this server
identifier change when a mobile node changes its mobile access
gateway. Any information carried in DHCP options such as addresses
of domain name server, time server, lpr server, etc. MUST be
configured in all the DHCP server located at mobile access gateways
if necessary.
MN MAG(DHCP-S) LMA The IPv4 home address mobility support essentially enables a mobile
|------>| | 1. DHCP discovery node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
| |------->| 2. Proxy Binding Update * configuration for its attached interface and be able to retain that
| |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) address configuration even after changing its point of attachment in
| |========| 4. Tunnel/Route Setup* that Proxy Mobile IPv6 domain. This section describes the protocol
|<------| | 5. DHCP offer (IPv4 HoA) operation and the required extensions to Proxy Mobile IPv6 protocol
|------>| | 6. DHCP request (IPv4 HoA) for supporting IPv4 home address mobility support.
|<------| | 7. DHCP acknowledgement
| | |
* DHCP discovery (no.1) and PBU (no.2) are operated in parallel.
* Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
are processed in parallel.
Figure 2: An example when LMA assigns an IPv4 home address 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
network 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 support. Upon the completion of the
signaling the local mobility anchor and the mobile access gateway
will have the required states for allowing the mobile node to use its
IPv4 home address(es) from the current point of attachment.
In the second scenario, a DHCP relay is co-located at each mobile The mobile node on the access link using any of the standard IPv4
access gateway and a DHCP server is co-located at a local mobility address configuration mechanisms supported on that access link, such
anchor. A mobile access gateway sends a proxy binding update and as IPCP [RFC-1332], IKEv2 [RFC-4306] or using DHCP [RFC-2131], will
retrieves an IPv4 home address for the mobile node from the local be able to obtain one or more IPv4 home addresses (IPv4-MN-HoA) for
mobility anchor as described in the first scenario. When the mobile the attached interface. Although the address configuration protocol
access gateway relays DHCP messages to the DHCP server, it includes mechanisms for delivering the address configuration to the mobile
the assigned IPv4 home address information in the DHCP messages as a node is independent of the Proxy Mobile IPv6 protocol operation,
hint. The DHCP server SHOULD assign the address stored in the hint however there needs to be some interactions between these two
to the mobile node. Figure 3 are the sequence of IPv4 home address protocol flows. Section 3.4 identifies these interactions for
assignment using DHCP Relay. The DHCP discovery message is sent by a supporting DHCP based address configuration.
mobile node at any time, but the DHCP relay SHOULD NOT relay the DHCP
discovery message before it learns the IPv4 home address hint during
the proxy binding registration. As shown in Figure 3, the DHCP
messages MAY be sent across an administrative boundaries. The
operators MUST ensure to secure these messages. More remarks can be
found in Section 6. The DHCP server identifier remains the same all
the time, because the server is uniquely located at the local
mobility anchor.
MN MAG(DHCP-R) LMA(DHCP-S) The support for IPv4 home address mobility is not dependent on the
| |------->| 1. Proxy Binding Update * IPv6 home address support. The mobile node is not required to have
| |<-------| 2. Proxy Binding Acknowledgement (IPv4HoA) an IPv6 home address for obtaining IPv4 home address mobility. A
| |========| 3. Tunnel/Route Setup* mobile node will be able to obtain just IPv4 address configuration or
|------>|------->| 4. DHCP discovery (IPv4HoA) via DHCP-R both IPv4 and IPv6 address configuration on its attached interface.
|<------|<-------| 5. DHCP offer (IPv4 HoA) via DHCP-R The mobile node's policy profile will determine if the mobile node is
|------>|------->| 6. DHCP request (IPv4 HoA) via DHCP-R entitled for both the protocols or a single protocol and based on
|<------|<-------| 7. DHCP acknowledgement via DHCP-R what is enabled, only those protocols will be enabled on the access
| | | link. Further, if the mobile node after obtaining the address
* Tunnel/Route setup(no.3) and DHCP offer/request/ack(no.4-7) configuration on its interface performs an handoff, either by
are processed in parallel. 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.
Figure 3: The use of DHCP relay 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 one or more IPv4 home addresses 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.2. Mobile Access Gateway Considerations 3.1. Local Mobility Anchor Considerations
3.2.1. Extensions to Binding Update List Entry 3.1.1. Extensions to Binding Cache Entry
For supporting this feature, the conceptual Binding Update List entry For supporting this feature, the conceptual Binding Cache entry data
data structure needs to be extended with the following additional structure maintained by the local mobility anchor needs to be
fields. extended with the following additional parameters.
o The IPv4 home address of the attached mobile node. This is o List of IPv4 home addresses assigned to the mobile node's
acquired from the mobile node's local mobility anchor through the interface registered by the mobile access gateway. Each of these
received Proxy Binding Acknowledgment message. The IPv4 home IPv4 home address entries also include the corresponding prefix
address parameter also includes the corresponding subnet mask. length.
o The IPv4 default-router address of the mobile node. This is o The IPv4 default-router address assigned to the mobile node.
acquired from the mobile node's local mobility anchor through the
received Proxy Binding Acknowledgment messages.
3.2.2. Signaling Considerations 3.1.2. Signaling Considerations
All the considerations from Section 6.9 of [ID-PMIP6] apply here. 3.1.2.1. Processing Proxy Binding Updates
However, the following additional considerations MUST be applied.
Mobile Node Attachment and Initial Binding Registration: 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 one or more
IPv4 Home Address options, the following additional considerations
MUST be applied.
o After detecting a new mobile node on its access link, the mobile o If there is an IPv4 Home Address option present in the received
access gateway must identify the mobile node and acquire its MN- Proxy Binding Update message, but if there is no Home Network
Identifier. If it determines that the IPv4 home address mobility Prefix option present in the request, the local mobility anchor
service needs to be offered to the mobile node [RYUJI by checking MUST NOT reject the request as specified in Section 5.3.1 of [RFC-
the policy profile], it MUST send a Proxy Binding Update message 5213]. At least one instance of any of these two options MUST be
for the IPv4 home address to the local mobility anchor. The present. However, if not a single instance of any of these
message MUST include the IPv4 Home Address option, defined in options are not present, the local mobility anchor MUST reject the
section 3.1.1 of [ID-DSMIP6]. The mobile access gateway MAY also request and send a Proxy Binding Acknowledgement message with
include the IPv6 Home Network Prefix option in the same message Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing
for requesting IPv6 home address support in addition to IPv4 home mobile node's home network prefix option).
address support for the mobile node. [RYUJI The mobile access
gateway contain either an IPv4 Home Address Option or a Home
Network Prefix option, or both, depending on the mobile node's
type.]
o If the mobile access gateway learns the mobile node's IPv4 home o For performing the Binding Cache entry existence test, the
network prefix or the IPv4 home address either from its policy following considerations MUST be applied:
store or from the DHCP messages exchanged between the mobile node
and the DHCP server, the mobile access gateway can specify the
same in the IPv4 Home Address option for requesting the local
mobility anchor to allocate that address or to allocate an address
from the specified home network prefix. If the specified value is
0.0.0.0, then the local mobility anchor will consider this as a
request for dynamic address allocation.
o The mobile access gateway on the access link where mobile node is * If there is at least one Home Network Prefix option with a
attached, will register this address with the local mobility NON_ZERO prefix value, or, if there is no IPv4 Home Address
anchor using the IPv4 Home Address option, defined in Section option with a NON_ZERO IPv4 address, considerations from
3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a Section 5.4 of [RFC-5213] MUST be applied.
proxy binding update message. The format of the proxy binding
update is slightly different from the one of [ID-DSMIP6]. In [ID-
DSMIP6], the source address of IPv6 header must be a home address
of the mobile terminal. However, since Proxy Mobile IPv6 supports
also IPv4-only nodes, IPv6 home address is not always available on
the terminal. In addition to this, the originator of this proxy
binding update is not the mobile terminal, but the mobile access
gateway. The mobile access gateway cannot send the proxy binding
update with the mobile node's home address because of security
reasons (IPsec and ingress filtering). Therefore, in this
specification, the mobile access gateway's care-of address (Proxy-
CoA) is used in the IPv6 source address field.
o The proxy binding update MUST be protected by IPsec ESP. * If there is at least one IPv4 Home Address option present in
the request with a NON_ZERO IPv4 address value, considerations
from Section 3.2.2.7 MUST be applied.
Receiving Binding Acknowledgement Message: 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.2.2.2 MUST be applied.
o If the received Proxy Binding Acknowledgement message has neither o If there exists a Binding Cache entry that can be associated with
an IPv4 Address Acknowledgement option or a Home Network Prefix the request, the local mobility anchor MUST apply considerations
option present, the mobile access gateway MUST ignore the Proxy from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
Binding Acknowledgement and MUST NOT enable routing for the mobile request is re-registration request or a de-registration request
node's IPv4 Home Address or IPv6 home address traffic. However, and the respective considerations from below MUST be applied.
if there is an IPv4 Home Address Acknowledgment option present in
the reply, the option MUST be processed as per the rules specified
in Dual Stack Mobile IPv6 specification [ID-DSMIP6].
o If the received Proxy Binding Acknowledgement message has the 3.1.2.2. Initial Binding Registration (New Mobility Session)
Status field value in the IPv4 Address Acknowledgement Option set
to a value that indicates that the request was rejected by the
local mobility anchor, the mobile access gateway MUST NOT enable
IPv4 support for the mobile node. However, if there is an IPv6
Home Network Prefix option in the Proxy Binding Acknowledgement
message and the Status field in the message is set to a value 0
(Proxy Binding Update accepted), the mobile access gateway MUST
enable IPv6 support for the mobile node.
o If the received Proxy Binding Acknowledgement message has the o If there is at least one IPv4 Home Address option present in the
Status field value set to 0 (Proxy Binding Update accepted), the Proxy Binding Update message with the IPv4 address value set to
mobile access gateway MUST update a Binding Update List entry and ALL_ZERO, the local mobility anchor MUST allocate one or more IPv4
must setup a tunnel to the local mobility anchor and must also add home addresses to the mobile node and associate them to the new
a default route over the tunnel for all the mobile node's IPv4 mobility session created for that mobile node. The decision on
traffic. The encapsulation mode for the bi-directional tunnel set how many IPv4 home addresses to be allocated can be based on a
to IPv4-In-IPv6 mode. The considerations from Section 6.10 [ID- domain-wide policy or a policy specific to that mobile node.
PMIP6] apply.
Extending Binding Lifetime: o If there are one or more IPv4 Home Address options present in the
received Proxy Binding Update message (with the IPv4 address field
in the option set to a NON_ZERO value), the local mobility anchor
before accepting the request, MUST ensure the address is owned by
the local mobility anchor and further the mobile node is
authorized to use that address. If the mobile node is not
authorized for a specific address, the local mobility anchor MUST
reject the request and send a Proxy Binding Acknowledgement
message with Status field set to
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
for the requesting IPv4 Home Address). It MUST also set the
status field value in the corresponding IPv4 Address
Acknowledgement option [ID-DSMIP6] to 129 (Administratively
prohibited).
o For extending the binding lifetime of a currently registered o If the local mobility anchor is unable to allocate an IPv4 address
mobile node , the mobile access gateway MUST send a Proxy Binding due to lack of resources, it MUST reject the request and send a
Update message to the local mobility anchor with a non zero Proxy Binding Acknowledgement message with Status field set to 130
lifetime value. The message MUST contain the IPv4 Home Address (Insufficient resources). It MUST also set the status field value
option with the value set to the currently registered IPv4 home in the corresponding IPv4 Address Acknowledgement option [ID-
address value. Additionally, if there is a registered IPv6 home DSMIP6], to 128 (Failure, reason unspecified).
network prefix for the mobile node for the connected interface on
that access link, both the options, Home Network Prefix option and
the IPv4 Home Address option MUST be present and with the values
set to the respective registered values.
Mobile Node Detachment and Binding De-Registration: 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,
there should still be only one Binding Cache entry that should be
created for this mobility session. The created Binding Cache
entry MUST be used for managing both IPv4 and IPv6 home address
bindings. The fields in the Binding Cache entry MUST be updated
with the accepted values for that binding.
o As specified in Section 6.9.1 [ID-PMIP6], at any point in time, o The local mobility anchor MUST establish a bi-directional tunnel
when the mobile access gateway detects that the mobile node has to the mobile access gateway and with the encapsulation mode as
moved away from its access link, it SHOULD send a Proxy Binding negotiated. When using IPv6 transport, the encapsulation mode is
Update message to the local mobility anchor with the lifetime IPv4 over IPv6.
value set to zero. The message MUST contain the IPv4 Home Address
option with the value set to the currently registered IPv4 home
address value. Additionally, if there is a registered IPv6 home
network prefix for the mobile node for the connected interface on
that access link, both the options, Home Network Prefix option and
the IPv4 Home Address option MUST be present and with the values
set to the respective registered values.
Constructing the Proxy Binding Update Message: o The local mobility anchor MUST create IPv4 host route(s) for
tunneling the packets received for any of the mobile node's home
address(es) associated with this mobility session.
The mobile access gateway when sending the Proxy Binding Update o The local mobility anchor MUST send the Proxy Binding
request to the local mobility anchor for requesting IPv4 home address Acknowledgement message with the Status field set to 0 (Proxy
mobility support MUST construct the message with the following Binding Update Accepted). The message MUST be constructed as
considerations. specified in Section 3.1.2.6.
o The message MUST be constructed as specified in Section 6.9 of 3.1.2.3. Binding Lifetime Extension (No handoff)
[ID-PMIP6]. However, when sending the messages over IPv4
transport, additional considerations from Section 4.0 MUST be All the consideration from Section 5.3.2 of [RFC-5213] MUST be
applied. applied.
o The IPv4 Home Address option [ID-DSMIP6] MUST be present. The 3.1.2.4. Binding Lifetime Extension (After handoff)
address value MAY be set 0.0.0.0 or to a specific value.
DHCP Messages from the mobile node: o The local mobility anchor MUST remove the previously created host
route(s), towards the mobile access gateway where the mobile node
was anchored prior to the handoff.
The operations of DHCP are almost same for both scenarios listed in o The local mobility anchor MUST create a host route(s) for
Section 3.1. There is one special operation for address renewing tunneling the packets received for any of the mobile node's home
operation when a mobile access gateway is the DHCP server. address(es) associated with this mobility session.
o When a mobile node attached to an access link and attempts to o The required forwarding state identified in Section 5.3.6 of [RFC-
obtain an IPv4 address configuration, using DHCP or other 5213] is for IPv6 payload traffic. Those considerations apply for
procedures, it will get an IPv4 address as an IPv4 home address IPv4 payload traffic as well. However, if IPv4 transport is in
from its home subnet as discussed in Section 3.1. The mobile use, considerations from Section 4.0 MUST be applied.
access gateway on the access link where mobile node is attached,
will register the IPv4 home address with the local mobility anchor
using the IPv4 Home Address option, defined in Section 3.1.1 of
[ID-DSMIP6]. The IPv4 Home Address option is sent with a proxy
binding update.
o When a mobile node attempts to obtain an IPv4 home address by 3.1.2.5. Binding De-Registration
using DHCP, the mobile access gateway SHOULD complete the proxy
binding registration before starting any DHCP operation. This is
necessary for the mobile access gateway to obtain all the
information required for DHCP operation from the local mobility
anchor.
o The mobile access gateway SHOULD send a proxy binding update with All the consideration from Section 5.3.5 of [RFC-5213] MUST be
0.0.0.0 in the the IPv4 Home Address field of the IPv4 home applied. Additionally, for removing the routing state as part of the
address option [ID-DSMIP6] and retrieve the assigned IPv4 home Binding Cache entry deletion, any IPv4 host route(s) added for this
address from the local mobility anchor. The IPv4 home address mobility session MUST be removed.
assigned by the local mobility anchor is offered to the mobile
node by DHCP.
o When a mobile node changes its attached mobile access gateway, the 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message
new mobile access gateway MUST sends a proxy binding update with
the IPv4 home address option. If the new mobile access gateway
know the assigned IPv4 home address, for example by context
transfer mechanism or policy profile, it SHOULD include the
address in the IPv4 Home Address field. Otherwise, it uses
0.0.0.0 and obtains the assigned IPv4 home address of the mobile
node from the local mobility anchor, again.
o Except for the mobile node's bootstrap, DHCP runs independently to The local mobility anchor when sending the Proxy Binding
the proxy binding registration, for instance, for renewing the Acknowledgement message to the mobile access gateway MUST construct
assigned IPv4 home address. It is not necessary to run DHCP the message as specified in Section 5.3.6 of [RFC-5213].
whenever a mobile node changes its attached mobile access gateway. Additionally, the following considerations MUST be applied.
A DHCP client renew the address according to the address lifetime,
etc. However, whenever a mobile node renews the IPv4 home address
by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access
gateway SHOULD send a proxy binding update to the local mobility
anchor regardless of the mobile node's assigned address changes.
o When a mobile node gets IPv4 home address from Local Mobility o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
Anchor through DHCP interaction with mobile access gateway that include at least one instance of Home Network Prefix option in the
supports DHCP server functionality, the DHCP client in the mobile Proxy Binding Acknowledgement message that it sends to the mobile
node recognizes mobile access gateway's IP address as DHCP access gateway. However, if the received Proxy Binding Update
server's IP address. Thus, the DHCP client unicasts DHCP renew to message has only the IPv4 Home Address option and did not contain
the mobile access gateway, when the DHCP client goes into the DHCP the Home Network Prefix option(s), then the local mobility anchor
RENEWING state [RFC-2131]. However, when the mobile node MUST NOT include the Home Network Prefix option in the reply.
handovers to a new mobile access gateway, the mobile node does not
know the link change and the DHCP client would unicast DHCP
request to the previous mobile access gateway whose IP address was
acquired from DHCP offer. The DHCP client in the mobile node
needs to reconfigure its local configuration parameters. The
mobile access gateway SHOULD discard any DHCP request message that
does not belong to the mobile access gateway itself, so that the
mobile node should go into the DHCP REBINDING state and broadcast
DHCP discovery message without server identifier.
3.3. Local Mobility Anchor Considerations o The IPv4 Address Acknowledgement option(s) MUST be present in the
Proxy Binding Acknowledgement message.
3.3.1. Extensions to Binding Cache Entry 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 for each of the
IPv4 Home Address options present in the request and with the
address value and the prefix length in the option set to the
values present in the corresponding request option. The
status field value in the option must be set to the specific
error code.
For supporting this feature, the conceptual Binding Cache entry data 2. For all other cases, there MUST be an IPv4 Address
structure needs to be extended with the following additional Acknowledgement option for each of the assigned IPv4 home
parameter, as specified in [ID-DSMIP6] specification and is presented addresses assigned for that mobility session and with the
here for convenience. value in the option set to the allocated address value. 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 home address of the registered mobile node. The IPv4 o The IPv4 Default-Router Address option MUST be present, if the
home address value may have been statically configured in the Status field value in the Proxy Binding Acknowledgement message is
mobile node's policy profile, it MAY have been assigned by a DHCP set to 0 (Proxy Binding Update Accepted). Otherwise, the option
server, or it MAY have been dynamically allocated by the local MUST NOT be present. If the option is present, the default-router
mobility anchor. address in the option MUST be set to the mobile node's default-
router address.
3.3.2. Signaling Considerations 3.1.2.7. Binding Cache Entry Lookup Considerations
All the considerations explained in Section 5.3 [ID-PMIP6] apply The Binding Cache entry lookup considerations specified in Section
here. For supporting IPv4 home address mobility feature, the 5.4.1.1 of [RFC-5213] is for using the Home Network Prefix as the key
following additional considerations MUST be applied. 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.
Processing Binding Registrations: 3.1.3. Routing Considerations for the Local Mobility Anchor
o If there is an IPv4 Home Address option present in the request, Intercepting Packets Sent to the Mobile Node's IPv4 home address:
but if there is no Home Network Prefix option present in the
request, the local mobility anchor MUST NOT reject the request as
specified in [ID-PMIP6]. At least one of these two options MUST
be present. However, if both the options are not present, 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).
o The local mobility anchor MUST use the identifier from the Mobile o When the local mobility anchor is serving a mobile node, it MUST
Node Identifier Option [RFC-4283] present in the Proxy Binding be able to receive packets that are sent to any of the mobile
Update request and MUST apply multihoming considerations specified node's IPv4 addresses. In order for it to receive those packets,
in Section 5.4 [ID-PMIP6] and from this section for performing the it MUST advertise a connected route in to the Routing
Binding Cache entry existence test. 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.
o If there is no existing Binding Cache entry that matches the Forwarding Packets to the Mobile Node:
request, the local mobility anchor MUST consider this request as
an initial binding registration request. If the entry exists, the
local mobility anchor MUST consider this request as a binding re-
registration request.
o The proxy care-of address MUST be retrieved from the source o On receiving a packet from a correspondent node with the
address field of the proxy binding update message. destination address matching a 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 If the IPv4 Home Address option present in the Proxy Binding o The format of the tunneled packet when payload protection is not
Update request has the value of 0.0.0.0, the local mobility anchor enabled:
MUST allocate an IPv4 home address for the mobile node and send a
Proxy Binding Acknowledgement message and including the IPv4
Address Acknowledgement option, defined in Section 3.2.1 of [ID-
DSMIP6], containing the allocated address value. The specific
details on how the local mobility anchor allocates the home
address is outside the scope of this document. The local mobility
anchor MUST ensure the allocated prefix is not in use by any other
mobile node.
o If the local mobility anchor is unable to allocate an IPv4 home IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
address for the mobile node, it MUST reject the request and send a IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Proxy Binding Acknowledgement message with Status field set to 130 Upper layer protocols /* Packet Content*/
(Insufficient resources).
o Upon accepting the request, the local mobility anchor MUST create Figure 2: Tunneled Packets from LMA to MAG
a Binding Cache entry for the mobile node. It must set the fields
in the Binding Cache entry to the accepted values for that
binding. It MUST also establish a bi-directional tunnel to the
mobile access gateway, as described in [RFC-2473]. Considerations
from Section 5.6 [ID-PMIP6] MUST be applied. The local mobility
anchor MUST add an IPv4 host route for that allocated IPv4 home
address over the tunnel to the mobile access gateway.
Multihoming Considerations: Forwarding Packets Sent by the Mobile Node:
o The multihoming considerations specified in Section 5.4 [ID-PMIP6] o All the reverse tunneled packets that the local mobility anchor
allows the local mobility anchor to perform the Binding Cache receives from the mobile access gateway, after removing the tunnel
entry existence test for identifying the mobility session, by header MUST be routed to the destination specified in the inner
using the mobile node identifier, interface identifier and the IPv4 packet header. These routed packets will have the source
Home Network Prefix values. When using an IPv4 home address address field set to the mobile node's IPv4 home address.
value, instead of the IPv6 home network prefix for matching the
Binding Cache entry, all those considerations equally apply for
the IPv4 home address as well.
o If there is an Home Network Prefix option present in the Proxy 3.2. Mobile Access Gateway Considerations
Binding Update request and with a NON_ZERO value, the local
mobility anchor MUST use this parameter in combination with the
mobile node identifier and interface identifier for matching the
Binding Cache entry, just as specified in Section 5.4 [ID-PMIP6].
For all other cases, the local mobility anchor MUST use the IPv4
home address parameter in combination with the mobile node
identifier and interface identifier for matching the Binding Cache
entry, as specified in Section 5.4 [ID-PMIP6].
Constructing the Proxy Binding Acknowledgement Message: 3.2.1. Extensions to Binding Update List Entry
o The local mobility anchor when sending the Proxy Binding For supporting the IPv4 home address mobility feature, the conceptual
Acknowledgement message to the mobile access gateway MUST Binding Update List entry data structure needs to be extended with
construct the message as specified in Proxy Mobile IPv6 base the following additional fields.
specification [ID-PMIP6]. However, the following considerations
MUST be applied.
o The IPv4 Address Acknowledgement option MUST be present in the o List of IPv4 home addresses assigned to the mobile node's attached
Proxy Binding Acknowledgement message. interface. These IPv4 home addresses may have been statically
configured in the mobile node's policy profile, or, may have been
dynamically allocated by the local mobility anchor through the
received Proxy Binding Acknowledgement message. Each of these
IPv4 home address entries also includes the corresponding subnet-
mask.
1. If the Status field is set to a value greater than or equal to o The IPv4 default-router address of the mobile node. This is
128, i.e., if the binding request is rejected, then the IPv4 acquired from the mobile node's local mobility anchor through the
home address value in the IPv4 Address Acknowledgement option received Proxy Binding Acknowledgment message.
MUST be set to ALL_ZERO value.
2. For all other cases, the IPv4 home address value in the IPv4 3.2.2. Extensions to Mobile Node's Policy Profile
Address Acknowledgement option MUST be set to the allocated
IPv4 home address value for that mobility session.
3.3.3. Routing Considerations For supporting this feature the mobile node's policy profile,
specified in Section 6.2 of [RFC-5213] MUST be extended with the
following additional fields.
Forwarding Considerations for the mobile node's IPv4 home address Extensions to the mandatory section of the policy profile:
traffic.
Intercepting Packets Sent to the Mobile Node's IPv4 home network: o This field indicates the scope of IP address mobility support that
needs to be extended for the mobile node. If the mobile access
gateway should enable support for IPv4, IPv6 or IPv4/IPv6 home
address mobility support.
o When the local mobility anchor is serving a mobile node, it MUST Extensions to the optional section of the policy profile:
be able to receive packets that are sent to the mobile node's IPv4
network. 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 network prefix or for an aggregated
prefix with a larger scope. This essentially enables IPv4 routers
in that network to detect the local mobility anchor as the last-
hop router for that IPv4 prefix.
Forwarding Packets to the Mobile Node: o The IPv4 home addresses assigned to the mobile node's attached
interface. These addresses have to be maintained on a per-
interface basis. The specific details on how the network
maintains the association between the addresses and the interfaces
is outside the scope of this document. These address entries also
include the corresponding prefix length.
o On receiving a packet from a correspondent node with the 3.2.3. Signaling Considerations
destination address matching a mobile node's IPv4 home address,
the local mobility anchor MUST forward the packet through the bi-
directional tunnel setup for that mobile node. The format of the
tunneled packet is shown below.
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 3.2.3.1. Mobile Node Attachment and Initial Binding Registration
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 4: Tunneled Packets from LMA to MAG 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 specifies if IPv4-only, IPv6-only or
IPv4/IPv6 home address mobility service needs to be enabled for that
mobile node. Based on those policy considerations, if it is
determined that IPv4 home address mobility support is required to be
enabled for the mobile node, the considerations from section 6.9.1.1
of [RFC-5213] MUST be applied with the following exceptions.
Forwarding Packets Sent by the Mobile Node: o The IPv4 Home Address option(s) MUST be present in the Proxy
Binding Update request.
o All the reverse tunneled packets that the local mobility anchor * If the mobile access gateway learns the mobile node's IPv4 home
receives from the mobile access gateway, after removing the tunnel address(es) either from its policy profile, or from other means
header MUST be routed to the destination specified in the inner the mobile access gateway MAY choose to request the local
IPv4 packet header. These routed packets will have the source mobility anchor to allocate the requested addresses by
address field set to the mobile node's IPv4 home address. including an IPv4 Home Address option for each of those
addresses. The IPv4 address and the prefix length fields in
the option MUST be set to that specific address and its prefix
length. The (P) flag in the option MUST be set to 0.
3.4. Mobility Options * The mobile access gateway MAY also choose to request the local
mobility anchor for dynamic home address allocation. It can
include exactly one instance of the IPv4 home address option
with the IPv4 address value, prefix length fields and (P) flag
in the option set to a ALL_ZERO value. 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. However, the Home Network Prefix option(s)
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.
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_SUPPORT (The mobile node is
not authorized for IPv4 home address support), the mobile access
gateway SHOULD NOT send a Proxy Binding Update message including
the IPv4 Home Address option(s) till an administrative action is
taken.
o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_REQ_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 if
IPv4 Home Address option with the address value set to ALL_ZERO.
o If there is no IPv4 Address Acknowledgement option present in the
received Proxy Binding Acknowledgement message, the mobile access
gateway MUST NOT enable IPv4 support for the mobile node and the
rest of the considerations from this section can be skipped.
o If the received Proxy Binding Acknowledgement message has the
Status field value in the IPv4 Address Acknowledgement Option 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(es).
o The bi-directional established with the local mobility anchor with
IPv4 or IPv6 transport and using any of the supported
encapsulation mode, as per [RFC-5213] or as per this specification
when using IPv4 transport, MUST be enabled to carry IPv4 traffic.
o The mobile access gateway MUST set up the route for forwarding the
IPv4 packets received from the mobile node through the bi-
directional tunnel set up for that 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. However,
the following additional considerations MUST be applied.
o There MUST be an IPv4 Home Address option for each of the assigned
IPv4 home address(es) for that mobility session. The IPv4 address
and the prefix length fields in the option MUST be set to that
specific address and its prefix length. The (P) flag in the
option MUST be set to 0.
o The Home Network Prefix option(s) 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.
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.
3.3. Mobility Options and Status Codes
For supporting IPv4 home address mobility feature, this specification For supporting IPv4 home address mobility feature, this specification
defines the following new option. defines the following new options and Status Codes.
3.4.1. IPv4 Default Router Address Option 3.3.1. IPv4 Default-Router Address Option
A new option, IPv4 Default Router Address Option is defined for using A new option, IPv4 Default-Router Address Option is defined for using
it in the Proxy Binding Acknowledgment message sent by the local it in the Proxy Binding Acknowledgment message sent by the local
mobility anchor to the mobile access gateway. This option can be mobility anchor to the mobile access gateway. This option can be
used for sending the mobile node's IPv4 default router address. used for sending the mobile node's IPv4 default-router address.
The IPv4 Default Router Address option has an alignment requirement The IPv4 Default-Router Address option has an alignment requirement
of 4n. Its format is as follows: of 4n. Its format is as follows:
0 1 2 3 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 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) | | Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default Router Address | | IPv4 Default Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 44 skipping to change at page 20, line 31
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST octets, excluding the type and length fields. This field MUST
be set to 6. be set to 6.
Reserved (R) Reserved (R)
This 8-bit field is unused for now. The value MUST be This 8-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the initialized to 0 by the sender and MUST be ignored by the
receiver. receiver.
IPv4 Default Router Address IPv4 Default-Router Address
A four-byte field containing the mobile node's default router A four-byte field containing the mobile node's default router
address. address.
Figure 5: IPv4 Default Router Address Option Figure 3: IPv4 Default-Router Address Option
3.3.2. Status Codes
This document defines the following new Status values for use in the
Proxy Binding Acknowledgement message. These values are to be
allocated from the same numbering space, as defined in Section 6.1.8
of [RFC-3775].
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address
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 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 can be a virtual address used only for the DHCP
protocol communication on any of the access links. This address
will be the server identifier in the DHCP messages.
o The DHCP server identifies the a DHCP client either from the
client identifier or the client hardware address (chaddr). 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 in the mobile node is configured
to use a stable client identifier that does not change during the
active life of that DHCP session.
o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain SHOULD be configured with the same set
of DHCP option values (Ex: DNS Server, SIP Server ..etc.).
3.4.1. DHCP Server co-located with the Mobile Access Gateway
Figure 4 shows the operational sequence of the home address
assignment when a DHCP server is co-located with the mobile access
gateways.
MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVERY
| |------->| 2. Proxy Binding Update *
| |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA)
| |========| 4. Tunnel/Route Setup*
|<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK
| | |
* DHCP discovery (no.1) and PBU (no.2) are operated in parallel.
* Tunnel/Route setup(no.4) and DHCPOFFER/REQUEST/ACK(no.5-7)
are processed in parallel.
Figure 4: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment:
o If the mobile node attached to the access link sends a
DHCPDISCOVERY message, 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 tear down the point-to-point
link shared with the mobile node.
o After a successful completion of the Proxy Mobile IPv6 signaling
and acquiring the mobile node's IPv4 home address assigned by the
local mobility anchor, the DHCP server on the mobile access
gateway will send a DHCP offer message to the mobile node. The
offered address will the mobile node's IPv4 home address, assigned
by the local mobility anchor. The 'siaddr' field of the DHCPOFFER
message will be set to the mobile node's default-router address or
to the globally fixed address used for all DHCP servers. 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 When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
it simply unicasts DHCPREQUEST message including the assigned IPv4
home address in the 'requested IPv4 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.
IPv4 Home Address Renewal with the different DHCP server (After
Handoff):
1. The use of Virtual DHCP server address
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK or DHCPNACK
| : |
2. The use of FORCERENEW [RFC3-203]
MN oMAG(DHCP-S) nMAG(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
3. The use of Individual DHCP server address
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
| : | (discarding & timeout)
REBINDING--------->| 2. DHCPDISCOVERY
|<---------------| 3. DHCPOFFER (IPv4 HoA)
|--------------->| 4. DHCPREQUEST(IPv4 HoA)
BOUND<-------------| 5. DHCPACK (IPv4 HoA)
| : |
Figure 5: Renewing Address to different DHCP server
o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
it directly unicasts DHCPREQUEST message to the DHCP server. If
the mobile node moves and attaches to a new mobile access gateway,
it needs to update the DHCP server address to the new one (i.e.
the address of the currently attached mobile access gateway).
Thus, one of following operations is required.
o If the IPv4 virtual DHCP address is used, the DHCPREQUEST for
renewing address is received by the mobile access gateway to which
the mobile node is currently attached. The mobile access gateway
SHOULD reply DHCPACK or DHCPNACK depending on the correctness of
the requesting IPv4 home address in the DHCPREQUEST as shown in
Figure 5-1).
o If the IPv4 virtual DHCP address is not used, the mobile node
reconfigures the DHCP server address whenever it changes the
attached mobile access gateway.
* If a mobile access gateway receives any DHCP messages unicasted
to a different mobile access gateway from the mobile node, it
SHOULD unicast FORCERENEW message [RFC-3203] to the mobile node
as shown in Figure 5-2). In the FORCERENEW, the 'server
identifier' field MUST be overwritten by the IPv4 address of
the current mobile access gateway so that the client can update
the DHCP server address.
* If the IPv4 virtual DHCP address is not used and the FORCERENEW
[RFC-3203] is not supported at the mobile access gateway, the
mobile access gateway SHOULD discard any DHCPREQUEST message
sent not to the mobile access gateway itself, so that the
mobile node should go into the DHCP-REBINDING-STATE and
broadcast DHCPDISCOVERY without server identifier as shown in
Figure 5-3).
Additional Operation:
o At an point the mobile access gateway fails to extend the binding
lifetime with the local mobility anchor, it MUST send an
unsolicited DHCPNACK to the mobile node. It MUST also tear down
the point-to-point link shared with the mobile node.
3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway
A DHCP relay is co-located with each mobile access gateway. A DHCP
server is located somewhere in the Proxy Mobile IPv6 domain or is co-
located with the local mobility anchor. Figure 6 are 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. DHCPDISCOVERY (IPv4HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK via DHCP-R
| | |
* Tunnel/Route setup(no.3) and DHCPOFFER/REQUEST/ACK (no.4-7)
are processed in parallel.
Figure 6: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment:
o When the mobile access gateway receives a DHCPDISCOVERY message
from a mobile node, it MUST check whether it has already obtained
the IPv4 home address for the mobile node from the local mobility
anchor.
o If the IPv4 home address is not yet assigned by the local mobility
anchor, the mobile access gateway MUST send a Proxy Binding Update
for that.
o If the IPv4 home address is not assigned to the mobile node by the
local mobility anchor due to administrative policy or resource
limitation, it MUST discard the DHCPDISCOVERY messages from the
mobile node.
o Otherwise, it MUST add the DHCP relay agent information option
[RFC-3046] to the DHCPDISCOVERY message. The assigned IPv4 home
address (32-bit full address) is included in the Agent Remote ID
Sub-option of the DHCP relay agent information option. This sub-
option is used as a hint of address assignment of the DHCP server.
o When the mobile access gateway receives the DHCPOFFER from the
DHCP server, it MUST verify whether the DHCP server offers the
correct IPv4 home address which is indicated in the Agent Remote
ID Sub-option of the DHCPDISOCVERY. If the DHCP server offers the
different address from the expected address, the mobile access
gateway MUST drop the DHCPOFFER.
o After the successful relaying the DHCPOFFER, the mobile access
gateway acts as a regular DHCP relay agent as [RFC-2131].
o As shown in Figure 6, the DHCP messages MAY be sent across an
administrative boundaries. The operators MUST ensure to secure
these messages. All the DHCP messages relayed by the mobile
access gateway can be tunneled over the local mobility anchor if
needed. Alternatively, if the networks in the Proxy Mobile IPv6
domain are secured enough, the mobile access gateway just relays
the DHCP messages to the server without the tunnel. For doing
this, all the mobile access gateway MUST have the route toward the
DHCP server. More remarks can be found in Section 7.
IPv4 Home Address Renewal to the same DHCP server: (No Hanover)
o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
it directly unicasts DHCPREQUEST message to the DHCP server. The
DHCP relay agent cannot receive the DHCPREQUEST for renewing
addresses. Thus, one of following operations is required.
* The DHCP relay agent SHOULD 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, it is possible to check the DHCP packets at the interface
by enabling the promiscuous mode.
* The cost of packets monitoring is not negligible. Therefore,
The DHCP relay agent MAY use the DHCP Server Identifier
Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for
the address renewal. 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 Override Sub-option is recommended only when the
Virtual DHCP 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. As a result, the DHCP relay agent MUST monitor DHCP
packets by force as described above.
o Once the DHCP relay agent intercepts the DHCPREQUEST from the
mobile node, it MUST verify the requesting IPv4 home address
stored in the DHCPREQUEST message. The verification is operated
by checking it with the binding update list for the mobile node.
If the requesting IPv4 home address is not registered to the local
mobility anchor, the mobile access gateway MUST NOT relay the
DHCPREQUEST and MUST discard it.
o If the address verification is successfully completed, the DHCP
relay agent SHOULD forward the DHCPREQUEST to the DHCP server.
Additional Operations:
o If the mobile access gateway sends Proxy Binding Update for the
IPv4 home address and receives the unsuccessful Proxy Binding
Acknowledgement (by indicating the error codes), it MUST send
unsolicited DHCPNACK for the invalid IPv4 home address to the
mobile node. XXXX
4. IPv4 Transport Support 4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [ID-PMIP6] requires the network The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling
between the local mobility anchor and the mobile access gateway to be messages exchanged between the local mobility anchor and the mobile
an IPv6 network and the signaling messages exchanged between the access gateway to be over an IPv6 transport. The extensions defined
local mobility anchor and the mobile access gateway to be over an in this section allow the exchange of signaling messages over an IPv4
IPv6 transport. The extensions defined in this section allow the transport when the local mobility anchor and the mobile access
exchange of signaling messages over an IPv4 transport when the local gateway are separated by an IPv4 network and are reachable using only
mobility anchor and the mobile access gateway are separated by an IPv4 addresses.
IPv4 network and are reachable using an IPv4 address.
IPv4-Proxy-CoA IPv4-LMAA IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + | | + - - - - - - + |
+--+ +---+ / \ +---+ +--+ +--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+ +--+ +---+ \ / +---+ +--+
+ - - - - - - + + - - - - - - +
Figure 6: IPv4 Transport Network Figure 7: IPv4 Transport Network
When the network between the local mobility anchor and the mobile
access gateway is an IPv4 network, i.e., when both these mobility
entities are configured and reachable using an IPv4 address, the
mobile access gateway serving a mobile node can potentially register
its IPv4 address with the local mobility anchor, as the care-of
address in the mobile node's Binding Cache entry and can negotiate
and IPv4 transport tunnel for tunneling the mobile node's data
traffic.
The Dual Stack Mobile IPv6 specification [ID-DSMIP6] defines protocol When the local mobility anchor and the mobile access gateway are
extensions to Mobile IPv6 protocol for allowing a mobile node to roam configured and reachable using only IPv4 addresses, the mobile access
into an IPv4 network and registers an IPv4 care-of address with the gateway serving a mobile node can potentially send the signaling
home agent. The same mechanism is leveraged for extending IPv4 messages over IPv4 transport and register its IPv4 address as the
transport support to Proxy Mobile IPv6 protocol. The mobility care-of address in the mobile node's Binding Cache entry. An IPv4
options for requesting IPv4 transport support, the processing logic tunnel (with any of the supported encapsulation modes) can be used
and the on-path NAT detection logic is just as described in [ID- for tunneling the mobile node's data traffic. The following are the
DSMIP6]. The following are the key properties of this feature. key aspects of this feature.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address. configured and reachable using only an IPv4 address.
Additionally, both these entities are also IPv6 enabled and have
configured IPv6 addresses on its interfaces, as specified in [RFC-
5213], but are reachable only over an IPv4 transport.
o The configured address on the mobile access gateway can be an IPv4 o The mobile access gateway can be potentially in a private IPv4
private address and when it is behind a NAT translation device and network behind a NAT [RFC-3022] device, with a private IPv4
the mechanism specified in Dual Stack Mobile IPv6 specification address configured on its egress interface. However, the local
[ID-DSMIP6] is again leveraged for NAT detection and traversal. mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address.
o The Proxy Mobile IPv6 signaling messages exchanged between the o The Proxy Mobile IPv6 signaling messages exchanged between the
local mobility anchor and the mobile access gateway for local mobility anchor and the mobile access gateway for
negotiating the IPv4 transport will be encapsulated and carried as negotiating the IPv4 transport will be encapsulated and carried as
IPv4 packets. However, these signaling messages are fundamentally IPv4 packets. However, these signaling messages are fundamentally
IPv6 messages with the mobility header and the semantics as IPv6 messages using the mobility header and the related semantics
specified in base Proxy Mobile IPv6 specification [ID-PMIP6], but as specified in base Proxy Mobile IPv6 specification [RFC-5213],
carried as payload in IPv4 packets. Additionally, the mobility but carried as a payload in an IPv4 packet (IPv4-UDP encapsulation
options defined in Dual Stack Mobile IPv6 specification [ID- mode).
DSMIP6] are used for negotiating IPv4 transport support and with a
specific encapsulation mode. 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 o The IPv4 tunnel established between the local mobility anchor and
the mobile access gateway (with any of the supported encapsulation the mobile access gateway (with any of the supported encapsulation
modes over IPv4 transport) is used for carrying the mobile node's modes over IPv4 transport) will be used for carrying the mobile
IPv4 and IPv6 traffic. The mobile node can be an IPv6, IPv4 or a node's IPv4 and IPv6 traffic. The supported encapsulation modes
dual IPv4/IPv6 node and the IPv4 transport support specified in for carrying mobile node's IPv4 or IPv6 packets when using IPv4
this section is agnostic to the type of address mobility enabled transport are as shown below.
for the mobile node.
4.1. NAT Support * IPv4
* 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
For supporting 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 The IPv4 address of the mobile access gateway. This is the
address configured on the egress interface of the mobile access
gateway that sent the Proxy Binding Update message. This address
can be obtained from the IPv4 Care-of Address option, present in
the received Proxy Binding Update message. If the option was not
present in the request, this field MUST be set to the source
address of 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.
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
For supporting this feature the mobile node's policy profile,
specified in Section 6.2 of [RFC-5213] MUST be extended with the
following additional fields. This are mandatory fields of the policy
profile required for supporting this feature.
o A flag indicating if IPv4 transport should be used. The value of
this flag can be different at different mobile access gateway.
The specific details on how this flag is maintained on a per
mobile access gateway basis is outside the scope of this document.
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. The local mobility
anchor MUST apply these signaling rules on the IPv4 UDP encapsulated
Proxy Binding Update messages received on DSMIP UDP port [ID-DSMIP6].
4.1.3.1. Processing Proxy Binding Updates
o If the received Proxy Binding Update message (encapsulated in IPv4
UDP packet) is protected using IPsec ESP header, then the message
MUST be authenticated as described in Section 4 of [RFC-5213].
However, if the IPv4 packet is not protected using IPsec ESP
header, then the message MUST be authenticated after removing the
outer IPv4 UDP header.
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 IPv4 UDP header.
o If there is an IPv4 Care-of Address present in the request, 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.
The encapsulation mode MUST be determined from the below
considerations.
* If the NAT is detected on the path, then the encapsulation mode
for the tunnel MUST be set to IPv4-UDP. Otherwise the
encapsulation mode MUST be set to IPv4. However, if the (F)
flag in the received Proxy Binding Update message is set to
value of 1 and even if NAT is not detected, then the
encapsulation mode MUST be set to IPv4-UDP.
* If the (T) flag 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 UDP
header of an IPv4 packet, the following additional considerations
MUST be applied.
o The NAT Detection option [ID-DSMIP6] MUST be present only if there
is a IPv4 Care-of Address option present in the received Proxy
Binding Update and if the NAT detection procedure resulted in
detecting a NAT on path. In all other cases, the option MUST NOT
be present.
o The Proxy Binding Acknowledgement message MUST be encapsulated in
an 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.
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 PBA) MUST be protected using
IPsec ESP [RFC-4301] mode and additionally there is no need to
apply IPsec ESP header on the IPv6 packet. In all other cases,
the Proxy Binding Acknowledgement message MUST be protected using
IPsec prior to the IPv4 UDP encapsulation.
o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 UDP packet and protected using IPv6
security association.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
UDP header (sport=DSMIP_PORT, dport= pbu_sport)
/* IPv6 PBU Packet protected with ESP header */
Figure 8: Proxy Binding Acknowledgment Message encapsulated in
IPv4 header
o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 UDP packet and protected using IPv4
security association.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
ESP Header
UDP header (sport=DSMIP_PORT, dport= pbu_sport)
/* IPv6 PBU Packet protected with no ESP header */
Figure 9: Proxy Binding Acknowledgment encapsulated in IPv4 ESP
header
4.1.3.3. NAT Presence Detection
When the transport network between the local mobility anchor and the When the transport network between the local mobility anchor and the
mobile access gateway is an IPv4 network, the mobile access gateway mobile access gateway is an IPv4 network, the mobile access gateway
MUST send Proxy Binding Update message encapsulated in the IPv4-UDP will send the Proxy Binding Update messages encapsulated in the IPv4-
packet. On receiving this Proxy Binding Update packet encapsulated UDP packet. On receiving this Proxy Binding Update packet
in an IPv4-UDP packet, the local mobility anchor if it detects a NAT encapsulated in an IPv4-UDP packet, the local mobility anchor if it
on the path, will send the Proxy Binding Acknowledgment message with detects a NAT on the path, will send the Proxy Binding Acknowledgment
the NAT Detection Option. The presence of this option in the Proxy message with the NAT Detection Option. The presence of this option
Binding Acknowledgment is an indication to the mobile access gateway in the Proxy Binding Acknowledgment is an indication to the mobile
about the presence of NAT in the path. On detecting the NAT in the access gateway about the presence of NAT in the path. On detecting
path, both the local mobility anchor and the mobile access gateway the NAT in the path, both the local mobility anchor and the mobile
MUST set the encapsulation mode of the tunnel to IPv4-UDP-based access gateway MUST set the encapsulation mode of the tunnel to IPv4-
encapsulation. The specific details around the NAT detection and the UDP-based encapsulation. The specific details around the NAT
related logic is described in in DSMIPv6 specification [ID-DSMIP6]. detection and the related logic is described in DSMIPv6 specification
[ID-DSMIP6].
There are discussions on how to incorporate the NAT detection 4.1.4. Routing Considerations
mechanism of IKE with DSMIPv6 in the MEXT Working Groups. This
documentation will follow the conclusion of their discussions.
[RYUJI Private addresses MUST NOT be configured at both mobile access 4.1.4.1. Forwarding Considerations
gateways and a local mobility anchor in the same Proxy Mobile IPv6
domain. At least one of Proxy Mobile IPv6's tunnel end points MUST
have a global address. Otherwise, the packets might not be exchanged
in the tunnel due to NAT.]
[RYUJI When a mobile access gateway is configured with an IPv4 Forwarding Packets to the Mobile Node:
private address, it MUST NOT operate the local routing (described in
Section 6.10.3 of [ID-PMIP6]) for packets destined to an IPv4 address
assigned to a correspondent node. The address translation MUST
happen before the packets are arrived at the correspondent node. To
ensure this, the packets MUST be sent to the local mobility anchor
and routed back to the correspondent node.]
4.2. Mobile Access Gateway Considerations 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.
4.2.1. Extensions to Binding Update List Entry o The format of the tunneled packet is shown below.
For supporting this feature, the conceptual Binding Update List entry IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */
data structure needs to be extended with the following additional [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */
parameters, as specified in [ID-DSMIP6] specification and is reviewed [TLV Header] /* If TLV negotiated */
here for convenience. /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA)
OR
IPv4 header (src= CN, dst= IPv4 MN-HoA)
o The IPv4 address registered with the local mobility anchor as the Figure 10: Tunneled IPv4 Packet from LMA to MAG
mobile node's care-of address.
4.2.2. Signaling Considerations o Forwarding Packets Sent by the Mobile Node:
All the considerations as explained in Section 6.11 of the base Proxy * All the reverse tunneled packets (IPv4 and IPv6) that the local
Mobile IPv6 specification apply here. mobility anchor receives from the mobile access gateway, after
removing the tunnel header (i.e., the outer IPv4 header along
with the UDP and TLV header, if negotiated) MUST be routed to
the destination specified in the inner packet header. These
routed packets will have the source address field set to the
mobile node's home address.
Network Configurations for IPv4 Transport Signaling Support: 4.1.4.2. ECN Considerations
o If IPv4 transport support is enabled in order to place a mobile The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply
access gateway at IPv4 only network, the mobile access gateway for the IPv4 transport tunnels as well. The mobility agents at the
MUST have an IPv4 address at the visiting network. In addition to tunnel entry and exit points MUST handle ECN information as specified
that, the mobile access gateway MUST obtain an IPv6 address in that document.
configured for the Proxy Mobile IPv6 operation. Even if the
mobile access gateway does not have connectivity to the IPv6
network, it MUST configure with an IPv6 address for sending the
proxy binding registration to the local mobility anchor.
Processing Binding Registrations: 4.1.4.3. Bi-Directional Tunnel Management
o As explained in the DSMIPv6 specification, the mobile access The Tunnel Management considerations specified in section 5.6.1 of
gateway can encapsulate a Proxy Binding Update message and carry [RFC-5213] apply for the IPv4 transport tunnels as well, with just
it in IPv4 and UDP packet. The processing logic for handling the one difference that the encapsulation mode is different.
NAT detection at the mobile node is applicable to the mobile
access gateway as described in Section 4.1.
o An example of proxy binding update sent by mobile access gateway 4.2. Mobile Access Gateway Considerations
is shown in Figure 7. The source address of the inner IPv6 header
MUST set to the IPv6 address assigned to the mobile access gateway
and the destination address MUST be the local mobility anchor's
IPv6 address (LMAA). This is slightly different from [ID-DSMIP6]
. The reason is already mentioned in Section 3.2.2.
o The source address of the outer packet MUST be the IPv4-Proxy-CoA 4.2.1. Extensions to Binding Update List Entry
and the destination MUST be the local mobility anchor's IPv4
address (IPv4-LMAA).
o The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option For supporting this feature, the conceptual Binding Update List entry
defined in section 3.1.2 of [ID-DSMIP6]. data structure maintained by the mobile access gateway [RFC-5213]
MUST be extended with the following additional parameters.
o For the NAT handling, the UDP-based encapsulation MUST be always o The IPv4 address of the local mobility anchor. This address can
used for the proxy binding update. The UDP port number is defined be obtained from the mobile node's policy profile.
in [ID-DSMIP6].
o If the mobile access gateway requested to use the TLV header for o The IPv4 address of the mobile access gateway. This is the
the UDP encapsulation, it MUST insert a TLV header after the UDP address configured on the egress interface of the mobile access
header and MUST set T flag in the proxy binding update message. gateway and is registered with the mobile node's local mobility
The format of the TLV header is defined in section 4.1 of [ID- anchor as the IPv4 Proxy-CoA. However, if the mobile access
DSMIP6]. 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.
o The proxy binding update MUST be protected by IPsec ESP. The 4.2.2. Signaling Considerations
security association for IPv4 addresses of the mobile access
gateway and local mobility anchor are pre-established.
Constructing the Proxy Binding Update Message: 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. However, if the mobile access gateway is in an
IPv4-only access network, the following additional considerations
MUST be applied.
o For requesting IPv4 transport support, the mobile access gateway o The Proxy Binding Update message MUST be encapsulated in an UDP
when sending the Proxy Binding Update request to the local header of an IPv4 packet.
mobility anchor from an IPv4 networks MUST construct the message
as specified below.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The
UDP header IPv4 address in the option MUST be set to the mobile access
IPv6 header (src=Proxy-CoA, dst=LMAA) gateway's IPv4-Proxy-CoA.
Mobility header
-BU (P flag is set. F/T flags are optional)
Mobility Options
- The IPv4 Care-of Address option(Mandatory)
-
- All the options as required by [ID-PMIP6]
- or as required by any extension documents
-
Figure 7: Proxy Binding Update Message Format for IPv4 Transport o The packet MUST be constructed as specified in Section 4.2.3.
Support
o
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o When sending a Proxy Binding message for extending the lifetime of
address value MUST be set to mobile access gateway's IPv4 address. a currently existing mobility session or for de-registering the
mobility session, the Proxy Binding Update message MUST be
constructed as the initial request.
o All the other fields and the options MUST be constructed, as Receiving Proxy Binding Acknowledgement
specified in [ID-PMIP6].
Receiving Binding Registration Reply: o If the received Proxy Binding Acknowledgement message
(encapsulated in IPv4 UDP packet) is protected using IPsec ESP
header, then the message MUST be authenticated as described in
Section 4 of [RFC-5213]. However, if the IPv4 packet is not
protected using IPsec ESP header, then the message MUST be
authenticated after removing the outer IPv4 UDP header.
o After receiving a Proxy Binding Acknowledgment message o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be
encapsulated in an IPv4 packet, the mobile access gateway MUST applied on the encapsulated Proxy Binding Acknowledgement message,
verify the Proxy Binding Acknowledgment according to the Section after removing the outer IPv4 UDP header.
4.3 of Dual Stack Mobile IPv6 specification [ID-DSMIP6].
o If the Status field indicates Success, the mobile access gateway o If the Status field indicates Success, the mobile access gateway
MUST setup a tunnel to the local mobility anchor and add a default MUST setup a bi-directional tunnel to the local mobility anchor.
route over the tunnel for all the mobile node's traffic.
o If the NAT is available and the NAT detection option is presented o Upon accepting the request, the local mobility anchor MUST set up
in the Proxy Binding Acknowledgment, the mobile access gateway an IPv4 bi-directional tunnel to the mobile access gateway. The
MUST use the UDP tunnel to traverse the NAT for mobile node's tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
traffic and MUST send a proxy binding update every refresh time The encapsulation mode MUST be determined from the below
specified in the NAT detection option. The detailed operation can considerations.
be found in Dual Stack Mobile IPv6 specification [ID-DSMIP6].
o If the Status field in the proxy binding acknowledgment indicates * If there is a NAT Detection option [ID-DSMIP6] in the received
the rejection of the binding registration, the mobile access Proxy Binding Acknowledgement message, then the encapsulation
gateway MUST NOT enable IPv4 transport for the mobile node's mode for the tunnel MUST be set to IPv4-UDP. Otherwise the
traffic. encapsulation mode MUST be set to IPv4.
Forwarding Packets to Local Mobility Anchor * 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.
o On receiving any packets from the mobile node's IPv6 home address 4.2.2.1. Constructing the Proxy Binding Update Message
and/or IPv4 home address, the mobile access gateway tunnels the
packets to local mobility anchor as shown in Figure 8. If the
mobile access gateway and the local mobility anchor agreed to use
the TLV header for the UDP tunnel during the binding registration,
the TLV header MUST be presented after the UDP header as shown in
Figure 9.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) o The source address in the IPv4 header MUST be set to IPv4-Proxy-
[UDP header] /*Only if NAT is detected*/ CoA of the mobile access gateway and the destination address MUST
union { /*following either v6 or v4 header */ be set to the local mobility anchor's IPv4-LMAA.
IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
}
Upper layer protocols /*TCP,UDP,SCTP*/
Figure 8: Tunneled Packets from MAG to LMA 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 enabled.
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 PBU) 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 UDP packet with IPsec protection on the encapsulated packet:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header UDP header (sport=ANY, dport= DSMIP_PORT)
TLV header /* IPv6 PBU Packet protected with ESP header */
union {
IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
IPsec
GRE
}
Upper layer protocols /*TCP,UDP,SCTP*/
Figure 9: Tunneled Packets from MAG to LMA using the TLV header Figure 11: Proxy Binding Update Message encapsulated in IPv4 UDP
header
4.3. Local Mobility Anchor Considerations o The format of the Proxy Binding Update message encapsulated in an
IPv4 UDP packet and with IPsec protection on the encapsulated
packet:
4.3.1. Extensions to Binding Cache Entry IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
ESP Header
UDP header (sport=ANY, dport= DSMIP_PORT)
/* IPv6 PBU Packet protected with no ESP header */
For supporting this feature, the conceptual Binding Cache entry data Figure 12: Proxy Binding Update Message Encapsulated with IPsec
structure needs to be extended with the following additional protection
parameter as specified in [ID-DSMIP6] specification and are reviewed
here for convenience.
o The IPv4 Care-of address of the attached mobile node. In this 4.2.2.2. Forwarding Considerations
specification, it can be translated to IPv4 Care-of address of the
mobile access gateway to which a mobile node is attached.
4.3.2. Signaling Considerations Forwarding Packets Sent by the Mobile Node:
When a mobile node is attached to a mobile access gateway that is o On receiving an IPv4 or an IPv6 packet from the mobile node to any
reachable only through an IPv4 transport network, the local mobility destination, the mobile access gateway MUST tunnel the packet to
anchor must establish an IPv4 tunnel for routing the mobile node's the local mobility anchor. The format of the tunneled packet is
IPv4 and IPv6 home address traffic. The DSMIPv6 specification shown below. However, considerations from Section 6.10.3 of [RFC-
provides the semantics on how the IPv4 tunnel needs to be negotiated 5213] MUST be applied with respect the local routing and on the
and the detection logic of the NAT devices. This specification use of EnableMAGLocalRouting flag.
leverages the NAT Detection Option, defined in the Dual Stack Mobile
IPv6 specification for the use in Binding Acknowledgment message and
extends it to Proxy Binding Acknowledgment messages. The operational
steps are defined below.
Processing Binding Registrations: 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 13: Tunneled IPv4 Packet from LMA to MAG
o After accepting the registration from the mobile access gateway o Forwarding Packets received from the bi-directional tunnel:
locating at the IPv4 only network, the local mobility anchor MUST
setup a tunnel to the mobile access gateway. The tunnel is
established between the v4-LMAA and the IPv4-Proxy-CoA of the
mobile access gateway.
o If the NAT is available, the local mobility anchor MUST use UDP o On receiving a packet from the bi-directional tunnel established
encapsulation for the tunnel. 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 If the T flag is set in the proxy binding update message and the 5. Protocol Configuration Variables
TLV header is presented, the specified tunnel type must be used.
o The local mobility anchor also setup a host routes for the IPv4 5.1. Local Mobility Anchor - Configuration Variables
home address and the IPv6 home address of the mobile node over the
tunnel to the mobile access gateway. Any traffic that the local
mobility anchor receives from a correspondent node will be
tunneled to the mobile access gateway over the bi-directional
tunnel and then routed accordingly after removing the tunnel
headers. The encapsulation modes for the bi-directional tunnel
are as specified in Section 5.3 of Proxy Mobile IPv6 specification
[ID-PMIP6] and as in this specification.
o Upon receiving a Proxy Binding Update message encapsulated in an The local mobility anchor MUST allow the following variables to be
IPv4 packet, the local mobility anchor MUST send the Proxy Binding configured by the system management. The configured values for these
Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by protocol variables MUST survive server reboots and service restarts.
using IPv4 encapsulation.
o If the NAT is detected, the NAT detection option MUST be used in AcceptIPv4UDPEncapsulationRequest
the Proxy Binding Acknowledgment. How to detect NAT is described
in Section 4.1 of [ID-DSMIP6] and Section 4.1.
Constructing the Proxy Binding Acknowledgement Message: This flag indicates whether or not the local mobility anchor
should accept IPv4 UDP encapsulation support if there is NAT
detected in the path.
o The proxy binding acknowledgment MUST be protected by IPsec ESP. The default value for this flag is set to value of 1, indicating
The security association for IPv4 addresses of the mobile access that the local mobility anchor MUST enable IPv4 UDP encapsulation
gateway and local mobility anchor are pre-established. support on detecting NAT in the path.
o For the IPv4 transport support, no special mobility options are When the value for this flag is set to value of 0, the local
required. Only when NAT is detected, the NAT detection option mobility anchor MUST NOT enable IPv4 UDP encapsulation support.
MUST be present. The local mobility anchor MUST construct the
proxy binding Acknowledgement as specified in [ID-PMIP6].
o An example of proxy binding acknowledgment sent by local mobility 5.2. Mobile Access Gateway - Configuration Variables
anchor is shown below. The same illustration for Mobile IPv6 can
be found in Section 4.1 of [ID-DSMIP6].
IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) The mobile access gateway MUST allow the following variables to be
UDP header configured by the system management. The configured values for these
[TLV-header] /* optional, if T flag is set */ protocol variables MUST survive server reboots and service restarts.
IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header
-BA /* P flag/T flag(option) */
Mobility Options
- Home Network Prefix Option
- IPv4 Address Acknowledgement option
- Timestamp option (optional)
- Mobile Node Identifier Option
- Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option
(Optional)
- NAT Detection Option (Optional) RequestIPv4UDPEncapsulationSupport
Figure 10: Proxy Binding Acknowledgment in IPv4 network This flag indicates whether or not the mobile access gateway
should request the mobile node's local mobility anchor for IPv4
UDP encapsulation support if NAT is detected in the path.
Forwarding Packets to Mobile Access Gateway 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 IPv4 UDP encapsulation support.
o When sending any packets meant to a mobile node's IPv4 home When the value for this flag is set to value of 1, the mobile
address or IPv6 home address, the local mobility anchor tunnels access gateway MUST request the mobile node's local mobility
the packet to mobile access gateway as shown in Figure 11. anchor for IPv4 UDP encapsulation support if there is NAT detected
in the path.
IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) ForceIPv4UDPEncapsulationSupport
[UDP header] /*Only if NAT is detected*/ This flag indicates whether or not the mobile access gateway
union { /*following either v6 or v4 header */ should request the mobile node's local mobility anchor for forcing
IPv4 header (src=IPv4-CN, dst=IPv4-HoA) IPv4 UDP encapsulation support even when NAT is not detected in
IPv6 header (src=IPv6-CN, dst=IPv6-HoA) path.
}
Upper layer protocols /*TCP,UDP,SCTP*/
Figure 11: Tunneled Packets from LMA to MAG The default value for this flag is set to value of 0, indicating
o If the mobile access gateway and the local mobility anchor agreed that the mobile access gateway MUST NOT request the mobile node's
to use the TLV header for the UDP tunnel during the binding local mobility anchor for forcing IPv4 UDP encapsulation support
registration, the TLV header MUST be presented after the UDP even when NAT is not detected in path.
header as shown in Figure 12.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) When the value for this flag is set to value of 1, the mobile
UDP header access gateway MUST force the mobile node's local mobility anchor
TLV header for IPv4 UDP encapsulation support.
union {
IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
IPsec
GRE
}
Upper layer protocols /*TCP,UDP,SCTP*/
Figure 12: Tunneled Packets from LMA to MAG using the TLV header This flag is applicable only when the flag
RequestIPv4UDPEncapsulationSupport is set to a value of 1.
4.4. Tunnel Management 5.3. Proxy Mobile IPv6 Domain - Configuration Variables
As specified in the Proxy Mobile IPv6 specification, the bi- All the mobile entities (local mobility anchors and mobile access
directional tunnel between the local mobility anchor and the mobile gateways) in a Proxy Mobile IPv6 domain MUST allow the following
access gateway, is a shared tunnel and all the considerations from variables to be configured by the system management. The configured
Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport values for these protocol variables MUST survive server reboots and
as well. service restarts. These variables MUST be globally fixed for a given
Proxy Mobile IPv6 domain resulting in the same values being enforced
on all the mobility entities in that domain.
5. IANA Considerations FixedDHCPServerId
This document does not require IANA Action. This variable indicates the DHCP server id that all the DHCP
servers co-located with the mobile access gateways SHOULD
configure in that Proxy Mobile IPv6 domain. If this variable is
initialized to ALL_ZERO value, it implies the use of fixed address
is not enabled for that Proxy Mobile IPv6 domain.
6. Security Considerations 6. IANA Considerations
The security mechanisms specified for Proxy Mobile IPv6 protocol are This document defines a new Mobility Header option, IPv4 Default
used when using the extensions defined in this document. 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].
When supporting IPv4 address assignment from a DHCP server, all the This document also defines new Binding Acknowledgement status values,
IPv4 home addresses managed in the DHCP server must be reachable via as described in Section 3.3.2. The status values MUST be assigned
local mobility anchor so that local mobility anchor intercepts from the same number space used for Binding Acknowledgement status
packets meant for an IPv4 home address and tunnels them to the mobile values, as defined in [RFC3775]. The allocated values for each of
node via corresponding mobile access gateway. Moreover, all the DHCP these status values must be greater than 128.
messages between a DHCP relay and the DHCP server SHOULD be securely
exchanged.
After receiving a Proxy Binding Update message with an IPv4 Home 7. Security Considerations
Address Option, the local mobility anchor MUST be able to verify that
the mobile node is authorized to use that address before setting up
forwarding for that host route.
When supporting dynamic IPv4 address assignment by DHCP and also from All the security considerations from the base Proxy Mobile IPv6
local mobility anchor, it should be ensured both the entities are protocol [RFC-5213] apply when using the extensions defined in this
configured with different address pools, so as to avoid both entities document. Additionally, the following security considerations need
do not allocate the same address to different mobile nodes. to be applied.
This specification describes the use of IPv4 transport network This document defines news mobility options for supporting the IPv4
between the local mobility anchor and the mobile access gateway. All Home Address assignment and IPv4 Transport Support features. It also
the signaling messages exchanged between the mobile access gateway uses some of the mobility options from DSMIPv6 specification [ID-
and the local mobility anchor over the IPv4 transport MUST be DSMIP6]. These options are to be carried in Proxy Binding Update and
protected using IPsec, just as the messages must be protected when Proxy Binding Acknowledgement messages. The required security
using IPv6 transport and as specified in the Section 4.0, of the mechanisms specified in the base Proxy Mobile IPv6 protocol for
Proxy Mobile IPv6 specification [ID-PMIP6]. protecting these signaling messages are sufficient when carrying
these mobility options.
7. Contributors This specification describes the use of IPv4 transport for exchanging
the signaling messages between the local mobility anchor and the
mobile access gateway. These messages are protected using IPsec
using the security associations established using the IPv4 transport
addresses and offer the same security as when the messages are
protected when using IPv6 transport.
8. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
people (in alphabetical order): people (in alphabetical order):
Kuntal Chowdhury Kuntal Chowdhury
kchowdhury@starentnetworks.com kchowdhury@starentnetworks.com
Vijay Devarapalli Vijay Devarapalli
skipping to change at page 31, line 30 skipping to change at page 42, line 30
sjjeong@etri.re.kr sjjeong@etri.re.kr
Basavaraj Patil Basavaraj Patil
basavaraj.patil@nsn.com basavaraj.patil@nsn.com
Myungki Shin Myungki Shin
myungki.shin@gmail.com myungki.shin@gmail.com
8. Acknowledgments 9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. This document internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like
leverages lot of text from that document. We would like to thank all to thank all the authors of the document and acknowledge that initial
the authors of the document and acknowledge that initial work. work.
9. References Thanks to Jonne Soinnen, Julien Laganier, Zu Qiang, Premec Domagoj,
Sammy Touati and Niklas Nuemann for their helpful review of this
document.
9.1. Normative References 10. References
10.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
November 2005.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05.txt Hosts and Routers (DSMIPv6)",
,July 2007. draft-ietf-mip6-mext-nemo-v4traversal-05.txt,July 2008.
[ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
draft-ietf-netlmm-proxymip6-16.txt, November 2007. November 2007.
9.2. Informative References 10.2. Informative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001. Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
Mobility", RFC 4977, August 2007. Mobility", RFC 4977, August 2007.
Appendix A. DHCP usages for IPv4 home address assignment [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp,
"DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
There are several other configurations of DHCP entities [RFC-2131] in
a Proxy Mobile IPv6 domain other than the two configurations listed
in Section 3.1. Although this specification recommends the two
configurations described in Section 3.1, operators should select the
best configuration according to their deployments scenario. The
mobile node behavior for all scenarios does not change. We do not
have major interoperability concerns between multiple scenarios. A
mobile access gateway and local mobility anchor make sure that which
scenario is used in the same Proxy Mobile IPv6 domain based on
deployment requirements. The optional DHCP configurations for IPv4
home address assignment are described below.
o DHCP relay is co-located with each mobile access gateway and DHCP
server is solely located in the Proxy Mobile IPv6 domain.
o DHCP relay is co-located with both each mobile access gateway and
a local mobility anchor. DHCP server is solely located behind the
local mobility anchor in the Proxy Mobile IPv6 domain.
The operations are same as described in Section 3.1. Before relaying
any DHCP messages, a mobile access gateway&#12288;SHOULD complete the
proxy binding registration so that it learns the assigned address to
provide the IPv4 home address hint to the DHCP server. However, when
DHCP relays are located at both a mobile access gateway and a local
mobility anchor, the DHCP relay at the local mobility anchor can
simply insert the address hint retrieved from its local address
management pool in the DHCP messages. Thus, the IPv4 home address
option [ID-DSMIP6] can be omitted from the Proxy Binding Update and
Acknowledgement messages.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Keio University Toyota ITC / Keio University
Department of Environmental Information, Keio University. 6-6-20 Akasaka, Minato-ku
5322 Endo Tokyo 107-0052
Fujisawa, Kanagawa 252-8520
Japan Japan
Email: ryuji@sfc.wide.ad.jp Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Sri Gundavelli Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
Full Copyright Statement Full Copyright Statement
 End of changes. 214 change blocks. 
934 lines changed or deleted 1292 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/