idnits 2.17.1 draft-ietf-dhc-nsso-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 78 has weird spacing: '...for the name...' == Line 79 has weird spacing: '...s (the earli...' == Line 103 has weird spacing: '...of 0 is used ...' == Line 104 has weird spacing: '... client shou...' == Line 107 has weird spacing: '... client shoul...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2001) is 8495 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Smith 2 Internet Draft Sun Microsystems, Inc. 3 July 2000 4 Expires January 2001 6 The Name Service Search Option for DHCP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To view the entire list of current Internet-Drafts, please check the 29 1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), 32 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document defines a new DHCP option which is passed from the DHCP 37 Server to the DHCP Client to specify the order in which name services 38 should be consulted when resolving hostnames and other information. 40 Introduction 42 The Dynamic Host Configuration Protocol (DHCP)[1] provides a 43 framework for passing configuration information to hosts on a TCP/IP 44 network. RFC 2132 [2] allows DHCP servers to specify configuration 45 information for various kinds of name services to be passed to DHCP 46 clients. Many clients use multiple name services and have crafted 47 their own conventions that allow an individual host to express the 48 order among the various name services with which lookups are done. 49 However, no search order can be specified via DHCP. The purpose of 50 this document is to allow DHCP servers to specify the search order to 51 be used by DHCP clients. To avoid the need for inventing and 52 maintaining a separate name space for this option, we rely on the 53 existence of previously-defined DHCP options that specify the IP 54 address(es) of servers which provide name services whose order we 55 wish to express. 57 Definitions 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [3]. This 62 document also uses the following terms: 64 "DHCP client" 66 DHCP client or "client" is an Internet host using DHCP to 67 obtain configuration parameters such as a network address. 69 "DHCP server" 71 A DHCP server or "server" is an Internet host that returns 72 configuration parameters to DHCP clients. 74 Name Service Search Option Format 76 The code for this option is TBD, and its minimum length is 2 bytes. 77 A DHCP server SHOULD return, in its preferred order, the 16-bit, 78 network byte order (big-endian [4]) integer option code for the name 79 services (the earlier in the list, the more preferred the name 80 service). 82 Code Length Name Service Search Order in Sequence 83 0 1 2 3 84 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 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 | TBD | Len | ns1 | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | ns2 | ... | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 In the above diagram, ns1 and ns2 are 16-bit integers corresponding 92 to two DHCP options which specify the IP addresses of two different 93 types of name server. The current list of name services and their 94 DHCP option codes, taken from RFC 2132, includes 96 Name Service Value 98 Domain Name Server Option 6 99 Network Information Servers Option 41 100 NetBIOS over TCP/IP Name Server Option 44 101 Network Information Service+ Servers Option 65 103 A name service option code of 0 is used to indicate that the 104 client should refer to local naming information (e.g. an 105 /etc/hosts file on a UNIX machine). 107 A DHCP server wishing to express that a client should first search 108 DNS, then NIS+, would send 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | TBD | 4 | 6 | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | 65 | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 DHCP Client Behavior 120 The DHCP client will use this option to create a search list for name 121 resolution. The client may receive name services in this option that 122 it does not support or has not been configured to access. Likewise, 123 a client may receive an option that lists name services for which no 124 corresponding DHCP option was supplied. Clients will interpret this 125 option in a system-specific manner whose specification is outside the 126 scope of this document. 128 Security Considerations 130 DHCP currently provides no authentication or security mechanisms. 131 Potential exposures to attack are discussed in section 7 of the DHCP 132 protocol specification [1]. 134 IANA Considerations 136 IANA has assigned a value of TBD for the DHCP option code described 137 in this document. 139 References 141 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 142 1997. 143 [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 144 Extensions", RFC 2132, March 1997. 145 [3] Bradner, S., "Key words for use in RFCs to indicate requirement 146 levels", RFC 2119, March 1997. 147 [4] Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, 148 October 1981. 150 Author Information 152 Carl Smith 153 Sun Microsystems, Inc. 154 901 San Antonio Road 155 Palo Alto, CA 94043 156 email: cs@Eng.Sun.COM 158 Expiration 160 This document will expire on January 15, 2001. 162 Full Copyright Statement 164 Copyright (C) The Internet Society (1999). All Rights Reserved. 166 This document and translations of it may be copied and furnished to 167 others, and derivative works that comment on or otherwise explain it 168 or assist in its implementation may be prepared, copied, published 169 and distributed, in whole or in part, without restriction of any 170 kind, provided that the above copyright notice and this paragraph are 171 included on all such copies and derivative works. However, this 172 document itself may not be modified in any way, such as by removing 173 the copyright notice or references to the Internet Society or other 174 Internet organizations, except as needed for the purpose of 175 developing Internet standards in which case the procedures for 176 copyrights defined in the Internet Standards process must be 177 followed, or as required to translate it into languages other than 178 English. 180 The limited permissions granted above are perpetual and will not be 181 revoked by the Internet Society or its successors or assigns. 183 This document and the information contained herein is provided on an 184 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 185 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 186 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 187 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 188 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.