draft-ietf-netlmm-pmip6-ipv4-support-02.txt   draft-ietf-netlmm-pmip6-ipv4-support-03.txt 
NETLMM Working Group R. Wakikawa (Editor) NETLMM Working Group R. Wakikawa (Editor)
Internet-Draft Keio University Internet-Draft Keio University
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: May 22, 2008 Cisco Expires: November 23, 2008 Cisco
November 19, 2007 May 22, 2008
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-02.txt draft-ietf-netlmm-pmip6-ipv4-support-03.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 May 22, 2008. This Internet-Draft will expire on November 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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 supporting IPv4 protocol. The scope of this IPv4 support includes
the support for the mobile node's IPv4 home address mobility and for the support for the mobile node's IPv4 home address mobility and for
allowing the mobility entities in the Proxy Mobile IPv6 domain to allowing the mobility entities in the Proxy Mobile IPv6 domain to
exchange signaling messages over IPv4 transport. The solution exchange signaling messages over an IPv4 transport.
leverages the extensions defined in DSMIPv6 specification for
achieving this.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 7
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7
3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 10
3.2.1. Extensions to Binding Update List Entry . . . . . . . 10
3.2.2. Signaling Considerations . . . . . . . . . . . . . . . 10
3.3. Local Mobility Anchor Considerations . . . . . . . . . . . 14
3.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 14
3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 15
3.3.3. Routing Considerations . . . . . . . . . . . . . . . . 17
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 19 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8
4.1. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 20 3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 8
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 20 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 11
4.2.1. Extensions to Binding Update List Entry . . . . . . . 20 3.2.1. Extensions to Binding Update List Entry . . . . . . . 11
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 20 3.2.2. Signaling Considerations . . . . . . . . . . . . . . . 11
4.3. Local Mobility Anchor Considerations . . . . . . . . . . . 24 3.3. Local Mobility Anchor Considerations . . . . . . . . . . . 15
4.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 24 3.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 15
4.3.2. Signaling Considerations . . . . . . . . . . . . . . . 24 3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 16
4.4. Tunnel Management . . . . . . . . . . . . . . . . . . . . 26 3.3.3. Routing Considerations . . . . . . . . . . . . . . . . 18
3.4. Mobility Options . . . . . . . . . . . . . . . . . . . . . 19
3.4.1. IPv4 Default Router Address Option . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 20
4.1. NAT Support . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 22
4.2.1. Extensions to Binding Update List Entry . . . . . . . 22
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 22
4.3. Local Mobility Anchor Considerations . . . . . . . . . . . 25
4.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 25
4.3.2. Signaling Considerations . . . . . . . . . . . . . . . 25
4.4. Tunnel Management . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. DHCP usages for IPv4 home address assignment . . . . 31 Appendix A. DHCP usages for IPv4 home address assignment . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35
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
only network. It is also reasonable to expect the same mobility or an IPv6 network. It is also reasonable to expect the same
infrastructure in a Proxy Mobile IPv6 domain to provide mobility to mobility infrastructure in a Proxy Mobile IPv6 domain to provide
the mobile node's operating in IPv4, IPv6 or in dual mode and when mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode
the network between the local mobility anchor and the mobile access and when the network between the local mobility anchor and the mobile
gateway is an IPv4 network. The motivation and scope of IPv4 support access gateway is an IPv4 or an IPv6 network. The motivation and
in Mobile IPv6 is summarized in [RFC-4977]. scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and
all those requirements apply to Proxy Mobile IPv6 protocol as well.
The Proxy Mobile IPv6 protocol[ID-PMIP6] specifies a mechanism for The Proxy Mobile IPv6 protocol[ID-PMIP6] 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 and when there is an IPv6 transport network
separating the entities involved in the mobility management. The separating the entities involved in the mobility management. The
extensions defined in this document are for extending IPv4 support to extensions defined in this document are for extending IPv4 support to
the Proxy Mobile IPv6 protocol [ID-PMIP6]. the Proxy Mobile IPv6 protocol [ID-PMIP6].
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 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 Support: The mobility entities in the Proxy Mobile o IPv4 Transport Network Support: The mobility entities in the Proxy
IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
messages over an IPv4 transport and further the local mobility signaling messages over an IPv4 transport and further the local
anchor or the mobile access gateway may be using IPv4 private mobility anchor or the mobile access gateway may be using IPv4
addresses and with NAT [RFC-3022] translation devices separating private addresses and with NAT [RFC-3022] translation devices
them. separating them.
The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address
mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC- mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC-
3775]. The solution specified in this document leverages these 3775]. The solution specified in this document leverages some of the
extensions for enabling IPv4 support to Proxy Mobile IPv6 protocol. options related to IPv4 support and some processing logic for
These two features, the IPv4 Home Address Mobility support and IPv4 extending IPv4 support to Proxy Mobile IPv6 protocol. These two
transport support features, are independent of each other and features, the IPv4 Home Address Mobility support and IPv4 transport
deployments can choose to enable any one or both of these features. support features, are independent of each other and deployments can
choose to enable any one or both of these features.
This specification requires that the local mobility anchor and the
mobile access gateway are both IPv6 capable and IPv6 enabled,
irrespective of the type of transport network (IPv4 or IPv6),
connecting these two entities. The signaling protocol is
fundamentally based on Mobile IPv6.
Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home
address mobility and IPv4 transport support features. The mobile address mobility and IPv4 transport support features. The mobile
nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or
dual-stack mode, and the transport network between the local mobility dual-stack mode, and the transport network between the local mobility
anchor and the mobile access gateway may be an IPv6 network or an anchor and the mobile access gateway may be an IPv6 network or an
IPv4 network. Further, when the transport network is IPv4, either IPv4 network. Further, when the transport network is IPv4, either
the local mobility anchor or the mobile access gateway, or both can the local mobility anchor or the mobile access gateway, or both can
be behind a NAT [RFC-3022] translation device and configured with an be behind a NAT [RFC-3022] translation device and configured with an
IPv4 private address. IPv4 private address.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA1 -> | | <-- IPv4-LMAA2 IPv4-LMAA1 -> | | <-- LMAA2
| | | |
\\ //\\ \\ //\\
[NAT] // \\ [NAT] // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // [NAT]
\\ // \\ \\ // \\
IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2 \\ // \\
IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+ +----+ +----+
|MAG1|-----{MN2} |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
| | | (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
o This specification requires that the local mobility anchor and the
mobile access gateway are both IPv6 capable and IPv6 enabled.
Irrespective of the type of transport network (IPv4 or IPv6)
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
network between the local mobility anchor and the mobile access
gateway can be an IPv6 network or an IPv4 network. However, for
supporting IPv4 transport network feature, as implied, IPv4
transport network is required.
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
IPv4-only, IPv6-only or both IPv4 and IPv6 address(es) on its
interface. However, the respective protocol(s) support must be
enabled on the access link between the mobile node and the mobile
access gateway.
o There can be support for multiple IPv4 home network prefixes for
the mobile node's attached interface. The mobile node should be
able to obtain one or more IPv4 addresses from one or all of its
IPv4 home network prefixes. Based on the type of link, it may be
able to acquire its IPv4 address configuration using DHCP, IPCP,
IKEv2 or through other standard address configuration mechanisms.
o The mobile node's IPv4 home network prefix is a shared prefix
(unlike its IPv6 home network prefix, which is a shared prefix).
There can be more than one mobile node sharing address(es) from
the same IPv4 home network prefix.
o The mobile access gateway is always the IPv4 default-router for
the mobile node on its access link. It will always be able to
receive traffic sent to the mobile node's IPv4 default-router
address.
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], Dual interpreted as defined in Mobile IPv6 specification [RFC-3775] and
Stack Mobile IPv6 specification [ID-DSMIP6] and Proxy Mobile IPv6 Proxy Mobile IPv6 specification [ID-PMIP6]. In addition the document
specification [ID-PMIP6]. In addition the document introduces the introduces the following terms.
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 interface of the mobile
access gateway and is the transport endpoint of the tunnel between access gateway and is the transport endpoint of the tunnel between
a local mobility anchor and a mobile access gateway. This address a local mobility anchor and a mobile access gateway. This address
will be used as the source address for the signaling messages sent will be used as the source address for the signaling messages sent
by the mobile access gateway to the local mobility anchor and will by the mobile access gateway to the local mobility anchor and will
be the registered Care-of address in the mobile node's Binding be the registered Care-of address in the mobile node's Binding
Cache entry. However, when the configured address is a private Cache entry. However, when the configured address is a private
skipping to change at page 6, line 41 skipping to change at page 7, line 40
mobility anchor, the care-of address as seen by the local mobility mobility anchor, the care-of address as seen by the local mobility
anchor will be the address allocated by the NAT device for that anchor will be the address allocated by the NAT device for that
flow. 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 interface of a local
mobility anchor and is the transport endpoint of the tunnel mobility anchor and is the transport endpoint of the tunnel
between the local mobility anchor and the mobile access gateway. between the local mobility anchor and the mobile access gateway.
This is the address to where the mobile access gateway sends the This is the address to where the mobile access gateway sends the
Proxy Binding Update messages. If the local mobility anchor is Proxy Binding Update messages when using IPv4 transport. If the
configured to be behind a NAT device, this address will be the local mobility anchor is configured to be behind a NAT device,
address allocated by the NAT device for that flow. 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)
This is the IPv4 prefix from which the mobile node obtains its
home address(es). This IPv4 home network prefix is topologically
anchored at the mobile node's local mobility anchor. The mobile
node configures its interface with address(es) from this prefix.
3. IPv4 Home Address Mobility Support 3. IPv4 Home Address Mobility Support
An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6 An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6
domain, the network will ensure the mobile node will be able to domain, the network will ensure the mobile node will be able to
obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for
the interface attached to the access network in that Proxy Mobile the interface attached to the access network in that Proxy Mobile
IPv6 domain. Using the extensions defined in this specification, the IPv6 domain. Using the extensions defined in this specification, the
mobile access gateway on the access network will exchange the mobile access gateway on the access network will exchange the
signaling messages with the mobile node's local mobility anchor and signaling messages with the mobile node's local mobility anchor and
skipping to change at page 7, line 30 skipping to change at page 8, line 30
will be multiple Binding Cache entries on the local mobility anchor will be multiple Binding Cache entries on the local mobility anchor
for that mobile node and with one entry for each connected interface, for that mobile node and with one entry for each connected interface,
as specified in Section 5.4 [ID-PMIP6]. as specified in Section 5.4 [ID-PMIP6].
The support for IPv4 addressing is orthogonal to the IPv6 addressing The support for IPv4 addressing is orthogonal to the IPv6 addressing
support. Unlike as specified in [ID-DSMIP6], the mobile node is not support. Unlike as specified in [ID-DSMIP6], the mobile node is not
required to have an IPv6 home address for obtaining IPv4 home address 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 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 IPv6 domain will be able to obtain just an IPv4 address configuration
or both IPv4 and IPv6 address configurations on the connected or both IPv4 and IPv6 address configurations on the connected
interface. The policy on the mobile access gateway will determine if interface. The mobile nodes' policy profile will determine if the
the mobile node is entitled for both the protocols or a single mobile node is entitled for both the protocols or a single protocol
protocol and based on what is enabled, only those protocols will be and based on what is enabled, only those protocols will be enabled on
enabled on the access link. Further, when the mobile node after the access link. Further, when the mobile node after obtaining the
obtaining the IPv4 or IPv4/IPv6 address configuration on the access IPv4 or IPv4/IPv6 address configuration on the access link, performs
link, performs an inter-technology handoff, the network will ensure an inter-technology handoff, the network will ensure the mobile node
the mobile node will be able to use the same IPv4/IPv6 address will be able to use the same IPv4/IPv6 address configuration on the
configuration on the new interface. 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 3.1. IPv4 Home Address Assignment
A mobile node on attaching to an access link connected to a mobile A mobile node on attaching to an access link connected to a mobile
access gateway, and if the network allows the mobile node for IPv4 access gateway, and if the network allows the mobile node for IPv4
home address mobility service, the mobile node using any of the IPv4 home address mobility service, the mobile node using any of the IPv4
address configuration procedures, such as DHCP [RFC-2131], IPCP or address configuration procedures, such as DHCP [RFC-2131], IPCP or
IKEv2 that are supported on that access link, will be able to obtain IKEv2 that are supported on that access link, will be able to obtain
required information for its IPv4 home address configuration. The required information for its IPv4 home address configuration. The
required information includes the IPv4 home address, the IPv4 home required information includes the IPv4 home address, the IPv4 home
network prefix and IPv4 home network prefix length. Any available network prefix, IPv4 home network prefix length and the IPv4 default
IPv4 address configuration mechanisms can be used such as static router address.
configuration method specific to the access link or dynamic
configuration from DHCP.
When a mobile node is configured with a static IPv4 home address, the When a mobile node is configured with a static IPv4 home address, the
IPv4 home address information SHOULD be stored in the mobile node's IPv4 home address information SHOULD be stored in the mobile node's
policy profile. The mobile access gateway where the mobile node policy profile. The mobile access gateway where the mobile node
attached obtains the static IPv4 home address from the policy attached obtains the static IPv4 home address from the policy
profile. The mobile access gateway MUST set the known IPv4 home profile. The mobile access gateway MUST use either the obtained IPv4
prefix to the IPv4 Home Address field and the Pref field of the IPv4 home address or the obtained IPv4 home subnet address to initialize
home address option [ID-DSMIP6]. This option is carried by a proxy the IPv4 Home Address and Pref fields in the IPv4 Home Address option
binding update described in [ID-PMIP6]. [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 On the other hand, if DHCP is used for the IPv4 home address
allocation as specified in [RFC-2131], a DHCP server and/or a DHCP allocation as specified in [RFC-2131], a DHCP server and/or a DHCP
relay agent on the link will ensure the mobile node is assigned an relay agent on the link will ensure the mobile node is assigned an
address from its home network prefix. There are several 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 configurations where the DHCP entities are located in a Proxy Mobile
IPv6 domain. This document recommends following two configurations IPv6 domain. This document recommends following two configurations.
as default operations. The other configurations are explained in The other configurations are explained in Appendix A.
Appendix A.
1. DHCP server is co-located with each mobile access gateway 1. DHCP server is co-located with each mobile access gateway
2. DHCP server is co-located with a local mobility anchor and a DHCP 2. DHCP server is co-located with a local mobility anchor and a DHCP
relay is co-located with each mobile access gateway relay is co-located with each mobile access gateway
Figure 2 shows the operational sequence of the home address Figure 2 shows the operational sequence of the home address
assignment when a DHCP server is co-located with each mobile access assignment when a DHCP server is co-located with each mobile access
gateway. In this scenario, a DHCP server (i.e. mobile access gateway. In this scenario, a DHCP server which is also a mobile
gateway) interacts with a DHCP client on a mobile node, while a local access gateway interacts with a DHCP client on a mobile node. All
mobility anchor actually provides an IPv4 Home Address dynamically to mobile access gateways SHOULD support minimal functionality of a DHCP
a mobile node during proxy binding registration. All mobile access server in order to send DHCP offer and acknowledgment messages to the
gateways SHOULD support minimal functionality of a DHCP server in mobile node in reply to the DHCP discovery and request messages.
order to send DHCP offer and acknowledgment messages to the mobile While the mobile access gateway is seen as a DHCP server from a
node in reply to the DHCP discovery and request messages. The mobile mobile node, it actually obtains the IPv4 home address for each
access gateway is seen as a DHCP server from a mobile node, but it mobile node from the local mobility anchor during proxy binding
actually obtains the IPv4 home address for each mobile node from the procedure (set 0.0.0.0 in the the IPv4 Home Address field of the IPv4
local mobility anchor during proxy binding procedure (set 0.0.0.0 in home address option as described in [ID-DSMIP6]). After MAG
the the IPv4 Home Address field of the IPv4 home address option as receiving the assigned IPv4 address from LMA, it assigns the address
described in [ID-DSMIP6]). The mobile access gateway MUST return its to the requesting mobile node. Note that the mobile access gateway
own IP address in the 'server identifier' option when sending DHCP MUST return its own IP address in the 'server identifier' option when
offer message to the mobile node. Thus, whenever the mobile node sending DHCP messages to the mobile node. Thus, whenever the mobile
changes the attached mobile access gateway, this server identifier node changes the attached mobile access gateway, this server
must be updated. The detail can be found in Section 3.2.2. Any identifier must be updated. The detail can be found in
information carried in DHCP options such as addresses of domain name Section 3.2.2. The second scenario does not have this server
server, time server, lpr server, etc. MUST be configured in all the identifier change when a mobile node changes its mobile access
mobile access gateway (i.e. DHCP server) if necessary. 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 MN MAG(DHCP-S) LMA
|------>| | 1. DHCP discovery |------>| | 1. DHCP discovery
| |------->| 2. Proxy Binding Update | |------->| 2. Proxy Binding Update *
| |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) | |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA)
| |========| 4. Tunnel/Route Setup* | |========| 4. Tunnel/Route Setup*
|<------| | 5. DHCP offer (IPv4 HoA) |<------| | 5. DHCP offer (IPv4 HoA)
|------>| | 6. DHCP request (IPv4 HoA) |------>| | 6. DHCP request (IPv4 HoA)
|<------| | 7. DHCP acknowledgement |<------| | 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) * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
are processed in parallel. are processed in parallel.
Figure 2: An example when LMA assigns an IPv4 home address Figure 2: An example when LMA assigns an IPv4 home address
In the second scenario, a DHCP relay is co-located at each mobile In the second scenario, a DHCP relay is co-located at each mobile
access gateway and a DHCP server is co-located at a local mobility access gateway and a DHCP server is co-located at a local mobility
anchor. The mobile access gateway learns the IPv4 home address from anchor. A mobile access gateway sends a proxy binding update and
the DHCP reply and sends that information to the mobile node by DHCP retrieves an IPv4 home address for the mobile node from the local
offer message. Meanwhile, it notifies the assigned IPv4 home address mobility anchor as described in the first scenario. When the mobile
by an IPv4 home address option in a proxy binding update to the local access gateway relays DHCP messages to the DHCP server, it includes
mobility anchor. In this case, the local mobility anchor does not the assigned IPv4 home address information in the DHCP messages as a
allocate any address, but only deals with route setup and tunnel hint. The DHCP server SHOULD assign the address stored in the hint
setup for the requested home address. Note that all the IPv4 home to the mobile node. Figure 3 are the sequence of IPv4 home address
addresses managed in the DHCP server must be reachable via local assignment using DHCP Relay. The DHCP discovery message is sent by a
mobility anchor so that local mobility anchor intercepts packets mobile node at any time, but the DHCP relay SHOULD NOT relay the DHCP
meant for an IPv4 home address and tunnels them to the mobile node discovery message before it learns the IPv4 home address hint during
via corresponding mobile access gateway. In addition, the DHCP the proxy binding registration. As shown in Figure 3, the DHCP
messages MAY be sent across an administrative boundaries. The messages MAY be sent across an administrative boundaries. The
operators MUST ensure to secure these messages. More remarks can be operators MUST ensure to secure these messages. More remarks can be
found in Section 6. Figure 3 are the sequence of IPv4 home address found in Section 6. The DHCP server identifier remains the same all
assignment using DHCP Relay. the time, because the server is uniquely located at the local
mobility anchor.
MN MAG(DHCP-R) LMA(DHCP-S) MN MAG(DHCP-R) LMA(DHCP-S)
|------>|------->| 1. DHCP discovery to DHCP-S through DHCP-R | |------->| 1. Proxy Binding Update *
|<------|<-------| 2. DHCP offer (IPv4 HoA) | |<-------| 2. Proxy Binding Acknowledgement (IPv4HoA)
|------>|------->| 3. DHCP request (IPv4 HoA) | |========| 3. Tunnel/Route Setup*
| |<-------| 4. DHCP acknowledgement |------>|------->| 4. DHCP discovery (IPv4HoA) via DHCP-R
| |------->| 5. Proxy Binding Update |<------|<-------| 5. DHCP offer (IPv4 HoA) via DHCP-R
| |<-------| 6. Proxy Binding Acknowledgement |------>|------->| 6. DHCP request (IPv4 HoA) via DHCP-R
| |========| 7. Tunnel/Route Setup |<------|<-------| 7. DHCP acknowledgement via DHCP-R
|<------| | 8. DHCP acknowledgement
| | | | | |
* Tunnel/Route setup(no.3) and DHCP offer/request/ack(no.4-7)
are processed in parallel.
Figure 3: The use of DHCP relay Figure 3: The use of DHCP relay
3.2. Mobile Access Gateway Considerations 3.2. Mobile Access Gateway Considerations
3.2.1. Extensions to Binding Update List Entry 3.2.1. Extensions to Binding Update List Entry
For supporting this feature, the conceptual Binding Update List entry For supporting this feature, the conceptual Binding Update List entry
data structure needs to be extended with the following additional data structure needs to be extended with the following additional
parameter, as specified in [ID-DSMIP6] specification and are fields.
presented here for convenience.
o The IPv4 home address of the attached mobile node. The IPv4 home o The IPv4 home address of the attached mobile node. This is
address value is acquired from the mobile node's local mobility acquired from the mobile node's local mobility anchor through the
anchor through the received Proxy Binding Acknowledgment messages. received Proxy Binding Acknowledgment message. The IPv4 home
address parameter also includes the corresponding subnet mask.
o The IPv4 default-router address of the mobile node. This is
acquired from the mobile node's local mobility anchor through the
received Proxy Binding Acknowledgment messages.
3.2.2. Signaling Considerations 3.2.2. Signaling Considerations
All the considerations explained in Section 6.11 of the base Proxy All the considerations from Section 6.9 of [ID-PMIP6] apply here.
Mobile IPv6 specification apply here. For supporting IPv4 home However, the following additional considerations MUST be applied.
address mobility feature, the following additional considerations
MUST be applied.
Mobile Node Attachment and Initial Binding Registration: Mobile Node Attachment and Initial Binding Registration:
o After detecting a new mobile node on its access link, the mobile o After detecting a new mobile node on its access link, the mobile
access gateway must identify the mobile node and acquire its MN- access gateway must identify the mobile node and acquire its MN-
Identifier. If it determines that the IPv4 home address mobility Identifier. If it determines that the IPv4 home address mobility
service needs to be offered to the mobile node, it MUST send a service needs to be offered to the mobile node [RYUJI by checking
Proxy Binding Update message to the local mobility anchor. The the policy profile], it MUST send a Proxy Binding Update message
for the IPv4 home address to the local mobility anchor. The
message MUST include the IPv4 Home Address option, defined in message MUST include the IPv4 Home Address option, defined in
section 3.1.1 of [ID-DSMIP6]. The mobile access gateway MAY also section 3.1.1 of [ID-DSMIP6]. The mobile access gateway MAY also
include the IPv6 Home Network Prefix option in the same message include the IPv6 Home Network Prefix option in the same message
for requesting IPv6 home address support in addition to IPv4 home for requesting IPv6 home address support in addition to IPv4 home
address support for the mobile node. 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 If the mobile access gateway learns the mobile node's IPv4 home
network prefix or the IPv4 home address either from its policy network prefix or the IPv4 home address either from its policy
store or from the DHCP messages exchanged between the mobile node store or from the DHCP messages exchanged between the mobile node
and the DHCP server, the mobile access gateway can specify the and the DHCP server, the mobile access gateway can specify the
same in the IPv4 Home Address option for requesting the local same in the IPv4 Home Address option for requesting the local
mobility anchor to allocate that address or to allocate an address mobility anchor to allocate that address or to allocate an address
from the specified home network prefix. If the specified value is 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 0.0.0.0, then the local mobility anchor will consider this as a
request for dynamic address allocation. request for dynamic address allocation.
o The mobile access gateway on the access link where mobile node is o The mobile access gateway on the access link where mobile node is
attached, will register this address with the local mobility attached, will register this address with the local mobility
anchor using the IPv4 Home Address option, defined in Section 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 3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a
proxy binding update as shown in Figure 4. The format of the proxy binding update message. The format of the proxy binding
proxy binding update is slightly different from the one of [ID- update is slightly different from the one of [ID-DSMIP6]. In [ID-
DSMIP6]. In [ID-DSMIP6], the source address of IPv6 header must DSMIP6], the source address of IPv6 header must be a home address
be a home address of the mobile terminal. However, since Proxy of the mobile terminal. However, since Proxy Mobile IPv6 supports
Mobile IPv6 supports only IPv4 capable node, IPv6 home address is also IPv4-only nodes, IPv6 home address is not always available on
not always available on the terminal. In addition to this, the the terminal. In addition to this, the originator of this proxy
originator of this proxy binding update is not the mobile binding update is not the mobile terminal, but the mobile access
terminal, but the mobile access gateway. The mobile access gateway. The mobile access gateway cannot send the proxy binding
gateway cannot send the proxy binding update with the mobile update with the mobile node's home address because of security
node's home address because of security reasons (IPsec and ingress reasons (IPsec and ingress filtering). Therefore, in this
filtering). Therefore, in this specification, the mobile access specification, the mobile access gateway's care-of address (Proxy-
gateway's care-of address (Proxy-CoA) is used in the IPv6 source CoA) is used in the IPv6 source address field.
address field.
o The proxy binding update MUST be protected by IPsec ESP. o The proxy binding update MUST be protected by IPsec ESP.
Receiving Binding Registration Reply: Receiving Binding Acknowledgement Message:
o If the received Proxy Binding Acknowledgement message has neither o If the received Proxy Binding Acknowledgement message has neither
an IPv4 Address Acknowledgement option or a Home Network Prefix an IPv4 Address Acknowledgement option or a Home Network Prefix
option present, the mobile access gateway MUST ignore the Proxy option present, the mobile access gateway MUST ignore the Proxy
Binding Acknowledgement and MUST NOT enable routing for the mobile Binding Acknowledgement and MUST NOT enable routing for the mobile
node's IPv4 Home Address or IPv6 home address traffic. However, node's IPv4 Home Address or IPv6 home address traffic. However,
if there is an IPv4 Home Address Acknowledgment option present in if there is an IPv4 Home Address Acknowledgment option present in
the reply, the option MUST be processed as per the rules specified the reply, the option MUST be processed as per the rules specified
in Dual Stack Mobile IPv6 specification [ID-DSMIP6]. in Dual Stack Mobile IPv6 specification [ID-DSMIP6].
skipping to change at page 12, line 34 skipping to change at page 14, line 7
value set to zero. The message MUST contain the IPv4 Home Address value set to zero. The message MUST contain the IPv4 Home Address
option with the value set to the currently registered IPv4 home option with the value set to the currently registered IPv4 home
address value. Additionally, if there is a registered IPv6 home address value. Additionally, if there is a registered IPv6 home
network prefix for the mobile node for the connected interface on network prefix for the mobile node for the connected interface on
that access link, both the options, Home Network Prefix option and that access link, both the options, Home Network Prefix option and
the IPv4 Home Address option MUST be present and with the values the IPv4 Home Address option MUST be present and with the values
set to the respective registered values. set to the respective registered values.
Constructing the Proxy Binding Update Message: Constructing the Proxy Binding Update Message:
o The mobile access gateway when sending the Proxy Binding Update The mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor for requesting IPv4 home request to the local mobility anchor for requesting IPv4 home address
address mobility support MUST construct the message as specified mobility support MUST construct the message with the following
below. considerations.
IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header
-BU /*P & A flags are set*/
Mobility Options
- Timestamp Option (optional)
- Mobile Node Identifier option
- Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option
(Optional)
- IPv4 Home Address option (Mandatory)
Figure 4: Proxy Binding Update for IPv4 Home Address Support
o The source address field of the IPv6 header MUST be the IPv6 o The message MUST be constructed as specified in Section 6.9 of
address of the mobile access gateway. [ID-PMIP6]. However, when sending the messages over IPv4
transport, additional considerations from Section 4.0 MUST be
applied.
o The IPv4 Home Address option [ID-DSMIP6] MUST be present. The o The IPv4 Home Address option [ID-DSMIP6] MUST be present. The
address value MAY be set 0.0.0.0 or to a specific value. address value MAY be set 0.0.0.0 or to a specific value.
o All the other fields and the options MUST be constructed, as
specified in [ID-PMIP6].
DHCP Messages from the mobile node: DHCP Messages from the mobile node:
The operations of DHCP are almost same for both scenarios listed in
Section 3.1. There is one special operation for address renewing
operation when a mobile access gateway is the DHCP server.
o When a mobile node attached to an access link and attempts to o When a mobile node attached to an access link and attempts to
obtain an IPv4 address configuration, using DHCP or other obtain an IPv4 address configuration, using DHCP or other
procedures, it will get an IPv4 address as an IPv4 home address procedures, it will get an IPv4 address as an IPv4 home address
from its home network prefix as discussed in Section 3.1. The from its home subnet as discussed in Section 3.1. The mobile
mobile access gateway on the access link where mobile node is access gateway on the access link where mobile node is attached,
attached, will register this address with the local mobility will register the IPv4 home address with the local mobility anchor
anchor using the IPv4 Home Address option, defined in Section using the IPv4 Home Address option, defined in Section 3.1.1 of
3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a [ID-DSMIP6]. The IPv4 Home Address option is sent with a proxy
proxy binding update as shown in Figure 4 binding update.
o When a mobile node obtains an IPv4 home address from DHCP server,
the mobile access gateway SHOULD record the assigned IPv4 home
address in the policy profile. A new mobile access gateway can
send a proxy binding update when a mobile node roams to the new
mobile access gateway.
o When a mobile node first attaches to a Proxy Mobile IPv6 domain, a o When a mobile node attempts to obtain an IPv4 home address by
mobile access gateway triggers a proxy binding update by following using DHCP, the mobile access gateway SHOULD complete the proxy
conditions. It is rarely happened that the DHCP procedure and binding registration before starting any DHCP operation. This is
proxy binding procedure run at the same time except for the necessary for the mobile access gateway to obtain all the
initial attachment. information required for DHCP operation from the local mobility
anchor.
* When a mobile access gateway is a DHCP server, it MUST send a o The mobile access gateway SHOULD send a proxy binding update with
proxy binding update right after receiving a DHCP discovery 0.0.0.0 in the the IPv4 Home Address field of the IPv4 home
message from a mobile node. By sending the proxy binding address option [ID-DSMIP6] and retrieve the assigned IPv4 home
update, it will learn the assigned IPv4 home address from the address from the local mobility anchor. The IPv4 home address
local mobility anchor. assigned by the local mobility anchor is offered to the mobile
node by DHCP.
* When a DHCP relay is co-located with a mobile access gateway, o When a mobile node changes its attached mobile access gateway, the
the mobile access gateway MUST send a proxy binding update as new mobile access gateway MUST sends a proxy binding update with
soon as it receives a DHCP Acknowledgement message from the the IPv4 home address option. If the new mobile access gateway
DHCP server. During the proxy binding registration, it MUST know the assigned IPv4 home address, for example by context
NOT relay the DHCP Acknowledgement message to the DHCP client. transfer mechanism or policy profile, it SHOULD include the
After the proxy binding is successfully registered, the DHCP address in the IPv4 Home Address field. Otherwise, it uses
relay (i.e. mobile access gateway) MUST forward the DHCP 0.0.0.0 and obtains the assigned IPv4 home address of the mobile
Acknowledgement to the DHCP client (i.e. mobile node). Before node from the local mobility anchor, again.
a DHCP Acknowledgement message, a DHCP client and the DHCP
server do not complete the negotiation of IPv4 address
assignment so that the mobile access gateway MAY send a
different IPv4 address to the local mobility anchor by a proxy
binding update.
o After the initial procedure described in above, DHCP runs o Except for the mobile node's bootstrap, DHCP runs independently to
independently to the proxy binding registration for renewing the the proxy binding registration, for instance, for renewing the
assigned IPv4 home address. It is not necessary to run DHCP assigned IPv4 home address. It is not necessary to run DHCP
whenever a mobile node changes its attached mobile access gateway. whenever a mobile node changes its attached mobile access gateway.
A DHCP client renew the address according to the address lifetime, A DHCP client renew the address according to the address lifetime,
etc. However, whenever a mobile node renews the IPv4 home address etc. However, whenever a mobile node renews the IPv4 home address
by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access
gateway SHOULD send a proxy binding update to the local mobility gateway SHOULD send a proxy binding update to the local mobility
anchor regardless of the mobile node's assigned address changes. anchor regardless of the mobile node's assigned address changes.
o When a mobile node gets IPv4 home address from Local Mobility o When a mobile node gets IPv4 home address from Local Mobility
Anchor through DHCP interaction with mobile access gateway that Anchor through DHCP interaction with mobile access gateway that
supports DHCP server functionality, the DHCP client in the mobile supports DHCP server functionality, the DHCP client in the mobile
node recognizes mobile access gateway's IP address as DHCP node recognizes mobile access gateway's IP address as DHCP
server's IP address. Thus, the DHCP client unicasts DHCP renew to server's IP address. Thus, the DHCP client unicasts DHCP renew to
the mobile access gateway, when the DHCP client goes into the DHCP the mobile access gateway, when the DHCP client goes into the DHCP
RENEWING state [RFC-2131]. However, when the mobile node RENEWING state [RFC-2131]. However, when the mobile node
handovers to a new mobile access gateway, the mobile node does not handovers to a new mobile access gateway, the mobile node does not
know the link change and the DHCP client would unicast DHCP know the link change and the DHCP client would unicast DHCP
request to the previous mobile access gateway whose IP address was request to the previous mobile access gateway whose IP address was
acquired from DHCP offer. So, DHCP client in the mobile node acquired from DHCP offer. The DHCP client in the mobile node
needs to reconfigure its local configuration parameters. needs to reconfigure its local configuration parameters. The
Therefore, mobile access gateway SHOULD discard any DHCP request mobile access gateway SHOULD discard any DHCP request message that
message that does not belong to the mobile access gateway itself, does not belong to the mobile access gateway itself, so that the
so that the mobile node should go into the DHCP REBINDING state mobile node should go into the DHCP REBINDING state and broadcast
and broadcast DHCP request without server identifier. DHCP discovery message without server identifier.
3.3. Local Mobility Anchor Considerations 3.3. Local Mobility Anchor Considerations
3.3.1. Extensions to Binding Cache Entry 3.3.1. Extensions to Binding Cache Entry
For supporting this feature, the conceptual Binding Cache entry data For supporting this feature, the conceptual Binding Cache entry data
structure needs to be extended with the following additional structure needs to be extended with the following additional
parameter, as specified in [ID-DSMIP6] specification and is presented parameter, as specified in [ID-DSMIP6] specification and is presented
here for convenience. here for convenience.
skipping to change at page 16, line 44 skipping to change at page 17, line 40
Binding Cache entry, just as specified in Section 5.4 [ID-PMIP6]. Binding Cache entry, just as specified in Section 5.4 [ID-PMIP6].
For all other cases, the local mobility anchor MUST use the IPv4 For all other cases, the local mobility anchor MUST use the IPv4
home address parameter in combination with the mobile node home address parameter in combination with the mobile node
identifier and interface identifier for matching the Binding Cache identifier and interface identifier for matching the Binding Cache
entry, as specified in Section 5.4 [ID-PMIP6]. entry, as specified in Section 5.4 [ID-PMIP6].
Constructing the Proxy Binding Acknowledgement Message: Constructing the Proxy Binding Acknowledgement Message:
o The local mobility anchor when sending the Proxy Binding o The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST Acknowledgement message to the mobile access gateway MUST
construct the message as specified below. construct the message as specified in Proxy Mobile IPv6 base
specification [ID-PMIP6]. However, the following considerations
IPv6 header (src=LMAA, dst=Proxy-CoA) MUST be applied.
Mobility header
-BA /*P flag is set*/
Mobility Options
- Timestamp option (optional)
- Mobile Node Identifier Option
- Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option
(Optional)
- IPv4 Address Acknowledgement Option (Mandatory)
Figure 5: Proxy Binding Acknowledgement for IPv4 Home Address
Support
o The destination address field of the IPv6 header MUST be set to
the mobile access gateway.
o The IPv4 Address Acknowledgement option MUST be present in the o The IPv4 Address Acknowledgement option MUST be present in the
Proxy Binding Acknowledgement message. If both the IPv4 Home Proxy Binding Acknowledgement message.
Address option and the IPv6 Home Network Prefix option were not
present in the Proxy Binding Update request and if the Status
field value in the message is set to
MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to
ALL_ZERO. For all other Status values, the IPv4 home address
value MUST be set to the allocated address value for that mobile
node. Considerations from [ID-DSMIP6] MUST be applied on
determining Status field value in the option.
o All the other fields and the options MUST be constructed, as 1. If the Status field is set to a value greater than or equal to
specified in [ID-PMIP6]. 128, i.e., if the binding request is rejected, then the IPv4
home address value in the IPv4 Address Acknowledgement option
MUST be set to ALL_ZERO value.
2. For all other cases, the IPv4 home address value in the IPv4
Address Acknowledgement option MUST be set to the allocated
IPv4 home address value for that mobility session.
3.3.3. Routing Considerations 3.3.3. Routing Considerations
Forwarding Considerations for the mobile node's IPv4 home address Forwarding Considerations for the mobile node's IPv4 home address
traffic. traffic.
Intercepting Packets Sent to the Mobile Node's IPv4 home network: Intercepting Packets Sent to the Mobile Node's IPv4 home network:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
be able to receive packets that are sent to the mobile node's IPv4 be able to receive packets that are sent to the mobile node's IPv4
skipping to change at page 18, line 19 skipping to change at page 18, line 38
o On receiving a packet from a correspondent node with the o On receiving a packet from a correspondent node with the
destination address matching a mobile node's IPv4 home address, destination address matching a mobile node's IPv4 home address,
the local mobility anchor MUST forward the packet through the bi- the local mobility anchor MUST forward the packet through the bi-
directional tunnel setup for that mobile node. The format of the directional tunnel setup for that mobile node. The format of the
tunneled packet is shown below. tunneled packet is shown below.
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper layer protocols /* Packet Content*/
Figure 6: Tunneled Packets from LMA to MAG Figure 4: Tunneled Packets from LMA to MAG
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header MUST be routed to the destination specified in the inner
IPv4 packet header. These routed packets will have the source IPv4 packet header. These routed packets will have the source
address field set to the mobile node's IPv4 home address. address field set to the mobile node's IPv4 home address.
3.4. Mobility Options
For supporting IPv4 home address mobility feature, this specification
defines the following new option.
3.4.1. IPv4 Default Router Address Option
A new option, IPv4 Default Router Address Option is defined for using
it in the Proxy Binding Acknowledgment message sent by the local
mobility anchor to the mobile access gateway. This option can be
used for sending the mobile node's IPv4 default router address.
The IPv4 Default Router Address option has an alignment requirement
of 4n. Its format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<IANA>
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST
be set to 6.
Reserved (R)
This 8-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
IPv4 Default Router Address
A four-byte field containing the mobile node's default router
address.
Figure 5: IPv4 Default Router Address Option
4. IPv4 Transport Support 4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [ID-PMIP6] assumes the network The Proxy Mobile IPv6 specification [ID-PMIP6] requires the network
between the local mobility anchor and the mobile access gateway to be between the local mobility anchor and the mobile access gateway to be
an IPv6 network and requires the signaling messages exchanged between an IPv6 network and the signaling messages exchanged between the
the local mobility anchor and the mobile access gateway to be over an local mobility anchor and the mobile access gateway to be over an
IPv6 transport. The extensions defined in this section allow the IPv6 transport. The extensions defined in this section allow the
exchange of signaling messages over an IPv4 transport and when the exchange of signaling messages over an IPv4 transport when the local
local mobility anchor and the mobile access gateway are separated by mobility anchor and the mobile access gateway are separated by an
an IPv4 network and potentially even configured with IPv4 private IPv4 network and are reachable using an IPv4 address.
addresses and with NAT translation devices in the path.
IPv4-Proxy-CoA IPv4-LMAA IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + | | + - - - - - - + |
+--+ +---+ / \ +---+ +--+ +--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+ +--+ +---+ \ / +---+ +--+
+ - - - - - - + + - - - - - - +
Figure 7: IPv4 Transport Network Figure 6: IPv4 Transport Network
When the network between the local mobility anchor and the mobile When the network between the local mobility anchor and the mobile
access gateway is an IPv4 network, the mobile access gateway can access gateway is an IPv4 network, i.e., when both these mobility
potentially register an IPv4 address with the local mobility anchor, entities are configured and reachable using an IPv4 address, the
as the care-of address in the mobile node's Binding Cache entry and mobile access gateway serving a mobile node can potentially register
thus creating an IPv4 tunnel for carrying all the mobile node's 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. traffic.
The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing The Dual Stack Mobile IPv6 specification [ID-DSMIP6] defines protocol
a mobile node to roam over an IPv4 network and the same mechanism is extensions to Mobile IPv6 protocol for allowing a mobile node to roam
extended to Proxy Mobile IPv6. As explained in Section 4.1, of the into an IPv4 network and registers an IPv4 care-of address with the
[ID-DSMIP6], a mobile access gateway MUST send a Proxy Binding Update home agent. The same mechanism is leveraged for extending IPv4
IPv6 message by IPv4 UDP-based encapsulation and route it to the transport support to Proxy Mobile IPv6 protocol. The mobility
local mobility anchor. The processing logic and the on path NAT options for requesting IPv4 transport support, the processing logic
detection logic are just as described in Section 4.1. The signaling and the on-path NAT detection logic is just as described in [ID-
messages will always be IPv6 messages encapsulated in an IPv4 packet DSMIP6]. The following are the key properties of this feature.
and carried as an IPv4 packet. The data traffic to and from the
mobile node will also be encapsulated and carried as IPv4 packets.
This specification does not cover the dynamic discovery of the IPv4
address of the local mobility anchor (IPv4-LMAA) and thus it is
assumed that the mobile access gateway can learn this address from
the mobile node's policy profile or it can obtain this information
through other techniques that are beyond the scope of this document.
4.1. NAT Detection o The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address.
o The configured address on the mobile access gateway can be an IPv4
private address and when it is behind a NAT translation device and
the mechanism specified in Dual Stack Mobile IPv6 specification
[ID-DSMIP6] is again leveraged for NAT detection and traversal.
o The Proxy Mobile IPv6 signaling messages exchanged between the
local mobility anchor and the mobile access gateway for
negotiating the IPv4 transport will be encapsulated and carried as
IPv4 packets. However, these signaling messages are fundamentally
IPv6 messages with the mobility header and the semantics as
specified in base Proxy Mobile IPv6 specification [ID-PMIP6], but
carried as payload in IPv4 packets. Additionally, the mobility
options defined in Dual Stack Mobile IPv6 specification [ID-
DSMIP6] are used for negotiating IPv4 transport support and with a
specific encapsulation mode.
o The IPv4 tunnel established between the local mobility anchor and
the mobile access gateway (with any of the supported encapsulation
modes over IPv4 transport) is used for carrying the mobile node's
IPv4 and IPv6 traffic. 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 the mobile node.
4.1. NAT Support
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 MUST send Proxy Binding Update message encapsulated in the IPv4-UDP
packet. On receiving this Proxy Binding Update packet encapsulated packet. On receiving this Proxy Binding Update packet encapsulated
in an IPv4-UDP packet, the local mobility anchor if it detects a NAT in an IPv4-UDP packet, the local mobility anchor if it detects a NAT
on the path, will send the Proxy Binding Acknowledgment message with on the path, will send the Proxy Binding Acknowledgment message with
the NAT Detection Option. The presence of this option in the Proxy the NAT Detection Option. The presence of this option in the Proxy
Binding Acknowledgment is an indication to the mobile access gateway Binding Acknowledgment is an indication to the mobile access gateway
about the presence of NAT in the path. On detecting the NAT in the about the presence of NAT in the path. On detecting the NAT in the
path, both the local mobility anchor and the mobile access gateway path, both the local mobility anchor and the mobile access gateway
MUST set the encapsulation mode of the tunnel to IPv4-UDP-based MUST set the encapsulation mode of the tunnel to IPv4-UDP-based
encapsulation. The specific details around the NAT detection and the encapsulation. The specific details around the NAT detection and the
related logic is described in in DSMIPv6 specification [ID-DSMIP6]. related logic is described in in DSMIPv6 specification [ID-DSMIP6].
There are discussions on how to incorporate the NAT detection There are discussions on how to incorporate the NAT detection
mechanism of IKE with DSMIPv6 in the MIP6 and the NEMO Working mechanism of IKE with DSMIPv6 in the MEXT Working Groups. This
Groups. This documentation will follow the conclusion of their documentation will follow the conclusion of their discussions.
discussions.
[RYUJI Private addresses MUST NOT be configured at both mobile access
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
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 4.2. Mobile Access Gateway Considerations
4.2.1. Extensions to Binding Update List Entry 4.2.1. Extensions to Binding Update List Entry
For supporting this feature, the conceptual Binding Update List entry For supporting this feature, the conceptual Binding Update List entry
data structure needs to be extended with the following additional data structure needs to be extended with the following additional
parameter, as specified in [ID-DSMIP6] specification and are reviewed parameters, as specified in [ID-DSMIP6] specification and is reviewed
here for convenience. here for convenience.
o The IPv4 Care-of address of the attached mobile node. In this o The IPv4 address registered with the local mobility anchor as the
specification, it can be translated to IPv4 Care-of address of the mobile node's care-of address.
mobile access gateway to which a mobile node is attached.
4.2.2. Signaling Considerations 4.2.2. Signaling Considerations
All the considerations as explained in Section 6.11 of the base Proxy All the considerations as explained in Section 6.11 of the base Proxy
Mobile IPv6 specification apply here. Mobile IPv6 specification apply here.
Network Configurations for IPv4 Transport Signaling Support: Network Configurations for IPv4 Transport Signaling Support:
o If IPv4 transport support is enabled in order to place a mobile o If IPv4 transport support is enabled in order to place a mobile
access gateway at IPv4 only network, the mobile access gateway access gateway at IPv4 only network, the mobile access gateway
skipping to change at page 21, line 16 skipping to change at page 22, line 46
Processing Binding Registrations: Processing Binding Registrations:
o As explained in the DSMIPv6 specification, the mobile access o As explained in the DSMIPv6 specification, the mobile access
gateway can encapsulate a Proxy Binding Update message and carry gateway can encapsulate a Proxy Binding Update message and carry
it in IPv4 and UDP packet. The processing logic for handling the it in IPv4 and UDP packet. The processing logic for handling the
NAT detection at the mobile node is applicable to the mobile NAT detection at the mobile node is applicable to the mobile
access gateway as described in Section 4.1. access gateway as described in Section 4.1.
o An example of proxy binding update sent by mobile access gateway o An example of proxy binding update sent by mobile access gateway
is shown in Figure 8. The source address of the inner IPv6 header 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 MUST set to the IPv6 address assigned to the mobile access gateway
and the destination address MUST be the local mobility anchor's and the destination address MUST be the local mobility anchor's
IPv6 address (LMAA). This is slightly different from [ID-DSMIP6] IPv6 address (LMAA). This is slightly different from [ID-DSMIP6]
. The reason is already mentioned in Section 3.2.2. . The reason is already mentioned in Section 3.2.2.
o The source address of the outer packet MUST be the IPv4-Proxy-CoA o The source address of the outer packet MUST be the IPv4-Proxy-CoA
and the destination MUST be the local mobility anchor's IPv4 and the destination MUST be the local mobility anchor's IPv4
address (IPv4-LMAA). address (IPv4-LMAA).
o The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option o The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option
skipping to change at page 21, line 45 skipping to change at page 23, line 29
header and MUST set T flag in the proxy binding update message. header and MUST set T flag in the proxy binding update message.
The format of the TLV header is defined in section 4.1 of [ID- The format of the TLV header is defined in section 4.1 of [ID-
DSMIP6]. DSMIP6].
o The proxy binding update MUST be protected by IPsec ESP. The o The proxy binding update MUST be protected by IPsec ESP. The
security association for IPv4 addresses of the mobile access security association for IPv4 addresses of the mobile access
gateway and local mobility anchor are pre-established. gateway and local mobility anchor are pre-established.
Constructing the Proxy Binding Update Message: Constructing the Proxy Binding Update Message:
o The mobile access gateway when sending the Proxy Binding Update o For requesting IPv4 transport support, the mobile access gateway
request to the local mobility anchor from an IPv4 networks MUST when sending the Proxy Binding Update request to the local
construct the message as specified below. mobility anchor from an IPv4 networks MUST construct the message
as specified below.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header UDP header
[TLV-header] (Optional, if T flag is set)
IPv6 header (src=Proxy-CoA, dst=LMAA) IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header Mobility header
-BU (P flag is set. F/T flags are optional) -BU (P flag is set. F/T flags are optional)
Mobility Options Mobility Options
- Home Network Prefix Option
- IPv4 Home Address option
- Timestamp option (optional)
- Mobile Node Identifier Option
- Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option
(Optional)
- The IPv4 Care-of Address option(Mandatory) - The IPv4 Care-of Address option(Mandatory)
-
- All the options as required by [ID-PMIP6]
- or as required by any extension documents
-
Figure 8: Proxy Binding Update from mobile access gateway in IPv4 Figure 7: Proxy Binding Update Message Format for IPv4 Transport
network Support
o
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The
address value MUST be set to a mobile access gateway's IPv4 address value MUST be set to mobile access gateway's IPv4 address.
address.
o All the other fields and the options MUST be constructed, as o All the other fields and the options MUST be constructed, as
specified in [ID-PMIP6]. specified in [ID-PMIP6].
Receiving Binding Registration Reply: Receiving Binding Registration Reply:
o After receiving a Proxy Binding Acknowledgment message o After receiving a Proxy Binding Acknowledgment message
encapsulated in an IPv4 packet, the mobile access gateway MUST encapsulated in an IPv4 packet, the mobile access gateway MUST
verify the Proxy Binding Acknowledgment according to the Section verify the Proxy Binding Acknowledgment according to the Section
4.3 of Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 4.3 of Dual Stack Mobile IPv6 specification [ID-DSMIP6].
skipping to change at page 23, line 14 skipping to change at page 24, line 39
o If the Status field in the proxy binding acknowledgment indicates o If the Status field in the proxy binding acknowledgment indicates
the rejection of the binding registration, the mobile access the rejection of the binding registration, the mobile access
gateway MUST NOT enable IPv4 transport for the mobile node's gateway MUST NOT enable IPv4 transport for the mobile node's
traffic. traffic.
Forwarding Packets to Local Mobility Anchor Forwarding Packets to Local Mobility Anchor
o On receiving any packets from the mobile node's IPv6 home address o On receiving any packets from the mobile node's IPv6 home address
and/or IPv4 home address, the mobile access gateway tunnels the and/or IPv4 home address, the mobile access gateway tunnels the
packets to local mobility anchor as shown in Figure 9. If the packets to local mobility anchor as shown in Figure 8. If the
mobile access gateway and the local mobility anchor agreed to use 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 for the UDP tunnel during the binding registration,
the TLV header MUST be presented after the UDP header as shown in the TLV header MUST be presented after the UDP header as shown in
Figure 10. Figure 9.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
[UDP header] /*Only if NAT is detected*/ [UDP header] /*Only if NAT is detected*/
union { /*following either v6 or v4 header */ union { /*following either v6 or v4 header */
IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
} }
Upper layer protocols /*TCP,UDP,SCTP*/ Upper layer protocols /*TCP,UDP,SCTP*/
Figure 9: Tunneled Packets from MAG to LMA Figure 8: Tunneled Packets from MAG to LMA
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header UDP header
TLV header TLV header
union { union {
IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
IPsec IPsec
GRE GRE
} }
Upper layer protocols /*TCP,UDP,SCTP*/ Upper layer protocols /*TCP,UDP,SCTP*/
Figure 10: Tunneled Packets from MAG to LMA using the TLV header Figure 9: Tunneled Packets from MAG to LMA using the TLV header
4.3. Local Mobility Anchor Considerations 4.3. Local Mobility Anchor Considerations
4.3.1. Extensions to Binding Cache Entry 4.3.1. Extensions to Binding Cache Entry
For supporting this feature, the conceptual Binding Cache entry data For supporting this feature, the conceptual Binding Cache entry data
structure needs to be extended with the following additional structure needs to be extended with the following additional
parameter as specified in [ID-DSMIP6] specification and are reviewed parameter as specified in [ID-DSMIP6] specification and are reviewed
here for convenience. here for convenience.
skipping to change at page 25, line 48 skipping to change at page 27, line 28
- Home Network Prefix Option - Home Network Prefix Option
- IPv4 Address Acknowledgement option - IPv4 Address Acknowledgement option
- Timestamp option (optional) - Timestamp option (optional)
- Mobile Node Identifier Option - Mobile Node Identifier Option
- Access Technology Type option (Mandatory) - Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option - Mobile Node Interface Identifier option
(Optional) (Optional)
- NAT Detection Option (Optional) - NAT Detection Option (Optional)
Figure 11: Proxy Binding Acknowledgment in IPv4 network Figure 10: Proxy Binding Acknowledgment in IPv4 network
Forwarding Packets to Mobile Access Gateway Forwarding Packets to Mobile Access Gateway
o When sending any packets meant to a mobile node's IPv4 home o When sending any packets meant to a mobile node's IPv4 home
address or IPv6 home address, the local mobility anchor tunnels address or IPv6 home address, the local mobility anchor tunnels
the packet to mobile access gateway as shown in Figure 12. the packet to mobile access gateway as shown in Figure 11.
IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
[UDP header] /*Only if NAT is detected*/ [UDP header] /*Only if NAT is detected*/
union { /*following either v6 or v4 header */ union { /*following either v6 or v4 header */
IPv4 header (src=IPv4-CN, dst=IPv4-HoA) IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
IPv6 header (src=IPv6-CN, dst=IPv6-HoA) IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
} }
Upper layer protocols /*TCP,UDP,SCTP*/ Upper layer protocols /*TCP,UDP,SCTP*/
Figure 12: Tunneled Packets from LMA to MAG Figure 11: Tunneled Packets from LMA to MAG
o If the mobile access gateway and the local mobility anchor agreed o If the mobile access gateway and the local mobility anchor agreed
to use the TLV header for the UDP tunnel during the binding to use the TLV header for the UDP tunnel during the binding
registration, the TLV header MUST be presented after the UDP registration, the TLV header MUST be presented after the UDP
header as shown in Figure 13. header as shown in Figure 12.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header UDP header
TLV header TLV header
union { union {
IPv4 header (src=IPv4-CN, dst=IPv4-HoA) IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
IPv6 header (src=IPv6-CN, dst=IPv6-HoA) IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
IPsec IPsec
GRE GRE
} }
Upper layer protocols /*TCP,UDP,SCTP*/ Upper layer protocols /*TCP,UDP,SCTP*/
Figure 13: Tunneled Packets from LMA to MAG using the TLV header Figure 12: Tunneled Packets from LMA to MAG using the TLV header
4.4. Tunnel Management 4.4. Tunnel Management
As specified in the Proxy Mobile IPv6 specification, the bi- As specified in the Proxy Mobile IPv6 specification, the bi-
directional tunnel between the local mobility anchor and the mobile directional tunnel between the local mobility anchor and the mobile
access gateway, is a shared tunnel and all the considerations from access gateway, is a shared tunnel and all the considerations from
Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport
as well. as well.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 30, line 17 skipping to change at page 32, line 17
[RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
November 2005. 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)", draft-ietf-mip6-nemo-v4traversal-05.txt
,July 2007. ,July 2007.
[ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-07.txt, November 2007. draft-ietf-netlmm-proxymip6-16.txt, November 2007.
9.2. Informative References 9.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-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-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 Appendix A. DHCP usages for IPv4 home address assignment
There are several other configurations of DHCP entities [RFC-2131] in There are several other configurations of DHCP entities [RFC-2131] in
a Proxy Mobile IPv6 domain other than the two configurations listed a Proxy Mobile IPv6 domain other than the two configurations listed
in Section 3.1. Although this specification recommends the two in Section 3.1. Although this specification recommends the two
configurations described in Section 3.1, operators should select the configurations described in Section 3.1, operators should select the
best configuration according to their deployments scenario. Note best configuration according to their deployments scenario. The
that the mobile node behavior for all scenarios does not change. We mobile node behavior for all scenarios does not change. We do not
do not have major interoperability concerns between multiple have major interoperability concerns between multiple scenarios. A
scenarios. A mobile access gateway and local mobility anchor make mobile access gateway and local mobility anchor make sure that which
sure that which option is used in the Proxy Mobile IPv6 domain based scenario is used in the same Proxy Mobile IPv6 domain based on
on the deployment scenario. deployment requirements. The optional DHCP configurations for IPv4
home address assignment are described below.
In the configurations described in this section, the DHCP messages
MAY be sent across an administrative boundaries. The operators
SHOULD consider to protect these messages crossing the administrative
boundary. The optional DHCP configurations for IPv4 home address
assignment are described below.
o DHCP relay is located in each mobile access gateway and DHCP
server is solely located in the Proxy Mobile IPv6 domain
o DHCP relay is located in both each mobile access gateway and a
local mobility anchor. DHCP server is solely located in the Proxy
Mobile IPv6 domain
In Figure 14, a DHCP relay is co-located with each mobile access
gateway. The DHCP server is located independently in a Proxy Mobile
IPv6 domain. Thus, the address assignment is done between the mobile
access gateway and the DHCP server, but not with the local mobility
anchor. A mobility anchor gateway is configured with the DHCP server
address and relays the DHCP discovery message from the mobile node to
the DHCP server. While the DHCP server offers the IPv4 home address
to the mobile node, the mobile access gateway intercepts the DHCP
offer and starts sending proxy binding update to the local mobility
anchor. As soon as proxy binding registration is completed, the
mobile access gateway sends the DHCP offer back to the mobile node.
The mobile node will send DHCP request and wait for the DHCP
Acknowledgement to/from the DHCP server through the mobility anchor
gateway (i.e. DHCP relay). When multiple local mobility anchors are
available in the Proxy Mobile IPv6 domain, each mobile access gateway
must ensure to relay the DHCP messages to the right DHCP server.
MN MAG(DHCP-R) DHCP-S LMA
|------>|------->| | 1. DHCP discovery
|<------|<-------| | 2. DHCP offer (IPv4 HoA) and Relay
|------>|------->| | 3. DHCP request (IPv4 HoA) and Relay
| |<-------| | 4. DHCP acknowledgement and Relay
| |--------------->| 5. Proxy Binding Update
| |<---------------| 6. Proxy Binding Acknowledgement
| |================| 7. Tunnel/Route Setup
|<------| | | 8. DHCP acknowledgement to client
| | | |
Figure 14: The use of an Independent DHCP relay
Figure 15 is very similar to the Figure 14 except for the local o DHCP relay is co-located with each mobile access gateway and DHCP
mobility anchor being a DHCP relay. In this case, both a mobile server is solely located in the Proxy Mobile IPv6 domain.
access gateway and local mobility anchor relay the DHCP messages from
and to the mobile nodes.
MN MAG(DHCP-R) LMA(DHCP-R) DHCP-S o DHCP relay is co-located with both each mobile access gateway and
|------>|------->|------>| 1. DHCP discovery and Relay a local mobility anchor. DHCP server is solely located behind the
|<------|<-------|<------| 2. DHCP offer (IPv4 HoA) and Relay local mobility anchor in the Proxy Mobile IPv6 domain.
|------>|------->|------>| 3. DHCP request (IPv4 HoA) and Relay
| |<-------|<------| 4. DHCP acknowledgement and Relay
| |------->| | 5. Proxy Binding Update
| |<-------| | 6. Proxy Binding Acknowledgement
| |========| | 7. Tunnel/Route Setup
|<------| | | 8. DHCP acknowledgement to client
| | | |
* Tunnel setup(no.5) and DHCP offer/request/ack(no.6-8)
are processed in parallel.
Figure 15: The use of double DHCP relays on MAG and LMA 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 (Editor) Ryuji Wakikawa
Faculty of Environment and Information Studies, Keio University Keio University
Department of Environmental Information, Keio University.
5322 Endo 5322 Endo
Fujisawa, Kanagawa 252-8520 Fujisawa, Kanagawa 252-8520
Japan Japan
Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/
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
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 95 change blocks. 
395 lines changed or deleted 446 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/