IPv6 Group R. Droms
Internet-Draft P. Thubert
Expires: August 6, 2004 Cisco
February 6, 2004
DHCPv6 Prefix Delegation for NEMO
draft-droms-nemo-dhcpv6-pd-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
One aspect of network mobility support is the assignment of a prefix
or prefixes to a mobile router (MR) for use on the links in the
mobile network. DHCPv6 prefix delegation can be used for this
configuration task.
1. Introduction
One aspect of network mobility support is the assignment of a prefix
or prefixes to a mobile router for use on the links in the mobile
network. DHCPv6 prefix delegation [4] (DHCPv6PD) can be used for
this configuration task, whether from the Home Network or locally
from an Access Network.
Droms & Thubert Expires August 6, 2004 [Page 1]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
2. Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC2119 [1].
The following terms used in this document are defined in the IPv6
Addressing Architecture document [3]:
link-local unicast address
link-local scope multicast address
The following terms used in this document are defined in the mobile
IPv6 specification [5]:
home agent (HA)
home link
The following terms used in this document are defined in the mobile
network terminology document [8]:
mobile router (MR)
mobile network
mobile host (MH)
The following terms used in this document are defined in the DHCPv6
[2] and DHCPv6 prefix delegation [4] specifications:
delegating router (DR)
requesting router (RR)
DHCPv6 relay agent
3. Application of DHCPv6 prefix delegation to mobile networks
The network mobility requirements document [7] defines a solution for
mobile IPv6 networks based on the mobile IPv6 protocol [5]. In this
solution, a MR uses the mobile IPv6 protocol to establish a maintain
a session with its HA, and uses bidirectional tunneling between the
MR and HA to provide a path through which hosts attached to links in
the mobile network can maintain connectivity with nodes not in the
mobile network.
Droms & Thubert Expires August 6, 2004 [Page 2]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
The requirements in basic network mobility support [7] include the
ability of the MR to receive delegated prefixes that can then be
assigned to links in the mobile network. DHCPv6PD can be used to
meet this requirement for prefix delegation.
3.1 Delegating Home prefixes
To use DHCPv6PD for mobile networks, the HA assumes the role of the
DR and the MR assumes the role of the RR. Throughout the remainder of
this document, the HA will be assumed to be acting as a DHCPv6PD DR
and the MR will be assumed to be acting as a RR.
The HA and MR exchange DHCPv6PD protocol messages through the tunnel
connecting them. The tunnel acts as the link labeled "DSL to
subscriber premises" in figure 1 of the DHCPv6PD specification.
The HA (acting as the DR) is provisioned with prefixes to be assigned
using any of the prefix assignment mechanisms described in the
DHCPv6PD specifications. Other updates to the HA data structures
required as a side effect of prefix delegation are specified by the
particular network mobility protocol. For example, in the case of
Basic Network Mobility Support [6], the HA would add an entry in its
binding cache registering the delegated prefix to the MR to which the
prefix was delegated.
3.1.1 Use of HA-MR tunnel for DHCPv6 messages
The DHCPv6 specification requires the use of link-local unicast and
link-local scope multicast addresses in DHCPv6 messages (except in
certain cases as defined in section 22.12 of the DHCPv6
specification). Section 10.4.2 of the mobile IPv6 specification
describes forwarding of intercepted packets, and the third paragraph
of that section begins:
However, packets addressed to the mobile node's link-local address
MUST NOT be tunneled to the mobile node.
The DHCPv6 messages exchanged between the HA and the MR originate
only with the HA and the MR, and therefore are not "intercepted
packets" and may be sent between the HA and the MR through the
tunnel.
3.1.2 Exchanging DHCPv6 messages when HA and MR are on the same link
When the MR is on its home link, the HA uses the home link to
exchange DHCPv6PD messages with the MR, even if there is a tunnel
across the home link between the MR and the HA. It is the
responsibility of the implementation to determine when the MR is on
Droms & Thubert Expires August 6, 2004 [Page 3]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
its home link and to avoid use of any existing tunnel.
3.1.3 Location of DHCPv6PD Delegating Router function
The DHCPv6PD DR function MUST be implemented in the HA for the MR.
The use of a DHCPv6 relay agent is not defined for DHCPv6PD.
3.1.4 Other DHCPv6 functions
The DHCPv6 messages exchanged between the MR and the HA may also be
used for other DHCPv6 functions in addition to DHCPv6PD. For
example, the HA may assign global addresses to the MR and may pass
other configuration information such as a list of available DNS
recursive resolvers to the MR using the same DHCPv6 messages as used
for DHCPV6PD.
The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR
for MRs.
3.2 Delegating Access Prefixes
A Mobile Router may also obtain a temporary delegated prefix from its
Access Router (acting as a DHCPv6PD DR) while the MR is roaming
within the AR space.
This is used for instance if the MR opens a network for anonymous
visitors to roam in. In that model, the delegated network is
advertised in the clear, as opposed to the MR's own Mobile Network
Prefixes, which can stay private, over secured media.
As a result, the CareOf Addresses of the visitors in a nested
structure are all aggregated by a larger prefix owned, subdelegated,
and advertised to the infrastructure by the Access Router itself.
It is possible to protect the privacy of both parties between a VMN
that implements RFC 3041 [13] and a visited MR that advertises only
the delegated prefixes in the clear.
In the case of a nested structure, it is expected that the AR and the
MR maintain a tunnel and that the connectivity between the two is
maintained somehow; this can be achieved by:
Performing a routing protocol such as a MANET within the nested
topology.
performing some L3 bridging technique between AR and MRs.
Droms & Thubert Expires August 6, 2004 [Page 4]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
placing a Nemo Home Agent at the AR so that the MR registers the
mobility of the delegated prefix while it is roaming inside or
outside the nested structure below the AR.
It may be beneficial for the Mobile Router to use its address within
its delegated prefix as CareOf to register to its Home Agent. As a
result, the MR gets some advantages similar to those obtained with
HMIP.
In particular, if the Access Router is a Home Agent for the
aggregation of delegated prefixes, and if that Home Agent supports
the Reverse Routing Header (see [9]), then there are only 2 tunnels,
the MRAR encapsulating the MRHA tunnel whatever the nested depth of
the MR.
3.2.1 New Tree Information Option Format
This draft modifies the Tree Information option, as described in [9],
adding a new bit to indicate that the TLMR supports DHCP-PD.
The new bit are set by the TLMR are propagated transparently by the
MRs. Mobile Routers SHOULD add that option to the Router
Advertisement messages sent over the ingress interfaces.
Droms & Thubert Expires August 6, 2004 [Page 5]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
The Tree Information option has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 6 | TreePreference| TreeDepth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|H|D|Reserved | Bandwidth | DelayTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRPreference | BootTimeRandom |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PathCRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Tree TLMR Identifier +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Tree Group +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8-bit unsigned integer set to 10 by the TLMR.
Length
8-bit unsigned integer set to 6 by the TLMR. The length of the
option (including the type and length fields) in units of 8
octets.
TreePreference
8-bit unsigned integer set by the TLMR to its configured
preference. Range from 0 = lowest to 255 = highest.
TreeDepth
8-bit unsigned integer set to 0 by the TLMR and incremented by 1
Droms & Thubert Expires August 6, 2004 [Page 6]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
by each MR down the tree.
Grounded (G)
1-bit flag. Set by the TLMR to indicate that it is either attached
to a fixed network or at home.
Home Agent (H)
1-bit flag. Set by the TLMR to indicate that it is also
functioning as a Home Agent, for re-homing purposes.
Home (D)
1-bit flag. Set by the TLMR to indicate that it is also
functioning as a DHCPv6PD-DR.
Reserved
6-bit unsigned integer, set to 0 by the TLMR.
Bandwidth
8-bit unsigned integer set by the TLMR and decremented by MRs with
lower egress bandwidth. This is a power of 2 so that the available
egress bandwidth in bps is between 2^Bandwidth and
2^(Bandwidth+1). 0 means 'unspecified' and can not be modified
down the tree.
DelayTime
16-bit unsigned integer set by the TLMR. Tree time constant in
milliseconds.
MRPreference
8-bit signed integer. Set by each MR to its configured preference.
Range from 0 = lowest to 255 = highest.
BootTimeRandom
24-bit unsigned integer set by each MR to a random value that the
MR generates at boot time.
PathCRC
32-bit unsigned integer CRC, updated by each MR. This is the
result of a CRC-32c computation on a bit string obtained by
Droms & Thubert Expires August 6, 2004 [Page 7]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
appending the received value and the MR CareOf Address. TLMRs use
a 'previous value' of zeroes to initially set the pathCRC.
Tree TLMR Identifier
IPv6 global address, set by the TLMR. Identifier of the tree.
Tree Group
IPv6 global address, set by the TLMR. Identifier of the tree
group. A MR may use the Tree Group in its tree selection
algorithm.
The AR MUST include this option in its Router Advertisements, placing
itself as TLMR.
A MR receiving this option from its Attachment Router MUST update the
TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST
propagate it on its ingress interface(s), as described in [9].
The alignment requirement of the Tree Information option is 8n.
4. Security Considerations
This document describes the use of DHCPv6 for prefix delegation in
mobile networks. It does not introduce any additional security
considerations beyond those described in the "Security
Considerations" section of the DHCPv6 base specification [2] and the
"Security Considerations" of the DHCPv6 Prefix Delegation
specification [4].
Following the DHCPv6 Prefix Delegation specification, HAs and MRs
SHOULD use DHCPv6 authentication as described in section
"Authentication of DHCP messages" of the DHCPv6 specification [2], to
guard against attacks mounted through prefix delegation.
5. IANA Considerations
This document describes the use of DHCPv6 for prefix delegation in
mobile networks. It does not introduce any additional IANA
considerations.
6. Terms of Use
Cisco has a pending patent which relates to the subject matter of
this Internet Draft. If a standard relating to this subject matter is
adopted by IETF and any claims of any issued Cisco patents are
necessary for practicing this standard, any party will be able to
Droms & Thubert Expires August 6, 2004 [Page 8]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
obtain a license from Cisco to use any such patent claims under
openly specified, reasonable, non-discriminatory terms to implement
and fully comply with the standard.
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December
2003.
[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
2003.
[6] Devarapalli, V., "Nemo Basic Support Protocol",
draft-ietf-nemo-basic-support-02 (work in progress), December
2003.
[7] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-01 (work in progress), May 2003.
[8] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-00 (work in progress), May 2003.
[9] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-02 (work in
progress), June 2003.
[10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mobileip-hmipv6-08 (work in progress), July 2003.
[11] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad
Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in
progress), April 2003.
[12] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance
Droms & Thubert Expires August 6, 2004 [Page 9]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
Vector (AODV) Routing", draft-ietf-manet-aodv-13 (work in
progress), February 2003.
[13] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Authors' Addresses
Ralph Droms
Cisco
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Phone: +1 978.936.1674
EMail: rdroms@cisco.com
Pascal Thubert
Cisco
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.com
Appendix A. Changes since version 00
The section on access prefix delegation was added. That section
provides a mechanism that is very close to HMIP but purely based on
standard DHCP-PD. It is limited to Nemo applications, but it provides
additional features, including the privacy of the mobile access
router.
Droms & Thubert Expires August 6, 2004 [Page 10]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Droms & Thubert Expires August 6, 2004 [Page 11]
Internet-Draft DHCPv6 Prefix Delegation for NEMO February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Droms & Thubert Expires August 6, 2004 [Page 12]