[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/