Network Working Group R. Droms
Internet-Draft Cisco Systems
Expires: April 27, 2003 October 27, 2002
Issues Concerning DHCP in IPv6 Specifications
draft-droms-dhcpv6-issues-00.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 April 27, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
There are several issues related to DHCPv6 in various IPv6 documents
that require clarification or resolution. The v6ops working group
discussed these issues at an interim meeting in August, 2002. This
document presents those issues and summarizes the v6ops working group
discussion.
1. Introduction
There are several issues related to DHCPv6 in various IPv6 documents
that require clarification or resolution. The v6ops working group
discussed these issues at an interim meeting in August, 2002. This
document presents those issues and summarizes the v6ops working group
Droms Expires April 27, 2003 [Page 1]
Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002
discussion.
2. Terminology
This document uses IPv6 terminology from "The IPv6 Protocol" (RFC
2460 [1]), "IPv6 Addressing Architecture "(RFC 2373 [2]), and "IPv6
Stateless Address Autoconfiguration" (RFC 2462 [3]). This document
also uses the DHCP terminology from "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)" [4].
3. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [5].
4. Operational issues concerning DHCPv6
This section presents the issues discussed at the v6ops working group
interim meeting and a summary of the discussion of each issue.
Except as noted, the v6ops working group suggested that these issues
should be referred to the ipv6 working group for further discussion.
4.1 "Stateful autoconfiguration" == DHCPv6?
Issue: IPv6 documents refer loosely to "stateful autoconfiguration"
(SAC) as an alternative to "stateless address autoconfiguration" [3]
(SLAAC). Does this reference require clarification; e.g., should
DHCP be cited as the mechanism to use for "stateful
autoconfiguration"?
Discussion: The consensus was that references to "stateful
autoconfiguration" should be clarified to DHCP.
4.2 'M', 'O' and 'A' bits
Issue: The interaction of 'M', 'O' and 'A' bits with SLAAC and SAC
may not be clear [6][3]. Summary of bits:
1. 'A' bit set in the prefix advertisement causes hosts to perform
SLAAC on the prefix, independent of the 'M' and 'O' bits in the
router advertisement (RA).
2. 'M' bit set in the prefix advertisement causes SAC for address
assignment (and implies 'O' bit), independent of SLAAC; 'M' bit
not set gives no guidance on use of DHCP.
3. 'O' bit set in RA causes SAC for other configuration (not address
Droms Expires April 27, 2003 [Page 2]
Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002
assignment); 'O' bit not set gives not guidance on use of DHCP.
As an example of the use of these bits, a network administrator can
restrict hosts to use of SAC for address assignment (disallowing
SLAAC) by setting the 'M' bit in RAs and not setting the 'A' bit in
any prefix advertisements.
Discussion: Some relevant text from section 4 of RFC 2462 may clarify
points 2 and 3:
A "managed address configuration" flag indicates whether hosts
should use stateful autoconfiguration to obtain addresses. An
"other stateful configuration" flag indicates whether hosts should
use stateful autoconfiguration to obtain additional information
(excluding addresses).
This text can be interpreted to mean that if the 'M' bit and 'O' bit
are not set, the host does not use SAC.
The consensus was that this issue could use some additional
clarification.
4.3 Requirement for DHCP
Issue: Does the requirement for SAC, as controlled by the 'M' and 'O'
bits, imply that an IPv6 implementation MUST include DHCP?
Discussion: There was no clear consensus. During the discussion,
doubt about the utility of the 'M' and 'O' bits was raised, now that
DHCP and the reserved address for DNS resolvers mechanism has been
defined. If the 'O' bit is set, is it useful to preclude use of the
reserved resolver addresses if the host doesn't receive a response
from a DHCP server?
4.4 SLAAC and DHCP address assignment from the same prefix
Issue: Is use of SLAAC and DHCP address assignment from the same
prefix OK?
Discussion: DAD should prevent conflict between SLAAC and DHCP
addresses. See following section for discussion of inconsistency
between RA prefix lifetimes and DHCP address lifetimes.
4.5 Inconsistencies between SLAAC and DHCP
Issue: Is the description of what to do when SLAAC and DHCP provide
inconsistent information - e.g., prefix/address lifetimes -
sufficiently clear?
Droms Expires April 27, 2003 [Page 3]
Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002
Discussion: Section 6.3.4 of RFC 2461 includes the following text:
When multiple routers are present, the information advertised
collectively by all routers may be a superset of the information
contained in a single Router Advertisement. Moreover, information
may also be obtained through other dynamic means, such as stateful
autoconfiguration. Hosts accept the union of all received
information; the receipt of a Router Advertisement MUST NOT
invalidate all information received in a previous advertisement or
from another source. However, when received information for a
specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a
specific Prefix) differs from information received earlier, and
the parameter/option can only have one value, the most recently-
received information is considered authoritative.
However, this test doesn't clarify, for example, whether a preferred
lifetime on a prefix as obtained from a prefix advertisement
overrides the preferred lifetime on an address assigned through DHCP
4.6 Reserved interface identifiers
Issue: Should there be an explicit recommendation in the DHCPv6
specification against assigning addresses through DHCP that use any
reserved interface identifiers?
Discussion: Yes.
5. Security considerations
This document has no references to security issues.
6. Acknowledgments
This document is based on the discussion of of DHCPv6 issues at the
v6ops working group interim meeting of August, 2002. Thanks to Bob
Fink for compiling the minutes from that meeting, and to Bob Hinden,
Bernie Volz and Margaret Wasserman for their review and input.
References
[1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
Droms Expires April 27, 2003 [Page 4]
Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002
[4] Droms, R., Perkins, C., Bound, J., Volz, B., Carney, M. and T.
Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
draft-ietf-dhc-dhcpv6-27 (work in progress), October 2002.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
Author's Address
Ralph Droms
Cisco Systems
300 Apollo Drive
Chelmsford, MA 01824
USA
Phone: +1 978 497 4733
EMail: rdroms@cisco.com
Droms Expires April 27, 2003 [Page 5]
Internet-Draft Issues Concerning DHCP in IPv6 Specifications October 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Droms Expires April 27, 2003 [Page 6]