draft-ietf-netlmm-pmip6-ipv4-support-01.txt   draft-ietf-netlmm-pmip6-ipv4-support-02.txt 
NETLMM Working Group R. Wakikawa 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: January 10, 2008 Cisco Expires: May 22, 2008 Cisco
July 9, 2007 November 19, 2007
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-01.txt draft-ietf-netlmm-pmip6-ipv4-support-02.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 January 10, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies extensions to the Proxy Mobile IPv6 protocol This document specifies extensions to Proxy Mobile IPv6 protocol for
[ID-PMIP6] for supporting IPv4. The scope of the IPv4 support in supporting IPv4 protocol. The scope of this IPv4 support includes
Proxy Mobile IPv6 includes the support for the mobile node's IPv4 the support for the mobile node's IPv4 home address mobility and for
home address mobility and for supporting the scenario where the local allowing the mobility entities in the Proxy Mobile IPv6 domain to
mobility anchor and the mobile access gateway are separated by an exchange signaling messages over IPv4 transport. The solution
IPv4 transport network. The solution primarily leverages the leverages the extensions defined in DSMIPv6 specification for
extensions defined in Dual Stack Mobile IPv6 specification [ID- achieving this.
DSMIP6] for achieving this.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7
3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7 3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7
3.2. Extensions to Conceptual Data Structure . . . . . . . . . 9 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 10
3.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Extensions to Binding Update List Entry . . . . . . . 10
3.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 9 3.2.2. Signaling Considerations . . . . . . . . . . . . . . . 10
3.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 13 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 19
4.1. Mobility Options . . . . . . . . . . . . . . . . . . . . . 13 4.1. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Extensions to Conceptual Data Structure . . . . . . . . . 13 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 20
4.3. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Extensions to Binding Update List Entry . . . . . . . 20
4.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 14 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 20
4.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 16 4.3. Local Mobility Anchor Considerations . . . . . . . . . . . 24
4.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 18 4.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 24
4.3.2. Signaling Considerations . . . . . . . . . . . . . . . 24
4.4. Tunnel Management . . . . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. DHCP usages for IPv4 home address assignment . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 34
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 infrastructure. Thus, it is reasonable to assume that the same network infrastructure. Thus, it is reasonable to assume that a
mobile node, mobile access gateway and the local mobility anchor are mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
both IPv4 and IPv6 enabled and further it is also reasonable to IPv6-only or in dual-stack mode and additionally the network between
expect the same mobility infrastructure to provide both IPv4 and IPv6 the mobile access gateway and a local mobility anchor may be an IPv4-
address mobility for a mobile node. The motivation and scope of IPv4 only network. It is also reasonable to expect the same mobility
support in Mobile IPv6 is summarized in [ID-DSMIP6-PS]. infrastructure in a Proxy Mobile IPv6 domain to provide mobility to
the mobile node's operating in IPv4, IPv6 or in dual mode and when
the network between the local mobility anchor and the mobile access
gateway is an IPv4 network. The motivation and scope of IPv4 support
in Mobile IPv6 is summarized in [RFC-4977].
The Proxy Mobile IPv6 base specification [ID-PMIP6] defines a The Proxy Mobile IPv6 protocol[ID-PMIP6] specifies a mechanism for
network-based mobility management protocol. The protocol specifies a providing IPv6 home address mobility support to a mobile node in a
solution for providing IPv6 home address mobility for a mobile node Proxy Mobile IPv6 domain and when there is an IPv6 transport network
and over an IPv6 transport network separating the entities involved separating the entities involved in the mobility management. The
in the mobility management. This specification defines extensions to extensions defined in this document are for extending IPv4 support to
the Proxy Mobile IPv6 protocol for supporting IPv4. The scope of the Proxy Mobile IPv6 protocol [ID-PMIP6].
these IPv4 related extensions are the following:
o IPv4 Home Address Mobility: A mobile node operating in IPv4-only The scope of IPv4 support in Proxy Mobile IPv6 includes the support
mode or in a dual-stack mode should be able to obtain an IPv4 home for the following two features:
address and roam anywhere in that Proxy Mobile IPv6 domain.
o IPv4 Transport Network Support: The transport network between the o IPv4 Home Address Mobility Support: A mobile node that has IPv4
local mobility anchor and the mobile access gateway is an IPv4 stack enabled will be able to obtain an IPv4 address and be able
network and further the local mobility anchor or the mobile access to use that address from any of the access networks in that Proxy
gateway may be using IPv4 private addresses and with NAT Mobile IPv6 domain. The mobile node is not required to be
translation devices on the path allocated or assigned an IPv6 address for enabling IPv4 home
address support.
The Dual-Stack Mobile IPv6 specification [ID-DSMIP6], extends IPv4 o IPv4 Transport Support: The mobility entities in the Proxy Mobile
home address mobility and IPv4 transport network support to the IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling
Mobile IPv6 protocol [RFC-3775]. The solution specified in this messages over an IPv4 transport and further the local mobility
document leverages the DSMIP6 extensions for extending IPv4 support anchor or the mobile access gateway may be using IPv4 private
to Proxy Mobile IPv6 protocol. The protocol semantics, processing addresses and with NAT [RFC-3022] translation devices separating
logic and mobility header options, such as IPv4 home address option, them.
IPv4 address acknowledgment option and NAT detection option, defined
in the DSMIP6 specification, are all applied for Proxy Mobile IPv6
protocol. As specified in DSMIPv6, these two features, IPv4 Home
Address Mobility support and IPv4 transport support, are independent
of each other and implementers may choose to implement any one or
both of these features. Unlike in DSMIP6, a mobile node in Proxy
Mobile domain is NOT required to have an IPv6 home address for
obtaining IPv4 home address mobility.
As specified in the Proxy Mobile IPv6 specification [ID-PMIP6], this The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address
specification assumes that the link between the mobile access gateway mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC-
and the local mobility anchor is a point-to-point link. This 3775]. The solution specified in this document leverages these
specification also assumes that the local mobility anchor and the extensions for enabling IPv4 support to Proxy Mobile IPv6 protocol.
mobile access gateway are both IPv6 capable and IPv6 enabled and even These two features, the IPv4 Home Address Mobility support and IPv4
when the network between the mobile access gateway and a local transport support features, are independent of each other and
mobility anchor is IPv4-only network. The signaling protocol is deployments can choose to enable any one or both of these features.
primarily based on Mobile IPv6 and hence the entities providing the
network-based mobility management service must be IPv6 enabled. 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 network 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 translation device and configured with an IPv4 be behind a NAT [RFC-3022] translation device and configured with an
private address. IPv4 private address.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA1 -> | | <-- IPv4-LMAA2 IPv4-LMAA1 -> | | <-- IPv4-LMAA2
| | | |
\\ //\\ \\ //\\
[NAT] // \\ [NAT] // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // [NAT] \\ // [NAT]
\\ // \\ \\ // \\
IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2 IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2
+----+ +----+ +----+ +----+
|MAG1|-----[MN2] |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
| | | | | |
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
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]. 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], interpreted as defined in Mobile IPv6 specification [RFC-3775], Dual
DSMIP6 specification [ID-DSMIP6] and Proxy Mobile IPv6 specification Stack Mobile IPv6 specification [ID-DSMIP6] and Proxy Mobile IPv6
[ID-PMIP6]. In addition the document introduces the following terms. specification [ID-PMIP6]. In addition the document introduces the
following terms.
IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)
The IPv4 Care-of Address that is configured on the interface of The IPv4 address that is configured on the interface of the mobile
the mobile access gateway and is the transport endpoint of the access gateway and is the transport endpoint of the tunnel between
tunnel between a local mobility anchor and a mobile access a local mobility anchor and a mobile access gateway. This address
gateway. However, when the configured address is a private IPv4 will be used as the source address for the signaling messages sent
address and with a NAT device in the path to the local mobility by the mobile access gateway to the local mobility anchor and will
anchor, the care-of address as seen by the local mobility anchor be the registered Care-of address in the mobile node's Binding
will be the address allocated by the NAT device for the mobility Cache entry. However, when the configured address is a private
session. IPv4 address and with a NAT device in the path to the local
mobility anchor, the care-of address as seen by the local mobility
anchor will be the address allocated by the NAT device for that
flow.
IPv4 Local Mobility Anchor Address (IPv4-LMAA) IPv4 Local Mobility Anchor Address (IPv4-LMAA)
The global IPv4 address that is typically configured on the The IPv4 address that is configured on the interface of a local
interface of a local mobility anchor and is the transport endpoint mobility anchor and is the transport endpoint of the tunnel
of the tunnel between a local mobility anchor and a mobile access between the local mobility anchor and the mobile access gateway.
gateway. This is the address to where a mobile access gateway This is the address to where the mobile access gateway sends the
sends proxy binding update messages. If a local mobility anchor Proxy Binding Update messages. If the local mobility anchor is
is configured behind NAT, IPv4-LMAA is the IPv6 global address of configured to be behind a NAT device, this address will be the
the NAT box. According to Section 2.1 of [ID-DSMIP6], two options address allocated by the NAT device for that flow.
are introduced for the case of the home agent being behind the NAT
box. When we interpret this two options for Proxy Mobile IPv6, it
goes following. 1) configure a public IPv4 address for each local
mobility anchor on the NAT box. 2) configure one public address
and make the local mobility anchors share the public address.
3. IPv4 Home Address Mobility Support 3. IPv4 Home Address Mobility Support
Using the extensions defined in this specification, a mobile node An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6
operating in an IPv4-only or dual-stack mode will be able to obtain domain, the network will ensure the mobile node will be able to
an IPv4 address (IPv4-MN-HoA) and will be able to roam in that Proxy obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for
Mobile IPv6 domain using that address. Although IPv6 home address is the interface attached to the access network in that Proxy Mobile
always required in [ID-DSMIP6], this specification does not mandate IPv6 domain. Using the extensions defined in this specification, the
IPv6 home address unless a mobile node wants the IPv6 home address. mobile access gateway on the access network will exchange the
The network will provide mobility to that mobile node in that entire signaling messages with the mobile node's local mobility anchor and
domain. And further, the network will ensure that the mobile node will setup the required routing state for that home address.
will always be able to obtain the same IPv4 address, as it moves
between access links and as long as the mobile node is in the scope If the mobile node connects to the Proxy Mobile IPv6 domain, through
of that Proxy Mobile IPv6 domain. 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
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 policy on the mobile access gateway 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.
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, IPCP or IKEv2 that address configuration procedures, such as DHCP [RFC-2131], IPCP or
are supported on that access link, will be able to obtain its IPv4 IKEv2 that are supported on that access link, will be able to obtain
home address configuration. The IPv4 home address configuration required information for its IPv4 home address configuration. The
includes the IPv4 home address, the IPv4 home network prefix and IPv4 required information includes the IPv4 home address, the IPv4 home
home network prefix length. network prefix and IPv4 home network prefix length. Any available
IPv4 address configuration mechanisms can be used such as static
configuration method specific to the access link or dynamic
configuration from DHCP.
Figure 2 shows the operational sequence of the home address mobility When a mobile node is configured with a static IPv4 home address, the
support when a local mobility anchor assigns an IPv4 Home Address IPv4 home address information SHOULD be stored in the mobile node's
dynamically to a mobile node. All mobile access gateways SHOULD policy profile. The mobile access gateway where the mobile node
support minimal functionality of DHCP server in order to send DHCP attached obtains the static IPv4 home address from the policy
offer and and acknowledgment messages to the mobile node in reply to profile. The mobile access gateway MUST set the known IPv4 home
the DHCP discovery and request messages. The mobile access gateway prefix to the IPv4 Home Address field and the Pref field of the IPv4
is seen as a DHCP server from a mobile node, but it actually obtains home address option [ID-DSMIP6]. This option is carried by a proxy
the IPv4 home address for each mobile node from the local mobility binding update described in [ID-PMIP6].
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-DSMIP]). The mobile access gateway MUST return its own IP
address in the 'server identifier' option when sending DHCP offer
message 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.4. Any information
carried in DHCP options such as addresses of domain name server, time
server, lpr server, etc. MUST be configured in all the mobile access
gateway (i.e. DHCP server) if necessary. If IPCP is used for
address assignment, DHCP events in Figure 2 are replaced by PPP
events.
MN MAG(DHCPS) LMA 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
relay agent on the link will ensure the mobile node is assigned an
address from its home network prefix. There are several
configurations where the DHCP entities are located in a Proxy Mobile
IPv6 domain. This document recommends following two configurations
as default operations. The other configurations are explained in
Appendix A.
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
relay is co-located with each mobile access gateway
Figure 2 shows the operational sequence of the home address
assignment when a DHCP server is co-located with each mobile access
gateway. In this scenario, a DHCP server (i.e. mobile access
gateway) interacts with a DHCP client on a mobile node, while a local
mobility anchor actually provides an IPv4 Home Address dynamically to
a mobile node during proxy binding registration. 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. The mobile
access gateway is seen as a DHCP server from a mobile node, but 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]). The mobile access gateway MUST return its
own IP address in the 'server identifier' option when sending DHCP
offer message 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. Any
information carried in DHCP options such as addresses of domain name
server, time server, lpr server, etc. MUST be configured in all the
mobile access gateway (i.e. DHCP server) if necessary.
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
| | | | | |
* 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.
** MAG SHOULD return its own IP address in the 'server identifier'
option when sending DHCP offer.
Figure 2: An example when LMA assigns an IPv4 home address Figure 2: An example when LMA assigns an IPv4 home address
In addition to this, other address configuration mechanisms including In the second scenario, a DHCP relay is co-located at each mobile
static configuration methods specific to the access link or dynamic access gateway and a DHCP server is co-located at a local mobility
configuration from the DHCP server (without local mobility anchor anchor. The mobile access gateway learns the IPv4 home address from
involvmenet) may also be in place. Several other assignment schems the DHCP reply and sends that information to the mobile node by DHCP
are listed: offer message. Meanwhile, it notifies the assigned IPv4 home address
by an IPv4 home address option in a proxy binding update to the local
mobility anchor. In this case, the local mobility anchor does not
allocate any address, but only deals with route setup and tunnel
setup for the requested home address. Note that all the IPv4 home
addresses managed in the DHCP server 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. In addition, 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. Figure 3 are the sequence of IPv4 home address
assignment using DHCP Relay.
o Static IPv4 Home Address Assignment: When a mobile node is MN MAG(DHCP-R) LMA(DHCP-S)
configured with a static IPv4 home address, the IPv4 home address |------>|------->| 1. DHCP discovery to DHCP-S through DHCP-R
information MUST be stored in the mobile node's policy profile. |<------|<-------| 2. DHCP offer (IPv4 HoA)
The mobile access gateway where the mobile node attached obtains |------>|------->| 3. DHCP request (IPv4 HoA)
the static IPv4 home address from the policy profile. The mobile | |<-------| 4. DHCP acknowledgement
access gateway MUST set the known IPv4 home prefix to the IPv4 | |------->| 5. Proxy Binding Update
Home Address field and the Pref field of the IPv4 home address | |<-------| 6. Proxy Binding Acknowledgement
option [ID-DSMIP6]. This option is carried by a proxy binding | |========| 7. Tunnel/Route Setup
update described in [ID-PMIP6]. |<------| | 8. DHCP acknowledgement
| | |
o Dynamic IPv4 Home Address Assignment from DHCP Server: If DHCP is Figure 3: The use of DHCP relay
used for the IPv4 home address allocation, a DHCP server and a
DHCP relay agent on the link will ensure the mobile node is
assigned an address from its home network prefix. In this case,
the local mobility anchor only deals with route setup and tunnel
setup for the requested home address. A DHCP relay and a mobile
access gateway should be co-located. Otherwise, the mobile access
gateway MUST learn the IPv4 home address from the DHCP reply.
Meanwhile, it notifies the assigned IPv4 home address by an IPv4
home address option in a proxy binding update to the local
mobility anchor. Some remarks can be found in Section 6.
3.2. Extensions to Conceptual Data Structure 3.2. Mobile Access Gateway Considerations
There are certain extensions defined in DSMIP specification [DSMIP6] 3.2.1. Extensions to Binding Update List Entry
for supporting IPv4 home address mobility support. A mobile node can
obtain only IPv4 home address by this specification, while DSMIP
requires IPv6 home address for IPv4 home address support. Thus, a
mobile access gateway and a local mobility agent MUST create a
binding update list and a binding cache only for IPv4 home address
assigned to a mobile node.
3.3. Mobility Options For supporting this feature, the conceptual Binding Update List entry
data structure needs to be extended with the following additional
parameter, as specified in [ID-DSMIP6] specification and are
presented here for convenience.
For supporting the IPv4 home address mobility, the following options o The IPv4 home address of the attached mobile node. The IPv4 home
are required from the DSMIPv6 specification [ID-DSMIP6]. address value is acquired from the mobile node's local mobility
anchor through the received Proxy Binding Acknowledgment messages.
o IPv4 Home Address Option defined in section 3.1.1 of [ID-DSMIP6]. 3.2.2. Signaling Considerations
This option MUST be present in the Proxy Binding Update message
sent by the mobile access gateway to the local mobility anchor,
when requesting IPv4 home address support.
o IPv4 Address Acknowledgment Option defined in section 3.2.1 of All the considerations explained in Section 6.11 of the base Proxy
[ID-DSMIP6]. This option MUST be present in the Proxy Binding Mobile IPv6 specification apply here. For supporting IPv4 home
Acknowledgment, if the local mobility anchor accepts IPv4 home address mobility feature, the following additional considerations
address support. MUST be applied.
3.4. Mobile Access Gateway Operation Mobile Node Attachment and Initial Binding Registration:
o All the considerations as explained in Section 6.11 of the base o After detecting a new mobile node on its access link, the mobile
Proxy Mobile IPv6 specification apply here. access gateway must identify the mobile node and acquire its MN-
Identifier. If it determines that the IPv4 home address mobility
service needs to be offered to the mobile node, it MUST send a
Proxy Binding Update message to the local mobility anchor. The
message MUST include the IPv4 Home Address option, defined in
section 3.1.1 of [ID-DSMIP6]. The mobile access gateway MAY also
include the IPv6 Home Network Prefix option in the same message
for requesting IPv6 home address support in addition to IPv4 home
address support for the mobile node.
o If the mobile access gateway learns the mobile node's IPv4 home
network prefix or the IPv4 home address either from its policy
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
attached, will register this 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 as shown in Figure 4. 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 only IPv4 capable node, 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.
Receiving Binding Registration Reply:
o If the received Proxy Binding Acknowledgement message has neither
an IPv4 Address Acknowledgement option or a Home Network Prefix
option present, the mobile access gateway MUST ignore the Proxy
Binding Acknowledgement and MUST NOT enable routing for the mobile
node's IPv4 Home Address or IPv6 home address traffic. However,
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
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
Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST update a Binding Update List entry and
must setup a tunnel to the local mobility anchor and must also add
a default route over the tunnel for all the mobile node's IPv4
traffic. The encapsulation mode for the bi-directional tunnel set
to IPv4-In-IPv6 mode. The considerations from Section 6.10 [ID-
PMIP6] apply.
Extending Binding Lifetime:
o For extending the binding lifetime of a currently registered
mobile node , the mobile access gateway MUST send a Proxy Binding
Update message to the local mobility anchor with a non zero
lifetime value. 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.
Mobile Node Detachment and Binding De-Registration:
o As specified in Section 6.9.1 [ID-PMIP6], at any point in time,
when the mobile access gateway detects that the mobile node has
moved away from its access link, it SHOULD send a Proxy Binding
Update message to the local mobility anchor with the lifetime
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 mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor for requesting IPv4 home
address mobility support MUST construct the message as specified
below.
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
address of the mobile access gateway.
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.
o All the other fields and the options MUST be constructed, as
specified in [ID-PMIP6].
DHCP Messages from the mobile node:
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 a 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 network prefix as discussed in Section 3.1. The
mobile access gateway on the access link where mobile node is 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 3. The proxy binding proxy binding update as shown in Figure 4
update MUST be protected by IPsec ESP. How to build the IPv4 home
address option is varied as follows:
* If a mobile access gateway needs to request dynamic IPv4 home o When a mobile node obtains an IPv4 home address from DHCP server,
address allocation to the local mobility anchor, it MUST set the mobile access gateway SHOULD record the assigned IPv4 home
0.0.0.0 in the the IPv4 Home Address field of the IPv4 home address in the policy profile. A new mobile access gateway can
address option as described in [ID-DSMIP] and send this option send a proxy binding update when a mobile node roams to the new
by the proxy binding update. mobile access gateway.
* If a mobile access gateway knows the IPv4 home prefix (or home o When a mobile node first attaches to a Proxy Mobile IPv6 domain, a
address) for the mobile node from static mobile node's policy mobile access gateway triggers a proxy binding update by following
profile or DHCP server, it MUST set the known IPv4 home prefix conditions. It is rarely happened that the DHCP procedure and
to the IPv4 Home Address field and the Pref field of the IPv4 proxy binding procedure run at the same time except for the
home address option. This option is carried by a proxy binding initial attachment.
update described in Proxy Mobile IPv6 specification [ID-PMIP6].
IPv6 header (src=PCoA, dst=LMAA) * When a mobile access gateway is a DHCP server, it MUST send a
Mobility header proxy binding update right after receiving a DHCP discovery
-BU /*P flag is set*/ message from a mobile node. By sending the proxy binding
Mobility Options update, it will learn the assigned IPv4 home address from the
-HNP* /*IPv6 home address*/ local mobility anchor.
-TSO*
-IPv4-HAO
*HNP: Home Network Prefix Option * When a DHCP relay is co-located with a mobile access gateway,
*TSO: Time Stamp Option the mobile access gateway MUST send a proxy binding update as
soon as it receives a DHCP Acknowledgement message from the
DHCP server. During the proxy binding registration, it MUST
NOT relay the DHCP Acknowledgement message to the DHCP client.
After the proxy binding is successfully registered, the DHCP
relay (i.e. mobile access gateway) MUST forward the DHCP
Acknowledgement to the DHCP client (i.e. mobile node). Before
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.
Figure 3: Proxy Binding Update for IPv4 Home Address Support o After the initial procedure described in above, DHCP runs
independently to the proxy binding registration for renewing the
assigned IPv4 home address. It is not necessary to run DHCP
whenever a mobile node changes its attached mobile access gateway.
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 When a mobile node gets IPv4 home address from Local Mobility
Anchor through DHCP interaction with MAG that supports DHCP server Anchor through DHCP interaction with mobile access gateway that
functionality, the DHCP client in the mobile node recognizes MAG's supports DHCP server functionality, the DHCP client in the mobile
IP address as DHCP server's IP address. Thus, the DHCP client node recognizes mobile access gateway's IP address as DHCP
unicasts DHCP renew to the MAG, when the DHCP client goes into the server's IP address. Thus, the DHCP client unicasts DHCP renew to
DHCP RENEWING state [RFC2131]. However, when the mobile node the mobile access gateway, when the DHCP client goes into the DHCP
handovers to a new MAG, the mobile node does not know the link RENEWING state [RFC-2131]. However, when the mobile node
change and the DHCP client would unicast DHCP request to the handovers to a new mobile access gateway, the mobile node does not
previous MAG whose IP address was acquired from DHCP offer. So, know the link change and the DHCP client would unicast DHCP
DHCP client in the mobile node needs to reconfigure its local request to the previous mobile access gateway whose IP address was
configuration parameters. Therefore, MAG SHOULD discard any DHCP acquired from DHCP offer. So, DHCP client in the mobile node
request message that does not belong to the MAG itself, so that needs to reconfigure its local configuration parameters.
the mobile node should go into the DHCP REBINDING state and Therefore, mobile access gateway SHOULD discard any DHCP request
broadcast DHCP request without server identifier. 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 request without server identifier.
o A proxy binding acknowledgment will be returned by the local 3.3. Local Mobility Anchor Considerations
mobility anchor. In the proxy binding acknowledgment, an IPv4
address acknowledgment option MUST be presented in reply to the
IPv4 home address option. The processing of this IPv4 home
acknowledgment option is found in DSMIP6 specification [ID-
DSMIP6].
o After receiving a Proxy Binding Acknowledgment message with the 3.3.1. Extensions to Binding Cache Entry
IPv4 Address Acknowledgment Option and if the status code in the
Binding Acknowledgment and Status field in the IPv4 Address
Acknowledgment values are set to Success, the mobile access
gateway MUST setup a tunnel to the local mobility anchor and must
also add a default route over the tunnel for all the mobile node's
IPv4 traffic. The encapsulation modes for the bi-directional
tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6
specification [ID-PMIP6] and as in this specification.
o If the Status field in the IPv4 Address Acknowledgment Option For supporting this feature, the conceptual Binding Cache entry data
indicates the rejection of the IPv4 home address mobility service, structure needs to be extended with the following additional
the mobile access gateway MUST not enable IPv4 routing for the parameter, as specified in [ID-DSMIP6] specification and is presented
mobile node's IPv4 traffic. here for convenience.
3.5. Local Mobility Anchor Operation o The IPv4 home address of the registered mobile node. The IPv4
home address value may have been statically configured in the
mobile node's policy profile, it MAY have been assigned by a DHCP
server, or it MAY have been dynamically allocated by the local
mobility anchor.
o Upon receiving a Proxy Binding Update message with the IPv4 Home 3.3.2. Signaling Considerations
Address Option, defined in Section 3.1.1 of DSMIP6 specification
[ID-DSMIP6], the local mobility anchor, if it determines that the
mobile node is configured for IPv4 home address mobility service,
the local mobility anchor MUST send the Proxy Binding
Acknowledgment message with the IPv4 Address Acknowledgment
Option, defined in Section 3.2.1 of DSMIP6 specification. How to
process the IPv4 home address option and how to return the IPv4
address acknowledgment are described in [ID-DSMIP6].
IPv6 header (src=PCoA, dst=LMAA) All the considerations explained in Section 5.3 [ID-PMIP6] apply
here. For supporting IPv4 home address mobility feature, the
following additional considerations MUST be applied.
Processing Binding Registrations:
o If there is an IPv4 Home Address option present in the request,
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
Node Identifier Option [RFC-4283] present in the Proxy Binding
Update request and MUST apply multihoming considerations specified
in Section 5.4 [ID-PMIP6] and from this section for performing the
Binding Cache entry existence test.
o If there is no existing Binding Cache entry that matches the
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
address field of the proxy binding update message.
o If the IPv4 Home Address option present in the Proxy Binding
Update request has the value of 0.0.0.0, the local mobility anchor
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
address for the mobile node, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to 130
(Insufficient resources).
o Upon accepting the request, the local mobility anchor MUST create
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:
o The multihoming considerations specified in Section 5.4 [ID-PMIP6]
allows the local mobility anchor to perform the Binding Cache
entry existence test for identifying the mobility session, by
using the mobile node identifier, interface identifier and the
Home Network Prefix values. When using an 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
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:
o The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST
construct the message as specified below.
IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header Mobility header
-BA /*P flag is set*/ -BA /*P flag is set*/
Mobility Options Mobility Options
-HNP* /*IPv6 home address*/ - Timestamp option (optional)
-TSO* - Mobile Node Identifier Option
-IPv4-ACK - Access Technology Type option (Mandatory)
-IPv4-DRA - Mobile Node Interface Identifier option
*HNP: Home Network Prefix Option (Optional)
*TSO: Time Stamp Option
Figure 4: Proxy Binding Acknowledgement for IPv4 Home Address - IPv4 Address Acknowledgement Option (Mandatory)
Figure 5: Proxy Binding Acknowledgement for IPv4 Home Address
Support Support
o After accepting the registration for the mobile node's IPv4 home o The destination address field of the IPv6 header MUST be set to
address, the local mobility anchor will add an IPv4 host route the mobile access gateway.
over the tunnel to the mobile access gateway. Any IPv4 packets
that the local mobility anchor receives from a correspondent node o The IPv4 Address Acknowledgement option MUST be present in the
will be tunneled to the mobile access gateway over the bi- Proxy Binding Acknowledgement message. If both the IPv4 Home
directional tunnel, and then routed accordingly after removing the Address option and the IPv6 Home Network Prefix option were not
tunnel header. The encapsulation modes for the bi-directional present in the Proxy Binding Update request and if the Status
tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6 field value in the message is set to
specification [ID-PMIP6] and as in this specification. 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
specified in [ID-PMIP6].
3.3.3. Routing Considerations
Forwarding Considerations for the mobile node's IPv4 home address
traffic.
Intercepting Packets Sent to the Mobile Node's IPv4 home network:
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
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 On receiving a packet from a correspondent node with the
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 */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 6: Tunneled Packets from LMA to MAG
Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner
IPv4 packet header. These routed packets will have the source
address field set to the mobile node's IPv4 home address.
4. IPv4 Transport Support 4. IPv4 Transport Support
As per the Proxy Mobile IPv6 specification [ID-PMIP6], the transport The Proxy Mobile IPv6 specification [ID-PMIP6] assumes the network
network between the local mobility anchor and the mobile access between the local mobility anchor and the mobile access gateway to be
gateway is an IPv6 network. This specification defines extensions an IPv6 network and requires the signaling messages exchanged between
for supporting the scenario where the local mobility anchor and the the local mobility anchor and the mobile access gateway to be over an
mobile access gateway may be separated by an IPv4 transport network IPv6 transport. The extensions defined in this section allow the
and further these entities may be configured with IPv4 private exchange of signaling messages over an IPv4 transport and when the
local mobility anchor and the mobile access gateway are separated by
an IPv4 network and potentially even configured with IPv4 private
addresses and with NAT translation devices in the path. addresses and with NAT translation devices in the path.
IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + |
+--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+
+ - - - - - - +
Figure 7: 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, the mobile access gateway can
potentially register an IPv4 address with the local mobility anchor, potentially register an IPv4 address with the local mobility anchor,
as the care-of address in the mobile node's binding cache entry and as the care-of address in the mobile node's Binding Cache entry and
thus creating an IPv4 tunnel for carrying all the mobile node's thus creating an IPv4 tunnel for carrying all the mobile node's
traffic. traffic.
The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing
a mobile node to roam over an IPv4 network and the same solution can a mobile node to roam over an IPv4 network and the same mechanism is
be extended to Proxy Mobile IPv6. As explained in Section 4.1, of extended to Proxy Mobile IPv6. As explained in Section 4.1, of the
the DSMIPv6 specification, a mobile access gateway can encapsulate a [ID-DSMIP6], a mobile access gateway MUST send a Proxy Binding Update
Proxy Binding Update IPv6 message in an IPv4-UDP packet and route it IPv6 message by IPv4 UDP-based encapsulation and route it to the
to the local mobility anchor. The processing logic and the on path local mobility anchor. The processing logic and the on path NAT
NAT detection logic is just as described in Section 4.3. The detection logic are just as described in Section 4.1. The signaling
signaling messages will always be IPv6 messages encapsulated in an messages will always be IPv6 messages encapsulated in an IPv4 packet
IPv4 packet and carried as an IPv4 packet. The data traffic to and and carried as an IPv4 packet. The data traffic to and from the
from the mobile node will also be encapsulated and carried as IPv4 mobile node will also be encapsulated and carried as IPv4 packets.
packets. This specification does not cover the dynamic discovery of This specification does not cover the dynamic discovery of the IPv4
the IPv4 address of the local mobility anchor (IPv4-LMAA) and thus it address of the local mobility anchor (IPv4-LMAA) and thus it is
is assumed that the mobile access gateway can learn this address from assumed that the mobile access gateway can learn this address from
the mobile node's policy profile or it can obtain this information the mobile node's policy profile or it can obtain this information
through other techniques that are beyond the scope of this document. through other techniques that are beyond the scope of this document.
4.1. Mobility Options 4.1. NAT Detection
For supporting IPv4 transport support, the following options are
required from the DSMIP6 specification [ID-DSMIP6].
o NAT detection Option, defined in section 3.2.2 of the DSMIP
specification [ID-DSMIP6]. This option MUST be present in the
Proxy Binding Acknowledgment when the local mobility anchor
detects NAT in the path between mobile access gateway and itself.
4.2. Extensions to Conceptual Data Structure
There are certain extensions defined in DSMIP6 specification [ID-
DSMIP6] for supporting this feature.
4.3. NAT Detection
The NAT detection logic in Proxy Mobile IPv6 is just as specified in
DSMIP6 specification.
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 an 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
will set the encapsulation mode of the tunnel to IPv4-UDP. The MUST set the encapsulation mode of the tunnel to IPv4-UDP-based
specific details around the NAT detection and the related logic is encapsulation. The specific details around the NAT detection and the
described in in Dual Stack for Mobile IPv6 specification [ID-DSMIP6]. related logic is described in in DSMIPv6 specification [ID-DSMIP6].
4.4. Mobile Access Gateway Operation There are discussions on how to incorporate the NAT detection
mechanism of IKE with DSMIPv6 in the MIP6 and the NEMO Working
Groups. This documentation will follow the conclusion of their
discussions.
o All the considerations as explained in Section 6.11 of the base 4.2. Mobile Access Gateway Considerations
Proxy Mobile IPv6 specification apply here.
4.2.1. Extensions to Binding Update List Entry
For supporting this feature, the conceptual Binding Update List entry
data structure needs to be extended with the following additional
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
specification, it can be translated to IPv4 Care-of address of the
mobile access gateway to which a mobile node is attached.
4.2.2. Signaling Considerations
All the considerations as explained in Section 6.11 of the base Proxy
Mobile IPv6 specification apply here.
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
MUST have an IPv4 address at the visiting network. In addition to MUST have an IPv4 address at the visiting network. In addition to
that, the mobile access gateway MUST also obtain IPv6 address that, the mobile access gateway MUST obtain an IPv6 address
configured for the Proxy Mobile IPv6 operation. Even if the configured for the Proxy Mobile IPv6 operation. Even if the
mobile access gateway does not have connectivity to the IPv6 mobile access gateway does not have connectivity to the IPv6
network, it MUST configure with an IPv6 address for sending the network, it MUST configure with an IPv6 address for sending the
proxy binding registration to the local mobility anchor. proxy binding registration to the local mobility anchor.
o As explained in Section 4.1, of the DSMIPv6 specification, the Processing Binding Registrations:
mobile access gateway can encapsulate a Proxy Binding Update
message and carry it in IPv4 and UDP packet. The processing logic o As explained in the DSMIPv6 specification, the mobile access
for handling the NAT detection at the mobile node is applicable to gateway can encapsulate a Proxy Binding Update message and carry
the mobile access gateway as described in Section 4.3. An example it in IPv4 and UDP packet. The processing logic for handling the
of proxy binding update sent by mobile access gateway is shown in NAT detection at the mobile node is applicable to the mobile
Figure 5. Note that the source address of the inner IPv6 header access gateway as described in Section 4.1.
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
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). The source address of the outer packet MUST IPv6 address (LMAA). This is slightly different from [ID-DSMIP6]
be the IPv4-proxy-CoA and the destination MUST be the local . The reason is already mentioned in Section 3.2.2.
mobility anchor's IPv4 address (IPv4-LMAA). For the NAT handling,
UDP header MUST be always used for the proxy binding update. The
UDP port number is defined in [ID-DSMIP6]. The proxy binding
update MUST be protected by IPsec ESP. The security association
for IPv4 addresses of the mobile access gateway and local mobility
anchor are pre-established.
IPv4 header (src=IPv4-proxy-CoA, dst=IPv4-LMAA) 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
address (IPv4-LMAA).
o The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option
defined in section 3.1.2 of [ID-DSMIP6].
o For the NAT handling, the UDP-based encapsulation MUST be always
used for the proxy binding update. The UDP port number is defined
in [ID-DSMIP6].
o If the mobile access gateway requested to use the TLV header for
the UDP encapsulation, it MUST insert a TLV header after the UDP
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-
DSMIP6].
o The proxy binding update MUST be protected by IPsec ESP. The
security association for IPv4 addresses of the mobile access
gateway and local mobility anchor are pre-established.
Constructing the Proxy Binding Update Message:
o The mobile access gateway when sending the Proxy Binding Update
request to the local mobility anchor from an IPv4 networks MUST
construct the message as specified below.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header UDP header
IPv6 header (src=v6MAG*, dst=LMAA) [TLV-header] (Optional, if T flag is set)
IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header Mobility header
-BU /*P flag is set*/ -BU (P flag is set. F/T flags are optional)
Mobility Options Mobility Options
-HNP* /*IPv6 home address*/ - Home Network Prefix Option
-TSO* - IPv4 Home Address option
-IPv4-HAO /*if IPv4 HoA is required*/ - Timestamp option (optional)
-NAI /* NAI Option */ - Mobile Node Identifier Option
- Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option
(Optional)
*HNP: Home Network Prefix Option - The IPv4 Care-of Address option(Mandatory)
*TSO: Time Stamp Option
*v6MAG: IPv6 address assigned to the mobile access gateway.
*NAI: NAI Option
Figure 5: Proxy Binding Update from mobile access gateway in IPv4 Figure 8: Proxy Binding Update from mobile access gateway in IPv4
network network
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.
o All the other fields and the options MUST be constructed, as
specified in [ID-PMIP6].
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 DSMIP6 specification [ID-DSMIP6]. 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 tunnel to the local mobility anchor and add a default
route over the tunnel for all the mobile node's IPv6 traffic. If route over the tunnel for all the mobile node's traffic.
the NAT is available and the NAT detection option is presented in
the Proxy Binding Acknowledgment, the mobile access gateway MUST o If the NAT is available and the NAT detection option is presented
use UDP tunnel to traverse the NAT and MUST send a proxy binding in the Proxy Binding Acknowledgment, the mobile access gateway
update every refresh time specified in the NAT detection option. MUST use the UDP tunnel to traverse the NAT for mobile node's
The detailed operation can be found in DSMIP6 specification [ID- traffic and MUST send a proxy binding update every refresh time
DSMIP6]. specified in the NAT detection option. The detailed operation can
be found in Dual Stack Mobile IPv6 specification [ID-DSMIP6].
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
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 6 packets to local mobility anchor as shown in Figure 9. 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 10.
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 6: Tunneled Packets from MAG to LMA Figure 9: Tunneled Packets from MAG to LMA
4.5. Local Mobility Anchor Operation IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header
TLV 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 10: Tunneled Packets from MAG to LMA using the TLV header
4.3. Local Mobility Anchor Considerations
4.3.1. Extensions to Binding Cache Entry
For supporting this feature, the conceptual Binding Cache entry data
structure needs to be extended with the following additional
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
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
When a mobile node is attached to a mobile access gateway that is When a mobile node is attached to a mobile access gateway that is
reachable only through an IPv4 transport network, the local mobility reachable only through an IPv4 transport network, the local mobility
anchor must establish an IPv4 tunnel for routing the mobile node's anchor must establish an IPv4 tunnel for routing the mobile node's
IPv4 and IPv6 home address traffic. The DSMIPv6 specification IPv4 and IPv6 home address traffic. The DSMIPv6 specification
provides the semantics on how the IPv4 tunnel needs to be negotiated provides the semantics on how the IPv4 tunnel needs to be negotiated
and the detection logic of the NAT devices. This specification and the detection logic of the NAT devices. This specification
leverages the NAT Detection Option, defined in the DSMIP6 leverages the NAT Detection Option, defined in the Dual Stack Mobile
specification for the use in Binding Acknowledgment message and IPv6 specification for the use in Binding Acknowledgment message and
extends it to Proxy Binding Acknowledgment messages. The operational extends it to Proxy Binding Acknowledgment messages. The operational
steps are defined below. steps are defined below.
Processing Binding Registrations:
o After accepting the registration from the mobile access gateway
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
encapsulation for the tunnel.
o If the T flag is set in the proxy binding update message and the
TLV header is presented, the specified tunnel type must be used.
o The local mobility anchor also setup a host routes for the IPv4
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 o Upon receiving a Proxy Binding Update message encapsulated in an
IPv4 packet, the local mobility anchor MUST send the Proxy Binding IPv4 packet, the local mobility anchor MUST send the Proxy Binding
Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by
using IPv4 encapsulation. If the NAT is detected, the NAT using IPv4 encapsulation.
detection option MUST be used in the Proxy Binding Acknowledgment.
How to detect NAT is described in Section 4.1 of [ID-DSMIP6] and o If the NAT is detected, the NAT detection option MUST be used in
Section 4.3. 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:
o The proxy binding acknowledgment MUST be protected by IPsec ESP.
The security association for IPv4 addresses of the mobile access
gateway and local mobility anchor are pre-established.
o For the IPv4 transport support, no special mobility options are
required. Only when NAT is detected, the NAT detection option
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 o An example of proxy binding acknowledgment sent by local mobility
anchor is shown below. The same illustration for Mobile IPv6 can anchor is shown below. The same illustration for Mobile IPv6 can
be found in Section 4.1 of [ID-DSMIP6]. The proxy binding be found in Section 4.1 of [ID-DSMIP6].
acknowledgment MUST be protected by IPsec ESP. The security
association for IPv4 addresses of the mobile access gateway and
local mobility anchor are pre-established.
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
IPv6 header (src=LMAA, dst=v6MAG) [TLV-header] /* optional, if T flag is set */
IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header Mobility header
-BA /*P flag is set */ -BA /* P flag/T flag(option) */
Mobility Options Mobility Options
-HNP* /* IPv6-MN-HoA */ - Home Network Prefix Option
-TSO* - IPv4 Address Acknowledgement option
-IPv4-ACK /* Only if IPv4 HoA is required */ - Timestamp option (optional)
-NAT-DET /* Only if NAT is detected */ - Mobile Node Identifier Option
-NAI /*NAI Option */ - Access Technology Type option (Mandatory)
- Mobile Node Interface Identifier option
*HNP: Home Network Prefix Option (Optional)
*TSO: Time Stamp Option
*v6MAG: IPv6 address assigned to the mobile access gateway.
Figure 7: Proxy Binding Acknowledgment in IPv4 network - NAT Detection Option (Optional)
o After accepting the registration from the mobile access gateway Figure 11: Proxy Binding Acknowledgment in IPv4 network
locating at the IPv4 only network, the local mobility anchor MUST Forwarding Packets to Mobile Access Gateway
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. If the NAT is available and the NAT
detection option is included in the Proxy Binding Acknowledgment,
the local mobility anchor MUST use UDP encapsulation for the
tunnel. The local mobility anchor also setup a host routes for
the IPv4 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
may be as specified in Section 5.3 of Proxy Mobile IPv6
specification [ID-PMIP6] and as in this specification.
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 8 the packet to mobile access gateway as shown in Figure 12.
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 8: Tunneled Packets from LMA to MAG
4.6. Tunnel Management Figure 12: Tunneled Packets from LMA to MAG
o 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 13.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header
TLV header
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 13: Tunneled Packets from LMA to MAG using the TLV header
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
This document does not define any new messages. The UDP port number This document does not require IANA Action.
for proxy binding update and acknowledgment will be defined in [ID-
DSMIP6].
6. Security Considerations 6. Security Considerations
This specification describes the use of IPv4 transport network The security mechanisms specified for Proxy Mobile IPv6 protocol are
between the local mobility anchor and the mobile access gateway. All used when using the extensions defined in this document.
the signaling messages exchanged between the mobile access gateway
and the local mobility anchor over the IPv4 transport MUST be
protected using IPsec, just as the messages must be protected when
using IPv6 transport and as specified in the Section 4.0, of the
Proxy Mobile IPv6 specification [ID-PMIP6].
When supporting IPv4 address assignment from a DHCP server, all the When supporting IPv4 address assignment from a DHCP server, all the
IPv4 home addresses managed in the DHCP server must be reachable via IPv4 home addresses managed in the DHCP server must be reachable via
local mobility anchor so that local mobility anchor intercepts local mobility anchor so that local mobility anchor intercepts
packets meant for an IPv4 home address and tunnels them to the mobile packets meant for an IPv4 home address and tunnels them to the mobile
node via corresponding mobile access gateway. Moreover, all the DHCP node via corresponding mobile access gateway. Moreover, all the DHCP
messages between a DHCP relay and the DHCP server SHOULD be securely messages between a DHCP relay and the DHCP server SHOULD be securely
exchanged. exchanged.
After receiving a Proxy Binding Update message with an IPv4 Home After receiving a Proxy Binding Update message with an IPv4 Home
Address Option, the local mobility anchor MUST be able to verify that Address Option, the local mobility anchor MUST be able to verify that
the mobile node is authorized to use that address before setting up the mobile node is authorized to use that address before setting up
forwarding for that host route. forwarding for that host route.
When supporting dynamic IPv4 address assignment by DHCP and also from When supporting dynamic IPv4 address assignment by DHCP and also from
local mobility anchor, it should be ensured both the entities are local mobility anchor, it should be ensured both the entities are
configured with different address pools, so as to avoid both entities configured with different address pools, so as to avoid both entities
do not allocate the same address to different mobile nodes. do not allocate the same address to different mobile nodes.
This specification describes the use of IPv4 transport network
between the local mobility anchor and the mobile access gateway. All
the signaling messages exchanged between the mobile access gateway
and the local mobility anchor over the IPv4 transport MUST be
protected using IPsec, just as the messages must be protected when
using IPv6 transport and as specified in the Section 4.0, of the
Proxy Mobile IPv6 specification [ID-PMIP6].
7. Contributors 7. 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 21, line 41 skipping to change at page 29, line 41
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]. This document
leverages lot of text from that document. We would like to thank all leverages lot of text from that document. We would like to thank all
the authors of the document and acknowledge that initial work. the authors of the document and acknowledge that initial work.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[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-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
RFC 3776, June 2004. November 2005.
[RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
G., Liebsch, M., "Problem Statement for Network-based Localized Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05.txt
Mobility Management", September 2006. ,July 2007.
[RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6",
G., Liebsch, M., "Goals for Network-based Localized Mobility draft-ietf-netlmm-proxymip6-07.txt, November 2007.
Management", October 2006.
[RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 9.2. Informative References
Localized Mobility Management", September 2006.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03.txt 2131, March 1997.
,October 2006.
[ID-MIP6-IKEV2] Devarapalli, V. and Dupont, F., "Mobile IPv6 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Operation with IKEv2 and the revised IPsec Architecture", Address Translator (Traditional NAT)", RFC 3022, January 2001.
draft-ietf-mip6-ikev2-ipsec-08.txt, December 2006.
[ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
draft-ietf-netlmm-proxymip6-01.txt, December 2007. Mobility", RFC 4977, August 2007.
9.2. Informative References Appendix A. DHCP usages for IPv4 home address assignment
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 There are several other configurations of DHCP entities [RFC-2131] in
(IPv6) Specification", RFC 2460, December 1998. 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. Note
that 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 option is used in the Proxy Mobile IPv6 domain based
on the deployment scenario.
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor In the configurations described in this section, the DHCP messages
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 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.
[RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address o DHCP relay is located in each mobile access gateway and DHCP
Autoconfiguration", RFC 2462, December 1998. server is solely located in the Proxy Mobile IPv6 domain
[RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and o DHCP relay is located in both each mobile access gateway and a
M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", local mobility anchor. DHCP server is solely located in the Proxy
RFC 3315, July 2003. Mobile IPv6 domain
[RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the In Figure 14, a DHCP relay is co-located with each mobile access
Internet Protocol", RFC 4301, December 2005. 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.
[RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC MN MAG(DHCP-R) DHCP-S LMA
4303, December 2005. |------>|------->| | 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
| | | |
[RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) Figure 14: The use of an Independent DHCP relay
Protocol", RFC 4306, December 2005.
[ID-DSMIP6-PS] Tsirtsis, G., et.al, "Problem Statement: Dual Stack Figure 15 is very similar to the Figure 14 except for the local
Mobility", draft-ietf-mip6-dsmip-problem-03.txt, January 2007. mobility anchor being a DHCP relay. In this case, both a mobile
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
|------>|------->|------>| 1. DHCP discovery and Relay
|<------|<-------|<------| 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
| | | |
* 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
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa (Editor)
Keio University Faculty of Environment and Information Studies, 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
 End of changes. 124 change blocks. 
463 lines changed or deleted 924 lines changed or added

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