One document matched: draft-ietf-netlmm-pmip6-ipv4-support-01.txt
Differences from draft-ietf-netlmm-pmip6-ipv4-support-00.txt
NETLMM Working Group R. Wakikawa
Internet-Draft Keio University
Intended status: Standards Track S. Gundavelli
Expires: January 10, 2008 Cisco
July 9, 2007
IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-01.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 January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wakikawa & Gundavelli Expires January 10, 2008 [Page 1]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 . . . . . . . . . . . . . 9
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 January 10, 2008 [Page 2]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 25
Wakikawa & Gundavelli Expires January 10, 2008 [Page 3]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 summarized 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. This specification defines extensions to
the Proxy Mobile IPv6 protocol for supporting IPv4. The scope of
these IPv4 related extensions are 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 Dual-Stack Mobile IPv6 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 extensions for extending IPv4 support
to 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 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
specification assumes that the link between the mobile access gateway
and the local mobility anchor is a point-to-point link. This
specification also assumes that the local mobility anchor and the
Wakikawa & Gundavelli Expires January 10, 2008 [Page 4]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
mobile access gateway are both IPv6 capable and IPv6 enabled and even
when the network between the mobile access gateway and a local
mobility anchor is IPv4-only network. The signaling protocol is
primarily based on Mobile IPv6 and hence the entities providing the
network-based mobility management service must be IPv6 enabled.
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 January 10, 2008 [Page 5]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 January 10, 2008 [Page 6]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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. The IPv4 home address configuration
includes the IPv4 home address, the IPv4 home network prefix and IPv4
home network prefix length.
Figure 2 shows the operational sequence of the home address mobility
support when a local mobility anchor assigns an IPv4 Home Address
dynamically to a mobile node. All mobile access gateways 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 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-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.
Wakikawa & Gundavelli Expires January 10, 2008 [Page 7]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
MN MAG(DHCPS) 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.
** 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
In addition to this, other address configuration mechanisms including
static configuration methods specific to the access link or dynamic
configuration from the DHCP server (without local mobility anchor
involvmenet) may also be in place. Several other assignment schems
are listed:
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 DHCP Server: If DHCP is
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.
Wakikawa & Gundavelli Expires January 10, 2008 [Page 8]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
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.
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 3. 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.
Wakikawa & Gundavelli Expires January 10, 2008 [Page 9]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
* 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 3: Proxy Binding Update for IPv4 Home Address Support
o When a mobile node gets IPv4 home address from Local Mobility
Anchor through DHCP interaction with MAG that supports DHCP server
functionality, the DHCP client in the mobile node recognizes MAG's
IP address as DHCP server's IP address. Thus, the DHCP client
unicasts DHCP renew to the MAG, when the DHCP client goes into the
DHCP RENEWING state [RFC2131]. However, when the mobile node
handovers to a new MAG, the mobile node does not know the link
change and the DHCP client would unicast DHCP request to the
previous MAG whose IP address was acquired from DHCP offer. So,
DHCP client in the mobile node needs to reconfigure its local
configuration parameters. Therefore, MAG SHOULD discard any DHCP
request message that does not belong to the MAG 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
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
Wakikawa & Gundavelli Expires January 10, 2008 [Page 10]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
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 4: Proxy Binding Acknowledgement for IPv4 Home Address
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
Wakikawa & Gundavelli Expires January 10, 2008 [Page 11]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
specification [ID-PMIP6] and as in this specification.
Wakikawa & Gundavelli Expires January 10, 2008 [Page 12]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 January 10, 2008 [Page 13]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 5. 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 January 10, 2008 [Page 14]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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*/
-NAI /* NAI Option */
*HNP: Home Network Prefix Option
*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
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 6
Wakikawa & Gundavelli Expires January 10, 2008 [Page 15]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 6: 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 January 10, 2008 [Page 16]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 */
-NAI /*NAI Option */
*HNP: Home Network Prefix Option
*TSO: Time Stamp Option
*v6MAG: IPv6 address assigned to the mobile access gateway.
Figure 7: 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 8
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 January 10, 2008 [Page 17]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 2007
Figure 8: 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 January 10, 2008 [Page 18]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 January 10, 2008 [Page 19]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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, 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. Moreover, all the DHCP
messages between a DHCP relay and the DHCP server SHOULD be securely
exchanged.
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 January 10, 2008 [Page 20]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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@etri.re.kr
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 January 10, 2008 [Page 21]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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-ietf-netlmm-proxymip6-01.txt, December 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 January 10, 2008 [Page 22]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 January 10, 2008 [Page 23]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 January 10, 2008 [Page 24]
Internet-Draft IPv4 Support for Proxy Mobile IPv6 July 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 January 10, 2008 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 11:11:06 |