draft-ietf-netlmm-pmip6-ipv4-support-04.txt   draft-ietf-netlmm-pmip6-ipv4-support-05.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: January 15, 2009 Cisco Expires: March 27, 2009 Cisco
July 14, 2008 September 23, 2008
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-04.txt draft-ietf-netlmm-pmip6-ipv4-support-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on March 27, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) For extending IPv4 home address mobility support to the two-fold: 1) extending IPv4 home address mobility support to the
mobile node. 2) For allowing the mobility entities in the Proxy mobile node. 2) allowing the mobility entities in the Proxy Mobile
Mobile IPv6 domain to exchange signaling messages over an IPv4 IPv6 domain to exchange signaling messages over an IPv4 transport
transport network. network.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.1.3. Routing Considerations for the Local Mobility 3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 16 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 16
3.2.1. Extensions to Binding Update List Entry . . . . . . . 16 3.2.1. Extensions to Binding Update List Entry . . . . . . . 16
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 16 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 19 Gateway . . . . . . . . . . . . . . . . . . . . . . . 20
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 19 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 21
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 19 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 21
3.3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . 20 3.3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . 22
3.4. Supporting DHCP Based Address Configuration . . . . . . . 21 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 22
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2. DHCP Relay Agent co-located with the Mobile Access 3.4.2. DHCP Relay Agent co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 25 Gateway . . . . . . . . . . . . . . . . . . . . . . . 26
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 28 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 30
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 29 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 31
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 29 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 31
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 30 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 32
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 30 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 32
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 32 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 35
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 34 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 36
4.2.1. Extensions to Binding Update List Entry . . . . . . . 34 4.2.1. Extensions to Binding Update List Entry . . . . . . . 36
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 34 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 36
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 38 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 40
5.1. Local Mobility Anchor - Configuration Variables . . . . . 38 5.1. Local Mobility Anchor - Configuration Variables . . . . . 40
5.2. Mobile Access Gateway - Configuration Variables . . . . . 38 5.2. Mobile Access Gateway - Configuration Variables . . . . . 40
5.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 39 5.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . . 42 10.1. Normative References . . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . . 43 10.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a same network infrastructure. Thus, it is reasonable to assume that a
mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
IPv6-only or in dual-stack mode and additionally the network between IPv6-only or in dual-stack mode and additionally the network between
the mobile access gateway and a local mobility anchor may be an IPv4 the mobile access gateway and a local mobility anchor may be an IPv4
or an IPv6 network. It is also reasonable to expect the same or an IPv6 network. It is also reasonable to expect the same
skipping to change at page 5, line 40 skipping to change at page 5, line 40
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 for enabling IPv4 home
address support. address 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 further the mobile signaling messages over an IPv4 transport and furthermore the
access gateway may be using an IPv4 private address and with NAT mobile access gateway may be using an IPv4 private address and
[RFC-3022] translation devices on the path to the local mobility with NAT [RFC-3022] translation devices on the path to the local
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.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA1 -> | | <-- LMAA2 IPv4-LMAA1 -> | | <-- LMAA2
skipping to change at page 6, line 32 skipping to change at page 6, line 32
|MAG1|-----{MN2} |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
(IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2)
(IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3)
{MN1} {MN3} {MN1} {MN3}
Figure 1: IPv4 support for Proxy Mobile IPv6 Figure 1: IPv4 support for Proxy Mobile IPv6
1.1. Stated Assumptions 1.1. Stated Assumptions
Following are the configuration requirements from the mobility The following are the configuration requirements from the mobility
entities in the Proxy Mobile IPv6 domain for supporting the entities in the Proxy Mobile IPv6 domain for supporting the
extensions defined in this document. extensions defined in this document.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
IPv4 and IPv6 enabled. Irrespective of the type of transport IPv4 and IPv6 enabled. Irrespective of the type of transport
network (IPv4 or IPv6) separating these two entities, the mobility network (IPv4 or IPv6) separating these two entities, the mobility
signaling is always based on Proxy Mobile IPv6 [RFC-5213]. signaling is always based on Proxy Mobile IPv6 [RFC-5213].
o The mobile node can be operating in IPv4-only, IPv6-only or in o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. Based on what is enabled for a mobile node, it should dual mode. Based on what is enabled for a mobile node, it should
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
address(es) for its interface and further achieve mobility support address(es) for its interface and furthermore achieve mobility
for those addresses. support for those addresses.
o For enabling IPv4 home address mobility support to a mobile node, o For enabling IPv4 home address mobility support to a mobile node,
it is not required that the IPv6 home address mobility support it is not required that the IPv6 home address mobility support
needs to enabled. However, the respective protocol(s) support needs to enabled. However, the respective protocol(s) support
must be enabled on the access link between the mobile node and the must be enabled on the access link between the mobile node and the
mobile access gateway. mobile access gateway.
o The mobile node can obtain one or more IPv4 addresses for its o The mobile node can obtain an IPv4 address for its attached
attached interface. Based on the type of link, it may be able to interface. Based on the type of link, it may be able to acquire
acquire its IPv4 address configuration using DHCP [RFC-2131], IPCP its IPv4 address configuration using DHCP [RFC-2131], IPCP [RFC-
[RFC-1332], IKEv2 [RFC-4306], static configuration or through 1332], IKEv2 [RFC-4306], static configuration or through other
other standard IPv4 address configuration mechanisms. standard IPv4 address configuration mechanisms.
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. Its 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 more than one mobile node sharing different addresses There can be more than one mobile node sharing different addresses
from the same IPv4 subnet. from the same IPv4 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. for the mobile node's data traffic.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
skipping to change at page 8, line 43 skipping to change at page 8, line 43
The IPv4 address that is configured on the egress-interface of the The IPv4 address that is configured on the egress-interface of the
local mobility anchor. When using IPv4 transport, the mobile local mobility anchor. When using IPv4 transport, the mobile
access gateway sends the Proxy Binding Update messages to this access gateway sends the Proxy Binding Update messages to this
address and will be the transport-endpoint of the tunnel between address and will be the transport-endpoint of the tunnel between
the local mobility anchor and the mobile access gateway. the local mobility anchor and the mobile access gateway.
Mobile Node's IPv4 Home Address (IPv4-MN-HoA) Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
This is the IPv4 home address assigned to the mobile node's This is the IPv4 home address assigned to the mobile node's
attached interface. This IPv4 home address is topologically attached interface. This address is topologically anchored at the
anchored at the local mobility anchor. The mobile node configures local mobility anchor. The mobile node configures this address on
this address on its attached interface. There can be more than its attached interface. Further, if the mobile node connects to
one IPv4 home addresses assigned to the mobile node's attached the Proxy Mobile IPv6 domain through multiple interfaces and for
interface. Further, if the mobile node connects to the Proxy simultaneous access, each of the attached interface will be
Mobile IPv6 domain through multiple interfaces and for assigned a unique IPv4 home address. All the IPv6 home network
simultaneous access, each of the attached interfaces will be prefixes and the IPv4 home address assigned to a given interface
assigned a unique set of IPv4 home addresses and all the IPv4 of a mobile node will be managed under one mobility session.
addresses that are assigned to a given interface of a mobile node
will be managed under one mobility session.
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-over-IPv6 IPv4-over-IPv6
IPv4 packet carried as a payload of an IPv6 packet IPv4 packet carried as a payload of an IPv6 packet
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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
configuration for its attached interface and be able to retain that configuration for its attached interface and be able to retain that
address configuration even after changing its point of attachment in address configuration even after changing its point of attachment in
that Proxy Mobile IPv6 domain. This section describes the protocol that Proxy Mobile IPv6 domain. This section describes the protocol
operation and the required extensions to Proxy Mobile IPv6 protocol operation and the required extensions to Proxy Mobile IPv6 protocol
for supporting IPv4 home address mobility support. for extending IPv4 home address mobility support.
When an IPv4-enabled or a dual-stack enabled mobile node attaches to When an IPv4-enabled or a dual-stack enabled mobile node attaches to
the Proxy Mobile IPv6 domain, the mobile access gateway on the access the Proxy Mobile IPv6 domain, the mobile access gateway on the access
network where the mobile node is attached will identify the mobile link where the mobile node is attached will identify the mobile node
node and will initiate the Proxy Mobile IPv6 signaling with the and will initiate the Proxy Mobile IPv6 signaling with the mobile
mobile node's local mobility anchor. The mobile access gateway will node's local mobility anchor. The mobile access gateway will follow
follow the signaling considerations specified in Section 3.2 for the signaling considerations specified in Section 3.2 for requesting
requesting IPv4 home address support. Upon the completion of the IPv4 home address mobility support. Upon the completion of the
signaling the local mobility anchor and the mobile access gateway signaling, the local mobility anchor and the mobile access gateway
will have the required states for allowing the mobile node to use its will have the required routing states for allowing the mobile node to
IPv4 home address(es) from the current point of attachment. use its IPv4 home address from its current point of attachment.
The mobile node on the access link using any of the standard IPv4 The mobile node on the access link using any of the standard IPv4
address configuration mechanisms supported on that access link, such address configuration mechanisms supported on that access link, such
as IPCP [RFC-1332], IKEv2 [RFC-4306] or using DHCP [RFC-2131], will as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able
be able to obtain one or more IPv4 home addresses (IPv4-MN-HoA) for to obtain an IPv4 home address (IPv4-MN-HoA) for its attached
the attached interface. Although the address configuration protocol interface. Although the address configuration mechanisms for
mechanisms for delivering the address configuration to the mobile delivering the address configuration to the mobile node is
node is independent of the Proxy Mobile IPv6 protocol operation, independent of the Proxy Mobile IPv6 protocol operation, however
however there needs to be some interactions between these two there needs to be some interactions between these two protocol flows.
protocol flows. Section 3.4 identifies these interactions for Section 3.4 identifies these interactions for supporting DHCP based
supporting DHCP based address configuration. address configuration.
The support for IPv4 home address mobility is not dependent on the The support for IPv4 home address mobility is not dependent on the
IPv6 home address support. The mobile node is not required to have IPv6 home address mobility support. It is not required that the IPv6
an IPv6 home address for obtaining IPv4 home address mobility. A home address mobility support needs to be enabled for providing IPv4
mobile node will be able to obtain just IPv4 address configuration or home address mobility support. A mobile node will be able to obtain
both IPv4 and IPv6 address configuration on its attached interface. IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its
The mobile node's policy profile will determine if the mobile node is attached interface. The mobile node's policy profile will determine
entitled for both the protocols or a single protocol and based on if the mobile node is entitled for both the protocol versions or a
what is enabled, only those protocols will be enabled on the access single protocol version. Based on the policy, only those protocols
link. Further, if the mobile node after obtaining the address will be enabled on the access link. Furthermore, if the mobile node
configuration on its interface performs an handoff, either by after obtaining the address configuration on its interface performs
changing its point of attachment over the same interface or to a an handoff, either by changing its point of attachment over the same
different interface, the network will ensure the mobile node will be interface or to a different interface, the network will ensure the
able to use the same IPv4 address configuration after the handoff. mobile node will be able to use the same IPv4 address configuration
after the handoff.
Additionally, If the mobile node connects to the Proxy Mobile IPv6 Additionally, If the mobile node connects to the Proxy Mobile IPv6
domain, through multiple interfaces and simultaneously through domain, through multiple interfaces and simultaneously through
different access networks, each of the connected interfaces will different access networks, each of the connected interfaces will
obtain one or more IPv4 home addresses from different subnets. In obtain an IPv4 home address from different subnets. In such
such scenario, there will be multiple Binding Cache entries for the scenario, there will be multiple Binding Cache entries for the mobile
mobile node on the local mobility anchor. All the address (IPv4/ node on the local mobility anchor. All the address (IPv4/IPv6)
IPv6) assigned to a given interface will be managed as part of one assigned to a given interface will be managed as part of one mobility
mobility session, as specified in Section 5.4 of [RFC-5213]. session, as specified in Section 5.4 of [RFC-5213].
3.1. Local Mobility Anchor Considerations 3.1. Local Mobility Anchor Considerations
3.1.1. Extensions to Binding Cache Entry 3.1.1. Extensions to Binding Cache Entry
For supporting 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 be structure maintained by the local mobility anchor needs to be
extended with the following additional parameters. extended with the following additional parameters.
o List of IPv4 home addresses assigned to the mobile node's o The IPv4 home address assigned to the mobile node's interface and
interface registered by the mobile access gateway. Each of these registered by the mobile access gateway. The IPv4 home address
IPv4 home address entries also include the corresponding prefix entry also includes the corresponding subnet mask.
length.
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 one or more However, if the received Proxy Binding Update message has an IPv4
IPv4 Home Address options, the following additional considerations Home Address option [ID-DSMIP6], the following considerations MUST be
MUST be applied. applied additionally.
o If there is an IPv4 Home Address option present in the received o If there is an IPv4 Home Address option [ID-DSMIP6] present in the
Proxy Binding Update message, but if there is no Home Network received Proxy Binding Update message, but if there is no Home
Prefix option present in the request, the local mobility anchor Network Prefix option [RFC-5213] present in the request, the local
MUST NOT reject the request as specified in Section 5.3.1 of [RFC- mobility anchor MUST NOT reject the request as specified in
5213]. At least one instance of any of these two options MUST be Section 5.3.1 of [RFC-5213]. At least one instance of any of
present. However, if not a single instance of any of these these two options MUST be present. If there is not a single
options are not present, the local mobility anchor MUST reject the instance of any of these two options present in the request, the
request and send a Proxy Binding Acknowledgement message with local mobility anchor MUST reject the request and send a Proxy
Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing Binding Acknowledgement message with Status field set to
mobile node's home network prefix option). MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213].
o For performing the Binding Cache entry existence test, the o For associating the received Proxy Binding Update message to an
following considerations MUST be applied: existing mobility session, the local mobility anchor MUST perform
the Binding Cache entry existence test by applying the following
considerations.
* If there is at least one Home Network Prefix option with a * If there is at least one instance of the Home Network Prefix
NON_ZERO prefix value, or, if there is no IPv4 Home Address option [RFC-5213] with a NON_ZERO prefix value, or, if there is
option with a NON_ZERO IPv4 address, considerations from an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address
Section 5.4 of [RFC-5213] MUST be applied. in the option set to ALL_ZERO, considerations from Section
5.4.1 of [RFC-5213] MUST be applied.
* If there is at least one IPv4 Home Address option present in * If there is an IPv4 Home Address option [ID-DSMIP6] present in
the request with a NON_ZERO IPv4 address value, considerations the request with the IPv4 address value in the option set to a
from Section 3.2.2.7 MUST be applied. NON_ZERO value, considerations from Section 3.1.2.7 MUST be
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.2.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
[RFC-5213] present in the request, considerations from Section
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 request or a de-registration request request is re-registration or a de-registration request and the
and the respective considerations from below MUST be applied. respective considerations from the below sections MUST be applied.
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-
registration request and with the request to extend IPv4 home
address mobility support to the existing IPv6-only mobility
session, considerations from Section 3.1.2.2 MUST be applied with
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 at least one IPv4 Home Address option present in the o If there is an IPv4 Home Address option [ID-DSMIP6] present in the
Proxy Binding Update message with the IPv4 address value set to Proxy Binding Update message with the IPv4 address value in the
ALL_ZERO, the local mobility anchor MUST allocate one or more IPv4 option set to ALL_ZERO, the local mobility anchor MUST allocate an
home addresses to the mobile node and associate them to the new IPv4 home address to the mobile node and associate it with the new
mobility session created for that mobile node. The decision on mobility session created for that mobile node.
how many IPv4 home addresses to be allocated can be based on a
domain-wide policy or a policy specific to that mobile node.
o If there are one or more IPv4 Home Address options present in the o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4
received Proxy Binding Update message (with the IPv4 address field address in the option set to a NON_ZERO value, the local mobility
in the option set to a NON_ZERO value), the local mobility anchor anchor before accepting the request MUST ensure the address is
before accepting the request, MUST ensure the address is owned by owned by the local mobility anchor and furthermore the mobile node
the local mobility anchor and further the mobile node is is authorized to use that address. If the mobile node is not
authorized to use that address. If the mobile node is not authorized for that specific address, the local mobility anchor
authorized for a specific address, the local mobility anchor MUST 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 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 Home Address). It MUST also set the for the requesting IPv4 address). It MUST also include the IPv4
status field value in the corresponding IPv4 Address Address Acknowledgement option [ID-DSMIP6] in the reply with the
Acknowledgement option [ID-DSMIP6] 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 set the status field value (Insufficient resources). It MUST also include the IPv4 Address
in the corresponding IPv4 Address Acknowledgement option [ID- Acknowledgement option [ID-DSMIP6] in the reply with the status
DSMIP6], to 128 (Failure, reason unspecified). field value in the option set to 128 (Failure, reason
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, request also contains one or more Home Network Prefix options [ID-
there should still be only one Binding Cache entry that should be DSMIP6], there should still be only one Binding Cache entry that
created for this mobility session. The created Binding Cache should be created for this mobility session. The created Binding
entry MUST be used for managing both IPv4 and IPv6 home address Cache entry MUST be used for managing both IPv4 and IPv6 home
bindings. The fields in the Binding Cache entry MUST be updated address bindings. The fields in the Binding Cache entry MUST be
with the accepted values for that binding. 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 as to the mobile access gateway and with the encapsulation mode set
negotiated. When using IPv6 transport, the encapsulation mode is to the negotiated mode for carrying the IPv4 payload traffic.
IPv4 over IPv6. When using IPv6 transport, the encapsulation mode is IPv4-over-
IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When
using IPv4 transport, the encapsulation mode is as specified in
Section 4.0.
o The local mobility anchor MUST create IPv4 host route(s) for o The local mobility anchor MUST create an IPv4 host route for
tunneling the packets received for any of the mobile node's home tunneling the packets received for the mobile node's home address
address(es) associated with this mobility session. associated with this mobility session.
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 set to 0 (Proxy Acknowledgement message with the Status field set to 0 (Proxy
Binding Update Accepted). The message MUST be constructed as Binding Update Accepted). The message MUST be constructed as
specified in Section 3.1.2.6. specified in Section 3.1.2.6.
3.1.2.3. Binding Lifetime Extension (No handoff) 3.1.2.3. Binding Lifetime Extension (No handoff)
All the consideration from Section 5.3.2 of [RFC-5213] MUST be All the considerations from Section 5.3.3 of [RFC-5213] MUST be
applied. applied.
3.1.2.4. Binding Lifetime Extension (After handoff) 3.1.2.4. Binding Lifetime Extension (After handoff)
o The local mobility anchor MUST remove the previously created host o The local mobility anchor MUST remove the previously created IPv4
route(s), towards the mobile access gateway where the mobile node host route and the dynamically created bi-directional tunnel for
was anchored prior to the handoff. carrying the IPv4 payload traffic (if there are no other mobile
nodes for which the tunnel is being used). This will remove the
routing state towards the mobile access gateway where the mobile
node was anchored prior to the handoff.
o The local mobility anchor MUST create a host route(s) for o The local mobility anchor MUST create a bi-directional tunnel to
tunneling the packets received for any of the mobile node's home the mobile access gateway that sent the request (if there is no
address(es) associated with this mobility session. existing bi-directional tunnel) and with the encapsulation mode
set to the negotiated mode for carrying the IPv4 payload traffic.
An IPv4 host route for tunneling the packets received for the
mobile node's IPv4 home address MUST also be added.
o The required forwarding state identified in Section 5.3.6 of [RFC- o The required forwarding state identified in Section 5.3.6 of [RFC-
5213] is for IPv6 payload traffic. Those considerations apply for 5213] is for IPv6 payload traffic. Those considerations apply for
IPv4 payload traffic as well. However, if IPv4 transport is in IPv4 payload traffic as well. However, if IPv4 transport is in
use, considerations from Section 4.0 MUST be applied. use, considerations from Section 4.0 MUST be applied.
3.1.2.5. Binding De-Registration 3.1.2.5. Binding De-Registration
All the consideration from Section 5.3.5 of [RFC-5213] MUST be All the considerations from Section 5.3.5 of [RFC-5213] MUST be
applied. Additionally, for removing the routing state as part of the applied. Additionally, for removing the IPv4 state as part of the
Binding Cache entry deletion, any IPv4 host route(s) added for this Binding Cache entry deletion, the IPv4 host route and the dynamically
mobility session MUST be removed. created bi-directional tunnel for carrying the IPv4 payload traffic
(if there are no other mobile nodes for which the tunnel is being
used) MUST be removed. However, if the request is for a selective
de-registration (IPv4-only or IPv6-only addresses), the Binding Cache
entry MUST not be deleted, only the respective states with respect
those addresses MUST be deleted.
3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC-5213]. the message as specified in Section 5.3.6 of [RFC-5213].
Additionally, the following considerations MUST be applied. Additionally, the following considerations MUST be applied.
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option in the include at least one instance of Home Network Prefix option [RFC-
Proxy Binding Acknowledgement message that it sends to the mobile 5213] in the Proxy Binding Acknowledgement message that it sends
access gateway. However, if the received Proxy Binding Update to the mobile access gateway. However, if the received Proxy
message has only the IPv4 Home Address option and did not contain Binding Update message has only the IPv4 Home Address option [ID-
the Home Network Prefix option(s), then the local mobility anchor DSMIP6] and did not contain the Home Network Prefix option(s),
MUST NOT include the Home Network Prefix option in the reply. then the local mobility anchor MUST NOT include any Home Network
Prefix option(s) in the reply.
o The IPv4 Address Acknowledgement option(s) MUST be present in the o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be
Proxy Binding Acknowledgement message. present 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 there
MUST be an IPv4 Address Acknowledgement option for each of the MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6]
IPv4 Home Address options present in the request and with the corresponding to the IPv4 Home Address option [ID-DSMIP6]
address value and the prefix length in the option set to the present in the request and with the IPv4 address value and the
values present in the corresponding request option. The prefix length fields in the option set to the corresponding
status field value in the option must be set to the specific values in the request. The status field value in the option
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 each of the assigned IPv4 home Acknowledgement option for carrying the IPv4 home address
addresses assigned for that mobility session and with the assigned for that mobility session and with the value in the
value in the option set to the allocated address value. The option set to the allocated IPv4 address. The prefix length
prefix length in the option MUST be set to the prefix length in the option MUST be set to the prefix length of the
of the allocated address. The status field value in the allocated address. The status field value in the option must
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] is for using the Home Network Prefix as the key 5.4.1.1 of [RFC-5213] requires the Home Network Prefix [RFC-5213] as
parameter for identifying the Binding Cache entry. When using an the key parameter for identifying the Binding Cache entry. When
IPv4 address with a NON_ZERO value, the exact same considerations using an IPv4 address with a NON_ZERO value, the exact same
specified in Section 5.4.1.1 of [RFC-5213] MUST be applied, with the considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be
exception of using an IPv4 home address in place of an IPv6 home applied, with the exception of using an IPv4 home address in place of
network prefix. an IPv6 home network prefix.
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 any of the mobile be able to receive packets that are sent to the mobile node's IPv4
node's IPv4 addresses. In order for it to receive those packets, home address. In order for it to receive those packets, it MUST
it MUST advertise a connected route in to the Routing advertise a connected route in to the Routing Infrastructure for
Infrastructure for the mobile node's IPv4 home address or for its the mobile node's IPv4 home address or for its home subnet. This
home subnet. This essentially enables IPv4 routers in that essentially enables IPv4 routers in that network to detect the
network to detect the local mobility anchor as the last-hop router local mobility anchor as the last-hop router for that subnet.
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 a 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:
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper layer protocols /* Packet Content*/
skipping to change at page 16, line 15 skipping to change at page 16, line 41
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header MUST be routed to the destination specified in the inner
IPv4 packet header. These routed packets will have the source IPv4 packet header. These routed packets will have the source
address field set to the mobile node's IPv4 home address. address field set to the mobile node's IPv4 home address.
3.2. Mobile Access Gateway Considerations 3.2. Mobile Access Gateway Considerations
3.2.1. Extensions to Binding Update List Entry 3.2.1. Extensions to Binding Update List Entry
For supporting 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 List of IPv4 home addresses assigned to the mobile node's attached o The IPv4 home address assigned to the mobile node's attached
interface. These IPv4 home addresses 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 through the dynamically allocated by the local mobility anchor. The IPv4 home
received Proxy Binding Acknowledgement message. Each of these address entry also includes the corresponding subnet mask.
IPv4 home address entries 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
For supporting this feature the mobile node's policy profile, To support the IPv4 Home Address Mobility Support feature the mobile
specified in Section 6.2 of [RFC-5213] MUST be extended with the node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be
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:
o This field indicates the scope of IP address mobility support that o This field identifies all the IP protocol versions for which the
needs to be extended for the mobile node. If the mobile access home address mobility support needs to be extended to the mobile
gateway should enable support for IPv4, IPv6 or IPv4/IPv6 home node. The supported modes are IPv4-only, IPv6-only and dual IPv4/
address mobility support. IPv6.
Extensions to the optional section of the policy profile: Extensions to the optional section of the policy profile:
o The IPv4 home addresses assigned to the mobile node's attached o The IPv4 home address assigned to the mobile node's attached
interface. These addresses have to be maintained on a per- interface. The specific details on how the network maintains the
interface basis. The specific details on how the network association between the address and the attached interface is
maintains the association between the addresses and the interfaces outside the scope of this document. This address field also
is outside the scope of this document. These address entries also includes the corresponding subnet mask.
include the corresponding prefix length.
3.2.3. Signaling Considerations 3.2.3. Signaling Considerations
3.2.3.1. Mobile Node Attachment and Initial Binding Registration 3.2.3.1. Mobile Node Attachment and Initial Binding Registration
After detecting a new mobile node on its access link, the mobile After detecting a new mobile node on its access link, the mobile
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 specifies if IPv4-only, IPv6-only or mobile node's policy profile identifies the supported modes (IPv4-
IPv4/IPv6 home address mobility service needs to be enabled for that only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the
mobile node. Based on those policy considerations, if it is mobile service needs to be enabled. Based on those policy
determined that IPv4 home address mobility support is required to be considerations and from other triggers such as from the network, if
enabled for the mobile node, the considerations from section 6.9.1.1 it is determined that IPv4 home address mobility support needs to be
of [RFC-5213] MUST be applied with the following exceptions. enabled for the mobile node, considerations from section 6.9.1.1 of
[RFC-5213] MUST be applied with the following exceptions.
o The IPv4 Home Address option(s) MUST be present in the Proxy o The IPv4 Home Address option [ID-DSMIP6] MUST be present in the
Binding Update request. 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(es) either from its policy profile, or from other means address either from its policy profile, or from other means,
the mobile access gateway MAY choose to request the local the mobile access gateway MAY ask the local mobility anchor to
mobility anchor to allocate the requested addresses by allocate that specific address by including exactly one
including an IPv4 Home Address option for each of those instance of the IPv4 Home Address option [ID-DSMIP6] with the
addresses. The IPv4 address and the prefix length fields in IPv4 home address and the prefix length fields in the option
the option MUST be set to that specific address and its prefix set to that specific address and its prefix length.
length. 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 choose to request the local * The mobile access gateway MAY also ask the local mobility
mobility anchor for dynamic 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 address value, prefix length fields and (P) flag with the IPv4 home address and the prefix length fields in the
in the option set to a ALL_ZERO value. This essentially serves option set to ALL_ZERO value. Furthermore, the (P) flag in the
as a request to the local mobility anchor for the IPv4 home option MUST be set to 0. This essentially serves as a request
address allocation. to the local mobility anchor for the IPv4 home address
allocation.
o The Proxy Binding Update message MUST be constructed as specified o The Proxy Binding Update message MUST be constructed as specified
in Section 6.9.1.5. However, the Home Network Prefix option(s) in Section 6.9.1.5 of [RFC-5213]. However, the Home Network
MUST be present in the Proxy Binding Update only if IPv6 home Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding
address mobility support also needs to be enabled for the mobile Update only if IPv6 home address mobility support also needs to be
node. Otherwise, the Home Network Prefix option(s) MUST NOT be enabled for the mobile node. Otherwise, the Home Network Prefix
present. option(s) MUST NOT be present.
o When using IPv4 transport for carrying the signaling messages, the o When using IPv4 transport for carrying the signaling messages, the
related considerations from section 4.0 MUST be applied. related considerations from section 4.0 MUST be applied
additionally.
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 Status field value set to
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS_SUPPORT (The mobile node is NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS_SUPPORT (The mobile node is
not authorized for IPv4 home address support), the mobile access not authorized for IPv4 home address support), the mobile access
gateway SHOULD NOT send a Proxy Binding Update message including gateway SHOULD NOT send a Proxy Binding Update message including
the IPv4 Home Address option(s) till an administrative action is the IPv4 Home Address option [ID-DSMIP6] till an administrative
taken. 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_REQ_IPV4_HOME_ADDRESS Status field value set to NOT_AUTHORIZED_FOR_REQ_IPV4_HOME_ADDRESS
(The mobile node is not authorized for the requesting IPv4 home (The 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 if do the assignment of address by including exactly one instance if
IPv4 Home Address option with the address value set to ALL_ZERO. IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
and the prefix length fields in the option set to ALL_ZERO value.
o If there is no IPv4 Address Acknowledgement option present in the o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6]
received Proxy Binding Acknowledgement message, the mobile access present in the received Proxy Binding Acknowledgement message, the
gateway MUST NOT enable IPv4 support for the mobile node and the mobile access gateway MUST NOT enable IPv4 support for the mobile
rest of the considerations from this section can be skipped. node and the rest of the considerations from this section can be
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 set Status field value in the IPv4 Address Acknowledgement Option [ID-
to a value that indicates that the request was rejected by the DSMIP6] set to a value that indicates that the request was
local mobility anchor, the mobile access gateway MUST NOT enable rejected by the local mobility anchor, the mobile access gateway
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(es). IPv4 home address and other accepted registration values.
o The bi-directional established with the local mobility anchor with o If the received Proxy Binding Acknowledgement message has the
IPv4 or IPv6 transport and using any of the supported Status field value set to 0 (Proxy Binding Update accepted) and
encapsulation mode, as per [RFC-5213] or as per this specification has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a
when using IPv4 transport, MUST be enabled to carry IPv4 traffic. value that indicates that the request was accepted by the local
mobility anchor, the mobile access gateway MUST establish a bi-
directional tunnel to the local mobility anchor (if there is no
existing bi-directional tunnel to that local mobility anchor) and
with the encapsulation mode set to IPv4-over-IPv6 (IPv4 packet
carried as a payload of an IPv6 packet). Considerations from
Section 5.6.1 of [RFC-5213] MUST be applied for managing the
dynamically created bi-directional tunnel. However, when using
IPv4 transport, the encapsulation mode MUST be set to the
negotiated encapsulation mode, as specified in Section 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 through the bi- IPv4 packets received from the mobile node (using its IPv4 home
directional tunnel set up for that mobile node. address) through the bi-directional tunnel set up for that mobile
node.
o If there is an IPv4 Default-Router Address option present in the
received Proxy Binding Acknowledgement message, the mobile access
gateway MAY configure this address on its interface and respond to
any ARP requests sent by the mobile node for resolving the
hardware address of the default-router.
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. However, respective considerations from [RFC-5213] MUST be applied.
the following additional considerations MUST be applied. Furthermore, the following additional considerations MUST also be
applied.
o There MUST be an IPv4 Home Address option for each of the assigned o If there is an IPv4 home address assigned to the mobility session,
IPv4 home address(es) for that mobility session. The IPv4 address then there MUST be exactly one instance of the IPv4 Home Address
and the prefix length fields in the option MUST be set to that option [ID-DSMIP6] present in the Proxy Binding Update message.
specific address and its prefix length. The (P) flag in the The IPv4 home address and the prefix length fields in the option
option MUST be set to 0. MUST be set to that specific address and its corresponding subnet-
mask length. The (P) flag in the option MUST be set to 0.
o The Home Network Prefix option(s) MUST NOT be present if the same o If there was no IPv4 home address requested in the initial Proxy
option(s) was not present in the initial Proxy Binding Update Binding Update message, but if it is determined that the IPv4 home
message. Otherwise considerations from [RFC-5213] with respect to address MUST be requested subsequently, then there MUST be exactly
this option MUST be applied. one instance of the IPv4 Home Address option [ID-DSMIP6] present
in the Proxy Binding Update message. The IPv4 home address in the
option MUST be set to either ALL_ZERO or to a specific address
that is being requested.
o For performing selective de-registration of the IPv4-only home
address, but still retaining the mobility session with all the
IPv6 home network prefixes, the Proxy Binding Update message with
the lifetime value of 0 MUST NOT include any IPv6 Home Network
Prefix options(s) [RFC-5213]. It MUST include exactly one
instance of the IPv4 Home Address option [ID-DSMIP6] with the IPv4
home address and the prefix length fields in the option set to the
IPv4 home address that is being deregistered.
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
Update message. Otherwise considerations from [RFC-5213] with
respect to this option MUST be applied.
3.2.4. Routing Considerations for the Mobile Access Gateway 3.2.4. Routing Considerations for the Mobile Access Gateway
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST remove the outer header before forwarding the packet gateway MUST remove the outer header before forwarding the packet
to the mobile node. to the mobile node.
o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect the local routing and on the use of with respect the local routing and on the use of
EnableMAGLocalRouting flag. EnableMAGLocalRouting flag.
o On receiving a packet from a mobile node connected to its access o On receiving a packet from a mobile node connected to its access
link, the packet MUST be forwarded to the local mobility anchor link, the packet MUST be forwarded to the local mobility anchor
through the bi-directional tunnel established with the local through the bi-directional tunnel established with the local
mobility anchor. The encapsulation considerations specified in mobility anchor. The encapsulation considerations specified in
section 3.1.3 MUST be applied. section 3.1.3 MUST be applied.
3.3. Mobility Options and Status Codes 3.3. Mobility Options and Status Codes
For supporting 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 sent by the local it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
mobility anchor to the mobile access gateway. This option can be local mobility anchor to the mobile access gateway. This option can
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 8-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.
Figure 3: IPv4 Default-Router Address Option
3.3.2. Status Codes 3.3.2. Status Codes
This document defines the following new Status values for use in the This document defines the following new Status values for use in the
Proxy Binding Acknowledgement message. These values are to be Proxy Binding Acknowledgement message [RFC-5213]. These values are
allocated from the same numbering space, as defined in Section 6.1.8 to be allocated from the same numbering space, as defined in Section
of [RFC-3775]. 6.1.8 of [RFC-3775].
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address Mobile node not authorized for the requesting IPv4 home address
3.4. Supporting DHCP Based Address Configuration 3.4. Supporting DHCP-Based Address Configuration
This section explains how DHCP based address configuration support This section explains how DHCP-based address configuration support
can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It
explains the protocol operation, supported DHCP server deployment explains the protocol operation, supported DHCP server deployment
configurations and the protocol interactions between DHCP agents and configurations and the protocol interactions between DHCP agents and
mobility entities in each of the supported configurations. mobility entities in each of the supported configurations.
This specification supports the following two DHCP deployment This specification supports the following two DHCP deployment
configurations. configurations.
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 either the DHCP messages with the mobile node. This address can be
the IPv4 Proxy Care-of Address or the mobile node's default-router either the IPv4 Proxy Care-of Address or the mobile node's
address provided by the local mobility anchor. Optionally, all default-router address provided by the local mobility anchor.
the DHCP servers co-located with the mobile access gateways in the
Proxy Mobile IPv6 domain can be configured with a fixed IPv4 Optionally, all the DHCP servers co-located with the mobile access
address. This can be a virtual address used only for the DHCP gateways in the Proxy Mobile IPv6 domain can be configured with a
fixed IPv4 address. This fixed address can be potentially an IPv4
link-local address [RFC-3927] that can be used for the DHCP
protocol communication on any of the access links. This address protocol communication on any of the access links. This address
will be the server identifier in the DHCP messages. will be used as the server identifier in the DHCP messages.
o The DHCP server identifies the a DHCP client either from the o The DHCP server identifies the DHCP client either from the client
client identifier or the client hardware address (chaddr). A identifier or the client hardware address (chaddr) [RFC-2131]. A
mobile node in a Proxy Mobile IPv6 domain may present any of these mobile node in a Proxy Mobile IPv6 domain may present any of these
identifiers to the DHCP server as long as the identifier remains identifiers to the DHCP server as long as the identifier remains
the same through out the mobile node's attachment in that Proxy the same through out the mobile node's attachment in that Proxy
Mobile IPv6 domain. If the client hardware address is used as the Mobile IPv6 domain. If the client hardware address is used as the
identifier and if the mobile node performs an handoff between two identifier and if the mobile node performs an handoff between two
interfaces, this hardware identifier will change and the DHCP interfaces, this hardware identifier will change and the DHCP
server will not be able to identify the mobile node. Thus, it is server will not be able to identify the mobile node. Thus, it is
recommended that the DHCP client in the mobile node is configured recommended that the DHCP client in a multihomed mobile node is
to use a stable client identifier that does not change during the configured to use a stable client identifier that does not change
active life of that DHCP session. during the active life of its DHCP session.
o All the DHCP servers co-located with the mobile access gateways in o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain SHOULD be configured with the same set a Proxy Mobile IPv6 domain can be configured with the same set of
of DHCP option values (Ex: DNS Server, SIP Server ..etc.). DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure
the mobile node receives the same configuration values on any of
the access links in that Proxy Mobile IPv6 domain.
3.4.1. DHCP Server co-located with the Mobile Access Gateway 3.4.1. DHCP Server co-located with the Mobile Access Gateway
Figure 4 shows the operational sequence of the home address This section explains the operational sequence of home address
assignment when a DHCP server is co-located with the mobile access assignment operation when the DHCP server is co-located with the
gateways. mobile access gateway.
MN MAG(DHCP-S) LMA MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVERY |------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update * | |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) | |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA)
| |========| 4. Tunnel/Route Setup* | |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA) |<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK |<------| | 7. DHCPACK
| | | | | |
* DHCP discovery (no.1) and PBU (no.2) are operated in parallel. * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling
* Tunnel/Route setup(no.4) and DHCPOFFER/REQUEST/ACK(no.5-7) * (Step-2 to Step-4) may happen in parallel and in no specific order
are processed in parallel. * Tunnel/Route setup(Step-4) and the subsequent steps will happen in
* in the specified order.
Figure 4: Overview of DHCP Server located at Mobile Access Gateway Figure 4: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o If the mobile node attached to the access link sends a o When a mobile node attached to an access link sends a DHCPDISCOVER
DHCPDISCOVERY message, the DHCP server co-located with the mobile message [RFC-2131], the DHCP server co-located with the mobile
access gateway will trigger the mobile access gateway to complete access gateway will trigger the mobile access gateway to complete
the Proxy Mobile IPv6 signaling. This is the required interaction the Proxy Mobile IPv6 signaling. This is the required interaction
between these two protocols. If the mobile access gateway is between these two protocols. If the mobile access gateway is
unable to complete the Proxy Mobile IPv6 signaling or if the local unable to complete the Proxy Mobile IPv6 signaling, or, if the
mobility anchor does not assign an IPv4 address for the mobile local mobility anchor does not assign an IPv4 address for the
node, the mobile access gateway MUST tear down the point-to-point mobile node, the mobile access gateway MUST NOT enable IPv4
link shared with the mobile node. support for the mobile node on that access link.
o After a successful completion of the Proxy Mobile IPv6 signaling o After a successful completion of the Proxy Mobile IPv6 signaling
and acquiring the mobile node's IPv4 home address assigned by the and acquiring the mobile node's IPv4 home address assigned by 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 DHCP offer message to the mobile node. The gateway will send a DHCPOFFER message [RFC-2131] to the mobile
offered address will the mobile node's IPv4 home address, assigned node. The offered address will the mobile node's IPv4 home
by the local mobility anchor. The 'siaddr' field of the DHCPOFFER address, assigned by the local mobility anchor. The server
message will be set to the mobile node's default-router address or address, 'siaddr' field of the DHCPOFFER message, will be set to
to the globally fixed address used for all DHCP servers. The the mobile node's default-router address, or, to the address set
DHCPOFFER message will be unicasted to the mobile node. in the FixedDHCPServerId configuration variable. The DHCPOFFER
message will be unicasted to the mobile node.
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 When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131], o Any time the DHCP client goes into the DHCP RENEWING state [RFC-
it simply unicasts DHCPREQUEST message including the assigned IPv4 2131], it simply unicasts the DHCPREQUEST message including the
home address in the 'requested IPv4 address' option. The assigned IPv4 home address in the 'requested IP address' option.
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. o The DHCP server will send a DHCPACK to the mobile node to
acknowledge the assignment of the committed IPv4 address.
IPv4 Home Address Renewal with the different DHCP server (After IPv4 Home Address Renewal with a different DHCP server (After
Handoff): Handoff):
1. The use of Virtual DHCP server address When the DHCP client goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile
access gateway, it is required that the mobile node updates the DHCP
server address and uses the address of the DHCP server that is on co-
located on the new mobile access gateway. Any of the following
approaches can be adopted for forcing the DHCP server address change.
1. 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 or DHCPNACK
| : | | : |
2. The use of FORCERENEW [RFC3-203] 2. The use of FORCERENEW message to notify the address change
MN oMAG(DHCP-S) nMAG(DHCP-S) MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
| : | | : |
RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA) RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA)
|<---------------| 2. FORCERENEW |<---------------| 2. FORCERENEW
|--------------->| 3. DHCPREQUEST*b (IPv4 HoA) |--------------->| 3. DHCPREQUEST*b (IPv4 HoA)
BOUND<-------------| 4. DHCPACK or DHCPNACK BOUND<-------------| 4. DHCPACK or DHCPNACK
| : | | : |
*a DHCPREQUEST sent to oMAG *a DHCPREQUEST sent to oMAG
*b DHCPREQUEST sent to nMAG *b DHCPREQUEST sent to nMAG
3. The use of Individual DHCP server address 3. The use of different address on different DHCP servers
MN oMAG(DHCP-S) nMAG(DHCP-S) MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
| : | | : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
| : | (discarding & timeout) | : | (discarding & timeout)
REBINDING--------->| 2. DHCPDISCOVERY REBINDING--------->| 2. DHCPDISCOVER
|<---------------| 3. DHCPOFFER (IPv4 HoA) |<---------------| 3. DHCPOFFER (IPv4 HoA)
|--------------->| 4. DHCPREQUEST(IPv4 HoA) |--------------->| 4. DHCPREQUEST(IPv4 HoA)
BOUND<-------------| 5. DHCPACK (IPv4 HoA) BOUND<-------------| 5. DHCPACK (IPv4 HoA)
| : | | : |
Figure 5: Renewing Address to different DHCP server Figure 5: Address renewal with a different DHCP server
o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
it directly unicasts DHCPREQUEST message to the DHCP server. If
the mobile node moves and attaches to a new mobile access gateway,
it needs to update the DHCP server address to the new one (i.e.
the address of the currently attached mobile access gateway).
Thus, one of following operations is required.
o If the IPv4 virtual DHCP address is used, the DHCPREQUEST for
renewing address is received by the mobile access gateway to which
the mobile node is currently attached. The mobile access gateway
SHOULD reply DHCPACK or DHCPNACK depending on the correctness of
the requesting IPv4 home address in the DHCPREQUEST as shown in
Figure 5-1).
o If the IPv4 virtual DHCP address is not used, the mobile node o If a fixed DHCP server address is used by all the mobile access
reconfigures the DHCP server address whenever it changes the gateways in the Proxy Mobile IPv6 domain, the DHCPREQUEST message
attached mobile access gateway. sent by the mobile node for renewing the address will be received
by the new mobile access gateway on the attached link. The mobile
access gateway after completing the Proxy Mobile IPv6 signaling
and upon acquiring the IPv4 home address of the mobile node will
return the address in the DHCPACK message. However, if the mobile
access gateway is unable to complete the Proxy Mobile IPv6
signaling or 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, as shown in Figure 5-1).
* If a mobile access gateway receives any DHCP messages unicasted o If the mobile access gateway on the access link receives any DHCP
to a different mobile access gateway from the mobile node, it messages from the mobile node unicasted to a server address that
SHOULD unicast FORCERENEW message [RFC-3203] to the mobile node is not locally configured, the mobile access gateway can unicast
as shown in Figure 5-2). In the FORCERENEW, the 'server FORCERENEW message [RFC-3203] to the mobile node as shown in
identifier' field MUST be overwritten by the IPv4 address of Figure 5-2). This will force the mobile node to update the DHCP
the current mobile access gateway so that the client can update server address with the address of the mobile access gateway on
the DHCP server address. the new link.
* If the IPv4 virtual DHCP address is not used and the FORCERENEW o If a fixed IPv4 address is not used by all the DHCP servers in the
[RFC-3203] is not supported at the mobile access gateway, the Proxy Mobile IPv6 domain and if the FORCERENEW message [RFC-3203]
mobile access gateway SHOULD discard any DHCPREQUEST message is also not supported by the DHCP server on the mobile access
sent not to the mobile access gateway itself, so that the gateway, then that DHCPREQUEST message should be ignored. This
mobile node should go into the DHCP-REBINDING-STATE and will force the mobile node to enter the DHCP REBINDING state [RFC-
broadcast DHCPDISCOVERY without server identifier as shown in 2131] and start the DHCPDISCOVER phase, as shown in Figure 5-3).
Figure 5-3).
Additional Operation: Additional Operation:
o At an point the mobile access gateway fails to extend the binding o If at any point the mobile access gateway fails to extend the
lifetime with the local mobility anchor, it MUST send an binding lifetime with the local mobility anchor, it MUST send an
unsolicited DHCPNACK to the mobile node. It MUST also tear down unsolicited DHCPNAK message [RFC-2131] to the mobile node.
the point-to-point link shared with the mobile node.
3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway
A DHCP relay is co-located with each mobile access gateway. A DHCP A DHCP relay is co-located with each mobile access gateway. A DHCP
server is located somewhere in the Proxy Mobile IPv6 domain or is co- server is located somewhere in the Proxy Mobile IPv6 domain (e.g., is
located with the local mobility anchor. Figure 6 are the sequence of co-located with the local mobility anchor). Figure 6 shows the
IPv4 home address assignment using DHCP Relay. 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. DHCPDISCOVERY (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 via DHCP-R
| | | | | |
* Tunnel/Route setup(no.3) and DHCPOFFER/REQUEST/ACK (no.4-7) * The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the
are processed in parallel. DHCPDISCOVER phase (Step-4) may occur in any order. However,
the DHCPOFFER (Step-5) and the following steps will occur in
the specified order and after the Tunnel/Route Setup (Step-3).
Figure 6: Overview of the DHCP relay located at mobile access gateway Figure 6: 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 DHCPDISCOVERY message o When the mobile access gateway receives a DHCPDISCOVER message
from a mobile node, it MUST check whether it has already obtained from a mobile node, it MUST check whether it has already obtained
the IPv4 home address for the mobile node from the local mobility the IPv4 home address for the mobile node from the local mobility
anchor. anchor.
o If the IPv4 home address is not yet assigned by the local mobility o If the IPv4 home address is not yet assigned by the local mobility
anchor, the mobile access gateway MUST send a Proxy Binding Update anchor, the mobile access gateway MUST send a Proxy Binding Update
for that. for that.
o If the IPv4 home address is not assigned to the mobile node by the o If the IPv4 home address is not assigned to the mobile node by the
local mobility anchor due to administrative policy or resource local mobility anchor due to administrative policy or resource
limitation, it MUST discard the DHCPDISCOVERY messages from the limitation, it MUST discard the DHCPDISCOVER messages from the
mobile node. mobile node.
o Otherwise, it MUST add the DHCP relay agent information option o Otherwise, it MUST add the DHCP relay agent information option
[RFC-3046] to the DHCPDISCOVERY message. The assigned IPv4 home [RFC-3046] to the DHCPDISCOVER message. The assigned IPv4 home
address (32-bit full address) is included in the Agent Remote ID address (32-bit full address) is included in the Agent Remote ID
Sub-option of the DHCP relay agent information option. This sub- Sub-option of the DHCP relay agent information option. This sub-
option is used as a hint of address assignment of the DHCP server. option is used as a hint of address assignment of the DHCP server.
o When the mobile access gateway receives the DHCPOFFER from the o When the mobile access gateway receives the DHCPOFFER from the
DHCP server, it MUST verify whether the DHCP server offers the DHCP server, it MUST verify whether the DHCP server offers the
correct IPv4 home address which is indicated in the Agent Remote correct IPv4 home address which is indicated in the Agent Remote
ID Sub-option of the DHCPDISOCVERY. If the DHCP server offers the ID Sub-option of the DHCPDISOCVERY. If the DHCP server offers the
different address from the expected address, the mobile access different address from the expected address, the mobile access
gateway MUST drop the DHCPOFFER. gateway MUST drop the DHCPOFFER.
skipping to change at page 26, line 22 skipping to change at page 28, line 18
o As shown in Figure 6, the DHCP messages MAY be sent across an o As shown in Figure 6, the DHCP messages MAY be sent across an
administrative boundaries. The operators MUST ensure to secure administrative boundaries. The operators MUST ensure to secure
these messages. All the DHCP messages relayed by the mobile these messages. All the DHCP messages relayed by the mobile
access gateway can be tunneled over the local mobility anchor if access gateway can be tunneled over the local mobility anchor if
needed. Alternatively, if the networks in the Proxy Mobile IPv6 needed. Alternatively, if the networks in the Proxy Mobile IPv6
domain are secured enough, the mobile access gateway just relays domain are secured enough, the mobile access gateway just relays
the DHCP messages to the server without the tunnel. For doing the DHCP messages to the server without the tunnel. For doing
this, all the mobile access gateway MUST have the route toward the this, all the mobile access gateway MUST have the route toward the
DHCP server. More remarks can be found in Section 7. DHCP server. More remarks can be found in Section 7.
IPv4 Home Address Renewal to the same DHCP server: (No Hanover) IPv4 Home Address Renewal to the same DHCP server: (No Handover)
o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131], o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131],
it directly unicasts DHCPREQUEST message to the DHCP server. The it directly unicasts DHCPREQUEST message to the DHCP server. The
DHCP relay agent cannot receive the DHCPREQUEST for renewing DHCP relay agent cannot receive the DHCPREQUEST for renewing
addresses. Thus, one of following operations is required. addresses. Thus, one of following operations is required.
* The DHCP relay agent SHOULD intercept all the DHCP packets * The DHCP relay agent SHOULD intercept all the DHCP packets
regardless of the destination address. Since the link between regardless of the destination address. Since the link between
a mobile node and a mobile access gateway is the point-to-point a mobile node and a mobile access gateway is the point-to-point
link, it is possible to check the DHCP packets at the interface link, it is possible to check the DHCP packets at the interface
by enabling the promiscuous mode. by enabling the promiscuous mode.
* The cost of packets monitoring is not negligible. Therefore, * The cost of monitoring packets is not negligible. Therefore,
The DHCP relay agent MAY use the DHCP Server Identifier The DHCP relay agent MAY use the DHCP Server Identifier
Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for
the address renewal. The DHCP client uses the DHCP server the address renewal. The DHCP client uses the DHCP server
address which is overridden by the DHCP relay agent address as address which is overridden by the DHCP relay agent address as
a destination address of DHCPREQUEST. The DHCP Server a destination address of DHCPREQUEST. The DHCP Server
Identifier Override Sub-option is recommended only when the Identifier Override Sub-option is recommended only when the
Virtual DHCP address is configured on all the mobile access Virtual DHCP address is configured on all the mobile access
gateways. Otherwise, the DHCP relay agent address is changed gateways. Otherwise, the DHCP relay agent address is changed
when the mobile node changes the attached mobile access when the mobile node changes the attached mobile access
gateway. As a result, the DHCP relay agent MUST monitor DHCP gateway. As a result, the DHCP relay agent MUST monitor DHCP
skipping to change at page 27, line 16 skipping to change at page 29, line 12
mobility anchor, the mobile access gateway MUST NOT relay the mobility anchor, the mobile access gateway MUST NOT relay the
DHCPREQUEST and MUST discard it. DHCPREQUEST and MUST discard it.
o If the address verification is successfully completed, the DHCP o If the address verification is successfully completed, the DHCP
relay agent SHOULD forward the DHCPREQUEST to the DHCP server. relay agent SHOULD forward the DHCPREQUEST to the DHCP server.
Additional Operations: Additional Operations:
o If the mobile access gateway sends Proxy Binding Update for the o If the mobile access gateway sends Proxy Binding Update for the
IPv4 home address and receives the unsuccessful Proxy Binding IPv4 home address and receives the unsuccessful Proxy Binding
Acknowledgement (by indicating the error codes), it MUST send Acknowledgement (as indicated by the error codes), it MUST send
unsolicited DHCPNACK for the invalid IPv4 home address to the unsolicited DHCPNACK for the invalid IPv4 home address to the
mobile node. XXXX 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 28, line 34 skipping to change at page 30, line 34
When the local mobility anchor and the mobile access gateway are When the local mobility anchor and the mobile access gateway are
configured and reachable using only IPv4 addresses, the mobile access configured and reachable using only IPv4 addresses, the mobile access
gateway serving a mobile node can potentially send the signaling gateway serving a mobile node can potentially send the signaling
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 only an IPv4 address. configured and reachable using an IPv4 address. Additionally,
Additionally, both these entities are also IPv6 enabled and have both entities are also IPv6 enabled and have configured IPv6
configured IPv6 addresses on its interfaces, as specified in [RFC- addresses on their interfaces, as specified in [RFC-5213], but are
5213], but are reachable only over an IPv4 transport. reachable only over an IPv4 transport.
o The mobile access gateway can be potentially in a private IPv4 o The mobile access gateway can be potentially in a private IPv4
network behind a NAT [RFC-3022] device, with a private IPv4 network behind a NAT [RFC-3022] device, with a private IPv4
address configured on its egress interface. However, the local address configured on its egress interface. However, the local
mobility anchor must not be behind a NAT and must be using a mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address. globally routable IPv4 address.
o The Proxy Mobile IPv6 signaling messages exchanged between the o The Proxy Mobile IPv6 signaling messages exchanged between the
local mobility anchor and the mobile access gateway for local mobility anchor and the mobile access gateway for
negotiating the IPv4 transport will be encapsulated and carried as negotiating the IPv4 transport will be encapsulated and carried as
IPv4 packets. However, these signaling messages are fundamentally IPv4 packets. However, these signaling messages are fundamentally
IPv6 messages using the mobility header and the related semantics IPv6 messages using the mobility header and the related semantics
as specified in base Proxy Mobile IPv6 specification [RFC-5213], as specified in base Proxy Mobile IPv6 specification [RFC-5213],
but carried as a payload in an IPv4 packet (IPv4-UDP encapsulation but carried as a payload in an IPv4 packet. The supported
mode). encapsulation modes for the signaling messages are either native
IPv4 or IPv4 with UDP header.
o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and
the IPv4 transport support specified in this section is agnostic the IPv4 transport support specified in this section is agnostic
to the type of address mobility enabled for that mobile node. to the type of address mobility enabled for that mobile node.
o The IPv4 tunnel established between the local mobility anchor and o The IPv4 tunnel established between the local mobility anchor and
the mobile access gateway (with any of the supported encapsulation the mobile access gateway (with any of the supported encapsulation
modes over IPv4 transport) will be used for carrying the mobile modes over IPv4 transport) will be used for carrying the mobile
node's IPv4 and IPv6 traffic. The supported encapsulation modes node's IPv4 and IPv6 traffic. The supported encapsulation modes
for carrying mobile node's IPv4 or IPv6 packets when using IPv4 for carrying mobile node's IPv4 or IPv6 packets when using IPv4
transport are as shown below. transport are as shown below.
* IPv4 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet)
* IPv4-UDP (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP
header) header).
* IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP
and TLV header. Refer to [ID-DSMIP6]). and TLV header). Refer to [ID-DSMIP6].
* IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP
and ESP headers. Refer to [RFC-3948]. and ESP headers). Refer to [RFC-3948].
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
For supporting this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor [RFC-5213] MUST be structure maintained by the local mobility anchor [RFC-5213] MUST be
extended with the following additional parameters. extended with the following additional parameters.
o The IPv4 address of the mobile access gateway. This is the o The IPv4 address of the mobile access gateway. This is the
address configured on the egress interface of the mobile access address configured on the egress interface of 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, present in can be obtained from the IPv4 Care-of Address option [ID-DSMIP6],
the received Proxy Binding Update message. If the option was not present in the received Proxy Binding Update message. If the
present in the request, this field MUST be set to the source option was not present in the request, this field MUST be set to
address of the IPv4 header of the received Proxy Binding Update the source address of the IPv4 header of the received Proxy
message. However, if the received Proxy Binding Update message is Binding Update message. However, if the received Proxy Binding
not sent as an IPv4 packet, this field MUST be set to ALL_ZERO Update message is not sent as an IPv4 packet, this field MUST be
value. set to ALL_ZERO value.
o The IPv4 NAT translated address of the mobile access gateway. If o The IPv4 NAT translated address of the mobile access gateway. If
the mobile access gateway is not behind a NAT [RFC-3022], this the mobile access gateway is not behind a NAT [RFC-3022], this
address will be the same as the address configured on the egress address will be the same as the address configured on the egress
interface of the mobile access gateway. This address can be interface of the mobile access gateway. This address can be
obtained from the IPv4 header of the received Proxy Binding Update obtained from the IPv4 header of the received Proxy Binding Update
message. However, if the received Proxy Binding Update message is message. However, if the received Proxy Binding Update message is
not sent as an IPv4 packet, this field MUST be set to ALL_ZERO not sent as an IPv4 packet, this field MUST be set to ALL_ZERO
value. value.
4.1.2. Extensions to Mobile Node's Policy Profile 4.1.2. Extensions to Mobile Node's Policy Profile
For supporting this feature the mobile node's policy profile, To support the IPv4 Transport Support feature the mobile node's
specified in Section 6.2 of [RFC-5213] MUST be extended with the policy profile, specified in Section 6.2 of [RFC-5213] MUST be
following additional fields. This are mandatory fields of the policy extended with the following additional fields. This are mandatory
profile required for supporting this feature. fields of the policy profile required for supporting this feature.
o A flag indicating if IPv4 transport should be used. The value of o A flag indicating whether or not IPv4 transport should be used.
this flag can be different at different mobile access gateway. The value of this flag can vary at different mobile access
The specific details on how this flag is maintained on a per gateways. The specific details on how this flag is maintained on
mobile access gateway basis is outside the scope of this document. a per mobile access gateway basis is outside the scope of this
document.
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. The local mobility signaling messages received over IPv4 transport.
anchor MUST apply these signaling rules on the IPv4 UDP encapsulated
Proxy Binding Update messages received on DSMIP UDP port [ID-DSMIP6].
4.1.3.1. Processing Proxy Binding Updates 4.1.3.1. Processing Proxy Binding Updates
o If the received Proxy Binding Update message (encapsulated in IPv4 o If the received Proxy Binding Update message (encapsulated in IPv4
UDP packet) is protected using IPsec ESP header, then the message or IPv4-UDP header) is protected using IPsec ESP header, then the
MUST be authenticated as described in Section 4 of [RFC-5213]. message MUST be authenticated as described in Section 4 of [RFC-
However, if the IPv4 packet is not protected using IPsec ESP 5213]. However, if the IPv4 packet is not protected using IPsec
header, then the message MUST be authenticated after removing the ESP header, then the message MUST be authenticated after removing
outer IPv4 UDP header. the outer encapsulation (IPv4 or IPv4-UDP) header.
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 IPv4 UDP header. removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address present in the request, the o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in
NAT presence detection procedure specified in Section 4.1.3.3 MUST the request and if the outer encapsulation header is IPv4-UDP,
be used for detecting the NAT in the path. then the NAT presence detection procedure specified in Section
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 from the below
considerations. considerations.
* If the NAT is detected on the path, then the encapsulation mode * If the received Proxy Binding Update message was sent with IPv4
for the tunnel MUST be set to IPv4-UDP. Otherwise the encapsulated header, then the encapsulation mode for the bi-
encapsulation mode MUST be set to IPv4. However, if the (F) directional tunnel MUST be set to IPv4. Otherwise, the
flag in the received Proxy Binding Update message is set to following considerations apply.
value of 1 and even if NAT is not detected, then the
encapsulation mode MUST be set to IPv4-UDP. * If a 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,
then the encapsulation mode MUST be set to IPv4-UDP. Otherwise
the encapsulation mode MUST be set to IPv4.
* If the (T) flag in the Proxy Binding Update message is set to * If the (T) flag in the Proxy Binding Update message is set to
value of 1, then the encapsulation mode MUST be set to IPv4- value of 1, then the encapsulation mode MUST be set to IPv4-
UDP-TLV. UDP-TLV.
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 UDP the received Proxy Binding Update message was encapsulated in an IPv4
header of an IPv4 packet, the following additional considerations packet or as a payload in the UDP header of an IPv4 packet, the
MUST be applied. following additional considerations MUST be applied.
o The NAT Detection option [ID-DSMIP6] MUST be present only if there
is a IPv4 Care-of Address option present in the received Proxy
Binding Update and if the NAT detection procedure resulted in
detecting a NAT on path. In all other cases, the option MUST NOT
be present.
o The Proxy Binding Acknowledgement message MUST be encapsulated in o The Proxy Binding Acknowledgement message MUST be encapsulated in
an UDP header of an IPv4 packet. an IPv4 packet. However, if the received Proxy Binding Update
message was encapsulated in the UDP header of an IPv4 packet, then
the message MUST be encapsulated in the UDP header of an IPv4
packet.
o The source address in the IPv4 header of the message MUST be set o The source address in the IPv4 header of the message MUST be set
to the destination IPv4 address of the received request. to the destination IPv4 address of the received request.
o If the mobile access gateway and the local mobility anchor are o If the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security using globally routable IPv4 addresses and if there is a security
associated that is based of IPv4 addresses, then the encapsulated associated that is based of IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 PBA) MUST be protected using IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
IPsec ESP [RFC-4301] mode and additionally there is no need to MUST be protected using IPsec ESP [RFC-4301] mode. There is no
apply IPsec ESP header on the IPv6 packet. In all other cases, need to apply IPsec ESP header to the IPv6 packet. In all other
the Proxy Binding Acknowledgement message MUST be protected using cases, the Proxy Binding Acknowledgement message MUST be protected
IPsec prior to the 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
is a IPv4 Care-of Address option [ID-DSMIP6] present in the
received Proxy Binding Update and if the NAT detection procedure
resulted in detecting a NAT on path. In all other cases, the
option MUST NOT be present.
o The format of the Proxy Binding Acknowledgement message o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 UDP packet and protected using IPv6 encapsulated in an IPv4 packet and protected using IPv6 security
security association. association. The UDP header MUST be present only if the received
Proxy Binding Update message was sent with IPv4-UDP encapsulation
header.
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) UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/
/* IPv6 PBU Packet protected with ESP header */ /* IPv6 PBA Packet protected with ESP header */
Figure 8: Proxy Binding Acknowledgment Message encapsulated in Figure 8: Proxy Binding Acknowledgment (PBA) Message encapsulated
IPv4 header in IPv4 header
o The format of the Proxy Binding Acknowledgement message o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 UDP packet and protected using IPv4 encapsulated in an IPv4 packet and protected using IPv4 security
security association. association.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
ESP Header ESP Header
UDP header (sport=DSMIP_PORT, dport= pbu_sport) UDP header (sport=DSMIP_PORT, dport= pbu_sport) /* Optional */
/* IPv6 PBU Packet protected with no ESP header */ /* IPv6 PBA Packet protected with no ESP header */
Figure 9: Proxy Binding Acknowledgment encapsulated in IPv4 ESP Figure 9: Proxy Binding Acknowledgment (PBA)Message encapsulated
header in IPv4 ESP header
4.1.3.3. NAT Presence Detection 4.1.3.3. NAT Presence Detection
When the transport network between the local mobility anchor and the When the transport network between the local mobility anchor and the
mobile access gateway is an IPv4 network, the mobile access gateway mobile access gateway is an IPv4 network, the mobile access gateway
will send the Proxy Binding Update messages encapsulated in the IPv4- will send the Proxy Binding Update messages encapsulated in the IPv4-
UDP packet. On receiving this Proxy Binding Update packet UDP packet. On receiving this Proxy Binding Update packet
encapsulated in an IPv4-UDP packet, the local mobility anchor if it encapsulated in an IPv4-UDP packet, the local mobility anchor if it
detects a NAT on the path, will send the Proxy Binding Acknowledgment detects a NAT on the path, will send the Proxy Binding Acknowledgment
message with the NAT Detection Option. The presence of this option message with the NAT Detection Option. The presence of this option
in the Proxy Binding Acknowledgment is an indication to the mobile in the Proxy Binding Acknowledgment is an indication to the mobile
access gateway about the presence of NAT in the path. On detecting access gateway about the presence of NAT in the path. On detecting
the NAT in the path, both the local mobility anchor and the mobile any NAT in the path, both the local mobility anchor and the mobile
access gateway MUST set the encapsulation mode of the tunnel to IPv4- access gateway MUST set the encapsulation mode of the tunnel to IPv4-
UDP-based encapsulation. The specific details around the NAT UDP-based encapsulation. The specific details around the NAT
detection and the related logic is described in DSMIPv6 specification detection and the related logic are described in DSMIPv6
[ID-DSMIP6]. specification [ID-DSMIP6].
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:
o On receiving an IPv4 or an IPv6 packet from a correspondent node o On receiving an IPv4 or an IPv6 packet from a correspondent node
with the destination address matching any of the mobile node's with the destination address matching any of the mobile node's
IPv4 or IPv6 home addresses, the local mobility anchor MUST IPv4 or IPv6 home addresses, the local mobility anchor MUST
skipping to change at page 34, line 9 skipping to change at page 36, line 15
4.1.4.3. Bi-Directional Tunnel Management 4.1.4.3. Bi-Directional Tunnel Management
The Tunnel Management considerations specified in section 5.6.1 of The Tunnel Management considerations specified in section 5.6.1 of
[RFC-5213] apply for the IPv4 transport tunnels as well, with just [RFC-5213] apply for the IPv4 transport tunnels as well, with just
one difference that the encapsulation mode is different. one difference that the encapsulation mode is different.
4.2. Mobile Access Gateway Considerations 4.2. Mobile Access Gateway Considerations
4.2.1. Extensions to Binding Update List Entry 4.2.1. Extensions to Binding Update List Entry
For supporting this feature, the conceptual Binding Update List entry To support the IPv4 Transport Support feature, the conceptual Binding
data structure maintained by the mobile access gateway [RFC-5213] Update List entry data structure maintained by the mobile access
MUST be extended with the following additional parameters. gateway [RFC-5213] MUST be extended with the following additional
parameters.
o The IPv4 address of the local mobility anchor. This address can o The IPv4 address of the local mobility anchor. This address can
be obtained from the mobile node's policy profile. be obtained from the mobile node's policy profile.
o The IPv4 address of the mobile access gateway. This is the o The IPv4 address of the mobile access gateway. This is the
address configured on the egress interface of the mobile access address configured on the egress interface of the mobile access
gateway and is registered with the mobile node's local mobility gateway and is registered with the mobile node's local mobility
anchor as the IPv4 Proxy-CoA. However, if the mobile access anchor as the IPv4 Proxy-CoA. However, if the mobile access
gateway is in a private IPv4 network and behind a NAT, the address gateway is in a private IPv4 network and behind a NAT, the address
that is registered with the mobile node's local mobility anchor is that is registered with the mobile node's local mobility anchor is
the NAT translated public IPv4 address. the NAT translated public IPv4 address.
4.2.2. Signaling Considerations 4.2.2. Signaling Considerations
The mobile access gateway when sending a Proxy Binding Update message The mobile access gateway when sending a Proxy Binding Update message
to the local mobility anchor MUST construct the message as specified to the local mobility anchor MUST construct the message as specified
in Section 6.9.1.5. However, if the mobile access gateway is in an in Section 6.9.1.5. However, if the mobile access gateway is in an
IPv4-only access network, the following additional considerations IPv4-only access network, the following additional considerations
MUST be applied. MUST be applied.
o The Proxy Binding Update message MUST be encapsulated in an UDP o The Proxy Binding Update message MUST be encapsulated in an IPv4
header of an IPv4 packet. packet. However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
Binding Update message MUST be encapsulated in an UDP header of an
IPv4 packet.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [ID-DSMIP6] 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.3.
o When sending a Proxy Binding message for extending the lifetime of o When sending a Proxy Binding message for extending the lifetime of
a currently existing mobility session or for de-registering the a currently existing mobility session or for de-registering the
mobility session, the Proxy Binding Update message MUST be mobility session, the Proxy Binding Update message MUST be
constructed as the initial request. constructed as the initial request.
Receiving Proxy Binding Acknowledgement Receiving Proxy Binding Acknowledgement
o If the received Proxy Binding Acknowledgement message o If the received Proxy Binding Acknowledgement message
(encapsulated in IPv4 UDP packet) is protected using IPsec ESP (encapsulated in IPv4 or IPv4 UDP packet) is protected using IPsec
header, then the message MUST be authenticated as described in ESP header, then the message MUST be authenticated as described in
Section 4 of [RFC-5213]. However, if the IPv4 packet is not Section 4 of [RFC-5213]. However, if the IPv4 packet is not
protected using IPsec ESP header, then the message MUST be protected using IPsec ESP header, then the message MUST be
authenticated after removing the outer IPv4 UDP header. authenticated after removing the outer IPv4 or IPv4-UDP header.
o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be
applied on the encapsulated Proxy Binding Acknowledgement message, applied on the encapsulated Proxy Binding Acknowledgement message,
after removing the outer IPv4 UDP header. after removing the outer IPv4 UDP header.
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 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 from the below
considerations. considerations.
* The encapsulation mode for the bi-directional tunnel MUST be
set to IPv4. However, if the value of the configuration
variable, UseIPv4UDPEncapForSignalingMessages, is set to 1,
then the following considerations MUST be applied.
* If there is a NAT Detection option [ID-DSMIP6] in the received * If there is a NAT Detection option [ID-DSMIP6] in the received
Proxy Binding Acknowledgement message, then the encapsulation Proxy Binding Acknowledgement message, then the encapsulation
mode for the tunnel MUST be set to IPv4-UDP. Otherwise the mode for the tunnel MUST be set to IPv4-UDP. Otherwise the
encapsulation mode MUST be set to IPv4. encapsulation mode MUST 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 [ID-DSMIP6] 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 enabled. message MUST be set to value of 1.
o If the mobile access gateway and the local mobility anchor are o If the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security using globally routable IPv4 addresses and if there is a security
associated that is based of IPv4 addresses, then the encapsulated associated that is based of IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 PBU) MUST be protected using IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement
IPsec ESP [RFC-4301] mode and additionally there is no need to message) MUST be protected using IPsec ESP [RFC-4301] mode and
apply ESP header on the IPv6 packet. In all other cases, the additionally there is no need to apply ESP header on the IPv6
Proxy Binding Update message MUST be protected on the IPv6 packet packet. In all other cases, the Proxy Binding Update message MUST
of the Proxy Binding Update message, prior to the IPv4 be protected on the IPv6 packet of the Proxy Binding Update
encapsulation. message, 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 UDP packet with IPsec protection on the encapsulated packet: 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)
UDP header (sport=ANY, dport= DSMIP_PORT) UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/
/* IPv6 PBU Packet protected with ESP header */ /* IPv6 PBU Packet protected with ESP header */
Figure 11: Proxy Binding Update Message encapsulated in IPv4 UDP Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4
header UDP header
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 UDP packet and with IPsec protection on the encapsulated IPv4 UDP packet and with IPsec protection on the encapsulated
packet: packet:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
ESP Header ESP Header
UDP header (sport=ANY, dport= DSMIP_PORT) UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/
/* IPv6 PBU Packet protected with no ESP header */ /* IPv6 PBU Packet protected with no ESP header */
Figure 12: Proxy Binding Update Message Encapsulated with IPsec Figure 12: Proxy Binding Update (PBU) message encapsulated in IPv4
protection ESP header
4.2.2.2. Forwarding Considerations 4.2.2.2. Forwarding Considerations
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o On receiving an IPv4 or an IPv6 packet from the mobile node to any o On receiving an IPv4 or an IPv6 packet from the mobile node to any
destination, the mobile access gateway MUST tunnel the packet to destination, the mobile access gateway MUST tunnel the packet to
the local mobility anchor. The format of the tunneled packet is the local mobility anchor. The format of the tunneled packet is
shown below. However, considerations from Section 6.10.3 of [RFC- shown below. However, considerations from Section 6.10.3 of [RFC-
5213] MUST be applied with respect the local routing and on the 5213] MUST be applied with respect the local routing and on the
skipping to change at page 38, line 16 skipping to change at page 40, line 16
5.1. Local Mobility Anchor - Configuration Variables 5.1. Local Mobility Anchor - Configuration Variables
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.
AcceptIPv4UDPEncapsulationRequest AcceptIPv4UDPEncapsulationRequest
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 support if there is NAT should accept IPv4 UDP encapsulation support for the mobile node's
detected in the path. data traffic, if there is NAT detected in the path.
The default value for this flag is set to value of 1, indicating The default value for this flag is set to value of 1, indicating
that the local mobility anchor MUST enable IPv4 UDP encapsulation that the local mobility anchor MUST enable IPv4 UDP encapsulation
support on detecting NAT in the path. support on detecting NAT in the path.
When the value for this flag is set to value of 0, the local When the value for this flag is set to value of 0, the local
mobility anchor MUST NOT enable IPv4 UDP encapsulation support. mobility anchor MUST NOT enable IPv4 UDP encapsulation support.
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.
RequestIPv4UDPEncapsulationSupport UseIPv4UDPEncapForSignalingMessages
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 IPv4 should use IPv4-UDP encapsulation mode for the signaling messages.
UDP encapsulation support if NAT is detected in the path.
The default value for this flag is set to value of 0, indicating The default value for this flag is set to value of 0, indicating
that the mobile access gateway MUST NOT request the mobile node's that the mobile access gateway MUST NOT use IPv4-UDP encapsulation
local mobility anchor for IPv4 UDP encapsulation support. mode, but MUST use native IPv4 encapsulation mode for sending the
Proxy 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 value of 1, the mobile
access gateway MUST request the mobile node's local mobility access gateway MUST use IPv4-UDP encapsulation mode for sending
anchor for IPv4 UDP encapsulation support if there is NAT detected the Proxy Mobile IPv6 signaling messages.
in the path.
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 even when NAT is not detected in IPv4 UDP encapsulation support for the mobile node's data traffic,
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 value of 0, indicating
that the mobile access gateway MUST NOT request the mobile node's that the mobile access gateway MUST NOT request the mobile node's
local mobility anchor for forcing IPv4 UDP encapsulation support local mobility anchor for forcing IPv4 UDP encapsulation support
even when NAT is not detected in path. even 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 value of 1, the mobile
access gateway MUST force the mobile node's local mobility anchor access gateway MUST force the mobile node's local mobility anchor
for IPv4 UDP encapsulation support. for IPv4 UDP encapsulation support.
This flag is applicable only when the flag This flag is applicable only when the flag
RequestIPv4UDPEncapsulationSupport is set to a value of 1. UseIPv4UDPEncapForSignalingMessages is set to a value of 1.
5.3. Proxy Mobile IPv6 Domain - Configuration Variables 5.3. Proxy Mobile IPv6 Domain - Configuration Variables
All the mobile entities (local mobility anchors and mobile access All the mobile entities (local mobility anchors and mobile access
gateways) in a Proxy Mobile IPv6 domain MUST allow the following gateways) in a Proxy Mobile IPv6 domain MUST allow the following
variables to be configured by the system management. The configured variables to be configured by the system management. The configured
values for these protocol variables MUST survive server reboots and values for these protocol variables MUST survive server reboots and
service restarts. These variables MUST be globally fixed for a given service restarts. These variables MUST be globally fixed for a given
Proxy Mobile IPv6 domain resulting in the same values being enforced Proxy Mobile IPv6 domain resulting in the same values being enforced
on all the mobility entities in that domain. on all the mobility entities in that domain.
skipping to change at page 42, line 37 skipping to change at page 44, line 37
myungki.shin@gmail.com myungki.shin@gmail.com
9. Acknowledgments 9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like
to thank all the authors of the document and acknowledge that initial to thank all the authors of the document and acknowledge that initial
work. work.
Thanks to Jonne Soinnen, Julien Laganier, Zu Qiang, Premec Domagoj, Thanks to Charles Perkins, Jonne Soinnen, Julien Laganier, Mohana
Sammy Touati and Niklas Nuemann for their helpful review of this Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati and Zu Qiang
document. for their helpful review of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)",
draft-ietf-mip6-mext-nemo-v4traversal-05.txt,July 2008.
[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
Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-05.txt, July 2008.
10.2. Informative References 10.2. Informative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP", [RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000. RFC 3011, November 2000.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001. Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP [RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001. reconfigure extension", RFC 3203, December 2001.
[RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link-
Local Addresses", RFC 3927, May 2005.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
Mobility", RFC 4977, August 2007. Mobility", RFC 4977, August 2007.
[RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp,
"DHCP Server Identifier Override Suboption", RFC 5107, February 2008. "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University Toyota ITC / Keio University
 End of changes. 169 change blocks. 
506 lines changed or deleted 602 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/