draft-ietf-netlmm-pmip6-ipv4-support-05.txt   draft-ietf-netlmm-pmip6-ipv4-support-06.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: March 27, 2009 Cisco Expires: May 31, 2009 Cisco
September 23, 2008 November 27, 2008
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-05.txt draft-ietf-netlmm-pmip6-ipv4-support-06.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 March 27, 2009. This Internet-Draft will expire on May 31, 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) extending IPv4 home address mobility support to the two-fold: 1) enable IPv4 home address mobility support to the mobile
mobile node. 2) allowing the mobility entities in the Proxy Mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6
IPv6 domain to exchange signaling messages over an IPv4 transport domain to exchange signaling messages over an IPv4 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 . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 16 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 16 3.2.1. Extensions to Binding Update List Entry . . . . . . . 17
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 20 Gateway . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 21 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 21 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22
3.3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . 22 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 22 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 24
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 Gateway . . . . . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . . . . 26 Gateway . . . . . . . . . . . . . . . . . . . . . . . 28
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 30 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 31 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 31 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 32 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 32 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 35 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 36 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38
4.2.1. Extensions to Binding Update List Entry . . . . . . . 36 4.2.1. Extensions to Binding Update List Entry . . . . . . . 38
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 36 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 40 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 42
5.1. Local Mobility Anchor - Configuration Variables . . . . . 40 5.1. Local Mobility Anchor - Configuration Variables . . . . . 42
5.2. Mobile Access Gateway - Configuration Variables . . . . . 40 5.2. Mobile Access Gateway - Configuration Variables . . . . . 42
5.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a same network infrastructure. Thus, it is reasonable to assume that a
mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
IPv6-only or in dual-stack mode and additionally the network between IPv6-only or in dual-stack mode and additionally the network between
the mobile access gateway and a local mobility anchor may be an IPv4 the mobile access gateway and a local mobility anchor may be an IPv4
or an IPv6 network. It is also reasonable to expect the same or an IPv6 network. It is also reasonable to expect the same
skipping to change at page 6, line 41 skipping to change at page 6, line 41
The following are the configuration requirements from the mobility The following are the configuration requirements from the mobility
entities in the Proxy Mobile IPv6 domain for supporting the entities in the Proxy Mobile IPv6 domain for supporting the
extensions defined in this document. extensions defined in this document.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
IPv4 and IPv6 enabled. Irrespective of the type of transport IPv4 and IPv6 enabled. Irrespective of the type of transport
network (IPv4 or IPv6) separating these two entities, the mobility network (IPv4 or IPv6) separating these two entities, the mobility
signaling is always based on Proxy Mobile IPv6 [RFC-5213]. signaling is always based on Proxy Mobile IPv6 [RFC-5213].
o The local mobility anchor and the mobile access gateway MUST be
configured with IPv6 global addresses, even when they are in IPv4-
only network. When using IPv4 transport, it is not required that
there is IPv6 routing enabled between the local mobility anchor
and the mobile access gateway. However, there must be IPv6
routing enabled for the configured address locally within the
host.
o The mobile node can be operating in IPv4-only, IPv6-only or in o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. Based on what is enabled for a mobile node, it should dual mode. Based on what is enabled for a mobile node, it should
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
address(es) for its interface and furthermore achieve mobility address(es) for its interface and furthermore achieve mobility
support for those addresses. support for those addresses.
o For enabling IPv4 home address mobility support to a mobile node, o For enabling IPv4 home address mobility support to a mobile node,
it is not required that the IPv6 home address mobility support it is not required that the IPv6 home address mobility support
needs to enabled. However, the respective protocol(s) support needs to enabled. However, the respective protocol(s) support,
must be enabled on the access link between the mobile node and the such as IPv4 or IPv6 packet forwarding, must be enabled on the
mobile access gateway. access link between the mobile node and the mobile access gateway.
o The mobile node can obtain an IPv4 address for its attached o The mobile node can obtain an IPv4 address for its attached
interface. Based on the type of link, it may be able to acquire interface. Based on the type of link, it may be able to acquire
its IPv4 address configuration using DHCP [RFC-2131], IPCP [RFC- its IPv4 address configuration using standard IPv4 address
1332], IKEv2 [RFC-4306], static configuration or through other configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332],
standard IPv4 address configuration mechanisms. IKEv2 [RFC-4306] or static address configuration.
o The mobile node's IPv4 home subnet is typically a shared address o The mobile node's IPv4 home subnet is typically a shared address
space. It is not for the exclusive use of any one mobile node. space. It is not for the exclusive use of any one mobile node.
There can be more than one mobile node sharing different addresses There can be multiple mobile nodes that are assigned IPv4
from the same IPv4 subnet. addresses from the same subnet.
o The mobile access gateway is the IPv4 default-router for the o The mobile access gateway is the IPv4 default-router for the
mobile node on its access link. It will be in the forwarding path mobile node on its access link. It will be in the forwarding path
for the mobile node's data traffic. for the mobile node's data traffic.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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 address is topologically anchored at the attached interface. This address is topologically anchored at the
local mobility anchor. The mobile node configures this address on local mobility anchor. The mobile node configures this address on
its attached interface. Further, if the mobile node connects to its attached interface. If the mobile node connects to the Proxy
the Proxy Mobile IPv6 domain through multiple interfaces and for Mobile IPv6 domain via multiple interfaces each of the interfaces
simultaneous access, each of the attached interface will be are assigned a unique IPv4 address. All the IPv6 home network
assigned a unique IPv4 home address. All the IPv6 home network
prefixes and the IPv4 home address assigned to a given interface prefixes and the IPv4 home address assigned to a given interface
of a mobile node will be managed under one mobility session. of a mobile node will be managed under one mobility session.
Selective De-registration
It is a procedure for partial de-registration of all the addresses
that belong to one address family, i.e., de-registration of either
IPv4 home address, or all of the IPv6 home network prefixes.
Encapsulation Modes Encapsulation Modes
This document uses the following terms when referring to the This document uses the following terms when referring to the
different encapsulation modes. different encapsulation modes.
IPv4-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
IPv4-over-IPv4 IPv4-over-IPv4
skipping to change at page 10, line 23 skipping to change at page 10, line 23
for extending 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
link where the mobile node is attached will identify the mobile node link where the mobile node is attached will identify the mobile node
and will initiate the Proxy Mobile IPv6 signaling with the mobile and will initiate the Proxy Mobile IPv6 signaling with the mobile
node's local mobility anchor. The mobile access gateway will follow node's local mobility anchor. The mobile access gateway will follow
the signaling considerations specified in Section 3.2 for requesting the signaling considerations specified in Section 3.2 for requesting
IPv4 home address mobility 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 routing states for allowing the mobile node to will establish the required routing states for allowing the mobile
use its IPv4 home address from its current point of attachment. node to 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 DHCP [RFC-2131], will be able as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able
to obtain an IPv4 home address (IPv4-MN-HoA) for its attached to obtain an IPv4 home address (IPv4-MN-HoA) for its attached
interface. Although the address configuration mechanisms for interface. Although the address configuration mechanisms for
delivering the address configuration to the mobile node is delivering the address configuration to the mobile node is
independent of the Proxy Mobile IPv6 protocol operation, however independent of the Proxy Mobile IPv6 protocol operation, however
there needs to be some interactions between these two protocol flows. there needs to be some interactions between these two protocol flows.
Section 3.4 identifies these interactions for supporting DHCP based Section 3.4 identifies these interactions for supporting DHCP based
skipping to change at page 11, line 48 skipping to change at page 12, line 5
Network Prefix option [RFC-5213] present in the request, the local Network Prefix option [RFC-5213] present in the request, the local
mobility anchor MUST NOT reject the request as specified in mobility anchor MUST NOT reject the request as specified in
Section 5.3.1 of [RFC-5213]. At least one instance of any of Section 5.3.1 of [RFC-5213]. At least one instance of any of
these two options MUST be present. If there is not a single these two options MUST be present. If there is not a single
instance of any of these two options present in the request, the instance of any of these two options present in the request, the
local mobility anchor MUST reject the request and send a Proxy local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to Binding Acknowledgement message with Status field set to
MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213]. network prefix option) [RFC-5213].
o If there is at least one instance of Home Network Prefix option
[RFC-5213] present in the received Proxy Binding Update message,
but either if the mobile node is not IPv6 enabled, or if IPv6
routing not enabled in the home network, the local mobility anchor
SHOULD reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not
authorized for the requesting IPv6 home network prefix).
o For associating the received Proxy Binding Update message to an o For associating the received Proxy Binding Update message to an
existing mobility session, the local mobility anchor MUST perform existing mobility session, the local mobility anchor MUST perform
the Binding Cache entry existence test by applying the following the Binding Cache entry existence test by applying the following
considerations. considerations.
* If there is at least one instance of the Home Network Prefix * If there is at least one instance of the Home Network Prefix
option [RFC-5213] with a NON_ZERO prefix value, or, if there is option [RFC-5213] with a NON_ZERO prefix value, or, if there is
an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address
in the option set to ALL_ZERO, considerations from Section in the option set to ALL_ZERO, considerations from Section
5.4.1 of [RFC-5213] MUST be applied. 5.4.1 of [RFC-5213] MUST be applied.
skipping to change at page 12, line 50 skipping to change at page 13, line 16
o If there is an IPv4 Home Address option [ID-DSMIP6] 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 in the Proxy Binding Update message with the IPv4 address value in the
option set to ALL_ZERO, the local mobility anchor MUST allocate an option set to ALL_ZERO, the local mobility anchor MUST allocate an
IPv4 home address to the mobile node and associate it with the new IPv4 home address to the mobile node and associate it with the new
mobility session created for that mobile node. mobility session created for that mobile node.
o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4 o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4
address in the option set to a NON_ZERO value, the local mobility address in the option set to a NON_ZERO value, the local mobility
anchor before accepting the request MUST ensure the address is anchor before accepting the request MUST ensure the address is
owned by the local mobility anchor and furthermore the mobile node topologically anchored on the local mobility anchor and
is authorized to use that address. If the mobile node is not furthermore the mobile node is authorized to use that address. If
authorized for that specific address, the local mobility anchor the mobile node is not authorized for that specific address, the
MUST reject the request and send a Proxy Binding Acknowledgement local mobility anchor MUST reject the request and send a Proxy
message with the Status field set to Binding Acknowledgement message with the Status field set to
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
for the requesting IPv4 address). It MUST also include the IPv4 for the requesting IPv4 address). It MUST also include the IPv4
Address Acknowledgement option [ID-DSMIP6] in the reply with the Address Acknowledgement option [ID-DSMIP6] in the reply with the
status field value in the option set to 129 (Administratively status field value in the option set to 129 (Administratively
prohibited). prohibited).
o If the local mobility anchor is unable to allocate an IPv4 address o If the local mobility anchor is unable to allocate an IPv4 address
due to lack of resources, it MUST reject the request and send a due to lack of resources, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to 130 Proxy Binding Acknowledgement message with Status field set to 130
(Insufficient resources). It MUST also include the IPv4 Address (Insufficient resources). It MUST also include the IPv4 Address
skipping to change at page 13, line 39 skipping to change at page 14, line 5
updated with the accepted values for that session. updated with the accepted values for that session.
o The local mobility anchor MUST establish a bi-directional tunnel o The local mobility anchor MUST establish a bi-directional tunnel
to the mobile access gateway and with the encapsulation mode set to the mobile access gateway and with the encapsulation mode set
to the negotiated mode for carrying the IPv4 payload traffic. to the negotiated mode for carrying the IPv4 payload traffic.
When using IPv6 transport, the encapsulation mode is IPv4-over- When using IPv6 transport, the encapsulation mode is IPv4-over-
IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When
using IPv4 transport, the encapsulation mode is as specified in using IPv4 transport, the encapsulation mode is as specified in
Section 4.0. Section 4.0.
o The local mobility anchor MUST create an IPv4 host route for o The local mobility anchor MUST create an IPv4 host route (or a
tunneling the packets received for the mobile node's home address platform specific equivalent function that sets up the forwarding)
associated with this mobility session. for tunneling the packets received for the mobile node's home
address 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 considerations from Section 5.3.3 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 If there is no Home Network Prefix option(s) [RFC-5213] present in
the request, but if the Binding Cache entry associated with this
request has IPv6 home network prefix(es), the local mobility
anchor MUST consider this as a request to extend lifetime only for
the IPv4 home address and not for the IPv6 home network
prefix(es). Hence, the local mobility anchor SHOULD release all
the IPv6 home network prefix(es) assigned to that mobile node and
for that specific attached interface. Similar considerations
apply for the case where there is no IPv4 Home Address option [ID-
DSMIP6] present in the request, but if the Binding Cache entry
associated with that request has both IPv4 home address and IPv6
home network prefix(es).
o The local mobility anchor MUST remove the previously created IPv4 o The local mobility anchor MUST remove the previously created IPv4
host route and the dynamically created bi-directional tunnel for host route (or the forwarding state) and the dynamically created
carrying the IPv4 payload traffic (if there are no other mobile bi-directional tunnel for carrying the IPv4 payload traffic (if
nodes for which the tunnel is being used). This will remove the there are no other mobile nodes for which the tunnel is being
routing state towards the mobile access gateway where the mobile used). This will remove the routing state towards the mobile
node was anchored prior to the handoff. access gateway where the mobile node was anchored prior to the
handoff.
o The local mobility anchor MUST create a bi-directional tunnel to o The local mobility anchor MUST create a bi-directional tunnel to
the mobile access gateway that sent the request (if there is no the mobile access gateway that sent the request (if there is no
existing bi-directional tunnel) and with the encapsulation mode existing bi-directional tunnel) and with the encapsulation mode
set to the negotiated mode for carrying the IPv4 payload traffic. set to the negotiated mode for carrying the IPv4 payload traffic.
An IPv4 host route for tunneling the packets received for the An IPv4 host route for tunneling the packets received for the
mobile node's IPv4 home address MUST also be added. 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
skipping to change at page 14, line 39 skipping to change at page 15, line 15
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 considerations from Section 5.3.5 of [RFC-5213] MUST be All the considerations from Section 5.3.5 of [RFC-5213] MUST be
applied. Additionally, for removing the IPv4 state as part of the applied. Additionally, for removing the IPv4 state as part of the
Binding Cache entry deletion, the IPv4 host route and the dynamically Binding Cache entry deletion, the IPv4 host route and the dynamically
created bi-directional tunnel for carrying the IPv4 payload traffic created bi-directional tunnel for carrying the IPv4 payload traffic
(if there are no other mobile nodes for which the tunnel is being (if there are no other mobile nodes for which the tunnel is being
used) MUST be removed. However, if the request is for a selective used) MUST be removed. However, if the request is for a selective
de-registration (IPv4-only or IPv6-only addresses), the Binding Cache de-registration (IPv4 home address only, or all the IPv6 home network
entry MUST not be deleted, only the respective states with respect prefixes), the Binding Cache entry MUST not be deleted, only the
those addresses MUST be deleted. respective states with respect to those addresses MUST be deleted.
3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC-5213]. the message as specified in Section 5.3.6 of [RFC-5213].
Additionally, the following considerations MUST be applied. Additionally, the following considerations MUST be applied.
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option [RFC- include at least one instance of Home Network Prefix option [RFC-
5213] in the Proxy Binding Acknowledgement message that it sends 5213] in the Proxy Binding Acknowledgement message that it sends
to the mobile access gateway. However, if the received Proxy to the mobile access gateway. However, if the received Proxy
Binding Update message has only the IPv4 Home Address option [ID- Binding Update message has only the IPv4 Home Address option [ID-
DSMIP6] and did not contain the Home Network Prefix option(s), DSMIP6] and did not contain the Home Network Prefix option(s),
then the local mobility anchor MUST NOT include any Home Network then the local mobility anchor MUST NOT include any Home Network
Prefix option(s) in the reply. Prefix option(s) in the reply. However, there MUST be at least
one instance of either the Home Network Prefix option [RFC-5213]
or the IPv4 Address Acknowledgement option [ID-DSMIP6] present in
the Proxy Binding Acknowledgement message.
o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be
present in the 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 [ID-DSMIP6] MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6]
corresponding to the IPv4 Home Address option [ID-DSMIP6] corresponding to the IPv4 Home Address option [ID-DSMIP6]
present in the request and with the IPv4 address value and the present in the request and with the IPv4 address value and the
prefix length fields in the option set to the corresponding prefix length fields in the option set to the corresponding
skipping to change at page 18, line 43 skipping to change at page 19, line 22
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. 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(The
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS_SUPPORT (The mobile node is mobile node is not authorized for IPv4 home address), the mobile
not authorized for IPv4 home address support), the mobile access access gateway SHOULD NOT send a Proxy Binding Update message
gateway SHOULD NOT send a Proxy Binding Update message including including the IPv4 Home Address option [ID-DSMIP6] till an
the IPv4 Home Address option [ID-DSMIP6] till an administrative administrative action is 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_IPV4_HOME_ADDRESS(The
(The mobile node is not authorized for the requesting IPv4 home mobile node is not authorized for the requesting IPv4 home
address), the mobile access gateway SHOULD NOT request for the address), the mobile access gateway SHOULD NOT request for the
same address again, but MAY request the local mobility anchor to same address again, but MAY request the local mobility anchor to
do the assignment of address by including exactly one instance if do the assignment of address by including exactly one instance of
IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
and the prefix length fields in the option set to ALL_ZERO value. and the prefix length fields in the option set to ALL_ZERO value.
o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6] o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6]
present in the received Proxy Binding Acknowledgement message, the present in the received Proxy Binding Acknowledgement message, the
mobile access gateway MUST NOT enable IPv4 support for the mobile mobile access gateway MUST NOT enable IPv4 support for the mobile
node and the rest of the considerations from this section can be node and the rest of the considerations from this section can be
skipped. skipped.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
skipping to change at page 20, line 4 skipping to change at page 20, line 30
o The mobile access gateway MUST set up the route for forwarding the o The mobile access gateway MUST set up the route for forwarding the
IPv4 packets received from the mobile node (using its IPv4 home IPv4 packets received from the mobile node (using its IPv4 home
address) through the bi-directional tunnel set up for that mobile address) through the bi-directional tunnel set up for that mobile
node. node.
o If there is an IPv4 Default-Router Address option present in the o If there is an IPv4 Default-Router Address option present in the
received Proxy Binding Acknowledgement message, the mobile access received Proxy Binding Acknowledgement message, the mobile access
gateway MAY configure this address on its interface and respond to gateway MAY configure this address on its interface and respond to
any ARP requests sent by the mobile node for resolving the any ARP requests sent by the mobile node for resolving the
hardware address of the default-router. hardware address of the default-router. It MAY also use this
address as the source address for any datagrams sent to the mobile
node and originated by the mobile access gateway itself. It MAY
also use this address in the DHCP Router option [RFC-2132] in the
DHCP messages.
o If there is an IPv4 DHCP Support Mode option present in the
received Proxy Binding Acknowledgement message and if the (S) flag
in the option is set to a value of 1, then the mobile access
gateway MUST function as a DHCP server for the mobile node. If
either the (S) flag in the option is set to a value of 0, or if
the option is not present in the request, then the mobile access
gateway MUST function as a DHCP Relay for the mobile node.
3.2.3.3. Binding Re-Registration and De-Registrations 3.2.3.3. Binding Re-Registration and De-Registrations
When sending a Proxy Binding Update either for extending the lifetime When sending a Proxy Binding Update either for extending the lifetime
of a mobility session or for de-registering the mobility session, the of a mobility session or for de-registering the mobility session, the
respective considerations from [RFC-5213] MUST be applied. respective considerations from [RFC-5213] MUST be applied.
Furthermore, the following additional considerations MUST also be Furthermore, the following additional considerations MUST also be
applied. applied.
o If there is an IPv4 home address assigned to the mobility session, o If there is an IPv4 home address assigned to the mobility session,
skipping to change at page 20, line 29 skipping to change at page 21, line 20
mask length. The (P) flag in the option MUST be set to 0. mask length. The (P) flag in the option MUST be set to 0.
o If there was no IPv4 home address requested in the initial Proxy o If there was no IPv4 home address requested in the initial Proxy
Binding Update message, but if it is determined that the IPv4 home Binding Update message, but if it is determined that the IPv4 home
address MUST be requested subsequently, then there MUST be exactly address MUST be requested subsequently, then there MUST be exactly
one instance of the IPv4 Home Address option [ID-DSMIP6] present one instance of the IPv4 Home Address option [ID-DSMIP6] present
in the Proxy Binding Update message. The IPv4 home address in the 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 option MUST be set to either ALL_ZERO or to a specific address
that is being requested. that is being requested.
o For performing selective de-registration of the IPv4-only home o For performing selective de-registration of IPv4 home address but
address, but still retaining the mobility session with all the still retaining the mobility session with all the IPv6 home
IPv6 home network prefixes, the Proxy Binding Update message with network prefixes, the Proxy Binding Update message with the
the lifetime value of 0 MUST NOT include any IPv6 Home Network lifetime value of 0 MUST NOT include any IPv6 Home Network Prefix
Prefix options(s) [RFC-5213]. It MUST include exactly one options(s) [RFC-5213]. It MUST include exactly one instance of
instance of the IPv4 Home Address option [ID-DSMIP6] with the IPv4 the IPv4 Home Address option [ID-DSMIP6] with the IPv4 home
home address and the prefix length fields in the option set to the address and the prefix length fields in the option set to the IPv4
IPv4 home address that is being deregistered. home address that is being de-registered. Similarly for selective
de-registration of all the IPv6 home network prefixes, the Proxy
Binding Update message MUST NOT include the IPv4 Home address
option, it MUST include a Home Network Prefix option for each of
the assigned home network prefixes assigned for that mobility
session and with the prefix value in the option set to that
respective prefix value.
o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present
if the same option(s) was not present in the initial Proxy Binding if the same option(s) was not present in the initial Proxy Binding
Update message. Otherwise considerations from [RFC-5213] with Update message. Otherwise considerations from [RFC-5213] with
respect to this option MUST be applied. respect to this option MUST be applied.
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
skipping to change at page 21, line 13 skipping to change at page 22, line 9
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. However, before forwarding the
packet, the mobile access gateway MUST ensure the source address
in the received packet is the address allocated for that mobile
node and that there is an active binding on the local mobility
anchor for that mobile node.
3.3. Mobility Options and Status Codes 3.3. Mobility Options and Status Codes
To support the IPv4 home address mobility feature, this specification To support the IPv4 home address mobility feature, this specification
defines the following new options and Status Codes. defines the following new options and Status Codes.
3.3.1. IPv4 Default-Router Address Option 3.3.1. IPv4 Default-Router Address Option
A new option, IPv4 Default-Router Address Option is defined for using A new option, IPv4 Default-Router Address Option is defined for using
it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
skipping to change at page 22, line 16 skipping to change at page 23, line 16
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.
3.3.2. Status Codes 3.3.2. IPv4 DHCP Support Mode
A new option, IPv4 DHCP Support Mode Option is defined for using it
in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
local mobility anchor to the mobile access gateway. This option can
be used for notifying the mobile access gateway, if it should
function as a DHCP Server or a DHCP Relay for the attached mobile
node.
The IPv4 DHCP Support Mode option has no alignment requirement. Its
format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 DHCP Support Mode Option
Type
IANA
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST
be set to 2.
Reserved (R)
This 15-bit field is unused for now. The value MUST be
initialized to 0 by the sender and MUST be ignored by the
receiver.
DHCP Support Mode (S)
A 1-bit field that specifies the DHCP support mode. This flag
indicates if the mobile access gateway should function as a
DHCP Server or a DHCP Relay for the attached mobile node. The
flag value of (0) indicates the mobile access gateway should
act as a DHCP Relay and the flag value of (1) indicates it
should act as a DHCP Server.
3.3.3. 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 [RFC-5213]. These values are Proxy Binding Acknowledgement message [RFC-5213]. These values are
to be allocated from the same numbering space, as defined in Section to be allocated from the same numbering space, as defined in Section
6.1.8 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
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network
prefix(es).
3.4. Supporting DHCP-Based Address Configuration 3.4. Supporting DHCP-Based Address Configuration
This section explains how DHCP-based address configuration support This section explains how DHCP-based address configuration support
can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It
explains the protocol operation, supported DHCP server deployment explains the protocol operation, supported DHCP server deployment
configurations and the protocol interactions between DHCP agents and configurations and the protocol interactions between DHCP agents and
mobility entities in each of the supported configurations. mobility entities in each of the supported configurations.
This specification supports the following two DHCP deployment This specification supports the following two DHCP deployment
configurations. configurations.
skipping to change at page 24, line 5 skipping to change at page 26, line 19
| |========| 4. Tunnel/Route Setup | |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA) |<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK |<------| | 7. DHCPACK
| | | | | |
* DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling
* (Step-2 to Step-4) may happen in parallel and in no specific order * (Step-2 to Step-4) may happen in parallel and in no specific order
* Tunnel/Route setup(Step-4) and the subsequent steps will happen in * Tunnel/Route setup(Step-4) and the subsequent steps will happen in
* in the specified order. * in the specified order.
Figure 4: Overview of DHCP Server located at Mobile Access Gateway Figure 5: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o When a mobile node attached to an access link sends a DHCPDISCOVER o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the
message [RFC-2131], the DHCP server co-located with the mobile DHCP server co-located with the mobile access gateway will trigger
access gateway will trigger the mobile access gateway to complete the mobile access gateway to complete the Proxy Mobile IPv6
the Proxy Mobile IPv6 signaling. This is the required interaction signaling. This is the required interaction between these two
between these two protocols. If the mobile access gateway is protocols. If the mobile access gateway is unable to complete the
unable to complete the Proxy Mobile IPv6 signaling, or, if the Proxy Mobile IPv6 signaling, or, if the local mobility anchor does
local mobility anchor does not assign an IPv4 address for the not assign an IPv4 address for the mobile node, the mobile access
mobile node, the mobile access gateway MUST NOT enable IPv4 gateway MUST NOT enable IPv4 support for the mobile node on that
support for the mobile node on that access link. 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 upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the DHCP server on the mobile access local mobility anchor, the DHCP server on the mobile access
gateway will send a DHCPOFFER message [RFC-2131] to the mobile gateway will send a DHCPOFFER message [RFC-2131] to the mobile
node. The offered address will the mobile node's IPv4 home node. The offered address will be the mobile node's IPv4 home
address, assigned by the local mobility anchor. The server address, assigned by the local mobility anchor. The server
address, 'siaddr' field of the DHCPOFFER message, will be set to address, 'siaddr' field of the DHCPOFFER message, will be set to
the mobile node's default-router address, or, to the address set the mobile node's default-router address. The DHCPOFFER message
in the FixedDHCPServerId configuration variable. The DHCPOFFER will be unicasted to the mobile node.
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 Any time the DHCP client goes into the DHCP RENEWING state [RFC- o Any time the mobile node goes into the DHCP RENEWING state [RFC-
2131], it simply unicasts the DHCPREQUEST message including the 2131], it simply unicasts the DHCPREQUEST message including the
assigned IPv4 home address in the 'requested IP address' option. assigned IPv4 home address in the 'requested IP address' option.
The DHCPREQUEST is sent to the address specified in 'server The DHCPREQUEST is sent to the address specified in 'server
identifier' field of the previously received DHCPOFFER and DHCPACK identifier' field of the previously received DHCPOFFER and DHCPACK
messages. messages.
o The DHCP server will send a DHCPACK to the mobile node to o The DHCP server will send a DHCPACK to the mobile node to
acknowledge the assignment of the committed IPv4 address. acknowledge the assignment of the committed IPv4 address.
IPv4 Home Address Renewal with a different DHCP server (After IPv4 Home Address Renewal with a different DHCP server (After
Handoff): Handoff):
When the DHCP client goes into the DHCP RENEWING state [RFC-2131], it When the mobile node goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile changed its point of attachment and is attached to a new mobile
access gateway, it is required that the mobile node updates the DHCP access gateway, it is required that the mobile node updates the DHCP
server address and uses the address of the DHCP server that is on co- server address and uses the address of the DHCP server that is co-
located on the new mobile access gateway. Any of the following located with the new mobile access gateway. Any of the following
approaches can be adopted for forcing the DHCP server address change. approaches can be adopted to ensure the mobile node uses the DHCP
server on the attached link.
1. The use of fixed DHCP server address on all DHCP servers 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 message to notify the address change 2. The use of FORCERENEW message to notify the address change
MN prev-MAG (DHCP-S) new-MAG (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 different address on different DHCP servers Figure 6: Address renewal with a different DHCP server
MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
| : | (discarding & timeout)
REBINDING--------->| 2. DHCPDISCOVER
|<---------------| 3. DHCPOFFER (IPv4 HoA)
|--------------->| 4. DHCPREQUEST(IPv4 HoA)
BOUND<-------------| 5. DHCPACK (IPv4 HoA)
| : |
Figure 5: Address renewal with a different DHCP server
o If a fixed DHCP server address is used by all the mobile access o If a fixed address such as the IPv4 default-router address of the
gateways in the Proxy Mobile IPv6 domain, the DHCPREQUEST message mobile node is used as the DHCP server Id on any of the links in
sent by the mobile node for renewing the address will be received that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the
by the new mobile access gateway on the attached link. The mobile mobile node for renewing the address will be received by the new
access gateway after completing the Proxy Mobile IPv6 signaling mobile access gateway on the attached link. The mobile access
and upon acquiring the IPv4 home address of the mobile node will gateway after completing the Proxy Mobile IPv6 signaling and upon
return the address in the DHCPACK message. However, if the mobile acquiring the IPv4 home address of the mobile node will return the
access gateway is unable to complete the Proxy Mobile IPv6 address in the DHCPACK message. However, if the mobile access
signaling or is unable to acquire the same IPv4 address as gateway is unable to complete the Proxy Mobile IPv6 signaling or
requested by the mobile node, it will send a DHCPNACK message is unable to acquire the same IPv4 address as requested by the
[RFC-2131] to the mobile node, as shown in Figure 5-1). mobile node, it will send a DHCPNACK message [RFC-2131] to the
mobile node, as shown in Figure 6-1).
o If the mobile access gateway on the access link receives any DHCP o If the mobile access gateway on the access link receives any DHCP
messages from the mobile node unicasted to a server address that messages from the mobile node unicasted to a server address that
is not locally configured, the mobile access gateway can unicast is not locally configured, the mobile access gateway can unicast
FORCERENEW message [RFC-3203] to the mobile node as shown in FORCERENEW message [RFC-3203] to the mobile node as shown in
Figure 5-2). This will force the mobile node to update the DHCP Figure 6-2). This will force the mobile node to update the DHCP
server address with the address of the mobile access gateway on server address with the address of the mobile access gateway on
the new link. the new link. However, if the FORCERENEW message [RFC-3203] is
also not supported by the DHCP server on the mobile access
o If a fixed IPv4 address is not used by all the DHCP servers in the gateway, then that DHCPREQUEST message can be ignored. This will
Proxy Mobile IPv6 domain and if the FORCERENEW message [RFC-3203] force the mobile node to enter the DHCP REBINDING state [RFC-2131]
is also not supported by the DHCP server on the mobile access and start the DHCPDISCOVER phase again.
gateway, then that DHCPREQUEST message should be ignored. This
will force the mobile node to enter the DHCP REBINDING state [RFC-
2131] and start the DHCPDISCOVER phase, as shown in Figure 5-3).
Additional Operation: Additional Operation:
o If at any point the mobile access gateway fails to extend the o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor, it MUST send an binding lifetime with the local mobility anchor for the mobile
unsolicited DHCPNAK message [RFC-2131] to the mobile node. node's IPv4 address, it can send the unicast FORCERENEW message
[RFC-3203] to the mobile node to force it to change its DHCP state
to the RENEW state. Furthermore, it MUST remove forwarding for
the mobile node's IPv4 home address.
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 agent is co-located with each mobile access gateway. A
server is located somewhere in the Proxy Mobile IPv6 domain (e.g., is DHCP server is located somewhere in the Proxy Mobile IPv6 domain
co-located with the local mobility anchor). Figure 6 shows the (e.g., is co-located with the local mobility anchor). Figure 7 shows
sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA)
| |========| | 3. Tunnel/Route Setup* | |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R |------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK via DHCP-R |<------|<--------------| 7. DHCPACK via DHCP-R
| | | | | |
* The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the * The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the
DHCPDISCOVER phase (Step-4) may occur in any order. However, DHCPDISCOVER phase (Step-4) may occur in any order. However,
the DHCPOFFER (Step-5) and the following steps will occur in the DHCPOFFER (Step-5) and the following steps will occur in
the specified order and after the Tunnel/Route Setup (Step-3). the specified order and after the Tunnel/Route Setup (Step-3).
Figure 6: Overview of the DHCP relay located at mobile access gateway Figure 7: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o When the mobile access gateway receives a DHCPDISCOVER message o 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 can check if there is already an assigned
the IPv4 home address for the mobile node from the local mobility IPv4 home address for the mobile node from the local mobility
anchor. anchor. If there is no assigned IPv4 home address assigned for
that mobile node, the mobile access gateway has to complete the
o If the IPv4 home address is not yet assigned by the local mobility Proxy Mobile IPv6 signaling with the local mobility anchor by
anchor, the mobile access gateway MUST send a Proxy Binding Update sending a Proxy Binding Update message.
for that.
o If the IPv4 home address is not assigned to the mobile node by the o If the Proxy Binding Update message is rejected by the local
local mobility anchor due to administrative policy or resource mobility anchor for any reason, the local mobility anchor will
limitation, it MUST discard the DHCPDISCOVER messages from the discard the DHCPDISCOVER messages from the mobile node.
mobile node.
o Otherwise, it MUST add the DHCP relay agent information option o If the Proxy Binding Update message is accepted by the local
[RFC-3046] to the DHCPDISCOVER message. The assigned IPv4 home mobility anchor and if there is an assigned IPv4 home address for
address (32-bit full address) is included in the Agent Remote ID the mobile node, the DHCP messages will be forwarded to the DHCP
Sub-option of the DHCP relay agent information option. This sub- 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 The DHCP relay agent on the mobile access gateway will add the
DHCP server, it MUST verify whether the DHCP server offers the DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER
correct IPv4 home address which is indicated in the Agent Remote message. The assigned IPv4 home address will be included in the
ID Sub-option of the DHCPDISOCVERY. If the DHCP server offers the Agent Remote ID Sub-option of the DHCP relay agent information
different address from the expected address, the mobile access option. This sub-option is used as a hint for requesting the DHCP
gateway MUST drop the DHCPOFFER. server to allocate that specific IPv4 address.
o After the successful relaying the DHCPOFFER, the mobile access o On receiving a DHCPOFFER message from the DHCP server, the mobile
gateway acts as a regular DHCP relay agent as [RFC-2131]. access gateway will ensure the assigned address is the address
that is currently assigned to the mobile node by the local
mobility anchor. If this address is different from what is
assigned to the mobile node, then the mobile access gateway will
drop the DHCPOFFER message and an administrative error message can
be logged.
o As shown in Figure 6, the DHCP messages MAY be sent across an o When the DHCP messages are sent over administrative boundaries,
administrative boundaries. The operators MUST ensure to secure the operators needs to ensure these messages are secured. All the
these messages. All the DHCP messages relayed by the mobile DHCP messages relayed by the mobile access gateway can be tunneled
access gateway can be tunneled over the local mobility anchor if to the local mobility anchor if needed. Alternatively, if the
needed. Alternatively, if the networks in the Proxy Mobile IPv6 network in the Proxy Mobile IPv6 domain is secure enough, the
domain are secured enough, the mobile access gateway just relays mobile access gateway can just relay the DHCP messages to the
the DHCP messages to the server without the tunnel. For doing server. To achieve this, all the mobile access gateways needs to
this, all the mobile access gateway MUST have the route toward the have route towards the DHCP server.
DHCP server. More remarks can be found in Section 7.
IPv4 Home Address Renewal to the same DHCP server: (No Handover) IPv4 Home Address Renewal to the same DHCP server: (No Handover)
o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131], o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
it directly unicasts DHCPREQUEST message to the DHCP server. The directly unicasts DHCPREQUEST message to the DHCP server. The
DHCP relay agent cannot receive the DHCPREQUEST for renewing DHCP relay agent may not detect these unicasted DHCPREQUEST
addresses. Thus, one of following operations is required. messages for renewing the address. Thus, one of following
operations is required.
* The DHCP relay agent SHOULD intercept all the DHCP packets * The DHCP relay agent can intercept all the DHCP packets
regardless of the destination address. Since the link between regardless of the destination address. Since the link between
a mobile node and a mobile access gateway is the point-to-point a mobile node and a mobile access gateway is the point-to-point
link, it is possible to check the DHCP packets at the interface link, the mobile access gateway will be in path for all the
by enabling the promiscuous mode. messages.
* The cost of monitoring packets is not negligible. Therefore, * The DHCP relay agent can use the DHCP Server Identifier
The DHCP relay agent MAY use the DHCP Server Identifier Override Sub-option [RFC-5107] to be in path for all the DHCP
Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for message flows. The DHCP client uses the DHCP server address
the address renewal. The DHCP client uses the DHCP server which is overridden by the DHCP relay agent address as a
address which is overridden by the DHCP relay agent address as destination address of DHCPREQUEST. The DHCP Server Identifier
a destination address of DHCPREQUEST. The DHCP Server Override Sub-option is recommended only when the fixed DHCP
Identifier Override Sub-option is recommended only when the relay address is configured on all the mobile access gateways.
Virtual DHCP address is configured on all the mobile access Otherwise, the DHCP relay agent address is changed when the
gateways. Otherwise, the DHCP relay agent address is changed mobile node changes the attached mobile access gateway.
when the mobile node changes the attached mobile access
gateway. As a result, the DHCP relay agent MUST monitor DHCP
packets by force as described above.
o Once the DHCP relay agent intercepts the DHCPREQUEST from the o The DHCP Relay agent on detecting the DHCPREQUEST message from the
mobile node, it MUST verify the requesting IPv4 home address mobile node, will verify if the address in the DHCPREQUEST message
stored in the DHCPREQUEST message. The verification is operated is the address assigned by the local mobility anchor for that
by checking it with the binding update list for the mobile node. mobile node. If the requesting IPv4 home address is not
If the requesting IPv4 home address is not registered to the local registered to the local mobility anchor, the mobile access gateway
mobility anchor, the mobile access gateway MUST NOT relay the will drop the packet. Once the address verification is
DHCPREQUEST and MUST discard it. successfully completed, the DHCP relay agent will forward the
DHCPREQUEST message to the DHCP server.
o If the address verification is successfully completed, the DHCP IPv4 Address Release Triggers from the mobile node:
relay agent SHOULD forward the DHCPREQUEST to the DHCP server.
o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC-2131]. When the mobile
access gateway detects the DHCPRELEASE message sent by the mobile
node and for releasing its assigned IPv4 home address, the mobile
access gateway should consider this as a trigger for de-
registering the mobile node's IPv4 home address. It MUST apply
the considerations specified in section 3.2.3.3 for performing the
de-registration procedure. However, this operation should not
release any IPv6 home network prefix(es) assigned to the mobile
node.
Additional Operations: Additional Operations:
o If the mobile access gateway sends Proxy Binding Update for the o If at any point the mobile access gateway fails to extend the
IPv4 home address and receives the unsuccessful Proxy Binding binding lifetime with the local mobility anchor for the mobile
Acknowledgement (as indicated by the error codes), it MUST send node's IPv4 address, it can send the unicast FORCERENEW message
unsolicited DHCPNACK for the invalid IPv4 home address to the [RFC-3203] to the mobile node to force it to change its DHCP state
mobile node. to RENEW state. Furthermore, it MUST remove forwarding for the
mobile node IPv4 home address.
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.
IPv4-Proxy-CoA IPv4-LMAA IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + | | + - - - - - - + |
+--+ +---+ / \ +---+ +--+ +--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+ +--+ +---+ \ / +---+ +--+
+ - - - - - - + + - - - - - - +
Figure 7: IPv4 Transport Network Figure 8: IPv4 Transport Network
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.
skipping to change at page 32, line 15 skipping to change at page 34, line 15
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
To support the IPv4 Transport Support feature the mobile node's To support the IPv4 Transport Support feature the mobile node's
policy profile, specified in Section 6.2 of [RFC-5213] MUST be policy profile, specified in Section 6.2 of [RFC-5213] MUST be
extended with the following additional fields. This are mandatory extended with the following additional fields. These are mandatory
fields of the policy profile required for supporting this feature. fields of the policy profile required for supporting this feature.
o A flag indicating whether or not IPv4 transport should be used.
The value of this flag can vary at different mobile access
gateways. The specific details on how this flag is maintained on
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. signaling messages received over IPv4 transport.
4.1.3.1. Processing Proxy Binding Updates 4.1.3.1. Processing Proxy Binding Updates
o If the received Proxy Binding Update message (encapsulated in IPv4 o If the received Proxy Binding Update message was sent encapsulated
or IPv4-UDP header) is protected using IPsec ESP header, then the in IPv4 or IPv4-UDP header, the message MUST be authenticated
message MUST be authenticated as described in Section 4 of [RFC- after removing the outer encapsulation (IPv4 or IPv4-UDP) header.
5213]. However, if the IPv4 packet is not protected using IPsec Considerations from Section 4 of [RFC-5213] MUST be applied for
ESP header, then the message MUST be authenticated after removing authenticating and authorizing the request.
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 encapsulation (IPv4 or IPv4-UDP) header. removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in
the request and if the outer encapsulation header is IPv4-UDP, the request and if the outer encapsulation header is IPv4-UDP,
then the NAT presence detection procedure specified in Section then the NAT presence detection procedure specified in Section
4.1.3.3 MUST be used for detecting the NAT in the path. 4.1.3.3 MUST be used for detecting the NAT in the path.
skipping to change at page 33, line 4 skipping to change at page 34, line 45
removing the outer encapsulation (IPv4 or IPv4-UDP) header. removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in
the request and if the outer encapsulation header is IPv4-UDP, the request and if the outer encapsulation header is IPv4-UDP,
then the NAT presence detection procedure specified in Section then the NAT presence detection procedure specified in Section
4.1.3.3 MUST be used for detecting the NAT in the path. 4.1.3.3 MUST be used for detecting the NAT in the path.
o Upon accepting the request, the local mobility anchor MUST set up o Upon accepting the request, the local mobility anchor MUST set up
an IPv4 bi-directional tunnel to the mobile access gateway. The an IPv4 bi-directional tunnel to the mobile access gateway. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
The encapsulation mode MUST be determined from the below The encapsulation mode MUST be determined from the below
considerations. considerations.
* If the received Proxy Binding Update message was sent with IPv4 * If the received Proxy Binding Update message was sent with IPv4
encapsulated header, then the encapsulation mode for the bi- encapsulated header, then the encapsulation mode for the bi-
directional tunnel MUST be set to IPv4. Otherwise, the directional tunnel MUST be set to IPv4. Otherwise, the
following considerations apply. following considerations apply.
* If a NAT is detected on the path, or if the (F) flag in the * If NAT is detected on the path, or if the (F) flag in the
received Proxy Binding Update message is set to the value of 1, received Proxy Binding Update message is set to the value of 1,
then the encapsulation mode MUST be set to IPv4-UDP. Otherwise then the encapsulation mode MUST be set to IPv4-UDP. Otherwise
the encapsulation mode MUST be set to IPv4. the encapsulation mode MUST be set to IPv4.
* If the (T) flag in the Proxy Binding Update message is set to * If NAT is not detected on the path and if the (F) flag in the
value of 1, then the encapsulation mode MUST be set to IPv4- received Proxy Binding Update message is set to the value of 1,
UDP-TLV. but if the configuration flag,
AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
0, then the local mobility anchor MUST reject the request with
the Status field value set to 129 (Administratively
prohibited).
* If the (T) flag [ID-DSMIP6] in the Proxy Binding Update message
is set to value of 1, then the encapsulation mode MUST be set
to IPv4-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 IPv4 the received Proxy Binding Update message was encapsulated in an IPv4
packet or as a payload in the UDP header of an IPv4 packet, the packet or as a payload in the UDP header of an IPv4 packet, the
following additional considerations MUST be applied. following additional considerations MUST be applied.
o The Proxy Binding Acknowledgement message MUST be encapsulated in o The Proxy Binding Acknowledgement message MUST be encapsulated in
an IPv4 packet. However, if the received Proxy Binding Update an IPv4 packet. However, if the received Proxy Binding Update
message was encapsulated in the UDP header of an IPv4 packet, then message was sent encapsulated in the UDP header of an IPv4 packet,
the message MUST be encapsulated in the UDP header of an IPv4 then the Proxy Binding Acknowledgement message MUST be
packet. encapsulated in the UDP header of an IPv4 packet.
o The source address in the IPv4 header of the message MUST be set o The source address in the IPv4 header of the message MUST be set
to the destination IPv4 address of the received request. to the destination IPv4 address of the received request.
o If the mobile access gateway and the local mobility anchor are o If the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security using globally routable IPv4 addresses and if there is a security
associated that is based of IPv4 addresses, then the encapsulated associated that is based of IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
MUST be protected using IPsec ESP [RFC-4301] mode. There is no MUST be protected using IPsec ESP [RFC-4301] mode. There is no
need to apply IPsec ESP header to the IPv6 packet. In all other need to apply IPsec ESP header to the IPv6 packet. In all other
cases, the Proxy Binding Acknowledgement message MUST be protected cases, the Proxy Binding Acknowledgement message MUST be protected
using IPsec prior to the IPv4 or IPv4-UDP encapsulation. using IPsec prior to the IPv4 or IPv4-UDP encapsulation.
o The NAT Detection option [ID-DSMIP6] MUST be present only if there o The NAT Detection option [ID-DSMIP6] MUST be present only if there
is a IPv4 Care-of Address option [ID-DSMIP6] present in the is an IPv4 Care-of Address option [ID-DSMIP6] present in the
received Proxy Binding Update and if the NAT detection procedure received Proxy Binding Update message and if the NAT detection
resulted in detecting a NAT on path. In all other cases, the procedure resulted in detecting a NAT on path. However, if the
option MUST NOT be present. received Proxy Binding Update message was not sent encapsulated in
IPv4 UDP header, then the option MUST NOT be present.
Furthermore, in all other cases, the option MUST NOT be present.
o The IPv4 DHCP Support Mode option MAY be present. If this option
is not present, the mobile access gateway will enable the default
behavior and function as a DHCP Relay for the mobile node.
o The format of the Proxy Binding Acknowledgement message o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 packet and protected using IPv6 security encapsulated in an IPv4 packet and protected using IPv6 security
association. The UDP header MUST be present only if the received association. The UDP header MUST be present only if the received
Proxy Binding Update message was sent with IPv4-UDP encapsulation Proxy Binding Update message was sent with IPv4-UDP encapsulation
header. 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) /*Optional*/ UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/
/* IPv6 PBA Packet protected with ESP header */ /* IPv6 PBA Packet protected with ESP header */
Figure 8: Proxy Binding Acknowledgment (PBA) Message encapsulated
in IPv4 header
o The format of the Proxy Binding Acknowledgement message
encapsulated in an IPv4 packet and protected using IPv4 security
association.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
ESP Header
UDP header (sport=DSMIP_PORT, dport= pbu_sport) /* Optional */
/* IPv6 PBA Packet protected with no ESP header */
Figure 9: Proxy Binding Acknowledgment (PBA)Message encapsulated Figure 9: Proxy Binding Acknowledgment (PBA)Message encapsulated
in IPv4 ESP header in IPv4 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 and if the received Proxy
will send the Proxy Binding Update messages encapsulated in the IPv4- Binding Update message was sent encapsulated in IPv4 UDP header, the
UDP packet. On receiving this Proxy Binding Update packet local mobility anchor performs the NAT Presence Detection as
encapsulated in an IPv4-UDP packet, the local mobility anchor if it specified below.
detects a NAT on the path, will send the Proxy Binding Acknowledgment
message with the NAT Detection Option. The presence of this option On receiving the Proxy Binding Update message encapsulated in an IPv4
in the Proxy Binding Acknowledgment is an indication to the mobile UDP packet, the local mobility anchor, if it detects a NAT on the
access gateway about the presence of NAT in the path. On detecting path, will send the Proxy Binding Acknowledgment message with the NAT
any NAT in the path, both the local mobility anchor and the mobile Detection Option. The presence of this option in the Proxy Binding
access gateway MUST set the encapsulation mode of the tunnel to IPv4- Acknowledgment is an indication to the mobile access gateway about
UDP-based encapsulation. The specific details around the NAT the presence of NAT in the path. On detecting any NAT in the path,
detection and the related logic are described in DSMIPv6 both the local mobility anchor and the mobile access gateway will set
specification [ID-DSMIP6]. the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation.
The specific details around the NAT detection and the related logic
are described in DSMIPv6 specification [ID-DSMIP6].
However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to a value of 0, the
mobile access gateway will not use IPv4 UDP encapsulation for Proxy
Binding Update messages and hence the local mobility anchor will not
perform this NAT Presence Detection procedure on these messages that
are not sent in IPv4 UDP packet.
4.1.4. Routing Considerations 4.1.4. Routing Considerations
4.1.4.1. Forwarding Considerations 4.1.4.1. Forwarding Considerations
Forwarding Packets to the Mobile Node: Forwarding Packets to the Mobile Node:
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 36, line 35 skipping to change at page 38, line 36
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 of [RFC-5213]. However, if the mobile access
IPv4-only access network, the following additional considerations gateway is in an IPv4-only access network, the following additional
MUST be applied. considerations MUST be applied.
o The Proxy Binding Update message MUST be encapsulated in an IPv4 o The Proxy Binding Update message MUST be encapsulated in an IPv4
packet. However, if the value of the configuration variable, packet. However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
Binding Update message MUST be encapsulated in an UDP header of an Binding Update message MUST be encapsulated in an UDP header of an
IPv4 packet. IPv4 packet.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [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 is
(encapsulated in IPv4 or IPv4 UDP packet) is protected using IPsec encapsulated in IPv4 or IPv4 UDP packet, the message MUST be
ESP header, then the message MUST be authenticated as described in
Section 4 of [RFC-5213]. However, if the IPv4 packet is not
protected using IPsec ESP header, then the message MUST be
authenticated after removing the outer IPv4 or IPv4-UDP header. authenticated after removing the outer IPv4 or IPv4-UDP header.
Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the message.
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 mobile access gateway MUST set up
an IPv4 bi-directional tunnel to the mobile access gateway. The an IPv4 bi-directional tunnel to the local mobility anchor. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA.
The encapsulation mode MUST be determined from the below The encapsulation mode MUST be determined from the below
considerations. considerations.
* The encapsulation mode for the bi-directional tunnel MUST be * The encapsulation mode for the bi-directional tunnel MUST be
set to IPv4. However, if the value of the configuration set to IPv4. However, if the value of the configuration
variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, variable, UseIPv4UDPEncapForSignalingMessages, is set to 1,
then the following considerations MUST be applied. 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 and if the value of the
mode for the tunnel MUST be set to IPv4-UDP. Otherwise the configuration flag, UseIPv4UDPEncapForSignalingMessages, is set
encapsulation mode MUST be set to IPv4. to value of 1, then the encapsulation mode for the tunnel MUST
be set to IPv4-UDP. Otherwise the 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.
skipping to change at page 38, line 29 skipping to change at page 40, line 32
o The format of the Proxy Binding Update message encapsulated in an o The format of the Proxy Binding Update message encapsulated in an
IPv4 or IPv4-UDP packet with no IPsec protection: IPv4 or IPv4-UDP packet with no IPsec protection:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 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 (PBU) message encapsulated in IPv4 Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4
UDP header UDP header
o The format of the Proxy Binding Update message encapsulated in an
IPv4 UDP packet and with IPsec protection on the encapsulated
packet:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
ESP Header
UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/
/* IPv6 PBU Packet protected with no ESP header */
Figure 12: Proxy Binding Update (PBU) message encapsulated in IPv4
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
use of EnableMAGLocalRouting flag. use of EnableMAGLocalRouting flag.
IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */ [TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA) IPv6 header (src= CN, dst= MN-HOA)
OR OR
IPv4 header (src= CN, dst= IPv4 MN-HoA) IPv4 header (src= CN, dst= IPv4 MN-HoA)
Figure 13: Tunneled IPv4 Packet from LMA to MAG Figure 12: Tunneled IPv4 Packet from LMA to MAG
o Forwarding Packets received from the bi-directional tunnel: o Forwarding Packets received from the bi-directional tunnel:
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.
5. Protocol Configuration Variables 5. Protocol Configuration Variables
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 AcceptForcedIPv4UDPEncapsulationRequest
This flag indicates whether or not the local mobility anchor This flag indicates whether or not the local mobility anchor
should accept IPv4 UDP encapsulation support for the mobile node's should accept IPv4 UDP encapsulation request for the mobile node's
data traffic, if there is NAT detected in the path. data traffic, even if there is no NAT detected in the path.
The default value for this flag is set to value of 1, indicating The default value for this flag is set to value of 0, indicating
that the local mobility anchor MUST enable IPv4 UDP encapsulation that the local mobility anchor MUST not accept IPv4 UDP
support on detecting NAT in the path. encapsulation request when NAT is not detected 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 1, the local
mobility anchor MUST NOT enable IPv4 UDP encapsulation support. mobility anchor MUST accept IPv4 UDP encapsulation request even
when NAT is not detected in the path.
5.2. Mobile Access Gateway - Configuration Variables 5.2. Mobile Access Gateway - Configuration Variables
The mobile access gateway MUST allow the following variables to be The mobile access gateway MUST allow the following variables to be
configured by the system management. The configured values for these configured by the system management. The configured values for these
protocol variables MUST survive server reboots and service restarts. protocol variables MUST survive server reboots and service restarts.
UseIPv4UDPEncapForSignalingMessages UseIPv4UDPEncapForSignalingMessages
This flag indicates whether or not the mobile access gateway This flag indicates whether or not the mobile access gateway
skipping to change at page 41, line 21 skipping to change at page 44, line 5
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
UseIPv4UDPEncapForSignalingMessages is set to a value of 1. UseIPv4UDPEncapForSignalingMessages is set to a value of 1.
5.3. Proxy Mobile IPv6 Domain - Configuration Variables
All the mobile entities (local mobility anchors and mobile access
gateways) in a Proxy Mobile IPv6 domain MUST allow the following
variables to be configured by the system management. The configured
values for these protocol variables MUST survive server reboots and
service restarts. These variables MUST be globally fixed for a given
Proxy Mobile IPv6 domain resulting in the same values being enforced
on all the mobility entities in that domain.
FixedDHCPServerId
This variable indicates the DHCP server id that all the DHCP
servers co-located with the mobile access gateways SHOULD
configure in that Proxy Mobile IPv6 domain. If this variable is
initialized to ALL_ZERO value, it implies the use of fixed address
is not enabled for that Proxy Mobile IPv6 domain.
6. IANA Considerations 6. IANA Considerations
This document defines a new Mobility Header option, IPv4 Default This document defines a new Mobility Header option, IPv4 Default
Router Address option. This option is described in Section 3.3.1. Router Address option. This option is described in Section 3.3.1.
The Type value for this option needs to be assigned from the same The Type value for this option needs to be assigned from the same
numbering space as allocated for the other mobility options, as numbering space as allocated for the other mobility options, as
defined in [RFC-3775]. defined in [RFC-3775].
This document also defines new Binding Acknowledgement status values, This document also defines new Binding Acknowledgement status values,
as described in Section 3.3.2. The status values MUST be assigned as described in Section 3.3.2. The status values MUST be assigned
skipping to change at page 44, line 37 skipping to change at page 46, 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 Charles Perkins, Jonne Soinnen, Julien Laganier, Mohana Thanks to Behcet Sarikaya, Charles Perkins, Jonne Soinnen, Julien
Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati and Zu Qiang Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy
for their helpful review of this document. Touati and Zu Qiang for their helpful review of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
skipping to change at page 45, line 16 skipping to change at page 47, line 16
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.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
November 2007. November 2007.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-05.txt, July 2008. draft-ietf-mext-nemo-v4traversal-06.txt, November 2008.
10.2. Informative References 10.2. Informative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor
2131, March 1997. Extensions", RFC 2132, 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.
 End of changes. 93 change blocks. 
328 lines changed or deleted 413 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/