draft-ietf-netlmm-pmip6-ipv4-support-11.txt   draft-ietf-netlmm-pmip6-ipv4-support-12.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: October 10, 2009 Cisco Expires: October 25, 2009 Cisco
April 08, 2009 April 23, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-11.txt draft-ietf-netlmm-pmip6-ipv4-support-12.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 October 10, 2009. This Internet-Draft will expire on October 25, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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 . . . . . . . . . . . . . . . . . . . . . . . 28 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
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 32
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 34 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 34
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 35 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 35
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 36 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 36
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 36 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 36
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40
4.2.1. Extensions to Binding Update List Entry . . . . . . . 40 4.2.1. Extensions to Binding Update List Entry . . . . . . . 40
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 41 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 41
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. If the mobile node is DNAv4 [RFC-4436] capable after the handoff.
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 23, line 28 skipping to change at page 23, line 28
option, it MUST include a Home Network Prefix option for each of option, it MUST include a Home Network Prefix option for each of
the assigned home network prefixes assigned for that mobility the assigned home network prefixes assigned for that mobility
session and with the prefix value in the option set to that session and with the prefix value in the option set to that
respective prefix value. respective prefix value.
o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present
if the same option(s) was not present in the initial Proxy Binding if the same option(s) was not present in the initial Proxy Binding
Update message. Otherwise considerations from [RFC-5213] with Update message. Otherwise considerations from [RFC-5213] with
respect to this option MUST be applied. respect to this option MUST be applied.
o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up
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 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied
with respect the local routing and on the use of with respect the local routing and on the use of
EnableMAGLocalRouting flag. EnableMAGLocalRouting flag.
skipping to change at page 30, line 17 skipping to change at page 30, line 19
mobile node for renewing the address will be received by the new mobile node for renewing the address will be received by the new
mobile access gateway on the attached link. The mobile access mobile access gateway on the attached link. The mobile access
gateway after completing the Proxy Mobile IPv6 signaling and upon gateway after completing the Proxy Mobile IPv6 signaling and upon
acquiring the IPv4 home address of the mobile node will return the acquiring the IPv4 home address of the mobile node will return the
address in the DHCPACK message. However, if the mobile access address in the DHCPACK message. However, if the mobile access
gateway is unable to complete the Proxy Mobile IPv6 signaling or gateway is unable to complete the Proxy Mobile IPv6 signaling or
is unable to acquire the same IPv4 address as requested by the is unable to acquire the same IPv4 address as requested by the
mobile node, it will send a DHCPNACK message [RFC-2131] to the mobile node, it will send a DHCPNACK message [RFC-2131] to the
mobile node, as shown in Figure 6-1). mobile node, as shown in Figure 6-1).
Additional Operation:
o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address.
3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway
A DHCP relay agent is co-located with each mobile access gateway. A A DHCP relay agent is co-located with each mobile access gateway. A
DHCP server is located somewhere in the Proxy Mobile IPv6 domain DHCP server is located somewhere in the Proxy Mobile IPv6 domain
(e.g., is co-located with the local mobility anchor). Figure 7 shows (e.g., is co-located with the local mobility anchor). Figure 7 shows
the sequence of IPv4 home address assignment using DHCP Relay. the sequence of IPv4 home address assignment using DHCP Relay.
MN MAG(DHCP-R) LMA DHCP-S MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update * | |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA)
skipping to change at page 31, line 50 skipping to change at page 31, line 44
DHCP messages relayed by the mobile access gateway can be tunneled DHCP messages relayed by the mobile access gateway can be tunneled
to the local mobility anchor if needed. Alternatively, if the to the local mobility anchor if needed. Alternatively, if the
network in the Proxy Mobile IPv6 domain is secure enough, the network in the Proxy Mobile IPv6 domain is secure enough, the
mobile access gateway can just relay the DHCP messages to the mobile access gateway can just relay the DHCP messages to the
server. To achieve this, all the mobile access gateways needs to server. To achieve this, all the mobile access gateways needs to
have a route towards the DHCP server. have a route towards the DHCP server.
IPv4 Home Address Renewal to the same DHCP server: (No Handover) IPv4 Home Address Renewal to the same DHCP server: (No Handover)
o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it
directly unicasts DHCPREQUEST message to the DHCP server. The directly unicasts DHCPREQUEST messages to the DHCP server. The
DHCP relay agent may not detect these unicasted DHCPREQUEST DHCP relay agent may not detect any changes in the DHCP state.
messages for renewing the address. Thus, any of the following For example, if the mobile node releases the IPv4 address, the
approaches can be adopted. relay agent would not be aware of it. The following describes
additional mechanisms for the mobile access gateway to detect any
changes in the DHCP state.
* The DHCP relay agent can intercept all IPv4 DHCP packets * The DHCP relay agent can intercept all IPv4 DHCP packets
destined to the set of addresses used within the Proxy Mobile destined to the set of addresses used within the Proxy Mobile
IPv6 domain as DHCP addresses. Since the link between a mobile IPv6 domain as DHCP addresses. Since the link between a mobile
node and a mobile access gateway is the point-to-point link, node and a mobile access gateway is the point-to-point link,
the mobile access gateway will be in path for all the messages. the mobile access gateway will be in path for all the messages.
* The DHCP relay agent can use the DHCP Server Identifier * The DHCP relay agent can use the DHCP Server Identifier
Override Sub-option [RFC-5107] to be in path for all the DHCP Override Sub-option [RFC-5107] to be in path for all the DHCP
message flows. The DHCP client uses the DHCP server address message flows. The DHCP client uses the DHCP server address
which is overridden by the DHCP relay agent address as a which is overridden by the DHCP relay agent address as a
destination address of DHCPREQUEST. The DHCP Server Identifier destination address of DHCPREQUEST. The DHCP Server Identifier
Override Sub-option is recommended only when the fixed DHCP Override Sub-option is recommended only when the fixed DHCP
relay address is configured on all the mobile access gateways. relay address is configured on all the mobile access gateways.
Otherwise, the DHCP relay agent address is changed when the Otherwise, the DHCP relay agent address is changed when the
mobile node changes the attached mobile access gateway. mobile node changes the attached mobile access gateway.
o The DHCP Relay agent on detecting the DHCPREQUEST message from the o However, if the DHCP server is co-located with the local mobility
mobile node, will verify if the address in the DHCPREQUEST message anchor, then the DHCP relay agent is not required to intercept the
is the address assigned by the local mobility anchor for that unicast DHCP messages between the mobile node and the DHCP server.
mobile node. If the requesting IPv4 home address is not This is because the local mobility anchor will ensure that the
registered to the local mobility anchor, the mobile access gateway DHCP state is consistent with the PMIPv6 binding that exists for
will drop the packet. Once the address verification is the IPv4 address.
successfully completed, the DHCP relay agent will forward the
DHCPREQUEST message to the DHCP server. However, the mobile
access gateway is neither required to perform this check, nor
intercept the DCHPREQUEST message from the mobile node, if the
DHCP server is co-located with the local mobility anchor, as that
check will be performed by the local mobility anchor in such
scenario. The mobile access gateway can determine the co-location
of the DHCP server and the local mobility anchor by comparing the
source address of the DHCPOFFER message with the address of the
mobile node's local mobility anchor.
IPv4 Address Release Triggers from the mobile node: o Once the mobile access gateway intercepts the DHCP message from
the mobile node to the DHCP server, it can verify if the mobile
node is negotiating the same IPv4 address that the local mobility
anchor allocated for that mobile node. If the address in the
DHCPREQUEST message does not match with the IPv4 address allocated
for the mobile node, then the mobile access gateway SHOULD
silently drop the DHCP message.
o Any time the mobile access gateway detects that the mobile node
has released its IPv4 address, it can send a Proxy Binding Update
to the local mobility anchor and de-register the IPv4 mobility
session.
3.4.3. Common DHCP Considerations
The following handoff considerations are common to both the supported
configuration modes, specified in Section 3.4.1 and Section 3.4.2.
o When the mobile node performs an handoff from one mobile access
gateway to the another, the mobile access gateway on the new link
will initiate the Proxy Mobile IPv6 signaling with the local
mobility anchor. On completing the Proxy Mobile IPv6 signaling,
the mobile access gateway has the proper IPv4 address state that
the local mobility anchor has allocated for the mobile node and
which can be used for supporting DHCP based address configuration
on that link.
o 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, as per the base Proxy
Mobile IPv6 specification [RFC-5213]. The mobile node will not
perform any DHCP operation specifically due to this handoff.
o If the mobile node is not DNAv4 [RFC-4436] capable, after handoff
it will enter INIT-REBOOT state [RFC-2131] and will send a
DHCPREQUEST message. The mobile node in both the configuration
modes, specified in Section 3.4.1 and Section 3.4.2, will obtain
the same address configuration as before, as the link change will
not be transparent to the mobile node in that Proxy Mobile IPv6
domain.
o The mobile node may release its IPv4 home address at any time by o The mobile node may release its IPv4 home address at any time by
sending the DHCPRELEASE message [RFC-2131]. When the mobile sending the DHCPRELEASE message [RFC-2131]. When the mobile
access gateway detects the DHCPRELEASE message sent by the mobile access gateway detects the DHCPRELEASE message sent by the mobile
node and for releasing its assigned IPv4 home address, the mobile node, it should consider this as a trigger for de-registering the
access gateway should consider this as a trigger for de- mobile node's IPv4 home address. It will apply the considerations
registering the mobile node's IPv4 home address. It MUST apply specified in section 3.2.3.3 for performing the de-registration
the considerations specified in section 3.2.3.3 for performing the procedure. However, this operation should not release any IPv6
de-registration procedure. However, this operation should not home network prefix(es) assigned to the mobile node.
release any IPv6 home network prefix(es) assigned to the mobile
node.
Additional Operations:
o If at any point the mobile access gateway fails to extend the
binding lifetime with the local mobility anchor for the mobile
node's IPv4 address, it MUST remove any forwarding state set up
for the mobile node's IPv4 home address.
4. IPv4 Transport Support 4. IPv4 Transport Support
The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling
messages exchanged between the local mobility anchor and the mobile messages exchanged between the local mobility anchor and the mobile
access gateway to be over an IPv6 transport. The extensions defined access gateway to be over an IPv6 transport. The extensions defined
in this section allow the exchange of signaling messages over an IPv4 in this section allow the exchange of signaling messages over an IPv4
transport when the local mobility anchor and the mobile access transport when the local mobility anchor and the mobile access
gateway are separated by an IPv4 network and are reachable using only gateway are separated by an IPv4 network and are reachable using only
IPv4 addresses. IPv4 addresses.
 End of changes. 11 change blocks. 
51 lines changed or deleted 70 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/