draft-ietf-netlmm-pmip6-ipv4-support-12.txt   draft-ietf-netlmm-pmip6-ipv4-support-13.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: October 25, 2009 Cisco Expires: January 1, 2010 Cisco
April 23, 2009 June 30, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-12.txt draft-ietf-netlmm-pmip6-ipv4-support-13.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 October 25, 2009. This Internet-Draft will expire on January 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 11 skipping to change at page 4, line 11
5.2. Mobile Access Gateway - Configuration Variables . . . . . 44 5.2. Mobile Access Gateway - Configuration Variables . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References . . . . . . . . . . . . . . . . . . . 48 10.1. Normative References . . . . . . . . . . . . . . . . . . . 49
10.2. Informative References . . . . . . . . . . . . . . . . . . 49 10.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
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
mobility infrastructure in the Proxy Mobile IPv6 domain to provide mobility infrastructure in the Proxy Mobile IPv6 domain to provide
mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode
and when the network between the local mobility anchor and the mobile and whether the transport network is IPv4 or IPv6 network. The
access gateway is an IPv4 or an IPv6 network. The motivation and motivation and scope of IPv4 support in Mobile IPv6 is summarized in
scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and [RFC-4977] and all those requirements apply to Proxy Mobile IPv6
all those requirements apply to Proxy Mobile IPv6 protocol as well. protocol as well.
The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for
providing IPv6 home address mobility support to a mobile node in a providing IPv6 home address mobility support to a mobile node in a
Proxy Mobile IPv6 domain. The protocol requires IPv6 transport Proxy Mobile IPv6 domain. The protocol requires IPv6 transport
network between the mobility entities. The extensions defined in network between the mobility entities. The extensions defined in
this document extends IPv4 support to the Proxy Mobile IPv6 protocol this document extends IPv4 support to the Proxy Mobile IPv6 protocol
[RFC-5213]. [RFC-5213].
The scope of IPv4 support in Proxy Mobile IPv6 includes the support The scope of IPv4 support in Proxy Mobile IPv6 includes the support
for the following two features: for the following two features:
o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4
stack enabled will be able to obtain an IPv4 address and be able stack enabled will be able to obtain an IPv4 address and be able
to use that address from any of the access networks in that Proxy to use that address from any of the access networks in that Proxy
Mobile IPv6 domain. The mobile node is not required to be Mobile IPv6 domain. The mobile node is not required to be
allocated or assigned an IPv6 address for enabling IPv4 home allocated or assigned an IPv6 address to enable IPv4 home address
address support. support.
o IPv4 Transport Network Support: The mobility entities in the Proxy o IPv4 Transport Network Support: The mobility entities in the Proxy
Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
signaling messages over an IPv4 transport and furthermore the signaling messages over an IPv4 transport and furthermore the
mobile access gateway may be using an IPv4 private address and mobile access gateway may be using an IPv4 private address and
with NAT [RFC-3022] translation devices on the path to the local with NAT [RFC-3022] translation devices on the path to the local
mobility anchor. mobility anchor.
These two features, the IPv4 Home Address Mobility support and the These two features, the IPv4 Home Address Mobility support and the
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.
Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport
network and with IPv4 enabled mobile nodes. The terms used in this
illustration are explained in the Terminology section.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA1 -> | | <-- LMAA2 IPv4-LMAA -> | | <-- LMAA
| | | |
\\ //\\ \\ //\\
(NAT) // \\ (NAT) // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 IPv4-Proxy-CoA --> | | <-- Proxy-CoA
+----+ +----+ +----+ +----+
|MAG1|-----{MN2} |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
(IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) (MN-HoA) | | | <-- (MN-HoA)
(IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA)
{MN1} {MN3} {MN1} {MN3}
Figure 1: IPv4 support for Proxy Mobile IPv6 Figure 1: IPv4 support for Proxy Mobile IPv6
1.1. Stated Assumptions 1.1. Stated Assumptions
The following are the configuration requirements from the mobility The following are the system and configuration requirements from the
entities in the Proxy Mobile IPv6 domain for supporting the mobility 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 Both the mobility entities, the local mobility anchor and the
IPv4 and IPv6 enabled. Irrespective of the type of transport mobile access gateway are dual stack (IPv4/IPv6) enabled.
network (IPv4 or IPv6) separating these two entities, the mobility Irrespective of the type of transport network (IPv4 or IPv6)
signaling is always based on Proxy Mobile IPv6 [RFC-5213]. separating these two entities, the mobility 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 globally unique addresses, even when they are configured with IPv6 globally unique addresses, even when they are
in IPv4-only network. These addresses can be of the type Unique in IPv4-only network. These addresses can be of the type Unique
Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address
[RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using
IPv4 transport, it is not required that there is IPv6 routing IPv4 transport, it is not required that there is IPv6 routing
enabled between the local mobility anchor and the mobile access enabled between the local mobility anchor and the mobile access
gateway. However, they must be able to receive any IPv6 packets gateway. However, they must be able to receive any IPv6 packets
sent to the configured IPv6 addresses, after removing the outer sent to the configured IPv6 addresses, after removing the outer
skipping to change at page 7, line 28 skipping to change at page 7, line 29
interface. Based on the type of link, it may be able to acquire interface. Based on the type of link, it may be able to acquire
its IPv4 address configuration using standard IPv4 address its IPv4 address configuration using standard IPv4 address
configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332],
IKEv2 [RFC-4306] or static address configuration. IKEv2 [RFC-4306] or static address configuration.
o The mobile node's IPv4 home subnet is typically a shared address o The mobile node's IPv4 home subnet is typically a shared address
space. It is not for the exclusive use of any one mobile node. space. It is not for the exclusive use of any one mobile node.
There can be multiple mobile nodes that are assigned IPv4 There can be multiple mobile nodes that are assigned IPv4
addresses from the same subnet. addresses from the same subnet.
o The mobile access gateway is the IPv4 default-router for the o The mobile access gateway is the IPv4 default router for the
mobile node on its access link. It will be in the forwarding path mobile node on its access link. It will be in the forwarding path
for the mobile node's data traffic. Additionally, as specified in for the mobile node's data traffic. Additionally, as specified in
section 6.9.3 of [RFC-5213], all the mobile access gateways in the section 6.9.3 of [RFC-5213], all the mobile access gateways in the
Proxy Mobile IPv6 domain MUST use the same link-layer address on Proxy Mobile IPv6 domain MUST use the same link-layer address on
any of the access links wherever the mobile node attaches. any of the access links wherever the mobile node attaches.
1.2. Relevance to Dual-Stack Mobile IPv6 1.2. Relevance to Dual-Stack Mobile IPv6
IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6
specification [ID-DSMIP6]. This document to most part leverages the specification [RFC-5555]. This document to most part leverages the
approaches, messaging options and processing logic defined in that approaches, messaging options and processing logic defined in that
document for extending IPv4 support to Proxy Mobile IPv6, except with document for extending IPv4 support to Proxy Mobile IPv6, except with
deviation in some aspects for obvious reasons of supporting a deviation in some aspects for obvious reasons of supporting a
network-based mobility model. Following are some of the related network-based mobility model. Following are some of the related
considerations. considerations.
o The messaging options, IPv4 Home Address, IPv4 Address o The messaging options, IPv4 Home Address, IPv4 Address
Acknowledgement, IPv4 Care-of Address option defined in [ID- Acknowledgement, IPv4 Care-of Address option defined in [RFC-5555]
DSMIP6] for use in Binding Update and Binding Acknowledgement for use in Binding Update and Binding Acknowledgement messages are
messages are used by this specification to be carried in Proxy used by this specification to be carried in Proxy Binding Update
Binding Update and Proxy Binding Acknowledgement messages. and Proxy Binding Acknowledgement messages.
o The extensions needed to the conceptual data structures, Binding o The extensions needed to the conceptual data structures, Binding
Cache entry and Binding Update List entry, for storing the state Cache entry and Binding Update List entry, for storing the state
related to the IPv4 support defined in [ID-DSMIP6], will all be related to the IPv4 support defined in [RFC-5555], will all be
needed and relevant for this document. needed and relevant for this document.
o The NAT traversal logic specified in [ID-DSMIP6] for detecting the o The NAT traversal logic specified in [RFC-5555] for detecting the
on-path NAT devices is valid for this specification as well. on-path NAT devices is valid for this specification as well.
o The tunneling considerations specified in [ID-DSMIP6] for o The tunneling considerations specified in [RFC-5555] for
supporting IPv4 transport is relevant for this document as well. supporting IPv4 transport is relevant for this document as well.
If a given home agent [RFC-3775] implementation has support for both If a given home agent [RFC-3775] implementation has support for both
Dual-stack Mobile IPv6 [ID-DSMIP6] and local mobility anchor function Dual-stack Mobile IPv6 [RFC-5555] and local mobility anchor function
[RFC-5213], when extending IPv4 support as specified in this document [RFC-5213], when extending IPv4 support as specified in this document
the above common functions and the related considerations have to be the above common functions and the related considerations have to be
reused for Proxy Mobile IPv6 signaling flows. reused for Proxy Mobile IPv6 signaling flows.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 10, line 4 skipping to change at page 10, line 4
The IPv4 home address assigned to the mobile node's attached The IPv4 home address assigned to the mobile node's attached
interface. This address is topologically anchored at the local interface. This address is topologically anchored at the local
mobility anchor. The mobile node configures this address on its mobility anchor. The mobile node configures this address on its
attached interface. If the mobile node connects to the Proxy attached interface. If the mobile node connects to the Proxy
Mobile IPv6 domain via multiple interfaces each of the interfaces Mobile IPv6 domain via multiple interfaces each of the interfaces
are assigned a unique IPv4 address. All the IPv6 home network are assigned a unique IPv4 address. All the IPv6 home network
prefixes and the IPv4 home address assigned to a given interface prefixes and the IPv4 home address assigned to a given interface
of a mobile node will be managed under one mobility session. of a mobile node will be managed under one mobility session.
Selective De-registration Selective De-registration
It is a procedure for partial de-registration of all the addresses A procedure for partial de-registration of all the addresses that
that belong to one address family, i.e., de-registration of either belong to one address family, i.e., de-registration of either IPv4
IPv4 home address, or all of the IPv6 home network prefixes. home address, or all of the IPv6 home network prefixes.
Encapsulation Modes Encapsulation Modes
This document uses the following terms when referring to the This document uses the following terms when referring to the
different encapsulation modes. different encapsulation modes.
IPv4-or-IPv6-over-IPv6 IPv4-or-IPv6-over-IPv6
IPv4 or IPv6 packet carried as a payload of an IPv6 packet IPv4 or IPv6 packet carried as a payload of an IPv6 packet
IPv4-or-IPv6-over-IPv4 IPv4-or-IPv6-over-IPv4
IPv4 or IPv6 packet carried as a payload of an IPv4 packet IPv4 or IPv6 packet carried as a payload of an IPv4 packet
IPv4-or-IPv6-over-IPv4-UDP IPv4-or-IPv6-over-IPv4-UDP
IPv4 or IPv6 packet carried as a payload in an UDP header of an IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
IPv4 packet a UDP header
IPv4-or-IPv6-over-IPv4-UDP-TLV IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4 packet carried as a payload in an IPv4 packet with UDP and IPv4 packet carried as a payload in an IPv4 packet with UDP and
TLV headers TLV headers
3. IPv4 Home Address Mobility Support 3. IPv4 Home Address Mobility Support
The IPv4 home address mobility support essentially enables a mobile The IPv4 home address mobility support essentially enables a mobile
node in a Proxy Mobile IPv6 domain to obtain IPv4 home address node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
skipping to change at page 12, line 25 skipping to change at page 12, line 25
3.1.1. Extensions to Binding Cache Entry 3.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 needs to include structure maintained by the local mobility anchor needs to include
the following parameters. the following parameters.
o The IPv4 home address assigned to the mobile node's interface and o The IPv4 home address assigned to the mobile node's interface and
registered by the mobile access gateway. The IPv4 home address registered by the mobile access gateway. The IPv4 home address
entry also includes the corresponding subnet mask. It is to be entry also includes the corresponding subnet mask. It is to be
noted that this parameter is defined in the [ID-DSMIP6] and is noted that this parameter is defined in the [RFC-5555] and is
presented here for completeness. presented here for completeness.
o The IPv4 default-router address assigned to the mobile node. o The IPv4 default router address assigned to the mobile node.
3.1.2. Signaling Considerations 3.1.2. Signaling Considerations
3.1.2.1. Processing Proxy Binding Updates 3.1.2.1. Processing Proxy Binding Updates
The processing rules specified in Section 5.3 of [RFC-5213] are The processing rules specified in Section 5.3 of [RFC-5213] are
applied for processing the received Proxy Binding Update message. applied for processing the received Proxy Binding Update message.
However, if the received Proxy Binding Update message has an IPv4 However, if the received Proxy Binding Update message has an IPv4
Home Address option [ID-DSMIP6], the following considerations MUST be Home Address option [RFC-5555], the following considerations MUST be
applied additionally. applied additionally.
o If there is an IPv4 Home Address option [ID-DSMIP6] present in the o If there is an IPv4 Home Address option [RFC-5555] present in the
received Proxy Binding Update message, but if there is no Home received Proxy Binding Update message, but if there is no Home
Network Prefix option [RFC-5213] present in the request, the local Network Prefix option [RFC-5213] present in the request, the local
mobility anchor MUST NOT reject the request as specified in mobility anchor MUST NOT reject the request as specified in
Section 5.3.1 of [RFC-5213]. At least one instance of any of Section 5.3.1 of [RFC-5213]. At least one instance of any of
these two options MUST be present. If there is not a single these two options, either the IPv4 Home Address option or the Home
Network Prefix option, MUST be present. If there is not a single
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 it is known from the mobile node's policy profile but either if it is known from the mobile node's policy profile
that the mobile node is not authorized for IPv6 service or if IPv6 that the mobile node is not authorized for IPv6 service or if IPv6
skipping to change at page 13, line 22 skipping to change at page 13, line 23
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 o If there are more than one instance of the IPv4 Home Address
option present in the request, then the local mobility anchor MUST option present in the request, then the local mobility anchor MUST
reject the request and send a Proxy Binding Acknowledgement reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to message with the Status field set to
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
home address assignment not supported). home address assignment not supported).
o If the prefix request(P) flag in the IPv4 Home Address option is o If the prefix request(P) flag in the IPv4 Home Address option
set to a value of 1, then the local mobility anchor MUST reject [RFC-5555] is set to a value of (1), then the local mobility
the request and send a Proxy Binding Acknowledgement message with anchor MUST reject the request and send a Proxy Binding
the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4 Acknowledgement message with the Status field set to
prefix assignment not supported). 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 [RFC-5555] with the IPv4 address in
in the option set to ALL_ZERO, considerations from Section the option set to ALL_ZERO, considerations from Section 5.4.1
5.4.1 of [RFC-5213] MUST be applied. of [RFC-5213] MUST be applied.
* If there is an IPv4 Home Address option [ID-DSMIP6] present in * If there is an IPv4 Home Address option [RFC-5555] present in
the request with the IPv4 address value in the option set to a the request with the IPv4 address value in the option set to a
NON_ZERO value, considerations from Section 3.1.2.7 MUST be NON_ZERO value, considerations from Section 3.1.2.7 MUST be
applied. applied.
o If there is no existing Binding Cache entry that can be associated o If there is no existing Binding Cache entry that can be associated
with the request, the local mobility anchor MUST consider this with the request, the local mobility anchor MUST consider this
request as an initial binding registration request and request as an initial binding registration request and
considerations from Section 3.1.2.2 MUST be applied. considerations from Section 3.1.2.2 MUST be applied.
Additionally, if there are one or more Home Network Prefix options Additionally, if there are one or more Home Network Prefix options
[RFC-5213] present in the request, considerations from Section [RFC-5213] present in the request, considerations from Section
5.3.2 of [RFC-5213] MUST also be applied. 5.3.2 of [RFC-5213] MUST also be applied.
o If there exists a Binding Cache entry that can be associated with o If there exists a Binding Cache entry that can be associated with
the request, the local mobility anchor MUST apply considerations the request, the local mobility anchor MUST apply considerations
from Section 5.3.1 of [RFC-5213], (point 13), to determine if the from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
request is re-registration or a de-registration request and the request is re-registration or a de-registration request. If the
respective considerations from the below sections MUST be applied. request is a re-registration request, considerations from Section
3.1.2.3 MUST be applied and if it is a de-registration request,
considerations from Section 3.1.2.4 MUST be applied.
o If there exists a Binding Cache entry that can be associated with o If there exists a Binding Cache entry that can be associated with
the request and if it is determined that the request is a re- the request and if it is determined that the request is a re-
registration request and with the request to extend IPv4 home registration request for extending IPv4 home address mobility
address mobility support to the existing IPv6-only mobility support to the existing IPv6-only mobility session, considerations
session, considerations from Section 3.1.2.2 MUST be applied with from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
respect to IPv4 support.
3.1.2.2. Initial Binding Registration (New Mobility Session) 3.1.2.2. Initial Binding Registration (New Mobility Session)
o If there is an IPv4 Home Address option [ID-DSMIP6] present in the o If there is an IPv4 Home Address option [RFC-5555] present in the
Proxy Binding Update message with the IPv4 address value in the Proxy Binding Update message with the IPv4 address value in the
option set to ALL_ZERO, the local mobility anchor MUST allocate an option set to ALL_ZERO, the local mobility anchor MUST allocate an
IPv4 home address to the mobile node and associate it with the new IPv4 home address to the mobile node and associate it with the new
mobility session created for that mobile node. mobility session created for that mobile node.
o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4 o If there is an IPv4 Home Address option [RFC-5555] with the IPv4
address in the option set to a NON_ZERO value, the local mobility address in the option set to a NON_ZERO value, the local mobility
anchor before accepting the request MUST ensure the address is anchor before accepting the request MUST ensure the address is
topologically anchored on the local mobility anchor and topologically anchored on the local mobility anchor and
furthermore the mobile node is authorized to use that address. If furthermore the mobile node is authorized to use that address. If
the mobile node is not authorized for that specific address, the the mobile node is not authorized for that specific address, 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 the Status field set to Binding Acknowledgement message with the Status field set to
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
for the requesting IPv4 address). It MUST also include the IPv4 for the requesting IPv4 address). It MUST also include the IPv4
Address Acknowledgement option [ID-DSMIP6] in the reply with the Address Acknowledgement option [RFC-5555] in the reply with the
status field value in the option set to 129 (Administratively status field value in the option set to 129 (Administratively
prohibited). prohibited).
o If the local mobility anchor is unable to allocate an IPv4 address o If the local mobility anchor is unable to allocate an IPv4 address
due to lack of resources, it MUST reject the request and send a due to lack of resources, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to 130 Proxy Binding Acknowledgement message with Status field set to 130
(Insufficient resources). It MUST also include the IPv4 Address (Insufficient resources). It MUST also include the IPv4 Address
Acknowledgement option [ID-DSMIP6] in the reply with the status Acknowledgement option [RFC-5555] in the reply with the status
field value in the option set to 128 (Failure, reason field value in the option set to 128 (Failure, reason
unspecified). unspecified).
o Upon accepting the request, the local mobility anchor MUST create o Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for this mobility session. However, if the a Binding Cache entry for this mobility session. However, if the
request also contains one or more Home Network Prefix options [ID- request also contains one or more Home Network Prefix options
DSMIP6], there should still be only one Binding Cache entry that [RFC-5555], there should still be only one Binding Cache entry
should be created for this mobility session. The created Binding that should be created for this mobility session. The created
Cache entry MUST be used for managing both IPv4 and IPv6 home Binding Cache entry MUST be used for managing both IPv4 and IPv6
address bindings. The fields in the Binding Cache entry MUST be home address bindings. The fields in the Binding Cache entry MUST
updated with the accepted values for that session. be updated with the accepted values for that session.
o The local mobility anchor MUST establish a bi-directional tunnel o The local mobility anchor MUST establish a bi-directional tunnel
to the mobile access gateway and with the encapsulation mode set to the mobile access gateway and with the encapsulation mode set
to the negotiated mode for carrying the IPv4 payload traffic. to the negotiated mode for carrying the IPv4 payload traffic.
When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6- When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-
over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6
packet). When using IPv4 transport, the encapsulation mode is as packet). When using IPv4 transport, the encapsulation mode is as
specified in Section 4.0. specified in Section 4.0.
o The local mobility anchor MUST create an IPv4 host route (or a o The local mobility anchor MUST create an IPv4 host route (or a
skipping to change at page 15, line 42 skipping to change at page 15, line 47
3.1.2.4. Binding Lifetime Extension (After handoff) 3.1.2.4. Binding Lifetime Extension (After handoff)
o If there is no Home Network Prefix option(s) [RFC-5213] present in o If there is no Home Network Prefix option(s) [RFC-5213] present in
the request, but if the Binding Cache entry associated with this the request, but if the Binding Cache entry associated with this
request has IPv6 home network prefix(es), the local mobility request has IPv6 home network prefix(es), the local mobility
anchor MUST consider this as a request to extend lifetime only for anchor MUST consider this as a request to extend lifetime only for
the IPv4 home address and not for the IPv6 home network the IPv4 home address and not for the IPv6 home network
prefix(es). Hence, the local mobility anchor SHOULD release all prefix(es). Hence, the local mobility anchor SHOULD release all
the IPv6 home network prefix(es) assigned to that mobile node and the IPv6 home network prefix(es) assigned to that mobile node and
for that specific attached interface. Similar considerations for that specific attached interface. Similar considerations
apply for the case where there is no IPv4 Home Address option [ID- apply for the case where there is no IPv4 Home Address option
DSMIP6] present in the request, but if the Binding Cache entry [RFC-5555] present in the request, but if the Binding Cache entry
associated with that request has both IPv4 home address and IPv6 associated with that request has both IPv4 home address and IPv6
home network prefix(es). home network prefix(es).
o The local mobility anchor MUST remove the previously created IPv4 o The local mobility anchor MUST remove the previously created IPv4
host route (or the forwarding state) and the dynamically created host route (or the forwarding state) and the dynamically created
bi-directional tunnel for carrying the IPv4 payload traffic (if bi-directional tunnel for carrying the IPv4 payload traffic (if
there are no other mobile nodes for which the tunnel is being there are no other mobile nodes for which the tunnel is being
used). This will remove the routing state towards the mobile used). This will remove the routing state towards the mobile
access gateway where the mobile node was anchored prior to the access gateway where the mobile node was anchored prior to the
handoff. handoff.
skipping to change at page 16, line 43 skipping to change at page 16, line 48
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
include at least one instance of Home Network Prefix option [RFC- include at least one instance of Home Network Prefix option [RFC-
5213] in the Proxy Binding Acknowledgement message that it sends 5213] in the Proxy Binding Acknowledgement message that it sends
to the mobile access gateway. However, if the received Proxy to the mobile access gateway. However, if the received Proxy
Binding Update message has only the IPv4 Home Address option [ID- Binding Update message has only the IPv4 Home Address option [RFC-
DSMIP6] and did not contain the Home Network Prefix option(s), 5555] and did not contain the Home Network Prefix option(s), then
then the local mobility anchor MUST NOT include any Home Network the local mobility anchor MUST NOT include any Home Network Prefix
Prefix option(s) in the reply. However, there MUST be at least option(s) in the reply. However, there MUST be at least one
one instance of either the Home Network Prefix option [RFC-5213] instance of either the Home Network Prefix option [RFC-5213] or
or the IPv4 Address Acknowledgement option [ID-DSMIP6] present in the IPv4 Address Acknowledgement option [RFC-5555] present in the
the Proxy Binding Acknowledgement message. Proxy Binding Acknowledgement message.
o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be o The IPv4 Address Acknowledgement option [RFC-5555] MUST be present
present in the Proxy Binding Acknowledgement message. in the Proxy Binding Acknowledgement message.
1. If the Status field is set to a value greater than or equal to 1. If the Status field is set to a value greater than or equal to
128, i.e., if the Proxy Binding Update is rejected, then there (128), i.e., if the Proxy Binding Update is rejected, then
MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6] there MUST be an IPv4 Address Acknowledgement option [RFC-
corresponding to the IPv4 Home Address option [ID-DSMIP6] 5555] corresponding to the IPv4 Home Address option [RFC-5555]
present in the request and with the IPv4 address value and the present in the request and with the IPv4 address value and the
prefix length fields in the option set to the corresponding prefix length fields in the option set to the corresponding
values in the request. The status field value in the option values in the request. The status field value in the option
must be set to the specific error code. must be set to the specific error code.
2. For all other cases, there MUST be an IPv4 Address 2. For all other cases, there MUST be an IPv4 Address
Acknowledgement option for carrying the IPv4 home address Acknowledgement option for carrying the IPv4 home address
assigned for that mobility session and with the value in the assigned for that mobility session and with the value in the
option set to the allocated IPv4 address. The prefix length option set to the allocated IPv4 address. The prefix length
in the option MUST be set to the prefix length of the in the option MUST be set to the prefix length of the
allocated address. The status field value in the option must allocated address. The status field value in the option must
be set to 0 (Success). be set to 0 (Success).
o The IPv4 Default-Router Address option MUST be present, if the o The IPv4 Default-Router Address option MUST be present, if the
Status field value in the Proxy Binding Acknowledgement message is Status field value in the Proxy Binding Acknowledgement message is
set to 0 (Proxy Binding Update Accepted). Otherwise, the option set to 0 (Proxy Binding Update Accepted). Otherwise, the option
MUST NOT be present. If the option is present, the default-router MUST NOT be present. If the option is present, the default router
address in the option MUST be set to the mobile node's default- address in the option MUST be set to the mobile node's default
router address. router address.
3.1.2.7. Binding Cache Entry Lookup Considerations 3.1.2.7. Binding Cache Entry Lookup Considerations
The Binding Cache entry lookup considerations specified in section The Binding Cache entry lookup considerations specified in section
5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213]
as the key parameter for identifying the Binding Cache entry. as the key parameter for identifying the Binding Cache entry.
However, when there is not a single Home Network Prefix option with However, when there are no Home Network Prefix options with a
NON_ZERO value present in the request, but if there an IPv4 Home NON_ZERO value present in the request a single Home Network Prefix
Address option with a NON_ZERO value present in the request, the option with NON_ZERO value present in the request, but if there an
following considerations MUST be applied. IPv4 Home Address option with a NON_ZERO value present in the
request, the following considerations MUST be applied.
o The search rules specified in section 5.4.1.1 of [RFC-5213], which o The search rules specified in section 5.4.1.1 of [RFC-5213], which
primarily uses IPv6 home network prefix set as the search key, are primarily uses IPv6 home network prefix set as the search key, are
equally valid when using a single IPv4 home address as the key. equally valid when using a single IPv4 home address as the key.
When applying those considerations, instead of the IPv6 home When applying those considerations, instead of the IPv6 home
network prefix(es), the IPv4 home address from the IPv4 Home network prefix(es), the IPv4 home address from the IPv4 Home
Address option present in the request MUST be used as the search Address option present in the request MUST be used as the search
key. key.
o These rules specified in section 5.4.1.1 of [RFC-5213], assume the o These rules specified in section 5.4.1.1 of [RFC-5213], assume the
skipping to change at page 18, line 13 skipping to change at page 18, line 17
request and also in the Binding Cache entry. But, when using the request and also in the Binding Cache entry. But, when using the
IPv4 home address as the search key, these considerations MUST IPv4 home address as the search key, these considerations MUST
always assume just one single IPv4 home address, both in the always assume just one single IPv4 home address, both in the
request and also in the Binding Cache entry. request and also in the Binding Cache entry.
3.1.3. Routing Considerations for the Local Mobility Anchor 3.1.3. Routing Considerations for the Local Mobility Anchor
Intercepting Packets Sent to the Mobile Node's IPv4 home address: Intercepting Packets Sent to the Mobile Node's IPv4 home address:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
be able to receive packets that are sent to the mobile node's IPv4
home address. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for advertise a connected route in to the Routing Infrastructure for
the mobile node's IPv4 home address or for its home subnet. This the mobile node's IPv4 home address or for its home subnet, in
essentially enables IPv4 routers in that network to detect the order to receive packets that are sent to the mobile node's IPv4
local mobility anchor as the last-hop router for that subnet. home address. This essentially enables IPv4 routers in that
network to detect the local mobility anchor as the last-hop router
for that subnet.
Forwarding Packets to the Mobile Node: Forwarding Packets to the Mobile Node:
o On receiving a packet from a correspondent node with the o On receiving a packet from a correspondent node with the
destination address matching the mobile node's IPv4 home address, destination address matching the mobile node's IPv4 home address,
the local mobility anchor MUST forward the packet through the bi- the local mobility anchor MUST forward the packet through the bi-
directional tunnel setup for that mobile node. directional tunnel setup for that mobile node.
o The format of the tunneled packet when payload protection is not o The format of the tunneled packet when payload protection is not
enabled: enabled:
skipping to change at page 19, line 19 skipping to change at page 19, line 19
To support the IPv4 home address mobility feature, the conceptual To support the IPv4 home address mobility feature, the conceptual
Binding Update List entry data structure needs to be extended with Binding Update List entry data structure needs to be extended with
the following additional fields. the following additional fields.
o The IPv4 home address assigned to the mobile node's attached o The IPv4 home address assigned to the mobile node's attached
interface. This IPv4 home address may have been statically interface. This IPv4 home address may have been statically
configured in the mobile node's policy profile, or, may have been configured in the mobile node's policy profile, or, may have been
dynamically allocated by the local mobility anchor. The IPv4 home dynamically allocated by the local mobility anchor. The IPv4 home
address entry also includes the corresponding subnet mask. address entry also includes the corresponding subnet mask.
o The IPv4 default-router address of the mobile node. This is o The IPv4 default router address of the mobile node. This is
acquired from the mobile node's local mobility anchor through the acquired from the mobile node's local mobility anchor through the
received Proxy Binding Acknowledgment message. received Proxy Binding Acknowledgment message.
3.2.2. Extensions to Mobile Node's Policy Profile 3.2.2. Extensions to Mobile Node's Policy Profile
To support the IPv4 Home Address Mobility Support feature the mobile To support the IPv4 Home Address Mobility Support feature the mobile
node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be
extended with the following additional fields. extended with the following additional fields.
Extensions to the mandatory section of the policy profile: Extensions to the mandatory section of the policy profile:
skipping to change at page 20, line 18 skipping to change at page 20, line 18
access gateway on the access link MUST determine if IPv4 home address access gateway on the access link MUST determine if IPv4 home address
mobility support needs to be enabled for that mobile node. The mobility support needs to be enabled for that mobile node. The
mobile node's policy profile identifies the supported modes (IPv4- mobile node's policy profile identifies the supported modes (IPv4-
only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the
mobile service needs to be enabled. Based on those policy mobile service needs to be enabled. Based on those policy
considerations and from other triggers such as from the network, if considerations and from other triggers such as from the network, if
it is determined that IPv4 home address mobility support needs to be it is determined that IPv4 home address mobility support needs to be
enabled for the mobile node, considerations from section 6.9.1.1 of enabled for the mobile node, considerations from section 6.9.1.1 of
[RFC-5213] MUST be applied with the following exceptions. [RFC-5213] MUST be applied with the following exceptions.
o The IPv4 Home Address option [ID-DSMIP6] MUST be present in the o The IPv4 Home Address option [RFC-5555] MUST be present in the
Proxy Binding Update message. Proxy Binding Update message.
* If the mobile access gateway learns the mobile node's IPv4 home * If the mobile access gateway learns the mobile node's IPv4 home
address either from its policy profile, or from other means, address either from its policy profile, or from other means,
the mobile access gateway MAY ask the local mobility anchor to the mobile access gateway MAY ask the local mobility anchor to
allocate that specific address by including exactly one allocate that specific address by including exactly one
instance of the IPv4 Home Address option [ID-DSMIP6] with the instance of the IPv4 Home Address option [RFC-5555] with the
IPv4 home address and the prefix length fields in the option IPv4 home address and the prefix length fields in the option
set to that specific address and its prefix length. set to that specific address and its prefix length.
Furthermore, the (P) flag in the option MUST be set to 0. Furthermore, the (P) flag in the option MUST be set to 0.
* The mobile access gateway MAY also ask the local mobility * The mobile access gateway MAY also ask the local mobility
anchor for dynamic IPv4 home address allocation. It can anchor for dynamic IPv4 home address allocation. It can
include exactly one instance of the IPv4 Home Address option include exactly one instance of the IPv4 Home Address option
with the IPv4 home address and the prefix length fields in the with the IPv4 home address and the prefix length fields in the
option set to ALL_ZERO value. Furthermore, the (P) flag in the option set to ALL_ZERO value. Furthermore, the (P) flag in the
option MUST be set to 0. This essentially serves as a request option MUST be set to 0. This essentially serves as a request
skipping to change at page 21, line 14 skipping to change at page 21, line 14
3.2.3.2. Receiving Proxy Binding Acknowledgement 3.2.3.2. Receiving Proxy Binding Acknowledgement
All the considerations from section 6.9.1.2 of [RFC-5213] MUST be All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
applied with the following exceptions. applied with the following exceptions.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
mobile node is not authorized for IPv4 home address), the mobile mobile node is not authorized for IPv4 home address), the mobile
access gateway SHOULD NOT send a Proxy Binding Update message access gateway SHOULD NOT send a Proxy Binding Update message
including the IPv4 Home Address option [ID-DSMIP6] till an including the IPv4 Home Address option [RFC-5555] till an
administrative action is taken. administrative action is taken.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
mobile node is not authorized for the requesting IPv4 home mobile node is not authorized for the requesting IPv4 home
address), the mobile access gateway SHOULD NOT request for the address), the mobile access gateway SHOULD NOT request for the
same address again, but MAY request the local mobility anchor to same address again, but MAY request the local mobility anchor to
do the assignment of address by including exactly one instance of do the assignment of address by including exactly one instance of
IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address IPv4 Home Address option [RFC-5555] with the IPv4 home address and
and the prefix length fields in the option set to ALL_ZERO value. the prefix length fields in the option set to ALL_ZERO value.
o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6] o If there is no IPv4 Address Acknowledgement option [RFC-5555]
present in the received Proxy Binding Acknowledgement message, the present in the received Proxy Binding Acknowledgement message, the
mobile access gateway MUST NOT enable IPv4 support for the mobile mobile access gateway MUST NOT enable IPv4 support for the mobile
node and the rest of the considerations from this section can be node and the rest of the considerations from this section can be
skipped. skipped.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value in the IPv4 Address Acknowledgement Option [ID- Status field value in the IPv4 Address Acknowledgement Option
DSMIP6] set to a value that indicates that the request was [RFC-5555] set to a value that indicates that the request was
rejected by the local mobility anchor, the mobile access gateway rejected by the local mobility anchor, the mobile access gateway
MUST NOT enable forwarding for that specific IPv4 home address. MUST NOT enable forwarding for that specific IPv4 home address.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST update a Binding Update List entry for mobile access gateway MUST update a Binding Update List entry for
that mobile node. The entry MUST be updated with the assigned that mobile node. The entry MUST be updated with the assigned
IPv4 home address and other accepted registration values. IPv4 home address and other accepted registration values.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted) and Status field value set to 0 (Proxy Binding Update accepted) and
has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a has the IPv4 Address Acknowledgement Option [RFC-5555] set to a
value that indicates that the request was accepted by the local value that indicates that the request was accepted by the local
mobility anchor, the mobile access gateway MUST establish a bi- mobility anchor, the mobile access gateway MUST establish a bi-
directional tunnel to the local mobility anchor (if there is no directional tunnel to the local mobility anchor (if there is no
existing bi-directional tunnel to that local mobility anchor) and existing bi-directional tunnel to that local mobility anchor) and
with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or
IPv6 packet carried as a payload of an IPv6 packet). IPv6 packet carried as a payload of an IPv6 packet).
Considerations from Section 5.6.1 of [RFC-5213] MUST be applied Considerations from Section 5.6.1 of [RFC-5213] MUST be applied
for managing the dynamically created bi-directional tunnel. for managing the dynamically created bi-directional tunnel.
However, when using IPv4 transport, the encapsulation mode MUST be However, when using IPv4 transport, the encapsulation mode MUST be
set to the negotiated encapsulation mode, as specified in Section set to the negotiated encapsulation mode, as specified in Section
4 of this specification. 4 of this specification.
o The mobile access gateway MUST set up the route for forwarding the o The mobile access gateway MUST set up the route for forwarding the
IPv4 packets received from the mobile node (using its IPv4 home IPv4 packets received from the mobile node (using its IPv4 home
address) through the bi-directional tunnel set up for that mobile address) through the bi-directional tunnel set up for that mobile
node. node.
o The default-router address MUST be obtained from the IPv4 Default- o The default router address MUST be obtained from the IPv4 Default-
Router Address option present in the received Proxy Binding Router Address option present in the received Proxy Binding
Acknowledgement message. The mobile access gateway MAY configure Acknowledgement message. The mobile access gateway MAY configure
this address on its interface and respond to any ARP requests sent this address on its interface and respond to any ARP requests sent
by the mobile node for resolving the hardware address of the by the mobile node for resolving the hardware address of the
default-router. It MAY also use this address as the source default router. It MAY also use this address as the source
address for any datagrams sent to the mobile node and originated address for any datagrams sent to the mobile node and originated
by the mobile access gateway itself. It MAY also use this address by the mobile access gateway itself. It MAY also use this address
in the DHCP Router option [RFC-2132] in the DHCP messages. in the DHCP Router option [RFC-2132] in the DHCP messages.
o If there is an IPv4 DHCP Support Mode option present in the o If there is an IPv4 DHCP Support Mode option present in the
received Proxy Binding Acknowledgement message and if the (S) flag received Proxy Binding Acknowledgement message and if the (S) flag
in the option is set to a value of 1, then the mobile access in the option is set to a value of (1), then the mobile access
gateway MUST function as a DHCP server for the mobile node. If gateway MUST function as a DHCP server for the mobile node. If
either the (S) flag in the option is set to a value of 0, or if either the (S) flag in the option is set to a value of (0), or if
the option is not present in the request, then the mobile access the option is not present in the request, then the mobile access
gateway MUST function as a DHCP Relay for the mobile node. gateway MUST function as a DHCP Relay for the mobile node.
3.2.3.3. Binding Re-Registration and De-Registrations 3.2.3.3. Binding Re-Registration and De-Registrations
When sending a Proxy Binding Update either for extending the lifetime When sending a Proxy Binding Update either for extending the lifetime
of a mobility session or for de-registering the mobility session, the of a mobility session or for de-registering the mobility session, the
respective considerations from [RFC-5213] MUST be applied. respective considerations from [RFC-5213] MUST be applied.
Furthermore, the following additional considerations MUST also be Furthermore, the following additional considerations MUST also be
applied. applied.
o If there is an IPv4 home address assigned to the mobility session, o If there is an IPv4 home address assigned to the mobility session,
then there MUST be exactly one instance of the IPv4 Home Address then there MUST be exactly one instance of the IPv4 Home Address
option [ID-DSMIP6] present in the Proxy Binding Update message. option [RFC-5555] present in the Proxy Binding Update message.
The IPv4 home address and the prefix length fields in the option The IPv4 home address and the prefix length fields in the option
MUST be set to that specific address and its corresponding subnet- MUST be set to that specific address and its corresponding subnet-
mask length. The (P) flag in the option MUST be set to 0. mask length. The (P) flag in the option MUST be set to 0.
o If there was no IPv4 home address requested in the initial Proxy o If there was no IPv4 home address requested in the initial Proxy
Binding Update message, but if it is determined that the IPv4 home Binding Update message, but if it is determined that the IPv4 home
address MUST be requested subsequently, then there MUST be exactly address MUST be requested subsequently, then there MUST be exactly
one instance of the IPv4 Home Address option [ID-DSMIP6] present one instance of the IPv4 Home Address option [RFC-5555] present in
in the Proxy Binding Update message. The IPv4 home address in the the Proxy Binding Update message. The IPv4 home address in the
option MUST be set to either ALL_ZERO or to a specific address option MUST be set to either ALL_ZERO or to a specific address
that is being requested. that is being requested.
o For performing selective de-registration of IPv4 home address but o For performing selective de-registration of IPv4 home address but
still retaining the mobility session with all the IPv6 home still retaining the mobility session with all the IPv6 home
network prefixes, the Proxy Binding Update message with the network prefixes, the Proxy Binding Update message with the
lifetime value of 0 MUST NOT include any IPv6 Home Network Prefix lifetime value of (0) MUST NOT include any IPv6 Home Network
options(s) [RFC-5213]. It MUST include exactly one instance of Prefix options(s) [RFC-5213]. It MUST include exactly one
the IPv4 Home Address option [ID-DSMIP6] with the IPv4 home instance of the IPv4 Home Address option [RFC-5555] with the IPv4
address and the prefix length fields in the option set to the IPv4 home address and the prefix length fields in the option set to the
home address that is being de-registered. Similarly for selective IPv4 home address that is being de-registered. Similarly for
de-registration of all the IPv6 home network prefixes, the Proxy selective de-registration of all the IPv6 home network prefixes,
Binding Update message MUST NOT include the IPv4 Home address the Proxy Binding Update message MUST NOT include the IPv4 Home
option, it MUST include a Home Network Prefix option for each of address option, it MUST include a Home Network Prefix option for
the assigned home network prefixes assigned for that mobility each of the assigned home network prefixes assigned for that
session and with the prefix value in the option set to that mobility session and with the prefix value in the option set to
respective prefix value. that respective prefix value.
o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present
if the same option(s) was not present in the initial Proxy Binding if the same option(s) was not present in the initial Proxy Binding
Update message. Otherwise considerations from [RFC-5213] with Update message. Otherwise considerations from [RFC-5213] with
respect to this option MUST be applied. respect to this option MUST be applied.
o If at any point the mobile access gateway fails to extend the o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address. for the mobile node's IPv4 home address.
skipping to change at page 24, line 17 skipping to change at page 24, line 17
3.3. Mobility Options and Status Codes 3.3. Mobility Options and Status Codes
To support the IPv4 home address mobility feature, this specification To support the IPv4 home address mobility feature, this specification
defines the following new options and Status Codes. defines the following new options and Status Codes.
3.3.1. IPv4 Default-Router Address Option 3.3.1. IPv4 Default-Router Address Option
A new option, IPv4 Default-Router Address Option is defined for using A new option, IPv4 Default-Router Address Option is defined for using
it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
local mobility anchor to the mobile access gateway. This option can local mobility anchor to the mobile access gateway. This option can
be used for sending the mobile node's IPv4 default-router address. be used for sending the mobile node's IPv4 default router address.
The IPv4 Default-Router Address option has an alignment requirement The IPv4 Default-Router Address option has an alignment requirement
of 4n. Its format is as follows: of 4n. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | | Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default-Router Address | | IPv4 Default-Router Address |
skipping to change at page 24, line 40 skipping to change at page 24, line 40
Figure 3: IPv4 Default-Router Address Option Figure 3: IPv4 Default-Router Address Option
Type Type
IANA IANA
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST octets, excluding the type and length fields. This field MUST
be set to 6. be set to (6).
Reserved (R) Reserved (R)
This 8-bit field is unused for now. The value MUST be This 16-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the initialized to (0) by the sender and MUST be ignored by the
receiver. receiver.
IPv4 Default-Router Address IPv4 Default-Router Address
A four-byte field containing the mobile node's default router A four-byte field containing the mobile node's default router
address. address.
3.3.2. IPv4 DHCP Support Mode 3.3.2. IPv4 DHCP Support Mode
A new option, IPv4 DHCP Support Mode Option is defined for using it A new option, IPv4 DHCP Support Mode Option is defined for using it
skipping to change at page 25, line 43 skipping to change at page 25, line 43
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST octets, excluding the type and length fields. This field MUST
be set to 2. be set to 2.
Reserved (R) Reserved (R)
This 15-bit field is unused for now. The value MUST be This 15-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the initialized to (0) by the sender and MUST be ignored by the
receiver. receiver.
DHCP Support Mode (S) DHCP Support Mode (S)
A 1-bit field that specifies the DHCP support mode. This flag A 1-bit field that specifies the DHCP support mode. This flag
indicates if the mobile access gateway should function as a indicates if the mobile access gateway should function as a
DHCP Server or a DHCP Relay for the attached mobile node. The DHCP Server or a DHCP Relay for the attached mobile node. The
flag value of (0) indicates the mobile access gateway should flag value of (0) indicates the mobile access gateway should
act as a DHCP Relay and the flag value of (1) indicates it act as a DHCP Relay and the flag value of (1) indicates it
should act as a DHCP Server. should act as a DHCP Server.
skipping to change at page 27, line 11 skipping to change at page 27, line 11
configurations. configurations.
o DHCP relay agent co-located with the mobile access gateway. o DHCP relay agent co-located with the mobile access gateway.
o DHCP server co-located in the mobile access gateway. o DHCP server co-located in the mobile access gateway.
The following are the configuration requirements: The following are the configuration requirements:
o The DHCP server or the DHCP relay agent configured on the mobile o The DHCP server or the DHCP relay agent configured on the mobile
access gateway is required to have an IPv4 address for exchanging access gateway is required to have an IPv4 address for exchanging
the DHCP messages with the mobile node. This address can be the DHCP messages with the mobile node. This address is the
either the IPv4 Proxy Care-of Address or the mobile node's mobile node's default router address provided by the local
default-router address provided by the local mobility anchor. mobility anchor. Optionally, all the DHCP servers co-located with
Optionally, all the DHCP servers co-located with the mobile access the mobile access gateways in the Proxy Mobile IPv6 domain can be
gateways in the Proxy Mobile IPv6 domain can be configured with a configured with a fixed IPv4 address. This fixed address can be
fixed IPv4 address. This fixed address can be potentially an IPv4 potentially an IPv4 private address [RFC-1918] that can be used
private address [RFC-1918] that can be used for the DHCP protocol for the DHCP protocol communication on any of the access links.
communication on any of the access links. This address will be This address will be used as the server identifier in the DHCP
used as the server identifier in the DHCP messages. messages.
o A DHCP server identifies the DHCP client and its interface for o A DHCP server identifies a DHCP client from the client identifier,
which the address is assigned from the client identifier and the if present, or from the client hardware address (chaddr), as
client hardware address (chaddr) [RFC-2131] fields respectively. specified in [RFC-2131]. It uses this identity for identifying
A mobile node in a Proxy Mobile IPv6 domain, can attach to the the client and its interface for which the address is assigned. A
network through multiple interfaces and additionally may perform mobile node in a Proxy Mobile IPv6 domain, can attach to the
handoffs between its interfaces. Following are the related network through multiple interfaces and can obtain address
considerations: configuration for each of its interfaces. Additionally, it may
perform handoffs between its interfaces. Following are the
related considerations with respect to the identification
presented to the DHCP server.
* If the mobile node attaches to the Proxy Mobile IPv6 domain * If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple interfaces, the DHCP server will uniquely through multiple interfaces, the DHCP server will uniquely
identify each of those interfaces from the client hardware identify each of those interfaces from the client hardware
address and will perform address assignment. As the mobile address and will perform address assignment. As the mobile
node changes its point of attachment in the network and node changes its point of attachment in the network and
performs an handoff to a different mobile access gateway, using performs an handoff to a different mobile access gateway, using
the same interface, the DHCP server will always be able to the same interface, the DHCP server will always be able to
identify the binding using the presented client hardware identify the binding using the presented client hardware
address. The client hardware address and client identifier address. The client hardware address and client identifier
skipping to change at page 28, line 26 skipping to change at page 28, line 28
MN MAG(DHCP-S) LMA MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER |------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update | |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| 4. Tunnel/Route Setup | |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA) |<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK |<------| | 7. DHCPACK
| | | | | |
* DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling * The DHCP address configuration (starting at Step-1) and the Proxy
* (Step-2 to Step-4) may happen in parallel and in no specific order Mobile IPv6 signaling (starting at Step-2) may start in any order.
* Tunnel/Route setup(Step-4) and the subsequent steps will happen in However, the DHCPOFFER (Step-5) and the immediate steps following
* in the specified order. it will occur in the specified order and only after the
Tunnel/Route Setup (Step-4).
Figure 5: Overview of DHCP Server located at Mobile Access Gateway Figure 5: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the o For acquiring the mobile node's IPv4 home address from the local
DHCP server co-located with the mobile access gateway will trigger mobility anchor, the mobile access gateway will initiate Proxy
the mobile access gateway to complete the Proxy Mobile IPv6 Mobile IPv6 signaling with the local mobility anchor.
signaling. This is the required interaction between these two
protocols. If the mobile access gateway is unable to complete the
Proxy Mobile IPv6 signaling, or, if the local mobility anchor does
not assign an IPv4 address for the mobile node, the mobile access
gateway MUST NOT enable IPv4 support for the mobile node on that
access link. The trigger for initiating Proxy Mobile IPv6
signaling can also be delivered to the mobile access gateway as
part of a context transfer from the previous mobile access
gateway, or delivered from the other network elements in the radio
network, the details of which are outside the scope of this
document.
o After a successful completion of the Proxy Mobile IPv6 signaling o After the successful completion of the Proxy Mobile IPv6 signaling
and upon acquiring the mobile node's IPv4 home address from the and upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the DHCP server on the mobile access local mobility anchor, the DHCP server on the mobile access
gateway will send a DHCPOFFER message [RFC-2131] to the mobile gateway will send a DHCPOFFER message [RFC-2131] to the mobile
node. The offered address will be the mobile node's IPv4 home node. The offered address will be the mobile node's IPv4 home
address, assigned by the local mobility anchor. The server address, assigned by the local mobility anchor. The DHCPOFFER
address, 'siaddr' field of the DHCPOFFER message, will be set to message will have the server address field (siaddr) and the
the mobile node's default-router address. The DHCPOFFER message default router option set to the mobile node's default router
will be sent to the mobile node just as specified in [RFC-2131]. address. The DHCPOFFER message will be sent to the mobile node
just as specified in [RFC-2131].
o If the mobile node sends the DHCPREQUEST message, the DHCP server o If the mobile node sends the DHCPREQUEST message, the DHCP server
will send DHCPACK message, as per [RFC-2131]. will send DHCPACK message, as per [RFC-2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff): IPv4 Home Address Renewal with the DHCP server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state [RFC- o Any time the mobile node goes into the DHCP RENEWING state [RFC-
2131], it simply unicasts the DHCPREQUEST message including the 2131], it simply unicasts the DHCPREQUEST message including the
assigned IPv4 home address in the 'requested IP address' option. assigned IPv4 home address in the 'requested IP address' option.
The DHCPREQUEST is sent to the address specified in 'server The DHCPREQUEST is sent to the address specified in 'server
identifier' field of the previously received DHCPOFFER and DHCPACK identifier' field of the previously received DHCPOFFER and DHCPACK
messages. messages.
o The DHCP server will send a DHCPACK to the mobile node to o The DHCP server will send a DHCPACK to the mobile node to
acknowledge the assignment of the committed IPv4 address. acknowledge the assignment of the committed IPv4 address.
IPv4 Home Address Renewal with a different DHCP server (After IPv4 Home Address Renewal with the DHCP server (After Handoff):
Handoff):
When the mobile node goes into the DHCP RENEWING state [RFC-2131], it When the mobile node goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile changed its point of attachment and is attached to a new mobile
access gateway, it is required that the mobile node updates the DHCP access gateway, it is required that the mobile node updates the DHCP
server address and uses the address of the DHCP server that is co- server address and uses the address of the DHCP server that is co-
located with the new mobile access gateway. The following approach located with the new mobile access gateway. The following approach
can be adopted to ensure the mobile node uses the DHCP server on the can be adopted to ensure the mobile node uses the DHCP server on the
attached link. attached link.
The use of fixed DHCP server address on all DHCP servers
MN oMAG(DHCP-S) nMAG(DHCP-S) MN oMAG(DHCP-S) nMAG(DHCP-S)
| : | | : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK or DHCPNACK BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : | | : |
Figure 6: Address renewal with a different DHCP server * The use of a fixed DHCP server address on all DHCP servers
o If a fixed address such as the IPv4 default-router address of the Figure 6: Address renewal with the DHCP server
o If a fixed address such as the IPv4 default router address of the
mobile node is used as the DHCP server Id on any of the links in mobile node is used as the DHCP server Id on any of the links in
that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the
mobile node for renewing the address will be received by the new mobile node for renewing the address will be received by the new
mobile access gateway on the attached link. The mobile access mobile access gateway on the attached link. The mobile access
gateway after completing the Proxy Mobile IPv6 signaling and upon gateway after completing the Proxy Mobile IPv6 signaling and upon
acquiring the IPv4 home address of the mobile node will return the acquiring the IPv4 home address of the mobile node will return the
address in the DHCPACK message. However, if the mobile access address in the DHCPACK message. However, if the mobile access
gateway is unable to complete the Proxy Mobile IPv6 signaling or gateway is unable to complete the Proxy Mobile IPv6 signaling or
is unable to acquire the same IPv4 address as requested by the is unable to acquire the same IPv4 address as requested by the
mobile node, it will send a DHCPNACK message [RFC-2131] to the mobile node, it will send a DHCPNACK message [RFC-2131] to the
skipping to change at page 30, line 33 skipping to change at page 30, line 27
(e.g., is co-located with the local mobility anchor). Figure 7 shows (e.g., is co-located with the local mobility anchor). Figure 7 shows
the sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA)
| |========| | 3. Tunnel/Route Setup* | |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R |------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK via DHCP-R |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | | | | |
* The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the * The Proxy Mobile IPv6 signaling (starting at Step-1) and the
DHCPDISCOVER phase (Step-4) may occur in any order. However, DHCP address configuration (starting at Step-4) may start in any
the DHCPOFFER (Step-5) and the following steps will occur in order. However, the DHCPOFFER (Step-5) and the immediate steps
the specified order and after the Tunnel/Route Setup (Step-3). following it will occur in the specified order and only after the
Tunnel/Route Setup (Step-3).
Figure 7: Overview of the DHCP relay located at mobile access gateway Figure 7: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o When the mobile access gateway receives a DHCPDISCOVER message o For acquiring the mobile node's IPv4 home address from the local
from a mobile node, it can check if there is already an assigned mobility anchor, the mobile access gateway will initiate Proxy
IPv4 home address for the mobile node, from the local mobility Mobile IPv6 signaling with the local mobility anchor.
anchor. If there is no assigned IPv4 home address assigned for
that mobile node, the mobile access gateway has to complete the
Proxy Mobile IPv6 signaling with the local mobility anchor by
sending a Proxy Binding Update message. It is to be noted that
the mobile node needs to be identified by the MN-Identifier, as
specified in Section 6.6 of [RFC-5213].
o If the Proxy Binding Update message is rejected by the local
mobility anchor for any reason, the mobile access gateway will
discard the DHCPDISCOVER messages from the mobile node.
o If the Proxy Binding Update message is accepted by the local o After the successful completion of the Proxy Mobile IPv6 signaling
mobility anchor and if there is an assigned IPv4 home address for and upon acquiring the mobile node's IPv4 home address from the
the mobile node, the DHCP messages will be forwarded to the DHCP local mobility anchor, the mobile access gateway will enable
server. forwarding for all the DHCP messages between the mobile node and
the DHCP 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 o On receiving a DHCPOFFER message from the DHCP server, the mobile
access gateway will ensure the assigned address is currently access gateway will ensure the assigned address is currently
skipping to change at page 31, line 41 skipping to change at page 31, line 28
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 a route towards the DHCP server. have a 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 Handoff)
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 messages to the DHCP server. The directly unicasts DHCPREQUEST messages to the DHCP server. The
DHCP relay agent may not detect any changes in the DHCP state. DHCP relay agent may not detect any changes in the DHCP state.
For example, if the mobile node releases the IPv4 address, the For example, if the mobile node releases the IPv4 address, the
relay agent would not be aware of it. The following describes relay agent would not be aware of it. The following describes
additional mechanisms for the mobile access gateway to detect any additional mechanisms for the mobile access gateway to detect any
changes in the DHCP state. changes in the DHCP state.
* The DHCP relay agent can intercept all IPv4 DHCP packets * The DHCP relay agent can intercept all IPv4 DHCP packets
skipping to change at page 32, line 43 skipping to change at page 32, line 28
for the mobile node, then the mobile access gateway SHOULD for the mobile node, then the mobile access gateway SHOULD
silently drop the DHCP message. silently drop the DHCP message.
o Any time the mobile access gateway detects that the mobile node o Any time the mobile access gateway detects that the mobile node
has released its IPv4 address, it can send a Proxy Binding Update has released its IPv4 address, it can send a Proxy Binding Update
to the local mobility anchor and de-register the IPv4 mobility to the local mobility anchor and de-register the IPv4 mobility
session. session.
3.4.3. Common DHCP Considerations 3.4.3. Common DHCP Considerations
The following handoff considerations are common to both the supported The following DHCP related considerations are common to both the
configuration modes, specified in Section 3.4.1 and Section 3.4.2. supported configuration modes, specified in Section 3.4.1 and Section
3.4.2.
o When a mobile node sends a DHCPDISCOVER message [RFC-2131], the
DHCP server or the relay agent co-located with the mobile access
gateway will trigger the mobile access gateway to complete the
Proxy Mobile IPv6 signaling. This is the required interaction
between these two protocols. The mobile access gateway on
receiving this trigger will check if there is already an assigned
IPv4 home address for the mobile node, from the local mobility
anchor. If there is no assigned IPv4 home address assigned for
that mobile node, the mobile access gateway will complete the
Proxy Mobile IPv6 signaling with the local mobility anchor by
sending a Proxy Binding Update message.
o The mobile node needs to be identified by the MN-Identifier, as
specified in Section 6.6 of [RFC-5213]. This identity should be
associated to the DHCP messages sent by the mobile node.
o The mobile access gateway will drop all the DHCPDISCOVER messages
till it completes the Proxy Mobile IPv6 signaling. If the mobile
access gateway is unable to complete the Proxy Mobile IPv6
signaling, or, if the local mobility anchor does not assign an
IPv4 address for the mobile node, the mobile access gateway MUST
NOT enable IPv4 home address mobility support for the mobile node
on that access link.
o The trigger for initiating Proxy Mobile IPv6 signaling can also be
delivered to the mobile access gateway as part of a context
transfer from the previous mobile access gateway, or delivered
from the other network elements in the radio network, the details
of which are outside the scope of this document.
o When the mobile node performs an handoff from one mobile access o When the mobile node performs an handoff from one mobile access
gateway to the another, the mobile access gateway on the new link gateway to another, the mobile access gateway on the new link will
will initiate the Proxy Mobile IPv6 signaling with the local initiate the Proxy Mobile IPv6 signaling with the local mobility
mobility anchor. On completing the Proxy Mobile IPv6 signaling, anchor. On completing the Proxy Mobile IPv6 signaling, the mobile
the mobile access gateway has the proper IPv4 address state that access gateway has the proper IPv4 address state that the local
the local mobility anchor has allocated for the mobile node and mobility anchor has allocated for the mobile node and which can be
which can be used for supporting DHCP based address configuration used for supporting DHCP based address configuration on that link.
on that link.
o If the mobile node is DNAv4 [RFC-4436] capable and if it performs o Any time the mobile node detects a link change event due to
DNAv4 procedures after a handoff, it would always detect the same handoff, or due to other reasons such as re-establishment of the
default-router on any of the access links in that Proxy Mobile link-layer, the following are the mobile node's considerations
IPv6 domain, as the mobile access gateway configures a fixed link- with respect to the DHCP protocol.
layer address on all the access links, as per the base Proxy
Mobile IPv6 specification [RFC-5213]. The mobile node will not
perform any DHCP operation specifically due to this handoff.
o If the mobile node is not DNAv4 [RFC-4436] capable, after handoff * If the mobile node is DNAv4 [RFC-4436] capable and if it
it will enter INIT-REBOOT state [RFC-2131] and will send a performs DNAv4 procedures after receiving a link change event,
DHCPREQUEST message. The mobile node in both the configuration it would always detect the same default router on any of the
modes, specified in Section 3.4.1 and Section 3.4.2, will obtain access links in that Proxy Mobile IPv6 domain, as the mobile
the same address configuration as before, as the link change will access gateway configures a fixed link-layer address on all the
access links, as per the base Proxy Mobile IPv6 specification
[RFC-5213]. The mobile node will not perform any DHCP
operation specifically due to this event.
* If the mobile node is not DNAv4 [RFC-4436] capable, after
receiving the link change event it will enter INIT-REBOOT state
[RFC-2131] and will send a DHCPREQUEST message as specified in
Section 3.7 of [RFC-2131]. The mobile node will obtain the
same address configuration as before, as the link change will
not be transparent to the mobile node in that Proxy Mobile IPv6 not be transparent to the mobile node in that Proxy Mobile IPv6
domain. domain.
o The mobile node may release its IPv4 home address at any time by o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC-2131]. When the mobile sending the DHCPRELEASE message [RFC-2131]. When the mobile
access gateway detects the DHCPRELEASE message sent by the mobile access gateway detects the DHCPRELEASE message sent by the mobile
node, it should consider this as a trigger for de-registering the node, it should consider this as a trigger for de-registering the
mobile node's IPv4 home address. It will apply the considerations mobile node's IPv4 home address. It will apply the considerations
specified in section 3.2.3.3 for performing the de-registration specified in section 3.2.3.3 for performing the de-registration
procedure. However, this operation should not release any IPv6 procedure. However, this operation MUST NOT release any IPv6 home
home network prefix(es) assigned to the mobile node. network prefix(es) assigned to the mobile node.
4. IPv4 Transport Support 4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling
messages exchanged between the local mobility anchor and the mobile messages exchanged between the local mobility anchor and the mobile
access gateway to be over an IPv6 transport. The extensions defined access gateway to be over an IPv6 transport. The extensions defined
in this section allow the exchange of signaling messages over an IPv4 in this section allow the exchange of signaling messages over an IPv4
transport when the local mobility anchor and the mobile access transport when the local mobility anchor and the mobile access
gateway are separated by an IPv4 network and are reachable using only gateway are separated by an IPv4 network and are reachable using only
IPv4 addresses. IPv4 addresses.
skipping to change at page 34, line 37 skipping to change at page 34, line 37
messages over IPv4 transport and register its IPv4 address as the messages over IPv4 transport and register its IPv4 address as the
care-of address in the mobile node's Binding Cache entry. An IPv4 care-of address in the mobile node's Binding Cache entry. An IPv4
tunnel (with any of the supported encapsulation modes) can be used tunnel (with any of the supported encapsulation modes) can be used
for tunneling the mobile node's data traffic. The following are the for tunneling the mobile node's data traffic. The following are the
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 network.
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. But, 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. However, both the local mobility globally routable IPv4 address. However, both the local mobility
anchor and the mobile access gateway can be in the same private anchor and the mobile access gateway can be in the same private
IPv4 routing domain, i.e., when both are configured with private IPv4 routing domain, i.e., when both are configured with private
IPv4 addresses and with no need for NAT translation between them. IPv4 addresses and with no need for NAT translation between them.
skipping to change at page 35, line 50 skipping to change at page 35, line 50
protection using IPsec is enabled for the tunneled traffic, the protection using IPsec is enabled for the tunneled traffic, the
ESP header follows the outer tunnel header. ESP header follows the outer tunnel header.
4.1. Local Mobility Anchor Considerations 4.1. Local Mobility Anchor Considerations
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. It is to be noted extended with the following additional parameters. It is to be noted
that all of these parameters are specified in [ID-DSMIP6] and also that all of these parameters are specified in [RFC-5555] and also
required here in the present usage context, and are presented here required here in the present usage context, and are presented here
only for completeness. only for completeness.
o The IPv4 Proxy Care-of Address configured on the mobile access o The IPv4 Proxy Care-of Address configured on the mobile access
gateway that sent the Proxy Binding Update message. This address gateway that sent the Proxy Binding Update message. This address
can be obtained from the IPv4 Care-of Address option [ID-DSMIP6], can be obtained from the IPv4 Care-of Address option [RFC-5555],
present in the received Proxy Binding Update message. However, if present in the received Proxy Binding Update message. However, if
the received Proxy Binding Update message is not sent as an IPv4 the received Proxy Binding Update message is not sent as an IPv4
packet, i.e., when using IPv6 transport, this field in the Binding packet, i.e., when using IPv6 transport, this field in the Binding
Cache entry MUST be set to ALL_ZERO value. Cache entry 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
skipping to change at page 36, line 46 skipping to change at page 36, line 46
o The IPv4 address of the local mobility anchor (IPv4-LMAA). o The IPv4 address of the local mobility anchor (IPv4-LMAA).
4.1.3. Signaling Considerations 4.1.3. Signaling Considerations
This section provides the rules for processing the Proxy Mobile IPv6 This section provides the rules for processing the Proxy Mobile IPv6
signaling messages received over IPv4 transport. signaling messages received over IPv4 transport.
4.1.3.1. Processing Proxy Binding Updates 4.1.3.1. Processing Proxy Binding Updates
o If the received Proxy Binding Update message was sent encapsulated o If the received Proxy Binding Update message was sent encapsulated
in IPv4 or IPv4-UDP header, the message MUST be authenticated in an IPv4 or IPv4-UDP packet, the message MUST be authenticated
after removing the outer encapsulation (IPv4 or IPv4-UDP) header. after removing the outer encapsulation (IPv4 or IPv4-UDP) header.
Considerations from Section 4 of [RFC-5213] MUST be applied for Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the request. authenticating and authorizing the request.
o All the considerations from Section 5.3.1 of [RFC-5213] MUST be o All the considerations from Section 5.3.1 of [RFC-5213] MUST be
applied on the encapsulated Proxy Binding Update message, after applied on the encapsulated Proxy Binding Update message, after
removing the outer encapsulation (IPv4 or IPv4-UDP) header. removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in o If there is an IPv4 Care-of Address option [RFC-5555] present in
the request and if the outer encapsulation header is IPv4-UDP, the request and if the outer encapsulation header is IPv4-UDP,
then the NAT presence detection procedure specified in Section then the NAT presence detection procedure specified in Section
4.1.3.3 MUST be used for detecting the NAT in the path. 4.1.3.3 MUST be used for detecting the NAT in the path.
o Upon accepting the request, the local mobility anchor MUST set up o Upon accepting the request, the local mobility anchor MUST set up
an IPv4 bi-directional tunnel to the mobile access gateway. The an IPv4 bi-directional tunnel to the mobile access gateway. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
The encapsulation mode MUST be determined from the below The encapsulation mode MUST be determined by applying the
considerations. following considerations:
* If the received Proxy Binding Update message was sent with IPv4 * If the received Proxy Binding Update message was sent with IPv4
encapsulated header, then the encapsulation mode for the bi- encapsulated header, then the encapsulation mode for the bi-
directional tunnel MUST be set to IPv4. Otherwise, the directional tunnel MUST be set to IPv4. Otherwise, the
following considerations apply. following considerations apply.
* If NAT is not detected on the path and if the (F) flag in the * If NAT is not detected on the path and if the (F) flag in the
received Proxy Binding Update message is set to the value of 1, received Proxy Binding Update message is set to the value of
but if the configuration flag, (1), but if the configuration flag,
AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
0, then the local mobility anchor MUST reject the request with (0), then the local mobility anchor MUST reject the request
the Status field value set to 129 (Administratively with the Status field value set to 129 (Administratively
prohibited). prohibited).
* If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update * If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update
message is set to value of 1, then the encapsulation mode MUST message is set to value of (1), then the encapsulation mode
be set to IPv4-or-IPv6-over-IPv4-UDP-TLV. MUST be set to IPv4-or-IPv6-over-IPv4-UDP-TLV.
* If NAT is detected on the path, or if the (F) flag in the * If NAT is detected on the path, or if the (F) flag in the
received Proxy Binding Update message is set to the value of 1, received Proxy Binding Update message is set to the value of
then the encapsulation mode MUST be set to IPv4-or-IPv6-over- (1), then the encapsulation mode MUST be set to IPv4-or-IPv6-
IPv4-UDP. Otherwise the encapsulation mode MUST be set to over-IPv4-UDP. Otherwise the encapsulation mode MUST be set to
IPv4-or-IPv6-over-IPv4. IPv4-or-IPv6-over-IPv4.
o The local mobility anchor MUST send the Proxy Binding o The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field value set to 0 Acknowledgement message with the Status field value set to (0)
(Proxy Binding Update Accepted). The message MUST be constructed (Proxy Binding Update Accepted). The message MUST be constructed
as specified in Section 4.1.3.2. as specified in Section 4.1.3.2.
4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 4.1.3.2. 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]. However, if the message as specified in Section 5.3.6 of [RFC-5213]. However, if
the received Proxy Binding Update message was encapsulated in an IPv4 the received Proxy Binding Update message was encapsulated in an IPv4
packet or as a payload in the UDP header of an IPv4 packet, the packet or as a payload in the UDP header of an IPv4 packet, the
following additional considerations MUST be applied. following additional considerations MUST be applied.
o The Proxy Binding Acknowledgement message MUST be encapsulated in o The Proxy Binding Acknowledgement message MUST be encapsulated in
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 an IPv4-UDP packet, then the
then the Proxy Binding Acknowledgement message MUST be Proxy Binding Acknowledgement message MUST be encapsulated in the
encapsulated in the UDP header of an IPv4 packet. 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
association that is based of IPv4 addresses, then the encapsulated association that is based on 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 [RFC-5555] 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 [RFC-5555] 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
received Proxy Binding Update message was not sent encapsulated in received Proxy Binding Update message was not sent encapsulated in
IPv4 UDP header, then the option MUST NOT be present. IPv4 UDP header, then the option MUST NOT be present.
Furthermore, in all other cases, the option MUST NOT be present. Furthermore, in all other cases, the option MUST NOT be present.
o The IPv4 DHCP Support Mode option MAY be present. If this option o The IPv4 DHCP Support Mode option MAY be present. If this option
is not present, the mobile access gateway will enable the default is not present, the mobile access gateway will enable the default
behavior and function as a DHCP Relay for the mobile node. behavior and function as a DHCP Relay for the mobile node.
o The format of the Proxy Binding Acknowledgement message o Figure 9 shows the format of the Proxy Binding Acknowledgement
encapsulated in an IPv4 packet and protected using IPv6 security message encapsulated in an IPv4 packet and protected using IPv6
association. The UDP header MUST be present only if the received security association. The UDP header MUST be present only if the
Proxy Binding Update message was sent with IPv4-UDP encapsulation received Proxy Binding Update message was sent encapsulated in an
header. IPv4-UDP packet.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/
/* IPv6 PBA Packet protected with ESP header */ /* IPv6 PBA Packet protected with ESP header */
Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated
in IPv4 header in IPv4 header
4.1.3.3. NAT Presence Detection 4.1.3.3. NAT Presence Detection
skipping to change at page 39, line 22 skipping to change at page 39, line 22
On receiving the Proxy Binding Update message encapsulated in an IPv4 On receiving the Proxy Binding Update message encapsulated in an IPv4
UDP packet, the local mobility anchor, if it detects a NAT on the UDP packet, the local mobility anchor, if it detects a NAT on the
path, will send the Proxy Binding Acknowledgment message with the NAT path, will send the Proxy Binding Acknowledgment message with the NAT
Detection Option. The presence of this option in the Proxy Binding Detection Option. The presence of this option in the Proxy Binding
Acknowledgment is an indication to the mobile access gateway about Acknowledgment is an indication to the mobile access gateway about
the presence of NAT in the path. On detecting any NAT in the path, the presence of NAT in the path. On detecting any NAT in the path,
both the local mobility anchor and the mobile access gateway will set both the local mobility anchor and the mobile access gateway will set
the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation.
The specific details around the NAT detection and the related logic The specific details around the NAT detection and the related logic
are described in DSMIPv6 specification [ID-DSMIP6]. are described in DSMIPv6 specification [RFC-5555].
However, if the value of the configuration variable, However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to a value of 0, the UseIPv4UDPEncapForSignalingMessages, is set to a value of (0), the
mobile access gateway will not use IPv4 UDP encapsulation for Proxy mobile access gateway will not use IPv4 UDP encapsulation for Proxy
Binding Update messages and hence the local mobility anchor will not Binding Update messages and hence the local mobility anchor will not
perform this NAT Presence Detection procedure on these messages that perform this NAT Presence Detection procedure on these messages that
are not sent in IPv4 UDP packet. are not sent in IPv4 UDP packet.
4.1.4. Routing Considerations 4.1.4. Routing Considerations
4.1.4.1. Forwarding Considerations 4.1.4.1. Forwarding Considerations
Forwarding Packets to the Mobile Node: Forwarding Packets to the Mobile Node:
skipping to change at page 41, line 19 skipping to change at page 41, line 19
in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access
gateway is in an IPv4-only access network, the following additional gateway is in an IPv4-only access network, the following additional
considerations MUST be applied. considerations MUST be applied.
o The Proxy Binding Update message MUST be encapsulated in an IPv4 o The Proxy Binding Update message MUST be encapsulated in an IPv4
packet. However, if the value of the configuration variable, packet. However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
Binding Update message MUST be encapsulated in an UDP header of an Binding Update message MUST be encapsulated in an UDP header of an
IPv4 packet. IPv4 packet.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [RFC-5555] MUST be present. The
IPv4 address in the option MUST be set to the mobile access IPv4 address in the option MUST be set to the mobile access
gateway's IPv4-Proxy-CoA. gateway's IPv4-Proxy-CoA.
o The packet MUST be constructed as specified in Section 4.2.3. o The packet MUST be constructed as specified in Section 4.2.2.1.
o Just as specified in [RFC-5213], when sending a Proxy Binding o Just as specified in [RFC-5213], when sending a Proxy Binding
message for extending the lifetime of a currently existing message for extending the lifetime of a currently existing
mobility session or for de-registering the mobility session, the mobility session or for de-registering the mobility session, the
Proxy Binding Update message MUST be constructed just as the Proxy Binding Update message MUST be constructed just as the
initial request. initial request.
Receiving Proxy Binding Acknowledgement Receiving Proxy Binding Acknowledgement
o If the received Proxy Binding Acknowledgement message is o If the received Proxy Binding Acknowledgement message is
skipping to change at page 42, line 5 skipping to change at page 42, line 5
o If the Status field indicates Success, the mobile access gateway o If the Status field indicates Success, the mobile access gateway
MUST setup a bi-directional tunnel to the local mobility anchor. MUST setup a bi-directional tunnel to the local mobility anchor.
o Upon accepting the request, the mobile access gateway MUST set up o Upon accepting the request, the mobile access gateway MUST set up
an IPv4 bi-directional tunnel to the local mobility anchor. The an IPv4 bi-directional tunnel to the local mobility anchor. The
tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA.
The encapsulation mode MUST be determined from the below The encapsulation mode MUST be determined from the below
considerations. considerations.
* The encapsulation mode for the bi-directional tunnel MUST be o The encapsulation mode for the bi-directional tunnel MUST be set
set to IPv4. However, if the value of the configuration to IPv4. However, if the value of the configuration variable,
variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, UseIPv4UDPEncapForSignalingMessages, is set to (1), then the
then the following considerations MUST be applied. following considerations MUST be applied.
* If there is a NAT Detection option [ID-DSMIP6] in the received * If there is a NAT Detection option [RFC-5555] in the received
Proxy Binding Acknowledgement message and if the value of the Proxy Binding Acknowledgement message and if the value of the
configuration flag, UseIPv4UDPEncapForSignalingMessages, is set configuration flag, UseIPv4UDPEncapForSignalingMessages, is set
to value of 1, then the encapsulation mode for the tunnel MUST to value of (1), then the encapsulation mode for the tunnel
be set to IPv4-UDP. Otherwise the encapsulation mode MUST be MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST
set to IPv4. be set to IPv4.
* If the (T) flag in the Proxy Binding Acknowledgement message is * If the (T) flag in the Proxy Binding Acknowledgement message is
set to value of 1, then the encapsulation mode MUST be set to set to value of (1), then the encapsulation mode MUST be set to
IPv4-UDP-TLV. IPv4-UDP-TLV.
4.2.2.1. Constructing the Proxy Binding Update Message 4.2.2.1. Constructing the Proxy Binding Update Message
o The source address in the IPv4 header MUST be set to IPv4-Proxy- o The source address in the IPv4 header MUST be set to IPv4-Proxy-
CoA of the mobile access gateway and the destination address MUST CoA of the mobile access gateway and the destination address MUST
be set to the local mobility anchor's IPv4-LMAA. be set to the local mobility anchor's IPv4-LMAA.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [RFC-5555] MUST be present. The
address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. address MUST be set to the mobile access gateway's IPv4-Proxy-CoA.
o If the configuration variable ForceIPv4UDPEncapsulationSupport is o If the configuration variable ForceIPv4UDPEncapsulationSupport is
set to value of 1, then the (F) flag in the Proxy Binding Update set to value of (1), then the (F) flag in the Proxy Binding Update
message MUST be set to value of 1. message MUST be set to value of (1).
o The Proxy Binding Update message MUST be protected using IPsec ESP o The Proxy Binding Update message MUST be protected using IPsec ESP
[RFC-4301], as specified in [RFC-5213]. The protection MUST be [RFC-4301], as specified in [RFC-5213]. The protection MUST be
applied on the IPv6 packet of the Proxy Binding Update message, applied on the IPv6 packet of the Proxy Binding Update message,
prior to the IPv4 encapsulation. prior to the IPv4 encapsulation.
o The format of the Proxy Binding Update message encapsulated in an o The format of the Proxy Binding Update message encapsulated in an
IPv4 or IPv4-UDP packet with no IPsec protection: IPv4 or IPv4-UDP packet with no IPsec protection:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
skipping to change at page 44, line 19 skipping to change at page 44, line 19
The local mobility anchor MUST allow the following variables to be The local mobility anchor 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
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 (0), indicating that the
that the local mobility anchor MUST NOT accept IPv4 UDP local mobility anchor MUST NOT accept IPv4 UDP encapsulation
encapsulation request when NAT is not detected in the path. 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 (1), the local mobility
mobility anchor MUST accept IPv4 UDP encapsulation request even anchor MUST accept IPv4 UDP encapsulation request even when NAT is
when NAT is not detected in the path. 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
protocol variables MUST survive server reboots and service restarts. protocol variables MUST survive server reboots and service restarts.
UseIPv4UDPEncapForSignalingMessages UseIPv4UDPEncapForSignalingMessages
This flag indicates whether or not the mobile access gateway This flag indicates whether or not the mobile access gateway
should use IPv4-UDP encapsulation mode for the signaling messages. should use IPv4-UDP encapsulation mode for the signaling messages.
The default value for this flag is set to value of 0, indicating The default value for this flag is set to (0), indicating that the
that the mobile access gateway MUST NOT use IPv4-UDP encapsulation mobile access gateway MUST NOT use IPv4-UDP encapsulation mode,
mode, but MUST use native IPv4 encapsulation mode for sending the but MUST use native IPv4 encapsulation mode for sending the Proxy
Proxy Mobile IPv6 signaling messages. Mobile IPv6 signaling messages.
When the value for this flag is set to value of 1, the mobile When the value for this flag is set to (1), the mobile access
access gateway MUST use IPv4-UDP encapsulation mode for sending gateway MUST use IPv4-UDP encapsulation mode for sending the Proxy
the Proxy Mobile IPv6 signaling messages. Mobile IPv6 signaling messages.
ForceIPv4UDPEncapsulationSupport ForceIPv4UDPEncapsulationSupport
This flag indicates whether or not the mobile access gateway This flag indicates whether or not the mobile access gateway
should request the mobile node's local mobility anchor for forcing should request the mobile node's local mobility anchor for forcing
IPv4 UDP encapsulation support for the mobile node's data traffic, IPv4 UDP encapsulation support for the mobile node's data traffic,
even when NAT is not detected in the path. even when NAT is not 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 (0), indicating that the
that the mobile access gateway MUST NOT request the mobile node's mobile access gateway MUST NOT request the mobile node's local
local mobility anchor for forcing IPv4 UDP encapsulation support mobility anchor for forcing IPv4 UDP encapsulation support even
even when NAT is not detected in path. when NAT is not detected in path.
When the value for this flag is set to value of 1, the mobile When the value for this flag is set to (1), the mobile access
access gateway MUST force the mobile node's local mobility anchor gateway MUST force the mobile node's local mobility anchor for
for IPv4 UDP encapsulation support. IPv4 UDP encapsulation support.
This flag is applicable only when the flag This flag is applicable only when the flag
UseIPv4UDPEncapForSignalingMessages is set to a value of 1. UseIPv4UDPEncapForSignalingMessages is set to a value of (1).
6. IANA Considerations 6. IANA Considerations
This document defines a new Mobility Header option, IPv4 Default This document defines two new Mobility Header options, IPv4 Default
Router Address option. This option is described in Section 3.3.1. Router Address option and IPv4 DHCP Support Mode option. These
The Type value for this option needs to be assigned from the same options are described in Section 3.3.1 and Section 3.3.2
number space as allocated for the other mobility options, as defined respectively. The Type value for these options needs to be assigned
in [RFC-3775]. from the same number space as allocated for the other mobility
options, as defined in [RFC-3775].
The IPv4 DHCP Support Mode Option, described in Section 3.3.2 of this
document, introduces a new number space, IPv4 DHCP Support Mode
Flags. This document reserves the value 0x1 for the (S) flag.
Approval of this flag values are to be made through IANA Expert
Review.
This document also defines new status values, used in Proxy Binding This document also defines new status values, used in Proxy Binding
Acknowledgement message, as described in Section 3.3.2. These values Acknowledgement message, as described in Section 3.3.3. These values
are to be assigned from the same number space as allocated for other are to be assigned from the same number space as allocated for other
Status codes [RFC-3775]. Each of these allocated values have to be Status codes [RFC-3775]. Each of these allocated values have to be
greater than 128. greater than 128.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network
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
7. Security Considerations 7. Security Considerations
All the security considerations from the base Proxy Mobile IPv6 [RFC- All the security considerations from the base Proxy Mobile IPv6 [RFC-
5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [ID-DSMIP6] 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555]
apply when using the extensions defined in this document. apply when using the extensions defined in this document.
Additionally, the following security considerations need to be Additionally, the following security considerations need to be
applied. applied.
This document defines news mobility options for supporting the IPv4 This document defines new mobility options for supporting the IPv4
Home Address assignment and IPv4 Transport Support features. These Home Address assignment and IPv4 Transport Support features. These
options are to be carried in Proxy Binding Update and Proxy Binding options are to be carried in Proxy Binding Update and Proxy Binding
Acknowledgement messages. The required security mechanisms specified Acknowledgement messages. The required security mechanisms specified
in the base Proxy Mobile IPv6 protocol for protecting these signaling in the base Proxy Mobile IPv6 protocol for protecting these signaling
messages are sufficient when carrying these mobility options. messages are sufficient when carrying these mobility options.
This specification describes the use of IPv4 transport for exchanging This specification describes the use of IPv4 transport for exchanging
the signaling messages between the local mobility anchor and the the signaling messages between the local mobility anchor and the
mobile access gateway. These signaling messages are fundamentally mobile access gateway. These signaling messages are fundamentally
IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4
skipping to change at page 48, line 43 skipping to change at page 48, line 43
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, Bernard Aboba, Charles Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles
Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen,
Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj,
Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu and Zu Qiang Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu and Zu Qiang
for their helpful review of this document. for their helpful review of this document.
Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem
Dodge and Adrian Farrel for their reviews of this document as part of
the IESG review process.
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.
skipping to change at page 49, line 20 skipping to change at page 49, line 25
[RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast
Addresses", RFC-4193, October 2005. Addresses", RFC-4193, October 2005.
[RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC-4291, February 2006. 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 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", Hosts and Routers (DSMIPv6)", RFC-5555, June 2009.
draft-ietf-mext-nemo-v4traversal-10.txt, April 2009.
[ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K.,
"GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-06.txt, February 2009.
10.2. Informative References 10.2. Informative References
[RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996. 1918, February 1996.
skipping to change at page 50, line 18 skipping to change at page 50, line 18
[RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network
Attachment in IPv4", RFC 4436, March 2006. Attachment in IPv4", RFC 4436, March 2006.
[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.
[ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K.,
"GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-09.txt, May 2009.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku 6-6-20 Akasaka, Minato-ku
Tokyo 107-0052 Tokyo 107-0052
Japan Japan
Phone: +81-3-5561-8276 Phone: +81-3-5561-8276
Fax: +81-3-5561-8292 Fax: +81-3-5561-8292
 End of changes. 124 change blocks. 
295 lines changed or deleted 353 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/