draft-ietf-netlmm-pmip6-ipv4-support-07.txt   draft-ietf-netlmm-pmip6-ipv4-support-08.txt 
NETLMM Working Group R. Wakikawa NETLMM Working Group R. Wakikawa
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: June 19, 2009 Cisco Expires: July 22, 2009 Cisco
December 16, 2008 January 18, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-07.txt draft-ietf-netlmm-pmip6-ipv4-support-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 19, 2009. This Internet-Draft will expire on July 22, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) enable IPv4 home address mobility support to the mobile two-fold: 1) enable IPv4 home address mobility support to the mobile
node. 2) allowing the mobility entities in the Proxy Mobile IPv6 node. 2) allowing the mobility entities in the Proxy Mobile IPv6
domain to exchange signaling messages over an IPv4 transport network. domain to exchange signaling messages over an IPv4 transport network.
Table of Contents Table of Contents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.1.3. Routing Considerations for the Local Mobility 3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 16 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 17 3.2.1. Extensions to Binding Update List Entry . . . . . . . 17
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 21 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22
3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23
3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 24 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 25
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 25 Gateway . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2. DHCP Relay Agent co-located with the Mobile Access 3.4.2. DHCP Relay Agent co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 28 Gateway . . . . . . . . . . . . . . . . . . . . . . . 29
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38
4.2.1. Extensions to Binding Update List Entry . . . . . . . 38 4.2.1. Extensions to Binding Update List Entry . . . . . . . 38
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38
skipping to change at page 4, line 12 skipping to change at page 4, line 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a same network infrastructure. Thus, it is reasonable to assume that a
mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
IPv6-only or in dual-stack mode and additionally the network between IPv6-only or in dual-stack mode and additionally the network between
the mobile access gateway and a local mobility anchor may be an IPv4 the mobile access gateway and a local mobility anchor may be an IPv4
or an IPv6 network. It is also reasonable to expect the same or an IPv6 network. It is also reasonable to expect the same
skipping to change at page 6, line 11 skipping to change at page 6, line 11
IPv4 transport support features, are independent of each other and IPv4 transport support features, are independent of each other and
deployments may choose to enable any one or both of these features as deployments may choose to enable any one or both of these features as
required. required.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA1 -> | | <-- LMAA2 IPv4-LMAA1 -> | | <-- LMAA2
| | | |
\\ //\\ \\ //\\
[NAT] // \\ (NAT) // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+ +----+ +----+
skipping to change at page 6, line 42 skipping to change at page 6, line 42
The following are the configuration requirements from the mobility The following are the configuration requirements from the mobility
entities in the Proxy Mobile IPv6 domain for supporting the entities in the Proxy Mobile IPv6 domain for supporting the
extensions defined in this document. extensions defined in this document.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
IPv4 and IPv6 enabled. Irrespective of the type of transport IPv4 and IPv6 enabled. Irrespective of the type of transport
network (IPv4 or IPv6) separating these two entities, the mobility network (IPv4 or IPv6) separating these two entities, the mobility
signaling is always based on Proxy Mobile IPv6 [RFC-5213]. signaling is always based on Proxy Mobile IPv6 [RFC-5213].
o The local mobility anchor and the mobile access gateway MUST be o The local mobility anchor and the mobile access gateway MUST be
configured with IPv6 global addresses, even when they are in IPv4- configured with IPv6 globally unique addresses, even when they are
only network. When using IPv4 transport, it is not required that in IPv4-only network. These addresses can be of the type Unique
there is IPv6 routing enabled between the local mobility anchor Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address
and the mobile access gateway. However, they must be able to [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using
receive any IPv6 packets sent to the configured IPv6 addresses, IPv4 transport, it is not required that there is IPv6 routing
after removing the outer IPv4 encapsulation header. enabled between the local mobility anchor and the mobile access
gateway. However, they must be able to receive any IPv6 packets
sent to the configured IPv6 addresses, after removing the outer
IPv4 encapsulation header.
o The mobile node can be operating in IPv4-only, IPv6-only or in o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. Based on what is enabled for a mobile node, it should dual mode. Based on what is enabled for a mobile node, it should
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
address(es) for its interface and furthermore achieve mobility address(es) for its interface and furthermore achieve mobility
support for those addresses. support for those addresses.
o For enabling IPv4 home address mobility support to a mobile node, o For enabling IPv4 home address mobility support to a mobile node,
it is not required that the IPv6 home address mobility support it is not required that the IPv6 home address mobility support
needs to enabled. However, the respective protocol(s) support, needs to enabled. However, the respective protocol(s) support,
skipping to change at page 12, line 9 skipping to change at page 12, line 9
instance of any of these two options present in the request, the instance of any of these two options present in the request, the
local mobility anchor MUST reject the request and send a Proxy local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to Binding Acknowledgement message with Status field set to
MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213]. network prefix option) [RFC-5213].
o If there is at least one instance of Home Network Prefix option o If there is at least one instance of Home Network Prefix option
[RFC-5213] present in the received Proxy Binding Update message, [RFC-5213] present in the received Proxy Binding Update message,
but either if the mobile node is not IPv6 enabled, or if IPv6 but either if the mobile node is not IPv6 enabled, or if IPv6
routing not enabled in the home network, the local mobility anchor routing not enabled in the home network, the local mobility anchor
SHOULD reject the request and send a Proxy Binding Acknowledgement MUST reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to message with the Status field set to
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not
authorized for the requesting IPv6 home network prefix). authorized for the requesting IPv6 home network prefix).
o If there are more than one instance of the IPv4 Home Address
option present in the request, then the local mobility anchor MUST
reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
home address assignment not supported).
o If the prefix request(P) flag in the IPv4 Home Address option is
set to a value of 1, then the local mobility anchor MUST reject
the request and send a Proxy Binding Acknowledgement message with
the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4
prefix assignment not supported).
o For associating the received Proxy Binding Update message to an o For associating the received Proxy Binding Update message to an
existing mobility session, the local mobility anchor MUST perform existing mobility session, the local mobility anchor MUST perform
the Binding Cache entry existence test by applying the following the Binding Cache entry existence test by applying the following
considerations. considerations.
* If there is at least one instance of the Home Network Prefix * If there is at least one instance of the Home Network Prefix
option [RFC-5213] with a NON_ZERO prefix value, or, if there is option [RFC-5213] with a NON_ZERO prefix value, or, if there is
an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address
in the option set to ALL_ZERO, considerations from Section in the option set to ALL_ZERO, considerations from Section
5.4.1 of [RFC-5213] MUST be applied. 5.4.1 of [RFC-5213] MUST be applied.
skipping to change at page 15, line 16 skipping to change at page 15, line 27
3.1.2.5. Binding De-Registration 3.1.2.5. Binding De-Registration
All the considerations from Section 5.3.5 of [RFC-5213] MUST be All the considerations from Section 5.3.5 of [RFC-5213] MUST be
applied. Additionally, for removing the IPv4 state as part of the applied. Additionally, for removing the IPv4 state as part of the
Binding Cache entry deletion, the IPv4 host route and the dynamically Binding Cache entry deletion, the IPv4 host route and the dynamically
created bi-directional tunnel for carrying the IPv4 payload traffic created bi-directional tunnel for carrying the IPv4 payload traffic
(if there are no other mobile nodes for which the tunnel is being (if there are no other mobile nodes for which the tunnel is being
used) MUST be removed. However, if the request is for a selective used) MUST be removed. However, if the request is for a selective
de-registration (IPv4 home address only, or all the IPv6 home network de-registration (IPv4 home address only, or all the IPv6 home network
prefixes), the Binding Cache entry MUST not be deleted, only the prefixes), the Binding Cache entry MUST NOT be deleted, only the
respective states with respect to those addresses MUST be deleted. respective states with respect to those addresses MUST be deleted.
3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC-5213]. the message as specified in Section 5.3.6 of [RFC-5213].
Additionally, the following considerations MUST be applied. Additionally, the following considerations MUST be applied.
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
skipping to change at page 24, line 33 skipping to change at page 24, line 45
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address Mobile node not authorized for the requesting IPv4 home address
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network Mobile node not authorized for the requesting IPv6 home network
prefix(es). prefix(es).
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
Multiple IPv4 home address assignment not supported
IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED
IPv4 prefix assignment not supported
3.4. Supporting DHCP-Based Address Configuration 3.4. Supporting DHCP-Based Address Configuration
This section explains how DHCP-based address configuration support This section explains how DHCP-based address configuration support
can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It
explains the protocol operation, supported DHCP server deployment explains the protocol operation, supported DHCP server deployment
configurations and the protocol interactions between DHCP agents and configurations and the protocol interactions between DHCP agents and
mobility entities in each of the supported configurations. mobility entities in each of the supported configurations.
This specification supports the following two DHCP deployment This specification supports the following two DHCP deployment
configurations. configurations.
skipping to change at page 29, line 47 skipping to change at page 30, line 17
the mobile node, the DHCP messages will be forwarded to the DHCP the mobile node, the DHCP messages will be forwarded to the DHCP
server. server.
o The DHCP relay agent on the mobile access gateway will add the o The DHCP relay agent on the mobile access gateway will add the
DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER
message. The assigned IPv4 home address will be included in the message. The assigned IPv4 home address will be included in the
Agent Remote ID Sub-option of the DHCP relay agent information Agent Remote ID Sub-option of the DHCP relay agent information
option. This sub-option is used as a hint for requesting the DHCP option. This sub-option is used as a hint for requesting the DHCP
server to allocate that specific IPv4 address. server to allocate that specific IPv4 address.
o On receiving a DHCPOFFER message from the DHCP server, the mobile
access gateway will ensure the assigned address is currently
assigned by the local mobility anchor to that mobile node. If
this address is different from what is assigned to the mobile
node, then the mobile access gateway will drop the DHCPOFFER
message and an administrative error message will be logged.
However, the mobile access gateway is not required to perform this
check, if the DHCP server is co-located with the local mobility
anchor, as that check will be performed by the local mobility
anchor in such scenario. The mobile access gateway can determine
the co-location of the DHCP server and the local mobility anchor
by comparing the source address of the DHCPOFFER message with the
address of the mobile node's local mobility anchor.
o When the DHCP messages are sent over administrative boundaries, o When the DHCP messages are sent over administrative boundaries,
the operators needs to ensure these messages are secured. All the the operators needs to ensure these messages are secured. All the
DHCP messages relayed by the mobile access gateway can be tunneled DHCP messages relayed by the mobile access gateway can be tunneled
to the local mobility anchor if needed. Alternatively, if the to the local mobility anchor if needed. Alternatively, if the
network in the Proxy Mobile IPv6 domain is secure enough, the network in the Proxy Mobile IPv6 domain is secure enough, the
mobile access gateway can just relay the DHCP messages to the mobile access gateway can just relay the DHCP messages to the
server. To achieve this, all the mobile access gateways needs to server. To achieve this, all the mobile access gateways needs to
have route towards the DHCP server. have route towards the DHCP server.
IPv4 Home Address Renewal to the same DHCP server: (No Handover) IPv4 Home Address Renewal to the same DHCP server: (No Handover)
o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
directly unicasts DHCPREQUEST message to the DHCP server. The directly unicasts DHCPREQUEST message to the DHCP server. The
DHCP relay agent may not detect these unicasted DHCPREQUEST DHCP relay agent may not detect these unicasted DHCPREQUEST
messages for renewing the address. Thus, one of following messages for renewing the address. Thus, any of the following
operations is required. approaches can be adopted.
* The DHCP relay agent can intercept all the DHCP packets * The DHCP relay agent can intercept all the DHCP packets
regardless of the destination address. Since the link between regardless of the destination address. Since the link between
a mobile node and a mobile access gateway is the point-to-point a mobile node and a mobile access gateway is the point-to-point
link, the mobile access gateway will be in path for all the link, the mobile access gateway will be in path for all the
messages. messages.
* The DHCP relay agent can use the DHCP Server Identifier * The DHCP relay agent can use the DHCP Server Identifier
Override Sub-option [RFC-5107] to be in path for all the DHCP Override Sub-option [RFC-5107] to be in path for all the DHCP
message flows. The DHCP client uses the DHCP server address message flows. The DHCP client uses the DHCP server address
skipping to change at page 32, line 41 skipping to change at page 32, line 41
key aspects of this feature. key aspects of this feature.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address. Additionally, configured and reachable using an IPv4 address. Additionally,
both entities are also IPv6 enabled and have configured IPv6 both entities are also IPv6 enabled and have configured IPv6
addresses on their interfaces, as specified in [RFC-5213], but are addresses on their interfaces, as specified in [RFC-5213], but are
reachable only over an IPv4 transport. reachable only over an IPv4 transport.
o The mobile access gateway can be potentially in a private IPv4 o The mobile access gateway can be potentially in a private IPv4
network behind a NAT [RFC-3022] device, with a private IPv4 network behind a NAT [RFC-3022] device, with a private IPv4
address configured on its egress interface. However, the local address configured on its egress interface. But, the local
mobility anchor must not be behind a NAT and must be using a mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address. globally routable IPv4 address. However, both the local mobility
anchor and the mobile access gateway can be in the same private
IPv4 routing domain, i.e., when both are configured with private
IPv4 addresses and with no need for NAT translation between them.
o The IPv6 address configuration requirement on the mobile access
gateway does not imply there needs to be IPv6 routing enabled
between the local mobility anchor and the mobile access gateway.
It just requires each of the mobile access gateways and local
mobility anchors in a Proxy Mobile IPv6 domain to be configured
with a globally unique IPv6 address.
o The Proxy Mobile IPv6 signaling messages exchanged between the o The Proxy Mobile IPv6 signaling messages exchanged between the
local mobility anchor and the mobile access gateway for local mobility anchor and the mobile access gateway for
negotiating the IPv4 transport will be encapsulated and carried as negotiating the IPv4 transport will be encapsulated and carried as
IPv4 packets. However, these signaling messages are fundamentally IPv4 packets. However, these signaling messages are fundamentally
IPv6 messages using the mobility header and the related semantics IPv6 messages using the mobility header and the related semantics
as specified in base Proxy Mobile IPv6 specification [RFC-5213], as specified in base Proxy Mobile IPv6 specification [RFC-5213],
but carried as a payload in an IPv4 packet. The supported but carried as a payload in an IPv4 packet. The supported
encapsulation modes for the signaling messages are either native encapsulation modes for the signaling messages are either native
IPv4 or IPv4 with UDP header. IPv4 or IPv4 with UDP header.
skipping to change at page 33, line 42 skipping to change at page 34, line 4
4.1.1. Extensions to Binding Cache Entry 4.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor [RFC-5213] MUST be structure maintained by the local mobility anchor [RFC-5213] MUST be
extended with the following additional parameters. extended with the following additional parameters.
o This is the IPv4 Proxy Care-of Address configured on the mobile o This is the IPv4 Proxy Care-of Address configured on the mobile
access gateway that sent the Proxy Binding Update message. This access gateway that sent the Proxy Binding Update message. This
address can be obtained from the IPv4 Care-of Address option [ID- address can be obtained from the IPv4 Care-of Address option [ID-
DSMIP6], present in the received Proxy Binding Update message. If DSMIP6], present in the received Proxy Binding Update message.
the option was not present in the request, this field MUST be set However, if the received Proxy Binding Update message is not sent
to the source address of the IPv4 header of the received Proxy as an IPv4 packet, i.e., when using IPv6 transport, this field
Binding Update message. However, if the received Proxy Binding MUST be set to ALL_ZERO value.
Update message is not sent as an IPv4 packet, this field MUST be
set to ALL_ZERO value.
o The IPv4 NAT translated address of the mobile access gateway. If o The IPv4 NAT translated address of the mobile access gateway. If
the mobile access gateway is not behind a NAT [RFC-3022], this the mobile access gateway is not behind a NAT [RFC-3022], this
address will be the same as the address configured on the egress address will be the same as the address configured on the egress
interface of the mobile access gateway. This address can be interface of the mobile access gateway. This address can be
obtained from the IPv4 header of the received Proxy Binding Update obtained from the IPv4 header of the received Proxy Binding Update
message. However, if the received Proxy Binding Update message is message. However, if the received Proxy Binding Update message is
not sent as an IPv4 packet, this field MUST be set to ALL_ZERO not sent as an IPv4 packet, this field MUST be set to ALL_ZERO
value. value.
skipping to change at page 35, line 47 skipping to change at page 36, line 7
an IPv4 packet. However, if the received Proxy Binding Update an IPv4 packet. However, if the received Proxy Binding Update
message was sent encapsulated in the UDP header of an IPv4 packet, message was sent encapsulated in the UDP header of an IPv4 packet,
then the Proxy Binding Acknowledgement message MUST be then the Proxy Binding Acknowledgement message MUST be
encapsulated in the UDP header of an IPv4 packet. encapsulated in the UDP header of an IPv4 packet.
o The source address in the IPv4 header of the message MUST be set o The source address in the IPv4 header of the message MUST be set
to the destination IPv4 address of the received request. to the destination IPv4 address of the received request.
o If the mobile access gateway and the local mobility anchor are o If the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security using globally routable IPv4 addresses and if there is a security
associated that is based of IPv4 addresses, then the encapsulated association that is based of IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
MUST be protected using IPsec ESP [RFC-4301] mode. There is no MUST be protected using IPsec ESP [RFC-4301] mode. There is no
need to apply IPsec ESP header to the IPv6 packet. In all other need to apply IPsec ESP header to the IPv6 packet. In all other
cases, the Proxy Binding Acknowledgement message MUST be protected cases, the Proxy Binding Acknowledgement message MUST be protected
using IPsec prior to the IPv4 or IPv4-UDP encapsulation. using IPsec prior to the IPv4 or IPv4-UDP encapsulation.
o The NAT Detection option [ID-DSMIP6] MUST be present only if there o The NAT Detection option [ID-DSMIP6] MUST be present only if there
is an IPv4 Care-of Address option [ID-DSMIP6] present in the is an IPv4 Care-of Address option [ID-DSMIP6] present in the
received Proxy Binding Update message and if the NAT detection received Proxy Binding Update message and if the NAT detection
procedure resulted in detecting a NAT on path. However, if the procedure resulted in detecting a NAT on path. However, if the
skipping to change at page 42, line 20 skipping to change at page 42, line 20
configured by the system management. The configured values for these configured by the system management. The configured values for these
protocol variables MUST survive server reboots and service restarts. protocol variables MUST survive server reboots and service restarts.
AcceptForcedIPv4UDPEncapsulationRequest AcceptForcedIPv4UDPEncapsulationRequest
This flag indicates whether or not the local mobility anchor This flag indicates whether or not the local mobility anchor
should accept IPv4 UDP encapsulation request for the mobile node's should accept IPv4 UDP encapsulation request for the mobile node's
data traffic, even if there is no NAT detected in the path. data traffic, even if there is no NAT detected in the path.
The default value for this flag is set to value of 0, indicating The default value for this flag is set to value of 0, indicating
that the local mobility anchor MUST not accept IPv4 UDP that the local mobility anchor MUST NOT accept IPv4 UDP
encapsulation request when NAT is not detected in the path. encapsulation request when NAT is not detected in the path.
When the value for this flag is set to value of 1, the local When the value for this flag is set to value of 1, the local
mobility anchor MUST accept IPv4 UDP encapsulation request even mobility anchor MUST accept IPv4 UDP encapsulation request even
when NAT is not detected in the path. when NAT is not detected in the path.
5.2. Mobile Access Gateway - Configuration Variables 5.2. Mobile Access Gateway - Configuration Variables
The mobile access gateway MUST allow the following variables to be The mobile access gateway MUST allow the following variables to be
configured by the system management. The configured values for these configured by the system management. The configured values for these
skipping to change at page 44, line 16 skipping to change at page 44, line 16
This document defines a new Mobility Header option, IPv4 Default This document defines a new Mobility Header option, IPv4 Default
Router Address option. This option is described in Section 3.3.1. Router Address option. This option is described in Section 3.3.1.
The Type value for this option needs to be assigned from the same The Type value for this option needs to be assigned from the same
numbering space as allocated for the other mobility options, as numbering space as allocated for the other mobility options, as
defined in [RFC-3775]. defined in [RFC-3775].
This document also defines new Binding Acknowledgement status values, This document also defines new Binding Acknowledgement status values,
as described in Section 3.3.2. The status values MUST be assigned as described in Section 3.3.2. The status values MUST be assigned
from the same number space used for Binding Acknowledgement status from the same number space used for Binding Acknowledgement status
values, as defined in [RFC3775]. The allocated values for each of values, as defined in [RFC-3775]. The allocated values for each of
these status values must be greater than 128. these status values must be greater than 128.
7. Security Considerations 7. Security Considerations
All the security considerations from the base Proxy Mobile IPv6 All the security considerations from the base Proxy Mobile IPv6
protocol [RFC-5213] apply when using the extensions defined in this protocol [RFC-5213] apply when using the extensions defined in this
document. Additionally, the following security considerations need document. Additionally, the following security considerations need
to be applied. to be applied.
This document defines news mobility options for supporting the IPv4 This document defines news mobility options for supporting the IPv4
skipping to change at page 46, line 38 skipping to change at page 46, line 38
myungki.shin@gmail.com myungki.shin@gmail.com
9. Acknowledgments 9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like
to thank all the authors of the document and acknowledge that initial to thank all the authors of the document and acknowledge that initial
work. work.
Thanks to Alper Yegin, Behcet Sarikaya, Charles Perkins, Damic Thanks to Alper Yegin, Behcet Sarikaya, Charles Perkins, Damic
Damjan, Jonne Soinnen, Julien Laganier, Mohana Jeyatharan, Niklas Damjan, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana
Nuemann, Premec Domagoj, Sammy Touati, Yingzhe Wu and Zu Qiang for Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati, Vidya
their helpful review of this document. Narayanan, Yingzhe Wu and Zu Qiang for their helpful review of this
document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
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-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast
Addresses", RFC-4193, October 2005.
[RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC-4291, February 2006.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
November 2007. November 2007.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-07.txt, December 2008. draft-ietf-mext-nemo-v4traversal-07.txt, December 2008.
10.2. Informative References 10.2. Informative References
[RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001. Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January
2001.
[RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP [RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001. reconfigure extension", RFC 3203, December 2001.
[RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link- [RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link-
Local Addresses", RFC 3927, May 2005. Local Addresses", RFC 3927, May 2005.
[RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP
Packets", RFC 3948, January 2005.
[RFC-4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
Mobility", RFC 4977, August 2007. Mobility", RFC 4977, August 2007.
[RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp,
"DHCP Server Identifier Override Suboption", RFC 5107, February 2008. "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University Toyota ITC / Keio University
skipping to change at page 49, line 4 skipping to change at line 1961
Fax: +81-3-5561-8292 Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com Email: ryuji@jp.toyota-itc.com
Sri Gundavelli Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
 End of changes. 34 change blocks. 
47 lines changed or deleted 116 lines changed or added

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