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

Versions: 00

2000-07-14 13:33           New Option Review     Carney           Page    1


Network Working Group                                     Michael Carney
Dynamic Host Configuration Working Group           Sun Microsystems, Inc
Category: Standards Track                                      July 2000
INTERNET-DRAFT                                   Expires:   January 2001


                    New Option Review Guidelines for DHCP
                   <draft-ietf-dhc-new-opt-review-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.

     Comments regarding this draft should be sent to dhcp-v4@bucknell.edu

Abstract

     This document outlines deficiencies that have become evident since
     RFC 2131 and RFC 2132 were published regarding the allocation of
     new option codes, the review of drafts covering these new option
     codes, and the availability of option codes for new parameters. The
     document then presents proposals for correcting these deficiencies.

1. Introduction

     The rapid and wide-spread adoption of DHCP for IPv4 has lead to an
     increasing number of new DHCP option and message type drafts under
     DHC WG review.  Experience with the current IANA option code
     allocation process and the DHC WG draft review process has
     identified a number of deficiencies, namely:

      * We're rapidly going through the remaining option codes, and face
        the possibility of exhausting the remaining codes before the
        wide-spread adoption of IPv6 is achieved.

2000-07-14 13:33           New Option Review     Carney           Page    2



      * There are no guidelines to help the DHC WG and the DHCP
        community at large gauge the impact of the addition of new
        message types and options. Some message types and options that
        have been proposed require changes to the DHCP protocol itself
        and/or current implementations. Because the adoption of such
        message types or options has a greater impact on the DHCP
        community, these message types and options require more
        scrutiny by the DHC WG and IESG.

      * Because some options or message types could change the DHCP
        protocol itself, we need a method of explicitly communicating
        the change of DHCP versions among implementations. Today, we
        have no such method.

      * There is no provision to preserve compatibility with earlier
        versions of the protocol.

     Inter-operability testing at Connectathon (1997-2000) has shown a
     reduction in the level of interoperability between
     implementations. These interoperability problems were found to
     be due to confusion among implementors about how certain features
     of the protocol should be implemented. Improvement (tightening)
     of the general RFC 2131 and RFC 2132 drafts as well as the
     tightening of new option drafts (using the guidelines defined in
     this document) will help prevent these interoperability problems
     from occurring as new implementations appear.

     The specification of a RFC 2132-form option to carry the DHCP
     protocol version and a proposal for a new, larger option namespace
     is discussed in a companion document, "A New Option Namespace for
     DHCP" [8].

1.1 Conventions Used in the Document

     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 RFC 2119 [5].

2. Review Guidelines

     We tackle the message type and option code review problem by
     defining a set of categories based upon the impact the adoption
     of an option or new message type will have on the DHCP community.
     Option or new message drafts appropriately categorized aid
     reviewers by helping them evaluate the draft. Once the DHC WG
     and the draft author(s) agree on the category of the proposed
     option or message type, that category will be listed explicitly
     in the abstract of the option or message draft.

2000-07-14 13:33           New Option Review     Carney           Page    3



2.1. Hints for selecting the correct review category

     Read the following hints and select the one which best describes
     your option or message type, then proceed to Table 1 at the end of
     this section for the suggested option review category. If, after
     reading the following hints, you cannot find one that fits your
     option or message type, read each of the category sections (2.2-2.5)
     carefully. If you still are not sure which category your option
     or message type belongs in, you can ask the DHC WG (if it still
     exists) or the IESG for help in selecting the right category.

        A) This option has no relationship to other existing or proposed
           options. It would not require change of existing DHCP client,
           server, or BOOTP relay agent implementations. It would not
           change the version of the DHCP protocol. Its introduction
           would not invalidate previous version(s) of the DHCP
           protocol. The proposed option provides data which is
           non-implementation specific and unrelated to network
           configuration.

        B) This message type has no relationship to other existing or
           proposed message types. It would not require change of
           existing DHCP client, server, or BOOTP relay agent
           implementations. It would not change the version of the DHCP
           protocol. The message type is useful to the DHCP community at
           large.

        C) This option has no relationship to other existing or
           proposed options or message types. It would not require
           change of existing DHCP client, server, or BOOTP relay
           agent implementations. It would not change the version of the
           DHCP protocol. Its introduction would not invalidate previous
           version(s) of the DHCP protocol [8]. The information it carries
           is network or system configuration related, but only for a
           particular implementation or set of implementations from the
           same vendor.

        D) This option has no relationship to other existing or
           proposed options or message types. It would not require change
           of existing DHCP client, server, or BOOTP relay agent
           implementations. It would not change the version of the DHCP
           protocol. Its introduction would not invalidate previous
           version(s) of the DHCP protocol [8]. It carries network or
           system configuration data with is of general usefulness.

        E) This option would have a implicit or explicit relationship
           between it and other existing options or other proposed
           options. It MAY change the behavior of existing DHCP client,
           server, and/or BOOTP relay agent implementations. It would
           not change the DHCP protocol version. Its introduction would
           not invalidate previous version(s) of the DHCP protocol [8].

2000-07-14 13:33           New Option Review     Carney           Page    4


           Examples of implicit/explicit option relationships:

           Option                         Related Options
           ------                         ---------------
           Vendor Class Identifier        Encapsulated vendor option(s)
           User Class Identifier          Standard option's scope

        F) This message type would have a implicit or explicit
           relationship between it and other existing message types or
           options. Its adoption MAY change the behavior of existing DHCP
           client, server, and/or BOOTP relay agent implementations. It
           would not change the DHCP protocol version. Its introduction
           would not invalidate previous version(s) of the DHCP
           protocol [8].

        G) The addition of this option would change Table 3, "Fields and
           options used by DHCP servers" and/or Table 5, "Fields and
           options used by DHCP clients" in RFC 2131 [1], and thus
           change the DHCP protocol. Pre-existing versions /
           implementations would continue to interoperate.

        H) The addition of this option or message type would invalidate
           previous versions of the DHCP protocol [8], preventing client,
           server, and/or BOOTP relay agents implementing the earlier
           version(s) from functioning.


                   Table 1: Linking Hints to Review Category

     Guidelines              Review Category
     ----------              ---------------
         A                   None. Use SLP or an other alternative to
                             to register and deliver your information.

         B                   Category One

         C                   None. Use your Vendor-specific
                             option space for your option.

         D                   Category One

         E                   Category Two

         F                   Category Two

         G                   Category Three

         H                   Category Four

2000-07-14 13:33           New Option Review     Carney           Page    5



2.2. Category One

     Options in this category MUST NOT require changes to the DHCP
     protocol, server, client, or BOOTP relay agent implementations.
     They MUST NOT be dependent on other options being present or
     absent. Earlier versions/implementations of the protocol continue
     to interoperate in the presence of these options. Administrative
     tools and DHCP protocol debugging tools which generically support
     the default option types MAY need to be reconfigured in order to
     permit management of the new option. Options of this type are
     "payload" options, and MUST be of one of the default option types
     for the option block form (RFC 2132 or RFC TBD_NS [8]).

     Acceptance criteria:

          Working group/IETF community review:                   Yes.
          IANA option number registration:                       Yes.
          Inter-operability testing (2 or more implementations)  No.
          DHCP protocol version change [8]:                      No.

2.3. Category Two

     Options in this category MUST NOT require changes to the DHCP
     protocol. They MAY require changes to server, client, relay agent
     implementations, administrative tools, and DHCP protocol debugging
     tools. They MAY depend on the presence or absence of other options,
     as long as those other options are NOT in Table 3 or Table 5 of
     RFC 2131 [1]. Any dependence on other options MUST be made
     explicit in the new options draft. Existing versions /
     implementations of the protocol continue to interoperate in the
     presence of messages containing category two options. Options of
     this type are "affect implementation" options.

     An option MUST be designed in such a way as a reply/response from
     non-compliant implementations can be easily distinguished from
     those of compliant implementations. An option MUST NEVER change the
     interpretation of existing options. The option draft author MUST
     specify a compliant implementation's behavior if that implement-
     ation receives a reply/response from a non-compliant implementation.

     Acceptance criteria:

          Working group/IETF community review:                  Yes.
          IANA option number registration:                      Yes.
          Inter-operability testing (2 or more implementations) Yes.
          DHCP protocol version change [8]:                     No.

2000-07-14 13:33           New Option Review     Carney           Page    6



2.4. Category Three

     Options in this category EXPLICITLY change the DHCP protocol. They
     WILL require changes to server, client, and/or relay agent
     implementations. They MAY depend on the presence or absence of
     other options. Any dependence on other options MUST be made
     explicit in the new option draft. The addition of such options
     result in changes to Table 3, "Fields and options used by DHCP
     servers" and/or Table 5, "Fields and options used by DHCP clients"
     in RFC 2131 [1]. Existing versions / implementations of the
     protocol continue to interoperate in the presence of traffic
     containing category three options. Administrative tools MUST be
     changed to support options of this type. DHCP protocol debugging
     tools would need to be updated to recognize these options. Options
     of this type are known as "affect protocol" options. The acceptance
     of a Category Three option results in incrementing the DHCP version
     option value (see a companion document, "A New Option Namespace
     for DHCP" for details on the DHCP version option [8].

     An option MUST be designed in such a way as a reply/response from
     non-compliant implementations can be easily distinguished from
     those of compliant implementations. The option draft author MUST
     specify a compliant implementation's behavior if that implement-
     ation receives a reply/response from a non-compliant
     implementation. An option MUST NEVER change the interpretation of
     existing options. Category Three option implementations can easily
     detect a non-compliant implementation due to the absence of the
     DHCP version option or a lower than expected version number [8].

     Acceptance criteria:

          Working group/IETF community review:                  Yes.
          IANA option number registration:                      Yes.
          Inter-operability testing (2 or more implementations) Yes.
          DHCP protocol version change [8]:                     Yes.

2.5. Category Four

     Options in this category would EXPLICITLY change the DHCP
     protocol in a non-backward compatible manner. They would require
     changes to ALL DHCP client, server, and/or BOOTP relay agent
     implementations. They INVALIDATE one or more of the previous
     versions of the BOOTP/DHCP protocol.

     Because category four options invalidate previous versions of the
     protocol, they are NOT candidates for acceptance. Changes to the
     the DHCP protocol MUST BE backward compatible.

     Acceptance criteria:

          Working group/IETF community review:                   N/A.
          IANA option number registration:                       N/A.
          Inter-operability testing (2 or more implementations)  N/A.
          DHCP protocol version change [8]:                      N/A.
2000-07-14 13:33           New Option Review     Carney           Page    7



3. Security Considerations

     Not Applicable.

4. Acknowledgements

     The author would like to gratefully acknowledge the active
     participation of the following DHCP future panel members:
     Ralph Droms, Kester Fong, Pratik Gupta, Barr Hibbs, Kim Kinnear,
     Ted Lemon, Nathan Lane, and Glenn Waters. The author would also
     like to thank Thomas Narten and Bernie Volz for their review
     comments.

5. Copyright

   Copyright (C) The Internet Society (2000).  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.

6. References

     [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
     Bucknell University, March 1997.
     <ftp://ds.internic.net/rfc/rfc2131.txt>

     [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP
     Vendor Extension", RFC 2132, March 1997.
     <ftp://ds.internic.net/rfc/rfc2132.txt>

2000-07-14 13:33           New Option Review     Carney           Page    8



     [3] Prindeville, P. "BOOTP Vendor Information Extensions", RFC 1048,
     McGill University, February 1988.
     <ftp://ds.internic.net/rfc/rfc1048.txt>

     [4] Droms, R. "Procedure for Defining New DHCP Options",
     INTERNET-DRAFT, August 1998
  <ftp://www.ietf.org/internet-drafts/draft-ietf-dhc-new-options-02.txt>

     [5] Bradner, "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, Harvard University, March 1997.
     <ftp://ds.internic.net/rfc/rfc2119.txt>

     [6] Hinden R. and Deering, S., "IP Version 6 Addressing
     Architecture", RFC 2373, Nokia and Cisco Systems, July 1998.
     <ftp://ds.internic.net/rfc/rfc2373.txt>

     [7] Guttman E.,  Perkins C., Veizades J., and Day M., "Service
     Location Protocol, Version 2", April 1999.
<ftp://www.ietf.org/internet-drafts/draft-ietf-svrloc-protocol-v2-16.txt>

     [8] Carney, M., "A New Option Namespace for DHCP", RFC TBD_NS,
     July 2000. <ftp://ds.internic.net/rfc/rfcTBD_NS>

7. Author's Address

     Michael Carney
     Sun Microsystems, Inc.
     901 San Antonio Road
     Palo Alto, CA 94303-4900

     Phone: (650) 786-4171
     Fax: (650) 786-5896
     Email: Michael.Carney@sun.com

8. Expiration

     This document will expire on January 31, 2001.


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