draft-ietf-netlmm-pmip6-ipv4-support-15.txt   draft-ietf-netlmm-pmip6-ipv4-support-16.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: February 24, 2010 Cisco Expires: March 14, 2010 Cisco
August 23, 2009 September 10, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-15.txt draft-ietf-netlmm-pmip6-ipv4-support-16.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 February 24, 2010. This Internet-Draft will expire on March 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 2, line 29 skipping to change at page 2, line 29
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11
3.1.3. Routing Considerations for the Local Mobility 3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . 24
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26
3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 26 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 27 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 34 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 37 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 38 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 38 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 39 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 39 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 42 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 43
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 44
4.2.1. Extensions to Binding Update List Entry . . . . . . . 43 4.2.1. Extensions to Binding Update List Entry . . . . . . . 44
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 44 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 45
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 46 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 47
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 46 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 47
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 50 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 51
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 53 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 54
5.1. Local Mobility Anchor - Configuration Variables . . . . . 53 5.1. Local Mobility Anchor - Configuration Variables . . . . . 54
5.2. Mobile Access Gateway - Configuration Variables . . . . . 53 5.2. Mobile Access Gateway - Configuration Variables . . . . . 54
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 58
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 58 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 59
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . . 60
10.2. Informative References . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
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 5, line 8 skipping to change at page 5, line 8
deployments may choose to enable any one or both of these features as deployments may choose to enable any one or both of these features as
required. required.
Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport
network and with IPv4 enabled mobile nodes. The terms used in this network and with IPv4 enabled mobile nodes. The terms used in this
illustration are explained in the Terminology section. illustration are explained in the Terminology section.
+----+ +----+ +----+ +----+
|LMA1| |LMA2| |LMA1| |LMA2|
+----+ +----+ +----+ +----+
IPv4-LMAA -> | | <-- LMAA IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA
| | | |
\\ //\\ \\ //\\
(NAT) // \\ (NAT) // \\
\\ // \\ \\ // \\
+---\\------------- //------\\----+ +---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ ) ( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ ) ( \\ Network // \\ )
+------\\--------//------------\\-+ +------\\--------//------------\\-+
\\ // \\ \\ // \\
\\ // \\ \\ // \\
skipping to change at page 8, line 43 skipping to change at page 8, line 43
The IPv4 address that is configured on the egress-interface of the The IPv4 address that is configured on the egress-interface of the
local mobility anchor. When using IPv4 transport, the mobile local mobility anchor. When using IPv4 transport, the mobile
access gateway sends the Proxy Binding Update messages to this access gateway sends the Proxy Binding Update messages to this
address and will be the transport-endpoint of the tunnel between address and will be the transport-endpoint of the tunnel between
the local mobility anchor and the mobile access gateway. the local mobility anchor and the mobile access gateway.
Mobile Node's IPv4 Home Address (IPv4-MN-HoA) Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
The IPv4 home address assigned to the mobile node's attached The IPv4 home address assigned to the mobile node's attached
interface. This address is topologically anchored at the local interface. This address is topologically anchored at the mobile
mobility anchor. The mobile node configures this address on its node's local mobility anchor. The mobile node configures this
attached interface. If the mobile node connects to the Proxy address on its attached interface. If the mobile node connects to
Mobile IPv6 domain via multiple interfaces each of the interfaces the Proxy Mobile IPv6 domain via multiple interfaces each of the
are assigned a unique IPv4 address. All the IPv6 home network interfaces are assigned a unique IPv4 address. All the IPv6 home
prefixes and the IPv4 home address assigned to a given interface network prefixes and the IPv4 home address assigned to a given
of a mobile node will be managed under one mobility session. interface of a mobile node will be managed under one mobility
session.
Selective De-registration Selective De-registration
A procedure for partial de-registration of all the addresses that A procedure for partial de-registration of all the addresses that
belong to one address family, i.e., de-registration of either IPv4 belong to one address family, i.e., de-registration of either IPv4
home address, or all of the IPv6 home network prefixes. home address, or all of the IPv6 home network prefixes.
Encapsulation Modes Encapsulation Modes
This document uses the following terms when referring to the This document uses the following terms when referring to the
different encapsulation modes. different encapsulation modes.
IPv4-or-IPv6-over-IPv6 IPv4-or-IPv6-over-IPv6
skipping to change at page 10, line 9 skipping to change at page 10, line 9
IPv4-or-IPv6-over-IPv4-UDP-TLV IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4 packet carried as a payload in an IPv4 packet with UDP and IPv4 packet carried as a payload in an IPv4 packet with UDP and
TLV headers TLV headers
3. IPv4 Home Address Mobility Support 3. IPv4 Home Address Mobility Support
The IPv4 home address mobility support essentially enables a mobile The IPv4 home address mobility support essentially enables a mobile
node in a Proxy Mobile IPv6 domain to obtain IPv4 home address node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
configuration for its attached interface and be able to retain that configuration for its attached interfaces and be able to retain that
address configuration even after changing its point of attachment in address configuration even after performing an handoff anywhere
that Proxy Mobile IPv6 domain. This section describes the protocol within that Proxy Mobile IPv6 domain. This section describes the
operation and the required extensions to Proxy Mobile IPv6 protocol protocol operation and the required extensions to Proxy Mobile IPv6
for extending IPv4 home address mobility support. protocol for extending IPv4 home address mobility support.
When an IPv4-enabled or a dual-stack enabled mobile node attaches to When an IPv4-enabled or a dual-stack enabled mobile node attaches to
the Proxy Mobile IPv6 domain, the mobile access gateway on the access the Proxy Mobile IPv6 domain, the mobile access gateway on the access
link where the mobile node is attached will identify the mobile node link where the mobile node is attached will identify the mobile node
and will initiate the Proxy Mobile IPv6 signaling with the mobile and will initiate the Proxy Mobile IPv6 signaling with the mobile
node's local mobility anchor. The mobile access gateway will follow node's local mobility anchor. The mobile access gateway will follow
the signaling considerations specified in Section 3.2 for requesting the signaling considerations specified in Section 3.2 for requesting
IPv4 home address mobility support. Upon the completion of the IPv4 home address mobility support. Upon the completion of the
signaling, the local mobility anchor and the mobile access gateway signaling, the local mobility anchor and the mobile access gateway
will establish the required routing states for allowing the mobile will establish the required routing states for allowing the mobile
skipping to change at page 12, line 13 skipping to change at page 12, line 13
to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213]. network prefix option) [RFC-5213].
o If there is at least one instance of Home Network Prefix option o If there is at least one instance of Home Network Prefix option
[RFC-5213] present in the received Proxy Binding Update message, [RFC-5213] present in the received Proxy Binding Update message,
but either if it is known from the mobile node's policy profile but either if it is known from the mobile node's policy profile
that the mobile node is not authorized for IPv6 service or if IPv6 that the mobile node is not authorized for IPv6 service or if IPv6
routing not enabled in the home network, the local mobility anchor routing not enabled in the home network, the local mobility anchor
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_MOBILITY_SERVICE (mobile node not
authorized for the requesting IPv6 home network prefix). authorized for IPv6 mobility service).
o If there is an IPv4 Home Address Request option present in the
received Proxy Binding Update message, but either if it is known
from the mobile node's policy profile that the mobile node is not
authorized for IPv4 service or if IPv4 routing not enabled in the
home network, the local mobility anchor MUST reject the request
and send a Proxy Binding Acknowledgement message with the Status
field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node
not authorized for IPv4 mobility service).
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
Request option present in the request, then the local mobility Request option present in the request, 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
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4
home address assignment not 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
skipping to change at page 13, line 5 skipping to change at page 13, line 15
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.
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, the local mobility anchor MUST apply considerations the request, the local mobility anchor MUST apply considerations
from Section 5.3.1 of [RFC-5213], (point 13), to determine if the from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
request is re-registration or a de-registration request. If the request is re-registration or a de-registration request. If the
request is a re-registration request, considerations from Section request is a re-registration request, considerations from Section
3.1.2.3 MUST be applied and if it is a de-registration request, 3.1.2.3 MUST be applied and if it is a de-registration request,
considerations from Section 3.1.2.4 MUST be applied. considerations from Section 3.1.2.5 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 Request option present in the o If there is an IPv4 Home Address Request option present in the
skipping to change at page 16, line 30 skipping to change at page 16, line 38
set to 0 (Proxy Binding Update Accepted). Otherwise, the option set to 0 (Proxy Binding Update Accepted). Otherwise, the option
MUST NOT be present. If the option is present, the default router MUST NOT be present. If the option is present, the default router
address in the option MUST be set to the mobile node's default address in the option MUST be set to the mobile node's default
router address. router address.
3.1.2.7. Binding Cache Entry Lookup Considerations 3.1.2.7. Binding Cache Entry Lookup Considerations
The Binding Cache entry lookup considerations specified in section The Binding Cache entry lookup considerations specified in section
5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213]
as the key parameter for identifying the Binding Cache entry. as the key parameter for identifying the Binding Cache entry.
However, when there are no Home Network Prefix options with a However, when there is not a single Home Network Prefix option with a
NON_ZERO value present in the request a single Home Network Prefix NON_ZERO value present in the request, but if there is an IPv4 Home
option with NON_ZERO value present in the request, but if there an Address option with a NON_ZERO value present in the request, then the
IPv4 Home Address option with a NON_ZERO value present in the following considerations MUST be applied.
request, the following considerations MUST be applied.
o The search rules specified in section 5.4.1.1 of [RFC-5213], which o The search rules specified in section 5.4.1.1 of [RFC-5213], which
primarily uses IPv6 home network prefix set as the search key, are primarily uses IPv6 home network prefix set as the search key, are
equally valid when using a single IPv4 home address as the key. equally valid when using a single IPv4 home address as the key.
When applying those considerations, instead of the IPv6 home When applying those considerations, instead of the IPv6 home
network prefix(es), the IPv4 home address from the IPv4 Home network prefix(es), the IPv4 home address from the IPv4 Home
Address option present in the request MUST be used as the search Address option present in the request MUST be used as the search
key. key.
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
skipping to change at page 20, line 11 skipping to change at page 20, line 15
o When using IPv4 transport for carrying the signaling messages, the o When using IPv4 transport for carrying the signaling messages, the
related considerations from section 4.0 MUST be applied related considerations from section 4.0 MUST be applied
additionally. additionally.
3.2.3.2. Receiving Proxy Binding Acknowledgement 3.2.3.2. Receiving Proxy Binding Acknowledgement
All the considerations from section 6.9.1.2 of [RFC-5213] MUST be All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
applied with the following exceptions. applied with the following exceptions.
o If the received Proxy Binding Acknowledgement message has the o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE
mobile node is not authorized for IPv4 home address), the mobile (The mobile node is not authorized for IPv4 mobility service), the
access gateway SHOULD NOT send a Proxy Binding Update message mobile access gateway SHOULD NOT send a Proxy Binding Update
including the IPv4 Home Address Request option till an message including a 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 IPv4 address again, but MAY request the local mobility anchor
do the assignment of address by including exactly one instance of to perform the address assignment by including exactly one
IPv4 Home Address Request option with the IPv4 home address and instance of IPv4 Home Address Request option with the IPv4 home
the prefix length fields in the option set to ALL_ZERO value. address and the prefix length fields in the option set to ALL_ZERO
value.
o If the received Proxy Binding Acknowledgement message has the
Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE
(The mobile node is not authorized for IPv6 mobility service), the
mobile access gateway SHOULD NOT send a Proxy Binding Update
message including any Home Network Prefix option(s) till an
administrative action is taken.
o If there is no IPv4 Home Address Reply option present in the o If there is no IPv4 Home Address Reply option present in the
received Proxy Binding Acknowledgement message, the mobile access received Proxy Binding Acknowledgement message, the mobile access
gateway MUST NOT enable IPv4 support for the mobile node and the gateway MUST NOT enable IPv4 support for the mobile node and the
rest of the considerations from this section can be skipped. rest of the considerations from this section can be 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 Home Address Reply option set to a Status field value in the IPv4 Home Address Reply option set to a
value that indicates that the request was rejected by the local value that indicates that the request was rejected by the local
mobility anchor, the mobile access gateway MUST NOT enable mobility anchor, the mobile access gateway MUST NOT enable
skipping to change at page 21, line 16 skipping to change at page 21, line 28
negotiated encapsulation mode, as specified in Section 4 of this negotiated encapsulation mode, as specified in Section 4 of this
specification. 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 SHOULD
this address on its interface and respond to any ARP requests sent configure this address on its interface and respond to any ARP
by the mobile node for resolving the hardware address of the requests sent by the mobile node for resolving the hardware
default router. It MAY also use this address as the source address of the default router. However, since the link between
the mobile access gateway and the mobile node is a point-to-point
link, implementations will be able receive any packets sent to the
default router address without having to explicitly configure the
default router address on its interface. The mobile access
gateway MAY also use the default router address as the source
address for any datagrams sent to the mobile node and originated address for any datagrams sent to the mobile node and originated
by the mobile access gateway itself. It MAY also use this address by the mobile access gateway itself. It MUST also use this
in the DHCP Router option [RFC-2132] in the DHCP messages. address in the DHCP Router option [RFC-2132] in the DHCP messages.
o If there is an IPv4 DHCP Support Mode option present in the o If there is an IPv4 DHCP Support Mode option present in the
received Proxy Binding Acknowledgement message and if the (S) flag received Proxy Binding Acknowledgement message and if the (S) flag
in the option is set to a value of (1), then the mobile access in the option is set to a value of (1), then the mobile access
gateway MUST function as a DHCP server for the mobile node. If gateway MUST function as a DHCP server for the mobile node. If
either the (S) flag in the option is set to a value of (0), or if either the (S) flag in the option is set to a value of (0), or if
the option is not present in the request, then the mobile access the option is not present in the request, then the mobile access
gateway MUST function as a DHCP Relay for the mobile node. gateway MUST function as a DHCP Relay for the mobile node.
3.2.3.3. Binding Re-Registration and De-Registrations 3.2.3.3. Binding Re-Registration and De-Registrations
skipping to change at page 22, line 39 skipping to change at page 23, line 12
node's IPv4 address, it MUST remove any forwarding state set up node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address. for the mobile node's IPv4 home address.
3.2.4. Routing Considerations for the Mobile Access Gateway 3.2.4. Routing Considerations for the Mobile Access Gateway
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.
o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect the local routing and on the use of
EnableMAGLocalRouting flag.
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. However, when EnableMAGLocalRouting flag is set,
section 3.1.3 MUST be applied. However, before forwarding the considerations from Section 6.10.3 of [RFC-5213] MUST be applied
packet, the mobile access gateway MUST ensure the source address with respect to local routing.
in the received packet is the address allocated for that mobile
node and that there is an active binding on the local mobility
anchor for that mobile node.
o The mobile access gateway MAY use proxy ARP [RFC-925] to reply to o When forwarding the packet through the bi-directional tunnel, the
ARP Requests that it receives from the mobile node seeking address encapsulation considerations specified in section 3.1.3 MUST be
resolutions for the destinations on the mobile node's home subnet. applied. However, before forwarding the packet, the mobile access
When receiving an ARP Request, the local mobility anchor can gateway MUST ensure the source address in the received packet is
examine the target IP address of the Request, and if this IP the address allocated for that mobile node and that there is an
address matches the mobile node's IPv4 home subnet, it MAY active binding on the local mobility anchor for that mobile node.
transmit a Proxy ARP 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
address resolutions for the destinations on the mobile node's home
subnet. When receiving an ARP Request, the local mobility anchor
SHOULD examine the target IP address of the Request, and if this
IP address matches the mobile node's IPv4 home subnet, it SHOULD
transmit a Proxy ARP Reply. However, if the link between the
mobile node and the mobile access gateway is a point-to-point
link, then the mobile access gateway is not required to support
proxy ARP. The mobile node can be configured to use the point-to-
point link for sending all IP packets.
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 25, line 4 skipping to change at page 25, line 23
| IPv4 home address | | IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Home Address Reply Option Figure 4: IPv4 Home Address Reply 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).
Status Status
Indicates success or failure for the IPv4 home address Indicates success or failure for the IPv4 home address
assignment. Values from 0 to 127 indicate success. Higher assignment. Values from 0 to 127 indicate success. Higher
values indicate failure. The following status values are values (128 to 255) indicate failure. The following status
currently allocated by this document: values are currently allocated by this document:
0 Success 0 Success
128 Failure, reason unspecified 128 Failure, reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 Incorrect IPv4 home address 130 Incorrect IPv4 home address
131 Invalid IPv4 address 131 Invalid IPv4 address
skipping to change at page 27, line 45 skipping to change at page 28, line 27
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.5. 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. These values are to be Proxy Binding Acknowledgement message. These values are to be
allocated from the same numbering space, as defined in Section 6.1.8 allocated from the same numbering space, as defined in Section 6.1.8
of [RFC-3775]. of [RFC-3775].
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA
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_HOME_NETWORK_PREFIX: IANA NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA
Mobile node not authorized for the requesting IPv6 home network
prefix(es). Mobile node not authorized for IPv6 mobility service.
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
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
skipping to change at page 28, line 40 skipping to change at page 29, line 26
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 client identifier, o A DHCP server identifies a DHCP client from the interface
if present, or from the client hardware address (chaddr), as identifier, if present, or from the client hardware address
specified in [RFC-2131]. It uses this identity for identifying (chaddr), as specified in [RFC-2131]. It uses this identity for
the client and its interface for which the address is assigned. A identifying the interface for which the address is assigned. A
mobile node in a Proxy Mobile IPv6 domain, can attach to the mobile node in a Proxy Mobile IPv6 domain, can attach to the
network through multiple interfaces and can obtain address network through multiple interfaces and can obtain address
configuration for each of its interfaces. Additionally, it may configuration for each of its interfaces. Additionally, it may
perform handoffs between its interfaces. Following are the perform handoffs between its interfaces. Following are the
related considerations with respect to the identification related considerations with respect to the identification
presented to the DHCP server. presented to the DHCP server.
* If the mobile node attaches to the Proxy Mobile IPv6 domain * If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple interfaces, the DHCP server will uniquely through multiple interfaces, the DHCP server will uniquely
identify each of those interfaces and will perform address identify each of those interfaces and will perform address
assignment. The DHCP server will identify the client as assignment. The DHCP server will identify the interface as
specified in [RFC-2131]. If the client identifier is present, specified in [RFC-2131]. If the interface identifier is
that will be used for identifying the mobile node, otherwise present, that will be used for identifying the mobile node
the client hardware address will be used. Anytime the mobile interface, otherwise the client hardware address will be used.
node changes its point of attachment in the network and Anytime the mobile node performs an handoff to a different
performs an handoff to a different mobile access gateway, using mobile access gateway, using the same interface, the DHCP
the same interface, the DHCP server will always be able to server will always be able to identify the binding using the
identify the binding using the presented identifier, the client presented identifier, the interface identifier or the hardware
identifier or the hardware address. The client identifier or address. The interface identifier or the hardware address will
the hardware address will remain as the primary key for each remain as the primary key for each binding, just as how they
binding, just as how they are unique in a Binding Cache entry. are unique in a Binding Cache entry.
* However, if the mobile node is capable of performing handoff * However, if the mobile node is capable of performing handoff
between interfaces, as per [RFC-5213], the client identifier in between interfaces, as per [RFC-5213], the interface identifier
such scenarios needs to be an identifier that is not tied to in such scenarios needs to be an identifier that is not tied to
any of those interfaces. The identifier must be a stable any of those interfaces. The identifier must be a stable
identifier which remains the same through out the mobile node's identifier which remains the same through out the mobile node's
attachment in that Proxy Mobile IPv6 domain. This identifier attachment in that Proxy Mobile IPv6 domain. This identifier
must remain fixed for a given binding. This identifier in some must remain fixed for a given binding. This identifier in some
implementations can be the identifier associated to a virtual implementations can be the identifier associated to a virtual
interface, that is abstracting the physical interfaces. 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
skipping to change at page 31, line 13 skipping to change at page 31, line 34
router address. router address.
o If the mobile node sends the DHCPREQUEST message, the DHCP server o If the mobile node sends the DHCPREQUEST message, the DHCP server
will send DHCPACK message, as per [RFC-2131]. will send DHCPACK message, as per [RFC-2131].
IPv4 Home Address Renewal with the DHCP server (No Handoff): IPv4 Home Address Renewal with the DHCP server (No Handoff):
o Any time the mobile node goes into the DHCP RENEWING state [RFC- o Any time the mobile node goes into the DHCP RENEWING state [RFC-
2131], it simply unicasts the DHCPREQUEST message including the 2131], it simply unicasts the DHCPREQUEST message including the
assigned IPv4 home address in the 'requested IP address' option. assigned IPv4 home address in the 'requested IP address' option.
The DHCPREQUEST is sent to the address specified in 'server The DHCPREQUEST is sent to the address specified in Server
identifier' field of the previously received DHCPOFFER and DHCPACK Identifier option of the previously received DHCPOFFER and DHCPACK
messages. messages.
o The DHCP server will send a DHCPACK to the mobile node to o The DHCP server will send a DHCPACK to the mobile node to
acknowledge the assignment of the committed IPv4 address. acknowledge the assignment of the committed IPv4 address.
IPv4 Home Address Renewal with the DHCP server (After Handoff): IPv4 Home Address Renewal with the DHCP server (After Handoff):
When the mobile node goes into the DHCP RENEWING state [RFC-2131], it When the mobile node goes into the DHCP RENEWING state [RFC-2131], it
directly unicasts the DHCPREQUEST message to the DHCP server that directly unicasts the DHCPREQUEST message to the DHCP server that
currently provided the DHCP lease. However, if the mobile node currently provided the DHCP lease. However, if the mobile node
skipping to change at page 31, line 41 skipping to change at page 32, line 16
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 8: 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 The use of a stable address, either the IPv4 default router
mobile node is used as the DHCP server Id on any of the links in address of the mobile node, or a fixed IPv4 address common in that
that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the Proxy Mobile IPv6 domain, as the DHCP server Id will ensure the
mobile node for renewing the address will be received by the new DHCPREQUEST message sent by the mobile node for renewing the
mobile access gateway on the attached link. The mobile access address will be received by the new mobile access gateway on the
gateway after completing the Proxy Mobile IPv6 signaling and upon attached link. The mobile access gateway after completing the
acquiring the IPv4 home address of the mobile node will return the Proxy Mobile IPv6 signaling and upon acquiring the IPv4 home
address in the DHCPACK message. However, if the mobile access address of the mobile node will return the address in the DHCPACK
gateway is unable to complete the Proxy Mobile IPv6 signaling or message. However, if the mobile access gateway is unable to
is unable to acquire the same IPv4 address as requested by the complete the Proxy Mobile IPv6 signaling or is unable to acquire
mobile node, it will send a DHCPNACK message [RFC-2131] to the the same IPv4 address as requested by the mobile node, it will
mobile node, as shown in Figure 8-1). 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 55, line 7 skipping to change at page 56, 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 Home This document defines four new Mobility Header options, IPv4 Home
Address Request option, IPv4 Home Address Reply option, IPv4 Default Address Request option, IPv4 Home Address Reply option, IPv4 Default
Router Address option and IPv4 DHCP Support Mode option. These Router Address option and IPv4 DHCP Support Mode option. These
options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4 options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4
respectively. The Type value for these options needs to be assigned respectively. The Type value for these options needs to be assigned
from the same number space as allocated for the other mobility from the same number space as allocated for the other mobility
options, as defined in [RFC-3775]. options, as defined in [RFC-3775].
The IPv4 Home Address Reply option, described in Section 3.3.2 of The IPv4 Home Address Reply option, described in Section 3.3.2 of
this document, introduces a new number space, IPv4 Home Address Reply this document, introduces a new number space, IPv4 Home Address Reply
Status Codes. This document currently reserves the following values. Status Codes. This document currently reserves the following values.
skipping to change at page 55, line 45 skipping to change at page 56, line 45
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.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
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_HOME_NETWORK_PREFIX: IANA
Mobile node not authorized for the requesting IPv6 home network NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA
prefix(es).
Mobile node not authorized for IPv6 mobility service.
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
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.
 End of changes. 43 change blocks. 
126 lines changed or deleted 163 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/