idnits 2.17.1 draft-ietf-dhc-options-cont-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** 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 55: '...ion. This option MUST not appear as th...' RFC 2119 keyword, line 56: '...eceding this one MUST have a size of 2...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 65 has weird spacing: '...e Len optio...' == Line 74 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: 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 (May 1998) is 9477 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 61 == Unused Reference: '2' is defined on line 88, but no explicit reference was found in the text Summary: 11 errors (**), 0 flaws (~~), 5 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 University of Pennsylvania 4 November 1997 5 Expires May 1998 7 DHCP Continuation Option Code 8 10 Status of this memo 12 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The Dynamic Host Configuration Protocol (DHCP) provides a framework 31 for passing configuration information to hosts on a TCP/IP network. 32 Currently options are limited to an information size of 256 bytes 33 because of the one-octet size of the length field. This document 34 defines a new option that permits the continuation of the previous 35 option information. 37 1. Introduction 39 The Dynamic Host Configuration Protocol (DHCP) [1] provides a 40 framework for passing configuration information to hosts on a TCP/IP 41 network. Configuration parameters and other control information are 42 carried in tagged data items that are stored in the 'options' field 43 of the DHCP message. The data items themselves are also called 44 "options." 46 Each option is assigned a one-octet option code and an one-octet size 47 field. The one-octet size field limits the information contained in 48 an option to 256 bytes. While there exist options that permit the use 49 of the sname and file fields of the header, these options only add an 50 additional 192 bytes when the fields are not in use. This document 52 DRAFT DHCP Continuation Option Code November 1997 54 describes a new DHCP option for continuing the information from the 55 previous option. This option MUST not appear as the first option in 56 a message. The option preceding this one MUST have a size of 256 57 bytes. 59 2. Definition of option [TBD] 61 Option code [TBD] indicates that the data contained in the option is 62 a continuation of the previous option. 64 Continuation 65 Code Len option code Data... 66 +-----+-----+-----+-----+-----+-----+-------------- 67 | TBD | XXX | Continuation of previous option data 68 +-----+-----+-----+-----+-----+-----+--------------- 70 The example below shows how the option would work with a hypothetical 71 authentication option that requires more than 255 bytes of information. 73 Auth 74 Code Len option Data... 75 +-----+-----+-----+-----+-----+-----+-------------- 76 | 90 | 256 | 04 | d1 d2 d4 ... d255 77 +-----+-----+-----+-----+-----+-----+--------------- 78 Code Len Data... 79 +-----+-----+-----+-----+-----+-----+-------------- 80 | TBD | 20 | d257 d258 d259 d260 ... d276 81 +-----+-----+-----+-----+-----+-----+--------------- 83 4. References 85 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 86 Bucknell University, March 1997. 88 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 89 Extensions", RFC 2132, Lachman Associates, March 1997. 91 5. Security Considerations 93 DHCP currently provides no authentication or security mechanisms. 94 Potential exposures to attack are discussed in section 7 of the DHCP 95 protocol specification [1]. One of the reasons for this definition is 96 to provide support for the exchange of public key certificates are 97 which usually larger than 256 bytes. 99 DRAFT DHCP Continuation Option Code November 1997 101 6. Author's Address 103 William A. Arbaugh 104 Angelos D. Keromytis 105 Distributed Systems Lab -- 102 Moore 106 Department of Computer and Information Sciences 107 University of Pennsylvania 108 200 South 33rd St. 109 Philadelphia, PA. 19104-6389 111 Email: {waa, angelos}@dsl.cis.upenn.edu