draft-ietf-netlmm-pmip6-ipv4-support-17.txt   draft-ietf-netlmm-pmip6-ipv4-support-18a-pasi-jikv3.txt 
NETLMM Working Group R. Wakikawa NETLMM Working Group R. Wakikawa
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: March 16, 2010 Cisco Expires: May 31, 2010 Cisco
September 12, 2009 November 27, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-17.txt draft-ietf-netlmm-pmip6-ipv4-support-18.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 16, 2010. This Internet-Draft will expire on May 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.1.3. Routing Considerations for the Local Mobility 3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 18 3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 17
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18
3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 25 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26
3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 29 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 43 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 41
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 44 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43
4.2.1. Extensions to Binding Update List Entry . . . . . . . 44 4.2.1. Extensions to Binding Update List Entry . . . . . . . 43
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 45 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 43
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 47 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 45
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 47 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 45
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 51 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 46
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 54 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 47
5.1. Local Mobility Anchor - Configuration Variables . . . . . 54 5.1. Local Mobility Anchor - Configuration Variables . . . . . 47
5.2. Mobile Access Gateway - Configuration Variables . . . . . 54 5.2. Mobile Access Gateway - Configuration Variables . . . . . 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
7. Security Considerations . . . . . . . . . . . . . . . . . . . 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 59 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1. Normative References . . . . . . . . . . . . . . . . . . . 60 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52
10.2. Informative References . . . . . . . . . . . . . . . . . . 60 10.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a same network infrastructure. Thus, it is reasonable to assume that a
mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
IPv6-only or in dual-stack mode and additionally the network between IPv6-only or in dual-stack mode and additionally the network between
the mobile access gateway and a local mobility anchor may be an IPv4 the mobile access gateway and a local mobility anchor may be an IPv4
or an IPv6 network. It is also reasonable to expect the same or an IPv6 network. It is also reasonable to expect the same
skipping to change at page 4, line 40 skipping to change at page 4, line 40
o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4
stack enabled will be able to obtain an IPv4 address and be able stack enabled will be able to obtain an IPv4 address and be able
to use that address from any of the access networks in that Proxy to use that address from any of the access networks in that Proxy
Mobile IPv6 domain. The mobile node is not required to be Mobile IPv6 domain. The mobile node is not required to be
allocated or assigned an IPv6 address to enable IPv4 home address allocated or assigned an IPv6 address to enable IPv4 home address
support. support.
o IPv4 Transport Network Support: The mobility entities in the Proxy o IPv4 Transport Network Support: The mobility entities in the Proxy
Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
signaling messages over an IPv4 transport and furthermore the signaling messages over an IPv4 transport.
mobile access gateway may be using an IPv4 private address and
with NAT [RFC-3022] translation devices on the path to the local
mobility anchor.
These two features, the IPv4 Home Address Mobility support and the These two features, the IPv4 Home Address Mobility support and the
IPv4 transport support features, are independent of each other and IPv4 transport support features, are independent of each other and
deployments may choose to enable any one or both of these features as deployments may choose to enable any one or both of these features as
required. required.
Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport Figure 1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport
network and with IPv4 enabled mobile nodes. The terms used in this network and with IPv4 enabled mobile nodes. The terms used in this
illustration are explained in the Terminology section. illustration are explained in the Terminology section.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA
| | | |
\\ //\\ \\ //\\
(NAT) // \\ \\ // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // \\ \\ // \\
\\ // \\ \\ // \\
IPv4-Proxy-CoA --> | | <-- Proxy-CoA IPv4-Proxy-CoA --> | | <-- Proxy-CoA
+----+ +----+ +----+ +----+
skipping to change at page 5, line 42 skipping to change at page 5, line 42
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 [RFC-5213]. based on Proxy Mobile IPv6 [RFC-5213].
o The local mobility anchor and the mobile access gateway MUST be o A deployment where a mobile access gateway uses an IPv4 private
configured with IPv6 globally unique addresses. Or, they must be address and NAT [RFC-3022] translation devices are located on the
at least unique within that Proxy Mobile IPv6 domain. These path to a local mobility anchor is not supported by this
addresses can be of the type, Unique Local IPv6 Unicast Address specification.
[RFC-4193], IPv6 Global Unicast Address [RFC-3587], or IPv4-mapped
IPv6 address [RFC-4291]. When using IPv4 transport, it is not
required that there is IPv6 routing enabled between the local
mobility anchor and the mobile access gateway. However, they must
be able to receive any IPv6 packets sent to the configured IPv6
addresses, after removing the outer IPv4 encapsulation header.
o The mobile node can be operating in IPv4-only, IPv6-only or in o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. Based on what is enabled for a mobile node, it should dual mode. Based on what is enabled for a mobile node, it should
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
address(es) for its interface and furthermore achieve mobility address(es) for its interface and furthermore achieve mobility
support for those addresses. support for those addresses.
o For enabling IPv4 home address mobility support to a mobile node, o For enabling IPv4 home address mobility support to a mobile node,
it is not required that the IPv6 home address mobility support it is not required that the IPv6 home address mobility support
needs to enabled. However, the respective protocol(s) support, needs to enabled. However, the respective protocol(s) support,
skipping to change at page 6, line 41 skipping to change at page 6, line 35
o The mobile access gateway is the IPv4 default router for the o The mobile access gateway is the IPv4 default router for the
mobile node on its access link. It will be in the forwarding path mobile node on its access link. It will be in the forwarding path
for the mobile node's data traffic. Additionally, as specified in for the mobile node's data traffic. Additionally, as specified in
section 6.9.3 of [RFC-5213], all the mobile access gateways in the section 6.9.3 of [RFC-5213], all the mobile access gateways in the
Proxy Mobile IPv6 domain MUST use the same link-layer address on Proxy Mobile IPv6 domain MUST use the same link-layer address on
any of the access links wherever the mobile node attaches. any of the access links wherever the mobile node attaches.
1.2. Relevance to Dual-Stack Mobile IPv6 1.2. Relevance to Dual-Stack Mobile IPv6
IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6
specification [RFC-5555]. This document to most part leverages the specification [RFC-5555]. 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. Following are some of the related
considerations. considerations.
o The messaging option, IPv4 Care-of Address option defined in [RFC- o The Binding Update flag 'F' and the NAT Detection Option defined
5555] for use in Binding Update and Binding Acknowledgement in Sections 3.1.3 and 3.2.2 of [RFC-5555] are used by this
messages are used by this specification to be carried in Proxy specification in Proxy Binding Update and Proxy Binding
Binding Update and Proxy Binding Acknowledgement messages. Acknowledgement messages. Their sole purpose is to allow forcing
of UDP encapsulation between a mobile access gateway and a local
mobility anchor in situations discussed in Sections 4.1 and 4.4.1
of [RFC-5555].
o The extensions needed to the conceptual data structures, Binding o The extensions needed to the conceptual data structures, Binding
Cache entry and Binding Update List entry, for storing the state Cache entry and Binding Update List entry, for storing the state
related to the IPv4 support defined in [RFC-5555], will all be related to the IPv4 support defined in [RFC-5555], will all be
needed and relevant for this document. needed and relevant for this document.
o The NAT traversal logic specified in [RFC-5555] for detecting the o In normal Mobile IPv6 [RFC-3775] and Dual-Stack Mobile IPv6
on-path NAT devices is valid for this specification as well. [RFC-5555], IPsec security associations (SAs) are specific to a
single MN; they use the identifier visible to upper-layer
protocols (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec
SAs need to be updated when the MN moves.
o The tunneling considerations specified in [RFC-5555] for In Proxy Mobile IPv6 (both [RFC-5213] and this document), the IPsec
supporting IPv4 transport is relevant for this document as well. SAs are specific to MAG (and used for potentially large number of
MNs); they use the locators used for routing (Proxy-CoA/
IPv4-Proxy-CoA) as traffic selector; and they are not updated when
the MN moves.
If a given home agent [RFC-3775] implementation has support for both This means the IPsec processing for Mobile IPv6 and Proxy Mobile
Dual-stack Mobile IPv6 [RFC-5555] and local mobility anchor function IPv6 (whether IPv6 only or dual-stack) is very different.
[RFC-5213], when extending IPv4 support as specified in this document
the above common functions and the related considerations have to be o The tunneling considerations specified in [RFC-5555] for supporting
reused for Proxy Mobile IPv6 signaling flows. IPv4 transport is relevant for this document as well.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119]. document are to be interpreted as described in RFC 2119 [RFC-2119].
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 [RFC-3775] interpreted as defined in the Mobile IPv6 specification [RFC-3775] and
and Proxy Mobile IPv6 specification [RFC-5213]. In addition this Proxy Mobile IPv6 specification [RFC-5213]. In addition this document
document introduces the following terms. 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. However, if the configured address is a private IPv4 gateway.
address and with a NAT device in the path to the local mobility
anchor, the care-of address as seen by the local mobility anchor
will be the address allocated by the NAT device for that flow.
IPv4 Local Mobility Anchor Address (IPv4-LMAA) IPv4 Local Mobility Anchor Address (IPv4-LMAA)
The IPv4 address that is configured on the egress-interface of the The IPv4 address that is configured on the egress-interface of the
local mobility anchor. When using IPv4 transport, the mobile local mobility anchor. When using IPv4 transport, the mobile
access gateway sends the Proxy Binding Update messages to this access gateway sends the Proxy Binding Update messages to this
address and will be the transport-endpoint of the tunnel between address and will be the transport-endpoint of the tunnel between
the local mobility anchor and the mobile access gateway. the local mobility anchor and the mobile access gateway.
Mobile Node's IPv4 Home Address (IPv4-MN-HoA) Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
skipping to change at page 10, line 5 skipping to change at page 9, line 31
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 packet carried as a payload in an IPv4 packet with UDP and
TLV headers TLV headers
IPv4-or-IPv6-over-IPv4-GRE
IPv4 packet carried as a payload in an IPv4 packet with 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 an handoff anywhere
within that Proxy Mobile IPv6 domain. This section describes the within that Proxy Mobile IPv6 domain. This section describes the
protocol operation and the required extensions to Proxy Mobile IPv6 protocol operation and the required extensions to Proxy Mobile IPv6
protocol for extending IPv4 home address mobility support. protocol for extending IPv4 home address mobility support.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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 [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able to
to obtain an IPv4 home address (IPv4-MN-HoA) for its attached obtain an IPv4 home address (IPv4-MN-HoA) for its attached interface.
interface. Although the address configuration mechanisms for Although the address configuration mechanisms for delivering the
delivering the address configuration to the mobile node is address configuration to the mobile node is independent of the Proxy
independent of the Proxy Mobile IPv6 protocol operation, however Mobile IPv6 protocol operation, however there needs to be some
there needs to be some interactions between these two protocol flows. interactions between these two protocol flows. Section 3.4
Section 3.4 identifies these interactions for supporting DHCP based identifies these interactions for supporting DHCP based address
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 for 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
skipping to change at page 11, line 44 skipping to change at page 11, line 44
The processing rules specified in Section 5.3 of [RFC-5213] are The processing rules specified in Section 5.3 of [RFC-5213] are
applied for processing the received Proxy Binding Update message. applied for processing the received Proxy Binding Update message.
However, if the received Proxy Binding Update message has an IPv4 However, if the received Proxy Binding Update message has an IPv4
Home Address 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 present in the
received Proxy Binding Update message, but if there is no Home received Proxy Binding Update message, but if there is no Home
Network Prefix option [RFC-5213] present in the request, the local Network Prefix option [RFC-5213] present in the request, the local
mobility anchor MUST NOT reject the request as specified in mobility anchor MUST NOT reject the request as specified in
Section 5.3.1 of [RFC-5213]. At least one instance of any of Section 5.3.1 of [RFC-5213]. At least one instance of any of these
these two options, either the IPv4 Home Address Request option or two options, either the IPv4 Home Address Request option or the
the Home Network Prefix option, MUST be present. If there is not Home Network Prefix option, MUST be present. If there is not a
a single instance of any of these two options present in the single instance of any of these two options present in the
request, the local mobility anchor MUST reject the request and request, the local mobility anchor MUST reject the request and
send a Proxy Binding Acknowledgement message with Status field set send a Proxy Binding Acknowledgement message with Status field set
to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213]. network prefix option) [RFC-5213].
o If there is at least one instance of Home Network Prefix option o If there is at least one instance of Home Network Prefix option
[RFC-5213] present in the received Proxy Binding Update message, [RFC-5213] present in the received Proxy Binding Update message,
but either if it is known from the mobile node's policy profile but either if it is known from the mobile node's policy profile
that the mobile node is not authorized for IPv6 service or if IPv6 that the mobile node is not authorized for IPv6 service or if IPv6
routing not enabled in the home network, the local mobility anchor routing not enabled in the home network, the local mobility anchor
skipping to change at page 14, line 8 skipping to change at page 13, line 51
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
[RFC-5213], there should still be only one Binding Cache entry [RFC-5213], there should still be only one Binding Cache entry that
that should be created for this mobility session. The created should be created for this mobility session. The created Binding
Binding Cache entry MUST be used for managing both IPv4 and IPv6 Cache entry MUST be used for managing both IPv4 and IPv6 home
home address bindings. The fields in the Binding Cache entry MUST address bindings. The fields in the Binding Cache entry MUST be
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 bi-directional tunnel
to the mobile access gateway and with the encapsulation mode set to the mobile access gateway and with the encapsulation mode set
to the negotiated mode for carrying the IPv4 payload traffic. to the negotiated mode for carrying the IPv4 payload traffic.
When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6- When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-
over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6
packet). When using IPv4 transport, the encapsulation mode is as packet). When using IPv4 transport, the encapsulation mode is as
specified in Section 4.0. specified in Section 4.
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.
skipping to change at page 15, line 20 skipping to change at page 15, line 14
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 bi-directional tunnel to
the mobile access gateway that sent the request (if there is no the mobile access gateway that sent the request (if there is no
existing bi-directional tunnel) and with the encapsulation mode existing bi-directional tunnel) and with the encapsulation mode
set to the negotiated mode for carrying the IPv4 payload traffic. set to the negotiated mode for carrying the IPv4 payload traffic.
An IPv4 host route for tunneling the packets received for the An IPv4 host route for tunneling the packets received for the
mobile node's IPv4 home address MUST also be added. mobile node's IPv4 home address MUST also be added.
o The required forwarding state identified in Section 5.3.6 of [RFC- o The required forwarding state identified in Section 5.3.6 of
5213] is for IPv6 payload traffic. Those considerations apply for [RFC-5213] is for IPv6 payload traffic. Those considerations apply
IPv4 payload traffic as well. However, if IPv4 transport is in for IPv4 payload traffic as well. However, if IPv4 transport is
use, considerations from Section 4.0 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 [RFC-5213] MUST be All the considerations from Section 5.3.5 of [RFC-5213] MUST be
applied. Additionally, for removing the IPv4 state as part of the applied. Additionally, for removing the IPv4 state as part of the
Binding Cache entry deletion, the IPv4 host route and the dynamically Binding Cache entry deletion, the IPv4 host route and the dynamically
created bi-directional tunnel for carrying the IPv4 payload traffic created bi-directional tunnel for carrying the IPv4 payload traffic
(if there are no other mobile nodes for which the tunnel is being (if there are no other mobile nodes for which the tunnel is being
used) MUST be removed. However, if the request is for a selective used) MUST be removed. However, if the request is for a selective
de-registration (IPv4 home address only, or all the IPv6 home network de-registration (IPv4 home address only, or all the IPv6 home network
skipping to change at page 15, line 45 skipping to change at page 15, line 39
respective states with respect to those addresses MUST be deleted. respective states with respect to those addresses MUST be deleted.
3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC-5213]. the message as specified in Section 5.3.6 of [RFC-5213].
Additionally, the following considerations MUST be applied. Additionally, the following considerations MUST be applied.
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option [RFC- include at least one instance of Home Network Prefix option
5213] in the Proxy Binding Acknowledgement message that it sends [RFC-5213] in the Proxy Binding Acknowledgement message that it
to the mobile access gateway. However, if the received Proxy sends to the mobile access gateway. However, if the received
Binding Update message has only the IPv4 Home Address Request Proxy Binding Update message has only the IPv4 Home Address
option and did not contain the Home Network Prefix option(s), then Request option and did not contain the Home Network Prefix
the local mobility anchor MUST NOT include any Home Network Prefix option(s), then the local mobility anchor MUST NOT include any
option(s) in the reply. However, there MUST be at least one Home Network Prefix option(s) in the reply. However, there MUST
instance of either the Home Network Prefix option [RFC-5213] or be at least one instance of either the Home Network Prefix option
the IPv4 Home Address Reply option present in the Proxy Binding [RFC-5213] or the IPv4 Home Address Reply option present in the
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 MUST be an IPv4 Home Address Reply option corresponding there MUST be an IPv4 Home Address Reply option corresponding
to the IPv4 Home Address Request option present in the request to the IPv4 Home Address Request option present in the request
and with the IPv4 address value and the prefix length fields and with the IPv4 address value and the prefix length fields
in the option set to the corresponding values in the request. in the option set to the corresponding values in the request.
skipping to change at page 16, line 36 skipping to change at page 16, line 31
o The IPv4 Default-Router Address option MUST be present, if the o The IPv4 Default-Router Address option MUST be present, if the
Status field value in the Proxy Binding Acknowledgement message is Status field value in the Proxy Binding Acknowledgement message is
set to 0 (Proxy Binding Update Accepted). Otherwise, the option set to 0 (Proxy Binding Update Accepted). Otherwise, the option
MUST NOT be present. If the option is present, the default router MUST NOT be present. If the option is present, the default router
address in the option MUST be set to the mobile node's default address in the option MUST be set to the mobile node's default
router address. router address.
3.1.2.7. Binding Cache Entry Lookup Considerations 3.1.2.7. Binding Cache Entry Lookup Considerations
The Binding Cache entry lookup considerations specified in section The Binding Cache entry lookup considerations specified in section
5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] as
as the key parameter for identifying the Binding Cache entry. the key parameter for identifying the Binding Cache entry. However,
However, when there is not a single Home Network Prefix option with a when there is not a single Home Network Prefix option with a NON_ZERO
NON_ZERO value present in the request, but if there is an IPv4 Home value present in the request, but if there is an IPv4 Home Address
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 [RFC-5213], which o The search rules specified in section 5.4.1.1 of [RFC-5213], which
primarily uses IPv6 home network prefix set as the search key, are primarily uses IPv6 home network prefix set as the search key, are
equally valid when using a single IPv4 home address as the key. equally valid when using a single IPv4 home address as the key.
When applying those considerations, instead of the IPv6 home When applying those considerations, instead of the IPv6 home
network prefix(es), the IPv4 home address from the IPv4 Home network prefix(es), the IPv4 home address from the IPv4 Home
Address option present in the request MUST be used as the search Address option present in the request MUST be used as the search
key. key.
skipping to change at page 19, line 47 skipping to change at page 19, line 41
* The mobile access gateway MAY also ask the local mobility * The mobile access gateway MAY also ask the local mobility
anchor for dynamic IPv4 home address allocation. It can anchor for dynamic IPv4 home address allocation. It can
include exactly one instance of the IPv4 Home Address option include exactly one instance of the IPv4 Home Address option
with the IPv4 home address and the prefix length fields in the with the IPv4 home address and the prefix length fields in the
option set to ALL_ZERO value. Furthermore, the (P) flag in the option set to ALL_ZERO value. Furthermore, the (P) flag in the
option MUST be set to 0. This essentially serves as a request option MUST be set to 0. This essentially serves as a request
to the local mobility anchor for the IPv4 home address to the local mobility anchor for the IPv4 home address
allocation. 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 [RFC-5213]. However, the Home Network in Section 6.9.1.5 of [RFC-5213]. However, the Home Network Prefix
Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding option(s) [RFC-5213] MUST be present in the Proxy Binding Update
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 for carrying the signaling messages, the
related considerations from section 4.0 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 [RFC-5213] MUST be All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
applied with the following exceptions. applied with the following exceptions.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_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
skipping to change at page 22, line 32 skipping to change at page 22, line 24
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) [RFC-5213]. It MUST include exactly one Prefix options(s) [RFC-5213]. It MUST include exactly one instance
instance of the IPv4 Home Address Request option with the IPv4 of the IPv4 Home Address Request option with the IPv4 home address
home address and the prefix length fields in the option set to the and the prefix length fields in the option set to the IPv4 home
IPv4 home address that is being de-registered. Similarly for address that is being de-registered. Similarly for selective de-
selective de-registration of all the IPv6 home network prefixes, registration of all the IPv6 home network prefixes, the Proxy
the Proxy Binding Update message MUST NOT include the IPv4 Home Binding Update message MUST NOT include the IPv4 Home address
address option, it MUST include a Home Network Prefix option for option, it MUST include a Home Network Prefix option for each of
each of the assigned home network prefixes assigned for that the assigned home network prefixes assigned for that mobility
mobility session and with the prefix value in the option set to session and with the prefix value in the option set to that
that respective prefix value. respective prefix value.
o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present if
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 [RFC-5213] with Update message. Otherwise considerations from [RFC-5213] with
respect to this option MUST be applied. respect to this option MUST be applied.
o If at any point the mobile access gateway fails to extend the o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address. for the mobile node's IPv4 home address.
3.2.4. Routing Considerations for the Mobile Access Gateway 3.2.4. Routing Considerations for the Mobile Access Gateway
skipping to change at page 23, line 26 skipping to change at page 23, line 19
considerations from Section 6.10.3 of [RFC-5213] MUST be applied considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect to local routing. with respect to local routing.
o When forwarding the packet through the bi-directional tunnel, the o When forwarding the packet through the bi-directional tunnel, the
encapsulation considerations specified in section 3.1.3 MUST be encapsulation considerations specified in section 3.1.3 MUST be
applied. However, before forwarding the packet, the mobile access applied. However, before forwarding the packet, the mobile access
gateway MUST ensure the source address in the received packet is gateway MUST ensure the source address in the received packet is
the address allocated for that mobile node and that there is an the address allocated for that mobile node and that there is an
active binding on the local mobility anchor for that mobile node. active binding on the local mobility anchor for that mobile node.
o The mobile access gateway SHOULD use Proxy ARP [RFC-925] to reply o The mobile access gateway SHOULD use Proxy ARP [RFC-0925] to reply
to ARP Requests that it receives from the mobile node seeking to ARP Requests that it receives from the mobile node seeking
address resolutions for the destinations on the mobile node's home address resolutions for the destinations on the mobile node's home
subnet. When receiving an ARP Request, the local mobility anchor subnet. When receiving an ARP Request, the local mobility anchor
SHOULD examine the target IP address of the Request, and if this SHOULD examine the target IP address of the Request, and if this
IP address matches the mobile node's IPv4 home subnet, it SHOULD IP address matches the mobile node's IPv4 home subnet, it SHOULD
transmit a Proxy ARP Reply. However, on certain types of links, transmit a Proxy ARP Reply. However, on certain types of links,
the mobile node does not use ARP for address resolutions, instead the mobile node does not use ARP for address resolutions, instead
it forwards all the packets to the mobile access gateway. On such it forwards all the packets to the mobile access gateway. On such
types of links, the mobile access gateway is not required to types of links, the mobile access gateway is not required to
support Proxy ARP function. At the same time, implementations not support Proxy ARP function. At the same time, implementations not
skipping to change at page 27, line 4 skipping to change at page 26, line 42
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 IANA
Length Length
8-bit unsigned integer indicating the length of the option in 8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST octets, excluding the type and length fields. This field MUST
be set to (6). be set to (6).
Reserved (R) Reserved (R)
skipping to change at page 29, line 29 skipping to change at page 29, line 29
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 [RFC-1918] that can be used potentially an IPv4 private address [RFC-1918] that can be used for
for the DHCP protocol communication on any of the access links. the DHCP protocol communication on any of the access links. This
This address will be used as the server identifier in the DHCP address 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 [RFC-2132], if present, or from DHCP "Client-identifier" option [RFC-2132], if present, or from the
the client hardware address (chaddr), as specified in [RFC-2131]. client hardware address (chaddr), as specified in [RFC-2131]. Note
Note that the name "Client-identifier" is a misnomer as it that the name "Client-identifier" is a misnomer as it actually
actually identifies an interface and not the client. The DHCP identifies an interface and not the client. The DHCP server uses
server uses this identity to identify the interface for which the this identity to identify the interface for which the address is
address is assigned. A mobile node in a Proxy Mobile IPv6 domain, assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach
can attach to the network through multiple interfaces and can to the network through multiple interfaces and can obtain address
obtain address configuration for each of its interfaces. configuration for each of its interfaces. Additionally, it may
Additionally, it may perform handoffs between its interfaces. perform handoffs between its interfaces. Following are the
Following are the related considerations with respect to the related considerations with respect to the identification
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 [RFC-4361]. Any time the mobile node interface according to [RFC-4361]. Any time the mobile node
performs an handoff of a physical interface to a different performs an 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 handoff between
interfaces, as per [RFC-5213], a "Client-identifier" value MUST interfaces, as per [RFC-5213], 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 [RFC-4361], which guarantees that the identifier according to [RFC-4361], which guarantees that the identifier is
is stable and unique across all "Client-identifier" values in stable and unique across all "Client-identifier" values in use
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 (Ex: 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
skipping to change at page 31, line 43 skipping to change at page 31, line 43
o For acquiring the mobile node's IPv4 home address from the local o For acquiring 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 [RFC-2131] to the mobile gateway will send a DHCPOFFER message [RFC-2131] to the mobile
node. The offered address will be the mobile node's IPv4 home node. The offered address will be the mobile node's IPv4 home
address, assigned by the local mobility anchor. The DHCPOFFER address, assigned by the local mobility anchor. The DHCPOFFER
message will also have the subnet mask option [RFC-2132] and message will also have the subnet mask option [RFC-2132] and router
router option [RFC-2132], with the values in those options set to option [RFC-2132], with the values in those options set to the
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 [RFC-2131]. will send DHCPACK message, as per [RFC-2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff): IPv4 Home Address Renewal with the DHCP server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state [RFC- o Any time the mobile node goes into the DHCP RENEWING state
2131], it simply unicasts the DHCPREQUEST message including the [RFC-2131], it simply unicasts the DHCPREQUEST message including
assigned IPv4 home address in the 'requested IP address' option. the assigned IPv4 home address in the 'requested IP address'
The DHCPREQUEST is sent to the address specified in Server option. The DHCPREQUEST is sent to the address specified in
Identifier option of the previously received DHCPOFFER and DHCPACK Server Identifier option of the previously received DHCPOFFER and
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 [RFC-2131], it When the mobile node goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile changed its point of attachment and is attached to a new mobile
skipping to change at page 33, line 11 skipping to change at page 33, line 5
DHCPREQUEST message sent by the mobile node for renewing the DHCPREQUEST message sent by the mobile node for renewing the
address will be received by the new mobile access gateway on the address will be received by the new mobile access gateway on the
attached link. 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
[RFC-2131] to the mobile node, as shown in Figure 8-1). [RFC-2131] 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 *
skipping to change at page 36, line 25 skipping to change at page 36, line 21
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 [RFC-2131] sent to the mobile node MUST o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST
include the Subnet Mask option [RFC-2132] and the Router option include the Subnet Mask option [RFC-2132] and the Router option
[RFC-2132]. The values in the Subnet Mask option and Router [RFC-2132]. The values in the Subnet Mask option and Router option
option MUST be set to the mobile node's IPv4 home subnet mask and MUST be set to the mobile node's IPv4 home subnet mask and its
its default router address respectively. default router address respectively.
o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST
include the Interface MTU option [RFC-2132]. The DHCP servers in include the Interface MTU option [RFC-2132]. 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 bi-directional tunnel between the mobile access gateway
and the local mobility anchor. and 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
skipping to change at page 37, line 13 skipping to change at page 37, line 11
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 [RFC-4436] capable and if it * If the mobile node is DNAv4 [RFC-4436] capable and if it
performs DNAv4 procedures after receiving a link change event, performs DNAv4 procedures after receiving a link change event,
it would always detect the same default router on any of the it would always detect the same default router on any of the
access links in that Proxy Mobile IPv6 domain, as the mobile access links in that Proxy Mobile IPv6 domain, as the mobile
access gateway configures a fixed link-layer address on all the access gateway configures a fixed link-layer address on all the
access links, as per the base Proxy Mobile IPv6 specification access links, as per the base Proxy Mobile IPv6 specification
[RFC-5213]. The mobile node will not perform any DHCP [RFC-5213]. The mobile node will not perform any DHCP operation
operation specifically due to this event. specifically due to this event.
* If the mobile node is not DNAv4 [RFC-4436] capable, after * If the mobile node is not DNAv4 [RFC-4436] capable, after
receiving the link change event it will enter INIT-REBOOT state receiving the link change event it will enter INIT-REBOOT state
[RFC-2131] and will send a DHCPREQUEST message as specified in [RFC-2131] and will send a DHCPREQUEST message as specified in
Section 3.7 of [RFC-2131]. The mobile node will obtain the Section 3.7 of [RFC-2131]. The mobile node will obtain the same
same address configuration as before, as the link change does address configuration as before, as the link change does not
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 [RFC-2131]. When the mobile sending the DHCPRELEASE message [RFC-2131]. When the mobile access
access gateway detects the DHCPRELEASE message sent by the mobile gateway detects the DHCPRELEASE message sent by the mobile node,
node, it should consider this as a trigger for de-registering the it should consider this as a trigger for de-registering the mobile
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 [RFC-5213] requires the signaling The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling
messages exchanged between the local mobility anchor and the mobile messages exchanged between the local mobility anchor and the mobile
access gateway to be over an IPv6 transport. The extensions defined access gateway to be over an IPv6 transport. However, in some cases
in this section allow the exchange of signaling messages over an IPv4 the local mobility anchor and the mobile access gateway are separated
transport when the local mobility anchor and the mobile access by an IPv4 network.
gateway are separated by an IPv4 network and are reachable using only
IPv4 addresses. The normal Proxy Mobile IPv6 specification [RFC-5213] can be run over
an IPv4 transport without any modifications by using a transition
technology that allows IPv6 hosts to communicate over IPv4 networks.
For example, the MAG and the LMA could have a simple configured IPv6-
over-IPv4 tunnel. Instead of configured tunnels, various mechanisms
for automatic tunneling could be used, too. To these tunnels, Proxy
Mobile IPv6 would look just like any other application traffic
running over IPv6.
However, treating Proxy Mobile IPv6 just like any other IPv6 traffic
would mean an extra layer of encapsulation for the mobile node's
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.
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
When the local mobility anchor and the mobile access gateway are When the local mobility anchor and the mobile access gateway are
configured and reachable using only IPv4 addresses, the mobile access configured and reachable using only IPv4 addresses, the mobile access
gateway serving a mobile node can potentially send the signaling gateway serving a mobile node can potentially send the signaling
messages over IPv4 transport and register its IPv4 address as the messages over IPv4 transport and register its IPv4 address as the
care-of address in the mobile node's Binding Cache entry. An IPv4 care-of address in the mobile node's Binding Cache entry. An IPv4
tunnel (with any of the supported encapsulation modes) can be used tunnel (with any of the supported encapsulation modes) can be used
for tunneling the mobile node's data traffic. The following are the for tunneling the mobile node's data traffic. The following are the
key aspects of this feature. key aspects of this feature.
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address. Additionally, configured and reachable using an IPv4 address of the same scope.
both entities are also IPv6 enabled and have configured IPv6
addresses on their interfaces, as specified in [RFC-5213], but are
reachable only over an IPv4 transport network.
o The mobile access gateway can be potentially in a private IPv4 o The IPv4 addresses used can be private IPv4 addresses, but it is
network behind a NAT [RFC-3022] device, with a private IPv4 assumed that there is no NAT between the LMA and the MAG.
address configured on its egress interface. But, the local
mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address. However, both the local mobility
anchor and the mobile access gateway can be in the same private
IPv4 routing domain, i.e., when both are configured with private
IPv4 addresses and with no need for NAT translation between them.
o The IPv6 address configuration requirement on the mobile access However, it is possible to use UDP encapsulation if other types of
gateway does not imply there needs to be IPv6 routing enabled middleboxes are present.
between the local mobility anchor and the mobile access gateway.
It just requires each of the mobile access gateways and local
mobility anchors in a Proxy Mobile IPv6 domain to be configured
with a globally unique IPv6 address.
o The Proxy Mobile IPv6 signaling messages exchanged between the o The Mobility Header protocol is carried inside an IPv4 packet and
local mobility anchor and the mobile access gateway for UDP header, using an UDP port number for Proxy Mobile IPv6
negotiating the IPv4 transport will be encapsulated and carried as signalling over IPv4.
IPv4 packets. However, these signaling messages are fundamentally
IPv6 messages using the mobility header and the related semantics
as specified in base Proxy Mobile IPv6 specification [RFC-5213],
but carried as a payload in an IPv4 packet. The supported
encapsulation modes for the signaling messages are either native
IPv4 or IPv4 with UDP header.
o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and
the IPv4 transport support specified in this section is agnostic the IPv4 transport support specified in this section is agnostic
to the type of address mobility enabled for that mobile node. to the type of address mobility enabled for that mobile node.
o The IPv4 tunnel established between the local mobility anchor and o The mobile node's data traffic will be tunneled between the local
the mobile access gateway (with any of the supported encapsulation mobility anchor and the mobile access gateway. There are several
modes over IPv4 transport) will be used for carrying the mobile encapsulation modes available:
node's IPv4 and IPv6 traffic. The following are the outer headers
based on the negotiated encapsulation mode.
* 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 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). If payload protection using IPsec is enabled for the header, using a UDP port number for Proxy Mobile IPv6 data;
tunneled traffic, the ESP header follows the outer tunnel this is different port than is used for signalling). If
header, as explained in Section 4.3. payload protection using IPsec is enabled, the ESP header
follows the 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). Refer to [ID-GREKEY-NEGO]. If payload and TLV header) and IPv4-GRE (Payload packet carried in an IPv4
protection using IPsec is enabled for the tunneled traffic, the packet with GRE header). Refer to
ESP header follows the outer tunnel header, as explained in [I-D.ietf-netlmm-grekey-option]. If payload protection using
Section 4.3. IPsec is enabled, the ESP header follows the outer IPv4 header,
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 [RFC-5213] MUST be structure maintained by the local mobility anchor [RFC-5213] MUST be
extended with the following additional parameters. It is to be noted extended with the following additional parameters. It is to be noted
that all of these parameters are specified in [RFC-5555] and also that all of these parameters are specified in [RFC-5555] and also
required here in the present usage context, and are presented here required here in the present usage context, and are presented here
only for completeness. only for completeness.
o The IPv4 Proxy Care-of Address configured on the mobile access o The IPv4 Proxy Care-of Address configured on the mobile access
gateway that sent the Proxy Binding Update message. This address gateway that sent the Proxy Binding Update message. The address
can be obtained from the IPv4 Care-of Address option [RFC-5555], MUST be the same as the source address of the received IPv4 packet
present in the received Proxy Binding Update message. However, if that contains the Proxy Binding Update message. However, if the
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 ALL_ZERO value.
o The IPv4 NAT translated address of the mobile access gateway. If
the mobile access gateway is not behind a NAT [RFC-3022], this
address will be the same as the address configured on the egress
interface of the mobile access gateway. This address can be
obtained from the IPv4 header of the received Proxy Binding Update
message. However, if the received Proxy Binding Update message is
not sent as an IPv4 packet, this field in the Binding Cache entry
MUST be set to ALL_ZERO value.
o The source UDP port, if the Proxy Binding Update was received in
an IPv4 packet with UDP header.
o The destination UDP port, if the Proxy Binding Update was received
in an IPv4 packet with UDP header.
4.1.2. Extensions to Mobile Node's Policy Profile 4.1.2. Extensions to Mobile Node's Policy Profile
To support the IPv4 Transport Support feature the mobile node's To support the IPv4 Transport Support feature the mobile node's
policy profile, specified in Section 6.2 of [RFC-5213] MUST be policy profile, specified in Section 6.2 of [RFC-5213] MUST be
extended with the following additional fields. 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 received Proxy Binding Update message was sent encapsulated o If the Proxy Binding Update message is protected with IPsec ESP,
in an IPv4 or IPv4-UDP packet, the message MUST be authenticated IPsec processing happens before the packet is passed to Proxy
after removing the outer encapsulation (IPv4 or IPv4-UDP) header. Mobile IPv6.
Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the request.
o All the considerations from Section 5.3.1 of [RFC-5213] MUST be
applied on the encapsulated Proxy Binding Update message, after
removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address option [RFC-5555] present in o All the considerations from Section 5.3.1 of [RFC-5213] except step
the request and if the outer encapsulation header is IPv4-UDP, 1 (about IPsec) MUST be applied on the encapsulated Proxy Binding
then the NAT presence detection procedure specified in Section Update message. Note that the Checksum field in Mobility Header
4.1.3.3 MUST be used for detecting the NAT in the path. 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 bi-directional tunnel to the mobile access gateway. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
The encapsulation mode MUST be determined by applying the The encapsulation mode MUST be determined by applying the
following considerations: following considerations:
* If the received Proxy Binding Update message was sent with IPv4 * If the (F) flag in the received Proxy Binding Update message is
encapsulated header, then the encapsulation mode for the bi- set to the value of (1), but if the configuration flag,
directional tunnel MUST be set to IPv4. Otherwise, the
following considerations apply.
* If NAT is not detected on the path and if the (F) flag in the
received Proxy Binding Update message is set to the value of
(1), 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 [ID-GREKEY-NEGO] in the Proxy Binding Update * If the (T) flag is set to (1), or GRE Key option is included,
message is set to value of (1), then the encapsulation mode see [I-D.ietf-netlmm-grekey-option].
MUST be set to IPv4-or-IPv6-over-IPv4-UDP-TLV.
* If NAT is detected on the path, or if the (F) flag in the * If the (F) flag in the received Proxy Binding Update message is
received Proxy Binding Update message is set to the value of set to the value of (1), then the encapsulation mode MUST be
(1), then the encapsulation mode MUST be set to IPv4-or-IPv6- set to IPv4-UDP. Otherwise the encapsulation mode MUST be set
over-IPv4-UDP. Otherwise the encapsulation mode MUST be set to to IPv4.
IPv4-or-IPv6-over-IPv4.
o The local mobility anchor MUST send the Proxy Binding o The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field value set to (0) Acknowledgement message with the Status field value set to (0)
(Proxy Binding Update Accepted). The message MUST be constructed (Proxy Binding Update Accepted). The message MUST be constructed
as specified in Section 4.1.3.2. as specified in Section 4.1.3.2.
4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC-5213]. However, if the message as specified in Section 5.3.6 of [RFC-5213]. However, if
the received Proxy Binding Update message was encapsulated in an IPv4 the Proxy Binding Update message was received over IPv4, the
packet or as a payload in the UDP header of an IPv4 packet, the
following additional considerations MUST be applied. following additional considerations MUST be applied.
o The Proxy Binding Acknowledgement message MUST be encapsulated in o The IPv6 Header is removed, and the Mobility Header containing the
an IPv4 packet. However, if the received Proxy Binding Update PBA is encapsulated in UDP (with source and destination port set
message was sent encapsulated in an IPv4-UDP packet, then the to TBD1). The Mobility Header Checksum field MUST be set to zero
Proxy Binding Acknowledgement message MUST be encapsulated in the (and UDP checksum MUST be used instead).
UDP header of an IPv4 packet.
o The source address in the IPv4 header of the message MUST be set o The source address in the IPv4 header of the message MUST be set
to the destination IPv4 address of the received request. to the destination IPv4 address of the received request.
o If the mobile access gateway and the local mobility anchor are o If IPsec ESP is used to protect signalling, the packet is
using globally routable IPv4 addresses and if there is a security processed using transport mode ESP as described in Section 4.3.
association that is based on IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
MUST be protected using IPsec ESP [RFC-4301] mode. There is no
need to apply IPsec ESP header to the IPv6 packet. In all other
cases, the Proxy Binding Acknowledgement message MUST be protected
using IPsec prior to the IPv4 or IPv4-UDP encapsulation.
o The NAT Detection option [RFC-5555] MUST be present only if there
is an IPv4 Care-of Address option [RFC-5555] present in the
received Proxy Binding Update message and if the NAT detection
procedure resulted in detecting a NAT on path. However, if the
received Proxy Binding Update message was not sent encapsulated in
IPv4 UDP header, then the option MUST NOT be present.
Furthermore, in all other cases, the option MUST NOT be present.
o The IPv4 DHCP Support Mode option MAY be present. If this option
is not present, the mobile access gateway will enable the default
behavior and function as a DHCP Relay for the mobile node.
o Figure 9 shows the format of the Proxy Binding Acknowledgement o Figure 11 shows the format of the Proxy Binding Acknowledgement
message encapsulated in an IPv4 packet and protected using IPv6 message sent over IPv4 and protected using ESP.
security association. The UDP header MUST be present only if the
received Proxy Binding Update message was sent encapsulated in an
IPv4-UDP packet.
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) IPv4 header (src=IPv4-LMAA, dst=pbu_src_address)
UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ ESP header (in transport mode)
/* IPv6 PBA Packet protected with ESP header */ UDP header (sport=TBD1, dport=TBD1)
Mobility Header (PBA)
Figure 11: Proxy Binding Acknowledgment (PBA) Message encapsulated
in IPv4 header
4.1.3.3. NAT Presence Detection
When the transport network between the local mobility anchor and the
mobile access gateway is an IPv4 network and if the received Proxy
Binding Update message was sent encapsulated in IPv4 UDP header, the
local mobility anchor performs the NAT Presence Detection as
specified below.
On receiving the Proxy Binding Update message encapsulated in an IPv4
UDP packet, the local mobility anchor, if it detects a NAT on the
path, will send the Proxy Binding Acknowledgment message with the NAT
Detection Option. The presence of this option in the Proxy Binding
Acknowledgment is an indication to the mobile access gateway about
the presence of NAT in the path. On detecting any NAT in the path,
both the local mobility anchor and the mobile access gateway will set
the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation.
The specific details around the NAT detection and the related logic
are described in DSMIPv6 specification [RFC-5555].
However, if the value of the configuration variable, Figure 11: Proxy Binding Acknowledgment (PBA) Message sent over
UseIPv4UDPEncapForSignalingMessages, is set to a value of (0), the IPv4
mobile access gateway will not use IPv4 UDP encapsulation for Proxy
Binding Update messages and hence the local mobility anchor will not
perform this NAT Presence Detection procedure on these messages that
are not sent in IPv4 UDP packet.
4.1.4. Routing Considerations 4.1.4. Routing Considerations
4.1.4.1. Forwarding Considerations 4.1.4.1. Forwarding Considerations
Forwarding Packets to the Mobile Node: Forwarding Packets to the Mobile Node:
o On receiving an IPv4 or an IPv6 packet from a correspondent node o On receiving an IPv4 or an IPv6 packet from a correspondent node
with the destination address matching any of the mobile node's with the destination address matching any of the mobile node's
IPv4 or IPv6 home addresses, the local mobility anchor MUST IPv4 or IPv6 home addresses, the local mobility anchor MUST
forward the packet through the bi-directional tunnel set up for forward the packet through the bi-directional tunnel set up for
that mobile node. that mobile node.
o The format of the tunneled packet is shown below. o The format of the tunneled packet is shown below. The IPv4-UDP-
TLV and IPv4-GRE encapsulation modes are described in
[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=DSMIPv6, dst port=Z] /* If UDP encap nego */ [UDP Header (src port=TBD2, dst port=TBD2] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA) IPv6 header (src= CN, dst= MN-HOA)
OR OR
IPv4 header (src= CN, dst= IPv4 MN-HoA) IPv4 header (src=CN, dst=IPv4-MN-HoA)
Figure 12: Tunneled IPv4 Packet from LMA to MAG Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP
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 & Payload Fragmentation Considerations
The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply The ECN considerations specified in Section 5.6.3 of [RFC-5213] 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 [RFC- the IP packet fragmentation considerations as specified in [RFC-4213].
4213]. Additionally they MUST also apply the considerations related Additionally they MUST also apply the considerations related to
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. Bi-Directional Tunnel Management
The Tunnel Management considerations specified in section 5.6.1 of The Tunnel Management considerations specified in section 5.6.1 of
[RFC-5213] apply for the IPv4 transport tunnels as well, with just [RFC-5213] apply for the IPv4 transport tunnels as well, with just one
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 [RFC-5213] MUST be extended with the following additional gateway [RFC-5213] MUST be extended with the following additional
parameters. parameters.
skipping to change at page 45, line 17 skipping to change at page 43, line 25
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 message
to the local mobility anchor MUST construct the message as specified to the local mobility anchor MUST construct the message as specified
in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access
gateway is in an IPv4-only access network, the following additional gateway is in an IPv4-only access network, the following additional
considerations MUST be applied. considerations MUST be applied.
o The Proxy Binding Update message MUST be encapsulated in an IPv4 o The Proxy Binding Update message MUST be sent over IPv4 as
packet. However, if the value of the configuration variable, desribed in Section 4.2.2.1.
UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
Binding Update message MUST be encapsulated in an UDP header of an
IPv4 packet.
o The IPv4 Care-of Address option [RFC-5555] MUST be present. The
IPv4 address in the option MUST be set to the mobile access
gateway's IPv4-Proxy-CoA.
o The packet MUST be constructed as specified in Section 4.2.2.1.
o Just as specified in [RFC-5213], when sending a Proxy Binding o Just as specified in [RFC-5213], when sending a Proxy Binding
message for extending the lifetime of a currently existing Update message for extending the lifetime of a currently existing
mobility session or for de-registering the mobility session, the mobility session or for de-registering the mobility session, the
Proxy Binding Update message MUST be constructed just as the Proxy Binding Update message MUST be constructed just as the
initial request. initial request.
Receiving Proxy Binding Acknowledgement Receiving Proxy Binding Acknowledgement
o If the received Proxy Binding Acknowledgement message is o If the received Proxy Binding Acknowledgement message is protected
encapsulated in IPv4 or IPv4 UDP packet, the message MUST be with IPsec ESP, IPsec processing happens before the packet is
authenticated after removing the outer IPv4 or IPv4-UDP header. passed to Proxy Mobile IPv6. Considerations from Section 4 of
Considerations from Section 4 of [RFC-5213] MUST be applied for [RFC-5213] MUST be applied for authenticating and authorizing the
authenticating and authorizing the message. message.
o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be
applied on the encapsulated Proxy Binding Acknowledgement message, applied on the encapsulated Proxy Binding Acknowledgement message.
after removing the outer IPv4 UDP header. 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 setup a bi-directional tunnel to the local mobility anchor.
o Upon accepting the request, the mobile access gateway MUST set up o Upon accepting the request, the mobile access gateway MUST set up
an IPv4 bi-directional tunnel to the local mobility anchor. The an IPv4 bi-directional tunnel to the local mobility anchor. The
tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA.
The encapsulation mode MUST be determined from the below The encapsulation mode MUST be determined from the below
considerations. considerations:
o The encapsulation mode for the bi-directional tunnel MUST be set * If the (T) flag is set to (1), or GRE Key option is included,
to IPv4. However, if the value of the configuration variable, see [I-D.ietf-netlmm-grekey-option].
UseIPv4UDPEncapForSignalingMessages, is set to (1), then the
following considerations MUST be applied.
* If there is a NAT Detection option [RFC-5555] in the received * If there is a NAT Detection option [RFC-5555] in the received
Proxy Binding Acknowledgement message and if the value of the Proxy Binding Acknowledgement message, and the (F) flag is set
configuration flag, UseIPv4UDPEncapForSignalingMessages, is set to value of (1), the encapsulation mode for the tunnel MUST be
to value of (1), then the encapsulation mode for the tunnel set to IPv4-UDP. Otherwise the encapsulation mode MUST be set
MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST to IPv4.
be set to IPv4.
* If the (T) flag in the Proxy Binding Acknowledgement message is
set to value of (1), then the encapsulation mode MUST be set to
IPv4-UDP-TLV.
4.2.2.1. Constructing the Proxy Binding Update Message 4.2.2.1. Constructing the Proxy Binding Update Message
o The IPv6 Header is removed, and the Mobility Header containing the
PBA is encapsulated in UDP (with source and destination port set
to TBD1). The Mobility Header Checksum field 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 The IPv4 Care-of Address option [RFC-5555] MUST be present. The
address MUST be set to the mobile access gateway's IPv4-Proxy-CoA.
o If the configuration variable ForceIPv4UDPEncapsulationSupport is o If the configuration variable ForceIPv4UDPEncapsulationSupport is
set to value of (1), then the (F) flag in the Proxy Binding Update set to value of (1), then the (F) flag in the Proxy Binding Update
message MUST be set to value of (1). message MUST be set to value of (1).
o The Proxy Binding Update message MUST be protected using IPsec ESP o If IPsec ESP is used to protect signalling, the packet is
[RFC-4301], as specified in [RFC-5213]. The protection MUST be processed using transport mode ESP as described in Section 4.3.
applied on the IPv6 packet of the Proxy Binding Update message,
prior to the IPv4 encapsulation.
o The format of the Proxy Binding Update message encapsulated in an o Figure 13 shows the format of the Proxy Binding Acknowledgement
IPv4 or IPv4-UDP packet with no IPsec protection: message 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)
UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ ESP header (in transport mode)
/* IPv6 PBU Packet protected with ESP header */ UDP header (sport=TBD1, dport=TBD1)
Figure 13: Proxy Binding Update (PBU) message encapsulated in IPv4 Mobility Header (PBU)
UDP header
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. However, considerations from Section 6.10.3 of [RFC- shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes
5213] MUST be applied with respect the local routing and on the are described in [I-D.ietf-netlmm-grekey-option]. However,
use of EnableMAGLocalRouting flag. considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect the local routing and on the use of
EnableMAGLocalRouting flag.
IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ [UDP Header (src port=TBD2, dst port=TBD2] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA) IPv6 header (src= CN, dst= MN-HOA)
OR OR
IPv4 header (src= CN, dst= IPv4 MN-HoA) IPv4 header (src=CN, dst=IPv4-MN-HoA)
Figure 14 Figure 14: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP
encapsulation mode)
o Forwarding Packets received from the bi-directional tunnel: o Forwarding Packets received from the bi-directional tunnel:
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST remove the outer header before forwarding the packet gateway MUST remove the outer header before forwarding the packet
to the mobile node. to the mobile node.
4.3. IPsec Considerations 4.3. IPsec Considerations
skipping to change at page 48, line 7 skipping to change at page 46, line 7
The following section describes how IPsec is used for protecting the The following section describes how IPsec is used for protecting 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 SPD example entries to protect PBU and PBA on
the local mobility anchor and mobile access gateway. the local mobility anchor and mobile access gateway.
MAG SPD-S: MAG SPD-S:
- IF local_address = Proxy-CoA_1 & - IF local_address = Proxy-CoA_1 &
remote_address = LMAA_1 & proto = MH & remote_address = LMAA_1 & proto = UDP &
local_mh_type = PBU & remote_mh_type = PBAck remote_port = TBD1
Then use SA ESP transport mode Then use SA ESP transport mode
LMA SPD-S: LMA SPD-S:
- IF local_address = LMAA_1 & - IF local_address = LMAA_1 &
remote_address = Proxy-CoA_1 & proto = MH & remote_address = Proxy-CoA_1 & proto = UDP &
local_mh_type = PBAck & remote_mh_type = PBU local_port = TBD1
Then use SA ESP transport mode Then use SA ESP transport mode
Figure 15 and Figure 16 show how PBU and PBA are sent and processed
at the local mobility anchor and at the mobile access gateway. IPsec
ESP is always applied before the PBU or the PBA is encapsulated in
the outer IPv4 header.
| PBU on wire : PBU internal processing
\|/ \:/
MAG's PMIP Module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
\:/
MAG's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in transport mode
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
: * After adding the ESP header, the PBU is returned to the PMIP
: module and is encapsulated into the UDP and IPv4 headers.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via the normal forwarding
\:/
MAG
| IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
| UDP header (sport=Z, dport=DSMIPv6)
| IPv6 header (src=Proxy-CoA, dst=LMAA)
| ESP header in transport mode
| Mobility header
| PBU (p flag)
| Home Network Prefix option
| IPv4 Home Address Request option
| IPv4 Care-of Address option
\|/
LMA (received at DSMIPv6 port)
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in transport mode
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) needs to
: be passed along with the packet to ensure correct processing.
\:/
LMA's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
LMA's PMIP module
Figure 15: Proxy Binding Update
| PBA on wire : PBA internal processing
\|/ \:/
LMA's PMIP module
:
: IPv6 header (src=LMAA, dst=Proxy-CoA)
: Mobility header
: PBA (p flag)
: Home Network Prefix option
: IPv4 Home Address Reply option
: IPv4 Care-of Address option
\:/
LMA's IPsec module
:
: IPv6 header (src=LMAA, dst=Proxy-CoA)
: ESP header in transport mode
: Mobility header
: PBA (p flag)
: Home Network Prefix option
: IPv4 Home Address Reply option
: IPv4 Care-of Address option
:
: * After adding the ESP header, the PBA is returned to the PMIP
: module and is encapsulated into the UDP and IPv4 headers.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via normal forwarding
\:/
LMA
| IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
| UDP header (sport=DSMIPv6, dport=Z)
| IPv6 header (src=LMAA, dst=Proxy-CoA)
| ESP header in transport mode
| Mobility header
| PBA (p flag)
| Home Network Prefix option
| IPv4 Home Address Reply option
| IPv4 Care-of Address option
\|/
MAG (received at DSMIPv6 listening port)
:
: IPv6 header (src=LMAA, dst=Proxy-CoA)
: ESP header in transport mode
: Mobility header
: PBA (p flag)
: Home Network Prefix option
: IPv4 Home Address Reply option
: IPv4 Care-of Address option
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
MAG's IPsec module
:
: IPv6 header (src=LMAA, dst=Proxy-CoA)
: Mobility header
: PBA (p flag)
: Home Network Prefix option
: IPv4 Home Address Reply option
: IPv4 Care-of Address option
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
MAG's PMIP module
Figure 16: Proxy Binding Acknowledgement
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.
MAG SPD-S: MAG SPD-S:
- IF interface = IPv6 tunnel to LMAA_1 & - IF interface = tunnel to LMAA_1 &
local_address != Proxy-CoA_1 & local_address != Proxy-CoA_1 &
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 = IPv6 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 a payload packet is protected by IPsec, MAG and LMA SHOULD When payload packets are protected by IPsec, payload packets matching
always use the tunnel IPv6 header to let the payload packet be IPsec to the SPDs are passed to the IPsec module and encapsulated using the
protected in the ESP tunnel mode. If IPsec is not applied to payload tunnel mode ESP. The tunnel mode ESP encapsulated payload packets
packets, this additional tunnel IPv6 header SHOULD be omitted and an are then directly sent to the peer mobile access gateway or local
IPv4 header SHOULD be used to encapsulate the data packet as shown in mobility anchor. If IPsec is not applied to payload packets, then
Figure 14 . they are encapsulated as shown in Figures 12 and 14.
| Packet on wire : Packet internal processing
\|/ \:/
MN
| IPv4/v6 header (src= MN-HoA, dst= CN)
| Payload
\|/
MAG's PMIP Module
:3
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
\:/
MAG's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
: * After the ESP header installation, the payload packet is returned
: to the PMIP module and is encapsulated for the tunnel between MAG
: and LMA. If necessary, the UDP and TLV headers are added to the
: payload packet.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via normal forwarding
\:/
MAG
|
| IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
| UDP header (sport=Z, dport=DSMIPv6) /* If UDP encap nego */
| TLV Header /* If TLV negotiated */
| IPv6 header (src=Proxy-CoA, dst=LMAA)
| ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
| Payload
\|/
LMA (received at DSMIPv6 port)
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
LMA's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
LMA forwarding engine
Figure 17: IPsec Protected Payload Packet
5. Protocol Configuration Variables 5. Protocol Configuration Variables
5.1. Local Mobility Anchor - Configuration Variables 5.1. Local Mobility Anchor - Configuration Variables
The local mobility anchor MUST allow the following variables to be The local mobility anchor MUST allow the following variables to be
configured by the system management. The configured values for these configured by the system management. The configured values for these
protocol variables MUST survive server reboots and service restarts. protocol variables MUST survive server reboots and service restarts.
AcceptForcedIPv4UDPEncapsulationRequest AcceptForcedIPv4UDPEncapsulationRequest
This flag indicates whether or not the local mobility anchor This flag indicates whether or not the local mobility anchor
should accept IPv4 UDP encapsulation request for the mobile node's should accept IPv4 UDP encapsulation request for the mobile node's
data traffic, even if there is no NAT detected in the path. data traffic. The default value for this flag is set to (0),
indicating that plain IPv4 encapsulation (without UDP) is used for
The default value for this flag is set to (0), indicating that the data traffic.
local mobility anchor MUST NOT accept IPv4 UDP encapsulation
request when NAT is not detected in the path.
When the value for this flag is set to (1), the local mobility
anchor MUST accept IPv4 UDP encapsulation request even when NAT is
not detected in the path.
5.2. Mobile Access Gateway - Configuration Variables 5.2. Mobile Access Gateway - Configuration Variables
The mobile access gateway MUST allow the following variables to be The mobile access gateway MUST allow the following variables to be
configured by the system management. The configured values for these configured by the system management. The configured values for these
protocol variables MUST survive server reboots and service restarts. protocol variables MUST survive server reboots and service restarts.
UseIPv4UDPEncapForSignalingMessages
This flag indicates whether or not the mobile access gateway
should use IPv4-UDP encapsulation mode for the signaling messages.
The default value for this flag is set to (0), indicating that the
mobile access gateway MUST NOT use IPv4-UDP encapsulation mode,
but MUST use native IPv4 encapsulation mode for sending the Proxy
Mobile IPv6 signaling messages.
When the value for this flag is set to (1), the mobile access
gateway MUST use IPv4-UDP encapsulation mode for sending the Proxy
Mobile IPv6 signaling messages.
ForceIPv4UDPEncapsulationSupport ForceIPv4UDPEncapsulationSupport
This flag indicates whether or not the mobile access gateway
should request the mobile node's local mobility anchor for forcing
IPv4 UDP encapsulation support for the mobile node's data traffic,
even when NAT is not detected in the path.
The default value for this flag is set to (0), indicating that the This flag indicates whether or not the mobile access gateway
mobile access gateway MUST NOT request the mobile node's local should request the mobile node's local mobility anchor to use
mobility anchor for forcing IPv4 UDP encapsulation support even IPv4-UDP encapsulation mode for the mobile node's data traffic.
when NAT is not detected in path. The default value for this flag is set to (0), indicating that
plain IPv4 encapsulation (without UDP) is used for data traffic.
When the value for this flag is set to (1), the mobile access
gateway MUST force the mobile node's local mobility anchor for
IPv4 UDP encapsulation support.
This flag is applicable only when the flag
UseIPv4UDPEncapForSignalingMessages is set to a value of (1).
6. IANA Considerations 6. IANA Considerations
This document defines four new Mobility Header options, IPv4 Home This document defines four new Mobility Header options, 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 needs to be 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 [RFC-3775]. options, as defined in [RFC-3775].
skipping to change at page 58, line 5 skipping to change at page 49, line 17
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: IANA
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: IANA
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
"pmip6-cntl" and "pmip6-data", respectively.
7. Security Considerations 7. Security Considerations
All the security considerations from the base Proxy Mobile IPv6 [RFC- All the security considerations from the base Proxy Mobile IPv6
5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555] [RFC-5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6
apply when using the extensions defined in this document. [RFC-5555] apply when using the extensions defined in this document.
Additionally, the following security considerations need to be Additionally, the following security considerations need to be
applied. applied.
This document defines 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 the signaling messages between the local mobility anchor and the
mobile access gateway. These signaling messages are fundamentally mobile access gateway. These can be protected using IPsec as
IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 described in Section 4.3.
packets. The encapsulated inner IPv6 message is still protected
using IPsec, using the established security association and this
offers the same level of security as when the messages are routed
natively as IPv6 packets. The use of outer IPv4 header does not
introduce any new security vulnerabilities.
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
Sangjin Jeong Sangjin Jeong
sjjeong@etri.re.kr sjjeong@etri.re.kr
Basavaraj Patil Basavaraj Patil
basavaraj.patil@nsn.com basavaraj.patil@nokia.com
Myungki Shin Myungki Shin
myungki.shin@gmail.com myungki.shin@gmail.com
9. Acknowledgments 9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like internet-draft [draft-sgundave-mip6-proxymip6-02.txt"/>. We would
to thank all the authors of the document and acknowledge that initial like to thank all the authors of the document and acknowledge that
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 and 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. document as part of the IESG review process.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-netlmm-grekey-option]
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.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol",
2131, March 1997. RFC 2131, March 1997.
[RFC-2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3046] Patrick, M., "DHCP Relay Agent Information Option",
IPv6", RFC 3775, June 2004. RFC 3046, January 2001.
[RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
Addresses", RFC-4193, October 2005. in IPv6", RFC 3775, June 2004.
[RFC-4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms [RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing [RFC-4361] Lemon, T. and B. Sommerfeld, "Node-specific Client
Architecture", RFC-4291, February 2006. Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, [RFC-5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
November 2007. "DHCP Server Identifier Override Suboption", RFC 5107,
February 2008.
[RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack [RFC-5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC-5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
10.2. Informative References 10.2. Informative References
[RFC-925] Postel, J., "Multi-LAN Address Resolution", RFC 925, [RFC-0925] Postel, J., "Multi-LAN address resolution", RFC 925,
October 1984. October 1984.
[RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC-1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC E. Lear, "Address Allocation for Private Internets",
1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001. Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January
2001.
[RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC-4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC-4361] Lemon, T. and B. Sommerfield, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Version Four
(DHCPv4)", RFC 4361, February 2006.
[RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network
Attachment in IPv4", RFC 4436, March 2006.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Mobility", RFC 4977, August 2007. RFC 4306, December 2005.
[RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, [RFC-4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
"DHCP Server Identifier Override Suboption", RFC 5107, February 2008. Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., [RFC-4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual
"GRE Key Option for Proxy Mobile IPv6", Stack Mobility", RFC 4977, August 2007.
draft-ietf-netlmm-grekey-option-09.txt, 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
 End of changes. 124 change blocks. 
687 lines changed or deleted 354 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/