draft-ietf-netlmm-pmip6-ipv4-support-10.txt   draft-ietf-netlmm-pmip6-ipv4-support-11.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: September 25, 2009 Cisco Expires: October 10, 2009 Cisco
March 24, 2009 April 08, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-10.txt draft-ietf-netlmm-pmip6-ipv4-support-11.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 September 25, 2009. This Internet-Draft will expire on October 10, 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 19 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 19
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 24 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 24
3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 24 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 24
3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 25 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 25
3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 26 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 26
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . . . . 27 Gateway . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2. DHCP Relay Agent co-located with the Mobile Access 3.4.2. DHCP Relay Agent co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 30 Gateway . . . . . . . . . . . . . . . . . . . . . . . 30
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 33 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 34
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 34 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 34 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 35
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 35 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 36
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 35 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 36
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 38 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 39 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40
4.2.1. Extensions to Binding Update List Entry . . . . . . . 39 4.2.1. Extensions to Binding Update List Entry . . . . . . . 40
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 41
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 43 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44
5.1. Local Mobility Anchor - Configuration Variables . . . . . 43 5.1. Local Mobility Anchor - Configuration Variables . . . . . 44
5.2. Mobile Access Gateway - Configuration Variables . . . . . 43 5.2. Mobile Access Gateway - Configuration Variables . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 10.1. Normative References . . . . . . . . . . . . . . . . . . . 48
10.2. Informative References . . . . . . . . . . . . . . . . . . 48 10.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
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 11, line 51 skipping to change at page 11, line 51
home address mobility support. A mobile node will be able to obtain home address mobility support. A mobile node will be able to obtain
IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its
attached interface. The mobile node's policy profile will determine attached interface. The mobile node's policy profile will determine
if the mobile node is entitled for both the protocol versions or a if the mobile node is entitled for both the protocol versions or a
single protocol version. Based on the policy, only those protocols single protocol version. Based on the policy, only those protocols
will be enabled on the access link. Furthermore, if the mobile node will be enabled on the access link. Furthermore, if the mobile node
after obtaining the address configuration on its interface performs after obtaining the address configuration on its interface performs
an handoff, either by changing its point of attachment over the same an handoff, either by changing its point of attachment over the same
interface or to a different interface, the network will ensure the interface or to a different interface, the network will ensure the
mobile node will be able to use the same IPv4 address configuration mobile node will be able to use the same IPv4 address configuration
after the handoff. after the handoff. If the mobile node is DNAv4 [RFC-4436] capable
and if it performs DNAv4 procedures after a handoff, it would always
detect the same default-router on any of the access links in that
Proxy Mobile IPv6 domain, as the mobile access gateway configures a
fixed link-layer address on all the access links.
Additionally, If the mobile node connects to the Proxy Mobile IPv6 Additionally, If the mobile node connects to the Proxy Mobile IPv6
domain, through multiple interfaces and simultaneously through domain, through multiple interfaces and simultaneously through
different access networks, each of the connected interfaces will different access networks, each of the connected interfaces will
obtain an IPv4 home address from different subnets. In such obtain an IPv4 home address from different subnets. In such
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].
skipping to change at page 18, line 6 skipping to change at page 18, line 10
When applying those considerations, instead of the IPv6 home When applying those considerations, instead of the IPv6 home
network prefix(es), the IPv4 home address from the IPv4 Home network prefix(es), the IPv4 home address from the IPv4 Home
Address option present in the request MUST be used as the search Address option present in the request MUST be used as the search
key. key.
o These rules specified in section 5.4.1.1 of [RFC-5213], assume the 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 presence of one or more IPv6 home network prefixes in the received
request and also in the Binding Cache entry. But, when using the request and also in the Binding Cache entry. But, when using the
IPv4 home address as the search key, these considerations MUST IPv4 home address as the search key, these considerations MUST
always assume just one single IPv4 home address, both in the always assume just one single IPv4 home address, both in the
request and also in the request. request and also in the Binding Cache entry.
3.1.3. Routing Considerations for the Local Mobility Anchor 3.1.3. Routing Considerations for the Local Mobility Anchor
Intercepting Packets Sent to the Mobile Node's IPv4 home address: Intercepting Packets Sent to the Mobile Node's IPv4 home address:
o When the local mobility anchor is serving a mobile node, it MUST o When the local mobility anchor is serving a mobile node, it MUST
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 27, line 17 skipping to change at page 27, line 17
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
private address [RFC-1918] that can be used for the DHCP protocol private address [RFC-1918] that can be used for the DHCP protocol
communication on any of the access links. This address will be communication on any of the access links. This address 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 A DHCP server identifies the DHCP client and its interface for
identifier or the client hardware address (chaddr) [RFC-2131]. A which the address is assigned from the client identifier and the
mobile node in a Proxy Mobile IPv6 domain may present any of these client hardware address (chaddr) [RFC-2131] fields respectively.
identifiers to the DHCP server as long as the identifier remains A mobile node in a Proxy Mobile IPv6 domain, can attach to the
the same through out the mobile node's attachment in that Proxy network through multiple interfaces and additionally may perform
Mobile IPv6 domain. If the client hardware address is used as the handoffs between its interfaces. Following are the related
identifier and if the mobile node performs an handoff between two considerations:
interfaces, this hardware identifier will change and the DHCP
server will not be able to identify the mobile node. Thus, it is * If the mobile node attaches to the Proxy Mobile IPv6 domain
recommended that the DHCP client on the mobile node, which through multiple interfaces, the DHCP server will uniquely
performs mobility session handoff across interfaces in a Proxy identify each of those interfaces from the client hardware
Mobile IPv6 domain, is configured to use a stable client address and will perform address assignment. As the mobile
identifier that does not change during the active life of its DHCP node changes its point of attachment in the network and
session. performs an handoff to a different mobile access gateway, using
the same interface, the DHCP server will always be able to
identify the binding using the presented client hardware
address. The client hardware address and client identifier
will remain as the primary keys for each binding, just as how
they are unique in a Binding Cache entry.
* However, if the mobile node is capable of performing handoff
between interfaces, as per [RFC-5213], the client hardware
address in such scenarios needs to be an identifier that is not
tied to any of those interfaces. The identifier must be a
stable identifier which remains the same through out the mobile
node's attachment in that Proxy Mobile IPv6 domain. This
identifier must remain fixed for a given binding. This
identifier in some implementations can be the identifier
associated to a virtual interface, that is abstracting the
physical interfaces.
o All the DHCP servers co-located with the mobile access gateways in o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain can be configured with the same set of a Proxy Mobile IPv6 domain can be configured with the same set of
DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure
the mobile node receives the same configuration values on any of the mobile node receives the same configuration values on any of
the access links in that Proxy Mobile IPv6 domain. the access links in that Proxy Mobile IPv6 domain.
3.4.1. DHCP Server co-located with the Mobile Access Gateway 3.4.1. DHCP Server co-located with the Mobile Access Gateway
This section explains the operational sequence of home address This section explains the operational sequence of home address
skipping to change at page 29, line 26 skipping to change at page 29, line 32
IPv4 Home Address Renewal with a different DHCP server (After IPv4 Home Address Renewal with a different DHCP server (After
Handoff): Handoff):
When the mobile node goes into the DHCP RENEWING state [RFC-2131], it When the mobile node goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node currently provided the DHCP lease. However, if the mobile node
changed its point of attachment and is attached to a new mobile changed its point of attachment and is attached to a new mobile
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. The following approach
approaches can be adopted to ensure the mobile node uses the DHCP can be adopted to ensure the mobile node uses the DHCP server on the
server on the attached link. attached link.
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
| : | | : |
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
skipping to change at page 30, line 42 skipping to change at page 31, line 7
DHCPDISCOVER phase (Step-4) may occur in any order. However, DHCPDISCOVER phase (Step-4) may occur in any order. However,
the DHCPOFFER (Step-5) and the following steps will occur in the DHCPOFFER (Step-5) and the following steps will occur in
the specified order and after the Tunnel/Route Setup (Step-3). the specified order and after the Tunnel/Route Setup (Step-3).
Figure 7: Overview of the DHCP relay located at mobile access gateway Figure 7: Overview of the DHCP relay located at mobile access gateway
Initial IPv4 Home Address Assignment: Initial IPv4 Home Address Assignment:
o When the mobile access gateway receives a DHCPDISCOVER message o When the mobile access gateway receives a DHCPDISCOVER message
from a mobile node, it 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. It is to be noted that
the mobile node needs to be identified by the MN-Identifier, as
specified in Section 6.6 of [RFC-5213].
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 mobile access gateway 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.
skipping to change at page 40, line 5 skipping to change at page 41, line 5
4.2.1. Extensions to Binding Update List Entry 4.2.1. Extensions to Binding Update List Entry
To support the IPv4 Transport Support feature, the conceptual Binding To support the IPv4 Transport Support feature, the conceptual Binding
Update List entry data structure maintained by the mobile access Update List entry data structure maintained by the mobile access
gateway [RFC-5213] MUST be extended with the following additional gateway [RFC-5213] MUST be extended with the following additional
parameters. parameters.
o The IPv4 address of the local mobility anchor. This address can o The IPv4 address of the local mobility anchor. This address can
be obtained from the mobile node's policy profile. be obtained from the mobile node's policy profile.
o The IPv4 address of the mobile access gateway. This is the
address configured on the egress interface of the mobile access
gateway and is registered with the mobile node's local mobility
anchor as the IPv4 Proxy-CoA. However, if the mobile access
gateway is in a private IPv4 network and behind a NAT, the address
that is registered with the mobile node's local mobility anchor is
the NAT translated public IPv4 address.
4.2.2. Signaling Considerations 4.2.2. Signaling Considerations
The mobile access gateway when sending a Proxy Binding Update message The mobile access gateway when sending a Proxy Binding Update message
to the local mobility anchor MUST construct the message as specified to the local mobility anchor MUST construct the message as specified
in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access
gateway is in an IPv4-only access network, the following additional gateway is in an IPv4-only access network, the following additional
considerations MUST be applied. considerations MUST be applied.
o The Proxy Binding Update message MUST be encapsulated in an IPv4 o The Proxy Binding Update message MUST be encapsulated in an IPv4
packet. However, if the value of the configuration variable, packet. However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy
Binding Update message MUST be encapsulated in an UDP header of an Binding Update message MUST be encapsulated in an UDP header of an
IPv4 packet. IPv4 packet.
o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The
IPv4 address in the option MUST be set to the mobile access IPv4 address in the option MUST be set to the mobile access
gateway's IPv4-Proxy-CoA. gateway's IPv4-Proxy-CoA.
o The packet MUST be constructed as specified in Section 4.2.3. o The packet MUST be constructed as specified in Section 4.2.3.
o When sending a Proxy Binding message for extending the lifetime of o Just as specified in [RFC-5213], when sending a Proxy Binding
a currently existing mobility session or for de-registering the message for extending the lifetime of a currently existing
mobility session, the Proxy Binding Update message MUST be mobility session or for de-registering the mobility session, the
constructed as the initial request. Proxy Binding Update message MUST be constructed just as the
initial request.
Receiving Proxy Binding Acknowledgement Receiving Proxy Binding Acknowledgement
o If the received Proxy Binding Acknowledgement message is o If the received Proxy Binding Acknowledgement message is
encapsulated in IPv4 or IPv4 UDP packet, the message MUST be encapsulated in IPv4 or IPv4 UDP packet, the message MUST be
authenticated after removing the outer IPv4 or IPv4-UDP header. authenticated after removing the outer IPv4 or IPv4-UDP header.
Considerations from Section 4 of [RFC-5213] MUST be applied for Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the message. authenticating and authorizing the message.
o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be
skipping to change at page 45, line 15 skipping to change at page 46, line 15
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
number space as allocated for the other mobility options, as defined number space as allocated for the other mobility options, as defined
in [RFC-3775]. in [RFC-3775].
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.2. These values Acknowledgement message, as described in Section 3.3.2. These values
MUST 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 MUST be Status codes [RFC-3775]. Each of these allocated values have to be
greater than 128. greater than 128.
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 [ID-DSMIP6] 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [ID-DSMIP6]
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.
skipping to change at page 48, line 22 skipping to change at page 49, 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-09.txt, February 2009. draft-ietf-mext-nemo-v4traversal-10.txt, April 2009.
[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-06.txt, February 2009. 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.
skipping to change at page 49, line 9 skipping to change at page 50, line 9
[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-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network
Attachment in IPv4", RFC 4436, March 2006.
[RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack
Mobility", RFC 4977, August 2007. Mobility", RFC 4977, August 2007.
[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.
Authors' Addresses Authors' Addresses
Ryuji Wakikawa Ryuji Wakikawa
Toyota ITC / Keio University Toyota ITC / Keio University
 End of changes. 24 change blocks. 
67 lines changed or deleted 83 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/