draft-ietf-netlmm-pmip6-ipv4-support-09.txt   draft-ietf-netlmm-pmip6-ipv4-support-10.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: July 24, 2009 Cisco Expires: September 25, 2009 Cisco
January 20, 2009 March 24, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-09.txt draft-ietf-netlmm-pmip6-ipv4-support-10.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 July 24, 2009. This Internet-Draft will expire on September 25, 2009.
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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) enable IPv4 home address mobility support to the mobile two-fold: 1) enable IPv4 home address mobility support to the mobile
node. 2) allowing the mobility entities in the Proxy Mobile IPv6 node. 2) allowing the mobility entities in the Proxy Mobile IPv6
domain to exchange signaling messages over an IPv4 transport network. domain to exchange signaling messages over an IPv4 transport network.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6
1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 7
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 9
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 11
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 12
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 12
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 12
3.1.3. Routing Considerations for the Local Mobility 3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 16 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 19
3.2.1. Extensions to Binding Update List Entry . . . . . . . 17 3.2.1. Extensions to Binding Update List Entry . . . . . . . 19
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 19
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . 22 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 24
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 24
3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 25
3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 26
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 25 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 26
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 26 Gateway . . . . . . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . . . . 29 Gateway . . . . . . . . . . . . . . . . . . . . . . . 30
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 33
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 34
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 34
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 35
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 35
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 38
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 39
4.2.1. Extensions to Binding Update List Entry . . . . . . . 38 4.2.1. Extensions to Binding Update List Entry . . . . . . . 39
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 42 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 43
5.1. Local Mobility Anchor - Configuration Variables . . . . . 42 5.1. Local Mobility Anchor - Configuration Variables . . . . . 43
5.2. Mobile Access Gateway - Configuration Variables . . . . . 42 5.2. Mobile Access Gateway - Configuration Variables . . . . . 43
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 47 10.2. Informative References . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
1. Overview 1. Overview
The transition from IPv4 to IPv6 is a long process and during this The transition from IPv4 to IPv6 is a long process and during this
period of transition, both the protocols will be enabled over the period of transition, both the protocols will be enabled over the
same network infrastructure. Thus, it is reasonable to assume that a same network infrastructure. Thus, it is reasonable to assume that a
mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only
IPv6-only or in dual-stack mode and additionally the network between IPv6-only or in dual-stack mode and additionally the network between
the mobile access gateway and a local mobility anchor may be an IPv4 the mobile access gateway and a local mobility anchor may be an IPv4
or an IPv6 network. It is also reasonable to expect the same or an IPv6 network. It is also reasonable to expect the same
skipping to change at page 7, line 30 skipping to change at page 7, line 30
configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332],
IKEv2 [RFC-4306] or static address configuration. IKEv2 [RFC-4306] or static address configuration.
o The mobile node's IPv4 home subnet is typically a shared address o The mobile node's IPv4 home subnet is typically a shared address
space. It is not for the exclusive use of any one mobile node. space. It is not for the exclusive use of any one mobile node.
There can be multiple mobile nodes that are assigned IPv4 There can be multiple mobile nodes that are assigned IPv4
addresses from the same subnet. addresses from the same subnet.
o The mobile access gateway is the IPv4 default-router for the o The mobile access gateway is the IPv4 default-router for the
mobile node on its access link. It will be in the forwarding path mobile node on its access link. It will be in the forwarding path
for the mobile node's data traffic. 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
Proxy Mobile IPv6 domain MUST use the same link-layer address on
any of the access links wherever the mobile node attaches.
1.2. Relevance to Dual-Stack Mobile IPv6
IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6
specification [ID-DSMIP6]. This document to most part leverages the
approaches, messaging options and processing logic defined in that
document for extending IPv4 support to Proxy Mobile IPv6, except with
deviation in some aspects for obvious reasons of supporting a
network-based mobility model. Following are some of the related
considerations.
o The messaging options, IPv4 Home Address, IPv4 Address
Acknowledgement, IPv4 Care-of Address option defined in [ID-
DSMIP6] for use in Binding Update and Binding Acknowledgement
messages are used by this specification to be carried in Proxy
Binding Update and Proxy Binding Acknowledgement messages.
o The extensions needed to the conceptual data structures, Binding
Cache entry and Binding Update List entry, for storing the state
related to the IPv4 support defined in [ID-DSMIP6], will all be
needed and relevant for this document.
o The NAT traversal logic specified in [ID-DSMIP6] for detecting the
on-path NAT devices is valid for this specification as well.
o The tunneling considerations specified in [ID-DSMIP6] for
supporting IPv4 transport is relevant for this document as well.
If a given home agent [RFC-3775] implementation has support for both
Dual-stack Mobile IPv6 [ID-DSMIP6] and local mobility anchor function
[RFC-5213], when extending IPv4 support as specified in this document
the above common functions and the related considerations have to be
reused for Proxy Mobile IPv6 signaling flows.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
skipping to change at page 8, line 42 skipping to change at page 9, line 42
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)
This is the IPv4 home address assigned to the mobile node's The IPv4 home address assigned to the mobile node's attached
attached interface. This address is topologically anchored at the interface. This address is topologically anchored at the local
local mobility anchor. The mobile node configures this address on mobility anchor. The mobile node configures this address on its
its attached interface. If the mobile node connects to the Proxy attached interface. If the mobile node connects to the Proxy
Mobile IPv6 domain via multiple interfaces each of the interfaces Mobile IPv6 domain via multiple interfaces each of the interfaces
are assigned a unique IPv4 address. All the IPv6 home network are assigned a unique IPv4 address. All the IPv6 home network
prefixes and the IPv4 home address assigned to a given interface prefixes and the IPv4 home address assigned to a given interface
of a mobile node will be managed under one mobility session. of a mobile node will be managed under one mobility session.
Selective De-registration Selective De-registration
It is a procedure for partial de-registration of all the addresses It is a procedure for partial de-registration of all the addresses
that belong to one address family, i.e., de-registration of either that belong to one address family, i.e., de-registration of either
IPv4 home address, or all of the IPv6 home network prefixes. IPv4 home address, or all of the IPv6 home network prefixes.
Encapsulation Modes Encapsulation Modes
This document uses the following terms when referring to the This document uses the following terms when referring to the
different encapsulation modes. different encapsulation modes.
IPv4-over-IPv6 IPv4-or-IPv6-over-IPv6
IPv4 packet carried as a payload of an IPv6 packet IPv4 or IPv6 packet carried as a payload of an IPv6 packet
IPv4-over-IPv4 IPv4-or-IPv6-over-IPv4
IPv4 packet carried as a payload of an IPv4 packet IPv4 or IPv6 packet carried as a payload of an IPv4 packet
IPv4-over-IPv4-UDP IPv4-or-IPv6-over-IPv4-UDP
IPv4 packet carried as a payload in an UDP header of an IPv4 IPv4 or IPv6 packet carried as a payload in an UDP header of an
packet IPv4 packet
IPv4-over-IPv4-UDP-TLV IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4 packet carried as a payload in an IPv4 packet with UDP and IPv4 packet carried as a payload in an IPv4 packet with UDP and
TLV headers TLV headers
3. IPv4 Home Address Mobility Support 3. IPv4 Home Address Mobility Support
The IPv4 home address mobility support essentially enables a mobile The IPv4 home address mobility support essentially enables a mobile
node in a Proxy Mobile IPv6 domain to obtain IPv4 home address node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
configuration for its attached interface and be able to retain that configuration for its attached interface and be able to retain that
address configuration even after changing its point of attachment in address configuration even after changing its point of attachment in
skipping to change at page 11, line 19 skipping to change at page 12, line 19
scenario, there will be multiple Binding Cache entries for the mobile scenario, there will be multiple Binding Cache entries for the mobile
node on the local mobility anchor. All the address (IPv4/IPv6) node on the local mobility anchor. All the address (IPv4/IPv6)
assigned to a given interface will be managed as part of one mobility assigned to a given interface will be managed as part of one mobility
session, as specified in Section 5.4 of [RFC-5213]. session, as specified in Section 5.4 of [RFC-5213].
3.1. Local Mobility Anchor Considerations 3.1. Local Mobility Anchor Considerations
3.1.1. Extensions to Binding Cache Entry 3.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor needs to be structure maintained by the local mobility anchor needs to include
extended with the following additional parameters. the following parameters.
o The IPv4 home address assigned to the mobile node's interface and o The IPv4 home address assigned to the mobile node's interface and
registered by the mobile access gateway. The IPv4 home address registered by the mobile access gateway. The IPv4 home address
entry also includes the corresponding subnet mask. entry also includes the corresponding subnet mask. It is to be
noted that this parameter is defined in the [ID-DSMIP6] and is
presented here for completeness.
o The IPv4 default-router address assigned to the mobile node. o The IPv4 default-router address assigned to the mobile node.
3.1.2. Signaling Considerations 3.1.2. Signaling Considerations
3.1.2.1. Processing Proxy Binding Updates 3.1.2.1. Processing Proxy Binding Updates
The processing rules specified in Section 5.3 of [RFC-5213] are The processing rules specified in Section 5.3 of [RFC-5213] are
applied for processing the received Proxy Binding Update message. applied for processing the received Proxy Binding Update message.
However, if the received Proxy Binding Update message has an IPv4 However, if the received Proxy Binding Update message has an IPv4
skipping to change at page 12, line 7 skipping to change at page 13, line 7
Section 5.3.1 of [RFC-5213]. At least one instance of any of Section 5.3.1 of [RFC-5213]. At least one instance of any of
these two options MUST be present. If there is not a single these two options MUST be present. If there is not a single
instance of any of these two options present in the request, the instance of any of these two options present in the request, the
local mobility anchor MUST reject the request and send a Proxy local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with Status field set to Binding Acknowledgement message with Status field set to
MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213]. network prefix option) [RFC-5213].
o If there is at least one instance of Home Network Prefix option 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 the mobile node is not IPv6 enabled, or if IPv6 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
routing not enabled in the home network, the local mobility anchor routing not enabled in the home network, the local mobility anchor
MUST reject the request and send a Proxy Binding Acknowledgement MUST reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to message with the Status field set to
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not
authorized for the requesting IPv6 home network prefix). authorized for the requesting IPv6 home network prefix).
o If there are more than one instance of the IPv4 Home Address o If there are more than one instance of the IPv4 Home Address
option present in the request, then the local mobility anchor MUST option present in the request, then the local mobility anchor MUST
reject the request and send a Proxy Binding Acknowledgement reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to message with the Status field set to
skipping to change at page 14, line 10 skipping to change at page 15, line 12
request also contains one or more Home Network Prefix options [ID- request also contains one or more Home Network Prefix options [ID-
DSMIP6], there should still be only one Binding Cache entry that DSMIP6], there should still be only one Binding Cache entry that
should be created for this mobility session. The created Binding should be created for this mobility session. The created Binding
Cache entry MUST be used for managing both IPv4 and IPv6 home Cache entry MUST be used for managing both IPv4 and IPv6 home
address bindings. The fields in the Binding Cache entry MUST be address bindings. The fields in the Binding Cache entry MUST be
updated with the accepted values for that session. updated with the accepted values for that session.
o The local mobility anchor MUST establish a bi-directional tunnel o The local mobility anchor MUST establish a bi-directional tunnel
to the mobile access gateway and with the encapsulation mode set to the mobile access gateway and with the encapsulation mode set
to the negotiated mode for carrying the IPv4 payload traffic. to the negotiated mode for carrying the IPv4 payload traffic.
When using IPv6 transport, the encapsulation mode is IPv4-over- When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-
IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6
using IPv4 transport, the encapsulation mode is as specified in packet). When using IPv4 transport, the encapsulation mode is as
Section 4.0. specified in Section 4.0.
o The local mobility anchor MUST create an IPv4 host route (or a o The local mobility anchor MUST create an IPv4 host route (or a
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 16, line 31 skipping to change at page 17, line 34
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] requires the Home Network Prefix [RFC-5213] as 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213]
the key parameter for identifying the Binding Cache entry. When as the key parameter for identifying the Binding Cache entry.
using an IPv4 address with a NON_ZERO value, the exact same However, when there is not a single Home Network Prefix option with
considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be NON_ZERO value present in the request, but if there an IPv4 Home
applied, with the exception of using an IPv4 home address in place of Address option with a NON_ZERO value present in the request, the
an IPv6 home network prefix. following considerations MUST be applied.
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
equally valid when using a single IPv4 home address as the key.
When applying those considerations, instead of the IPv6 home
network prefix(es), the IPv4 home address from the IPv4 Home
Address option present in the request MUST be used as the search
key.
o These rules specified in section 5.4.1.1 of [RFC-5213], assume the
presence of one or more IPv6 home network prefixes in the received
request and also in the Binding Cache entry. But, when using the
IPv4 home address as the search key, these considerations MUST
always assume just one single IPv4 home address, both in the
request and also in the request.
3.1.3. Routing Considerations for the Local Mobility Anchor 3.1.3. Routing Considerations for the Local Mobility Anchor
Intercepting Packets Sent to the Mobile Node's IPv4 home address: Intercepting Packets Sent to the Mobile Node's IPv4 home address:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
be able to receive packets that are sent to the mobile node's IPv4 be able to receive packets that are sent to the mobile node's IPv4
home address. In order for it to receive those packets, it MUST home address. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for advertise a connected route in to the Routing Infrastructure for
the mobile node's IPv4 home address or for its home subnet. This the mobile node's IPv4 home address or for its home subnet. This
skipping to change at page 20, line 25 skipping to change at page 21, line 51
that mobile node. The entry MUST be updated with the assigned that mobile node. The entry MUST be updated with the assigned
IPv4 home address and other accepted registration values. IPv4 home address and other accepted registration values.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted) and Status field value set to 0 (Proxy Binding Update accepted) and
has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a
value that indicates that the request was accepted by the local value that indicates that the request was accepted by the local
mobility anchor, the mobile access gateway MUST establish a bi- mobility anchor, the mobile access gateway MUST establish a bi-
directional tunnel to the local mobility anchor (if there is no directional tunnel to the local mobility anchor (if there is no
existing bi-directional tunnel to that local mobility anchor) and existing bi-directional tunnel to that local mobility anchor) and
with the encapsulation mode set to IPv4-over-IPv6 (IPv4 packet with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or
carried as a payload of an IPv6 packet). Considerations from IPv6 packet carried as a payload of an IPv6 packet).
Section 5.6.1 of [RFC-5213] MUST be applied for managing the
dynamically created bi-directional tunnel. However, when using Considerations from Section 5.6.1 of [RFC-5213] MUST be applied
IPv4 transport, the encapsulation mode MUST be set to the for managing the dynamically created bi-directional tunnel.
negotiated encapsulation mode, as specified in Section 4 of this However, when using IPv4 transport, the encapsulation mode MUST be
specification. set to the negotiated encapsulation mode, as specified in Section
4 of this specification.
o The mobile access gateway MUST set up the route for forwarding the o The mobile access gateway MUST set up the route for forwarding the
IPv4 packets received from the mobile node (using its IPv4 home IPv4 packets received from the mobile node (using its IPv4 home
address) through the bi-directional tunnel set up for that mobile address) through the bi-directional tunnel set up for that mobile
node. node.
o The default-router address MUST be obtained from the IPv4 Default- o The default-router address MUST be obtained from the IPv4 Default-
Router Address option present in the received Proxy Binding Router Address option present in the received Proxy Binding
Acknowledgement message. The mobile access gateway MAY configure Acknowledgement message. The mobile access gateway MAY configure
this address on its interface and respond to any ARP requests sent this address on its interface and respond to any ARP requests sent
skipping to change at page 25, line 31 skipping to change at page 27, line 13
The following are the configuration requirements: The following are the configuration requirements:
o The DHCP server or the DHCP relay agent configured on the mobile o The DHCP server or the DHCP relay agent configured on the mobile
access gateway is required to have an IPv4 address for exchanging access gateway is required to have an IPv4 address for exchanging
the DHCP messages with the mobile node. This address can be the DHCP messages with the mobile node. This address can be
either the IPv4 Proxy Care-of Address or the mobile node's either the IPv4 Proxy Care-of Address or the mobile node's
default-router address provided by the local mobility anchor. default-router address provided by the local mobility anchor.
Optionally, all the DHCP servers co-located with the mobile access Optionally, all the DHCP servers co-located with the mobile access
gateways in the Proxy Mobile IPv6 domain can be configured with a gateways in the Proxy Mobile IPv6 domain can be configured with a
fixed IPv4 address. This fixed address can be potentially an IPv4 fixed IPv4 address. This fixed address can be potentially an IPv4
link-local address [RFC-3927] that can be used for the DHCP private address [RFC-1918] that can be used for the DHCP protocol
protocol communication on any of the access links. This address communication on any of the access links. This address will be
will be used as the server identifier in the DHCP messages. used as the server identifier in the DHCP messages.
o The DHCP server identifies the DHCP client either from the client o The DHCP server identifies the DHCP client either from the client
identifier or the client hardware address (chaddr) [RFC-2131]. A identifier or the client hardware address (chaddr) [RFC-2131]. A
mobile node in a Proxy Mobile IPv6 domain may present any of these mobile node in a Proxy Mobile IPv6 domain may present any of these
identifiers to the DHCP server as long as the identifier remains identifiers to the DHCP server as long as the identifier remains
the same through out the mobile node's attachment in that Proxy the same through out the mobile node's attachment in that Proxy
Mobile IPv6 domain. If the client hardware address is used as the Mobile IPv6 domain. If the client hardware address is used as the
identifier and if the mobile node performs an handoff between two identifier and if the mobile node performs an handoff between two
interfaces, this hardware identifier will change and the DHCP interfaces, this hardware identifier will change and the DHCP
server will not be able to identify the mobile node. Thus, it is server will not be able to identify the mobile node. Thus, it is
skipping to change at page 26, line 43 skipping to change at page 28, line 31
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the
DHCP server co-located with the mobile access gateway will trigger DHCP server co-located with the mobile access gateway will trigger
the mobile access gateway to complete the Proxy Mobile IPv6 the mobile access gateway to complete the Proxy Mobile IPv6
signaling. This is the required interaction between these two signaling. This is the required interaction between these two
protocols. If the mobile access gateway is unable to complete the protocols. If the mobile access gateway is unable to complete the
Proxy Mobile IPv6 signaling, or, if the local mobility anchor does Proxy Mobile IPv6 signaling, or, if the local mobility anchor does
not assign an IPv4 address for the mobile node, the mobile access not assign an IPv4 address for the mobile node, the mobile access
gateway MUST NOT enable IPv4 support for the mobile node on that gateway MUST NOT enable IPv4 support for the mobile node on that
access link. access link. The trigger for initiating Proxy Mobile IPv6
signaling can also be delivered to the mobile access gateway as
part of a context transfer from the previous mobile access
gateway, or delivered from the other network elements in the radio
network, the details of which are outside the scope of this
document.
o After a successful completion of the Proxy Mobile IPv6 signaling o After a successful completion of the Proxy Mobile IPv6 signaling
and upon acquiring the mobile node's IPv4 home address from the and upon acquiring the mobile node's IPv4 home address from the
local mobility anchor, the DHCP server on the mobile access local mobility anchor, the DHCP server on the mobile access
gateway will send a DHCPOFFER message [RFC-2131] to the mobile gateway will send a DHCPOFFER message [RFC-2131] to the mobile
node. The offered address will be the mobile node's IPv4 home node. The offered address will be the mobile node's IPv4 home
address, assigned by the local mobility anchor. The server address, assigned by the local mobility anchor. The server
address, 'siaddr' field of the DHCPOFFER message, will be set to address, 'siaddr' field of the DHCPOFFER message, will be set to
the mobile node's default-router address. The DHCPOFFER message the mobile node's default-router address. The DHCPOFFER message
will be unicasted to the mobile node. will be sent to the mobile node just as specified in [RFC-2131].
o If the mobile node sends the DHCPREQUEST message, the DHCP server o If the mobile node sends the DHCPREQUEST message, the DHCP server
will send DHCPACK message, as per [RFC-2131]. will send DHCPACK message, as per [RFC-2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff): IPv4 Home Address Renewal with the DHCP server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state [RFC- o Any time the mobile node goes into the DHCP RENEWING state [RFC-
2131], it simply unicasts the DHCPREQUEST message including the 2131], it simply unicasts the DHCPREQUEST message including the
assigned IPv4 home address in the 'requested IP address' option. assigned IPv4 home address in the 'requested IP address' option.
The DHCPREQUEST is sent to the address specified in 'server The DHCPREQUEST is sent to the address specified in 'server
skipping to change at page 28, line 5 skipping to change at page 29, line 30
When the mobile node goes into the DHCP RENEWING state [RFC-2131], it When the mobile node goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile changed its point of attachment and is attached to a new mobile
access gateway, it is required that the mobile node updates the DHCP access gateway, it is required that the mobile node updates the DHCP
server address and uses the address of the DHCP server that is co- server address and uses the address of the DHCP server that is co-
located with the new mobile access gateway. Any of the following located with the new mobile access gateway. Any of the following
approaches can be adopted to ensure the mobile node uses the DHCP approaches can be adopted to ensure the mobile node uses the DHCP
server on the attached link. server on the attached link.
1. The use of fixed DHCP server address on all DHCP servers The use of fixed DHCP server address on all DHCP servers
MN oMAG(DHCP-S) nMAG(DHCP-S) MN oMAG(DHCP-S) nMAG(DHCP-S)
| : | | : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK or DHCPNACK BOUND<-------------| 2. DHCPACK or DHCPNACK
| : | | : |
2. The use of FORCERENEW message to notify the address change
MN prev-MAG (DHCP-S) new-MAG (DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA)
|<---------------| 2. FORCERENEW
|--------------->| 3. DHCPREQUEST*b (IPv4 HoA)
BOUND<-------------| 4. DHCPACK or DHCPNACK
| : |
*a DHCPREQUEST sent to oMAG
*b DHCPREQUEST sent to nMAG
Figure 6: Address renewal with a different DHCP server Figure 6: Address renewal with a different DHCP server
o If a fixed address such as the IPv4 default-router address of the o If a fixed address such as the IPv4 default-router address of the
mobile node is used as the DHCP server Id on any of the links in mobile node is used as the DHCP server Id on any of the links in
that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the
mobile node for renewing the address will be received by the new mobile node for renewing the address will be received by the new
mobile access gateway on the attached link. The mobile access mobile access gateway on the attached link. The mobile access
gateway after completing the Proxy Mobile IPv6 signaling and upon gateway after completing the Proxy Mobile IPv6 signaling and upon
acquiring the IPv4 home address of the mobile node will return the acquiring the IPv4 home address of the mobile node will return the
address in the DHCPACK message. However, if the mobile access address in the DHCPACK message. However, if the mobile access
gateway is unable to complete the Proxy Mobile IPv6 signaling or gateway is unable to complete the Proxy Mobile IPv6 signaling or
is unable to acquire the same IPv4 address as requested by the is unable to acquire the same IPv4 address as requested by the
mobile node, it will send a DHCPNACK message [RFC-2131] to the mobile node, it will send a DHCPNACK message [RFC-2131] to the
mobile node, as shown in Figure 6-1). mobile node, as shown in Figure 6-1).
o If the mobile access gateway on the access link receives any DHCP
messages from the mobile node unicasted to a server address that
is not locally configured, the mobile access gateway can unicast
FORCERENEW message [RFC-3203] to the mobile node as shown in
Figure 6-2). This will force the mobile node to update the DHCP
server address with the address of the mobile access gateway on
the new link. However, if the FORCERENEW message [RFC-3203] is
also not supported by the DHCP server on the mobile access
gateway, then that DHCPREQUEST message can be ignored. This will
force the mobile node to enter the DHCP REBINDING state [RFC-2131]
and start the DHCPDISCOVER phase again.
Additional Operation: Additional Operation:
o If at any point the mobile access gateway fails to extend the o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it can send the unicast FORCERENEW message node's IPv4 address, it MUST remove any forwarding state set up
[RFC-3203] to the mobile node to force it to change its DHCP state for the mobile node's IPv4 home address.
to the RENEW state. Furthermore, it MUST remove forwarding for
the mobile node's IPv4 home address.
3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway
A DHCP relay 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 7 shows (e.g., is co-located with the local mobility anchor). Figure 7 shows
the sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
skipping to change at page 29, line 46 skipping to change at page 31, line 6
o When the mobile access gateway receives a DHCPDISCOVER message o When the mobile access gateway receives a DHCPDISCOVER message
from a mobile node, it can check if there is already an assigned from a mobile node, it can check if there is already an assigned
IPv4 home address for the mobile node from the local mobility IPv4 home address for the mobile node from the local mobility
anchor. If there is no assigned IPv4 home address assigned for anchor. If there is no assigned IPv4 home address assigned for
that mobile node, the mobile access gateway has to complete the that mobile node, the mobile access gateway has to complete the
Proxy Mobile IPv6 signaling with the local mobility anchor by Proxy Mobile IPv6 signaling with the local mobility anchor by
sending a Proxy Binding Update message. sending a Proxy Binding Update message.
o If the Proxy Binding Update message is rejected by the local o If the Proxy Binding Update message is rejected by the local
mobility anchor for any reason, the local mobility anchor will mobility anchor for any reason, the mobile access gateway will
discard the DHCPDISCOVER messages from the mobile node. discard the DHCPDISCOVER messages from the mobile node.
o If the Proxy Binding Update message is accepted by the local o If the Proxy Binding Update message is accepted by the local
mobility anchor and if there is an assigned IPv4 home address for mobility anchor and if there is an assigned IPv4 home address for
the mobile node, the DHCP messages will be forwarded to the DHCP the mobile node, the DHCP messages will be forwarded to the DHCP
server. server.
o The DHCP relay agent on the mobile access gateway will add the o The DHCP relay agent on the mobile access gateway will add the
DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER
message. The assigned IPv4 home address will be included in the message. The assigned IPv4 home address will be included in the
skipping to change at page 30, line 31 skipping to change at page 31, line 35
node, then the mobile access gateway will drop the DHCPOFFER node, then the mobile access gateway will drop the DHCPOFFER
message and an administrative error message will be logged. message and an administrative error message will be logged.
o When the DHCP messages are sent over administrative boundaries, o When the DHCP messages are sent over administrative boundaries,
the operators needs to ensure these messages are secured. All the the operators needs to ensure these messages are secured. All the
DHCP messages relayed by the mobile access gateway can be tunneled DHCP messages relayed by the mobile access gateway can be tunneled
to the local mobility anchor if needed. Alternatively, if the to the local mobility anchor if needed. Alternatively, if the
network in the Proxy Mobile IPv6 domain is secure enough, the network in the Proxy Mobile IPv6 domain is secure enough, the
mobile access gateway can just relay the DHCP messages to the mobile access gateway can just relay the DHCP messages to the
server. To achieve this, all the mobile access gateways needs to server. To achieve this, all the mobile access gateways needs to
have route towards the DHCP server. have a route towards the DHCP server.
IPv4 Home Address Renewal to the same DHCP server: (No Handover) IPv4 Home Address Renewal to the same DHCP server: (No Handover)
o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
directly unicasts DHCPREQUEST message to the DHCP server. The directly unicasts DHCPREQUEST message to the DHCP server. The
DHCP relay agent may not detect these unicasted DHCPREQUEST DHCP relay agent may not detect these unicasted DHCPREQUEST
messages for renewing the address. Thus, any of the following messages for renewing the address. Thus, any of the following
approaches can be adopted. approaches can be adopted.
* The DHCP relay agent can intercept all the DHCP packets * The DHCP relay agent can intercept all IPv4 DHCP packets
regardless of the destination address. Since the link between destined to the set of addresses used within the Proxy Mobile
a mobile node and a mobile access gateway is the point-to-point IPv6 domain as DHCP addresses. Since the link between a mobile
link, the mobile access gateway will be in path for all the node and a mobile access gateway is the point-to-point link,
messages. the mobile access gateway will be in path for all the messages.
* The DHCP relay agent can use the DHCP Server Identifier * The DHCP relay agent can use the DHCP Server Identifier
Override Sub-option [RFC-5107] to be in path for all the DHCP Override Sub-option [RFC-5107] to be in path for all the DHCP
message flows. The DHCP client uses the DHCP server address message flows. The DHCP client uses the DHCP server address
which is overridden by the DHCP relay agent address as a which is overridden by the DHCP relay agent address as a
destination address of DHCPREQUEST. The DHCP Server Identifier destination address of DHCPREQUEST. The DHCP Server Identifier
Override Sub-option is recommended only when the fixed DHCP Override Sub-option is recommended only when the fixed DHCP
relay address is configured on all the mobile access gateways. relay address is configured on all the mobile access gateways.
Otherwise, the DHCP relay agent address is changed when the Otherwise, the DHCP relay agent address is changed when the
mobile node changes the attached mobile access gateway. mobile node changes the attached mobile access gateway.
o The DHCP Relay agent on detecting the DHCPREQUEST message from the o The DHCP Relay agent on detecting the DHCPREQUEST message from the
mobile node, will verify if the address in the DHCPREQUEST message mobile node, will verify if the address in the DHCPREQUEST message
is the address assigned by the local mobility anchor for that is the address assigned by the local mobility anchor for that
mobile node. If the requesting IPv4 home address is not mobile node. If the requesting IPv4 home address is not
registered to the local mobility anchor, the mobile access gateway registered to the local mobility anchor, the mobile access gateway
will drop the packet. Once the address verification is will drop the packet. Once the address verification is
successfully completed, the DHCP relay agent will forward the successfully completed, the DHCP relay agent will forward the
DHCPREQUEST message to the DHCP server. However, the mobile DHCPREQUEST message to the DHCP server. However, the mobile
access gateway is not required to perform this check, if the DHCP access gateway is neither required to perform this check, nor
server is co-located with the local mobility anchor, as that check intercept the DCHPREQUEST message from the mobile node, if the
will be performed by the local mobility anchor in such scenario. DHCP server is co-located with the local mobility anchor, as that
The mobile access gateway can determine the co-location of the check will be performed by the local mobility anchor in such
DHCP server and the local mobility anchor by comparing the source scenario. The mobile access gateway can determine the co-location
address of the DHCPOFFER message with the address of the mobile of the DHCP server and the local mobility anchor by comparing the
node's local mobility anchor. source address of the DHCPOFFER message with the address of the
mobile node's local mobility anchor.
IPv4 Address Release Triggers from the mobile node: IPv4 Address Release Triggers from the mobile node:
o The mobile node may release its IPv4 home address at any time by o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC-2131]. When the mobile sending the DHCPRELEASE message [RFC-2131]. When the mobile
access gateway detects the DHCPRELEASE message sent by the mobile access gateway detects the DHCPRELEASE message sent by the mobile
node and for releasing its assigned IPv4 home address, the mobile node and for releasing its assigned IPv4 home address, the mobile
access gateway should consider this as a trigger for de- access gateway should consider this as a trigger for de-
registering the mobile node's IPv4 home address. It MUST apply registering the mobile node's IPv4 home address. It MUST apply
the considerations specified in section 3.2.3.3 for performing the the considerations specified in section 3.2.3.3 for performing the
de-registration procedure. However, this operation should not de-registration procedure. However, this operation should not
release any IPv6 home network prefix(es) assigned to the mobile release any IPv6 home network prefix(es) assigned to the mobile
node. node.
Additional Operations: Additional Operations:
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 can send the unicast FORCERENEW message node's IPv4 address, it MUST remove any forwarding state set up
[RFC-3203] to the mobile node to force it to change its DHCP state for the mobile node's IPv4 home address.
to RENEW state. Furthermore, it MUST remove forwarding for the
mobile node IPv4 home address.
4. IPv4 Transport Support 4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling
messages exchanged between the local mobility anchor and the mobile messages exchanged between the local mobility anchor and the mobile
access gateway to be over an IPv6 transport. The extensions defined access gateway to be over an IPv6 transport. The extensions defined
in this section allow the exchange of signaling messages over an IPv4 in this section allow the exchange of signaling messages over an IPv4
transport when the local mobility anchor and the mobile access transport when the local mobility anchor and the mobile access
gateway are separated by an IPv4 network and are reachable using only gateway are separated by an IPv4 network and are reachable using only
IPv4 addresses. IPv4 addresses.
skipping to change at page 33, line 26 skipping to change at page 34, line 26
encapsulation modes for the signaling messages are either native encapsulation modes for the signaling messages are either native
IPv4 or IPv4 with UDP header. IPv4 or IPv4 with UDP header.
o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and
the IPv4 transport support specified in this section is agnostic the IPv4 transport support specified in this section is agnostic
to the type of address mobility enabled for that mobile node. to the type of address mobility enabled for that mobile node.
o The IPv4 tunnel established between the local mobility anchor and o The IPv4 tunnel established between the local mobility anchor and
the mobile access gateway (with any of the supported encapsulation the mobile access gateway (with any of the supported encapsulation
modes over IPv4 transport) will be used for carrying the mobile modes over IPv4 transport) will be used for carrying the mobile
node's IPv4 and IPv6 traffic. The supported encapsulation modes node's IPv4 and IPv6 traffic. The following are the outer headers
for carrying mobile node's IPv4 or IPv6 packets when using IPv4 based on the negotiated encapsulation mode.
transport are as shown below.
* 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
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). header). If payload protection using IPsec is enabled for the
tunneled traffic, the ESP header follows the outer tunnel
header, as specified in [RFC-3948].
* IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP
and TLV header). Refer to [ID-DSMIP6]. and TLV header). Refer to [ID-GREKEY-NEGO]. If payload
protection using IPsec is enabled for the tunneled traffic, the
* IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP ESP header follows the outer tunnel header.
and ESP headers). Refer to [RFC-3948].
4.1. Local Mobility Anchor Considerations 4.1. Local Mobility Anchor Considerations
4.1.1. Extensions to Binding Cache Entry 4.1.1. Extensions to Binding Cache Entry
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. extended with the following additional parameters. It is to be noted
that all of these parameters are specified in [ID-DSMIP6] and also
required here in the present usage context, and are presented here
only for completeness.
o This is the IPv4 Proxy Care-of Address configured on the mobile o The IPv4 Proxy Care-of Address configured on the mobile access
access gateway that sent the Proxy Binding Update message. This gateway that sent the Proxy Binding Update message. This address
address can be obtained from the IPv4 Care-of Address option [ID- can be obtained from the IPv4 Care-of Address option [ID-DSMIP6],
DSMIP6], present in the received Proxy Binding Update message. present in the received Proxy Binding Update message. However, if
However, if the received Proxy Binding Update message is not sent the received Proxy Binding Update message is not sent as an IPv4
as an IPv4 packet, i.e., when using IPv6 transport, this field packet, i.e., when using IPv6 transport, this field in the Binding
MUST be set to ALL_ZERO value. Cache entry MUST be set to ALL_ZERO value.
o The IPv4 NAT translated address of the mobile access gateway. If o The IPv4 NAT translated address of the mobile access gateway. If
the mobile access gateway is not behind a NAT [RFC-3022], this the mobile access gateway is not behind a NAT [RFC-3022], this
address will be the same as the address configured on the egress address will be the same as the address configured on the egress
interface of the mobile access gateway. This address can be interface of the mobile access gateway. This address can be
obtained from the IPv4 header of the received Proxy Binding Update obtained from the IPv4 header of the received Proxy Binding Update
message. However, if the received Proxy Binding Update message is message. However, if the received Proxy Binding Update message is
not sent as an IPv4 packet, this field MUST be set to ALL_ZERO not sent as an IPv4 packet, this field in the Binding Cache entry
value. 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).
skipping to change at page 35, line 4 skipping to change at page 36, line 17
removing the outer encapsulation (IPv4 or IPv4-UDP) header. removing the outer encapsulation (IPv4 or IPv4-UDP) header.
o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in
the request and if the outer encapsulation header is IPv4-UDP, the request and if the outer encapsulation header is IPv4-UDP,
then the NAT presence detection procedure specified in Section then the NAT presence detection procedure specified in Section
4.1.3.3 MUST be used for detecting the NAT in the path. 4.1.3.3 MUST be used for detecting the NAT in the path.
o Upon accepting the request, the local mobility anchor MUST set up o Upon accepting the request, the local mobility anchor MUST set up
an IPv4 bi-directional tunnel to the mobile access gateway. The an IPv4 bi-directional tunnel to the mobile access gateway. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
The encapsulation mode MUST be determined from the below The encapsulation mode MUST be determined from the below
considerations. considerations.
* If the received Proxy Binding Update message was sent with IPv4 * If the received Proxy Binding Update message was sent with IPv4
encapsulated header, then the encapsulation mode for the bi- encapsulated header, then the encapsulation mode for the bi-
directional tunnel MUST be set to IPv4. Otherwise, the directional tunnel MUST be set to IPv4. Otherwise, the
following considerations apply. following considerations apply.
* If NAT is detected on the path, or if the (F) flag in the
received Proxy Binding Update message is set to the value of 1,
then the encapsulation mode MUST be set to IPv4-UDP. Otherwise
the encapsulation mode MUST be set to IPv4.
* If NAT is not detected on the path and if the (F) flag in the * If NAT is not detected on the path and if the (F) flag in the
received Proxy Binding Update message is set to the value of 1, received Proxy Binding Update message is set to the value of 1,
but if the configuration flag, but if the configuration flag,
AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
0, then the local mobility anchor MUST reject the request with 0, then the local mobility anchor MUST reject the request with
the Status field value set to 129 (Administratively the Status field value set to 129 (Administratively
prohibited). prohibited).
* If the (T) flag [ID-DSMIP6] in the Proxy Binding Update message * If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update
is set to value of 1, then the encapsulation mode MUST be set message is set to value of 1, then the encapsulation mode MUST
to IPv4-UDP-TLV. be set to IPv4-or-IPv6-over-IPv4-UDP-TLV.
* If NAT is detected on the path, or if the (F) flag in the
received Proxy Binding Update message is set to the value of 1,
then the encapsulation mode MUST be set to IPv4-or-IPv6-over-
IPv4-UDP. Otherwise the encapsulation mode MUST be set to
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
skipping to change at page 40, line 22 skipping to change at page 41, line 40
CoA of the mobile access gateway and the destination address MUST CoA of the mobile access gateway and the destination address MUST
be set to the local mobility anchor's IPv4-LMAA. be set to the local mobility anchor's IPv4-LMAA.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The
address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. address MUST be set to the mobile access gateway's IPv4-Proxy-CoA.
o If the configuration variable ForceIPv4UDPEncapsulationSupport is o If the configuration variable ForceIPv4UDPEncapsulationSupport is
set to value of 1, then the (F) flag in the Proxy Binding Update set to value of 1, then the (F) flag in the Proxy Binding Update
message MUST be set to value of 1. message MUST be set to value of 1.
o If the mobile access gateway and the local mobility anchor are o The Proxy Binding Update message MUST be protected using IPsec ESP
using globally routable IPv4 addresses and if there is a security [RFC-4301], as specified in [RFC-5213]. The protection MUST be
associated that is based of IPv4 addresses, then the encapsulated applied on the IPv6 packet of the Proxy Binding Update message,
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement prior to the IPv4 encapsulation.
message) MUST be protected using IPsec ESP [RFC-4301] mode and
additionally there is no need to apply ESP header on the IPv6
packet. In all other cases, the Proxy Binding Update message MUST
be protected 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 The format of the Proxy Binding Update message encapsulated in an
IPv4 or IPv4-UDP packet with no IPsec protection: IPv4 or IPv4-UDP packet with no IPsec protection:
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/
/* IPv6 PBU Packet protected with ESP header */ /* IPv6 PBU Packet protected with ESP header */
Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4 Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4
UDP header UDP header
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
skipping to change at page 44, line 10 skipping to change at page 45, line 10
for IPv4 UDP encapsulation support. for IPv4 UDP encapsulation support.
This flag is applicable only when the flag This flag is applicable only when the flag
UseIPv4UDPEncapForSignalingMessages is set to a value of 1. UseIPv4UDPEncapForSignalingMessages is set to a value of 1.
6. IANA Considerations 6. IANA Considerations
This document defines a new Mobility Header option, IPv4 Default This document defines a new Mobility Header option, IPv4 Default
Router Address option. This option is described in Section 3.3.1. Router Address option. This option is described in Section 3.3.1.
The Type value for this option needs to be assigned from the same The Type value for this option needs to be assigned from the same
numbering space as allocated for the other mobility options, as number space as allocated for the other mobility options, as defined
defined in [RFC-3775]. in [RFC-3775].
This document also defines new Binding Acknowledgement status values, This document also defines new status values, used in Proxy Binding
as described in Section 3.3.2. The status values MUST be assigned Acknowledgement message, as described in Section 3.3.2. These values
from the same number space used for Binding Acknowledgement status MUST be assigned from the same number space as allocated for other
values, as defined in [RFC-3775]. The allocated values for each of Status codes [RFC-3775]. Each of these allocated values MUST be
these status values must be greater than 128. greater than 128.
7. Security Considerations 7. Security Considerations
All the security considerations from the base Proxy Mobile IPv6 All the security considerations from the base Proxy Mobile IPv6 [RFC-
protocol [RFC-5213] apply when using the extensions defined in this 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [ID-DSMIP6]
document. Additionally, the following security considerations need apply when using the extensions defined in this document.
to be applied. Additionally, the following security considerations need to be
applied.
This document defines news mobility options for supporting the IPv4 This document defines news mobility options for supporting the IPv4
Home Address assignment and IPv4 Transport Support features. It also Home Address assignment and IPv4 Transport Support features. These
uses some of the mobility options from DSMIPv6 specification [ID- options are to be carried in Proxy Binding Update and Proxy Binding
DSMIP6]. These options are to be carried in Proxy Binding Update and Acknowledgement messages. The required security mechanisms specified
Proxy Binding Acknowledgement messages. The required security in the base Proxy Mobile IPv6 protocol for protecting these signaling
mechanisms specified in the base Proxy Mobile IPv6 protocol for messages are sufficient when carrying these mobility options.
protecting these signaling messages are sufficient when carrying
these mobility options.
This specification describes the use of IPv4 transport for exchanging This specification describes the use of IPv4 transport for exchanging
the signaling messages between the local mobility anchor and the the signaling messages between the local mobility anchor and the
mobile access gateway. These signaling messages are fundamentally mobile access gateway. These signaling messages are fundamentally
IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4
packets. The encapsulated inner IPv6 message is still protected packets. The encapsulated inner IPv6 message is still protected
using IPsec, using the established security association and this using IPsec, using the established security association and this
offers the same level of security as when the messages are routed offers the same level of security as when the messages are routed
natively as IPv6 packets. The use of outer IPv4 header does not natively as IPv6 packets. The use of outer IPv4 header does not
introduce any new security vulnerabilities. introduce any new security vulnerabilities.
skipping to change at page 46, line 37 skipping to change at page 47, line 37
myungki.shin@gmail.com myungki.shin@gmail.com
9. Acknowledgments 9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like
to thank all the authors of the document and acknowledge that initial to thank all the authors of the document and acknowledge that initial
work. work.
Thanks to Alper Yegin, Behcet Sarikaya, Charles Perkins, Damic Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles
Damjan, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen,
Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati, Vidya Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj,
Narayanan, Yingzhe Wu and Zu Qiang for their helpful review of this Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu and Zu Qiang
document. for their helpful review of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
skipping to change at page 47, line 22 skipping to change at page 48, line 22
Addresses", RFC-4193, October 2005. Addresses", RFC-4193, October 2005.
[RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC-4291, February 2006. Architecture", RFC-4291, February 2006.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
November 2007. November 2007.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-07.txt, December 2008. draft-ietf-mext-nemo-v4traversal-09.txt, February 2009.
[ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K.,
"GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-06.txt, February 2009.
10.2. Informative References 10.2. Informative References
[RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992. (IPCP)", RFC 1332, May 1992.
[RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. 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 [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January
2001. 2001.
[RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP
reconfigure extension", RFC 3203, December 2001.
[RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003. Unicast Address Format", RFC 3587, August 2003.
[RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link-
Local Addresses", RFC 3927, May 2005.
[RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP [RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP
Packets", RFC 3948, January 2005. Packets", RFC 3948, January 2005.
[RFC-4301] Kent, S. and K. Seo, "Security Architecture for the [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
 End of changes. 65 change blocks. 
198 lines changed or deleted 239 lines changed or added

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