Network Working Group                                           P. Gupta
Internet Draft                                           IBM Corporation
Obsoletes: draft-ietf-dhc-domsrch-00.txt draft-ietf-dhc-domsrch-01.txt                   November 1998
                                                        Expires May 1999

                   The Domain Search Option for DHCP
                    <draft-ietf-dhc-domsrch-01.txt>
                    <draft-ietf-dhc-domsrch-02.txt>

Status of this Memo

   This document is an Internet-Draft.  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".

   To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 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

   The Dynamic Host Configuration Protocol (DHCP)[1] provides a
   framework for passing configuration information to hosts on a TCP/IP
   network.

   This document defines a new DHCP option which is passed form the DHCP
   Server to the DHCP Client to configure the domain search list which
   is used by the clients to resolve hostnames in the Domain Name
   System[3].

Introduction

   The Dynamic Host Configuration Protocol (DHCP)[1] provides a
   framework for passing configuration information to hosts on a TCP/IP
   network. RFC 2132 allows the Domain Name (option 15) and the Domain
   Name Server (option 6) to be passed to the DHCP client. This
   information is used to resolve names in the Domain Name System. These
   options are usually placed in the resolv.conf file on most operating
   systems. The name resolution routines on the client are also capable
   of using a domain search list that allows name resolution to be
   attempted in a number of domains in sequence. The Domain Search
   Option allows a list of domain names, in order of preference, to be
   passed to the DHCP client such that the search directive can be
   specified for name resolution.

Definitions

   Throughout this document, the words that are used to define the
   significance of the particular requirements are capitalized.  These

   The key words are:

      "MUST"

           This word or the adjective "REQUIRED" means that the item is
           an absolute requirement of this specification. "MUST", "MUST NOT"

           This phrase means the item is an absolute prohibition of this
           specification.

      "SHOULD"

           This word or the adjective "RECOMMENDED" means that there may
           exist valid reasons in particular circumstances to ignore
           this item, but the full implications should be understood and
           the case carefully weighed before choosing a different
           course. NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT"

           This phrase means that there may exist valid reasons in
           particular circumstances when the listed behavior is
           acceptable or even useful, but the full implications should
           be understood and the case carefully weighted before
           implementing any behavior described with this label. NOT", "RECOMMENDED", "MAY"

           This word or the adjective and "OPTIONAL" means that in this item is
           truly optional.  One vendor may choose
   document are to include the item
           because a particular marketplace requires it or because it
           enhances the product, for example, another vendor may omit
           the same item. be interpreted as described in RFC 2119 [4].

   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.

Domain Search Option Format

   The code for this option is TBD, and its minimum length is 2 bytes.
   This option can contain multiple domain names separated by the ASCII
   space character.

             Code     Len       Domain Names in Sequence
           +-------+-------+-------+--------+---------+-
           |  TBD  |   n   |  d1   | 0x20   |   d2    |
           +-------+-------+-------+--------+---------+-

   Where

   In the above example, d1 & d2 are domain names specified as NVT ASCII
   strings. An ASCII space character (0x20) is used as a separator
   between the domain names.

DHCP Client Behavior

   The DHCP client will use this option to create a domain search list
   for name resolution. If a DHCP client is given both a Domain Name
   Option and a Domain Search Option, the Domain Search Option  will
   take precedence.

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]. The Domain Search Option can be used to
   misdirect domain name resolution on a client and thus misdirect
   network traffic based on DNS names.

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] Mockapetris, P. V., "Domain names - implementation and
        specification", RFC 1035, November 1987.
   [4] Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

Author Information

Pratik Gupta
IBM Corporation
4205 S.Miami Blvd
Research Triangle Park, NC 27709
Phone: (919)254-5654
email: pratikg@us.ibm.com

Expiration

   This document will expire on May 31, 1999.

Full Copyright Statement

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