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

Versions: 00 01 02 03 04 05 RFC 2937

Network Working Group                                         C. Smith
Internet Draft                                  Sun Microsystems, Inc.
                                                             July 2000
                                                 Expires  January 2001


                The Name Service Search Option for DHCP
                      <draft-ietf-dhc-nsso-05.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.



   To view the entire list of current Internet-Drafts, please check the
   1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   This document defines a new DHCP option which is passed from the DHCP
   Server to the DHCP Client to specify the order in which name services
   should be consulted when resolving hostnames and other information.

Introduction

   The Dynamic Host Configuration Protocol (DHCP)[1] provides a
   framework for passing configuration information to hosts on a TCP/IP
   network. RFC 2132 [2] allows DHCP servers to specify configuration
   information for various kinds of name services to be passed to DHCP
   clients.  Many clients use multiple name services and have crafted
   their own conventions that allow an individual host to express the
   order among the various name services with which lookups are done.
   However, no search order can be specified via DHCP.  The purpose of
   this document is to allow DHCP servers to specify the search order to
   be used by DHCP clients.  To avoid the need for inventing and
   maintaining a separate name space for this option, we rely on the



Smith                                                           [Page 1]


RFC DRAFT                                                      July 2000


   existence of previously-defined DHCP options that specify the IP
   address(es) of servers which provide name services whose order we
   wish to express.

Definitions

   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 [3].  This
   document also uses the following terms:

      "DHCP client"

         DHCP client or "client" is an Internet host using DHCP to
         obtain configuration parameters such as a network address.

      "DHCP server"

         A DHCP server or "server" is an Internet host that returns
         configuration parameters to DHCP clients.

Name Service Search Option Format

   The code for this option is TBD, and its minimum length is  2  bytes.
   A  DHCP  server  SHOULD  return,  in its preferred order, the 16-bit,
   network byte order (big-endian [4]) integer option code for the  name
   services  (the  earlier  in  the  list,  the  more preferred the name
   service).

            Code            Length      Name Service Search Order in Sequence
        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TBD       |     Len       |             ns1               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             ns2               |             ...               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the above diagram, ns1 and ns2 are 16-bit integers corresponding
   to two DHCP options which specify the IP addresses of two different
   types of name server.  The current list of name services and their
   DHCP option codes, taken from RFC 2132, includes

       Name Service                                  Value

       Domain Name Server Option                       6
       Network Information Servers Option             41
       NetBIOS over TCP/IP Name Server Option         44



Smith                                                           [Page 2]


RFC DRAFT                                                      July 2000


       Network Information Service+ Servers Option    65


       A name service option code of 0 is  used  to  indicate  that  the
       client   should  refer  to  local  naming  information  (e.g.  an
       /etc/hosts file on a UNIX machine).

   A DHCP server wishing to express that a client  should  first  search
   DNS, then NIS+, would send

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TBD       |      4        |              6                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              65               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCP Client Behavior

   The DHCP client will use this option to create a search list for name
   resolution.  The client may receive name services in this option that
   it does not support or has not been configured to access.  Likewise,
   a client may receive an option that lists name services for which no
   corresponding DHCP option was supplied.  Clients will interpret this
   option in a system-specific manner whose specification is outside the
   scope of this document.

Security Considerations

   DHCP currently provides no authentication or security mechanisms.
   Potential exposures to attack are discussed in section 7 of the DHCP
   protocol specification [1].

IANA Considerations

   IANA has assigned a value of TBD for the DHCP option code described
   in this document.

References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
   1997.
   [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
   Extensions", RFC 2132, March 1997.
   [3] Bradner, S., "Key words for use in RFCs to indicate requirement
   levels", RFC 2119, March 1997.
   [4] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE,



Smith                                                           [Page 3]


RFC DRAFT                                                      July 2000


   October 1981.

Author  Information

   Carl Smith
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94043
   email:  cs@Eng.Sun.COM

Expiration

   This document will expire on January 15, 2001.

Full Copyright Statement

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










Smith                                                           [Page 4]


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