NETLMM Working Group R. Wakikawa
Internet-Draft Keio University
Intended status: Standards Track S. Gundavelli
Expires: November 2, 2007 Cisco
May 2007
IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 2, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wakikawa & Gundavelli Expires November 2, 2007 [Page 1]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
Abstract
This document specifies extensions to the Proxy Mobile IPv6 protocol
[ID-PMIP6] for supporting IPv4. The scope of the IPv4 support in
Proxy Mobile IPv6 includes the support for the mobile node's IPv4
home address mobility and for supporting the scenario where the local
mobility anchor and the mobile access gateway are separated by an
IPv4 transport network. The solution primarily leverages the
extensions defined in Dual Stack Mobile IPv6 specification [ID-
DSMIP6] for achieving this.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7
3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7
3.2. Extensions to Conceptual Data Structure . . . . . . . . . 9
3.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 9
3.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 10
3.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 11
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 13
4.1. Mobility Options . . . . . . . . . . . . . . . . . . . . . 13
4.2. Extensions to Conceptual Data Structure . . . . . . . . . 13
4.3. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 14
4.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 16
4.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Wakikawa & Gundavelli Expires November 2, 2007 [Page 2]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Wakikawa & Gundavelli Expires November 2, 2007 [Page 3]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
1. Overview
The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the
same infrastructure. Thus, it is reasonable to assume that the
mobile node, mobile access gateway and the local mobility anchor are
both IPv4 and IPv6 enabled and further it is also reasonable to
expect the same mobility infrastructure to provide both IPv4 and IPv6
address mobility for a mobile node. The motivation and scope of IPv4
support in Mobile IPv6 is summraized in [ID-DSMIP6-PS].
The Proxy Mobile IPv6 base specification [ID-PMIP6] defines a
network-based mobility management protocol. The protocol specifies a
solution for providing IPv6 home address mobility for a mobile node
and over an IPv6 transport network separating the entities involved
in the mobility management. The extensions defined in this document
are for extending IPv4 support to the Proxy Mobile IPv6 protocol [ID-
PMIP6].
The scope of these efforts include the support for the following:
o IPv4 Home Address Mobility: A mobile node operating in IPv4-only
mode or in a dual-stack mode should be able to obtain an IPv4 home
address and roam anywhere in that Proxy Mobile IPv6 domain.
o IPv4 Transport Network Support: The transport network between the
local mobility anchor and the mobile access gateway is an IPv4
network and further the local mobility anchor or the mobile access
gateway may be using IPv4 private addresses and with NAT
translation devices on the path
The DSMIP6 specification [ID-DSMIP6], extends IPv4 home address
mobility and IPv4 transport network support to the Mobile IPv6
protocol [RFC-3775]. The solution specified in this document
leverages the DSMIP6 work and extends the IPv4 feature to the Proxy
Mobile IPv6 protocol. The protocol semantics, processing logic and
mobility header options, such as IPv4 home address option, 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 implementors may choose to implement any one or
both of these features. Since this specification also inherits Proxy
Mobile IPv6 [ID-PMIP6], only point to point link is assumed between a
mobile node and a mobile access gateway.
This specification assumes that the local mobility anchor and the
mobile access gateway are both IPv6 capabled and IPv6 enabled,
Wakikawa & Gundavelli Expires November 2, 2007 [Page 4]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
irrespective of the type of transport network (IPv4 or IPv6),
connecting these two entities. The signaling protocol is
fundamentally based on Mobile IPv6 in this document.
Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home
address mobility and IPv4 transport network features. The mobile
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
anchor and the mobile access gateway may be an IPv6 network or an
IPv4 network. Further, when the transport network is IPv4, either
the local mobility anchor or the mobile access gateway, or both can
be behind a NAT translation device and configured with an IPv4
private address.
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
IPv4-LMAA1 -> | | <-- IPv4-LMAA2
| |
\\ //\\
[NAT] // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // [NAT]
\\ // \\
IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2
+----+ +----+
|MAG1|-----[MN2] |MAG2|
+----+ | +----+
| | |
IPv4-MN-HoA1 --> | IPv4-MN-HoA2 | <-- IPv4-MN-HoA3
[MN1] [MN3]
Figure 1: IPv4 support for Proxy Mobile IPv6
Wakikawa & Gundavelli Expires November 2, 2007 [Page 5]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
2. Conventions & Terminology
2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
2.2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in Mobile IPv6 specification [RFC-3775],
DSMIP6 specification [ID-DSMIP6] and Proxy Mobile IPv6 specification
[ID-PMIP6]. In addition the document introduces the following terms.
IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)
The IPv4 Care-of Address that is configured on the interface of
the mobile access gateway and is the transport endpoint of the
tunnel between a local mobility anchor and a mobile access
gateway. However, when the configured address is a private IPv4
address and with a NAT device in the path to the local mobility
anchor, the care-of address as seen by the local mobility anchor
will be the address allocated by the NAT device for the mobility
session.
IPv4 Local Mobility Anchor Address (IPv4-LMAA)
The global IPv4 address that is typically configured on the
interface of a local mobility anchor and is the transport endpoint
of the tunnel between a local mobility anchor and a mobile access
gateway. This is the address to where a mobile access gateway
sends proxy binding update messages. If a local mobility anchor
is configured behind NAT, IPv4-LMAA is the IPv6 global address of
the NAT box. According to Section 2.1 of [ID-DSMIP6], two options
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.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 6]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
3. IPv4 Home Address Mobility Support
Using the extensions defined in this specification, a mobile node
operating in an IPv4-only or dual-stack mode will be able to obtain
an IPv4 address (IPv4-MN-HoA) and will be able to roam in that Proxy
Mobile IPv6 domain using that address. Although IPv6 home address is
always required in [ID-DSMIP6], this specification does not mandate
IPv6 home address unless a mobile node wants the IPv6 home address.
The network will provide mobility to that mobile node in that entire
domain. And further, the network will ensure that the mobile node
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
of that Proxy Mobile IPv6 domain.
3.1. IPv4 Home Address Assignment
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
home address mobility service, the mobile node using any of the IPv4
address configuration procedures, such as DHCP, IPCP or IKEv2 that
are supported on that access link, will be able to obtain its IPv4
home address configuration. In addition to this, other address
configuration mechanisms including static configuration methods
specific to the access link may also be in place. The IPv4 home
address configuration includes the IPv4 home address, the IPv4 home
network prefix and IPv4 home network prefix length. In this
specification, we support following static and dynamic assignment
schemes.
o Static IPv4 Home Address Assignment: When a mobile node is
configured with a static IPv4 home address, the IPv4 home address
information MUST be stored in the mobile node's policy profile.
The mobile access gateway where the mobile node attached obtains
the static IPv4 home address from the policy profile. The mobile
access gateway MUST set the known IPv4 home prefix to the IPv4
Home Address field and the Pref field of the IPv4 home address
option [ID-DSMIP6]. This option is carried by a proxy binding
update described in [ID-PMIP6].
o Dynamic IPv4 Home Address Assignment from Local Mobility Anchor:
If a local mobility anchor manages the IPv4 home address
allocation, a mobile access gateway requests dynamic IPv4 home
address allocation to the local mobility anchor as described in
[ID-DSMIP6]. The mobile access gateway SHOULD support minimal
functionality of DHCP server in order to send DHCP offer and and
acknowledgment messages to the mobile node in reply to the DHCP
discovery and request messages. The mobile access gateway is seen
as DHCP server from a mobile node, but it actually obtains the
Wakikawa & Gundavelli Expires November 2, 2007 [Page 7]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
IPv4 home address for each mobile node from the local mobility
anchor during proxy binding procedure. Figure 2 shows the
operational sequence of the home address mobility support< in this
case. If IPCP is used for address assignment, DHCP events in
Figure 2 are replaced by PPP events.
MN MAG LMA
|------>| | 1. DHCP discovery
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA)
| |========| 4. Tunnel/Route Setup*
|<------| | 5. DHCP offer (IPv4 HoA)
|------>| | 6. DHCP request (IPv4 HoA)
|<------| | 7. DHCP acknowledgement
| | |
* Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7)
are processed in parallel.
Figure 2: An example when LMA assigns an IPv4 home address
o Dynamic IPv4 Home Address Assignment from DHCP Server: If DHCP is
used for the IPv4 home address allocation, a mobile access gateway
or specifically a DHCP relay agent on the link will ensure the
mobile node is assigned an address from its home network prefix,
by marking the DHCP request with the mobile node's IPv4 home
network prefix hint. A DHCP relay and a mobile access gateway can
be co-located. The mobile access gateway learns the IPv4 home
address from the DHCP reply and sends that information to the
mobile node by DHCP 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. More remarks can be found in Section 6.
Figure 3 are the sequence of the home address mobility support.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 8]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
MN MAG(DHCPR) DHCPS LMA
|------>|------->| | 1. DHCP discovery and Relay
| |<-------| | 2. DHCP offer (IPv4 HoA)
| |--------------->| 3. Proxy Binding Update
| |<---------------| 4. Proxy Binding Acknowledgement
| |================| 5. Tunnel/Route Setup
|<------| | | 6. DHCP offer (IPv4 HoA) Relay
|------>|------->| | 7. DHCP request (IPv4 HoA) and Relay
|<------|<-------| | 8. DHCP acknowledgement and Relay
| | | |
DHCPS: DHCP Server
DHCPR: DHCP Relay
* Tunnel setup(no.5) and DHCP offer/request/ack(no.6-8)
are processed in parallel.
Figure 3: An example when DHCP Server assigns an IPv4 home address
3.2. Extensions to Conceptual Data Structure
There are certain extensions defined in DSMIP specification [DSMIP6]
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 the IPv4 home address mobility, the following options
are required from the DSMIPv6 specification [ID-DSMIP6].
o IPv4 Home Address Option defined in section 3.1.1 of [ID-DSMIP6].
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
[ID-DSMIP6]. This option MUST be present in the Proxy Binding
Acknowledgment, if the local mobility anchor accepts IPv4 home
address support.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 9]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
3.4. Mobile Access Gateway Operation
o All the considerations as explained in Section 6.11 of the base
Proxy Mobile IPv6 specification apply here.
o When a mobile node attached to an access link and attempts to
obtain an IPv4 address configuration, using DHCP or other
procedures, it will get an IPv4 address as a IPv4 home address
from its home network prefix as discussed in Section 3.1. 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 proxy binding
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
address allocation to the local mobility anchor, it MUST set
0.0.0.0 in the the IPv4 Home Address field of the IPv4 home
address option as described in [ID-DSMIP] and send this option
by the proxy binding update.
* If a mobile access gateway knows the IPv4 home prefix (or home
address) for the mobile node from static mobile node's policy
profile or DHCP server, it MUST set the known IPv4 home prefix
to the IPv4 Home Address field and the Pref field of the IPv4
home address option. This option is carried by a proxy binding
update described in Proxy Mobile IPv6 specification [ID-PMIP6].
IPv6 header (src=PCoA, dst=LMAA)
Mobility header
-BU /*P flag is set*/
Mobility Options
-HNP* /*IPv6 home address*/
-TSO*
-IPv4-HAO
*HNP: Home Network Prefix Option
*TSO: Time Stamp Option
Figure 4: Proxy Binding Update for IPv4 Home Address Support
Wakikawa & Gundavelli Expires November 2, 2007 [Page 10]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
o A proxy binding acknowledgment will be returned by the local
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
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
indicates the rejection of the IPv4 home address mobility service,
the mobile access gateway MUST not enable IPv4 routing for the
mobile node's IPv4 traffic.
3.5. Local Mobility Anchor Operation
o Upon receiving a Proxy Binding Update message with the IPv4 Home
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)
Mobility header
-BA /*P flag is set*/
Mobility Options
-HNP* /*IPv6 home address*/
-TSO*
-IPv4-ACK
-IPv4-DRA
*HNP: Home Network Prefix Option
*TSO: Time Stamp Option
Figure 5: Proxy Binding Acknowledgement for IPv4 Home Address
Wakikawa & Gundavelli Expires November 2, 2007 [Page 11]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
Support
o After accepting the registration for the mobile node's IPv4 home
address, the local mobility anchor will add an IPv4 host route
over the tunnel to the mobile access gateway. Any IPv4 packets
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 header. 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.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 12]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
4. IPv4 Transport Support
As per the Proxy Mobile IPv6 specification [ID-PMIP6], the transport
network between the local mobility anchor and the mobile access
gateway is an IPv6 network. This specification defines extensions
for supporting the scenario where the local mobility anchor and the
mobile access gateway may be separated by an IPv4 transport network
and further these entities may be configured with IPv4 private
addresses and with NAT translation devices in the path.
When the network between the local mobility anchor and the mobile
access gateway is an IPv4 network, the mobile access gateway can
potentially register an IPv4 address with the local mobility anchor,
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
traffic.
The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing
a mobile node to roam over an IPv4 network and the same solution can
be extended to Proxy Mobile IPv6. As explained in Section 4.1, of
the DSMIPv6 specification, a mobile access gateway can encapsulate a
Proxy Binding Update IPv6 message in an IPv4-UDP packet and route it
to the local mobility anchor. The processing logic and the on path
NAT detection logic is just as described in Section 4.3. The
signaling messages will always be IPv6 messages encapsulated in an
IPv4 packet 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. Mobility Options
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.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 13]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
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
mobile access gateway is an IPv4 network, the mobile access gateway
must send Proxy Binding Update message encapsulated in an IPv4-UDP
packet. On receiving this Proxy Binding Update packet encapsulated
in an IPv4-UDP packet, the local mobility anchor if it detects a NAT
on the path, will send the Proxy Binding Acknowledgment message with
the NAT Detection Option. The presence of this option in the Proxy
Binding Acknowledgment is an indication to the mobile access gateway
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
will set the encapsulation mode of the tunnel to IPv4-UDP. The
specific details around the NAT detection and the related logic is
described in in Dual Stack for Mobile IPv6 specification [ID-DSMIP6].
4.4. Mobile Access Gateway Operation
o All the considerations as explained in Section 6.11 of the base
Proxy Mobile IPv6 specification apply here.
o If IPv4 transport support is enabled in order to place a mobile
access gateway at IPv4 only network, the mobile access gateway
MUST have an IPv4 address at the visiting network. In addition to
that, the mobile access gateway MUST also obtain IPv6 address
configured for the Proxy Mobile IPv6 operation. Even if the
mobile access gateway does not have connectivity to the IPv6
network, it MUST configure with an IPv6 address for sending the
proxy binding registration to the local mobility anchor.
o As explained in Section 4.1, of the DSMIPv6 specification, the
mobile access gateway can encapsulate a Proxy Binding Update
message and carry it in IPv4 and UDP packet. The processing logic
for handling the NAT detection at the mobile node is applicable to
the mobile access gateway as described in Section 4.3. An example
of proxy binding update sent by mobile access gateway is shown in
Figure 6. Note that the source address of the inner IPv6 header
MUST set to the IPv6 address assigned to the mobile access gateway
and the destination address MUST be the local mobility anchor's
IPv6 address (LMAA). 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). 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
Wakikawa & Gundavelli Expires November 2, 2007 [Page 14]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
for IPv4 addresses of the mobile access gateway and local mobility
anchor are pre-established.
IPv4 header (src=IPv4-proxy-CoA, dst=IPv4-LMAA)
UDP header
IPv6 header (src=v6MAG*, dst=LMAA)
Mobility header
-BU /*P flag is set*/
Mobility Options
-HNP* /*IPv6 home address*/
-TSO*
-IPv4-HAO /*if IPv4 HoA is required*/
*HNP: Home Network Prefix Option
*TSO: Time Stamp Option
*v6MAG: IPv6 address assigned to the mobile access gateway.
Figure 6: Proxy Binding Update from mobile access gateway in IPv4
network
o After receiving a Proxy Binding Acknowledgment message
encapsulated in an IPv4 packet, the mobile access gateway MUST
verify the Proxy Binding Acknowledgment according to the Section
4.3 of DSMIP6 specification [ID-DSMIP6].
o If the Status field indicates Success, the mobile access gateway
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
the NAT is available and the NAT detection option is presented in
the Proxy Binding Acknowledgment, the mobile access gateway MUST
use UDP tunnel to traverse the NAT and MUST send a proxy binding
update every refresh time specified in the NAT detection option.
The detailed operation can be found in DSMIP6 specification [ID-
DSMIP6].
o If the Status field in the proxy binding acknowledgment indicates
the rejection of the binding registration, the mobile access
gateway MUST not enable IPv4 transport for the mobile node's
traffic.
o On receiving any packets from the mobile node's IPv6 home address
and/or IPv4 home address, the mobile access gateway tunnels the
packets to local mobility anchor as shown in Figure 7
Wakikawa & Gundavelli Expires November 2, 2007 [Page 15]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header /*Only if NAT is detected*/
union { /*following either v6 or v4 header */
IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN)
IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN)
}
Upper layer protocols /*TCP,UDP,SCTP*/
Figure 7: Tunneled Packets from MAG to LMA
4.5. Local Mobility Anchor Operation
When a mobile node is attached to a mobile access gateway that is
reachable only through an IPv4 transport network, the local mobility
anchor must establish an IPv4 tunnel for routing the mobile node's
IPv4 and IPv6 home address traffic. The DSMIPv6 specification
provides the semantics on how the IPv4 tunnel needs to be negotiated
and the detection logic of the NAT devices. This specification
leverages the NAT Detection Option, defined in the DSMIP6
specification for the use in Binding Acknowledgment message and
extends it to Proxy Binding Acknowledgment messages. The operational
steps are defined below.
o Upon receiving a Proxy Binding Update message encapsulated in an
IPv4 packet, the local mobility anchor MUST send the Proxy Binding
Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by
using IPv4 encapsulation. If the NAT is detected, the NAT
detection option MUST be used in the Proxy Binding Acknowledgment.
How to detect NAT is described in Section 4.1 of [ID-DSMIP6] and
Section 4.3.
o An example of proxy binding acknowledgment sent by local mobility
anchor is shown below. The same illustration for Mobile IPv6 can
be found in Section 4.1 of [ID-DSMIP6]. 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.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 16]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
IPv4 header (src=IPv4-LMAA, dst=IPv4-proxy-CoA)
UDP header /*Only if NAT is detected*/
IPv6 header (src=LMAA, dst=v6MAG)
Mobility header
-BA /*P flag is set */
Mobility Options
-HNP* /* IPv6-MN-HoA */
-TSO*
-IPv4-ACK /* Only if IPv4 HoA is required */
-NAT-DET /* Only if NAT is detected */
*HNP: Home Network Prefix Option
*TSO: Time Stamp Option
*v6MAG: IPv6 address assigned to the mobile access gateway.
Figure 8: Proxy Binding Acknowledgment in IPv4 network
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. 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
address or IPv6 home address, the local mobility anchor tunnels
the packet to mobile access gateway as shown in Figure 9
IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
UDP header /*Only if NAT is detected*/
union { /*following either v6 or v4 header */
IPv4 header (src=IPv4-CN, dst=IPv4-HoA)
IPv6 header (src=IPv6-CN, dst=IPv6-HoA)
}
Upper layer protocols /*TCP,UDP,SCTP*/
Wakikawa & Gundavelli Expires November 2, 2007 [Page 17]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
Figure 9: Tunneled Packets from LMA to MAG
4.6. Tunnel Management
As specified in the Proxy Mobile IPv6 specification, the bi-
directional tunnel between the local mobility anchor and the mobile
access gateway, is a shared tunnel and all the considerations from
Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport
as well.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 18]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
5. IANA Considerations
This document does not define any new messages. The UDP port number
for proxy binding update and acknowledgment will be defined in [ID-
DSMIP6].
Wakikawa & Gundavelli Expires November 2, 2007 [Page 19]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
6. Security Considerations
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].
When supporting IPv4 address assignment from a DHCP server, the local
mobility anchor MUST be the prefix owner and the topological anchor
point for the address pools that are configured on the DHCP server
for allocation for the mobile nodes.
After receiving a Proxy Binding Update message with an IPv4 Home
Address Option, the local mobility anchor MUST be able to verify that
the mobile node is authorized to use that address before setting up
forwarding for that host route.
When supporting dynamic IPv4 address assignment by DHCP and also from
local mobility anchor, it should be ensured both the entities are
configured with different address pools, so as to avoid both entities
do not allocate the same address to different mobile nodes.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 20]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
7. Contributors
This document reflects discussions and contributions from several
people (in alphabetical order):
Kuntal Chowdhury
kchowdhury@starentnetworks.com
Vijay Devarapalli
vijay.devarapalli@azairenet.com
Sangjin Jeong
sjjeong@gmail.com
Basavaraj Patil
basavaraj.patil@nsn.com
Myungki Shin
myungki.shin@gmail.com
8. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. This document
leverages lot of text from that document. We would like to thank all
the authors of the document and acknowledge that initial work.
9. 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
Requirement Levels", BCP 14, RFC 2119, March 1997.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 21]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004.
[RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
RFC 3776, June 2004.
[RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., Liebsch, M., "Problem Statement for Network-based Localized
Mobility Management", September 2006.
[RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
G., Liebsch, M., "Goals for Network-based Localized Mobility
Management", October 2006.
[RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based
Localized Mobility Management", September 2006.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03.txt
,October 2006.
[ID-MIP6-IKEV2] Devarapalli, V. and Dupont, F., "Mobile IPv6
Operation with IKEv2 and the revised IPsec Architecture",
draft-ietf-mip6-ikev2-ipsec-08.txt, December 2006.
[ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6",
draft-sgundave-mip6-proxymip6-02.txt, March 2007.
9.2. Informative References
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
Wakikawa & Gundavelli Expires November 2, 2007 [Page 22]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC
4303, December 2005.
[RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[ID-DSMIP6-PS] Tsirtsis, G., et.al, "Problem Statement: Dual Stack
Mobility", draft-ietf-mip6-dsmip-problem-03.txt, January 2007.
Wakikawa & Gundavelli Expires November 2, 2007 [Page 23]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
Authors' Addresses
Ryuji Wakikawa
Keio University
Department of Environmental Information, Keio University.
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Email: ryuji@sfc.wide.ad.jp
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Wakikawa & Gundavelli Expires November 2, 2007 [Page 24]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wakikawa & Gundavelli Expires November 2, 2007 [Page 25]
