IPv6 Group R. Droms
Internet-Draft P. Thubert
Intended status: Informational Cisco
Expires: June 8, 2008 December 6, 2007
DHCPv6 Prefix Delegation for NEMO
draft-ietf-nemo-dhcpv6-pd-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 June 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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.
Droms & Thubert Expires June 8, 2008 [Page 1]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
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 [RFC3633] (DHCPv6PD) can be used
for this configuration task.
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 [RFC2119].
The following terms used in this document are defined in the IPv6
Addressing Architecture document [RFC3513]:
link-local unicast address
link-local scope multicast address
The following terms used in this document are defined in the mobile
IPv6 specification [RFC3775]:
home agent (HA)
home link
The following terms used in this document are defined in the Mobile
Network terminology document [I-D.ietf-nemo-terminology]:
Mobile Router (MR)
Mobile Network
mobile host (MH)
The following terms used in this document are defined in the DHCPv6
[RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications:
delegating router (DR)
requesting router (RR)
DHCPv6 relay agent
3. Application of DHCPv6 prefix delegation to mobile networks for
delegation of home prefixes
The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol
[RFC3775] to enable network mobility. In this extension, 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.
The requirements for NEMO [I-D.ietf-nemo-requirements] include the
Droms & Thubert Expires June 8, 2008 [Page 2]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
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.
To use DHCPv6PD for Mobile Networks, the HA assumes the role of
either the DR or a DHCPv6 relay agent 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 or relay agent and the MR will
be assumed to be acting as a RR.
If the HA is acts as relay agent, some other device acts as the DR.
For example, the server providing DHCPv6 service in the home network
might also provide NEMO DHCPv6PD service. Or, a home network with
several HAs might configure one of those HAs as a DHCPv6PD server
while the other HAs act as relay agents.
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 DHCPv6PD server 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 [RFC3963], 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. When the MR uses DHCPv6
The MR initiates a DHCPv6 message exchange for prefix delegation
whenever it establishes an MRHA tunnel to its HA. If the MR does not
have any active delegated prefixes (with unexpired leases), the MR
initiates a DHCPv6 message exchange with a DHCPv6 Solicit message as
described in section 17 of RFC 3315 and section 12 of RFC 3633. If
the MR has one or more active delegated prefixes, the MR initiates a
DHCPv6 message exchange with a DHCPv6 Confirm message as described in
section 18.1.2 of RFC 3315 and section 12 of RFC 3633.
3.2. Use of MRHA 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:
Droms & Thubert Expires June 8, 2008 [Page 3]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
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.
Even though the MRHA tunnel is a point to point connection, the MR
SHOULD use multicast DHCPv6 messages as described in RFC 3315 over
that tunnel.
3.3. Exchanging DHCPv6 messages when MR is at home
When the MR is on its home link, the HA uses the home link to
exchange DHCPv6PD messages with the MR. It is the responsibility of
the implementation to determine when the MR is on its home link and
to avoid use of any existing tunnel.
3.4. Minimizing DHCPv6PD messages
DHCPv6PD in a Mobile Network can be combined with the Rapid Commit
option [RFC3315] to provide DHCPv6 prefix delegation with a two
message exchange between the mobile node and the DHCPv6 PD server.
3.5. DHCPv6PD and DHAAD
The MR acting as RR needs a direct link to the DR (or relay)
function. When the MR is away from Home, that link is the MRHA
tunnel. If a MR needs to obtain a prefix by means of DHCPv6PD, it
has to locate a HA that is capable of serving either as a DHCPv6PD
relay agent or server. Since the use of DHCPv6PD is optional and
comes as an addition to existing protocols [RFC 3775] and [RFC 3963],
it can not be expected that all HAs are DHCPv6PD capable.
This specification extends Dynamic Home Agent Address Discovery and
the Home Agent Information Option in order to enable the detection by
a MR of all HAs that are DHCPv6PD capable. A new 'D' bit is
introduced to let Home Agents advertise that they are willing to
participate to DHCP. Note that there is no need for the MR acting as
RR to know whether a HA is actually a DR or simply acting as a relay.
3.5.1. Modified Dynamic Home Agent Address Discovery Request
A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
Request message, defined in [RFC3775] and [RFC 3963]. The Mobile
Router sets this flag to indicate that it wants to discover Home
Agents participating to DHCPv6 Prefix Delegation.
Droms & Thubert Expires June 8, 2008 [Page 4]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
A the MR which sets the 'D' flag MUST also set the 'R' flag, to
declare that it is a Mobile Router and asks for a HA that supports
Mobile Routers, as defined in [RFC 3963].
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6PD Support Flag (D)
A one-bit flag that when set indicates that the Mobile Router
wants to discover Home Agents participating to DHCPv6 Prefix
Delegation.
For a description of the other fields in the message, see [RFC3775]
and [RFC 3963].
3.5.2. Modified Dynamic Home Agent Address Discovery Reply
A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
Reply message, defined in [RFC3775] and [RFC 3963]. If a Home Agent
receives a Dynamic Home Agent Discovery request message with the
DHCPv6PD Support Flag set, it MUST reply with a list of Home Agents
participating to DHCPv6PD.
The DHCPv6PD Support Flag MUST be set if there is at least one Home
Agent participating to DHCPv6PD. In that case, the reply will list
only those HAs that participate to DHCPv6PD, whether they act as
servers (DRs) or relays.
A HA that supports DHCPv6PD MUST support Mobile Routers as well, so
if the 'D' bit is set, then the 'R' bit should be set as well. So
there is no need in an implementation to support the case where some
HAs would support Mobile Routers while others would be participating
to DHCPv6 Prefix Delegation but none could do both.
If none of the Home Agents support DHCPv6PD, the Home Agent MAY reply
with a list of Home Agents that only support NEMO basic Mobile
Routers or Mobile IPv6 Mobile Nodes. In this case, the DHCPv6PD
Support Flag MUST be set to 0.
The modified message format is as follows.
Droms & Thubert Expires June 8, 2008 [Page 5]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6PD Support Flag (D)
A one-bit flag that when set indicates that the Home Agents
listed in this message participate to DHCPv6 Prefix Delegation.
For a description of the other fields in the message, see [RFC3775]
and [RFC 3963].
3.5.3. Modified Home Agent Information Option
A new flag (D) (Support for DHCPv6PD) is introduced in the Home Agent
Information Option defined in [RFC3775] and [RFC 3963].
If a Home Agent participates to DHCPv6PD, it SHOULD set the flag. If
the HA sets the 'D' flag, then it MUST also set the 'R' flag,
Indicating that it supports Mobile Routers, as defined in [RFC 3963].
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 |R|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DHCPv6PD Support Flag (D)
A one-bit flag that when set indicates that the Home Agents
participates to DHCPv6 Prefix Delegation.
For a description of the other fields in the message, see [RFC3775]
and [RFC 3963].
Droms & Thubert Expires June 8, 2008 [Page 6]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
3.6. Location of DHCPv6PD Delegating Router function
Support of DHCPv6PD for a Mobile Network is optional.
The use of a DHCPv6 relay agent is not defined for DHCPv6PD in the
DHCPv6PD specification [RFC3633]. If the DHCPv6PD DR function is
implemented in the HA for the MR, no relay agent function is
required.
It may be desirable to use a single DR to manage RRs in a network
with multiple HAs. In this scenario, the HAs will act as DHCP relay
agents, forwarding messages between the RRs and the DR.
Use of the DHCPv6 relay agent function with DHCPv6PD requires that
there be some mechanism through which routing information for the
delegated prefixes can be added to the appropriate routing
infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA
SHOULD add a route to the delegated prefix and advertise that route
after receiving a binding update for the prefix from the RR
[RFC3963].
In particular, if the MR uses NEMO explicit mode, then it must add
the delegated prefix to prefix list in the Binding Update messages.
If the binding cache is cleared before the prefix valid lifetime, the
MR might bind that prefix again using explicit mode, till the
lifetime expires.
In implicit mode, the HA must save the delegated prefix with the
binding cache entry of the Mobile Router. When the BCE is cleared,
the HA loses the information about the delegated prefix. Because the
MR will use DHCPv6 when it reestablishes its tunnel to the HA (see
Section 3.1), the HA will be able to add the delegated prefix back to
the BCE.
At the time this draft was written, one way in which a DR can
explicitly notify a relay agent about delegated prefixes, is to use
the "DHCP Relay Agent Assignment Notification Option"
[I-D.ietf-dhc-dhcpv6-agentopt-delegate].
Another alternative, if the RR is part of the same administrative
domain as the home network to which it is attached through the HA,
and the RR can be trusted, the RR can use a routing protocol like
OSPF to advertise any delegated prefixes.
NEMO explicit mode is recommended to take advantage of the function
already defined for NEMO.
Droms & Thubert Expires June 8, 2008 [Page 7]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
3.7. 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.
4. Changes in this draft
4.1. Revision -01
Removed section 3.2, "Delegating Access Prefixes".
Modified sections 3 and 3.6 (was section 3.1.3), "Location of
DHCPv6PD Delegating Router function," to allow for DHCPv6PD through a
relay agent and to allow for a single DR on a home network to perform
PD for RRs through more than one HA.
Added section 3.1 describing when the MR should use DHCPv6 PD.
Added section 3.4 describing use of Rapid Commit to minimize DHCPv6PD
messages and
Added section 3.5 recommending that DHCPv6PD and DHAAD be kept
independent and describing flags indicating availability of PD
service from HA.
Added section 3.7 describing the use of DHCPv6 for other
configuration in parallel with PD.
5. 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 [RFC3315]
and the "Security Considerations" of the DHCPv6 Prefix Delegation
specification [RFC3633].
Following the DHCPv6 Prefix Delegation specification, HAs and MRs
SHOULD use DHCPv6 authentication as described in section
Droms & Thubert Expires June 8, 2008 [Page 8]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
"Authentication of DHCP messages" of the DHCPv6 specification
[RFC3315], to guard against attacks mounted through prefix
delegation.
6. IANA Considerations
This document describes the use of DHCPv6 for prefix delegation in
Mobile Networks. It does not introduce any additional IANA
considerations.
7. Normative References
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-nemo-terminology]
Ernst, T. and H. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-06 (work in
progress), November 2006.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[I-D.ietf-nemo-requirements]
Ernst, T., "Network Mobility Support Goals and
Requirements", draft-ietf-nemo-requirements-06 (work in
progress), November 2006.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[I-D.ietf-dhc-dhcpv6-agentopt-delegate]
Droms, R., "DHCPv6 Relay Agent Assignment Notification
(RAAN) Option", draft-ietf-dhc-dhcpv6-agentopt-delegate-02
Droms & Thubert Expires June 8, 2008 [Page 9]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
(work in progress), November 2006.
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
Droms & Thubert Expires June 8, 2008 [Page 10]
Internet-Draft DHCPv6 Prefix Delegation for NEMO December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Droms & Thubert Expires June 8, 2008 [Page 11]
