draft-ietf-netlmm-pmip6-ipv4-support-06.txt   draft-ietf-netlmm-pmip6-ipv4-support-07.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: May 31, 2009 Cisco Expires: June 19, 2009 Cisco
November 27, 2008 December 16, 2008
IPv4 Support for Proxy Mobile IPv6 IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-06.txt draft-ietf-netlmm-pmip6-ipv4-support-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 31, 2009. This Internet-Draft will expire on June 19, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies extensions to Proxy Mobile IPv6 protocol for This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) enable IPv4 home address mobility support to the mobile two-fold: 1) enable IPv4 home address mobility support to the mobile
skipping to change at page 6, line 45 skipping to change at page 6, line 45
o The local mobility anchor and the mobile access gateway are both o The local mobility anchor and the mobile access gateway are both
IPv4 and IPv6 enabled. Irrespective of the type of transport IPv4 and IPv6 enabled. Irrespective of the type of transport
network (IPv4 or IPv6) separating these two entities, the mobility network (IPv4 or IPv6) separating these two entities, the mobility
signaling is always based on Proxy Mobile IPv6 [RFC-5213]. signaling is always 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 global addresses, even when they are in IPv4- configured with IPv6 global addresses, even when they are in IPv4-
only network. When using IPv4 transport, it is not required that only network. When using IPv4 transport, it is not required that
there is IPv6 routing enabled between the local mobility anchor there is IPv6 routing enabled between the local mobility anchor
and the mobile access gateway. However, there must be IPv6 and the mobile access gateway. However, they must be able to
routing enabled for the configured address locally within the receive any IPv6 packets sent to the configured IPv6 addresses,
host. 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,
skipping to change at page 25, line 28 skipping to change at page 25, line 28
o The DHCP server identifies the DHCP client either from the client o The DHCP server identifies the DHCP client either from the client
identifier or the client hardware address (chaddr) [RFC-2131]. A identifier or the client hardware address (chaddr) [RFC-2131]. A
mobile node in a Proxy Mobile IPv6 domain may present any of these mobile node in a Proxy Mobile IPv6 domain may present any of these
identifiers to the DHCP server as long as the identifier remains identifiers to the DHCP server as long as the identifier remains
the same through out the mobile node's attachment in that Proxy the same through out the mobile node's attachment in that Proxy
Mobile IPv6 domain. If the client hardware address is used as the Mobile IPv6 domain. If the client hardware address is used as the
identifier and if the mobile node performs an handoff between two identifier and if the mobile node performs an handoff between two
interfaces, this hardware identifier will change and the DHCP interfaces, this hardware identifier will change and the DHCP
server will not be able to identify the mobile node. Thus, it is server will not be able to identify the mobile node. Thus, it is
recommended that the DHCP client in a multihomed mobile node is recommended that the DHCP client on the mobile node, which
configured to use a stable client identifier that does not change performs mobility session handoff across interfaces in a Proxy
during the active life of its DHCP session. Mobile IPv6 domain, is configured to use a stable client
identifier that does not change during the active life of its DHCP
session.
o All the DHCP servers co-located with the mobile access gateways in o All the DHCP servers co-located with the mobile access gateways in
a Proxy Mobile IPv6 domain can be configured with the same set of a Proxy Mobile IPv6 domain can be configured with the same set of
DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure
the mobile node receives the same configuration values on any of the mobile node receives the same configuration values on any of
the access links in that Proxy Mobile IPv6 domain. the access links in that Proxy Mobile IPv6 domain.
3.4.1. DHCP Server co-located with the Mobile Access Gateway 3.4.1. DHCP Server co-located with the Mobile Access Gateway
This section explains the operational sequence of home address This section explains the operational sequence of home address
skipping to change at page 29, line 47 skipping to change at page 29, line 47
the mobile node, the DHCP messages will be forwarded to the DHCP the mobile node, the DHCP messages will be forwarded to the DHCP
server. server.
o The DHCP relay agent on the mobile access gateway will add the o The DHCP relay agent on the mobile access gateway will add the
DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER
message. The assigned IPv4 home address will be included in the message. The assigned IPv4 home address will be included in the
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
access gateway will ensure the assigned address is the address
that is currently assigned to the mobile node by the local
mobility anchor. If this address is different from what is
assigned to the mobile node, then the mobile access gateway will
drop the DHCPOFFER message and an administrative error message can
be logged.
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.
IPv4 Home Address Renewal to the same DHCP server: (No Handover) IPv4 Home Address Renewal to the same DHCP server: (No Handover)
skipping to change at page 33, line 39 skipping to change at page 33, line 39
and ESP headers). Refer to [RFC-3948]. and ESP headers). Refer to [RFC-3948].
4.1. Local Mobility Anchor Considerations 4.1. Local Mobility Anchor Considerations
4.1.1. Extensions to Binding Cache Entry 4.1.1. Extensions to Binding Cache Entry
To support this feature, the conceptual Binding Cache entry data To support this feature, the conceptual Binding Cache entry data
structure maintained by the local mobility anchor [RFC-5213] MUST be structure maintained by the local mobility anchor [RFC-5213] MUST be
extended with the following additional parameters. extended with the following additional parameters.
o The IPv4 address of the mobile access gateway. This is the o This is the IPv4 Proxy Care-of Address configured on the mobile
address configured on the egress interface of the mobile access access gateway that sent the Proxy Binding Update message. This
gateway that sent the Proxy Binding Update message. This address address can be obtained from the IPv4 Care-of Address option [ID-
can be obtained from the IPv4 Care-of Address option [ID-DSMIP6], DSMIP6], present in the received Proxy Binding Update message. If
present in the received Proxy Binding Update message. If the the option was not present in the request, this field MUST be set
option was not present in the request, this field MUST be set to to the source address of the IPv4 header of the received Proxy
the source address of the IPv4 header of the received Proxy
Binding Update message. However, if the received Proxy Binding Binding Update message. However, if the received Proxy Binding
Update message is not sent as an IPv4 packet, this field MUST be Update message is not sent as an IPv4 packet, this field MUST be
set to ALL_ZERO value. set to ALL_ZERO value.
o The IPv4 NAT translated address of the mobile access gateway. If o The IPv4 NAT translated address of the mobile access gateway. If
the mobile access gateway is not behind a NAT [RFC-3022], this the mobile access gateway is not behind a NAT [RFC-3022], this
address will be the same as the address configured on the egress address will be the same as the address configured on the egress
interface of the mobile access gateway. This address can be interface of the mobile access gateway. This address can be
obtained from the IPv4 header of the received Proxy Binding Update obtained from the IPv4 header of the received Proxy Binding Update
message. However, if the received Proxy Binding Update message is message. However, if the received Proxy Binding Update message is
skipping to change at page 45, line 23 skipping to change at page 45, line 23
Home Address assignment and IPv4 Transport Support features. It also Home Address assignment and IPv4 Transport Support features. It also
uses some of the mobility options from DSMIPv6 specification [ID- uses some of the mobility options from DSMIPv6 specification [ID-
DSMIP6]. These options are to be carried in Proxy Binding Update and DSMIP6]. These options are to be carried in Proxy Binding Update and
Proxy Binding Acknowledgement messages. The required security Proxy Binding Acknowledgement messages. The required security
mechanisms specified in the base Proxy Mobile IPv6 protocol for mechanisms specified in the base Proxy Mobile IPv6 protocol for
protecting these signaling messages are sufficient when carrying protecting these signaling messages are sufficient when carrying
these mobility options. these mobility options.
This specification describes the use of IPv4 transport for exchanging This specification describes the use of IPv4 transport for exchanging
the signaling messages between the local mobility anchor and the the signaling messages between the local mobility anchor and the
mobile access gateway. These messages are protected using IPsec mobile access gateway. These signaling messages are fundamentally
using the security associations established using the IPv4 transport IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4
addresses and offer the same security as when the messages are packets. The encapsulated inner IPv6 message is still protected
protected when using IPv6 transport. using IPsec, using the established security association and this
offers the same level of security as when the messages are routed
natively as IPv6 packets. The use of outer IPv4 header does not
introduce any new security vulnerabilities.
8. Contributors 8. Contributors
This document reflects discussions and contributions from several This document reflects discussions and contributions from several
people (in alphabetical order): people (in alphabetical order):
Kuntal Chowdhury Kuntal Chowdhury
kchowdhury@starentnetworks.com kchowdhury@starentnetworks.com
skipping to change at page 46, line 37 skipping to change at page 46, line 37
myungki.shin@gmail.com myungki.shin@gmail.com
9. Acknowledgments 9. Acknowledgments
The IPv4 support for Proxy Mobile IPv6 was initially covered in the The IPv4 support for Proxy Mobile IPv6 was initially covered in the
internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like
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 Behcet Sarikaya, Charles Perkins, Jonne Soinnen, Julien Thanks to Alper Yegin, Behcet Sarikaya, Charles Perkins, Damic
Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Damjan, Jonne Soinnen, Julien Laganier, Mohana Jeyatharan, Niklas
Touati and Zu Qiang for their helpful review of this document. Nuemann, Premec Domagoj, Sammy Touati, Yingzhe Wu and Zu Qiang for
their helpful review of this document.
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.
skipping to change at page 47, line 16 skipping to change at page 47, line 17
IPv6 Specification", RFC 2473, December 1998. 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-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
November 2007. November 2007.
[ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
Hosts and Routers (DSMIPv6)", Hosts and Routers (DSMIPv6)",
draft-ietf-mext-nemo-v4traversal-06.txt, November 2008. draft-ietf-mext-nemo-v4traversal-07.txt, December 2008.
10.2. Informative References 10.2. Informative References
[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-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP", [RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP",
RFC 3011, November 2000. RFC 3011, November 2000.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
 End of changes. 10 change blocks. 
33 lines changed or deleted 30 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/