idnits 2.17.1 draft-ietf-dhc-between-bootp-02.txt: ** The Abstract section seems to be numbered 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. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == 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.) ** There are 30 instances of too long lines in the document, the longest one being 4 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 69: '...ts BOOTP clients MUST interact with BO...' RFC 2119 keyword, line 70: '...col. The server MUST formulate a BOOT...' RFC 2119 keyword, line 72: '...type' option and MUST NOT exceed the s...' RFC 2119 keyword, line 84: '...DHCP servers MAY send any DHCP Options...' RFC 2119 keyword, line 89: '...A DHCP client MAY use a reply from a B...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Droms 3 INTERNET-DRAFT Bucknell University 4 November, 1992 6 Interoperation Between DHCP and BOOTP 8 1 Abstract 10 DHCP provides a superset of the functions provided by BOOTP. This document 11 describes the interactions between DHCP and BOOTP network participants. 13 2 Status of this memo 15 This draft document is a product of the IETF Dynamic Host Configuration 16 Working Group; it will be submitted to the RFC editor as a standards 17 document. Distribution of this memo is unlimited. Please respond with 18 comments to the host-conf@sol.cs.bucknell.edu mailing list. This document 19 will expire on June 1, 1993. 21 This document is an Internet Draft. Internet Drafts are working documents 22 of the Internet Engineering Task Force (IETF), its Areas, and its Working 23 Groups. Note that other groups may also distribute working documents as 24 Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six months. 27 Internet Drafts may be updated, replaced, or obsoleted by other documents at 28 any time. It is not appropriate to use Internet Drafts as reference 29 material or to cite them other than as a ``working draft'' or ``work in 30 progress.'' Please check the 1id-abstracts.txt listing contained in the 31 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 32 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current 33 status of any Internet Draft. 35 3 Introduction 37 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for 38 transmitting configuration parameters to hosts using the TCP/IP protocl 39 suite. The format of DHCP messages is based on the format of BOOTP 40 messages, so that, in certain circumstances, DHCP and BOOTP particpants may 41 exchange messages. This document specifies the ways in which DHCP and BOTP 42 participants may interoperate. 44 DHCP introduces a small change in terminology intended to clarify the 45 meaning of one of the fields. What was the ``vendor extensions'' field in 46 BOOTP has been re-named the ``options'' field in DHCP. Similarly, the tagged 47 data items that were used inside the BOOTP ``vendor extensions'' field, 48 which were formerly referred to as ``vendor extensions,'' are now termed 49 simply ``options.'' This document will refer to BOOTP vendor extensions and 50 DHCP options uniformly as ``options.'' 52 Throughout this document, DHCP messages that include a 'DHCP message type' 53 option will be referred to by the type of the message; e.g., a DHCP message 54 with 'DHCP message type' option type1 will be referred to as a 55 ``DHCPDISCOVER'' message. 57 4 BOOTP clients and DHCP servers 59 The format of DHCP messages is defined to be compatible with the format of 60 BOOTP messages, so that existing BOOTP clients can interoperate with DHCP 61 servers. Any message received by a DHCP server that includes a 'DHCP 62 message type' (51) option is assumed to have been sent by a DHCP client. 63 Messages without the DHCP Message Type option are assumed to have been sent 64 by a BOOTP client. Support of BOOTP clients by a DHCP server is optional at 65 the discretion of the local system administrator. If a DHCP server that is 66 not configured to support BOOTP clients receives a BOOTREQUEST message from 67 a BOOTP client, that server silently discards the BOOTREQUEST message. 69 A DHCP server that supports BOOTP clients MUST interact with BOOTP clients 70 according to the BOOTP protocol. The server MUST formulate a BOOTP 71 BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e., the server 72 MUST NOT include the 'DHCP message type' option and MUST NOT exceed the size 73 limit for BOOTREPLY messages). The server marks a binding for a BOOTP 74 client as BOUND after sending the BOOTP BOOTREPLY, as a non-DHCP client will 75 not send a DHCPREQUEST message nor will that client expect a DHCPACK 76 message. 78 A BOOTP client will not be aware of the DHCP lease mechanism for network 79 address assignment. A DHCP server assigns an infinite lease duration to for 80 network addresses assigned to BOOTP clients. Such network addresses cannot 81 be automatically reassigned by the server. The local system administrator 82 may choose to manually release network addresses assigned to BOOTP clients. 84 DHCP servers MAY send any DHCP Options to a BOOTP client as allowed by the 85 ``DHCP Options and BOOTP Vendor Extensions'' internet Draft. 87 5 DHCP clients and BOOTP servers 89 A DHCP client MAY use a reply from a BOOTP server if the configuration 90 returned from the BOOTP server is acceptable to the DHCP client. A DHCP 91 client MUST assume that an IP address returned in a message from a BOOTP 92 server has an infinite lease. A DHCP client SHOULD choose to use a reply 93 from a DHCP server in preference to a reply from a BOOTP server. 95 6 Security Considerations 97 This document does not address security issues. 99 7 Author's Address 101 Ralph Droms 102 Computer Science Department 103 323 Dana Engineering 104 Bucknell University 105 Lewisburg, PA 17837 106 (717) 524-1145 108 droms@bucknell.edu 110 8 Expiration date 112 This document will expire on June 31, 1993.