draft-ietf-netlmm-pmip6-ipv4-support-08.txt   draft-ietf-netlmm-pmip6-ipv4-support-09.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: July 22, 2009 Cisco Expires: July 24, 2009 Cisco
January 18, 2009 January 20, 2009
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-08.txt draft-ietf-netlmm-pmip6-ipv4-support-09.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 July 22, 2009. This Internet-Draft will expire on July 24, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 20, line 38 skipping to change at page 20, line 38
dynamically created bi-directional tunnel. However, when using dynamically created bi-directional tunnel. However, when using
IPv4 transport, the encapsulation mode MUST be set to the IPv4 transport, the encapsulation mode MUST be set to the
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 If there is an IPv4 Default-Router Address option present in the o The default-router address MUST be obtained from the IPv4 Default-
received Proxy Binding Acknowledgement message, the mobile access Router Address option present in the received Proxy Binding
gateway MAY configure this address on its interface and respond to Acknowledgement message. The mobile access gateway MAY configure
any ARP requests sent by the mobile node for resolving the this address on its interface and respond to any ARP requests sent
hardware address of the default-router. It MAY also use this by the mobile node for resolving the hardware address of the
address as the source address for any datagrams sent to the mobile default-router. It MAY also use this address as the source
node and originated by the mobile access gateway itself. It MAY address for any datagrams sent to the mobile node and originated
also use this address in the DHCP Router option [RFC-2132] in the by the mobile access gateway itself. It MAY also use this address
DHCP messages. 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 30, line 23 skipping to change at page 30, line 23
Agent Remote ID Sub-option of the DHCP relay agent information Agent Remote ID Sub-option of the DHCP relay agent information
option. This sub-option is used as a hint for requesting the DHCP option. This sub-option is used as a hint for requesting the DHCP
server to allocate that specific IPv4 address. server to allocate that specific IPv4 address.
o On receiving a DHCPOFFER message from the DHCP server, the mobile o On receiving a DHCPOFFER message from the DHCP server, the mobile
access gateway will ensure the assigned address is currently access gateway will ensure the assigned address is currently
assigned by the local mobility anchor to that mobile node. If assigned by the local mobility anchor to that mobile node. If
this address is different from what is assigned to the mobile this address is different from what is assigned to the mobile
node, then the mobile access gateway will drop the DHCPOFFER node, then the mobile access gateway will drop the DHCPOFFER
message and an administrative error message will be logged. message and an administrative error message will be logged.
However, the mobile access gateway is not required to perform this
check, 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.
o When the DHCP messages are sent over administrative boundaries, o When the DHCP messages are sent over administrative boundaries,
the operators needs to ensure these messages are secured. All the the operators needs to ensure these messages are secured. All the
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 route towards the DHCP server. have route towards the DHCP server.
skipping to change at page 31, line 23 skipping to change at page 31, line 16
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 The DHCP Relay agent on detecting the DHCPREQUEST message from the
mobile node, will verify if the address in the DHCPREQUEST message mobile node, will verify if the address in the DHCPREQUEST message
is the address assigned by the local mobility anchor for that is the address assigned by the local mobility anchor for that
mobile node. If the requesting IPv4 home address is not mobile node. If the requesting IPv4 home address is not
registered to the local mobility anchor, the mobile access gateway registered to the local mobility anchor, the mobile access gateway
will drop the packet. Once the address verification is will drop the packet. Once the address verification is
successfully completed, the DHCP relay agent will forward the successfully completed, the DHCP relay agent will forward the
DHCPREQUEST message to the DHCP server. DHCPREQUEST message to the DHCP server. However, the mobile
access gateway is not required to perform this check, 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: IPv4 Address Release Triggers from the mobile node:
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 and for releasing its assigned IPv4 home address, the mobile
access gateway should consider this as a trigger for de- access gateway should consider this as a trigger for de-
registering the mobile node's IPv4 home address. It MUST apply registering the mobile node's IPv4 home address. It MUST apply
the considerations specified in section 3.2.3.3 for performing the the considerations specified in section 3.2.3.3 for performing the
 End of changes. 6 change blocks. 
21 lines changed or deleted 21 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/