draft-ietf-netlmm-pmip6-ipv4-support-13.txt   draft-ietf-netlmm-pmip6-ipv4-support-14.txt 
NETLMM Working Group R. Wakikawa NETLMM Working Group R. Wakikawa
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: January 1, 2010 Cisco Expires: January 14, 2010 Cisco
June 30, 2009 July 13, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-13.txt draft-ietf-netlmm-pmip6-ipv4-support-14.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 January 1, 2010. This Internet-Draft will expire on January 14, 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 3, line 7 skipping to change at page 2, line 15
Abstract Abstract
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5
1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 7 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 6
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 9 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 11 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 12 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 12 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 18 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 19 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 19 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 19 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 24 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 24 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23
3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 25 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24
3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 26 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 26 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 26
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 27
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 28 Gateway . . . . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . 30 Gateway . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 32 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 34
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 34 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 37
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 38
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 35 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 38
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 36 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 39
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 36 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 39
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 42
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43
4.2.1. Extensions to Binding Update List Entry . . . . . . . 40 4.2.1. Extensions to Binding Update List Entry . . . . . . . 43
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 41 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 44
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 46
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 50
5.1. Local Mobility Anchor - Configuration Variables . . . . . 44 5.1. Local Mobility Anchor - Configuration Variables . . . . . 50
5.2. Mobile Access Gateway - Configuration Variables . . . . . 44 5.2. Mobile Access Gateway - Configuration Variables . . . . . 50
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 55
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Normative References . . . . . . . . . . . . . . . . . . . 49
10.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10.1. Normative References . . . . . . . . . . . . . . . . . . . 56
10.2. Informative References . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
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 46 skipping to change at page 6, line 46
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 to most part leverages 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 options, IPv4 Home Address, IPv4 Address o The messaging option, IPv4 Care-of Address option defined in [RFC-
Acknowledgement, IPv4 Care-of Address option defined in [RFC-5555] 5555] for use in Binding Update and Binding Acknowledgement
for use in Binding Update and Binding Acknowledgement messages are messages are used by this specification to be carried in Proxy
used by this specification to be carried in Proxy Binding Update Binding Update and Proxy Binding Acknowledgement messages.
and Proxy Binding Acknowledgement messages.
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 The NAT traversal logic specified in [RFC-5555] for detecting the
on-path NAT devices is valid for this specification as well. on-path NAT devices is valid for this specification as well.
o The tunneling considerations specified in [RFC-5555] for o The tunneling considerations specified in [RFC-5555] for
skipping to change at page 12, line 37 skipping to change at page 11, line 37
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
Home Address option [RFC-5555], 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 option [RFC-5555] 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 two options, either the IPv4 Home Address option or the Home these two options, either the IPv4 Home Address Request option or
Network Prefix option, MUST be present. If there is not a single the Home Network Prefix option, MUST be present. If there is not
instance of any of these two options present in the request, the a single instance of any of these two options present in the
local mobility anchor MUST reject the request and send a Proxy request, the local mobility anchor MUST reject the request and
Binding Acknowledgement message with Status field set to send a Proxy Binding Acknowledgement message with Status field set
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
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 Request option present in the request, then the local mobility
reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
home address assignment not supported).
o If the prefix request(P) flag in the IPv4 Home Address option
[RFC-5555] is set to a value of (1), then the local mobility
anchor MUST reject the request and send a Proxy Binding anchor MUST reject the request and send a Proxy Binding
Acknowledgement message with the Status field set to Acknowledgement message with the Status field set to
IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4 prefix assignment not MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
supported). home address assignment not supported).
o For associating the received Proxy Binding Update message to an o For associating the received Proxy Binding Update message to an
existing mobility session, the local mobility anchor MUST perform existing mobility session, the local mobility anchor MUST perform
the Binding Cache entry existence test by applying the following the Binding Cache entry existence test by applying the following
considerations. considerations.
* If there is at least one instance of the Home Network Prefix * If there is at least one instance of the Home Network Prefix
option [RFC-5213] with a NON_ZERO prefix value, or, if there is option [RFC-5213] with a NON_ZERO prefix value, or, if there is
an IPv4 Home Address option [RFC-5555] with the IPv4 address in an IPv4 Home Address Request option with the IPv4 address in
the option set to ALL_ZERO, considerations from Section 5.4.1 the option set to ALL_ZERO, considerations from Section 5.4.1
of [RFC-5213] MUST be applied. of [RFC-5213] MUST be applied.
* If there is an IPv4 Home Address option [RFC-5555] present in * If there is an IPv4 Home Address Request option present in the
the request with the IPv4 address value in the option set to a request with the IPv4 address value in the option set to a
NON_ZERO value, considerations from Section 3.1.2.7 MUST be NON_ZERO value, considerations from Section 3.1.2.7 MUST be
applied. applied.
o If there is no existing Binding Cache entry that can be associated o If there is no existing Binding Cache entry that can be associated
with the request, the local mobility anchor MUST consider this with the request, the local mobility anchor MUST consider this
request as an initial binding registration request and request as an initial binding registration request and
considerations from Section 3.1.2.2 MUST be applied. considerations from Section 3.1.2.2 MUST be applied.
Additionally, if there are one or more Home Network Prefix options Additionally, if there are one or more Home Network Prefix options
[RFC-5213] present in the request, considerations from Section [RFC-5213] present in the request, considerations from Section
5.3.2 of [RFC-5213] MUST also be applied. 5.3.2 of [RFC-5213] MUST also be applied.
skipping to change at page 14, line 22 skipping to change at page 13, line 15
considerations from Section 3.1.2.4 MUST be applied. considerations from Section 3.1.2.4 MUST be applied.
o If there exists a Binding Cache entry that can be associated with o If there exists a Binding Cache entry that can be associated with
the request and if it is determined that the request is a re- the request and if it is determined that the request is a re-
registration request for extending IPv4 home address mobility registration request for extending IPv4 home address mobility
support to the existing IPv6-only mobility session, considerations support to the existing IPv6-only mobility session, considerations
from Section 3.1.2.2 MUST be applied with respect to IPv4 support. from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
3.1.2.2. Initial Binding Registration (New Mobility Session) 3.1.2.2. Initial Binding Registration (New Mobility Session)
o If there is an IPv4 Home Address option [RFC-5555] present in the o If there is an IPv4 Home Address Request option present in the
Proxy Binding Update message with the IPv4 address value in the Proxy Binding Update message with the IPv4 address value in the
option set to ALL_ZERO, the local mobility anchor MUST allocate an option set to ALL_ZERO, the local mobility anchor MUST allocate an
IPv4 home address to the mobile node and associate it with the new IPv4 home address to the mobile node and associate it with the new
mobility session created for that mobile node. mobility session created for that mobile node.
o If there is an IPv4 Home Address option [RFC-5555] with the IPv4 o If there is an IPv4 Home Address Request option with the IPv4
address in the option set to a NON_ZERO value, the local mobility address in the option set to a NON_ZERO value, the local mobility
anchor before accepting the request MUST ensure the address is anchor before accepting the request MUST ensure the address is
topologically anchored on the local mobility anchor and topologically anchored on the local mobility anchor and
furthermore the mobile node is authorized to use that address. If furthermore the mobile node is authorized to use that address. If
the mobile node is not authorized for that specific address, the the mobile node is not authorized for that specific address, 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 the Status field set to Binding Acknowledgement message with the Status field set to
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
for the requesting IPv4 address). It MUST also include the IPv4 for the requesting IPv4 address). It MUST also include the IPv4
Address Acknowledgement option [RFC-5555] in the reply with the Home Address Reply option in the reply with the status field value
status field value in the option set to 129 (Administratively in the option set to 129 (Administratively prohibited).
prohibited).
o If the local mobility anchor is unable to allocate an IPv4 address o If the local mobility anchor is unable to allocate an IPv4 address
due to lack of resources, it MUST reject the request and send a due to lack of resources, it MUST reject the request and send a
Proxy Binding Acknowledgement message with Status field set to 130 Proxy Binding Acknowledgement message with Status field set to 130
(Insufficient resources). It MUST also include the IPv4 Address (Insufficient resources). It MUST also include the IPv4 Home
Acknowledgement option [RFC-5555] in the reply with the status Address Reply option in the reply with the status field value in
field value in the option set to 128 (Failure, reason the option set to 128 (Failure, reason unspecified).
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-5555], there should still be only one Binding Cache entry [RFC-5213], there should still be only one Binding Cache entry
that should be created for this mobility session. The created that should be created for this mobility session. The created
Binding Cache entry MUST be used for managing both IPv4 and IPv6 Binding Cache entry MUST be used for managing both IPv4 and IPv6
home address bindings. The fields in the Binding Cache entry MUST home address bindings. The fields in the Binding Cache entry MUST
be updated with the accepted values for that session. be 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
skipping to change at page 15, line 47 skipping to change at page 14, line 38
3.1.2.4. Binding Lifetime Extension (After handoff) 3.1.2.4. Binding Lifetime Extension (After handoff)
o If there is no Home Network Prefix option(s) [RFC-5213] present in o If there is no Home Network Prefix option(s) [RFC-5213] present in
the request, but if the Binding Cache entry associated with this the request, but if the Binding Cache entry associated with this
request has IPv6 home network prefix(es), the local mobility request has IPv6 home network prefix(es), the local mobility
anchor MUST consider this as a request to extend lifetime only for anchor MUST consider this as a request to extend lifetime only for
the IPv4 home address and not for the IPv6 home network the IPv4 home address and not for the IPv6 home network
prefix(es). Hence, the local mobility anchor SHOULD release all prefix(es). Hence, the local mobility anchor SHOULD release all
the IPv6 home network prefix(es) assigned to that mobile node and the IPv6 home network prefix(es) assigned to that mobile node and
for that specific attached interface. Similar considerations for that specific attached interface. Similar considerations
apply for the case where there is no IPv4 Home Address option apply for the case where there is no IPv4 Home Address Request
[RFC-5555] present in the request, but if the Binding Cache entry option present in the request, but if the Binding Cache entry
associated with that request has both IPv4 home address and IPv6 associated with that request has both IPv4 home address and IPv6
home network prefix(es). home network prefix(es).
o The local mobility anchor MUST remove the previously created IPv4 o The local mobility anchor MUST remove the previously created IPv4
host route (or the forwarding state) and the dynamically created host route (or the forwarding state) and the dynamically created
bi-directional tunnel for carrying the IPv4 payload traffic (if bi-directional tunnel for carrying the IPv4 payload traffic (if
there are no other mobile nodes for which the tunnel is being there are no other mobile nodes for which the tunnel is being
used). This will remove the routing state towards the mobile used). This will remove the routing state towards the mobile
access gateway where the mobile node was anchored prior to the access gateway where the mobile node was anchored prior to the
handoff. handoff.
skipping to change at page 16, line 48 skipping to change at page 15, line 40
The local mobility anchor when sending the Proxy Binding The local mobility anchor when sending the Proxy Binding
Acknowledgement message to the mobile access gateway MUST construct Acknowledgement message to the mobile access gateway MUST construct
the message as specified in Section 5.3.6 of [RFC-5213]. the message as specified in Section 5.3.6 of [RFC-5213].
Additionally, the following considerations MUST be applied. Additionally, the following considerations MUST be applied.
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option [RFC- include at least one instance of Home Network Prefix option [RFC-
5213] in the Proxy Binding Acknowledgement message that it sends 5213] in the Proxy Binding Acknowledgement message that it sends
to the mobile access gateway. However, if the received Proxy to the mobile access gateway. However, if the received Proxy
Binding Update message has only the IPv4 Home Address option [RFC- Binding Update message has only the IPv4 Home Address Request
5555] and did not contain the Home Network Prefix option(s), then option and did not contain the Home Network Prefix option(s), then
the local mobility anchor MUST NOT include any Home Network Prefix the local mobility anchor MUST NOT include any Home Network Prefix
option(s) in the reply. However, there MUST be at least one option(s) in the reply. However, there MUST be at least one
instance of either the Home Network Prefix option [RFC-5213] or instance of either the Home Network Prefix option [RFC-5213] or
the IPv4 Address Acknowledgement option [RFC-5555] present in the the IPv4 Home Address Reply option present in the Proxy Binding
Proxy Binding Acknowledgement message. Acknowledgement message.
o The IPv4 Address Acknowledgement option [RFC-5555] MUST be present o The IPv4 Home Address Reply option MUST be present in the Proxy
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 Address Acknowledgement option [RFC- there MUST be an IPv4 Home Address Reply option corresponding
5555] corresponding to the IPv4 Home Address option [RFC-5555] to the IPv4 Home Address Request option present in the request
present in the request and with the IPv4 address value and the and with the IPv4 address value and the prefix length fields
prefix length fields in the option set to the corresponding in the option set to the corresponding values in the request.
values in the request. The status field value in the option The status field value in the option must be set to the
must be set to the specific error code. specific error code.
2. For all other cases, there MUST be an IPv4 Address 2. For all other cases, there MUST be an IPv4 Home Address Reply
Acknowledgement option for carrying the IPv4 home address option for carrying the IPv4 home address assigned for that
assigned for that mobility session and with the value in the mobility session and with the value in the option set to the
option set to the allocated IPv4 address. The prefix length allocated IPv4 address. The prefix length in the option MUST
in the option MUST be set to the prefix length of the be set to the prefix length of the allocated address. The
allocated address. The status field value in the option must status field value in the option must be set to 0 (Success).
be set to 0 (Success).
o The IPv4 Default-Router Address option MUST be present, if the o The IPv4 Default-Router Address option MUST be present, if the
Status field value in the Proxy Binding Acknowledgement message is Status field value in the Proxy Binding Acknowledgement message is
set to 0 (Proxy Binding Update Accepted). Otherwise, the option set to 0 (Proxy Binding Update Accepted). Otherwise, the option
MUST NOT be present. If the option is present, the default router MUST NOT be present. If the option is present, the default router
address in the option MUST be set to the mobile node's default address in the option MUST be set to the mobile node's default
router address. router address.
3.1.2.7. Binding Cache Entry Lookup Considerations 3.1.2.7. Binding Cache Entry Lookup Considerations
skipping to change at page 20, line 18 skipping to change at page 19, line 11
access gateway on the access link MUST determine if IPv4 home address access gateway on the access link MUST determine if IPv4 home address
mobility support needs to be enabled for that mobile node. The mobility support needs to be enabled for that mobile node. The
mobile node's policy profile identifies the supported modes (IPv4- mobile node's policy profile identifies the supported modes (IPv4-
only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the
mobile service needs to be enabled. Based on those policy mobile service needs to be enabled. Based on those policy
considerations and from other triggers such as from the network, if considerations and from other triggers such as from the network, if
it is determined that IPv4 home address mobility support needs to be it is determined that IPv4 home address mobility support needs to be
enabled for the mobile node, considerations from section 6.9.1.1 of enabled for the mobile node, considerations from section 6.9.1.1 of
[RFC-5213] MUST be applied with the following exceptions. [RFC-5213] MUST be applied with the following exceptions.
o The IPv4 Home Address option [RFC-5555] MUST be present in the o The IPv4 Home Address Request option MUST be present in the Proxy
Proxy Binding Update message. Binding Update message.
* If the mobile access gateway learns the mobile node's IPv4 home * If the mobile access gateway learns the mobile node's IPv4 home
address either from its policy profile, or from other means, address either from its policy profile, or from other means,
the mobile access gateway MAY ask the local mobility anchor to the mobile access gateway MAY ask the local mobility anchor to
allocate that specific address by including exactly one allocate that specific address by including exactly one
instance of the IPv4 Home Address option [RFC-5555] with the instance of the IPv4 Home Address Request option with the IPv4
IPv4 home address and the prefix length fields in the option home address and the prefix length fields in the option set to
set to that specific address and its prefix length. that specific address and its prefix length.
Furthermore, the (P) flag in the option MUST be set to 0.
* 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.
skipping to change at page 21, line 14 skipping to change at page 19, line 51
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_HOME_ADDRESS(The Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
mobile node is not authorized for IPv4 home address), the mobile mobile node is not authorized for IPv4 home address), the mobile
access gateway SHOULD NOT send a Proxy Binding Update message access gateway SHOULD NOT send a Proxy Binding Update message
including the IPv4 Home Address option [RFC-5555] till an including the IPv4 Home Address Request option till an
administrative action is taken. administrative action is taken.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
mobile node is not authorized for the requesting IPv4 home mobile node is not authorized for the requesting IPv4 home
address), the mobile access gateway SHOULD NOT request for the address), the mobile access gateway SHOULD NOT request for the
same address again, but MAY request the local mobility anchor to same address again, but MAY request the local mobility anchor to
do the assignment of address by including exactly one instance of do the assignment of address by including exactly one instance of
IPv4 Home Address option [RFC-5555] with the IPv4 home address and IPv4 Home Address Request option with the IPv4 home address and
the prefix length fields in the option set to ALL_ZERO value. the prefix length fields in the option set to ALL_ZERO value.
o If there is no IPv4 Address Acknowledgement option [RFC-5555] o If there is no IPv4 Home Address Reply option present in the
present in the received Proxy Binding Acknowledgement message, the received Proxy Binding Acknowledgement message, the mobile access
mobile access gateway MUST NOT enable IPv4 support for the mobile gateway MUST NOT enable IPv4 support for the mobile node and the
node and the rest of the considerations from this section can be rest of the considerations from this section can be skipped.
skipped.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value in the IPv4 Address Acknowledgement Option Status field value in the IPv4 Home Address Reply option set to a
[RFC-5555] set to a value that indicates that the request was value that indicates that the request was rejected by the local
rejected by the local mobility anchor, the mobile access gateway mobility anchor, the mobile access gateway MUST NOT enable
MUST NOT enable forwarding for that specific IPv4 home address. forwarding for that specific IPv4 home address.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST update a Binding Update List entry for mobile access gateway MUST update a Binding Update List entry for
that mobile node. The entry MUST be updated with the assigned that mobile node. The entry MUST be updated with the assigned
IPv4 home address 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 [RFC-5555] set to a has the IPv4 Home Address Reply option set to a value that
value that indicates that the request was accepted by the local indicates that the request was accepted by the local mobility
mobility anchor, the mobile access gateway MUST establish a bi- anchor, the mobile access gateway MUST establish a bi-directional
directional tunnel to the local mobility anchor (if there is no tunnel to the local mobility anchor (if there is no existing bi-
existing bi-directional tunnel to that local mobility anchor) and directional tunnel to that local mobility anchor) and with the
with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6
IPv6 packet carried as a payload of an IPv6 packet). packet carried as a payload of an IPv6 packet). Considerations
from Section 5.6.1 of [RFC-5213] MUST be applied for managing the
Considerations from Section 5.6.1 of [RFC-5213] MUST be applied dynamically created bi-directional tunnel. However, when using
for managing the dynamically created bi-directional tunnel. IPv4 transport, the encapsulation mode MUST be set to the
However, when using IPv4 transport, the encapsulation mode MUST be negotiated encapsulation mode, as specified in Section 4 of this
set to the negotiated encapsulation mode, as specified in Section specification.
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 22, line 44 skipping to change at page 21, line 33
3.2.3.3. Binding Re-Registration and De-Registrations 3.2.3.3. Binding Re-Registration and De-Registrations
When sending a Proxy Binding Update either for extending the lifetime When sending a Proxy Binding Update either for extending the lifetime
of a mobility session or for de-registering the mobility session, the of a mobility session or for de-registering the mobility session, the
respective considerations from [RFC-5213] MUST be applied. respective considerations from [RFC-5213] MUST be applied.
Furthermore, the following additional considerations MUST also be Furthermore, the following additional considerations MUST also be
applied. applied.
o If there is an IPv4 home address assigned to the mobility session, o If there is an IPv4 home address assigned to the mobility session,
then there MUST be exactly one instance of the IPv4 Home Address then there MUST be exactly one instance of the IPv4 Home Address
option [RFC-5555] present in the Proxy Binding Update message. Request option present in the Proxy Binding Update message. The
The IPv4 home address and the prefix length fields in the option IPv4 home address and the prefix length fields in the option MUST
MUST be set to that specific address and its corresponding subnet- be set to that specific address and its corresponding subnet-mask
mask length. The (P) flag in the option MUST be set to 0. length.
o If there was no IPv4 home address requested in the initial Proxy o If there was no IPv4 home address requested in the initial Proxy
Binding Update message, but if it is determined that the IPv4 home Binding Update message, but if it is determined that the IPv4 home
address MUST be requested subsequently, then there MUST be exactly address MUST be requested subsequently, then there MUST be exactly
one instance of the IPv4 Home Address option [RFC-5555] 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 of the IPv4 Home Address option [RFC-5555] with the IPv4 instance of the IPv4 Home Address Request option with the IPv4
home address and the prefix length fields in the option set to the home address and the prefix length fields in the option set to the
IPv4 home address that is being de-registered. Similarly for IPv4 home address that is being de-registered. Similarly for
selective de-registration of all the IPv6 home network prefixes, selective de-registration of all the IPv6 home network prefixes,
the Proxy Binding Update message MUST NOT include the IPv4 Home the Proxy Binding Update message MUST NOT include the IPv4 Home
address option, it MUST include a Home Network Prefix option for address option, it MUST include a Home Network Prefix option for
each of the assigned home network prefixes assigned for that each of the assigned home network prefixes assigned for that
mobility session and with the prefix value in the option set to mobility session and with the prefix value in the option set to
that respective prefix value. that respective prefix value.
o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present
skipping to change at page 24, line 7 skipping to change at page 22, line 43
o On receiving a packet from a mobile node connected to its access o On receiving a packet from a mobile node connected to its access
link, the packet MUST be forwarded to the local mobility anchor link, the packet MUST be forwarded to the local mobility anchor
through the bi-directional tunnel established with the local through the bi-directional tunnel established with the local
mobility anchor. The encapsulation considerations specified in mobility anchor. The encapsulation considerations specified in
section 3.1.3 MUST be applied. However, before forwarding the section 3.1.3 MUST be applied. However, before forwarding the
packet, the mobile access gateway MUST ensure the source address packet, the mobile access gateway MUST ensure the source address
in the received packet is the address allocated for that mobile in the received packet is the address allocated for that mobile
node and that there is an active binding on the local mobility node and that there is an active binding on the local mobility
anchor for that mobile node. anchor for that mobile node.
o The mobile access gateway MUST use proxy ARP [RFC-925] to reply to
ARP Requests that it receives from the mobile node seeking address
resolutions for the destinations on the mobile node's home subnet.
When receiving an ARP Request, the local mobility anchor MUST
examine the target IP address of the Request, and if this IP
address matches the mobile node's IPv4 home subnet, it MUST
transmit a Proxy ARP Reply.
3.3. Mobility Options and Status Codes 3.3. Mobility Options and Status Codes
To support the IPv4 home address mobility feature, this specification To support the IPv4 home address mobility feature, this specification
defines the following new options and Status Codes. defines the following new options and Status Codes.
3.3.1. IPv4 Default-Router Address Option 3.3.1. IPv4 Home Address Request Option
A new option, IPv4 Home Address Request Option is defined for use
with the Proxy Binding Update message sent by the mobile access
gateway to the local mobility anchor. This option is used for
requesting IPv4 home address assignment for the mobile node.
The IPv4 Home Address Request option has an alignment requirement of
4n. Its format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Prefix-len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Home Address Request Option
Type
IANA
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST
be set to (6).
Prefix-len
This 6-bit unsigned integer indicating the prefix length of the
IPv4 home address contained in the option.
Reserved
This 10-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the
receiver.
IPv4 home address
This four-byte field containing the IPv4 home address that is
being requested. The value of 0.0.0.0 is used for requesting
the local mobility anchor to perform the address allocation.
3.3.2. IPv4 Home Address Reply Option
A new option, IPv4 Home Address Reply Option is defined for using it
in the Proxy Binding Acknowledgment message sent by the local
mobility anchor to the mobile access gateway. This option can be
used for sending the assigned mobile node's IPv4 home address.
The IPv4 Home Address Reply option has an alignment requirement of
4n. Its format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Home Address Reply Option
Type
IANA
Length
8-bit unsigned integer indicating the length of the option in
octets, excluding the type and length fields. This field MUST
be set to (6).
Status
Indicates success or failure for the IPv4 home address
assignment. Values from 0 to 127 indicate success. Higher
values indicate failure. The following status values are
currently allocated by this document:
0 Success
128 Failure, reason unspecified
129 Administratively prohibited
130 Incorrect IPv4 home address
131 Invalid IPv4 address
132 Dynamic IPv4 home address assignment not available
Prefix-len
This 6-bit unsigned integer is used for carrying the prefix
length of the mobile node's IPv4 home network corresponding the
IPv4 home address contained in the option.
Reserved (Res)
This 2-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the
receiver.
IPv4 home address
This four-byte field is used for carrying the IPv4 home address
assigned to the mobile node.
3.3.3. IPv4 Default-Router Address Option
A new option, IPv4 Default-Router Address Option is defined for using A new option, IPv4 Default-Router Address Option is defined for using
it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the it in the Proxy Binding Acknowledgment message sent by the local
local mobility anchor to the mobile access gateway. This option can mobility anchor to the mobile access gateway. This option can be
be used for sending the mobile node's IPv4 default router address. used for sending the mobile node's IPv4 default router address.
The IPv4 Default-Router Address option has an alignment requirement The IPv4 Default-Router Address option has an alignment requirement
of 4n. Its format is as follows: of 4n. Its format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | | Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default-Router Address | | IPv4 Default-Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Default-Router Address Option 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).
skipping to change at page 25, line 10 skipping to change at page 26, line 36
This 16-bit field is unused for now. The value MUST be This 16-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the initialized to (0) by the sender and MUST be ignored by the
receiver. receiver.
IPv4 Default-Router Address IPv4 Default-Router Address
A four-byte field containing the mobile node's default router A four-byte field containing the mobile node's default router
address. address.
3.3.2. IPv4 DHCP Support Mode 3.3.4. IPv4 DHCP Support Mode
A new option, IPv4 DHCP Support Mode Option is defined for using it A new option, IPv4 DHCP Support Mode Option is defined for using it
in the Proxy Binding Acknowledgment message [RFC-5213] sent by the in the Proxy Binding Acknowledgment message sent by the local
local mobility anchor to the mobile access gateway. This option can mobility anchor to the mobile access gateway. This option can be
be used for notifying the mobile access gateway, if it should used for notifying the mobile access gateway, if it should function
function as a DHCP Server or a DHCP Relay for the attached mobile as a DHCP Server or a DHCP Relay for the attached mobile node.
node.
The IPv4 DHCP Support Mode option has no alignment requirement. Its The IPv4 DHCP Support Mode option has no alignment requirement. Its
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |S| | Type | Length | Reserved (R) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 DHCP Support Mode Option Figure 6: IPv4 DHCP Support Mode 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 2. be set to 2.
skipping to change at page 26, line 4 skipping to change at page 27, line 30
octets, excluding the type and length fields. This field MUST octets, excluding the type and length fields. This field MUST
be set to 2. be set to 2.
Reserved (R) Reserved (R)
This 15-bit field is unused for now. The value MUST be This 15-bit field is unused for now. The value MUST be
initialized to (0) by the sender and MUST be ignored by the initialized to (0) by the sender and MUST be ignored by the
receiver. receiver.
DHCP Support Mode (S) DHCP Support Mode (S)
A 1-bit field that specifies the DHCP support mode. This flag A 1-bit field that specifies the DHCP support mode. This flag
indicates if the mobile access gateway should function as a indicates if the mobile access gateway should function as a
DHCP Server or a DHCP Relay for the attached mobile node. The DHCP Server or a DHCP Relay for the attached mobile node. The
flag value of (0) indicates the mobile access gateway should flag value of (0) indicates the mobile access gateway should
act as a DHCP Relay and the flag value of (1) indicates it act as a DHCP Relay and the flag value of (1) indicates it
should act as a DHCP Server. should act as a DHCP Server.
3.3.3. Status Codes 3.3.5. Status Codes
This document defines the following new Status values for use in the This document defines the following new Status values for use in the
Proxy Binding Acknowledgement message [RFC-5213]. These values are Proxy Binding Acknowledgement message. These values are to be
to be allocated from the same numbering space, as defined in Section allocated from the same numbering space, as defined in Section 6.1.8
6.1.8 of [RFC-3775]. of [RFC-3775].
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address Mobile node not authorized for the requesting IPv4 home address
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network Mobile node not authorized for the requesting IPv6 home network
prefix(es). prefix(es).
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
Multiple IPv4 home address assignment not supported Multiple IPv4 home address assignment not supported
IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED
IPv4 prefix assignment not supported
3.4. Supporting DHCP-Based Address Configuration 3.4. Supporting DHCP-Based Address Configuration
This section explains how DHCP-based address configuration support This section explains how DHCP-based address configuration support
can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It
explains the protocol operation, supported DHCP server deployment explains the protocol operation, supported DHCP server deployment
configurations and the protocol interactions between DHCP agents and configurations and the protocol interactions between DHCP agents and
mobility entities in each of the supported configurations. mobility entities in each of the supported configurations.
This specification supports the following two DHCP deployment This specification supports the following two DHCP deployment
configurations. configurations.
skipping to change at page 28, line 28 skipping to change at page 30, line 14
MN MAG(DHCP-S) LMA MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER |------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update | |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| 4. Tunnel/Route Setup | |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA) |<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA) |------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK |<------| | 7. DHCPACK
| | | | | |
* The DHCP address configuration (starting at Step-1) and the Proxy * It is possible the MAG may have already completed the Proxy Mobile
Mobile IPv6 signaling (starting at Step-2) may start in any order. IPv6 signaling with the LMA for requesting both IPv6 home network
However, the DHCPOFFER (Step-5) and the immediate steps following prefix(es) and IPv4 home address assignment prior to step-1. In
it will occur in the specified order and only after the such event, the Proxy Mobile IPv6 signaling steps (step-2 to
Tunnel/Route Setup (Step-4). step-4) above are not relevant.
* It is possible the MAG may have initially completed the Proxy
Mobile IPv6 signaling prior to Step-1, but only for requesting
IPv6 home network prefix(es) and may later request IPv4 home
address assignment after detecting the DHCP triggers from the
mobile node as shown above.
Figure 5: Overview of DHCP Server located at Mobile Access Gateway Figure 7: Overview of DHCP Server located at Mobile Access Gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
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
skipping to change at page 29, line 42 skipping to change at page 31, line 34
can be adopted to ensure the mobile node uses the DHCP server on the can be adopted to ensure the mobile node uses the DHCP server on the
attached link. attached link.
MN oMAG(DHCP-S) nMAG(DHCP-S) MN oMAG(DHCP-S) nMAG(DHCP-S)
| : | | : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : | | : |
* The use of a fixed DHCP server address on all DHCP servers * The use of a fixed DHCP server address on all DHCP servers
Figure 6: Address renewal with the DHCP server Figure 8: Address renewal with the 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 8-1).
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 9 shows
the sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| | 3. Tunnel/Route Setup* | |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | | | | |
* The Proxy Mobile IPv6 signaling (starting at Step-1) and the * The Proxy Mobile IPv6 signaling (starting at Step-1) and the
DHCP address configuration (starting at Step-4) may start in any DHCP address configuration (starting at Step-4) may start in any
order. However, the DHCPOFFER (Step-5) and the immediate steps order. However, the DHCPOFFER (Step-5) and the immediate steps
following it will occur in the specified order and only after the following it will occur in the specified order and only after the
Tunnel/Route Setup (Step-3). Tunnel/Route Setup (Step-3).
* It is possible the MAG may have initially completed the Proxy
Mobile IPv6 signaling with the LMA only for requesting IPv6 home
network prefix(es) and may later request IPv4 home address
assignment after detecting the DHCP triggers from the mobile node
(after Step-4).
Figure 7: Overview of the DHCP relay located at mobile access gateway Figure 9: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
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 mobile access gateway will enable local mobility anchor, the mobile access gateway will enable
skipping to change at page 33, line 14 skipping to change at page 35, line 12
IPv4 address for the mobile node, the mobile access gateway MUST IPv4 address for the mobile node, the mobile access gateway MUST
NOT enable IPv4 home address mobility support for the mobile node NOT enable IPv4 home address mobility support for the mobile node
on that access link. on that access link.
o The trigger for initiating Proxy Mobile IPv6 signaling can also be o The trigger for initiating Proxy Mobile IPv6 signaling can also be
delivered to the mobile access gateway as part of a context delivered to the mobile access gateway as part of a context
transfer from the previous mobile access gateway, or delivered transfer from the previous mobile access gateway, or delivered
from the other network elements in the radio network, the details from the other network elements in the radio network, the details
of which are outside the scope of this document. of which are outside the scope of this document.
o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST
include the Interface MTU option [RFC-2132]. The DHCP servers in
the Proxy Mobile IPv6 domain MUST be configured to include the
Interface MTU option. The MTU value SHOULD reflect the tunnel MTU
for the bi-directional tunnel between the mobile access gateway
and the local mobility anchor.
o When the mobile node performs an handoff from one mobile access o When the mobile node performs an handoff from one mobile access
gateway to another, the mobile access gateway on the new link will gateway to another, the mobile access gateway on the new link will
initiate the Proxy Mobile IPv6 signaling with the local mobility initiate the Proxy Mobile IPv6 signaling with the local mobility
anchor. On completing the Proxy Mobile IPv6 signaling, the mobile anchor. On completing the Proxy Mobile IPv6 signaling, the mobile
access gateway has the proper IPv4 address state that the local access gateway has the proper IPv4 address state that the local
mobility anchor has allocated for the mobile node and which can be mobility anchor has allocated for the mobile node and which can be
used for supporting DHCP based address configuration on that link. used for supporting DHCP based address configuration on that link.
o Any time the mobile node detects a link change event due to o Any time the mobile node detects a link change event due to
handoff, or due to other reasons such as re-establishment of the handoff, or due to other reasons such as re-establishment of the
skipping to change at page 34, line 22 skipping to change at page 37, line 22
gateway are separated by an IPv4 network and are reachable using only gateway are separated by an IPv4 network and are reachable using only
IPv4 addresses. IPv4 addresses.
IPv4-Proxy-CoA IPv4-LMAA IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + | | + - - - - - - + |
+--+ +---+ / \ +---+ +--+ +--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+ +--+ +---+ \ / +---+ +--+
+ - - - - - - + + - - - - - - +
Figure 8: 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.
skipping to change at page 38, line 48 skipping to change at page 41, line 48
o Figure 9 shows the format of the Proxy Binding Acknowledgement o Figure 9 shows the format of the Proxy Binding Acknowledgement
message encapsulated in an IPv4 packet and protected using IPv6 message encapsulated in an IPv4 packet and protected using IPv6
security association. The UDP header MUST be present only if the security association. The UDP header MUST be present only if the
received Proxy Binding Update message was sent encapsulated in an received Proxy Binding Update message was sent encapsulated in an
IPv4-UDP packet. 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*/ UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/
/* IPv6 PBA Packet protected with ESP header */ /* IPv6 PBA Packet protected with ESP header */
Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated Figure 11: Proxy Binding Acknowledgment (PBA) Message encapsulated
in IPv4 header in IPv4 header
4.1.3.3. NAT Presence Detection 4.1.3.3. NAT Presence Detection
When the transport network between the local mobility anchor and the When the transport network between the local mobility anchor and the
mobile access gateway is an IPv4 network and if the received Proxy mobile access gateway is an IPv4 network and if the received Proxy
Binding Update message was sent encapsulated in IPv4 UDP header, the Binding Update message was sent encapsulated in IPv4 UDP header, the
local mobility anchor performs the NAT Presence Detection as local mobility anchor performs the NAT Presence Detection as
specified below. specified below.
skipping to change at page 40, line 13 skipping to change at page 43, line 13
o The format of the tunneled packet is shown below. o The format of the tunneled packet is shown below.
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=DSMIPv6, dst port=Z] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */ [TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA) IPv6 header (src= CN, dst= MN-HOA)
OR OR
IPv4 header (src= CN, dst= IPv4 MN-HoA) IPv4 header (src= CN, dst= IPv4 MN-HoA)
Figure 10: Tunneled IPv4 Packet from LMA to MAG Figure 12: Tunneled IPv4 Packet from LMA to MAG
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.
skipping to change at page 42, line 46 skipping to change at page 45, line 46
applied on the IPv6 packet of the Proxy Binding Update message, applied on the IPv6 packet of the Proxy Binding Update message,
prior to the IPv4 encapsulation. 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 13: 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
shown below. However, considerations from Section 6.10.3 of [RFC- shown below. However, considerations from Section 6.10.3 of [RFC-
skipping to change at page 43, line 24 skipping to change at page 46, line 24
use of EnableMAGLocalRouting flag. use of EnableMAGLocalRouting flag.
IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */
[TLV Header] /* If TLV negotiated */ [TLV Header] /* If TLV negotiated */
/* IPv6 or IPv4 Payload Packet */ /* IPv6 or IPv4 Payload Packet */
IPv6 header (src= CN, dst= MN-HOA) IPv6 header (src= CN, dst= MN-HOA)
OR OR
IPv4 header (src= CN, dst= IPv4 MN-HoA) IPv4 header (src= CN, dst= IPv4 MN-HoA)
Figure 12: Tunneled IPv4 Packet from LMA to MAG Figure 14: Tunneled IPv4 Packet from LMA to MAG
o Forwarding Packets received from the bi-directional tunnel: o Forwarding Packets received from the bi-directional tunnel:
o On receiving a packet from the bi-directional tunnel established o On receiving a packet from the bi-directional tunnel established
with the mobile node's local mobility anchor, the mobile access with the mobile node's local mobility anchor, the mobile access
gateway MUST remove the outer header before forwarding the packet gateway MUST remove the outer header before forwarding the packet
to the mobile node. to the mobile node.
4.3. IPsec Considerations
The following section describes how IPsec is used for protecting the
signaling messages between the local mobility anchor and mobile
access gateway when using IPv4 transport.
The following are the SPD example entries to protect PBU and PBA on
the local mobility anchor and mobile access gateway.
MAG SPD-S:
- IF local_address = Proxy-CoA_1 &
remote_address = LMAA_1 & proto = MH &
local_mh_type = PBU & remote_mh_type = PBAck
Then use SA ESP transport mode
LMA SPD-S:
- IF local_address = LMAA_1 &
remote_address = Proxy-CoA_1 & proto = MH &
local_mh_type = PBAck & remote_mh_type = PBU
Then use SA ESP transport mode
Figure 15 and Figure 16 show how PBU and PBA are sent and processed
at either the local mobility anchor or the mobile access gateway.
IPsec ESP is always applied before PBU and PBA are encapsulated in
the outer IPv4 header.
| PBU on wire : PBU internal processing
\|/ \:/
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) need to
: be passed 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
| 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
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
skipping to change at page 46, line 7 skipping to change at page 52, line 7
When the value for this flag is set to (1), the mobile access When the value for this flag is set to (1), the mobile access
gateway MUST force the mobile node's local mobility anchor for gateway MUST force the mobile node's local mobility anchor for
IPv4 UDP encapsulation support. 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 two new Mobility Header options, IPv4 Default This document defines two new Mobility Header options, IPv4 Home
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 Section 3.3.1 and Section 3.3.2 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].
The IPv4 DHCP Support Mode Option, described in Section 3.3.2 of this The IPv4 Home Address Reply option, described in Section 3.3.2 of
this document, introduces a new number space, IPv4 Home Address Reply
Status Codes. This document currently reserves the following values.
Approval of any new status code values are to be made through IANA
Expert Review.
o 0 Success
o 128 Failure, reason unspecified
o 129 Administratively prohibited
o 130 Incorrect IPv4 home address
o 131 Invalid IPv4 address
o 132 Dynamic IPv4 home address assignment not available
The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this
document, introduces a new number space, IPv4 DHCP Support Mode document, introduces a new number space, IPv4 DHCP Support Mode
Flags. This document reserves the value 0x1 for the (S) flag. Flags. This document reserves the value 0x1 for the (S) flag.
Approval of this flag values are to be made through IANA Expert Approval of this flag values are to be made through IANA Expert
Review. Review.
This document also defines new status values, used in Proxy Binding This document also defines new status values, used in Proxy Binding
Acknowledgement message, as described in Section 3.3.3. These values Acknowledgement message, as described in Section 3.3.5. These values
are to be assigned from the same number space as allocated for other are to be assigned from the same number space as allocated for other
Status codes [RFC-3775]. Each of these allocated values have to be Status codes [RFC-3775]. Each of these allocated values have to be
greater than 128. greater than 128.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA
Mobile node not authorized for the requesting IPv4 home address Mobile node not authorized for the requesting IPv4 home address
NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network Mobile node not authorized for the requesting IPv6 home network
prefix(es). prefix(es).
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
Multiple IPv4 home address assignment not supported Multiple IPv4 home address assignment not supported
IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED
IPv4 prefix assignment not supported
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 [RFC-
5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555] 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555]
apply when using the extensions defined in this document. 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
skipping to change at page 48, line 39 skipping to change at page 55, line 39
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, 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, Premec Domagoj, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen,
Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu and Zu Qiang Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe
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 and Adrian Farrel for their reviews of this document as part of Dodge and Adrian Farrel for their reviews of this document as part of
the IESG review process. the IESG review process.
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
skipping to change at page 49, line 30 skipping to change at page 56, line 30
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.
[RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. Hosts and Routers (DSMIPv6)", RFC-5555, June 2009.
10.2. Informative References 10.2. Informative References
[RFC-925] Postel, J., "Multi-LAN Address Resolution", RFC 925,
October 1984.
[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., [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996. 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.
skipping to change at page 50, line 25 skipping to change at page 57, line 28
[RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp,
"DHCP Server Identifier Override Suboption", RFC 5107, February 2008. "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
[ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., [ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K.,
"GRE Key Option for Proxy Mobile IPv6", "GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-09.txt, May 2009. draft-ietf-netlmm-grekey-option-09.txt, May 2009.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University TOYOTA InfoTechnology Center, U.S.A., Inc.
6-6-20 Akasaka, Minato-ku 465 Bernardo Avenue
Tokyo 107-0052 Mountain View, CA 94043
Japan USA
Phone: +81-3-5561-8276 Email: ryuji@us.toyota-itc.com
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Sri Gundavelli Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
 End of changes. 82 change blocks. 
196 lines changed or deleted 439 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/