draft-ietf-netlmm-pmip6-ipv4-support-18.txt   rfc5844.txt 
NETLMM Working Group R. Wakikawa Internet Engineering Task Force (IETF) R. Wakikawa
Internet-Draft Toyota ITC Request for Comments: 5844 Toyota ITC
Intended status: Standards Track S. Gundavelli Category: Standards Track S. Gundavelli
Expires: August 16, 2010 Cisco ISSN: 2070-1721 Cisco
February 12, 2010 May 2010
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-18.txt
Abstract Abstract
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to the Proxy Mobile IPv6 protocol
adding IPv4 protocol support. The scope of IPv4 protocol support is for adding IPv4 protocol support. The scope of IPv4 protocol support
two-fold: 1) enable IPv4 home address mobility support to the mobile is two-fold: 1) enable IPv4 home address mobility support to the
node. 2) allow the mobility entities in the Proxy Mobile IPv6 domain mobile node, and 2) allow the mobility entities in the Proxy Mobile
to exchange signaling messages over an IPv4 transport network. IPv6 domain to exchange signaling messages over an IPv4 transport
network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 16, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5844.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 4
1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 6 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 9
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 9
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 10
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 17 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 17 3.1.4. ECN and Payload Fragmentation Considerations . . . . . 16
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 3.2.1. Extensions to Binding Update List Entry . . . . . . . 17
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 Gateway . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 22
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 23
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25
3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27 3.3.4. IPv4 DHCP Support Mode Option . . . . . . . . . . . . 25
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 26
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 29 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 27
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 30 Gateway . . . . . . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . . . 33 Gateway . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 33
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 35
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 37
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 37
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 37
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 37
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 41 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43 4.2.1. Extensions to Binding Update List Entry . . . . . . . 40
4.2.1. Extensions to Binding Update List Entry . . . . . . . 43 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 43 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 43
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 45 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 43
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 45 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 43
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 46 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44
5.1. Local Mobility Anchor - Configuration Variables . . . . . 44
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 47 5.2. Mobile Access Gateway - Configuration Variables . . . . . 44
5.1. Local Mobility Anchor - Configuration Variables . . . . . 47
5.2. Mobile Access Gateway - Configuration Variables . . . . . 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 48
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-
IPv6-only or in dual-stack mode and additionally the network between only, IPv6-only, or dual-stack mode, and the network between the
the mobile access gateway and a local mobility anchor may be an IPv4 mobile access gateway and a local mobility anchor may be an IPv4 or
or an IPv6 network. It is also reasonable to expect the same an IPv6 network. It is also reasonable to expect the same mobility
mobility infrastructure in the Proxy Mobile IPv6 domain to provide infrastructure in the Proxy Mobile IPv6 domain to provide mobility to
mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode the mobile nodes operating in IPv4, IPv6, or in dual mode and whether
and whether the transport network is IPv4 or IPv6 network. The the transport network is IPv4 or IPv6 network. The motivation and
motivation and scope of IPv4 support in Mobile IPv6 is summarized in scope of IPv4 support in Mobile IPv6 is summarized in [RFC4977], and
[RFC4977] and all those requirements apply to Proxy Mobile IPv6 all those requirements apply to Proxy Mobile IPv6 protocol as well.
protocol as well.
The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for
providing IPv6 home address mobility support to a mobile node in a providing IPv6 home address mobility support to a mobile node in a
Proxy Mobile IPv6 domain. The protocol requires IPv6 transport Proxy Mobile IPv6 domain. The protocol requires IPv6 transport
network between the mobility entities. The extensions defined in network between the mobility entities. The extensions defined in
this document extends IPv4 support to the Proxy Mobile IPv6 protocol this document specify IPv4 support to the Proxy Mobile IPv6 protocol
[RFC5213]. [RFC5213].
The scope of IPv4 support in Proxy Mobile IPv6 includes the support The scope of IPv4 support in Proxy Mobile IPv6 includes the support
for the following two features: for the following two features:
o IPv4 Home Address Mobility Support: A mobile node which is dual- o IPv4 Home Address Mobility Support: A mobile node that is dual-
stack or IPv4-only enabled will be able to obtain an IPv4 address stack or IPv4-only enabled will be able to obtain an IPv4 address
and be able to use that address from any of the access networks in and be able to use that address from any of the access networks in
that Proxy Mobile IPv6 domain. The mobile node is not required to that Proxy Mobile IPv6 domain. The mobile node is not required to
be allocated or assigned an IPv6 address to enable IPv4 home be allocated or assigned an IPv6 address to enable IPv4 home
address support. address support.
o IPv4 Transport Network Support: The mobility entities in the Proxy o IPv4 Transport Network Support: The mobility entities in the Proxy
Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
signaling messages over an IPv4 transport. signaling messages over an IPv4 transport.
These two features, the IPv4 Home Address Mobility support and the These two features, the IPv4 home address mobility support and the
IPv4 transport support features, are independent of each other and IPv4 transport support features, are independent of each other, and
deployments may choose to enable any one or both of these features as deployments may choose to enable either one or both of these features
required. as required.
Figure 1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport Figure 1 shows a typical Proxy Mobile IPv6 domain with an IPv4
network and with IPv4 enabled mobile nodes. The terms used in this transport network and with IPv4 enabled mobile nodes. The terms used
illustration are explained in the Terminology section. in this illustration are explained in the Terminology section.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA
| | | |
\\ //\\ \\ //\\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
skipping to change at page 5, line 28 skipping to change at page 4, line 32
\\ // \\ \\ // \\
\\ // \\ \\ // \\
IPv4-Proxy-CoA --> | | <-- Proxy-CoA IPv4-Proxy-CoA --> | | <-- Proxy-CoA
+----+ +----+ +----+ +----+
|MAG1|-----{MN2} |MAG2| |MAG1|-----{MN2} |MAG2|
+----+ | +----+ +----+ | +----+
(MN-HoA) | | | <-- (MN-HoA) (MN-HoA) | | | <-- (MN-HoA)
(IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA) (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA)
{MN1} {MN3} {MN1} {MN3}
Figure 1: IPv4 support for Proxy Mobile IPv6 Figure 1: IPv4 Support for Proxy Mobile IPv6
1.1. Stated Assumptions 1.1. Stated Assumptions
The following are the system and configuration requirements from the The following are the system and configuration requirements from the
mobility entities in the Proxy Mobile IPv6 domain for supporting the mobility entities in the Proxy Mobile IPv6 domain for supporting the
extensions defined in this document. extensions defined in this document.
o Both the mobility entities, the local mobility anchor and the o Both the mobility entities, the local mobility anchor and the
mobile access gateway are dual stack (IPv4/IPv6) enabled. mobile access gateway are dual-stack (IPv4/IPv6) enabled.
Irrespective of the type of transport network (IPv4 or IPv6) Irrespective of the type of transport network (IPv4 or IPv6)
separating these two entities, the mobility signaling is always separating these two entities, the mobility signaling is always
based on Proxy Mobile IPv6 [RFC5213]. based on Proxy Mobile IPv6 protocol [RFC5213].
o A deployment where a mobile access gateway uses an IPv4 private o A deployment where a mobile access gateway uses an IPv4 private
address with NAT [RFC3022] translation devices in path to a local address with NAT [RFC3022] translation devices in the path to a
mobility anchor is not supported by this specification. local mobility anchor is not supported by this specification.
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 the enabled configuration for a mobile node,
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 the mobile node should be able to obtain IPv4-only, IPv6-only, or
address(es) for its interface and furthermore achieve mobility both IPv4 and IPv6 addresses for its interface and furthermore
support for those addresses. achieve mobility 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, need be enabled. However, the respective protocol(s) support,
such as IPv4 or IPv6 packet forwarding, must be enabled on the such as IPv4 or IPv6 packet forwarding, must be enabled on the
access link between the mobile node and 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 standard IPv4 address its IPv4 address configuration using standard IPv4 address
configuration mechanisms such as DHCP [RFC2131], IPCP [RFC1332], configuration mechanisms such as DHCP [RFC2131], IP Control
IKEv2 [RFC4306] or static address configuration. However, the Protocol (IPCP) [RFC1332], Internet Key Exchange Protocol version
details on how IPCP or IKEv2 can be used for address delivery is 2 (IKEv2) [RFC4306], or static address configuration. However,
outside the scope of this document. the details on how IPCP or IKEv2 can be used for address delivery
are outside the scope of this document.
o The mobile node's IPv4 home subnet is typically a shared address o The mobile node's IPv4 home subnet is typically a shared address
space. It is not for the exclusive use of any one mobile node. space. It is not for the exclusive use of any one mobile node.
There can be multiple mobile nodes that are assigned IPv4 There can be multiple mobile nodes that are assigned IPv4
addresses from the same subnet. addresses from the same subnet.
o The mobile access gateway is the IPv4 default router for the o The mobile access gateway is the IPv4 default router for the
mobile node on its access link. It will be in the forwarding path mobile node on its access link. It will be in the forwarding path
for the mobile node's data traffic. Additionally, as specified in for the mobile node's data traffic. Additionally, as specified in
section 6.9.3 of [RFC5213], all the mobile access gateways in the Section 6.9.3 of [RFC5213], all the mobile access gateways in the
Proxy Mobile IPv6 domain MUST use the same link-layer address on Proxy Mobile IPv6 domain MUST use the same link-layer address on
any of the access links wherever the mobile node attaches. any of the access links wherever the mobile node attaches.
1.2. Relevance to Dual-Stack Mobile IPv6 1.2. Relevance to Dual-Stack Mobile IPv6
IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 IPv4 support for Mobile IPv6 is specified in the Dual-Stack Mobile
specification [RFC5555]. This document leverages some of the IPv6 specification [RFC5555]. This document leverages some of the
approaches, messaging options and processing logic defined in that approaches, messaging options, and processing logic defined in that
document for extending IPv4 support to Proxy Mobile IPv6, except with document for extending IPv4 support to Proxy Mobile IPv6, except with
deviation in some aspects for obvious reasons of supporting a deviation in some aspects for obvious reasons of supporting a
network-based mobility model. Following are some of the related network-based mobility model. The following are some of the related
considerations. considerations.
o The Binding Update flag 'F' and the NAT Detection Option defined o The Binding Update message flag 'F' and the NAT Detection Option
in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this defined in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this
specification in Proxy Binding Update and Proxy Binding specification in Proxy Binding Update and Proxy Binding
Acknowledgement messages. Their sole purpose is to allow forcing Acknowledgement messages. Their sole purpose is to allow forcing
of UDP encapsulation between a mobile access gateway and a local of UDP encapsulation between a mobile access gateway and a local
mobility anchor in situations similar to those discussed in mobility anchor in situations similar to those discussed in
Sections 4.1 and 4.4.1 of [RFC5555]. Sections 4.1 and 4.4.1 of [RFC5555].
o The extensions needed to the conceptual data structures, Binding o The necessary extensions to the conceptual data structures,
Cache entry and Binding Update List entry, for storing the state Binding Cache entry and Binding Update List entry, for storing the
related to the IPv4 support defined in [RFC5555], will all be state related to the IPv4 support defined in [RFC5555], will all
needed and relevant for this document. be needed and relevant for this document.
o In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555], o In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555],
IPsec security associations (SAs) are specific to a single mobile IPsec security associations (SAs) are specific to a single mobile
node; they use the identifier visible to upper-layer protocols node; they use the identifier visible to upper-layer protocols
(HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to
be updated when the mobile node moves. be updated when the mobile node moves.
In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec
SAs are specific to mobile access gateway (and used for SAs are specific to the mobile access gateway (and used for a
potentially large number of mobile nodes); they use the locators potentially large number of mobile nodes); they use the locators
used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selector; used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selectors;
and they are not updated when the mobile node moves. and they are not updated when the mobile node moves.
This means the IPsec processing for Mobile IPv6 and Proxy Mobile This means the IPsec processing for Mobile IPv6 and Proxy Mobile
IPv6 (whether IPv6 only or dual-stack) is very different. IPv6 (whether IPv6-only or dual-stack) is very different.
o The tunneling considerations specified in [RFC5555] for supporting o The tunneling considerations specified in [RFC5555] for supporting
IPv4 transport is relevant for this document as well. IPv4 transport are relevant for this document as well.
2. Conventions & Terminology 2. Conventions and Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
All the mobility related terms used in this document are to be All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC3775] and interpreted as defined in the Mobile IPv6 specification [RFC3775] and
Proxy Mobile IPv6 specification [RFC5213]. In addition this document Proxy Mobile IPv6 specification [RFC5213]. In addition, this
introduces the following terms. document introduces the following terms.
IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)
The IPv4 address that is configured on the egress-interface of the The IPv4 address that is configured on the egress-interface of the
mobile access gateway. When using IPv4 transport, this address mobile access gateway. When using IPv4 transport, this address
will be the registered care-of address in the mobile node's will be the registered care-of address in the mobile node's
Binding Cache entry and will also be the transport-endpoint of the Binding Cache entry and will also be the transport-endpoint of the
tunnel between the local mobility anchor and a mobile access tunnel between the local mobility anchor and a mobile access
gateway. gateway.
skipping to change at page 9, line 4 skipping to change at page 7, line 35
interface. This address is topologically anchored at the mobile interface. This address is topologically anchored at the mobile
node's local mobility anchor. The mobile node configures this node's local mobility anchor. The mobile node configures this
address on its attached interface. If the mobile node connects to address on its attached interface. If the mobile node connects to
the Proxy Mobile IPv6 domain via multiple interfaces each of the the Proxy Mobile IPv6 domain via multiple interfaces each of the
interfaces are assigned a unique IPv4 address. All the IPv6 home interfaces are assigned a unique IPv4 address. All the IPv6 home
network prefixes and the IPv4 home address assigned to a given network prefixes and the IPv4 home address assigned to a given
interface of a mobile node will be managed under one mobility interface of a mobile node will be managed under one mobility
session. session.
Selective De-registration Selective De-registration
A procedure for partial de-registration of all the addresses that A procedure for partial de-registration of all the addresses that
belong to one address family, i.e. de-registration of either the belong to one address family, i.e., de-registration of either the
IPv4 home address, or one or more of the assigned IPv6 home IPv4 home address or one or more of the assigned IPv6 home network
network prefixes. prefixes.
Encapsulation Modes Encapsulation Modes
This document uses the following terms when referring to the This document uses the following terms when referring to the
different encapsulation modes. different encapsulation modes.
IPv4-or-IPv6-over-IPv6 IPv4-or-IPv6-over-IPv6
IPv4 or IPv6 packet carried as a payload of an IPv6 packet IPv4 or IPv6 packet carried as a payload of an IPv6 packet
skipping to change at page 9, line 29 skipping to change at page 8, line 12
IPv4 or IPv6 packet carried as a payload of an IPv4 packet IPv4 or IPv6 packet carried as a payload of an IPv4 packet
IPv4-or-IPv6-over-IPv4-UDP IPv4-or-IPv6-over-IPv4-UDP
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
a UDP header a UDP header
IPv4-or-IPv6-over-IPv4-UDP-TLV IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4 packet carried as a payload in an IPv4 packet with UDP and IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
TLV headers UDP and TLV headers
IPv4-or-IPv6-over-IPv4-GRE IPv4-or-IPv6-over-IPv4-GRE
IPv4 packet carried as a payload in an IPv4 packet with GRE IPv4 or IPv6 packet carried as a payload in an IPv4 packet with
header (but no UDP or TLV header) a Generic Routing Encapsulation (GRE) header (but no UDP or TLV
header)
3. IPv4 Home Address Mobility Support 3. IPv4 Home Address Mobility Support
The IPv4 home address mobility support essentially enables a mobile The IPv4 home address mobility support essentially enables a mobile
node in a Proxy Mobile IPv6 domain to obtain IPv4 home address node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
configuration for its attached interfaces and be able to retain that configuration for its attached interfaces and be able to retain that
address configuration even after performing an handoff anywhere address configuration even after performing a handoff anywhere within
within that Proxy Mobile IPv6 domain. This section describes the that Proxy Mobile IPv6 domain. This section describes the protocol
protocol operation and the required extensions to Proxy Mobile IPv6 operation and the required extensions to Proxy Mobile IPv6 protocol
protocol 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 establish the required routing states for allowing the mobile will establish the required routing states for allowing the mobile
node to use its IPv4 home address from its current point of node to use its IPv4 home address from its current point of
attachment. 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 [RFC1332], IKEv2 [RFC4306] or DHCP [RFC2131], will be able to as IPCP [RFC1332], IKEv2 [RFC4306], or DHCP [RFC2131], will be able
obtain an IPv4 home address (IPv4-MN-HoA) for its attached interface. to obtain an IPv4 home address (IPv4-MN-HoA) for its attached
Although the address configuration mechanisms for delivering the interface. Although the address configuration mechanisms for
address configuration to the mobile node is independent of the Proxy delivering the address configuration to the mobile node is
Mobile IPv6 protocol operation, however there needs to be some independent of the Proxy Mobile IPv6 protocol operation, there needs
interactions between these two protocol flows. Section 3.4 to be some interaction between these two protocol flows. Section 3.4
identifies these interactions for supporting DHCP based address identifies these interactions for supporting DHCP-based address
configuration. configuration.
The support for IPv4 home address mobility is not dependent on the The support for IPv4 home address mobility is not dependent on the
IPv6 home address mobility support. It is not required that the IPv6 IPv6 home address mobility support. It is not required that the IPv6
home address mobility support needs to be enabled for providing IPv4 home address mobility support needs to be enabled for providing IPv4
home address mobility support. A mobile node will be able to obtain home address mobility support. A mobile node will be able to obtain
IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its IPv4-only, IPv6-only, or dual IPv4/IPv6 address configuration for its
attached interface. The mobile node's policy profile will determine attached interface. The mobile node's policy profile will determine
if the mobile node is entitled for both the protocol versions or a if the mobile node is entitled to both the protocol versions or a
single protocol version. Based on the policy, only those protocols single protocol version. Based on the policy, only those protocols
will be enabled on the access link. Furthermore, if the mobile node will be enabled on the access link. Furthermore, if the mobile node,
after obtaining the address configuration on its interface performs after obtaining the address configuration on its interface, performs
an handoff, either by changing its point of attachment over the same a handoff, either by changing its point of attachment over the same
interface or to a different interface, the network will ensure the interface or to a different interface, the network will ensure the
mobile node will be able to use the same IPv4 address configuration mobile node will be able to use the same IPv4 address configuration
after the handoff. after the handoff.
Additionally, If the mobile node connects to the Proxy Mobile IPv6 Additionally, if the mobile node connects to the Proxy Mobile IPv6
domain, through multiple interfaces and simultaneously through domain, through multiple interfaces and simultaneously through
different access networks, each of the connected interfaces will different access networks, each of the connected interfaces will
obtain an IPv4 home address from different subnets. In such obtain a unique IPv4 home address. In such a scenario, there will be
scenario, there will be multiple Binding Cache entries for the mobile multiple Binding Cache entries for the mobile node on the local
node on the local mobility anchor. All the address (IPv4/IPv6) mobility anchor. All the addresses (IPv4/IPv6) assigned to a given
assigned to a given interface will be managed as part of one mobility interface will be managed as part of one mobility session, as
session, as specified in Section 5.4 of [RFC5213]. specified in Section 5.4 of [RFC5213].
3.1. Local Mobility Anchor Considerations 3.1. Local Mobility Anchor Considerations
3.1.1. Extensions to Binding Cache Entry 3.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor needs to include structure maintained by the local mobility anchor needs to include
the following parameters. the following parameters.
o The IPv4 home address assigned to the mobile node's interface and o The IPv4 home address assigned to the mobile node's interface and
registered by the mobile access gateway. The IPv4 home address registered by the mobile access gateway. The IPv4 home address
entry also includes the corresponding subnet mask. It is to be entry also includes the corresponding subnet mask. It is to be
noted that this parameter is defined in the [RFC5555] and is noted that this parameter is defined in [RFC5555] and is presented
presented here for completeness. here for completeness.
o The IPv4 default router address assigned to the mobile node. o The IPv4 default router address assigned to the mobile node.
3.1.2. Signaling Considerations 3.1.2. Signaling Considerations
3.1.2.1. Processing Proxy Binding Updates 3.1.2.1. Processing Proxy Binding Updates
The processing rules specified in Section 5.3 of [RFC5213] are The processing rules specified in Section 5.3 of [RFC5213] are
applied for processing the received Proxy Binding Update message. applied for processing the received Proxy Binding Update message.
However, if the received Proxy Binding Update message has an IPv4 However, if the received Proxy Binding Update message has an IPv4
Home Address Request option, the following considerations MUST be Home Address Request option, the following considerations MUST be
applied additionally. applied additionally.
o If there is an IPv4 Home Address Request option present in the o If there is an IPv4 Home Address Request option (Section 3.3.1)
received Proxy Binding Update message, but no Home Network Prefix present in the received Proxy Binding Update message, but no Home
option [RFC5213] present in the received Proxy Binding Update Network Prefix option [RFC5213] present in the received Proxy
message, the local mobility anchor MUST NOT reject the request as Binding Update message, the local mobility anchor MUST NOT reject
specified in Section 5.3.1 of [RFC5213]. At least one instance of the request as specified in Section 5.3.1 of [RFC5213]. At least
any of these two options, either the IPv4 Home Address Request one instance of either of these two options, either the IPv4 Home
option or the Home Network Prefix option, MUST be present. If Address Request option or the Home Network Prefix option, MUST be
there is not a single instance of any of these two options present present. If there is not a single instance of either of these two
in the request, the local mobility anchor MUST reject the request options present in the request, the local mobility anchor MUST
and send a Proxy Binding Acknowledgement message with Status field
set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's
home network prefix option) [RFC5213].
o If there is at least one instance of Home Network Prefix option
[RFC5213] present in the received Proxy Binding Update message,
but it is known from the mobile node's policy profile that the
mobile node is not authorized for IPv6 service, or IPv6 routing in
not enabled in the home network, the local mobility anchor MUST
reject the request and send a Proxy Binding Acknowledgement reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to message with the Status field set to
MISSING_HOME_NETWORK_PREFIX_OPTION (missing the mobile node's home
network prefix option) [RFC5213].
o If there is at least one instance of the Home Network Prefix
option [RFC5213] present in the received Proxy Binding Update
message, but it is known from the mobile node's policy profile
that the mobile node is not authorized for IPv6 service, or IPv6
routing in not enabled in the home network, the local mobility
anchor MUST reject the request and send a Proxy Binding
Acknowledgement message with the Status field set to
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not
authorized for IPv6 mobility service). authorized for IPv6 mobility service; see Section 3.3.5).
o If there is an IPv4 Home Address Request option present in the o If there is an IPv4 Home Address Request option present in the
received Proxy Binding Update message, but it is known from the received Proxy Binding Update message, but it is known from the
mobile node's policy profile that the mobile node is not mobile node's policy profile that the mobile node is not
authorized for IPv4 service, or if IPv4 routing not enabled in the authorized for IPv4 service, or if IPv4 routing is not enabled in
home network, the local mobility anchor MUST reject the request the home network, the local mobility anchor MUST reject the
and send a Proxy Binding Acknowledgement message with the Status request and send a Proxy Binding Acknowledgement message with the
field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE
not authorized for IPv4 mobility service). (mobile node not authorized for IPv4 mobility service; see
Section 3.3.5).
o If there are more than one instance of the IPv4 Home Address o If there is more than one instance of the IPv4 Home Address
Request option present in the request, then the local mobility Request option present in the request, then the local mobility
anchor MUST reject the request and send a Proxy Binding anchor MUST reject the request and send a Proxy Binding
Acknowledgement message with the Status field set to Acknowledgement message with the Status field set to
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
home address assignment not supported). home address assignments not supported; see Section 3.3.5).
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 [RFC5213] with a NON_ZERO prefix value, or, if there is option [RFC5213] with a NON_ZERO prefix value, or, if there is
an IPv4 Home Address Request option with the IPv4 address in an IPv4 Home Address Request option with the IPv4 address in
the option set to ALL_ZERO, considerations from Section 5.4.1 the option set to ALL_ZERO, considerations from Section 5.4.1
of [RFC5213] MUST be applied. of [RFC5213] MUST be applied.
* If there is an IPv4 Home Address Request option present in the * If there is an IPv4 Home Address Request option present in the
request with the IPv4 address value in the option set to a request with the IPv4 address value in the option set to a
NON_ZERO value, considerations from Section 3.1.2.7 MUST be NON_ZERO value, considerations from Section 3.1.2.7 MUST be
applied. applied.
o If there is no existing Binding Cache entry that can be associated o If there is no existing Binding Cache entry that can be associated
with the request, the local mobility anchor MUST consider this with the request, the local mobility anchor MUST consider this
request as an initial binding registration request and request as an initial binding registration request, and
considerations from Section 3.1.2.2 MUST be applied. considerations from Section 3.1.2.2 MUST be applied.
Additionally, if there are one or more Home Network Prefix options Additionally, if there are one or more Home Network Prefix options
[RFC5213] present in the request, considerations from Section [RFC5213] present in the request, considerations from Section
5.3.2 of [RFC5213] MUST also be applied. 5.3.2 of [RFC5213] MUST also be applied.
o If there exists a Binding Cache entry that can be associated with o If there exists a Binding Cache entry that can be associated with
the request, the local mobility anchor MUST apply considerations the request, the local mobility anchor MUST apply considerations
from Section 5.3.1 of [RFC5213], (point 13), to determine if the from Section 5.3.1 of [RFC5213], (point 13), to determine if the
request is re-registration or a de-registration request. If the request is a re-registration or a de-registration request. If the
request is a re-registration request, considerations from Section request is a re-registration request, considerations from
3.1.2.3 MUST be applied and if it is a de-registration request, Section 3.1.2.3 MUST be applied, and if it is a de-registration
considerations from Section 3.1.2.5 MUST be applied. request, considerations from Section 3.1.2.5 MUST be applied.
o If there exists a Binding Cache entry that can be associated with o If there exists a Binding Cache entry that can be associated with
the request and if it is determined that the request is a re- the request and if it is determined that the request is a re-
registration request for extending IPv4 home address mobility registration request for extending an IPv4 home address mobility
support to the existing IPv6-only mobility session, considerations support to the existing IPv6-only mobility session, considerations
from Section 3.1.2.2 MUST be applied with respect to IPv4 support. from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
3.1.2.2. Initial Binding Registration (New Mobility Session) 3.1.2.2. Initial Binding Registration (New Mobility Session)
o If there is an IPv4 Home Address Request option present in the o If there is an IPv4 Home Address Request option 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 Request option with the IPv4 o If there is an IPv4 Home Address Request option 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 that the address
topologically anchored on the local mobility anchor and is topologically anchored on the local mobility anchor and
furthermore the mobile node is authorized to use that address. If furthermore that the mobile node is authorized to use that
the mobile node is not authorized for that specific address, the address. If the mobile node is not authorized for that specific
local mobility anchor MUST reject the request and send a Proxy address, the local mobility anchor MUST reject the request and
Binding Acknowledgement message with the Status field set to send a Proxy Binding Acknowledgement message with the Status field
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not
for the requesting IPv4 address). It MUST also include the IPv4 authorized for the requesting IPv4 address; see Section 3.3.5).
Home Address Reply option in the reply with the status field value It MUST also include the IPv4 Home Address Reply option
in the option set to 129 (Administratively prohibited). (Section 3.3.2). in the reply with the Status field value in the
option set to 129 (Administratively 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 Home (Insufficient resources). It MUST also include the IPv4 Home
Address Reply option in the reply with the status field value in Address Reply option in the reply with the Status field value in
the option set to 128 (Failure, reason unspecified). the option set to 128 (Failure, reason unspecified).
o Upon accepting the request, the local mobility anchor MUST create o Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for this mobility session. However, if the a Binding Cache entry for this mobility session. However, if the
request also contains one or more Home Network Prefix options request also contains one or more Home Network Prefix options
[RFC5213], there should still be only one Binding Cache entry that [RFC5213], there should still be only one Binding Cache entry that
should be created for this mobility session. The created Binding should be created for this mobility session. The created Binding
Cache entry MUST be used for managing both IPv4 and IPv6 home Cache entry MUST be used for managing both IPv4 and IPv6 home
address bindings. The fields in the Binding Cache entry MUST be address bindings. The fields in the Binding Cache entry MUST be
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 bidirectional tunnel to
to the mobile access gateway with the encapsulation mode set to the mobile access gateway with the encapsulation mode set to the
the negotiated mode for carrying the IPv4 payload traffic. When negotiated mode for carrying the IPv4 payload traffic. When using
using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over- IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over-IPv6
IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet). (IPv4 or IPv6 packet carried as a payload of an IPv6 packet).
When using IPv4 transport, the encapsulation mode is as specified When using IPv4 transport, the encapsulation mode is as specified
in Section 4. in Section 4.
o The local mobility anchor MUST create an IPv4 host route (or a o The local mobility anchor MUST create an IPv4 host route (or a
platform specific equivalent function that sets up the forwarding) platform-specific equivalent function that sets up the forwarding)
for tunneling the packets received for the mobile node's home for tunneling the packets received for the mobile node's home
address associated with this mobility session. 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 [RFC5213] MUST be All the considerations from Section 5.3.3 of [RFC5213] 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) [RFC5213] present in o If there is no Home Network Prefix option [RFC5213] present in the
the request, but if the Binding Cache entry associated with this request, but if the Binding Cache entry associated with this
request has IPv6 home network prefix(es), the local mobility request has IPv6 home network prefix(es), the local mobility
anchor MUST consider this as a request to extend lifetime only for anchor MUST consider this as a request to extend lifetime only for
the IPv4 home address and not for the IPv6 home network the IPv4 home address and not for the IPv6 home network
prefix(es). Hence, the local mobility anchor SHOULD release all prefix(es). Hence, the local mobility anchor SHOULD release all
the IPv6 home network prefix(es) assigned to that mobile node and the IPv6 home network prefix(es) assigned to that mobile node and
for that specific attached interface. Similar considerations for that specific attached interface. Similar considerations
apply for the case where there is no IPv4 Home Address Request apply for the case where there is no IPv4 Home Address Request
option present in the request, but if the Binding Cache entry option present in the request, but if the Binding Cache entry
associated with that request has both IPv4 home address and IPv6 associated with that request has both IPv4 home address and IPv6
home network prefix(es). home network prefix(es).
o The local mobility anchor MUST remove the previously created IPv4 o The local mobility anchor MUST remove the previously created IPv4
host route (or the forwarding state) and the dynamically created host route (or the forwarding state) and the dynamically created
bi-directional tunnel for carrying the IPv4 payload traffic (if bidirectional tunnel for carrying the IPv4 payload traffic (if
there are no other mobile nodes for which the tunnel is being there are no other mobile nodes for which the tunnel is being
used). This will remove the routing state towards the mobile used). This will remove the routing state towards the mobile
access gateway where the mobile node was anchored prior to the access gateway where the mobile node was anchored prior to the
handoff. handoff.
o The local mobility anchor MUST create a bi-directional tunnel to o The local mobility anchor MUST create a bidirectional 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 bidirectional tunnel) and with the encapsulation mode set
set to the negotiated mode for carrying the IPv4 payload traffic. to the negotiated mode for carrying the IPv4 payload traffic. An
An IPv4 host route for tunneling the packets received for the IPv4 host route for tunneling the packets received for the mobile
mobile node's IPv4 home address MUST also be added. node's IPv4 home address MUST also be added.
o The required forwarding state identified in Section 5.3.6 of o The required forwarding state identified in Section 5.3.6 of
[RFC5213] is for IPv6 payload traffic. Those considerations apply [RFC5213] is for IPv6 payload traffic. Those considerations apply
for IPv4 payload traffic as well. However, if IPv4 transport is for IPv4 payload traffic as well. However, if IPv4 transport is
in use, considerations from Section 4 MUST be applied. in use, considerations from Section 4 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 [RFC5213] MUST be All the considerations from Section 5.3.5 of [RFC5213] MUST be
applied. Additionally, for removing the IPv4 state as part of the applied. Additionally, to remove 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 bidirectional tunnel for carrying the IPv4 payload traffic
(if there are no other mobile nodes for which the tunnel is being (if there are no other mobile nodes for which the tunnel is being
used) MUST be removed. However, if the request is for a selective used) MUST be removed. However, if the request is for a selective
de-registration (IPv4 home address only, or all the IPv6 home network de-registration (IPv4 home address only, or all the IPv6 home network
prefixes), the Binding Cache entry MUST NOT be deleted, only the prefixes), the Binding Cache entry MUST NOT be deleted, only the
respective states with respect to those addresses MUST be deleted. respective states related 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 When sending the Proxy Binding Acknowledgement message to the mobile
Acknowledgement message to the mobile access gateway MUST construct access gateway, the local mobility anchor MUST construct the message
the message as specified in Section 5.3.6 of [RFC5213]. as specified in Section 5.3.6 of [RFC5213]. Additionally, the
Additionally, the following considerations MUST be applied. following considerations MUST be applied.
o Section 5.3.6 of [RFC5213] requires the local mobility anchor to o Section 5.3.6 of [RFC5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option include at least one instance of the Home Network Prefix option
[RFC5213] in the Proxy Binding Acknowledgement message that it [RFC5213] in the Proxy Binding Acknowledgement message that it
sends to the mobile access gateway. However, if the received sends to the mobile access gateway. However, if the received
Proxy Binding Update message has only the IPv4 Home Address Proxy Binding Update message has only the IPv4 Home Address
Request option and did not contain the Home Network Prefix Request option and does not contain the Home Network Prefix
option(s), then the local mobility anchor MUST NOT include any option(s), then the local mobility anchor MUST NOT include any
Home Network Prefix option(s) in the reply. However, there MUST Home Network Prefix option(s) in the reply. However, there MUST
be at least one instance of either the Home Network Prefix option be at least one instance of either the Home Network Prefix option
[RFC5213] or the IPv4 Home Address Reply option present in the [RFC5213] or the IPv4 Home Address Reply option present in the
Proxy Binding Acknowledgement message. Proxy Binding Acknowledgement message.
o The IPv4 Home Address Reply option MUST be present in the Proxy o The IPv4 Home Address Reply option MUST be present in the Proxy
Binding Acknowledgement message. 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 128, i.e., if the Proxy Binding Update is rejected, then there
there MUST be an IPv4 Home Address Reply option corresponding MUST be an IPv4 Home Address Reply option corresponding to the
to the IPv4 Home Address Request option present in the request IPv4 Home Address Request option present in the request and
and with the IPv4 address value and the prefix length fields with the IPv4 address value and the prefix length fields in
in the option set to the corresponding values in the request. the option set to the corresponding values in the request.
The status field value in the option must be set to the The Status field value in the option must be set to the
specific error code. specific error code.
2. For all other cases, there MUST be an IPv4 Home Address Reply 2. For all other cases, there MUST be an IPv4 Home Address Reply
option for carrying the IPv4 home address assigned for that option to carry the IPv4 home address assigned for that
mobility session and with the value in the option set to the mobility session and with the value in the option set to the
allocated IPv4 address. The prefix length in the option MUST allocated IPv4 address. The prefix length in the option MUST
be set to the prefix length of the allocated address. The be set to the prefix length of the mobile node's IPv4 home
status field value in the option must be set to 0 (Success). network. The Status field value in the option must be set to
0 (Success).
o The IPv4 Default-Router Address option MUST be present, if the o The IPv4 Default-Router Address option (Section 3.3.3) MUST be
Status field value in the Proxy Binding Acknowledgement message is present, if the Status field value in the Proxy Binding
set to 0 (Proxy Binding Update Accepted). Otherwise, the option Acknowledgement message is set to 0 (Proxy Binding Update
MUST NOT be present. If the option is present, the default router accepted) [RFC5213]. Otherwise, the option MUST NOT be present.
address in the option MUST be set to the mobile node's default If the option is present, the default router address in the option
router address. MUST be set to the mobile node's default router address.
3.1.2.7. Binding Cache Entry Lookup Considerations 3.1.2.7. Binding Cache Entry Lookup Considerations
The Binding Cache entry lookup considerations specified in section The Binding Cache entry lookup considerations specified in Section
5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as 5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as
the key parameter for identifying the Binding Cache entry. However, the key parameter for identifying the Binding Cache entry. However,
when there is not a single Home Network Prefix option with a NON_ZERO when there is not a single Home Network Prefix option with a NON_ZERO
value present in the request, but if there is an IPv4 Home Address value present in the request, but there is an IPv4 Home Address
option with a NON_ZERO value present in the request, then the option with a NON_ZERO value present in the request, then the
following considerations MUST be applied. following considerations MUST be applied.
o The search rules specified in section 5.4.1.1 of [RFC5213], which o The search rules specified in Section 5.4.1.1 of [RFC5213], which
primarily uses IPv6 home network prefix set as the search key, are primarily uses IPv6 home network prefix set as the search key, are
equally valid when using a single IPv4 home address as the key. equally valid when using a single IPv4 home address as the key.
When applying those considerations, instead of the IPv6 home When applying those considerations, instead of the IPv6 home
network prefix(es), the IPv4 home address from the IPv4 Home network prefix(es), the IPv4 home address from the IPv4 Home
Address option present in the request MUST be used as the search Address option present in the request MUST be used as the search
key. key.
o The rules specified in section 5.4.1.1 of [RFC5213], assume the o The rules specified in Section 5.4.1.1 of [RFC5213] assume the
presence of one or more IPv6 home network prefixes in the received presence of one or more IPv6 home network prefixes in the received
request and also in the Binding Cache entry. But, when using the request and also in the Binding Cache entry. But, when using the
IPv4 home address as the search key, these considerations MUST IPv4 home address as the search key, these considerations MUST
always assume just one single IPv4 home address, both in the always assume just one single IPv4 home address, both in the
request and also in the Binding Cache entry. request and also in the Binding Cache entry.
3.1.3. Routing Considerations for the Local Mobility Anchor 3.1.3. Routing Considerations for the Local Mobility Anchor
Intercepting Packets Sent to the Mobile Node's IPv4 home address: Intercepting Packets Sent to the Mobile Node's IPv4 Home Address:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
advertise a connected route into the Routing Infrastructure for advertise a connected route into the Routing Infrastructure for
the mobile node's IPv4 home address or for its home subnet, in the mobile node's IPv4 home address or for its home subnet, in
order to receive packets that are sent to the mobile node's IPv4 order to receive packets that are sent to the mobile node's IPv4
home address. This essentially enables IPv4 routers in that home address. This essentially enables IPv4 routers in that
network to detect the local mobility anchor as the last-hop router network to detect the local mobility anchor as the last-hop router
for that subnet. for that subnet.
Forwarding Packets to the Mobile Node: Forwarding Packets to the Mobile Node:
o On receiving a packet from a correspondent node with the o On receiving a packet from a corresponding node with the
destination address matching the mobile node's IPv4 home address, destination address matching the mobile node's IPv4 home address,
the local mobility anchor MUST forward the packet through the bi- the local mobility anchor MUST forward the packet through the
directional tunnel setup for that mobile node. bidirectional tunnel setup for that mobile node.
o The format of the tunneled packet when payload protection is not o The format of the tunneled packet when payload protection is not
enabled: enabled:
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/ Upper-layer protocols /* Packet Content*/
Figure 2: Tunneled Packets from LMA to MAG Figure 2: Tunneled Packets from the Local Mobility Anchor (LMA) to
the Mobile Access Gateway (MAG)
Forwarding Packets Sent by the Mobile Node: Forwarding Packets Sent by the Mobile Node:
o All the reverse tunneled packets that the local mobility anchor o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner header, MUST be routed to the destination specified in the inner
IPv4 packet header. These routed packets will have the source IPv4 packet header. These routed packets will have the Source
address field set to the mobile node's IPv4 home address. Address field set to the mobile node's IPv4 home address.
3.1.4. ECN & Payload Fragmentation Considerations 3.1.4. ECN and Payload Fragmentation Considerations
The ECN considerations specified in Section 5.6.3 of [RFC5213] apply The Explicit Congestion Notification (ECN) considerations specified
for the IPv4 payload packets as well. The mobility agents at the in Section 5.6.3 of [RFC5213] apply for the IPv4 payload packets as
tunnel entry and exit points MUST handle ECN information as specified well. The mobility agents at the tunnel entry and exit points MUST
in that document. handle ECN information as specified in that document.
The mobility agents at the tunnel entry and exit points MUST apply The mobility agents at the tunnel entry and exit points MUST apply
the IP packet fragmentation considerations as specified in section 7 the IP packet fragmentation considerations as specified in Section 7
of [RFC2473] and additionally they MUST apply the considerations of [RFC2473]; additionally, they MUST apply the considerations
related to tunnel error processing and reporting as specified in related to tunnel error processing and reporting as specified in
section 8 of [RFC2473]. Section 8 of [RFC2473].
3.2. Mobile Access Gateway Considerations 3.2. Mobile Access Gateway Considerations
3.2.1. Extensions to Binding Update List Entry 3.2.1. Extensions to Binding Update List Entry
To support the IPv4 home address mobility feature, the conceptual To support the IPv4 home address mobility feature, the conceptual
Binding Update List entry data structure needs to be extended with Binding Update List entry data structure needs to be extended with
the following additional fields. the following additional fields.
o The IPv4 home address assigned to the mobile node's attached o The IPv4 home address assigned to the mobile node's attached
interface. This IPv4 home address may have been statically interface. This IPv4 home address may have been statically
configured in the mobile node's policy profile, or, may have been configured in the mobile node's policy profile, or, may have been
dynamically allocated by the local mobility anchor. The IPv4 home dynamically allocated by the local mobility anchor. The IPv4 home
address entry also includes the corresponding subnet mask. address entry also includes the corresponding subnet mask.
o The IPv4 default router address of the mobile node. This is o The IPv4 default router address of the mobile node. This is
acquired from the mobile node's local mobility anchor through the acquired from the mobile node's local mobility anchor through the
received Proxy Binding Acknowledgment message. received Proxy Binding Acknowledgement message.
3.2.2. Extensions to Mobile Node's Policy Profile 3.2.2. Extensions to Mobile Node's Policy Profile
To support the IPv4 Home Address Mobility Support feature the mobile To support the IPv4 home address mobility support feature, the mobile
node's policy profile, specified in Section 6.2 of [RFC5213] MUST be node's policy profile, specified in Section 6.2 of [RFC5213], MUST be
extended with the following additional fields. extended with the following additional fields.
Extensions to the mandatory section of the policy profile: Extensions to the mandatory section of the policy profile:
o This field identifies all the IP protocol versions for which the o This field identifies all the IP versions for which the home
home address mobility support needs to be extended to the mobile address mobility support needs to be extended to the mobile node.
node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ The supported modes are IPv4-only, IPv6-only, and dual IPv4/IPv6.
IPv6.
Extensions to the optional section of the policy profile: Extensions to the optional section of the policy profile:
o The IPv4 home address assigned to the mobile node's attached o The IPv4 home address assigned to the mobile node's attached
interface. The specific details on how the network maintains the interface. The specific details on how the network maintains the
association between the address and the attached interface is association between the address and the attached interface is
outside the scope of this document. This address field also outside the scope of this document. This address field also
includes the corresponding subnet mask. includes the corresponding subnet mask.
3.2.3. Signaling Considerations 3.2.3. Signaling Considerations
3.2.3.1. Mobile Node Attachment and Initial Binding Registration 3.2.3.1. Mobile Node Attachment and Initial Binding Registration
After detecting a new mobile node on its access link, the mobile After detecting a new mobile node on its access link, the mobile
access gateway on the access link MUST determine if IPv4 home address access gateway on the access link MUST determine if IPv4 home address
mobility support needs to be enabled for that mobile node. The mobility support needs to be enabled for that mobile node. The
mobile node's policy profile identifies the supported modes (IPv4- mobile node's policy profile identifies the supported modes (IPv4-
only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the only, IPv6-only, or dual IPv4/IPv6) for that mobile node for which
mobile service needs to be enabled. Based on those policy the mobile service needs to be enabled. Based on those policy
considerations and from other triggers such as from the network, if considerations and from other triggers such as from the network, if
it is determined that IPv4 home address mobility support needs to be it is determined that IPv4 home address mobility support needs to be
enabled for the mobile node, considerations from section 6.9.1.1 of enabled for the mobile node, considerations from Section 6.9.1.1 of
[RFC5213] MUST be applied with the following exceptions. [RFC5213] MUST be applied with the following exceptions.
o The IPv4 Home Address Request option MUST be present in the Proxy o The IPv4 Home Address Request option MUST be present in the Proxy
Binding Update message. Binding Update message.
* If the mobile access gateway learns the mobile node's IPv4 home * If the mobile access gateway learns the mobile node's IPv4 home
address either from its policy profile, or from other means, address either from its policy profile or from other means, the
the mobile access gateway MAY ask the local mobility anchor to mobile access gateway MAY ask the local mobility anchor to
allocate that specific address by including exactly one allocate that specific address by including exactly one
instance of the IPv4 Home Address Request option with the IPv4 instance of the IPv4 Home Address Request option with the IPv4
home address and the prefix length fields in the option set to home address and the prefix length fields in the option set to
that specific address and its prefix length. that specific IPv4 address and the prefix length of the
corresponding home network.
* The mobile access gateway MAY also ask the local mobility * The mobile access gateway MAY also ask the local mobility
anchor for dynamic IPv4 home address allocation. It can anchor for dynamic IPv4 home address allocation. It can
include exactly one instance of the IPv4 Home Address option include exactly one instance of the IPv4 Home Address option
with the IPv4 home address and the prefix length fields in the with the IPv4 home address and the prefix length fields in the
option set to ALL_ZERO value. Furthermore, the (P) flag in the option set to the ALL_ZERO value. Furthermore, the (P) flag in
option MUST be set to 0. This serves as a request to the local the option MUST be set to 0. This serves as a request to the
mobility anchor for the IPv4 home address allocation. local mobility anchor for the IPv4 home address allocation.
o The Proxy Binding Update message MUST be constructed as specified o The Proxy Binding Update message MUST be constructed as specified
in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix
option(s) [RFC5213] MUST be present in the Proxy Binding Update option(s) [RFC5213] MUST be present in the Proxy Binding Update
only if IPv6 home address mobility support also needs to be only if IPv6 home address mobility support also needs to be
enabled for the mobile node. Otherwise, the Home Network Prefix enabled for the mobile node. Otherwise, the Home Network Prefix
option(s) MUST NOT be present. option(s) MUST NOT be present.
o When using IPv4 transport for carrying the signaling messages, the o When using IPv4 transport to carry the signaling messages, the
related considerations from section 4 MUST be applied related considerations from Section 4 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 [RFC5213] MUST be All the considerations from Section 6.9.1.2 of [RFC5213] MUST be
applied with the following exceptions. applied with the following exceptions.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE
(The mobile node is not authorized for IPv4 mobility service), the (The mobile node is not authorized for IPv4 mobility service), the
mobile access gateway SHOULD NOT send a Proxy Binding Update mobile access gateway SHOULD NOT send a Proxy Binding Update
message including a IPv4 Home Address Request option till an message including a IPv4 Home Address Request option until an
administrative action is taken. administrative action is taken.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS
mobile node is not authorized for the requesting IPv4 home (The mobile node is not authorized for the requesting IPv4 home
address), the mobile access gateway SHOULD NOT request for the address), the mobile access gateway SHOULD NOT request the same
same IPv4 address again, but MAY request the local mobility anchor IPv4 address again, but MAY request the local mobility anchor to
to perform the address assignment by including exactly one perform the address assignment by including exactly one instance
instance of IPv4 Home Address Request option with the IPv4 home of the IPv4 Home Address Request option with the IPv4 home address
address and the prefix length fields in the option set to ALL_ZERO and the prefix length fields in the option set to the ALL_ZERO
value. value.
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_IPV6_MOBILITY_SERVICE Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE
(The mobile node is not authorized for IPv6 mobility service), the (The mobile node is not authorized for IPv6 mobility service), the
mobile access gateway SHOULD NOT send a Proxy Binding Update mobile access gateway SHOULD NOT send a Proxy Binding Update
message including any Home Network Prefix option(s) till an message including any Home Network Prefix option(s) until an
administrative action is taken. administrative action is taken.
o If there is no IPv4 Home Address Reply option present in the o If there is no IPv4 Home Address Reply option present in the
received Proxy Binding Acknowledgement message, the mobile access received Proxy Binding Acknowledgement message, the mobile access
gateway MUST NOT enable IPv4 support for the mobile node and the gateway MUST NOT enable IPv4 support for the mobile node and the
rest of the considerations from this section can be skipped. rest of the considerations from this section can be skipped.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value in the IPv4 Home Address Reply option set to a Status field value in the IPv4 Home Address Reply option set to a
value that indicates that the request was rejected by the local value that indicates that the request was rejected by the local
mobility anchor, the mobile access gateway MUST NOT enable mobility anchor, the mobile access gateway MUST NOT enable IPv4
forwarding for that specific IPv4 home address. mobility support.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST update a Binding Update List entry for mobile access gateway MUST update a Binding Update List entry for
that mobile node. The entry MUST be updated with the assigned that mobile node. The entry MUST be updated with the assigned
IPv4 home address and other accepted registration values. IPv4 home address and other accepted registration values.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted) and Status field value set to 0 (Proxy Binding Update accepted) and
has the IPv4 Home Address Reply option set to a value that has the IPv4 Home Address Reply option set to a value that
indicates that the request was accepted by the local mobility indicates that the request was accepted by the local mobility
anchor, the mobile access gateway MUST establish a bi-directional anchor, the mobile access gateway MUST establish a bidirectional
tunnel to the local mobility anchor (if there is no existing bi- tunnel to the local mobility anchor (if there is no existing
directional tunnel to that local mobility anchor) and with the bidirectional tunnel to that local mobility anchor) and with the
encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 encapsulation mode set to IPv4-or-IPv6-over-IPv6 (an IPv4 or IPv6
packet carried as a payload of an IPv6 packet). Considerations packet carried as a payload of an IPv6 packet). Considerations
from Section 5.6.1 of [RFC5213] MUST be applied for managing the from Section 5.6.1 of [RFC5213] MUST be applied for managing the
dynamically created bi-directional tunnel. However, when using dynamically created bidirectional tunnel. However, when using
IPv4 transport, the encapsulation mode MUST be set to the IPv4 transport, the encapsulation mode MUST be set to the
negotiated encapsulation mode, as specified in Section 4 of this negotiated encapsulation mode, as specified in Section 4 of this
specification. document.
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 bidirectional tunnel set up for that mobile
node. node.
o The default router address MUST be obtained from the IPv4 Default- o The default router address MUST be obtained from the IPv4 Default-
Router Address option present in the received Proxy Binding Router Address option present in the received Proxy Binding
Acknowledgement message. The mobile access gateway SHOULD Acknowledgement message. The mobile access gateway SHOULD
configure this address on its interface and respond to any ARP configure this address on its interface and respond to any Address
requests sent by the mobile node for resolving the hardware Resolution Protocol (ARP) requests sent by the mobile node to
address of the default router. However, since the link between resolve the hardware address of the default router. However,
the mobile access gateway and the mobile node is a point-to-point since the link between the mobile access gateway and the mobile
link, implementations will be able receive any packets sent to the node is a point-to-point link, implementations will be able
default router address without having to explicitly configure the receive any packets sent to the default router address without
default router address on its interface. The mobile access having to explicitly configure the default router address on its
gateway MAY also use the default router address as the source interface. The mobile access gateway MAY also use the default
address for any datagrams sent to the mobile node and originated router address as the source address for any datagrams sent to the
by the mobile access gateway itself. It MUST also use this mobile node and originated by the mobile access gateway itself.
address in the DHCP Router option [RFC2132] in the DHCP messages. It MUST also use this address in the DHCP Router option [RFC2132]
in the DHCP messages.
o If there is an IPv4 DHCP Support Mode option present in the o If there is an IPv4 DHCP Support Mode option (Section 3.3.4)
received Proxy Binding Acknowledgement message and if the (S) flag present in the received Proxy Binding Acknowledgement message and
in the option is set to a value of (1), then the mobile access if the (S) flag in the option is set to a value of (1), then the
gateway MUST function as a DHCP server for the mobile node. If mobile access gateway MUST function as a DHCP server for the
either the (S) flag in the option is set to a value of (0), or if mobile node. If either the (S) flag in the option is set to a
the option is not present in the request, then the mobile access value of (0), or if the option is not present in the request, then
gateway MUST function as a DHCP Relay for the mobile node. 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 to extend the lifetime of
of a mobility session or for de-registering the mobility session, the a mobility session or to de-register the mobility session, the
respective considerations from [RFC5213] MUST be applied. respective considerations from [RFC5213] MUST be applied.
Furthermore, the following additional considerations MUST also be Furthermore, the following additional considerations MUST also be
applied. applied.
o If there is an IPv4 home address assigned to the mobility session, o If there is an IPv4 home address assigned to the mobility session,
then there MUST be exactly one instance of the IPv4 Home Address then there MUST be exactly one instance of the IPv4 Home Address
Request option present in the Proxy Binding Update message. The Request option present in the Proxy Binding Update message. The
IPv4 home address and the prefix length fields in the option MUST IPv4 home address and the prefix length fields in the option MUST
be set to that specific address and its corresponding subnet-mask be set to that specific address and its corresponding subnet-mask
length. length.
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 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 Request option present in one instance of the IPv4 Home Address Request option present in
the Proxy Binding Update message. The IPv4 home address in the the Proxy Binding Update message. The IPv4 home address in the
option MUST be set to either ALL_ZERO or to a specific address option MUST be set to either ALL_ZERO or to a specific address
that is being requested. that is being requested.
o For performing selective de-registration of IPv4 home address but o For performing selective de-registration of IPv4 home address but
still retaining the mobility session with all the IPv6 home still retaining the mobility session with all the IPv6 home
network prefixes, the Proxy Binding Update message with the network prefixes, the Proxy Binding Update message with the
lifetime value of (0) MUST NOT include any IPv6 Home Network lifetime value of (0) MUST NOT include any IPv6 Home Network
Prefix options(s) [RFC5213]. It MUST include exactly one instance Prefix options [RFC5213]. It MUST include exactly one instance of
of the IPv4 Home Address Request option with the IPv4 home address the IPv4 Home Address Request option with the IPv4 home address
and the prefix length fields in the option set to the IPv4 home and the prefix length fields in the option set to the IPv4 home
address that is being de-registered. Similarly for selective de- address that is being de-registered. Similarly, for selective de-
registration of all the IPv6 home network prefixes, the Proxy registration of all the IPv6 home network prefixes, the Proxy
Binding Update message MUST NOT include the IPv4 Home address Binding Update message MUST NOT include the IPv4 Home address
option, it MUST include a Home Network Prefix option for each of option, it MUST include a Home Network Prefix option for each of
the assigned home network prefixes assigned for that mobility the assigned home network prefixes assigned for that mobility
session and with the prefix value in the option set to that session and with the prefix value in the option set to that
respective prefix value. respective prefix value.
o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if
the same option(s) was not present in the initial Proxy Binding the same option(s) was not present in the initial Proxy Binding
Update message. Otherwise considerations from [RFC5213] with Update message. Otherwise, considerations from [RFC5213] with
respect to this option MUST be applied. respect to this option MUST be applied.
o If at any point the mobile access gateway fails to extend the o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address. for the mobile node's IPv4 home address.
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 bidirectional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST remove the outer header before forwarding the packet gateway MUST remove the outer header before forwarding the packet
to the mobile node. to the mobile node.
o 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 bidirectional tunnel established with the local
mobility anchor. However, when EnableMAGLocalRouting flag is set, mobility anchor. However, when the EnableMAGLocalRouting flag is
considerations from Section 6.10.3 of [RFC5213] MUST be applied set, considerations from Section 6.10.3 of [RFC5213] MUST be
with respect to local routing. applied with respect to local routing.
o When forwarding the packet through the bi-directional tunnel, the o When forwarding the packet through the bidirectional tunnel, the
encapsulation considerations specified in section 3.1.3 MUST be encapsulation considerations as specified in Section 3.1.3 MUST be
applied. However, before forwarding the packet, the mobile access applied (except that the source and destination addresses fields
gateway MUST ensure the source address in the received packet is in the outer encapsulation header are reversed). However, before
the address allocated for that mobile node and that there is an forwarding the packet, the mobile access gateway MUST ensure the
active binding on the local mobility anchor for that mobile node. 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.
o The mobile access gateway SHOULD use Proxy ARP [RFC0925] to reply o The mobile access gateway SHOULD use the Proxy ARP [RFC0925] to
to ARP Requests that it receives from the mobile node seeking reply to ARP Requests that it receives from the mobile node
address resolutions for the destinations on the mobile node's home seeking address resolutions for the destinations on the mobile
subnet. When receiving an ARP Request, the mobile access gateway node's home subnet. When receiving an ARP Request, the mobile
SHOULD examine the target IP address of the Request, and if this access gateway SHOULD examine the target IP address of the
IP address matches the mobile node's IPv4 home subnet, it SHOULD Request, and if this IP address matches the mobile node's IPv4
transmit a Proxy ARP Reply. However, on certain types of links, home subnet, it SHOULD transmit a Proxy ARP Reply. However, on
the mobile node does not use ARP for address resolutions, instead certain types of links, the mobile node does not use ARP for
it forwards all the packets to the mobile access gateway. On such address resolutions, instead it forwards all the packets to the
types of links, the mobile access gateway is not required to mobile access gateway. On such types of links, the mobile access
support Proxy ARP function. At the same time, implementations not gateway is not required to support the Proxy ARP function. At the
supporting the Proxy ARP function on links where the mobile node same time, implementations not supporting the Proxy ARP function
uses ARP for seeking address resolutions for the destinations on on links where the mobile node uses ARP for seeking address
the mobile node's home subnet will result in communication resolutions for the destinations on the mobile node's home subnet
failure. will result in communication failure.
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 Home Address Request Option 3.3.1. IPv4 Home Address Request Option
A new option, IPv4 Home Address Request Option is defined for use A new option, the IPv4 Home Address Request option, is defined for
with the Proxy Binding Update message sent by the mobile access use with the Proxy Binding Update message sent by the mobile access
gateway to the local mobility anchor. This option is used for gateway to the local mobility anchor. This option is used to request
requesting IPv4 home address assignment for the mobile node. IPv4 home address assignment for the mobile node.
The IPv4 Home Address Request option has an alignment requirement of The IPv4 Home Address Request option has an alignment requirement of
4n. Its format is as follows: 4n. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Prefix-len | Reserved | | Type | Length |Prefix-len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Home Address Request Option Figure 3: IPv4 Home Address Request Option
Type Type
IANA 36
Length Length
8-bit unsigned integer indicating the length of the option in An 8-bit unsigned integer indicating the length of the option
octets, excluding the type and length fields. This field MUST in octets, excluding the Type and Length fields. This field
be set to (6). MUST be set to (6).
Prefix-len Prefix-len
This 6-bit unsigned integer indicating the prefix length of the This 6-bit unsigned integer indicating the prefix length of the
IPv4 home address contained in the option. mobile node's IPv4 home network corresponding to the IPv4 home
address contained in the option.
Reserved Reserved
This 10-bit field is unused for now. The value MUST be This 10-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 home address IPv4 home address
This four-byte field containing the IPv4 home address that is This 4-byte field containing the IPv4 home address that is
being requested. The value of 0.0.0.0 is used for requesting being requested. The value of 0.0.0.0 is used to request that
the local mobility anchor to perform the address allocation. the local mobility anchor perform the address allocation.
3.3.2. IPv4 Home Address Reply Option 3.3.2. IPv4 Home Address Reply Option
A new option, IPv4 Home Address Reply Option is defined for using it A new option, the IPv4 Home Address Reply option, is defined for use
in the Proxy Binding Acknowledgment message sent by the local in the Proxy Binding Acknowledgement message sent by the local
mobility anchor to the mobile access gateway. This option can be mobility anchor to the mobile access gateway. This option can be
used for sending the assigned mobile node's IPv4 home address. used to send the assigned mobile node's IPv4 home address.
The IPv4 Home Address Reply option has an alignment requirement of The IPv4 Home Address Reply option has an alignment requirement of
4n. Its format is as follows: 4n. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status |Pref-len |Res| | Type | Length | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Home Address Reply Option Figure 4: IPv4 Home Address Reply Option
Type Type
IANA 37
Length Length
8-bit unsigned integer indicating the length of the option in An 8-bit unsigned integer indicating the length of the option
octets, excluding the type and length fields. This field MUST in octets, excluding the Type and Length fields. This field
be set to (6). MUST be set to (6).
Status Status
Indicates success or failure for the IPv4 home address Indicates success or failure for the IPv4 home address
assignment. Values from 0 to 127 indicate success. Higher assignment. Values from 0 to 127 indicate success. Higher
values (128 to 255) indicate failure. The following status values (128 to 255) indicate failure. The following Status
values are currently allocated by this document: values are currently allocated by this document:
0 Success 0 Success
128 Failure, reason unspecified 128 Failure, reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Incorrect IPv4 home address 130 Incorrect IPv4 home address
skipping to change at page 26, line 4 skipping to change at page 24, line 31
0 Success 0 Success
128 Failure, reason unspecified 128 Failure, reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Incorrect IPv4 home address 130 Incorrect IPv4 home address
131 Invalid IPv4 address 131 Invalid IPv4 address
132 Dynamic IPv4 home address assignment not available 132 Dynamic IPv4 home address assignment not available
Prefix-len Prefix-len
This 6-bit unsigned integer is used for carrying the prefix This 6-bit unsigned integer is used to carry the prefix length
length of the mobile node's IPv4 home network corresponding the of the mobile node's IPv4 home network corresponding to the
IPv4 home address contained in the option. IPv4 home address contained in the option.
Reserved (Res) Reserved (Res)
This 2-bit field is unused for now. The value MUST be This 2-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 home address IPv4 home address
This four-byte field is used for carrying the IPv4 home address This 4-byte field is used to carry the IPv4 home address
assigned to the mobile node. assigned to the mobile node.
3.3.3. IPv4 Default-Router Address Option 3.3.3. IPv4 Default-Router Address Option
A new option, IPv4 Default-Router Address Option is defined for using A new option, the IPv4 Default-Router Address option, is defined for
it in the Proxy Binding Acknowledgment message sent by the local use in the Proxy Binding Acknowledgement message sent by the local
mobility anchor to the mobile access gateway. This option can be mobility anchor to the mobile access gateway. This option can be
used for sending the mobile node's IPv4 default router address. used to send the mobile node's IPv4 default router address.
The IPv4 Default-Router Address option has an alignment requirement The IPv4 Default-Router Address option has an alignment requirement
of 4n. Its format is as follows: of 4n. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | | Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default-Router Address | | IPv4 Default-Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv4 Default-Router Address Option Figure 5: IPv4 Default-Router Address Option
Type Type
IANA
38
Length Length
8-bit unsigned integer indicating the length of the option in An 8-bit unsigned integer indicating the length of the option
octets, excluding the type and length fields. This field MUST in octets, excluding the Type and Length fields. This field
be set to (6). MUST be set to (6).
Reserved (R) Reserved (R)
This 16-bit field is unused for now. The value MUST be This 16-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the initialized to (0) by the sender and MUST be ignored by the
receiver. receiver.
IPv4 Default-Router Address IPv4 Default-Router Address
A four-byte field containing the mobile node's default router A 4-byte field containing the mobile node's default router
address. address.
3.3.4. IPv4 DHCP Support Mode 3.3.4. IPv4 DHCP Support Mode Option
A new option, IPv4 DHCP Support Mode Option is defined for using it A new option, the IPv4 DHCP Support Mode option, is defined for use
in the Proxy Binding Acknowledgment message sent by the local in the Proxy Binding Acknowledgement message sent by the local
mobility anchor to the mobile access gateway. This option can be mobility anchor to the mobile access gateway. This option can be
used for notifying the mobile access gateway, if it should function used to notify the mobile access gateway as to whether it should
as a DHCP Server or a DHCP Relay for the attached mobile node. 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 The IPv4 DHCP Support Mode option has no alignment requirement. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |S| | Type | Length | Reserved (R) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv4 DHCP Support Mode Option Figure 6: IPv4 DHCP Support Mode Option
Type Type
IANA 39
Length Length
8-bit unsigned integer indicating the length of the option in An 8-bit unsigned integer indicating the length of the option
octets, excluding the type and length fields. This field MUST in octets, excluding the Type and Length fields. This field
be set to 2. MUST be set to 2.
Reserved (R) Reserved (R)
This 15-bit field is unused for now. The value MUST be This 15-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the initialized to (0) by the sender and MUST be ignored by the
receiver. receiver.
DHCP Support Mode (S) DHCP Support Mode (S)
A 1-bit field that specifies the DHCP support mode. This flag A 1-bit field that specifies the DHCP support mode. This flag
indicates if the mobile access gateway should function as a indicates whether the mobile access gateway should function as
DHCP Server or a DHCP Relay for the attached mobile node. The a DHCP Server or a DHCP Relay for the attached mobile node.
flag value of (0) indicates the mobile access gateway should The flag value of (0) indicates the mobile access gateway
act as a DHCP Relay and the flag value of (1) indicates it should act as a DHCP Relay, and the flag value of (1) indicates
should act as a DHCP Server. it should act as a DHCP Server.
3.3.5. Status Codes 3.3.5. Status Codes
This document defines the following new Status values for use in the This document defines the following new Status values for use in the
Proxy Binding Acknowledgement message. These values are to be Proxy Binding Acknowledgement message. These values are to be
allocated from the same numbering space, as defined in Section 6.1.8 allocated from the same numbering space, as defined in Section 6.1.8
of [RFC3775]. of [RFC3775].
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
Mobile node not authorized for IPv4 mobility service. Mobile node not authorized for IPv4 mobility service.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
Mobile node not authorized for the requesting IPv4 home address Mobile node not authorized for the requesting IPv4 home address.
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
Mobile node not authorized for IPv6 mobility service. Mobile node not authorized for IPv6 mobility service.
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
Multiple IPv4 home address assignment not supported Multiple IPv4 home address assignments not supported.
3.4. Supporting DHCP-Based Address Configuration 3.4. Supporting DHCP-Based Address Configuration
This section explains how DHCP-based address configuration support This section explains how DHCP-based address configuration support
can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It
explains the protocol operation, supported DHCP server deployment explains the protocol operation, supported DHCP server deployment
configurations and the protocol interactions between DHCP agents and configurations, and the protocol interactions between DHCP agents and
mobility entities in each of the supported configurations. mobility entities in each of the supported configurations.
This specification supports the following two DHCP deployment This specification supports the following two DHCP deployment
configurations. configurations.
o DHCP relay agent co-located with the mobile access gateway. o DHCP relay agent co-located with the mobile access gateway.
o DHCP server co-located in the mobile access gateway. o DHCP server co-located in the mobile access gateway.
The following are the configuration requirements: The following are the configuration requirements:
o The DHCP server or the DHCP relay agent configured on the mobile o The DHCP server or the DHCP relay agent configured on the mobile
access gateway is required to have an IPv4 address for exchanging access gateway is required to have an IPv4 address for exchanging
the DHCP messages with the mobile node. This address is the the DHCP messages with the mobile node. This address is the
mobile node's default router address provided by the local mobile node's default router address provided by the local
mobility anchor. Optionally, all the DHCP servers co-located with mobility anchor. Optionally, all the DHCP servers co-located with
the mobile access gateways in the Proxy Mobile IPv6 domain can be the mobile access gateways in the Proxy Mobile IPv6 domain can be
configured with a fixed IPv4 address. This fixed address can be configured with a fixed IPv4 address. This fixed address can be
potentially an IPv4 private address [RFC1918] that can be used for an IPv4 private address [RFC1918] that can be used for the DHCP
the DHCP protocol communication on any of the access links. This protocol communication on any of the access links. This address
address will be used as the server identifier in the DHCP will be used as the server identifier in the DHCP messages.
messages.
o A DHCP server identifies a DHCP interface from the contents of the o A DHCP server identifies a DHCP interface from the contents of the
DHCP "Client-identifier" option [RFC2132], if present, or from the DHCP "Client-identifier" option [RFC2132], if present, or from the
client hardware address (chaddr), as specified in [RFC2131]. Note client hardware address (chaddr), as specified in [RFC2131]. Note
that the name "Client-identifier" is a misnomer as it actually that the name "Client-identifier" is a misnomer as it actually
identifies an interface and not the client. The DHCP server uses identifies an interface and not the client. The DHCP server uses
this identity to identify the interface for which the address is this identity to identify the interface for which the address is
assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach
to the network through multiple interfaces and can obtain address to the network through multiple interfaces and can obtain address
configuration for each of its interfaces. Additionally, it may configuration for each of its interfaces. Additionally, it may
perform handoffs between its interfaces. Following are the perform handoffs between its interfaces. The following are the
related considerations with respect to the identification related considerations with respect to the identification
presented to the DHCP server. presented to the DHCP server.
* If the mobile node attaches to the Proxy Mobile IPv6 domain * If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple physical interfaces, the DHCP server will through multiple physical interfaces, the DHCP server will
uniquely identify each of those interfaces and will perform uniquely identify each of those interfaces and will perform
address assignment. The DHCP server will identify the address assignment. The DHCP server will identify the
interface as specified in RFC 2131. The mobile node SHOULD interface as specified in RFC 2131. The mobile node SHOULD
generate and use the "Client-identifier" for each physical generate and use the "Client-identifier" for each physical
interface according to [RFC4361]. Any time the mobile node interface according to [RFC4361]. Any time the mobile node
performs an handoff of a physical interface to a different performs a handoff of a physical interface to a different
mobile access gateway, using the same interface, the DHCP mobile access gateway, using the same interface, the DHCP
server will always be able to identify the binding using the server will always be able to identify the binding using the
presented identifier. The presented identifier (either the presented identifier. The presented identifier (either the
"Client-identifier" or the hardware address) will remain as the "Client-identifier" or the hardware address) will remain as the
primary key for each binding, just as how they are unique in a primary key for each binding, just as how they are unique in a
Binding Cache entry. Binding Cache entry.
* If the mobile node is capable of performing handoff between * If the mobile node is capable of performing a handoff between
interfaces, as per [RFC5213], a "Client-identifier" value MUST interfaces, as per [RFC5213], a "Client-identifier" value MUST
be used for the attachment point that is not tied to any of the be used for the attachment point that is not tied to any of the
physical interfaces. The identifier MUST be generated physical interfaces. The identifier MUST be generated
according to [RFC4361], which guarantees that the identifier is according to [RFC4361], which guarantees that the identifier is
stable and unique across all "Client-identifier" values in use stable and unique across all "Client-identifier" values in use
in the Proxy Mobile IPv6 domain. in the Proxy Mobile IPv6 domain.
o All the DHCP servers co-located with the mobile access gateways in o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain can be configured with the same set of a Proxy Mobile IPv6 domain can be configured with the same set of
DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure DHCP option values (e.g., DNS Server, SIP Server, etc.) to ensure
the mobile node receives the same configuration values on any of the mobile node receives the same configuration values on any of
the access links in that Proxy Mobile IPv6 domain. the access links in that Proxy Mobile IPv6 domain.
3.4.1. DHCP Server co-located with the Mobile Access Gateway 3.4.1. DHCP Server Co-Located with the Mobile Access Gateway
This section explains the operational sequence of home address This section explains the operational sequence of home address
assignment operation when the DHCP server is co-located with the assignment operation when the DHCP server is co-located with the
mobile access gateway. mobile access gateway.
MN MAG(DHCP-S) LMA MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER |------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update | |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| 4. Tunnel/Route Setup | |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA) |<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK |<------| | 7. DHCPACK
| | | | | |
* It is possible the MAG may have already completed the Proxy Mobile
IPv6 signaling with the LMA for requesting both IPv6 home network
prefix(es) and IPv4 home address assignment prior to step-1. In
such event, the Proxy Mobile IPv6 signaling steps (step-2 to
step-4) above are not relevant.
* It is possible the MAG may have initially completed the Proxy
Mobile IPv6 signaling prior to Step-1, but only for requesting
IPv6 home network prefix(es) and may later request IPv4 home
address assignment after detecting the DHCP triggers from the
mobile node as shown above.
* The MAG may choose to ignore the DHCPDISCOVER messages till the
Proxy Mobile IPv6 signaling is successfully completed, or it may
choose to send a delayed response for reducing the additional
delay waiting for a new DHCPDISCOVER message from the mobile node.
Figure 7: Overview of DHCP Server located at Mobile Access Gateway Figure 7: Overview of DHCP Server Located at Mobile Access Gateway
o It is possible that the mobile access gateway may have already
completed the Proxy Mobile IPv6 signaling with the local mobility
anchor to request both IPv6 home network prefix(es) and IPv4 home
address assignment prior to Step 1. In such an event, the Proxy
Mobile IPv6 signaling steps (Steps 2 to 4) above are not relevant.
o It is possible the mobile access gateway may have initially
completed the Proxy Mobile IPv6 signaling prior to Step 1, but
only for requesting IPv6 home network prefix(es), and it may later
request IPv4 home address assignment after detecting the DHCP
triggers from the mobile node as shown above.
o The mobile access gateway may choose to ignore the DHCPDISCOVER
messages until the Proxy Mobile IPv6 signaling is successfully
completed, or it may choose to send a delayed response for
reducing the additional delay waiting for a new DHCPDISCOVER
message from the mobile node.
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o For acquiring the mobile node's IPv4 home address from the local o To acquire the mobile node's IPv4 home address from the local
mobility anchor, the mobile access gateway will initiate Proxy mobility anchor, the mobile access gateway will initiate Proxy
Mobile IPv6 signaling with the local mobility anchor. Mobile IPv6 signaling with the local mobility anchor.
o After the successful completion of the Proxy Mobile IPv6 signaling o After the successful completion of the Proxy Mobile IPv6 signaling
and upon acquiring the mobile node's IPv4 home address from the and upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the DHCP server on the mobile access local mobility anchor, the DHCP server on the mobile access
gateway will send a DHCPOFFER message [RFC2131] to the mobile gateway will send a DHCPOFFER message [RFC2131] to the mobile
node. The offered address will be the mobile node's IPv4 home node. The offered address will be the mobile node's IPv4 home
address, assigned by the local mobility anchor. The DHCPOFFER address, assigned by the local mobility anchor. The DHCPOFFER
message will also have the subnet mask option [RFC2132] and router message will also have the Subnet Mask option [RFC2132] and Router
option [RFC2132], with the values in those options set to the option [RFC2132], with the values in those options set to the
mobile node's IPv4 home subnet mask and default router address mobile node's IPv4 home subnet mask and default router address,
respectively. Additionally, the Server Identifier option will be respectively. Additionally, the Server Identifier option will be
included and with the value in the option set to the default included and with the value in the option set to the default
router address. router address.
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 [RFC2131]. will send DHCPACK message, as per [RFC2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff): IPv4 Home Address Renewal with the DHCP Server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state o Any time the mobile node goes into the DHCP RENEWING state
[RFC2131], it simply unicasts the DHCPREQUEST message including [RFC2131], it simply unicasts the DHCPREQUEST message including
the assigned IPv4 home address in the 'requested IP address' the assigned IPv4 home address in the 'Requested IP Address'
option. The DHCPREQUEST is sent to the address specified in option. The DHCPREQUEST is sent to the address specified in the
Server Identifier option of the previously received DHCPOFFER and Server Identifier option of the previously received DHCPOFFER and
DHCPACK messages. DHCPACK 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 the DHCP server (After Handoff): IPv4 Home Address Renewal with the DHCP Server (after Handoff):
When the mobile node goes into the DHCP RENEWING state [RFC2131], it When the mobile node goes into the DHCP RENEWING state [RFC2131], 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 update the DHCP
server address and uses the address of the DHCP server that is co- server address and use the address of the DHCP server that is co-
located with the new mobile access gateway. The following approach located with the new mobile access gateway. The following approach
can be adopted to ensure the mobile node uses the DHCP server on the can be adopted to ensure the mobile node uses the DHCP server on the
attached link. attached link.
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 (IPv4 HoA) or DHCPNACK BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : | | : |
* The use of a fixed DHCP server address on all DHCP servers * The use of a fixed DHCP server address on all DHCP servers
Figure 8: Address renewal with the DHCP server Figure 8: Address Renewal with the DHCP Server
o The use of a stable address, either the IPv4 default router o The use of a stable address, either the IPv4 default router
address of the mobile node, or a fixed IPv4 address common in that address of the mobile node or a fixed IPv4 address common in that
Proxy Mobile IPv6 domain, as the DHCP server Id will ensure the Proxy Mobile IPv6 domain, as the DHCP Server Identifier will
DHCPREQUEST message sent by the mobile node for renewing the ensure the DHCPREQUEST message sent by the mobile node to renew
address will be received by the new mobile access gateway on the the address will be received by the new mobile access gateway on
attached link. the attached link.
o The mobile access gateway after completing the Proxy Mobile IPv6 o The mobile access gateway after completing the Proxy Mobile IPv6
signaling and upon acquiring the IPv4 home address of the mobile signaling and upon acquiring the IPv4 home address of the mobile
node will return the address in the DHCPACK message. However, if node will return the address in the DHCPACK message. However, if
the mobile access gateway is unable to complete the Proxy Mobile the mobile access gateway is unable to complete the Proxy Mobile
IPv6 signaling or is unable to acquire the same IPv4 address as IPv6 signaling or is unable to acquire the same IPv4 address as
requested by the mobile node, it will send a DHCPNACK message requested by the mobile node, it will send a DHCPNACK message
[RFC2131] to the mobile node, as shown in Figure 8. [RFC2131] to the mobile node, as shown in Figure 8.
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 agent is co-located with each mobile access gateway. A A DHCP relay agent is co-located with each mobile access gateway. A
DHCP server is located somewhere in the Proxy Mobile IPv6 domain DHCP server is located somewhere in the Proxy Mobile IPv6 domain
(e.g., is co-located with the local mobility anchor). Figure 9 shows (e.g., is co-located with the local mobility anchor). Figure 9 shows
the sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| | 3. Tunnel/Route Setup* | |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) 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 (IPv4 HoA) via DHCP-R |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | | | | |
* The Proxy Mobile IPv6 signaling (starting at Step-1) and the
DHCP address configuration (starting at Step-4) may start in any
order. However, the DHCPOFFER (Step-5) and the immediate steps
following it will occur in the specified order and only after the
Tunnel/Route Setup (Step-3).
* It is possible the MAG may have initially completed the Proxy
Mobile IPv6 signaling with the LMA only for requesting IPv6 home
network prefix(es) and may later request IPv4 home address
assignment after detecting the DHCP triggers from the mobile node
(after Step-4).
* The MAG may choose to ignore the DHCPDISCOVER messages till the
Proxy Mobile IPv6 signaling is successfully completed, or it may
choose to send a delayed response for reducing the additional
delay waiting for a new DHCPDISCOVER message from the mobile node.
Figure 9: Overview of the DHCP relay located at mobile access gateway Figure 9: Overview of the DHCP Relay Located at Mobile Access Gateway
o The Proxy Mobile IPv6 signaling (starting at Step 1) and the DHCP
address configuration (starting at Step 4) may start in any order.
However, the DHCPOFFER (Step 5) and the immediate steps following
it will occur in the specified order and only after the Tunnel/
Route Setup (Step 3).
o It is possible the mobile access gateway may have initially
completed the Proxy Mobile IPv6 signaling with the local mobility
anchor only to request IPv6 home network prefix(es) and may later
request IPv4 home address assignment after detecting the DHCP
triggers from the mobile node (after Step 4).
o The mobile access gateway may choose to ignore the DHCPDISCOVER
messages until the Proxy Mobile IPv6 signaling is successfully
completed, or it may choose to send a delayed response for
reducing the additional delay waiting for a new DHCPDISCOVER
message from the mobile node.
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o For acquiring the mobile node's IPv4 home address from the local o To acquire the mobile node's IPv4 home address from the local
mobility anchor, the mobile access gateway will initiate Proxy mobility anchor, the mobile access gateway will initiate Proxy
Mobile IPv6 signaling with the local mobility anchor. Mobile IPv6 signaling with the local mobility anchor.
o After the successful completion of the Proxy Mobile IPv6 signaling o After the successful completion of the Proxy Mobile IPv6 signaling
and upon acquiring the mobile node's IPv4 home address from the and upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the mobile access gateway will enable local mobility anchor, the mobile access gateway will enable
forwarding for all the DHCP messages between the mobile node and forwarding for all the DHCP messages between the mobile node and
the DHCP server. the DHCP server.
o The DHCP relay agent on the mobile access gateway will add the o The DHCP relay agent on the mobile access gateway will add the
DHCP relay agent information option [RFC3046] to the DHCPDISCOVER DHCP Relay Agent Information option [RFC3046] to the DHCPDISCOVER
message. The assigned IPv4 home address will be included in the message. The assigned IPv4 home address will be included in the
Agent Remote ID Sub-option of the DHCP relay agent information Agent Remote ID Sub-option of the DHCP Relay Agent Information
option. This sub-option is used as a hint for requesting the DHCP option. This sub-option is used as a hint for requesting the DHCP
server to allocate that specific IPv4 address. server to allocate that specific IPv4 address.
o On receiving a DHCPOFFER message from the DHCP server, the mobile o On receiving a DHCPOFFER message from the DHCP server, the mobile
access gateway will ensure the assigned address is currently access gateway will ensure the assigned address is currently
assigned by the local mobility anchor to that mobile node. If assigned by the local mobility anchor to that mobile node. If
this address is different from what is assigned to the mobile this address is different from what is assigned to the mobile
node, then the mobile access gateway will drop the DHCPOFFER node, then the mobile access gateway will drop the DHCPOFFER
message and an administrative error message will be logged. message and an administrative error message will be logged.
o When the DHCP messages are sent over administrative boundaries, o When the DHCP messages are sent over administrative boundaries,
the operators needs to ensure these messages are secured. All the the operators need to ensure these messages are secured. All the
DHCP messages relayed by the mobile access gateway can be tunneled DHCP messages relayed by the mobile access gateway can be tunneled
to the local mobility anchor if needed. Alternatively, if the to the local mobility anchor if needed. Alternatively, if the
network in the Proxy Mobile IPv6 domain is secure enough, the network in the Proxy Mobile IPv6 domain is secure enough, the
mobile access gateway can just relay the DHCP messages to the mobile access gateway can just relay the DHCP messages to the
server. To achieve this, all the mobile access gateways needs to server. To achieve this, all the mobile access gateways need to
have a route towards the DHCP server. have a route towards the DHCP server.
IPv4 Home Address Renewal to the same DHCP server: (No Handoff) IPv4 Home Address Renewal to the same DHCP Server: (No Handoff)
o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it
directly unicasts DHCPREQUEST messages to the DHCP server. The directly unicasts DHCPREQUEST messages to the DHCP server. The
DHCP relay agent may not detect any changes in the DHCP state. DHCP relay agent may not detect any changes in the DHCP state.
For example, if the mobile node releases the IPv4 address, the For example, if the mobile node releases the IPv4 address, the
relay agent would not be aware of it. The following describes relay agent would not be aware of it. The following describes
additional mechanisms for the mobile access gateway to detect any additional mechanisms for the mobile access gateway to detect any
changes in the DHCP state. changes in the DHCP state.
* The DHCP relay agent can intercept all IPv4 DHCP packets * The DHCP relay agent can intercept all IPv4 DHCP packets
destined to the set of addresses used within the Proxy Mobile destined to the set of addresses used within the Proxy Mobile
IPv6 domain as DHCP addresses. Since the link between a mobile IPv6 domain as DHCP addresses. Since the link between a mobile
node and a mobile access gateway is the point-to-point link, node and a mobile access gateway is the point-to-point link,
the mobile access gateway will be in path for all the messages. the mobile access gateway will be in path for all the messages.
* The DHCP relay agent can use the DHCP Server Identifier * The DHCP relay agent can use the DHCP Server Identifier
Override Sub-option [RFC5107] to be in path for all the DHCP Override Sub-option [RFC5107] to be in path for all the DHCP
message flows. The DHCP client uses the DHCP server address message flows. The DHCP client uses the DHCP server address
which is overridden by the DHCP relay agent address as a that is overridden by the DHCP relay agent address as a
destination address of DHCPREQUEST. The DHCP Server Identifier destination address of DHCPREQUEST. The DHCP Server Identifier
Override Sub-option is recommended only when the fixed DHCP Override Sub-option is recommended only when the fixed DHCP
relay address is configured on all the mobile access gateways. relay address is configured on all the mobile access gateways.
Otherwise, the DHCP relay agent address is changed when the Otherwise, the DHCP relay agent address is changed when the
mobile node changes the attached mobile access gateway. mobile node changes the attached mobile access gateway.
o However, if the DHCP server is co-located with the local mobility o However, if the DHCP server is co-located with the local mobility
anchor, then the DHCP relay agent is not required to intercept the anchor, then the DHCP relay agent is not required to intercept the
unicast DHCP messages between the mobile node and the DHCP server. unicast DHCP messages between the mobile node and the DHCP server.
This is because the local mobility anchor will ensure that the This is because the local mobility anchor will ensure that the
DHCP state is consistent with the PMIPv6 binding that exists for DHCP state is consistent with the Proxy Mobile IPv6 binding that
the IPv4 address. exists for the IPv4 address.
o Once the mobile access gateway intercepts the DHCP message from o Once the mobile access gateway intercepts the DHCP message from
the mobile node to the DHCP server, it can verify if the mobile the mobile node to the DHCP server, it can verify if the mobile
node is negotiating the same IPv4 address that the local mobility node is negotiating the same IPv4 address that the local mobility
anchor allocated for that mobile node. If the address in the anchor allocated for that mobile node. If the address in the
DHCPREQUEST message does not match with the IPv4 address allocated DHCPREQUEST message does not match with the IPv4 address allocated
for the mobile node, then the mobile access gateway SHOULD drop for the mobile node, then the mobile access gateway SHOULD drop
the DHCP message and an administrative error message can be the DHCP message and an administrative error message can be
logged. logged.
o Any time the mobile access gateway detects that the mobile node o Any time the mobile access gateway detects that the mobile node
has released its IPv4 address, it can send a Proxy Binding Update has released its IPv4 address, it can send a Proxy Binding Update
to the local mobility anchor and de-register the IPv4 mobility to the local mobility anchor and de-register the IPv4 mobility
session. session.
3.4.3. Common DHCP Considerations 3.4.3. Common DHCP Considerations
The following DHCP related considerations are common to both the The following DHCP-related considerations are common to both the
supported configuration modes, specified in Section 3.4.1 and Section supported configuration modes, specified in Sections 3.4.1 and 3.4.2.
3.4.2.
o When a mobile node sends a DHCPDISCOVER message [RFC2131], the o When a mobile node sends a DHCPDISCOVER message [RFC2131], the
DHCP server or the relay agent co-located with the mobile access DHCP server or the relay agent co-located with the mobile access
gateway will trigger the mobile access gateway to complete the gateway will trigger the mobile access gateway to complete the
Proxy Mobile IPv6 signaling. This is the required interaction Proxy Mobile IPv6 signaling. This is the required interaction
between these two protocols. The mobile access gateway on between these two protocols. The mobile access gateway, on
receiving this trigger will check if there is already an assigned receiving this trigger, will check if there is already an assigned
IPv4 home address for the mobile node, from the local mobility IPv4 home address for the mobile node, from the local mobility
anchor. If there is no assigned IPv4 home address assigned for anchor. If there is no assigned IPv4 home address assigned for
that mobile node, the mobile access gateway will complete the that mobile node, the mobile access gateway will complete the
Proxy Mobile IPv6 signaling with the local mobility anchor by Proxy Mobile IPv6 signaling with the local mobility anchor by
sending a Proxy Binding Update message. sending a Proxy Binding Update message.
o The mobile node needs to be identified by the MN-Identifier, as o The mobile node needs to be identified by the MN-Identifier, as
specified in Section 6.6 of [RFC5213]. This identity should be specified in Section 6.6 of [RFC5213]. This identity should be
associated to the DHCP messages sent by the mobile node. associated to the DHCP messages sent by the mobile node.
o The mobile access gateway will drop all the DHCPDISCOVER messages o The mobile access gateway will drop all the DHCPDISCOVER messages
till it completes the Proxy Mobile IPv6 signaling. If the mobile until it completes the Proxy Mobile IPv6 signaling. If the mobile
access gateway is unable to complete the Proxy Mobile IPv6 access gateway is unable to complete the Proxy Mobile IPv6
signaling, or, if the local mobility anchor does not assign an signaling, or, if the local mobility anchor does not assign an
IPv4 address for the mobile node, the mobile access gateway MUST IPv4 address for the mobile node, the mobile access gateway MUST
NOT enable IPv4 home address mobility support for the mobile node NOT enable IPv4 home address mobility support for the mobile node
on that access link. on that access link.
o The trigger for initiating Proxy Mobile IPv6 signaling can also be o The trigger for initiating Proxy Mobile IPv6 signaling can also be
delivered to the mobile access gateway as part of a context delivered to the mobile access gateway as part of a context
transfer from the previous mobile access gateway, or delivered transfer from the previous mobile access gateway, or delivered
from the other network elements in the radio network, the details from the other network elements in the radio network, the details
of which are outside the scope of this document. of which are outside the scope of this document.
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST o The DHCPOFFER message [RFC2131] sent to the mobile node MUST
include the Subnet Mask option [RFC2132] and the Router option include the Subnet Mask option [RFC2132] and the Router option
[RFC2132]. The values in the Subnet Mask option and Router option [RFC2132]. The values in the Subnet Mask option and Router option
MUST be set to the mobile node's IPv4 home subnet mask and its MUST be set to the mobile node's IPv4 home subnet mask and its
default router address respectively. default router address, respectively.
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST o The DHCPOFFER message [RFC2131] sent to the mobile node MUST
include the Interface MTU option [RFC2132]. The DHCP servers in include the Interface MTU option [RFC2132]. The DHCP servers in
the Proxy Mobile IPv6 domain MUST be configured to include the the Proxy Mobile IPv6 domain MUST be configured to include the
Interface MTU option. The MTU value SHOULD reflect the tunnel MTU Interface MTU option. The MTU value SHOULD reflect the tunnel MTU
for the bi-directional tunnel between the mobile access gateway for the bidirectional tunnel between the mobile access gateway and
and the local mobility anchor. the local mobility anchor.
o The DHCP lease length allocated to the mobile node's IPv4 home o The DHCP lease length allocated to the mobile node's IPv4 home
address may be different from the binding lifetime at the local address may be different from the binding lifetime at the local
mobility anchor for that mobile node's session. It is not mobility anchor for that mobile node's session. It is not
possible to keep these lifetimes synchronized and so its not possible to keep these lifetimes synchronized, and so its not
required that the configured lifetimes should be kept same in both required that the configured lifetimes should be kept same in both
DHCP and Proxy Mobile IPv6. DHCP and Proxy Mobile IPv6.
o When the mobile node performs an handoff from one mobile access o When the mobile node performs a handoff from one mobile access
gateway to another, the mobile access gateway on the new link will gateway to another, the mobile access gateway on the new link will
initiate the Proxy Mobile IPv6 signaling with the local mobility initiate the Proxy Mobile IPv6 signaling with the local mobility
anchor. On completing the Proxy Mobile IPv6 signaling, the mobile anchor. On completing the Proxy Mobile IPv6 signaling, the mobile
access gateway has the proper IPv4 address state that the local access gateway has the proper IPv4 address state that the local
mobility anchor has allocated for the mobile node and which can be mobility anchor has allocated for the mobile node and that can be
used for supporting DHCP based address configuration on that link. used for supporting DHCP based address configuration on that link.
o Any time the mobile node detects a link change event due to o Any time the mobile node detects a link change event due to
handoff, or due to other reasons such as re-establishment of the handoff, or due to other reasons such as re-establishment of the
link-layer, the following are the mobile node's considerations link-layer, the following are the mobile node's considerations
with respect to the DHCP protocol. with respect to the DHCP protocol.
* If the mobile node is DNAv4 [RFC4436] capable and if it * If the mobile node is DNAv4-capable (Detecting Network
performs DNAv4 procedures after receiving a link change event, Attachment version 4) [RFC4436] and if it performs DNAv4
it would always detect the same default router on any of the procedures after receiving a link change event, it would always
access links in that Proxy Mobile IPv6 domain, as the mobile detect the same default router on any of the access links in
access gateway configures a fixed link-layer address on all the that Proxy Mobile IPv6 domain, as the mobile access gateway
access links, as per the base Proxy Mobile IPv6 specification configures a fixed link-layer address on all the access links,
[RFC5213]. The mobile node will not perform any DHCP operation as per the base Proxy Mobile IPv6 specification [RFC5213]. The
specifically due to this event. mobile node will not perform any DHCP operation specifically
due to this event.
* If the mobile node is not DNAv4 [RFC4436] capable, after * If the mobile node is not DNAv4-capable [RFC4436], after
receiving the link change event it will enter INIT-REBOOT state receiving the link change event it will enter INIT-REBOOT state
[RFC2131] and will send a DHCPREQUEST message as specified in [RFC2131] and will send a DHCPREQUEST message as specified in
Section 3.7 of [RFC2131]. The mobile node will obtain the same Section 3.7 of [RFC2131]. The mobile node will obtain the same
address configuration as before, as the link change does not address configuration as before, as the link change does not
result in any change at the network layer. result in any change at the network layer.
o The mobile node may release its IPv4 home address at any time by o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC2131]. When the mobile access sending the DHCPRELEASE message [RFC2131]. When the mobile access
gateway detects the DHCPRELEASE message sent by the mobile node, gateway detects the DHCPRELEASE message sent by the mobile node,
it should consider this as a trigger for de-registering the mobile it should consider this as a trigger for de-registering the mobile
node's IPv4 home address. It will apply the considerations node's IPv4 home address. It will apply the considerations
specified in section 3.2.3.3 for performing the de-registration specified in Section 3.2.3.3 for performing the de-registration
procedure. However, this operation MUST NOT release any IPv6 home procedure. However, this operation MUST NOT release any IPv6 home
network prefix(es) assigned to the mobile node. network prefix(es) assigned to the mobile node.
4. IPv4 Transport Support 4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [RFC5213] requires the signaling The Proxy Mobile IPv6 specification [RFC5213] 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. However, in some cases access gateway to be over an IPv6 transport. However, in some cases,
the local mobility anchor and the mobile access gateway are separated the local mobility anchor and the mobile access gateway are separated
by an IPv4 network. by an IPv4 network.
The normal Proxy Mobile IPv6 specification [RFC5213] can be run over The normal Proxy Mobile IPv6 specification [RFC5213] can be run over
an IPv4 transport without any modifications by using a transition an IPv4 transport without any modifications by using a transition
technology that allows IPv6 hosts to communicate over IPv4 networks. technology that allows IPv6 hosts to communicate over IPv4 networks.
For example, the MAG and the LMA could have a simple configured IPv6- For example, the mobile access gateway and the local mobility anchor
over-IPv4 tunnel. Instead of configured tunnels, various mechanisms could have a simple configured IPv6-over-IPv4 tunnel. Instead of
for automatic tunneling could be used, too. To these tunnels, Proxy configured tunnels, various mechanisms for automatic tunneling could
Mobile IPv6 would look just like any other application traffic be used, too. To these tunnels, Proxy Mobile IPv6 would look just
running over IPv6. like any other application traffic running over IPv6.
However, treating Proxy Mobile IPv6 just like any other IPv6 traffic However, treating Proxy Mobile IPv6 just like any other IPv6 traffic
would mean an extra layer of encapsulation for the mobile node's would mean an extra layer of encapsulation for the mobile node's
tunneled data traffic, adding 40 octets of overhead for each packet. tunneled data traffic, adding 40 octets of overhead for each packet.
The extensions defined in this section allow the MAG and the LMA to
communicate over an IPv4 network without this overhead. The extensions defined in this section allow the mobile access
gateway and the local mobility anchor to communicate over an IPv4
network without this overhead.
IPv4-Proxy-CoA IPv4-LMAA IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + | | + - - - - - - + |
+--+ +---+ / \ +---+ +--+ +--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+ +--+ +---+ \ / +---+ +--+
+ - - - - - - + + - - - - - - +
Figure 10: IPv4 Transport Network Figure 10: IPv4 Transport Network
skipping to change at page 38, line 50 skipping to change at page 36, line 31
messages over IPv4 transport and register its IPv4 address as the messages over IPv4 transport and register its IPv4 address as the
care-of address in the mobile node's Binding Cache entry. An IPv4 care-of address in the mobile node's Binding Cache entry. An IPv4
tunnel (with any of the supported encapsulation modes) can be used tunnel (with any of the supported encapsulation modes) can be used
for tunneling the mobile node's data traffic. The following are the for tunneling the mobile node's data traffic. The following are the
key aspects of this feature. key aspects of this feature.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address of the same scope. configured and reachable using an IPv4 address of the same scope.
o The IPv4 addresses used can be private IPv4 addresses, but it is o The IPv4 addresses used can be private IPv4 addresses, but it is
assumed that there is no NAT between the LMA and the MAG. assumed that there is no NAT between the local mobility anchor and
the mobile access gateway. However, it is possible to use UDP
However, it is possible to use UDP encapsulation if other types of encapsulation if other types of middleboxes are present.
middleboxes are present.
o The Mobility Header [RFC3775] is carried inside an IPv4 packet and o The Mobility Header [RFC3775] is carried inside an IPv4 packet
UDP header, using an UDP port number for Proxy Mobile IPv6 with UDP header (IPv4-UDP-MH), using a UDP port number for Proxy
signalling over IPv4. Mobile IPv6 signaling over IPv4.
o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and o The mobile node can be an IPv6, IPv4, or a dual IPv4/IPv6 node and
the IPv4 transport support specified in this section is agnostic the IPv4 transport support specified in this section is agnostic
to the type of address mobility enabled for that mobile node. to the type of address mobility enabled for that mobile node.
o The mobile node's data traffic will be tunneled between the local o The mobile node's data traffic will be tunneled between the local
mobility anchor and the mobile access gateway. There are several mobility anchor and the mobile access gateway. There are several
encapsulation modes available: encapsulation modes available:
* IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). * IPv4 (IPv4 or IPv6 payload packet carried in an IPv4 packet).
If payload protection using IPsec is enabled for the tunneled If payload protection using IPsec is enabled for the tunneled
traffic, the ESP header follows the outer tunnel header. traffic, the Encapsulating Security Payload (ESP) header
follows the outer tunnel header.
* IPv4-UDP (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP (payload packet carried in an IPv4 packet with UDP
header, using a UDP port number for Proxy Mobile IPv6 data; header, using a UDP port number for Proxy Mobile IPv6 data;
this is different port than is used for signalling). If this is different port than is used for signaling). If payload
payload protection using IPsec is enabled, the ESP header protection using IPsec is enabled, the ESP header follows the
follows the outer IPv4 header, as explained in Section 4.3. outer IPv4 header, as explained in Section 4.3.
* IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP
and TLV header) and IPv4-GRE (Payload packet carried in an IPv4 and TLV header) and IPv4-GRE (Payload packet carried in an IPv4
packet with GRE header). Refer to packet with GRE header). Refer to [GREKEY]. If payload
[I-D.ietf-netlmm-grekey-option]. If payload protection using protection using IPsec is enabled, the ESP header follows the
IPsec is enabled, the ESP header follows the outer IPv4 header, outer IPv4 header, as explained in Section 4.3.
as explained in Section 4.3.
4.1. Local Mobility Anchor Considerations 4.1. Local Mobility Anchor Considerations
4.1.1. Extensions to Binding Cache Entry 4.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor [RFC5213] MUST be structure maintained by the local mobility anchor [RFC5213] MUST be
extended with the following additional parameters. It is to be noted extended with the following additional parameters. It is to be noted
that all of these parameters are specified in [RFC5555] and also that all of these parameters are specified in [RFC5555] and also
required here in the present usage context, and are presented here required here in the present usage context, and are presented here
only for completeness. only for completeness.
o The IPv4 Proxy Care-of Address configured on the mobile access o The IPv4 Proxy Care-of Address configured on the mobile access
gateway that sent the Proxy Binding Update message. The address gateway that sent the Proxy Binding Update message. The address
MUST be the same as the source address of the received IPv4 packet MUST be the same as the source address of the received IPv4 packet
that contains the Proxy Binding Update message. However, if the that contains the Proxy Binding Update message. However, if the
received Proxy Binding Update message is not sent as an IPv4 received Proxy Binding Update message is not sent as an IPv4
packet, i.e., when using IPv6 transport, this field in the Binding packet, i.e., when using IPv6 transport, this field in the Binding
Cache entry MUST be set to ALL_ZERO value. Cache entry MUST be set to the ALL_ZERO 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 [RFC5213] MUST be policy profile, specified in Section 6.2 of [RFC5213], MUST be
extended with the following additional fields. These 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 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 Proxy Binding Update message is protected with IPsec ESP, o If the Proxy Binding Update message is protected with IPsec ESP,
IPsec processing happens before the packet is passed to Proxy IPsec processing happens before the packet is passed to Proxy
Mobile IPv6. Mobile IPv6.
o All the considerations from Section 5.3.1 of [RFC5213] except step o All the considerations from Section 5.3.1 of [RFC5213] except Step
1 (about IPsec) MUST be applied on the encapsulated Proxy Binding 1 (about IPsec) MUST be applied on the encapsulated Proxy Binding
Update message. Note that the Checksum field in Mobility Header Update message. Note that the Checksum field in Mobility Header
MUST be ignored. MUST be ignored.
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 bidirectional 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 by applying the The encapsulation mode MUST be determined by applying the
following considerations: following considerations:
* If the (F) flag in the received Proxy Binding Update message is * If the (F) flag in the received Proxy Binding Update message is
set to the value of (1), but if the configuration flag, set to the value of (1), but if the configuration flag,
AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
(0), then the local mobility anchor MUST reject the request (0), then the local mobility anchor MUST reject the request
with the Status field value set to 129 (Administratively with the Status field value set to 129 (Administratively
prohibited). prohibited).
* If the (T) flag is set to (1), or GRE Key option is included, * If the (T) flag is set to (1), or GRE Key option is included,
see [I-D.ietf-netlmm-grekey-option]. see [GREKEY].
* If the (F) flag in the received Proxy Binding Update message is * If the (F) flag in the received Proxy Binding Update message is
set to the value of (1), then the encapsulation mode MUST be set to the value of (1), then the encapsulation mode MUST be
set to IPv4-UDP. Otherwise the encapsulation mode MUST be set set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set
to IPv4. to IPv4.
o The local mobility anchor MUST send the Proxy Binding o The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field value set to (0) Acknowledgement message with the Status field value set to (0)
(Proxy Binding Update Accepted). The message MUST be constructed (Proxy Binding Update accepted). The message MUST be constructed
as specified in Section 4.1.3.2. as specified in Section 4.1.3.2.
4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC5213]. However, if the message as specified in Section 5.3.6 of [RFC5213]. However, if
the Proxy Binding Update message was received over IPv4, the the Proxy Binding Update message was received over IPv4, the
following additional considerations MUST be applied. following additional considerations MUST be applied.
o The IPv6 Header is removed, and the Mobility Header containing the o The IPv6 Header is removed, and the Mobility Header containing the
Proxy Binding Acknowledgement is encapsulated in UDP (with source Proxy Binding Acknowledgement is encapsulated in UDP (with source
port set to TBD1 and destination port set to the source port of port set to 5436 and destination port set to the source port of
received Proxy Binding Update message). The Mobility Header the received Proxy Binding Update message). The Mobility Header
Checksum field MUST be set to zero (and UDP checksum MUST be used Checksum field MUST be set to zero (and the UDP checksum MUST be
instead). used instead).
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 IPsec ESP is used to protect signalling, the packet is o If IPsec ESP is used to protect signaling, the packet is processed
processed using transport mode ESP as described in Section 4.3. using transport mode ESP as described in Section 4.3.
o Figure 11 shows the format of the Proxy Binding Acknowledgement o Figure 11 shows the format of the Proxy Binding Acknowledgement
message sent over IPv4 and protected using ESP. message sent over IPv4 and protected using ESP.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
ESP header (in transport mode) ESP header (in transport mode)
UDP header (sport=TBD1, dport=TBD1) UDP header (sport=5436, dport=5436)
Mobility Header (PBA) Mobility Header (PBA)
Figure 11: Proxy Binding Acknowledgment (PBA) Message sent over Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over
IPv4 IPv4
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
forward the packet through the bi-directional tunnel set up for forward the packet through the bidirectional tunnel set up for
that mobile node. that mobile node.
o The format of the tunneled packet is shown below. The IPv4-UDP- o The format of the tunneled packet is shown below. The IPv4-UDP-
TLV and IPv4-GRE encapsulation modes are described in TLV and IPv4-GRE encapsulation modes are described in [GREKEY].
[I-D.ietf-netlmm-grekey-option].
IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */ IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */
[UDP Header (src port=TBD2, dst port=TBD2] /* If UDP encap nego */ [UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* 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 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP
encapsulation mode) Encapsulation Mode)
o Forwarding Packets Sent by the Mobile Node: o Forwarding Packets Sent by the Mobile Node:
* All the reverse tunneled packets (IPv4 and IPv6) that the local * All the reverse tunneled packets (IPv4 and IPv6) that the local
mobility anchor receives from the mobile access gateway, after mobility anchor receives from the mobile access gateway, after
removing the tunnel header (i.e., the outer IPv4 header along removing the tunnel header (i.e., the outer IPv4 header along
with the UDP and TLV header, if negotiated) MUST be routed to with the UDP and TLV header, if negotiated) MUST be routed to
the destination specified in the inner packet header. These the destination specified in the inner packet header. These
routed packets will have the source address field set to the routed packets will have the source address field set to the
mobile node's home address. mobile node's home address.
4.1.4.2. ECN & Payload Fragmentation Considerations 4.1.4.2. ECN and Payload Fragmentation Considerations
The ECN considerations specified in Section 5.6.3 of [RFC5213] apply The ECN considerations specified in Section 5.6.3 of [RFC5213] apply
for the IPv4 transport tunnels as well. The mobility agents at the for the IPv4 transport tunnels as well. The mobility agents at the
tunnel entry and exit points MUST handle ECN information as specified tunnel entry and exit points MUST handle ECN information as specified
in that document. in that document.
The mobility agents at the tunnel entry and exit points MUST apply The mobility agents at the tunnel entry and exit points MUST apply
the IP packet fragmentation considerations as specified in [RFC4213]. the IP packet fragmentation considerations as specified in [RFC4213].
Additionally they MUST also apply the considerations related to Additionally, they MUST also apply the considerations related to
tunnel error processing and reporting as specified in the same tunnel error processing and reporting as specified in the same
specification. specification.
4.1.4.3. Bi-Directional Tunnel Management 4.1.4.3. Bidirectional Tunnel Management
The Tunnel Management considerations specified in section 5.6.1 of The Tunnel Management considerations specified in Section 5.6.1 of
[RFC5213] apply for the IPv4 transport tunnels as well, with just one [RFC5213] apply for the IPv4 transport tunnels as well, with just one
difference that the encapsulation mode is different. difference that the encapsulation mode is different.
4.2. Mobile Access Gateway Considerations 4.2. Mobile Access Gateway Considerations
4.2.1. Extensions to Binding Update List Entry 4.2.1. Extensions to Binding Update List Entry
To support the IPv4 Transport Support feature, the conceptual Binding To support the IPv4 Transport Support feature, the conceptual Binding
Update List entry data structure maintained by the mobile access Update List entry data structure maintained by the mobile access
gateway [RFC5213] MUST be extended with the following additional gateway [RFC5213] MUST be extended with the following additional
parameters. parameters.
o The IPv4 address of the local mobility anchor. This address can o The IPv4 address of the local mobility anchor. This address can
be obtained from the mobile node's policy profile. be obtained from the mobile node's policy profile.
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
to the local mobility anchor MUST construct the message as specified message to the local mobility anchor, MUST construct the message as
in Section 6.9.1.5 of [RFC5213]. However, if the mobile access specified in Section 6.9.1.5 of [RFC5213]. However, if the mobile
gateway is in an IPv4-only access network, the following additional access gateway is in an IPv4-only access network, the following
considerations MUST be applied. additional considerations MUST be applied.
o The Proxy Binding Update message MUST be sent over IPv4 as o The Proxy Binding Update message MUST be sent over IPv4 as
desribed in Section 4.2.2.1. described in Section 4.2.2.1.
o Just as specified in [RFC5213], when sending a Proxy Binding o Just as specified in [RFC5213], when sending a Proxy Binding
Update message for extending the lifetime of a currently existing Update message for extending the lifetime of a currently existing
mobility session or for de-registering the mobility session, the mobility session or to de-register the mobility session, the Proxy
Proxy Binding Update message MUST be constructed just as the Binding Update message MUST be constructed just as the initial
initial request. request.
Receiving Proxy Binding Acknowledgement Receiving Proxy Binding Acknowledgement:
o If the received Proxy Binding Acknowledgement message is protected o If the received Proxy Binding Acknowledgement message is protected
with IPsec ESP, IPsec processing happens before the packet is with IPsec ESP, IPsec processing happens before the packet is
passed to Proxy Mobile IPv6. Considerations from Section 4 of passed to Proxy Mobile IPv6. Considerations from Section 4 of
[RFC5213] MUST be applied for authenticating and authorizing the [RFC5213] MUST be applied to authenticate and authorize the
message. message.
o All the considerations from Section 6.9.1.2 of [RFC5213] MUST be o All the considerations from Section 6.9.1.2 of [RFC5213] MUST be
applied on the encapsulated Proxy Binding Acknowledgement message. applied on the encapsulated Proxy Binding Acknowledgement message.
Note that the Checksum field in Mobility Header MUST be ignored. Note that the Checksum field in Mobility Header MUST be ignored.
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 set up a bidirectional tunnel to the local mobility anchor.
o Upon accepting the request, the mobile access gateway MUST set up o Upon accepting the request, the mobile access gateway MUST set up
an IPv4 bi-directional tunnel to the local mobility anchor. The an IPv4 bidirectional tunnel to the local mobility anchor. The
tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. tunnel endpoint addresses are the 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:
* If the (T) flag is set to (1), or GRE Key option is included, * If the (T) flag is set to (1), or the GRE Key option is
see [I-D.ietf-netlmm-grekey-option]. included, see [GREKEY].
* If there is a NAT Detection option [RFC5555] in the received * If there is a NAT Detection option [RFC5555] in the received
Proxy Binding Acknowledgement message, and the (F) flag is set Proxy Binding Acknowledgement message, and the (F) flag is set
to value of (1), the encapsulation mode for the tunnel MUST be to value of (1), the encapsulation mode for the tunnel MUST be
set to IPv4-UDP. Otherwise the encapsulation mode MUST be set set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set
to IPv4. to IPv4.
4.2.2.1. Constructing the Proxy Binding Update Message 4.2.2.1. Constructing the Proxy Binding Update Message
o The IPv6 Header is removed, and the Mobility Header containing the o The IPv6 Header is removed, and the Mobility Header containing the
Proxy Binding update message is encapsulated in UDP (with the Proxy Binding Update message is encapsulated in UDP (with the
destination port set to TBD1). The Mobility Header Checksum field destination port set to 5436). The Mobility Header Checksum field
MUST be set to zero (and UDP checksum MUST be used instead). MUST be set to zero (and UDP checksum MUST be used instead).
o The source address in the IPv4 header MUST be set to IPv4-Proxy- o The source address in the IPv4 header MUST be set to IPv4-Proxy-
CoA of the mobile access gateway and the destination address MUST CoA of the mobile access gateway and the destination address MUST
be set to the local mobility anchor's IPv4-LMAA. be set to the local mobility anchor's IPv4-LMAA.
o If the configuration variable ForceIPv4UDPEncapsulationSupport is o If the configuration variable ForceIPv4UDPEncapsulationSupport is
set to value of (1), then the (F) flag in the Proxy Binding Update set to value of (1), then the (F) flag in the Proxy Binding Update
message MUST be set to value of (1). message MUST be set to value of (1).
o If IPsec ESP is used to protect signalling, the packet is o If IPsec ESP is used to protect signaling, the packet is processed
processed using transport mode ESP as described in Section 4.3. using transport mode ESP as described in Section 4.3.
o Figure 13 shows the format of the Proxy Binding Update message o Figure 13 shows the format of the Proxy Binding Update message
sent over IPv4 and protected using ESP. sent over IPv4 and protected using ESP.
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
ESP header (in transport mode) ESP header (in transport mode)
UDP header (sport=TBD1, dport=TBD1) UDP header (sport=5436, dport=5436)
Mobility Header (PBU) Mobility Header (PBU)
Figure 13: Proxy Binding Update (PBU) message sent over IPv4 Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4
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. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes
are described in [I-D.ietf-netlmm-grekey-option]. However, are described in [GREKEY]. However, considerations from Section
considerations from Section 6.10.3 of [RFC5213] MUST be applied 6.10.3 of [RFC5213] MUST be applied with respect the local routing
with respect the local routing and on the use of and on the use of EnableMAGLocalRouting flag.
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=TBD2, dst port=TBD2] /* If UDP encap nego */ [UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src=MN-HOA, dst=CN) IPv6 header (src=MN-HOA, dst=CN)
OR OR
IPv4 header (src=MN-HOA, dst=CN) IPv4 header (src=IPv4-MN-HOA, dst=CN)
Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP
encapsulation mode) Encapsulation Mode)
Forwarding Packets received from the bi-directional tunnel: Forwarding Packets Received from the Bidirectional Tunnel:
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bidirectional 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.
4.3. IPsec Considerations 4.3. IPsec Considerations
4.3.1. PBU and PBA 4.3.1. PBU and PBA
The following section describes how IPsec is used for protecting the The following section describes how IPsec is used to protect the
signaling messages and data packets between the local mobility anchor signaling messages and data packets between the local mobility anchor
and mobile access gateway when using IPv4 transport. and mobile access gateway when using IPv4 transport.
The following are the SPD example entries to protect PBU and PBA on The following are the Security Policy Database (SPD) example entries
the local mobility anchor and mobile access gateway. to protect PBU and PBA on the local mobility anchor and mobile access
gateway.
MAG SPD-S: MAG SPD-S:
- IF local_address = IPv4-Proxy-CoA_1 & - IF local_address = IPv4-Proxy-CoA_1 &
remote_address = IPv4-LMAA_1 & proto = UDP & remote_address = IPv4-LMAA_1 & proto = UDP &
remote_port = TBD1 remote_port = 5436
Then use SA ESP transport mode Then use SA ESP transport mode
LMA SPD-S: LMA SPD-S:
- IF local_address = IPv4-LMAA_1 & - IF local_address = IPv4-LMAA_1 &
remote_address = IPv4-Proxy-CoA_1 & proto = UDP & remote_address = IPv4-Proxy-CoA_1 & proto = UDP &
local_port = TBD1 local_port = 5436
Then use SA ESP transport mode Then use SA ESP transport mode
4.3.2. Payload Packet 4.3.2. Payload Packet
The following are the SPD example entries to protect payload packets The following are the SPD example entries to protect payload packets
on the local mobility anchor and mobile access gateway. Note that on the local mobility anchor and mobile access gateway. Note that
the example SPDs protect all payload packets sent to and from mobile the example SPDs protect all payload packets sent to and from mobile
nodes. If an operator needs to apply a different security mechanism nodes. If an operator needs to apply a different security mechanism
per mobile node, they need to create a SPD and a SA entry per mobile per mobile node, they need to create a SPD and a SA entry per mobile
node. node.
skipping to change at page 46, line 39 skipping to change at page 44, line 18
remote_address != LMAA_1 & proto=any remote_address != LMAA_1 & proto=any
Then use SA ESP tunnel mode Then use SA ESP tunnel mode
LMA SPD-S: LMA SPD-S:
- IF interface = tunnel to Proxy-CoA_1 & - IF interface = tunnel to Proxy-CoA_1 &
local_address != LMAA_1 & local_address != LMAA_1 &
remote_address != Proxy-CoA_1 & proto=any remote_address != Proxy-CoA_1 & proto=any
Then use SA ESP tunnel mode Then use SA ESP tunnel mode
When payload packets are protected by IPsec, payload packets matching When payload packets are protected by IPsec, payload packets matching
to the SPDs are passed to the IPsec module and encapsulated using the the SPDs are passed to the IPsec module and encapsulated using the
tunnel mode ESP. The tunnel mode ESP encapsulated payload packets tunnel mode ESP. The tunnel mode ESP encapsulated payload packets
are then directly sent to the peer mobile access gateway or local are then directly sent to the peer mobile access gateway or local
mobility anchor. If IPsec is not applied to payload packets, then mobility anchor. If IPsec is not applied to payload packets, then
they are encapsulated as shown in Figures 12 and 14. they are encapsulated as shown in Figures 12 and 14.
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
skipping to change at page 48, line 7 skipping to change at page 45, line 7
ForceIPv4UDPEncapsulationSupport ForceIPv4UDPEncapsulationSupport
This flag indicates whether or not the mobile access gateway This flag indicates whether or not the mobile access gateway
should request the mobile node's local mobility anchor to use should request the mobile node's local mobility anchor to use
IPv4-UDP encapsulation mode for the mobile node's data traffic. IPv4-UDP encapsulation mode for the mobile node's data traffic.
The default value for this flag is set to (0), indicating that The default value for this flag is set to (0), indicating that
plain IPv4 encapsulation (without UDP) is used for data traffic. plain IPv4 encapsulation (without UDP) is used for data traffic.
6. IANA Considerations 6. IANA Considerations
This document defines four new Mobility Header options, IPv4 Home This document defines four new Mobility Header options: the IPv4 Home
Address Request option, IPv4 Home Address Reply option, IPv4 Default Address Request option, IPv4 Home Address Reply option, IPv4 Default
Router Address option and IPv4 DHCP Support Mode option. These Router Address option, and IPv4 DHCP Support Mode option. These
options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4 options are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4,
respectively. The Type value for these options needs to be assigned respectively. The Type value for these options has been assigned
from the same number space as allocated for the other mobility from the same number space as allocated for the other mobility
options, as defined in [RFC3775]. options, as defined in [RFC3775].
The IPv4 Home Address Reply option, described in Section 3.3.2 of The IPv4 Home Address Reply option, described in Section 3.3.2 of
this document, introduces a new number space, IPv4 Home Address Reply this document, introduces a new number space, IPv4 Home Address Reply
Status Codes. This document currently reserves the following values. status codes. This document currently reserves the following values.
Approval of any new status code values are to be made through IANA Approval of any new status code values are to be made through IANA
Expert Review. Expert Review.
o 0 Success o 0 Success
o 128 Failure, reason unspecified o 128 Failure, Reason Unspecified
o 129 Administratively prohibited o 129 Administratively prohibited
o 130 Incorrect IPv4 home address o 130 Incorrect IPv4 home address
o 131 Invalid IPv4 address o 131 Invalid IPv4 address
o 132 Dynamic IPv4 home address assignment not available o 132 Dynamic IPv4 home address assignment not available
The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this
document, introduces a new number space, IPv4 DHCP Support Mode document, introduces a new number space, IPv4 DHCP Support Mode
Flags. This document reserves the value 0x1 for the (S) flag. Flags. This document reserves the value 0x1 for the (S) flag.
Approval of this flag values are to be made through IANA Expert Approval of flag values are to be made through IANA Expert Review.
Review. At this point of time there are no thoughts on what the new At this point in time, there are no thoughts on what the new flag
flag allocations can be for and hence this document is leaving this allocations can be, and hence this document leaves this to the
to the discretion of the expert review. discretion of the Expert Review.
This document also defines new status values, used in Proxy Binding This document also defines new Status values, used in Proxy Binding
Acknowledgement message, as described in Section 3.3.5. These values Acknowledgement message, as described in Section 3.3.5. These values
are to be assigned from the same number space as allocated for other have been assigned from the same number space as allocated for other
Status codes [RFC3775]. Each of these allocated values have to be status codes [RFC3775]. Each of these allocated values is greater
greater than 128. than 128.
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
Mobile node not authorized for IPv4 mobility service. Mobile node not authorized for IPv4 mobility service.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
Mobile node not authorized for the requesting IPv4 home address Mobile node not authorized for the requesting IPv4 home
address.
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
Mobile node not authorized for IPv6 mobility service. Mobile node not authorized for IPv6 mobility service.
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
Multiple IPv4 home address assignment not supported Multiple IPv4 home address assignment not supported.
IANA is requested to assign two UDP port numbers, TBD1 and TBD2, for IANA has assigned two UDP port numbers, 5436 and 5437, for "pmip6-
"pmip6-cntl" and "pmip6-data", respectively. cntl" and "pmip6-data", respectively.
7. Security Considerations 7. Security Considerations
All the security considerations from the base Proxy Mobile IPv6 All the security considerations from the base Proxy Mobile IPv6
[RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6 [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6
[RFC5555] apply when using the extensions defined in this document. [RFC5555] specifications apply when using the extensions defined in
Additionally, the following security considerations need to be this document. Additionally, the following security considerations
applied. need to be applied.
This document defines new mobility options for supporting the IPv4 This document defines new mobility options for supporting the IPv4
Home Address assignment and IPv4 Transport Support features. These Home Address assignment and IPv4 Transport Support features. These
options are to be carried in Proxy Binding Update and Proxy Binding options are to be carried in Proxy Binding Update and Proxy Binding
Acknowledgement messages. The required security mechanisms specified Acknowledgement messages. The required security mechanisms specified
in the base Proxy Mobile IPv6 protocol for protecting these signaling in the base Proxy Mobile IPv6 protocol for protecting these signaling
messages are sufficient when carrying these mobility options. messages are sufficient when carrying these mobility options.
This specification describes the use of IPv4 transport for exchanging This specification describes the use of IPv4 transport for exchanging
the signaling messages between the local mobility anchor and the signaling messages between the local mobility anchor and the mobile
mobile access gateway. These can be protected using IPsec as access gateway. These can be protected using IPsec as described in
described in Section 4.3. Section 4.3.
8. Contributors 8. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
people (in alphabetical order): people (in alphabetical order):
Kuntal Chowdhury Kuntal Chowdhury
kchowdhury@starentnetworks.com kchowdhury@starentnetworks.com
Vijay Devarapalli Vijay Devarapalli
vijay.devarapalli@azairenet.com vijay.devarapalli@azairenet.com
Pasi Eronen
Pasi.Eronen@nokia.com
Sangjin Jeong Sangjin Jeong
sjjeong@etri.re.kr sjjeong@etri.re.kr
Basavaraj Patil Basavaraj Patil
basavaraj.patil@nokia.com basavaraj.patil@nokia.com
Myungki Shin Myungki Shin
myungki.shin@gmail.com myungki.shin@gmail.com
9. Acknowledgments 9. Acknowledgements
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in
internet-draft [draft-sgundave-mip6-proxymip6-02.txt"/>. We would "Proxy Mobile IPv6" (March 2007). We would like to thank all the
like to thank all the authors of the document and acknowledge that authors of the document and acknowledge that initial work.
initial work.
Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles
Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen,
Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen,
Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe
Wu and Zu Qiang for their helpful review of this document. Wu, and Zu Qiang for their helpful review of this document.
Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem Also, we would like to thank Spencer Dawkins, Tim Polk, Menachem
Dodge, Adrian Farrel and Pekka Savola for their reviews of this Dodge, Adrian Farrel, and Pekka Savola for their reviews of this
document as part of the IESG review process. Finally, special thanks document as part of the IESG review process. Finally, special thanks
to Jouni Korohonen for his support in addressing the IPsec issues. to Jouni Korohonen for his support in addressing the IPsec issues.
10. References 10. References
10.1. Normative References
[I-D.ietf-netlmm-grekey-option] 10.1. Normative References
Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-09 (work in progress),
May 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] 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.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
skipping to change at page 53, line 25 skipping to change at page 49, line 5
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
Stack Mobility", RFC 4977, August 2007. Stack Mobility", RFC 4977, August 2007.
[GREKEY] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"GRE Key Option for Proxy Mobile IPv6", Work in Progress,
May 2009.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
TOYOTA InfoTechnology Center, U.S.A., Inc. TOYOTA InfoTechnology Center, U.S.A., Inc.
465 Bernardo Avenue 465 Bernardo Avenue
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: ryuji@us.toyota-itc.com EMail: ryuji@us.toyota-itc.com
Sri Gundavelli Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com EMail: sgundave@cisco.com
 End of changes. 274 change blocks. 
652 lines changed or deleted 657 lines changed or added

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