draft-ietf-netlmm-pmip6-ipv4-support-16.txt   draft-ietf-netlmm-pmip6-ipv4-support-17.txt 
NETLMM Working Group R. Wakikawa NETLMM Working Group R. Wakikawa
Internet-Draft Toyota ITC Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli Intended status: Standards Track S. Gundavelli
Expires: March 14, 2010 Cisco Expires: March 16, 2010 Cisco
September 10, 2009 September 12, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-16.txt draft-ietf-netlmm-pmip6-ipv4-support-17.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 14, 2010. This Internet-Draft will expire on March 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 38 skipping to change at page 2, line 38
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 18 3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 18
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18
3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19
3.2.4. Routing Considerations for the Mobile Access 3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 25
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26
3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 29
3.4.1. DHCP Server co-located with the Mobile Access 3.4.1. DHCP Server co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 30 Gateway . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2. DHCP Relay Agent co-located with the Mobile Access 3.4.2. DHCP Relay Agent co-located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 32 Gateway . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 43 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 43
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 44 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 44
4.2.1. Extensions to Binding Update List Entry . . . . . . . 44 4.2.1. Extensions to Binding Update List Entry . . . . . . . 44
skipping to change at page 5, line 43 skipping to change at page 5, line 43
mobility entities in the Proxy Mobile IPv6 domain for supporting the mobility entities in the Proxy Mobile IPv6 domain for supporting the
extensions defined in this document. extensions defined in this document.
o Both the mobility entities, the local mobility anchor and the o Both the mobility entities, the local mobility anchor and the
mobile access gateway are dual stack (IPv4/IPv6) enabled. mobile access gateway are dual stack (IPv4/IPv6) enabled.
Irrespective of the type of transport network (IPv4 or IPv6) Irrespective of the type of transport network (IPv4 or IPv6)
separating these two entities, the mobility signaling is always separating these two entities, the mobility signaling is always
based on Proxy Mobile IPv6 [RFC-5213]. based on Proxy Mobile IPv6 [RFC-5213].
o The local mobility anchor and the mobile access gateway MUST be o The local mobility anchor and the mobile access gateway MUST be
configured with IPv6 globally unique addresses, even when they are configured with IPv6 globally unique addresses. Or, they must be
in IPv4-only network. These addresses can be of the type Unique at least unique within that Proxy Mobile IPv6 domain. These
Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address addresses can be of the type, Unique Local IPv6 Unicast Address
[RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using [RFC-4193], IPv6 Global Unicast Address [RFC-3587], or IPv4-mapped
IPv4 transport, it is not required that there is IPv6 routing IPv6 address [RFC-4291]. When using IPv4 transport, it is not
enabled between the local mobility anchor and the mobile access required that there is IPv6 routing enabled between the local
gateway. However, they must be able to receive any IPv6 packets mobility anchor and the mobile access gateway. However, they must
sent to the configured IPv6 addresses, after removing the outer be able to receive any IPv6 packets sent to the configured IPv6
IPv4 encapsulation header. addresses, after removing the outer IPv4 encapsulation header.
o The mobile node can be operating in IPv4-only, IPv6-only or in o The mobile node can be operating in IPv4-only, IPv6-only or in
dual mode. Based on what is enabled for a mobile node, it should dual mode. Based on what is enabled for a mobile node, it should
be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6
address(es) for its interface and furthermore achieve mobility address(es) for its interface and furthermore achieve mobility
support for those addresses. support for those addresses.
o For enabling IPv4 home address mobility support to a mobile node, o For enabling IPv4 home address mobility support to a mobile node,
it is not required that the IPv6 home address mobility support it is not required that the IPv6 home address mobility support
needs to enabled. However, the respective protocol(s) support, needs to enabled. However, the respective protocol(s) support,
such as IPv4 or IPv6 packet forwarding, must be enabled on the such as IPv4 or IPv6 packet forwarding, must be enabled on the
access link between the mobile node and the mobile access gateway. access link between the mobile node and the mobile access gateway.
o The mobile node can obtain an IPv4 address for its attached o The mobile node can obtain an IPv4 address for its attached
interface. Based on the type of link, it may be able to acquire interface. Based on the type of link, it may be able to acquire
its IPv4 address configuration using standard IPv4 address its IPv4 address configuration using standard IPv4 address
configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332],
IKEv2 [RFC-4306] or static address configuration. IKEv2 [RFC-4306] or static address configuration. However, the
details on how IPCP or IKEv2 can be used for address delivery is
outside the scope of this document.
o The mobile node's IPv4 home subnet is typically a shared address o The mobile node's IPv4 home subnet is typically a shared address
space. It is not for the exclusive use of any one mobile node. space. It is not for the exclusive use of any one mobile node.
There can be multiple mobile nodes that are assigned IPv4 There can be multiple mobile nodes that are assigned IPv4
addresses from the same subnet. addresses from the same subnet.
o The mobile access gateway is the IPv4 default router for the o The mobile access gateway is the IPv4 default router for the
mobile node on its access link. It will be in the forwarding path mobile node on its access link. It will be in the forwarding path
for the mobile node's data traffic. Additionally, as specified in for the mobile node's data traffic. Additionally, as specified in
section 6.9.3 of [RFC-5213], all the mobile access gateways in the section 6.9.3 of [RFC-5213], all the mobile access gateways in the
skipping to change at page 23, line 26 skipping to change at page 23, line 26
considerations from Section 6.10.3 of [RFC-5213] MUST be applied considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect to local routing. with respect to local routing.
o When forwarding the packet through the bi-directional tunnel, the o When forwarding the packet through the bi-directional tunnel, the
encapsulation considerations specified in section 3.1.3 MUST be encapsulation considerations specified in section 3.1.3 MUST be
applied. However, before forwarding the packet, the mobile access applied. However, before forwarding the packet, the mobile access
gateway MUST ensure the source address in the received packet is gateway MUST ensure the source address in the received packet is
the address allocated for that mobile node and that there is an the address allocated for that mobile node and that there is an
active binding on the local mobility anchor for that mobile node. active binding on the local mobility anchor for that mobile node.
o The mobile access gateway SHOULD use proxy ARP [RFC-925] to reply o The mobile access gateway SHOULD use Proxy ARP [RFC-925] to reply
to ARP Requests that it receives from the mobile node seeking to ARP Requests that it receives from the mobile node seeking
address resolutions for the destinations on the mobile node's home address resolutions for the destinations on the mobile node's home
subnet. When receiving an ARP Request, the local mobility anchor subnet. When receiving an ARP Request, the local mobility anchor
SHOULD examine the target IP address of the Request, and if this SHOULD examine the target IP address of the Request, and if this
IP address matches the mobile node's IPv4 home subnet, it SHOULD IP address matches the mobile node's IPv4 home subnet, it SHOULD
transmit a Proxy ARP Reply. However, if the link between the transmit a Proxy ARP Reply. However, on certain types of links,
mobile node and the mobile access gateway is a point-to-point the mobile node does not use ARP for address resolutions, instead
link, then the mobile access gateway is not required to support it forwards all the packets to the mobile access gateway. On such
proxy ARP. The mobile node can be configured to use the point-to- types of links, the mobile access gateway is not required to
point link for sending all IP packets. support Proxy ARP function. At the same time, implementations not
supporting the Proxy ARP function on links where the mobile node
uses ARP for seeking address resolutions for the destinations on
the mobile node's home subnet will result in communication
failure.
3.3. Mobility Options and Status Codes 3.3. Mobility Options and Status Codes
To support the IPv4 home address mobility feature, this specification To support the IPv4 home address mobility feature, this specification
defines the following new options and Status Codes. defines the following new options and Status Codes.
3.3.1. IPv4 Home Address Request Option 3.3.1. IPv4 Home Address Request Option
A new option, IPv4 Home Address Request Option is defined for use A new option, IPv4 Home Address Request Option is defined for use
with the Proxy Binding Update message sent by the mobile access with the Proxy Binding Update message sent by the mobile access
skipping to change at page 28, line 39 skipping to change at page 28, line 44
Mobile node not authorized for IPv4 mobility service. Mobile node not authorized for IPv4 mobility service.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 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_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA
Mobile node not authorized for IPv6 mobility service. Mobile node not authorized for IPv6 mobility service.
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA
Multiple IPv4 home address assignment not supported Multiple IPv4 home address 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.
skipping to change at page 29, line 26 skipping to change at page 29, line 34
the DHCP messages with the mobile node. This address is the the DHCP messages with the mobile node. This address is the
mobile node's default router address provided by the local mobile node's default router address provided by the local
mobility anchor. Optionally, all the DHCP servers co-located with mobility anchor. Optionally, all the DHCP servers co-located with
the mobile access gateways in the Proxy Mobile IPv6 domain can be the mobile access gateways in the Proxy Mobile IPv6 domain can be
configured with a fixed IPv4 address. This fixed address can be configured with a fixed IPv4 address. This fixed address can be
potentially an IPv4 private address [RFC-1918] that can be used potentially an IPv4 private address [RFC-1918] that can be used
for the DHCP protocol communication on any of the access links. for the DHCP protocol communication on any of the access links.
This address will be used as the server identifier in the DHCP This address will be used as the server identifier in the DHCP
messages. messages.
o A DHCP server identifies a DHCP client from the interface o A DHCP server identifies a DHCP interface from the contents of the
identifier, if present, or from the client hardware address DHCP "Client-identifier" option [RFC-2132], if present, or from
(chaddr), as specified in [RFC-2131]. It uses this identity for the client hardware address (chaddr), as specified in [RFC-2131].
identifying the interface for which the address is assigned. A Note that the name "Client-identifier" is a misnomer as it
mobile node in a Proxy Mobile IPv6 domain, can attach to the actually identifies an interface and not the client. The DHCP
network through multiple interfaces and can obtain address server uses this identity to identify the interface for which the
configuration for each of its interfaces. Additionally, it may address is assigned. A mobile node in a Proxy Mobile IPv6 domain,
perform handoffs between its interfaces. Following are the can attach to the network through multiple interfaces and can
related considerations with respect to the identification obtain address configuration for each of its interfaces.
presented to the DHCP server. Additionally, it may perform handoffs between its interfaces.
Following are the related considerations with respect to the
identification presented to the DHCP server. <
* If the mobile node attaches to the Proxy Mobile IPv6 domain * If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple interfaces, the DHCP server will uniquely through multiple physical interfaces, the DHCP server will
identify each of those interfaces and will perform address uniquely identify each of those interfaces and will perform
assignment. The DHCP server will identify the interface as address assignment. The DHCP server will identify the
specified in [RFC-2131]. If the interface identifier is interface as specified in RFC 2131. The mobile node SHOULD
present, that will be used for identifying the mobile node generate and use the "Client-identifier" for each physical
interface, otherwise the client hardware address will be used. interface according to [RFC-4361]. Any time the mobile node
Anytime the mobile node performs an handoff to a different performs an handoff of a physical interface to a different
mobile access gateway, using the same interface, the DHCP mobile access gateway, using the same interface, the DHCP
server will always be able to identify the binding using the server will always be able to identify the binding using the
presented identifier, the interface identifier or the hardware presented identifier. The presented identifier (either the
address. The interface identifier or the hardware address will "Client-identifier" or the hardware address) will remain as the
remain as the primary key for each binding, just as how they primary key for each binding, just as how they are unique in a
are unique in a Binding Cache entry. Binding Cache entry.
* However, if the mobile node is capable of performing handoff * If the mobile node is capable of performing handoff between
between interfaces, as per [RFC-5213], the interface identifier interfaces, as per [RFC-5213], a "Client-identifier" value MUST
in such scenarios needs to be an identifier that is not tied to be used for the attachment point that is not tied to any of the
any of those interfaces. The identifier must be a stable physical interfaces. The identifier MUST be generated
identifier which remains the same through out the mobile node's according to [RFC-4361], which guarantees that the identifier
attachment in that Proxy Mobile IPv6 domain. This identifier is stable and unique across all "Client-identifier" values in
must remain fixed for a given binding. This identifier in some use in the Proxy Mobile IPv6 domain.
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 32, line 21 skipping to change at page 32, line 46
| : | | : |
* The use of a fixed DHCP server address on all DHCP servers * The use of a fixed DHCP server address on all DHCP servers
Figure 8: Address renewal with the DHCP server Figure 8: Address renewal with the DHCP server
o The use of a stable address, either the IPv4 default router o The use of a stable address, either the IPv4 default router
address of the mobile node, or a fixed IPv4 address common in that address of the mobile node, or a fixed IPv4 address common in that
Proxy Mobile IPv6 domain, as the DHCP server Id will ensure the Proxy Mobile IPv6 domain, as the DHCP server Id will ensure the
DHCPREQUEST message sent by the mobile node for renewing the DHCPREQUEST message sent by the mobile node for renewing the
address will be received by the new mobile access gateway on the address will be received by the new mobile access gateway on the
attached link. The mobile access gateway after completing the attached link.
Proxy Mobile IPv6 signaling and upon acquiring the IPv4 home
address of the mobile node will return the address in the DHCPACK o The mobile access gateway after completing the Proxy Mobile IPv6
message. However, if the mobile access gateway is unable to signaling and upon acquiring the IPv4 home address of the mobile
complete the Proxy Mobile IPv6 signaling or is unable to acquire node will return the address in the DHCPACK message. However, if
the same IPv4 address as requested by the mobile node, it will the mobile access gateway is unable to complete the Proxy Mobile
send a DHCPNACK message [RFC-2131] to the mobile node, as shown in IPv6 signaling or is unable to acquire the same IPv4 address as
Figure 8-1). requested by the mobile node, it will send a DHCPNACK message
[RFC-2131] to the 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 9 shows (e.g., is co-located with the local mobility anchor). Figure 9 shows
the sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
skipping to change at page 35, line 11 skipping to change at page 35, line 27
unicast DHCP messages between the mobile node and the DHCP server. unicast DHCP messages between the mobile node and the DHCP server.
This is because the local mobility anchor will ensure that the This is because the local mobility anchor will ensure that the
DHCP state is consistent with the PMIPv6 binding that exists for DHCP state is consistent with the PMIPv6 binding that exists for
the IPv4 address. the IPv4 address.
o Once the mobile access gateway intercepts the DHCP message from o Once the mobile access gateway intercepts the DHCP message from
the mobile node to the DHCP server, it can verify if the mobile the mobile node to the DHCP server, it can verify if the mobile
node is negotiating the same IPv4 address that the local mobility node is negotiating the same IPv4 address that the local mobility
anchor allocated for that mobile node. If the address in the anchor allocated for that mobile node. If the address in the
DHCPREQUEST message does not match with the IPv4 address allocated DHCPREQUEST message does not match with the IPv4 address allocated
for the mobile node, then the mobile access gateway SHOULD for the mobile node, then the mobile access gateway SHOULD drop
silently drop the DHCP message. the DHCP message and an administrative error message can be
logged.
o Any time the mobile access gateway detects that the mobile node o Any time the mobile access gateway detects that the mobile node
has released its IPv4 address, it can send a Proxy Binding Update has released its IPv4 address, it can send a Proxy Binding Update
to the local mobility anchor and de-register the IPv4 mobility to the local mobility anchor and de-register the IPv4 mobility
session. session.
3.4.3. Common DHCP Considerations 3.4.3. Common DHCP Considerations
The following DHCP related considerations are common to both the The following DHCP related considerations are common to both the
supported configuration modes, specified in Section 3.4.1 and Section supported configuration modes, specified in Section 3.4.1 and Section
skipping to change at page 56, line 37 skipping to change at page 56, line 37
o 130 Incorrect IPv4 home address o 130 Incorrect IPv4 home address
o 131 Invalid IPv4 address o 131 Invalid IPv4 address
o 132 Dynamic IPv4 home address assignment not available o 132 Dynamic IPv4 home address assignment not available
The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this
document, introduces a new number space, IPv4 DHCP Support Mode document, introduces a new number space, IPv4 DHCP Support Mode
Flags. This document reserves the value 0x1 for the (S) flag. Flags. This document reserves the value 0x1 for the (S) flag.
Approval of this flag values are to be made through IANA Expert Approval of this flag values are to be made through IANA Expert
Review. Review. At this point of time there are no thoughts on what the new
flag allocations can be for and hence this document is leaving this
to the discretion of the expert review.
This document also defines new status values, used in Proxy Binding This document also defines new status values, used in Proxy Binding
Acknowledgement message, as described in Section 3.3.5. These values Acknowledgement message, as described in Section 3.3.5. These values
are to be assigned from the same number space as allocated for other 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_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA
Mobile node not authorized for IPv4 mobility service. Mobile node not authorized for IPv4 mobility service.
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 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_MOBILITY_SERVICE: IANA NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA
Mobile node not authorized for IPv6 mobility service. Mobile node not authorized for IPv6 mobility service.
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA
Multiple IPv4 home address assignment not supported Multiple IPv4 home address 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.
skipping to change at page 59, line 44 skipping to change at page 59, line 44
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, Pasi Eronen, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen,
Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe
Wu and Zu Qiang for their helpful review of this document. Wu and Zu Qiang for their helpful review of this document.
Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem
Dodge and Adrian Farrel for their reviews of this document as part of Dodge, Adrian Farrel and Pekka Savola for their reviews of this
the IESG review process. document as part of 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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast
Addresses", RFC-4193, October 2005. Addresses", RFC-4193, October 2005.
[RFC-4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, 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.
[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
skipping to change at page 60, line 43 skipping to change at page 60, line 49
[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.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001. Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January
2001. 2001.
[RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003. Unicast Address Format", RFC 3587, August 2003.
[RFC-4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 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-4361] Lemon, T. and B. Sommerfield, "Node-specific Client
Identifiers for Dynamic Host Configuration Protocol Version Four
(DHCPv4)", RFC 4361, February 2006.
[RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network
Attachment in IPv4", RFC 4436, March 2006. 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.
[ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., [ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K.,
 End of changes. 25 change blocks. 
74 lines changed or deleted 88 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/