idnits 2.17.1 draft-ietf-dhc-options-cont-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 123 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 60: '...on. This option MUST not appear as th...' RFC 2119 keyword, line 61: '...eceding this one MUST have a size of 2...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 70 has weird spacing: '...e Len optio...' == Line 79 has weird spacing: '...e Len optio...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Each option is assigned a one-octet option code and an one-octet size field. The one-octet size field limits the information contained in an option to 256 bytes. While there exist options that permit the use of the sname and file fields of the header, these options only add an additional 192 bytes when the fields are not in use. This document describes a new DHCP option for continuing the information from the previous option. This option MUST not appear as the first option in a message. The option preceding this one MUST have a size of 256 bytes. -- 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 2000) is 8839 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) -- Looks like a reference, but probably isn't: 'TBD' on line 66 == Unused Reference: '2' is defined on line 93, but no explicit reference was found in the text Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group William A. Arbaugh 2 Internet Draft Angelos D. Keromytis 3 Expires in sixth months University of Pennsylvania 4 January 2000 6 DHCP Continuation Option Code 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. 14 Please direct comments to one of the authors (for the authors contact 15 information, see the end of this document), and/or to the 16 trustmgt@east.isi.edu mailing list. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working Groups. Note that 20 other groups may also distribute working documents as Internet 21 Drafts. 23 Internet-Drafts draft documents are valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this memo is unlimited. 36 Abstract 38 The Dynamic Host Configuration Protocol (DHCP) provides a framework 39 for passing configuration information to hosts on a TCP/IP network. 40 Currently options are limited to an information size of 256 bytes 41 because of the one-octet size of the length field. This document 42 defines a new option that permits the continuation of the previous 43 option information. 45 1. Introduction 47 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 48 framework for passing configuration information to hosts on a TCP/IP 49 network. Configuration parameters and other control information are 50 carried in tagged data items that are stored in the 'options' field 51 of the DHCP message. The data items themselves are also called 52 "options." 54 Each option is assigned a one-octet option code and an one-octet size 55 field. The one-octet size field limits the information contained in 56 an option to 256 bytes. While there exist options that permit the use 57 of the sname and file fields of the header, these options only add an 58 additional 192 bytes when the fields are not in use. This document 59 describes a new DHCP option for continuing the information from the 60 previous option. This option MUST not appear as the first option in 61 a message. The option preceding this one MUST have a size of 256 62 bytes. 64 2. Definition of option [TBD] 66 Option code [TBD] indicates that the data contained in the option is 67 a continuation of the previous option. 69 Continuation 70 Code Len option code Data... 71 +-----+-----+-----+-----+-----+-----+-------------- 72 | TBD | XXX | Continuation of previous option data 73 +-----+-----+-----+-----+-----+-----+--------------- 75 The example below shows how the option would work with a hypothetical 76 authentication option that requires more than 255 bytes of information. 78 Auth 79 Code Len option Data... 80 +-----+-----+-----+-----+-----+-----+-------------- 81 | 90 | 256 | 04 | d1 d2 d4 ... d255 82 +-----+-----+-----+-----+-----+-----+--------------- 83 Code Len Data... 84 +-----+-----+-----+-----+-----+-----+-------------- 85 | TBD | 20 | d257 d258 d259 d260 ... d276 86 +-----+-----+-----+-----+-----+-----+--------------- 88 3. References 90 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 91 Bucknell University, March 1997. 93 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 94 Extensions", RFC 2132, Lachman Associates, March 1997. 96 4. Security Considerations 98 DHCP currently provides no authentication or security mechanisms. 99 Potential exposures to attack are discussed in section 7 of the DHCP 100 protocol specification [1]. One of the reasons for this definition is 101 to provide support for the exchange of public key certificates are 102 which usually larger than 256 bytes. 104 5. Authors' Address 106 William A. Arbaugh 107 Angelos D. Keromytis 108 Distributed Systems Lab -- 102 Moore 109 Department of Computer and Information Sciences 110 University of Pennsylvania 111 200 South 33rd St. 112 Philadelphia, PA. 19104-6389 114 Email: {waa, angelos}@dsl.cis.upenn.edu