summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorcvs2git <source@isc.org>1998-06-25 18:37:47 +0000
committercvs2git <source@isc.org>1998-06-25 18:37:47 +0000
commit794f3417bc9c378eb956b61ee9adaa2c36af89c4 (patch)
treea4c94f7415c29035c573a8b81129592865a25588
parentf3bc6c14c17b3de7662a2ff626f4c69ddbfa6850 (diff)
parent1921e527a2797b02a4e73cf5257b42326b42d11a (diff)
downloadisc-dhcp-794f3417bc9c378eb956b61ee9adaa2c36af89c4.tar.gz
This commit was manufactured by cvs2git to create tag 'V2-BETA-1'.V2-BETA-1
Diffstat
-rw-r--r--doc/IANA-arp-parameters145
-rw-r--r--doc/draft-ietf-dhc-authentication-03.txt446
-rw-r--r--doc/draft-ietf-dhc-dhcp-dns-02.txt356
-rw-r--r--doc/draft-ietf-dhc-new-options-00.txt110
-rw-r--r--doc/draft-ietf-dhc-options-opt127-02.txt167
-rw-r--r--doc/draft-ietf-dhc-renumbering-00.txt390
-rw-r--r--doc/rfc2131.txt (renamed from doc/draft-ietf-dhc-dhcp-09.txt)1488
-rw-r--r--doc/rfc2132.txt (renamed from doc/draft-ietf-dhc-options-1533update-06.txt)1054
-rw-r--r--doc/rfc951.txt684
9 files changed, 1847 insertions, 2993 deletions
diff --git a/doc/IANA-arp-parameters b/doc/IANA-arp-parameters
deleted file mode 100644
index 9fa8f115..00000000
--- a/doc/IANA-arp-parameters
+++ /dev/null
@@ -1,145 +0,0 @@
-
-
-ADDRESS RESOLUTION PROTOCOL PARAMETERS
-
-The Address Resolution Protocol (ARP) specified in [RFC826] has
-several parameters. The assigned values for these parameters are
-listed here.
-
-REVERSE ADDRESS RESOLUTION PROTOCOL OPERATION CODES
-
-The Reverse Address Resolution Protocol (RARP) specified in [RFC903]
-uses the "Reverse" codes below.
-
-DYNAMIC REVERSE ARP
-
-The Dynamic Reverse Address Resolution Protocol (DRARP) uses the
-"DRARP" codes below. For further information, contact: David Brownell
-(suneast!helium!db@Sun.COM).
-
-INVERSE ADDRESS RESOULUTION PROTOCOL
-
-The Inverse Address Resolution Protocol (IARP) specified in [RFC1293]
-uses the "InARP" codes below.
-
-Assignments:
-
-Number Operation Code (op) References
------- -------------------------- ----------
- 1 REQUEST [RFC826]
- 2 REPLY [RFC826]
- 3 request Reverse [RFC903]
- 4 reply Reverse [RFC903]
- 5 DRARP-Request [David Brownell]
- 6 DRARP-Reply [David Brownell]
- 7 DRARP-Error [David Brownell]
- 8 InARP-Request [RFC1293]
- 9 InARP-Reply [RFC1293]
- 10 ARP-NAK [RFC1577]
- 11 MARS-Request [Armitage]
- 12 MARS-Multi [Armitage]
- 13 MARS-MServ [Armitage]
- 14 MARS-Join [Armitage]
- 15 MARS-Leave [Armitage]
- 16 MARS-NAK [Armitage]
- 17 MARS-Unserv [Armitage]
- 18 MARS-SJoin [Armitage]
- 19 MARS-SLeave [Armitage]
- 20 MARS-Grouplist-Request [Armitage]
- 21 MARS-Grouplist-Reply [Armitage]
- 22 MARS-Redirect-Map [Armitage]
- 23 MAPOS-UNARP [Maruyama]
-
-
-Number Hardware Type (hrd) References
------- ----------------------------------- ----------
- 1 Ethernet (10Mb) [JBP]
- 2 Experimental Ethernet (3Mb) [JBP]
- 3 Amateur Radio AX.25 [PXK]
- 4 Proteon ProNET Token Ring [Doria]
- 5 Chaos [GXP]
- 6 IEEE 802 Networks [JBP]
- 7 ARCNET [JBP]
- 8 Hyperchannel [JBP]
- 9 Lanstar [TU]
- 10 Autonet Short Address [MXB1]
- 11 LocalTalk [JKR1]
- 12 LocalNet (IBM PCNet or SYTEK LocalNET) [JXM]
- 13 Ultra link [RXD2]
- 14 SMDS [GXC1]
- 15 Frame Relay [AGM]
- 16 Asynchronous Transmission Mode (ATM) [JXB2]
- 17 HDLC [JBP]
- 18 Fibre Channel [Yakov Rekhter]
- 19 Asynchronous Transmission Mode (ATM) [RFC1577]
- 20 Serial Line [JBP]
- 21 Asynchronous Transmission Mode (ATM) [MXB1]
- 22 MIL-STD-188-220 [Jensen]
- 23 Metricom [Stone]
- 24 IEEE 1394.1995 [Hattig]
- 25 MAPOS [Maruyama]
-
-Protocol Type (pro)
-
-Use the same codes as listed in the section called "Ethernet Numbers
-of Interest" (all hardware types use this code set for the protocol
-type).
-
-
-REFERENCES
-
-[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol or
- Converting Network Protocol Addresses to 48-bit Ethernet
- Addresses for Transmission on Ethernet Hardware", STD 37, RFC
- 826, MIT-LCS, November 1982.
-
-[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
- Reverse Address Resolution Protocol", STD 38, RFC 903,
- Stanford University, June 1984.
-
-[RFC1293] Bradley, T., and C. Brown, "Inverse Address Resolution
- Protocol", RFC 1293, Wellfleet Communications, Inc.,
- January 1992.
-
-
-PEOPLE
-
-[Armitage] Grenville Armitage, <gja@thumper.belcore.com>, April 1995.
-
-[AGM] Andy Malis <malis_a@timeplex.com>
-
-[GXC1] George Clapp <meritec!clapp@bellcore.bellcore.com>
-
-[Doria] Avri Doria <avri@peoteon.com> December 1994.
-
-[GXP] Gill Pratt <gill%mit-ccc@MC.LCS.MIT.EDU>
-
-[Jensen] Herb Jensen, <hwjensen@itt.com>, February 1995.
-
-[JBP] Jon Postel <postel@isi.edu>
-
-[JKR1] Joyce K. Reynolds <jkrey@isi.edu>
-
-[JXM] Joseph Murdock <---none--->
-
-[Hattig] Myron Hattig, <Myron_Hattig@ccm.jf.intel.com>, February 1997.
-
-[Maruyama] Mitsuru Maruyama, <mitsuru@ntt-20.ecl.net>, March 1997.
-
-[MXB1] Mike Burrows <burrows@SRC.DEC.COM>
-
-[PXK] Philip Koch <Philip.Koch@DARTMOUTH.EDU>
-
-[RXD2] Rajiv Dhingra <rajiv@ULTRA.COM>
-
-[Stone] Jonathan Stone, <jonathan@DSG.Stanford.edu>, May 1996.
-
-[TU] Tom Unger <tom@CITI.UMICH>
-
-[David Brownell]
-
-[Mark Laubach]
-
-[Yakov Rekhter] <Yakov@IBM.COM>
-
-[]
diff --git a/doc/draft-ietf-dhc-authentication-03.txt b/doc/draft-ietf-dhc-authentication-03.txt
deleted file mode 100644
index 5be03584..00000000
--- a/doc/draft-ietf-dhc-authentication-03.txt
+++ /dev/null
@@ -1,446 +0,0 @@
-
-Network Working Group R. Droms, Editor
-INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996
- Expires May 1997
-
-
- Authentication for DHCP Messages
- <draft-ietf-dhc-authentication-03.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 the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (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. In some situations, network administrators may wish to
- constrain the allocation of addresses to authorized hosts.
- Additionally, some network administrators may wish to provide for
- authentication of the source and contents of DHCP messages. This
- document defines a new DHCP option through which authorization
- tickets can be easily generated and newly attached hosts with proper
- authorization can be automatically configured from an authenticated
- DHCP server.
-
-1. Introduction
-
- DHCP transports protocol stack configuration parameters from
- centrally administered servers to TCP/IP hosts. Among those
- parameters are an IP address. DHCP servers can be configured to
- dynamically allocate addresses from a pool of addresses, eliminating
- a manual step in configuration of TCP/IP hosts.
-
-
-
-
-Droms [Page 1]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
- Some network administrators may wish to provide authentication of the
- source and contents of DHCP messages. For example, clients may be
- subject to denial of service attacks through the use of bogus DHCP
- servers, or may simply be misconfigured due to unintentionally
- instantiated DHCP servers. Network administrators may wish to
- constrain the allocation of addresses to authorized hosts to avoid
- denial of service attacks in "hostile" environments where the network
- medium is not physically secured, such as wireless networks or
- college residence halls.
-
- This document defines a technique that can provide both entity
- authentication and message authentication.
-
-1.1 Requirements
-
- Throughout this document, the words that are used to define the
- significance of particular requirements are capitalized. These words
- are:
-
- o "MUST"
-
- This word or the adjective "REQUIRED" means that the
- item is an absolute requirement of this specification.
-
- o "MUST NOT"
-
- This phrase means that the item is an absolute prohibition
- of this specification.
-
- o "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.
-
- o "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 weighed before implementing any behavior
- described with this label.
-
-
-
-
-
-
-
-
-Droms [Page 2]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
- o "MAY"
-
- This word or the adjective "OPTIONAL" means that this item is
- truly optional. One vendor may choose 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.
-
-1.2 Terminology
-
- This document uses the following terms:
-
- o "DHCP client"
-
- A DHCP client or "client" is an Internet host using DHCP to obtain
- configuration parameters such as a network address.
-
- o "DHCP server"
-
- A DHCP server of "server"is an Internet host that returns
- configuration parameters to DHCP clients.
-
-2. Format of the authentication option
-
- The following diagram defines the format of the DHCP
- authentication option:
-
-
- +----------+----------+----------+
- | Code | Length | Protocol |
- +----------+----------+----------+-----------+---
- | Authentication information ...
- +----------+----------+----------+-----------+---
-
-
- The code for the authentication option is TBD, and the length field
- contains the length of the protocol and authentication information
- fields in octets. The protocol field defines the particular
- technique for authentication used in the option.
-
- This document defines two protocols in sections 3 and 4, encoded with
- protocol field values 0 and 1. Protocol field values 2-254 are
- reserved for future use. Other protocols may be defined according to
- the procedure described in section 5.
-
-3. Protocol 0
-
- If the protocol field is 0, the authentication information field
-
-
-
-Droms [Page 3]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
- holds a simple authentication token:
-
-
- +----------+----------+----------+
- | Code | n+1 | 0 |
- +----------+----------+----------+-----------+------
- | Authentication token (n octets) ...
- +----------+----------+----------+-----------+------
-
-
- The authentication token is an opaque, unencoded value known to both
- the sender and receiver. The sender inserts the authentication token
- in the DHCP message and the receiver matches the token from the
- message to the shared token. If the authentication option is present
- and the token from the message does not match the shared token, the
- receiver MUST discard the message.
-
- Protocol 0 may be used to pass a plain-text password and provides
- only weak entity authentication and no message authentication. This
- protocol is useful for rudimentary protection against, e.g.,
- inadvertently instantiated DHCP servers.
-
- DISCUSSION:
-
- The intent here is to pass a constant, non-computed token such as
- a plain-text password. Other types of entity authentication using
- computed tokens such as Kerberos tickets or one-time passwords
- will be defined as separate protocols.
-
-
-4. Protocol 1
-
- If the protocol field is 1, the authentication information contains
- an encrypted value generated by the source as a message
- authentication code (MAC) to provide message authentication and
- entity authentication.
-
- This technique is based on the HMAC protocol [3] using the MD5 hash
- {2].
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 4]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
-4.1 Format
-
- The format of the authentication information for protocol 1 is:
-
-
- +----------+----------+----------+
- | Code | n | 1 |
- +----------+----------+----------+----------+-
- | Counter (8 octets) ...
- +----------+----------+----------+----------+-
- | MAC ...
- +----------+----------+----------+----------+-
-
- The following definitions will be used in the description of the
- authentication information for protocol 1:
-
- K - a secret value shared between the source and destination
- of the message
- Counter - the value of a 64-bit monotonically increasing counter
- HMAC-MD5 - the MAC generating function as defined by [3] and [2]
-
- The sender computes the MAC as described in [3]. The 'counter' field
- of the authentication option MUST be set to the value of a
- monotonically increasing counter and the 'MAC' field of the
- authentication option MUST be set to all 0s for the computation of
- the MAC. Because a DHCP relay agent may alter the values of the
- 'giaddr' and 'hops' fields in the DHCP message, the contents of those
- two fields MUST also be set to zero for the computation of the
- message digest. Using a counter value such as the current time of
- day (e.g., an NTP-format timestamp [4]) can reduce the danger of
- replay attacks.
-
- DISCUSSION:
-
- Protocol 1 specifies the use of HMAC-MD5. Use of a different
- technique, such as HMAC-SHA, will be specified as a separate
- protocol.
-
-4.2 Message validation
-
- To validate an incoming message, the receiver checks the 'counter'
- field and computes the MAC as described in [3]. If the 'counter'
- field does not contain a value larger than the last value of
- 'counter' used by the sender, the receiver MUST discard the incoming
- message. The receiver MUST set the 'MAC' field of the authentication
- option to all 0s for computation of the MAC. Because a DHCP relay
- agent may alter the values of the 'giaddr' and 'hops' fields in the
- DHCP message, the contents of those two fields MUST also be set to
-
-
-
-Droms [Page 5]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
- zero for the computation of the MAC. If the MAC computed by the
- receiver does not match the MAC contained in the authentication
- option, the receiver MUST discard the DHCP message.
-
-4.3 Key utilization
-
- Each DHCP client has a key, K. The client uses its key to encode any
- messages it sends to the server and to authenticate and verify any
- messages it receives from the server. The client's key must be
- initially distributed to the client through some out-of-band
- mechanism, and must be stored locally on the client for use in all
- authenticated DHCP messages. Once the client has been given its key,
- it may use that key for all transactions even if the client's
- configuration changes; e.g., if the client is assigned a new network
- address.
-
- Each DHCP server must know the keys for all authorized clients. If
- all clients use the same key, clients can perform both entity and
- message authentication for all messages received from servers.
- Servers will be able to perform message authentication. To
- authenticate the identity of individual clients, each client must be
- configured with a unique key. Appendix A describes a technique for
- key management.
-
-5. Definition of new authentication protocols
-
- The author of a new DHCP option will follow these steps to obtain
- acceptance of the option as a part of the DHCP Internet Standard:
-
- 1. The author devises the new authentication protocol.
- 2. The author documents the new protocol as an Internet Draft.
- 3. The author submits the Internet Draft for review through the IETF
- standards process as defined in "Internet Official Protocol
- Standards" (STD 1). The new protocol will be submitted for
- eventual acceptance as an Internet Standard.
- 4. The new protocol progresses through the IETF standards process;
- the new option will be reviewed by the Dynamic Host Configuration
- Working Group (if that group still exists), or as an Internet
- Draft not submitted by an IETF working group.
-
- This procedure for defining new authentication protocols will ensure
- that:
-
- * new options are reviewed for technical correctness and
- appropriateness, and
- * documentation for new options is complete and published.
-
-
-
-
-
-Droms [Page 6]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
-6. References
-
- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
- Bucknell University, October 1993.
-
- [2] Rivest, R., "The MD5 Message-Digest Algorithm",
- RFC-1321, April 1992.
-
- [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
- Message Authentication" <draft-ietf-ipsec-hmac-md5-01.txt> (work in
- progress), August 1996.
-
- [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
- 1992.
-
-7. Acknowledgments
-
- Jeff Schiller and Christian Huitema developed this scheme during a
- terminal room BOF at the Dallas IETF meeting, December 1995. The
- author transcribed the notes from that discussion, which form the
- basis for this document. The editor appreciates Jeff's and
- Christian's patience in reviewing this document and its earlier
- drafts.
-
- Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for
- reviewing this document, and to Thomas Narten for reviewing earlier
- drafts of this document.
-
-8. Security considerations
-
- This document describes authentication and verification mechanisms
- for DHCP.
-
-9. Author's address
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-Droms [Page 7]
-
-DRAFT Authentication for DHCP Messages November 1996
-
-
- Appendix A - Key Management Technique
-
- To avoid centralized management of a list of random keys, suppose K for
- each client is generated from the pair (client identifier, subnet
- address), which must be unique to that client. That is, K = MD5(MK,
- unique-id), where MK is a secret master key and MD5 is some encoding
- function.
-
- Without knowledge of the master key MK, an unauthorized client cannot
- generate its own key K. The server can quickly validate an incoming
- message from a new client by regenerating K from the client-id. For known
- clients, the server can choose to recover the client's K dynamically from
- the client-id in the DHCP message, or can choose to precompute and cache
- all of the Ks a priori.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 8]
-
diff --git a/doc/draft-ietf-dhc-dhcp-dns-02.txt b/doc/draft-ietf-dhc-dhcp-dns-02.txt
deleted file mode 100644
index b85ed12e..00000000
--- a/doc/draft-ietf-dhc-dhcp-dns-02.txt
+++ /dev/null
@@ -1,356 +0,0 @@
-
-
-Network Working Group Yakov Rekhter
-Internet Draft Cisco Systems
-Expiration Date: April 1997 October 1996
-
-
- Interaction between DHCP and DNS
- draft-ietf-dhc-dhcp-dns-02.txt
-
-
-1. 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 the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-
-2. Abstract
-
- DHCP provides a powerful mechanism for IP host autoconfiguration.
- However, the autoconfiguration provided by DHCP does not include
- updating DNS, and specifically updating the name to address and
- address to name mappings maintained by DNS.
-
- This document specifies how DHCP clients and servers should use the
- Dynamic DNS Updates mechanism to update the DNS name to address and
- address to name mapping, so that the mappings for DHCP clients would
- be consistent with the IP addresses that the clients acquire via
- DHCP.
-
-
-
-
-
-
-
-
-
-
-
-Yakov Rekhter [Page 1]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
-3. Interaction between DHCP and DNS
-
- DNS [RFC1034, RFC1035] maintains (among other things) the information
- about mapping between hosts' Fully Qualified Domain Names (FQDNs)
- [RFC1594] and IP addresses assigned to the hosts. The information is
- maintained in two types of Resource Records (RRs): A and PTR. The A
- RR contains mapping from a FQDN to an IP address; the PTR RR contains
- mapping from an IP address to a FQDN.
-
- DHCP [RFC1541] provides a mechanism by which a host (a DHCP client)
- could acquire certain configuration information, and specifically its
- IP address(es). However, DHCP does not provide any mechanisms to
- update the DNS RRs that contain the information about mapping between
- the host's FQDN and its IP address(es) (A and PTR RRs). Thus the
- information maintained by DNS for a DHCP client may be incorrect - a
- host (the client) could acquire its address by using DHCP, but the A
- RR for the host's FQDN wouldn't reflect the address that the host
- acquired, and the PTR RR for the acquired address wouldn't reflect
- the host's FQDN.
-
- Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS
- information to be updated DNS over a network.
-
- The Dynamic DNS Update protocol can be used to maintain consistency
- between the information stored in the A and PTR RRs and the actual
- address assignment done via DHCP. When a host with a particular FQDN
- acquires its IP address via DHCP, the A RR associated with the host's
- FQDN would be updated (by using the Dynamic DNS Updates protocol) to
- reflect the new address. Likewise, when an IP address gets assigned
- to a host with a particular FQDN, the PTR RR associated with this
- address would be updated (using the Dynamic DNS Updates protocol) to
- reflect the new FQDN.
-
-
-4. Models of operations
-
- When a DHCP client acquires a new address, both the A RR (for the
- client's FQDN) and the PTR RR (for the acquired address) have to be
- updated. Therefore, we have two separate Dynamic DNS Update
- transactions. Acquiring an address via DHCP involves two entities: a
- DHCP client and a DHCP server. In principle each of these entities
- could perform none, one, or both of the transactions. However, upon
- some introspection one could realize that not all permutations make
- sense. This document covers the possible design permutations:
-
- (1) DHCP client updates the A RR, DHCP server updates the PTR
- RR
-
-
-
-
-Yakov Rekhter [Page 2]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
- (2) DHCP server updates both the A and the PTR RRs
-
- One could observe that the only difference between these two cases is
- whether the FQDN to IP address mapping is updated by a DHCP client or
- by a DHCP server. The IP address to FQDN mapping is updated by a DHCP
- server in both cases.
-
-
-4.1. Client FQDN Option
-
- To update the IP address to FQDN mapping a DHCP server needs to know
- FQDN of the client to which the server leases the address. To allow
- the client to convey its FQDN to the server this document defines a
- new option, called "Client FQDN".
-
- The code for this option is 81. Its minimum length is 4.
-
-
-
- Code Len Flags RCODE1 RCODE2 Domain Name
- +------+------+------+------+------+------+--
- | TBD | n | 0/1 | | | ...
- +------+------+------+------+------+------+--
-
-
-
- The Flags field allows a DHCP client to indicate to a DHCP server
- whether the client wants the server to be responsible for updating
- the FQDN to IP address mapping (if Flags is set to 1), or whether the
- client wants to take this responsibility (if Flags is set to 0).
-
- The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to
- a DHCP client the Response Code from Dynamic DNS Updates.
-
- The Domain Name part of the option carries FQDN of a client.
-
-
-
-4.2. DHCP Client behavior
-
- If a client wants to be responsible for updating the FQDN to IP
- address mapping for the FQDN and address(es) used by the client, then
- the client shall include the Client FQDN option in the DHCPREQUEST
- message originated by the client. The Flags field in the option shall
- be set to 0. Once the client's DHCP configuration is completed (the
- client receives a DHCPACK message, and successfully completed a final
- check on the parameters passed in the message), the client shall
- originate an update for the A RR (associated with the client's FQDN).
-
-
-
-Yakov Rekhter [Page 3]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
- The update shall be originated following the procedures described in
- [DynDNS].
-
-
- If a client does not want to be responsible for updating the FQDN to
- IP address mapping for the FQDN and address(es) used by the client,
- then the client shall include the Client FQDN option in the
- DHCPREQUEST message originated by the client. The Flags field in the
- option shall be set to 1.
-
-
- A client should set the RCODE1 and RCODE2 fields in the Client FQDN
- option to 0 when sending the option.
-
- Whether the client wants to be responsible for updating the FQDN to
- IP address mapping, or whether the client wants to delegate this
- responsibility to a server is a local to the client matter. The
- choice between the two alternatives may be based on a particular
- security model that is used with the Dynamic DNS Update protocol
- (e.g., only a client may have sufficient credentials to perform
- updates to the FQDN to IP address mapping for its FQDN).
-
- If a client releases its address lease prior to the lease expiration
- time, and the client is responsible for updating its A RR(s), the
- client should delete the A RR (following the procedures described in
- [DynDNS]) associated with the leased address before sending DHCP
- RELEASE message.
-
-
-4.3. DHCP Server behavior
-
- When a server receives a DHCPREQUEST message from a client, if the
- message contains the Client FQDN option, and the server replies to
- the message with a DHCPACK message, the server shall originate an
- update for the PTR RR (associated with the address leased to the
- client). The server shall originate the update before the server
- sends the DHCPACK message to the client. The update shall be
- originated following the procedures described in [DynDNS]. The RCODE
- from the update [DynDNS] should be carried to the client in the
- RCODE1 field of the Client FQDN option in the DHCPACK message. The
- RCODE2 field should be set to 0.
-
- In addition, if the Client FQDN option carried in the DHCPREQUEST
- message has its Flags field set to 1, then the server shall originate
- an update for the A RR (associated with the FQDN carried in the
- option). The server shall originate the update before the server
- sends the DHCPACK message to the client. The update shall be
- originated following the procedures described in [DynDNS]. The RCODE
-
-
-
-Yakov Rekhter [Page 4]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
- from the update [DynDNS] should be carried to the client in the
- RCODE2 field of the Client FQDN option in the DHCPACK message.
-
- When a server receives a DHCPREQUEST message from a client, and the
- message contains the Client FQDN option, the server shall ignore the
- value carried in the RCODE1 and RCODE2 fields of the option.
-
- When a DHCP server sends the Client FQDN option to a client in the
- DHCPACK message, the server should copy the Flags and the Domain Name
- fields from the Client FQDN option that the client sent to the server
- in the DHCPREQUEST message.
-
-
- If a server originates updates for both the A and PTR RRs, then the
- order in which the updates are generated is not significant.
-
-
- If a server detects that a lease on an address that the server leases
- to a client expires, the server should delete the PTR RR associated
- with the address. In addition, if the client authorized the server to
- update its A RR, the server should also delete the A RR. The deletion
- should follow the procedures described in [DynDNS].
-
- If a server terminates a lease on an address prior to the lease
- expiration time, the server should delete the PTR RR associated with
- the address. In addition, if the client (that leased the address)
- authorized the server to update its A RR, the server should also
- delete the A RR. The deletion should follow the procedures described
- in [DynDNS].
-
-
-5. Updating other RRs
-
- The procedures described in this document cover updates only to the A
- and PTR RRs. Updating other types of RRs is outside the scope of this
- document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yakov Rekhter [Page 5]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
-6. Security Considerations
-
- Security issues are not discussed in this document.
-
-
-7. References
-
- [RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
- RFC1034, 11/01/1987
-
- [RFC1035] P. Mockapetris, "Domain names - implementation and
- specification", RFC1035, 11/01/1987
-
- [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541,
- 10/27/1993
-
- [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and
- Answer Answers to Commonly asked ``New Internet User'' Questions",
- RFC1594, 03/11/1994
-
- [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates
- in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS-
- 09.txt
-
-
-
-8. Acknowledgements
-
- Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms
- (Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron),
- and Michael Patton (BBN) for their review and comments.
-
-
-9. Author Information
-
-
- Yakov Rekhter
- cisco Systems, Inc.
- 170 Tasman Dr.
- San Jose, CA 95134
- Phone: (914) 528-0090
- email: yakov@cisco.com
-
-
-
-
-
-
-
-
-
-Yakov Rekhter [Page 6]
-
-
diff --git a/doc/draft-ietf-dhc-new-options-00.txt b/doc/draft-ietf-dhc-new-options-00.txt
deleted file mode 100644
index adf332a5..00000000
--- a/doc/draft-ietf-dhc-new-options-00.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-
-Network Working Group R. Droms
-INTERNET DRAFT Bucknell University
-Obsoletes: February 1996
- Expires August 1996
-
-
- Procedure for Defining New DHCP Options
- <draft-ietf-dhc-new-options-00.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 the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-Abstract
-
- The Dynamic Host Configuration Protocol (DHCP) provides a
- framework for passing configuration information to hosts on a TCP/IP
- network. Configuration parameters and other control information are
- carried in tagged data items that are stored in the 'options' field
- of the DHCP message. The data items themselves are also called
- "options."
-
- This document describes the procedure for defining new DHCP options.
- The procedure will guarantee that:
-
- * allocation of new option numbers is coordinated from a single
- authority,
- * new options are reviewed for technical correctness and
- appropriateness, and
- * documentation for new options is complete and published.
-
-
-
-
-
-
-
-Droms [Page 1]
-
-DRAFT Procedure for Defining New DHCP Options February 1996
-
-
-Procedure
-
- The author of a new DHCP option will follow these steps to obtain
- acceptance of the option as a part of the DHCP Internet Standard:
-
- 1. The author devises the new option.
- 2. The author requests a number for the new option from IANA.
- 3. The author documents the new option, using the newly obtained
- option number, as an Internet Draft.
- 4. The author submits the Internet Draft for review through the IETF
- standards process as defined in "Internet Official Protocol
- Standards" (STD 1). The new option will be submitted for eventual
- acceptance as an Internet Standard.
- 5. The new option progresses through the IETF standards process; the
- new option will be reviewed by the Dynamic Host Configuration
- Working Group (if that group still exists), or as an Internet
- Draft not submitted by an IETF working group.
- 6. If the new option fails to gain acceptance as an Internet
- Standard, the assigned option number will be returned to IANA for
- reassignment.
-
-Acceptance and publication
-
- If this procedure is accepted, it will be added to the DHCP options
- specification as an Appendix.
-
-Security Considerations
-
- Security issues are not discussed in this memo.
-
-Author's Address
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 2]
-
diff --git a/doc/draft-ietf-dhc-options-opt127-02.txt b/doc/draft-ietf-dhc-options-opt127-02.txt
deleted file mode 100644
index d42a33ea..00000000
--- a/doc/draft-ietf-dhc-options-opt127-02.txt
+++ /dev/null
@@ -1,167 +0,0 @@
-
-
-Network Working Group R. Droms
-INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-options-opt127-01.txt April 1996
- Expires October 1996
-
-
- An Extension to the DHCP Option Codes
- <draft-ietf-dhc-options-opt127-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 the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-Abstract
-
- The Dynamic Host Configuration Protocol (DHCP) provides a framework
- for passing configuration information to hosts on a TCP/IP network.
- This document defines a new option to extend the available option
- codes.
-
-Introduction
-
- The Dynamic Host Configuration Protocol (DHCP) [1] provides a
- framework for passing configuration information to hosts on a TCP/IP
- network. Configuration parameters and other control information are
- carried in tagged data items that are stored in the 'options' field
- of the DHCP message. The data items themselves are also called
- "options."
-
- Each option is assigned a one-octet option code. Options 128-254 are
- reserved for local use and at this time over half of the available
- options in the range 0-127 and option 255 have been assigned. This
- document defines a new option to extend the available option codes
- and new option to request the parameters represented by those new
-
-
-
-Droms [Page 1]
-
-DRAFT An extension to the DHCP Option Codes April 1996
-
-
- option codes.
-
-Definition of option 127
-
- Option code 127 indicates that the DHCP option has a two-octet
- extended option code. The format of these options is:
-
- Extended
- Code Len option code Data...
- +-----+-----+-----+-----+-----+-----+----
- | 127 | XXX | oh | ol | d1 | d2 | ...
- +-----+-----+-----+-----+-----+-----+----
-
- Other than the two-octet extended option code, these options are
- encoded and carried in DHCP messages identically to the options
- defined in RFC 1533 [2]. The high-order and low-order octets of the
- extended option code are stored in 'oh' and 'ol', respectively. The
- number of octets given in the 'len' field includes the two-octet
- extended option code.
-
- The two-octet extended option codes will be assigned through the
- mechanisms defined for the assignment of new options [3] after the
- current one-octet option codes have been exhausted.
-
-Definition of option 126
-
- This option is used by a DHCP client to request values for specified
- configuration paramaters that are identified by extended option codes
- as defined above. The list of n requested parameters is specified as
- 2n octets, where each pair of octets is a valid extended option code.
-
- The client MAY list the options in order of preference. The DHCP
- server is not required to return the options in the requested order,
- but MUST try to insert the requested options in the order requested
- by the client.
-
- The code for this option is 126. Its minimum length is 2.
-
- Extended
- Code Len option codes
- +-----+-----+-----+-----+-----+-----+----
- | 126 | XXX | c1h | c1l | c2h | c2l | ...
- +-----+-----+-----+-----+-----+-----+----
-
-
-
-
-
-
-
-
-Droms [Page 2]
-
-DRAFT An extension to the DHCP Option Codes April 1996
-
-
-References
-
- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
- Bucknell University, October 1993.
-
- [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 1533, Lachman Associates, October 1993.
-
- [3] Droms, R., "Procedure for Defining New DHCP Options", Work in
- progress, February, 1996.
-
-Security Considerations
-
- Security issues are not discussed in this document.
-
-Author's Address
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 3]
-
diff --git a/doc/draft-ietf-dhc-renumbering-00.txt b/doc/draft-ietf-dhc-renumbering-00.txt
deleted file mode 100644
index c0f00843..00000000
--- a/doc/draft-ietf-dhc-renumbering-00.txt
+++ /dev/null
@@ -1,390 +0,0 @@
-
-
-INTERNET-DRAFT Lowell Gilbert
-DHC Working Group Epilogue Technology Corporation
-Network Area April 1996
- Expires October 1996
-
-
- Graceful renumbering of networks with DHCP
- <draft-ietf-dhc-renumbering-00.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 the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-
-Abstract
-
- This document proposes a method for improving the ability of the
- Dynamic Host Configuration Protocol (DHCP) to assist in renumbering
- an internet. DHCP is already capable of supporting host renumbering
- by assigning a new address when a client attempts to renegotiate an
- existing lease, but this proposal makes host renumbering more
- graceful by providing for a transition period in which the client can
- use both addresses.
-
-
-
-
-
-
-
-Gilbert [Page 1]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
-Introduction
-
- This document proposes a method for improving the ability of the
- Dynamic Host Configuration Protocol (DHCP) to assist in renumbering an
- internet. DHCP is already capable of supporting host renumbering by
- assigning a new address when a client attempts to renegotiate an
- existing lease, but this proposal makes host renumbering more graceful
- by providing for a transition period in which the client can use both
- addresses. This enables the client to avoid disruption of existing
- communications that may have already bound themselves to the original
- address. This also enables the client to avoid disruption of new
- communications (when the existing address would no longer be valid) by
- ensuring they are bound to the new address.
-
- This proposal adds to the core DHC protocol a mechanism by which a
- DHCP client may acquire an additional IP address to eventually replace
- one already in use. A new option is defined for the server to start
- this process in the client. Significant modifications to the
- protocol's state machine are avoided by starting up a whole new state
- machine for handling the new address.
-
-
-Motivations
-
- Host addresses may need to change for a number of reasons. For
- example, if the address assignment scheme is based on CIDR
- guidelines, when a site changes its provider hosts within the site
- may need to change their addresses.
-
- The intention of the mechanism described here is to allow system
- administrators to specify a graceful transition period during
- renumbering to minimize disruption caused by address changes,
- particularly for hosts for which continuous availability is an
- important factor.
-
-
-
-
-
-
-
-
-
-
-Gilbert [Page 2]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
-Document Independence
-
- The most important point to note about this proposal is that it can
- be issued as a separate document from the protocol specification.
- There are three factors that make this practical:
-
- * the graceful renumbering support is optional,
-
- * the graceful renumbering support will be completely impossible
- for some existing platforms (i.e. those which aren't capable of
- having multiple addresses at one time anyway),
-
- * the graceful renumbering support doesn't in any way affect the
- operation of hosts or servers that don't implement it.
- Therefore, there's no good reason that it can't be split out on
- its own, to progress on its own (separate) merits.
-
-
-Design Goals
-
- * full backward compatibility with DHCP implementations compliant
- with RFC1541. This is essential for acceptance of new
- implementations with the new functionality.
-
- * no changes to relay agents. This is the key to the general DHCP
- migration strategy. The simpler a relay agent is, the more
- likely it is to be included in other network devices.
-
- * minimal impact upon the standards status (and advancement) of the
- base DHCP protocol. Acceptance of the core protocol is a
- prerequisite for acceptance of this one.
-
-
-Terminology:
-
-
- Use of the terms MUST, SHOULD, or SHOULD NOT in this document implies
- the usual meanings with respect to implementing this specification.
- However, none of this specification need be implemented for an
- implementation to be considered compliant with DHCP (for which
- compliance with RFC 1541 is necessary and sufficient).
-
-
-
-Gilbert [Page 3]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
-Requirements
-
- This proposal requires that any client be capable of binding more
- than one address to an interface at a time, and also that the client
- be able to distinguish among these addresses for the purpose of
- binding existing and new transport connections. It also requires
- that any server be able to track multiple bindings per client. If
- these requirements cannot be met, then the host in question can still
- implement DHCP, but won't be able to implement graceful renumbering
- support.
-
- A new option (the "renumbering" option) is defined for use in DHCPACK
- and DHCPDISCOVER messages. The length of this option is 4 octets.
- The presence of this option in a DHCPACK indicates that the client
- should initialize a new DHCP state machine for a new address. The
- option shall contain a "magic cookie" value which the server can use
- in tracking requests for new addresses; the client MUST NOT attempt
- to interpret the value.
-
- This proposal assumes that a DHCP Server would have to be configured
- with the new (post-renumbering) addresses, prior to the
- reconfiguration of any of the Relay Agents that point to that Server.
- Once the Server is configured with the new addresses, the Relay
- Agents that point to that server could be reconfigured on their own,
- without requiring any coordination with the Server. Under those
- conditions, this proposal can accommodate a situation where a client
- would receive a DHCPACK with the "renumbering" option, but the Relay
- Agent that serves the client would not be configured (yet) with a new
- (post-renumbering) address.
-
-
-Protocol Summary
-
-
- A renumbering option in a DHCPACK packet requests the client to begin
- trying to get a post-renumbering address. The post-renumbering
- address has its own DHCP state machine, which runs in parallel with
- the one for the pre-renumbering address (with both addresses active
- on the interface) until the lease runs out on the pre-renumbering
- address. Then the original state machine dies a quiet death.
-
-
-
-
-Gilbert [Page 4]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
-Client behaviour
-
-
- When a client receives the renumbering option in a DHCPACK packet, it
- MUST immediately initialize a new state machine for handling the new
- address. The old state machine SHOULD NOT attempt to renegotiate the
- lease after this point, and may terminate at any time thereafter, up
- to and including the termination of the lease. When the lease
- expires, the client MUST stop using that address and SHOULD release
- all resources related to that address.
-
- When the new state machine is initialized, it starts in the INIT
- state. Once it starts, it is responsible for acquiring a post-
- renumbering address and keeping this address on the interface; the
- responsibilities of the old state machine are now limited to deciding
- when to terminate.
-
- The renumbering option MUST be returned in the client's DHCPINIT
- message exactly as it was included in the DHCPACK message. The state
- machine then proceeds as normal, completely separate from the
- original state machine. When it receives a DHCPACK (for the *new*
- address), it SHOULD, if possible, arrange that the new address will
- be the address used by default on that particular interface. This
- means that any new transport connections should be bound to the new
- address, and that datagram protocols should switch to the new address
- as soon as practical.
-
-
- When a client receives the renumbering option in a DHCPACK packet,
- the client does the following:
-
- (1) If the received DHCPACK packet causes the DHCP state machine
- transition from Requesting to Bound state, then the client checks
- whether it has another DHCP state machine. If such a machine
- exists, then the client sends a DHCPRELEASE on the new machine,
- and terminates the new machine. The old machine continues to
- operate according to the normal DHCP operations. If no such (old)
- machine exists, then the new machine starts to operate according
- to the normal DHCP operations.
-
- (2) If the DHCPACK packet is received when the state machine is
-
-
-
-Gilbert [Page 5]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
- already in Bound, or Renewing, or Rebinding state, then the client
- marks the state machine as "deprecated" and immediately initiates
- another state machine. When the new state machine is initialized,
- it starts in the INIT state. The renumbering option MUST be
- returned in the client's DHCPINIT message exactly as it was
- included in the DHCPACK message. The state machine then proceeds
- as normal, completely separate from the original state machine.
- Once the new state machine starts, it attempts to acquire a post-
- renumbering address. If the attempt is successful, the client
- assigns this address on the interface; the responsibilities of the
- old state machine at that point would become limited to deciding
- when to terminate.
-
- When a client receives a DHCPACK packet without the renumbering
- option the client does the following:
-
- (1) If the received DHCPACK causes the DHCP state machine to
- transition into the Bound state, the client checks if it has
- another state machine which is marked as "deprecated". If yes,
- then the client SHOULD start using the newly acquired address for
- all the new transport connections, and that datagram protocols
- SHOULD switch to the new address as soon as practical. The
- existing connections are still bound to the old address (the
- address associated with the "deprecated" state machine). The
- "deprecated" machine SHOULD NOT attempt to renegotiate the lease
- after this point, and may terminate at any time thereafter, up to
- and including the termination of the lease. When the lease on the
- address associated with the "deprecated" state machine expires,
- the client MUST stop using that address and SHOULD release all
- resources related to that address.
-
- (2) In all other cases the client follows the standard DHCP
- procedures.
-
-
-
-Server behaviour
-
-
- As part of its database of addresses, a DHCP server MUST maintain
- state information for every address (or block of addresses)
-
-
-
-Gilbert [Page 6]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
- indicating whether that address is deprecated. When a DHCPREQUEST
- arrives, the server MUST check this state information.
-
- If the address being requested is not deprecated, the server
- continues as provided in RFC 1541. If, however, the address has been
- deprecated the server prepares a DHCPACK using the remainder of the
- available lease time, and in addition adds a renumbering option. The
- method of choosing a value for the renumbering option is an
- implentation decision. The server should be prepared to handle
- further negotiations on the deprecated address, even though the
- client is expected to stop such negotiations once it attempts to
- acquire a replacement address.
-
- If the server has no post-renumbering addresses available to offer to
- the client, it SHOULD offer the previous, deprecated address, in
- order to signal the problem to the client.
-
-
-
-Relay Agent behaviour
-
-
- The only requirement that this proposal places on relay agents is
- that they MUST place a "new" (i.e., post-renumbering) address for
- itself in the 'giaddr' field when passing on a DHCP message. Since
- this can, in the worst case, be accomplished by hand-configuration,
- modifications to relay agent software are not absolutely necessary.
-
-
-
-Discussion
-
-
- The option's cookie can be used for anything that the server wants.
- Two obvious possibilities are that it could be common across the
- whole renumbering, and that it could represent a binding to a
- particular client. Because the client's new state machine starts in
- INIT, the server will be able to gather subnet information from the
- broadcast DHCPDISCOVER.
-
- The idea behind using a new option to tell the client to initiate
-
-
-
-Gilbert [Page 7]
-
-DRAFT Graceful renumbering of networks with DHCP April 1996
-
-
- this process is that it avoids all of the problems that I saw in
- (Yakov Rekhter's) original version of this proposal. Those had to do
- with figuring out when to shut down a new state machine, and with the
- extra traffic from sending an extra DHCPDISCOVER every time you went
- back into the BOUND state.
-
-
-Acknowledgements
-
-
- This document owes a great deal to Yakov Rekhter's initial
- suggestions on the same subject. Input from both him and Ralph Droms
- had significant further effect on the document.
-
-
-References
-
-
- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
- Bucknell University, October 1993.
-
-Security Considerations
-
-
- Security issues are not discussed in this document.
-
-Author's Address
-
- Lowell Gilbert
- Lowell@Epilogue.Com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilbert [Page 8]
diff --git a/doc/draft-ietf-dhc-dhcp-09.txt b/doc/rfc2131.txt
index 399e2de3..f45d9b86 100644
--- a/doc/draft-ietf-dhc-dhcp-09.txt
+++ b/doc/rfc2131.txt
@@ -1,61 +1,44 @@
-Network Working Group R. Droms
-INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-dhcp-08.txt December 1996
- Expires June 1997
- Dynamic Host Configuration Protocol
- <draft-ietf-dhc-dhcp-09.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.
+Network Working Group R. Droms
+Request for Comments: 2131 Bucknell University
+Obsoletes: 1541 March 1997
+Category: Standards Track
+
+ Dynamic Host Configuration Protocol
- 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.''
+Status of this memo
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework
- for passing configuration information to hosts on a TCP/IP network.
+ for passing configuration information to hosts on a TCPIP network.
DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
capability of automatic allocation of reusable network addresses and
additional configuration options [19]. DHCP captures the behavior of
BOOTP relay agents [7, 21], and DHCP participants can interoperate
with BOOTP participants [9].
-
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
- 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 5
+ 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
-
-
-
-Droms [Page 1]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
2.1 Configuration parameters repository . . . . . . . . . . . . . 11
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
@@ -65,22 +48,28 @@ DRAFT Dynamic Host Configuration Protocol December 1996
3.3 Interpretation and representation of time values. . . . . . . 20
3.4 Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 20
+ 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
+
+
+
+Droms Standards Track [Page 1]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
- 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 33
- 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .40
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .41
- 7. Security Considerations. . . . . . . . . . . . . . . . . . . .42
- 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .43
- A. Host Configuration Parameters . . . . . . . . . . . . . . . .44
-
+ 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
+ 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
+ 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
+ A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
List of Figures
-
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
3. Timeline diagram of messages exchanged between DHCP client and
@@ -88,9 +77,7 @@ List of Figures
4. Timeline diagram of messages exchanged between DHCP client and
servers when reusing a previously allocated network address. . 18
5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
-
List of Tables
-
1. Description of fields in a DHCP message. . . . . . . . . . . . 10
2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
@@ -105,13 +92,6 @@ List of Tables
DHCP server to a host and a mechanism for allocation of network
addresses to hosts.
-
-
-Droms [Page 2]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
DHCP is built on a client-server model, where designated DHCP server
hosts allocate network addresses and deliver configuration parameters
to dynamically configured hosts. Throughout the remainder of this
@@ -128,6 +108,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
dissimilar kinds of network hardware, values for those parameters
cannot be guessed or assumed to have correct defaults. Also,
distributed address allocation schemes depend on a polling/defense
+
+
+
+Droms Standards Track [Page 2]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
mechanism for discovery of addresses that are already in use. IP
hosts may not always be able to defend their network addresses, so
that such a distributed address allocation scheme cannot be
@@ -160,14 +148,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
The format of DHCP messages is based on the format of BOOTP messages,
to capture the BOOTP relay agent behavior described as part of the
-
-
-
-Droms [Page 3]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
BOOTP specification [7, 21] and to allow interoperability of existing
BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
the necessity of having a DHCP server on each physical network
@@ -184,6 +164,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
changes have been made to clarify the text as a result of experience
gained in DHCP interoperability tests.
+
+
+
+Droms Standards Track [Page 3]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
1.2 Related Work
There are several Internet protocols and related mechanisms that
@@ -216,14 +204,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
automate the configuration of new hosts in an existing network.
In other related work, the path minimum transmission unit (MTU)
-
-
-
-Droms [Page 4]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
discovery algorithm can determine the MTU of an arbitrary internet
path [14]. The Address Resolution Protocol (ARP) has been proposed
as a transport protocol for resource location and selection [6].
@@ -239,6 +219,15 @@ DRAFT Dynamic Host Configuration Protocol December 1996
with any other host in the Internet. The TCP/IP stack parameters
supplied by DHCP are listed in Appendix A.
+
+
+
+
+Droms Standards Track [Page 4]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
Not all of these parameters are required for a newly initialized
client. A client and server may negotiate for the transmission of
only those parameters required by the client or specific to a
@@ -267,19 +256,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
This phrase means that the item is an absolute prohibition
of this specification.
-
-
-
-
-
-
-
-
-Droms [Page 5]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
@@ -295,6 +271,19 @@ DRAFT Dynamic Host Configuration Protocol December 1996
and the case carefully weighed before implementing any behavior
described with this label.
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 5]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
o "MAY"
This word or the adjective "OPTIONAL" means that this item is
@@ -309,38 +298,26 @@ DRAFT Dynamic Host Configuration Protocol December 1996
o "DHCP client"
- A DHCP client is an Internet host using DHCP to obtain
- configuration parameters such as a network address.
+ A DHCP client is an Internet host using DHCP to obtain
+ configuration parameters such as a network address.
o "DHCP server"
- A DHCP server is an Internet host that returns configuration
- parameters to DHCP clients.
+ A DHCP server is an Internet host that returns configuration
+ parameters to DHCP clients.
o "BOOTP relay agent"
- A BOOTP relay agent or relay agent is an Internet host or router that
- passes DHCP messages between DHCP clients and DHCP servers. DHCP is
- designed to use the same relay agent behavior as specified in
- the BOOTP protocol specification.
-
-
-
-
-
-
-
-
-Droms [Page 6]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
+ A BOOTP relay agent or relay agent is an Internet host or router
+ that passes DHCP messages between DHCP clients and DHCP servers.
+ DHCP is designed to use the same relay agent behavior as specified
+ in the BOOTP protocol specification.
o "binding"
- A binding is a collection of configuration parameters, including
- at least an IP address, associated with or "bound to" a DHCP
- client. Bindings are managed by DHCP servers.
+ A binding is a collection of configuration parameters, including
+ at least an IP address, associated with or "bound to" a DHCP
+ client. Bindings are managed by DHCP servers.
1.6 Design goals
@@ -352,22 +329,34 @@ DRAFT Dynamic Host Configuration Protocol December 1996
should be able to enforce local policies concerning allocation
and access to local resources where desired.
- o Clients should require no manual configuration. Each client should
- be able to discover appropriate local configuration parameters
- without user intervention and incorporate those parameters into
- its own configuration.
+
+
+
+
+
+
+Droms Standards Track [Page 6]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ o Clients should require no manual configuration. Each client
+ should be able to discover appropriate local configuration
+ parameters without user intervention and incorporate those
+ parameters into its own configuration.
o Networks should require no manual configuration for individual
- clients. Under normal circumstances, the network manager should
- not have to enter any per-client configuration parameters.
+ clients. Under normal circumstances, the network manager
+ should not have to enter any per-client configuration
+ parameters.
o DHCP should not require a server on each subnet. To allow for
scale and economy, DHCP must work across routers or through the
intervention of BOOTP relay agents.
- o A DHCP client must be prepared to receive multiple responses to a
- request for configuration parameters. Some installations may
- include multiple, overlapping DHCP servers to enhance
+ o A DHCP client must be prepared to receive multiple responses
+ to a request for configuration parameters. Some installations
+ may include multiple, overlapping DHCP servers to enhance
reliability and increase performance.
o DHCP must coexist with statically configured, non-participating
@@ -381,27 +370,17 @@ DRAFT Dynamic Host Configuration Protocol December 1996
The following list gives design goals specific to the transmission of
the network layer parameters. DHCP must:
-
-
-
-
-
-
-Droms [Page 7]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
o Guarantee that any specific network address will not be in
use by more than one DHCP client at a time,
- o Retain DHCP client configuration across DHCP client reboot. A DHCP
- client should, whenever possible, be assigned the same configuration
- parameters (e.g., network address) in response to each request,
+ o Retain DHCP client configuration across DHCP client reboot. A
+ DHCP client should, whenever possible, be assigned the same
+ configuration parameters (e.g., network address) in response
+ to each request,
- o Retain DHCP client configuration across server reboots, and, whenever
- possible, a DHCP client should be assigned the same configuration
- parameters despite restarts of the DHCP mechanism,
+ o Retain DHCP client configuration across server reboots, and,
+ whenever possible, a DHCP client should be assigned the same
+ configuration parameters despite restarts of the DHCP mechanism,
o Allow automated assignment of configuration parameters to new
clients to avoid hand configuration for new clients,
@@ -409,6 +388,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
o Support fixed or permanent allocation of configuration
parameters to specific clients.
+
+
+
+Droms Standards Track [Page 7]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
2. Protocol Summary
From the client's point of view, DHCP is an extension of the BOOTP
@@ -443,9 +430,26 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 8]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 8]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
0 1 2 3
@@ -499,9 +503,9 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 9]
+Droms Standards Track [Page 9]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
DHCP clarifies the interpretation of the 'siaddr' field as the
@@ -531,8 +535,8 @@ DRAFT Dynamic Host Configuration Protocol December 1996
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
- BOUND, RENEW or REBINDING state and can respond to ARP
- requests.
+ BOUND, RENEW or REBINDING state and can respond
+ to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
@@ -546,7 +550,7 @@ DRAFT Dynamic Host Configuration Protocol December 1996
options var Optional parameters field. See the options
documents for a list of defined options.
- Table 1: Description of fields in a DHCP message
+ Table 1: Description of fields in a DHCP message
The 'options' field is now variable length. A DHCP client must be
prepared to receive DHCP messages with an 'options' field of at least
@@ -555,9 +559,9 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 10]
+Droms Standards Track [Page 10]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
datagram size an IP host must be prepared to accept [3]. DHCP
@@ -575,8 +579,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
clients that cannot accept hardware unicast datagrams before the
TCP/IP software is configured.
-
-
To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
@@ -598,7 +600,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
Figure 2: Format of the 'flags' field
-
2.1 Configuration parameters repository
The first service provided by DHCP is to provide persistent storage
@@ -609,15 +610,16 @@ DRAFT Dynamic Host Configuration Protocol December 1996
subnet) and the value contains the configuration parameters for the
client.
+ For example, the key might be the pair (IP-subnet-number, hardware-
+ address) (note that the "hardware-address" should be typed by the
+
-Droms [Page 11]
+Droms Standards Track [Page 11]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
- For example, the key might be the pair (IP-subnet-number, hardware-
- address) (note that the "hardware-address" should be typed by the
type of hardware to accommodate possible duplication of hardware
addresses resulting from bit-ordering problems in a mixed-media,
bridged network) allowing for serial or concurrent reuse of a
@@ -629,13 +631,11 @@ DRAFT Dynamic Host Configuration Protocol December 1996
the network interface failed and was replaced). The protocol defines
that the key will be (IP-subnet-number, hardware-address) unless the
client explicitly supplies an identifier using the 'client
- identifier' option.
-
- A client can query the DHCP service to retrieve its configuration
- parameters. The client interface to the configuration parameters
- repository consists of protocol messages to request configuration
- parameters and responses from the server carrying the configuration
- parameters.
+ identifier' option. A client can query the DHCP service to
+ retrieve its configuration parameters. The client interface to the
+ configuration parameters repository consists of protocol messages to
+ request configuration parameters and responses from the server
+ carrying the configuration parameters.
2.2 Dynamic allocation of network addresses
@@ -664,16 +664,16 @@ DRAFT Dynamic Host Configuration Protocol December 1996
address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address,
+ e.g., with an ICMP echo request, and the client SHOULD probe the
+ newly received address, e.g., with ARP.
-Droms [Page 12]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
- e.g., with an ICMP echo request, and the client SHOULD probe the
- newly received address, e.g., with ARP.
+Droms Standards Track [Page 12]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
3. The Client-Server Protocol
@@ -717,17 +717,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
agents may pass the message on to DHCP servers not on the same
physical subnet.
-
-
-
-
-
-
-Droms [Page 13]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other
configuration parameters in DHCP options). Servers need not
@@ -735,6 +724,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
work more efficiently if the server avoids allocating the offered
network address to another client. When allocating a new address,
servers SHOULD check that the offered network address is not
+
+
+
+Droms Standards Track [Page 13]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
already in use; e.g., the server may probe the offered address
with an ICMP Echo Request. Servers SHOULD be implemented so that
network administrators MAY choose to disable probes of newly
@@ -779,9 +776,16 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 14]
+
+
+
+
+
+
+
+Droms Standards Track [Page 14]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
Server Client Server
@@ -791,22 +795,22 @@ DRAFT Dynamic Host Configuration Protocol December 1996
| | |
| Begins initialization |
| | |
- | _____________/|\_____________ |
- |/ DHCPDISCOVER | DHCPDISCOVER \|
+ | _____________/|\____________ |
+ |/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
- |\ | ____________/|
- | \_________ | /DHCPOFFER |
- | DHCPOFFER\ |/ |
- | \ | |
+ |\ | ____________/ |
+ | \________ | /DHCPOFFER |
+ | DHCPOFFER\ |/ |
+ | \ | |
| Collects replies |
- | \| |
+ | \| |
| Selects configuration |
| | |
- | _____________/|\_____________ |
- |/ DHCPREQUEST | DHCPREQUEST \|
+ | _____________/|\____________ |
+ |/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
@@ -820,8 +824,8 @@ DRAFT Dynamic Host Configuration Protocol December 1996
| | |
| Graceful shutdown |
| | |
- | |\_____________ |
- | | DHCPRELEASE \|
+ | |\ ____________ |
+ | | DHCPRELEASE \|
| | |
| | Discards lease
| | |
@@ -835,9 +839,9 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 15]
+Droms Standards Track [Page 15]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
3. The client receives one or more DHCPOFFER messages from one or more
@@ -891,9 +895,9 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 16]
+Droms Standards Track [Page 16]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
point, the client is configured. If the client detects that the
@@ -937,6 +941,21 @@ DRAFT Dynamic Host Configuration Protocol December 1996
shows the timing relationships in a typical client-server interaction
for a client reusing a previously allocated network address.
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 17]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
1. The client broadcasts a DHCPREQUEST message on its local subnet.
The message includes the client's network address in the
'requested IP address' option. As the client has not received its
@@ -944,14 +963,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
relay agents pass the message on to DHCP servers not on the same
subnet. If the client used a 'client identifier' to obtain its
address, the client MUST use the same 'client identifier' in the
-
-
-
-Droms [Page 17]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
DHCPREQUEST message.
2. Servers with knowledge of the client's configuration parameters
@@ -962,124 +973,122 @@ DRAFT Dynamic Host Configuration Protocol December 1996
Server Client Server
v v v
- | | |
- | Begins |
- | initialization |
- | | |
- | /|\ |
- | ___________/ | \___________ |
- | /DHCPREQUEST | DHCPREQUEST\ |
- |/ | \|
- | | |
- Locates | Locates
- configuration | configuration
- | | |
- |\ | /|
- | \ | ___________/ |
- | \ | / DHCPACK |
- | \_______ |/ |
- | DHCPACK\ | |
- | Initialization |
- | complete |
- | \| |
- | | |
- | (Subsequent |
- | DHCPACKS |
- | ignored) |
- | | |
- | | |
- v v v
+ | | |
+ | Begins |
+ | initialization |
+ | | |
+ | /|\ |
+ | _________ __/ | \__________ |
+ | /DHCPREQU EST | DHCPREQUEST\ |
+ |/ | \|
+ | | |
+ Locates | Locates
+ configuration | configuration
+ | | |
+ |\ | /|
+ | \ | ___________/ |
+ | \ | / DHCPACK |
+ | \ _______ |/ |
+ | DHCPACK\ | |
+ | Initialization |
+ | complete |
+ | \| |
+ | | |
+ | (Subsequent |
+ | DHCPACKS |
+ | ignored) |
+ | | |
+ | | |
+ v v v
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network address
- If the client's request is invalid (e.g., the client has moved
- to a new subnet), servers SHOULD respond with a DHCPNAK message to
- the client. Servers SHOULD NOT respond if their information is not
- guaranteed to be accurate. For example, a server that identifies a
- request for an expired binding that is owned by another server SHOULD
-
-
-Droms [Page 18]
+Droms Standards Track [Page 18]
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- NOT respond with a DHCPNAK unless the servers are using an explicit
- mechanism to maintain coherency among the servers.
-
- If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
- the same subnet as the server. The server MUST
- broadcast the DHCPNAK message to the 0xffffffff broadcast address
- because the client may not have a correct network address or subnet
- mask, and the client may not be answering ARP requests.
- Otherwise, the server MUST send the DHCPNAK message to the IP
- address of the BOOTP relay agent, as recorded in 'giaddr'. The
- relay agent will, in turn, forward the message directly to the
- client's hardware address, so that the DHCPNAK can be delivered even
- if the client has moved to a new network.
-
- 3. The client receives the DHCPACK message with configuration
- parameters. The client performs a final check on the parameters
- (as in section 3.1), and notes the duration of the lease specified
- in the DHCPACK message. The specific lease is implicitly identified
- by the 'client identifier' or 'chaddr' and the network address. At
- this point, the client is configured.
-
- If the client detects that the IP address in the DHCPACK message
- is already in use, the client MUST send a DHCPDECLINE message to the
- server and restarts the configuration process by requesting a
- new network address. This action corresponds to the client
- moving to the INIT state in the DHCP state diagram, which is
- described in section 4.4.
-
- If the client receives a DHCPNAK message, it cannot reuse its
- remembered network address. It must instead request a new
- address by restarting the configuration process, this time
- using the (non-abbreviated) procedure described in section
- 3.1. This action also corresponds to the client moving to
- the INIT state in the DHCP state diagram.
-
- The client times out and retransmits the DHCPREQUEST message if
- the client receives neither a DHCPACK nor a DHCPNAK message. The
- client retransmits the DHCPREQUEST according to the retransmission
- algorithm in section 4.1. The client should choose to retransmit
- the DHCPREQUEST enough times to give adequate probability of
- contacting the server without causing the client (and the user of
- that client) to wait overly long before giving up; e.g., a client
- retransmitting as described in section 4.1 might retransmit the
- DHCPREQUEST message four times, for a total delay of 60 seconds,
- before restarting the initialization procedure. If the client
- receives neither a DHCPACK or a DHCPNAK message after employing
- the retransmission algorithm, the client MAY choose to use the
- previously allocated network address and configuration parameters
-
-
-
-Droms [Page 19]
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ If the client's request is invalid (e.g., the client has moved
+ to a new subnet), servers SHOULD respond with a DHCPNAK message to
+ the client. Servers SHOULD NOT respond if their information is not
+ guaranteed to be accurate. For example, a server that identifies a
+ request for an expired binding that is owned by another server SHOULD
+ NOT respond with a DHCPNAK unless the servers are using an explicit
+ mechanism to maintain coherency among the servers.
+
+ If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
+ the same subnet as the server. The server MUST
+ broadcast the DHCPNAK message to the 0xffffffff broadcast address
+ because the client may not have a correct network address or subnet
+ mask, and the client may not be answering ARP requests.
+ Otherwise, the server MUST send the DHCPNAK message to the IP
+ address of the BOOTP relay agent, as recorded in 'giaddr'. The
+ relay agent will, in turn, forward the message directly to the
+ client's hardware address, so that the DHCPNAK can be delivered even
+ if the client has moved to a new network.
+
+ 3. The client receives the DHCPACK message with configuration
+ parameters. The client performs a final check on the parameters
+ (as in section 3.1), and notes the duration of the lease specified
+ in the DHCPACK message. The specific lease is implicitly identified
+ by the 'client identifier' or 'chaddr' and the network address. At
+ this point, the client is configured.
+
+ If the client detects that the IP address in the DHCPACK message
+ is already in use, the client MUST send a DHCPDECLINE message to the
+ server and restarts the configuration process by requesting a
+ new network address. This action corresponds to the client
+ moving to the INIT state in the DHCP state diagram, which is
+ described in section 4.4.
+
+ If the client receives a DHCPNAK message, it cannot reuse its
+ remembered network address. It must instead request a new
+ address by restarting the configuration process, this time
+ using the (non-abbreviated) procedure described in section
+ 3.1. This action also corresponds to the client moving to
+ the INIT state in the DHCP state diagram.
+
+ The client times out and retransmits the DHCPREQUEST message if
+ the client receives neither a DHCPACK nor a DHCPNAK message. The
+ client retransmits the DHCPREQUEST according to the retransmission
+ algorithm in section 4.1. The client should choose to retransmit
+ the DHCPREQUEST enough times to give adequate probability of
+ contacting the server without causing the client (and the user of
+ that client) to wait overly long before giving up; e.g., a client
+ retransmitting as described in section 4.1 might retransmit the
+
+
+
+Droms Standards Track [Page 19]
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- for the remainder of the unexpired lease. This corresponds to
- moving to BOUND state in the client state transition diagram shown
- in figure 5.
-
- 4. The client may choose to relinquish its lease on a network
- address by sending a DHCPRELEASE message to the server. The
- client identifies the lease to be released with its
- 'client identifier', or 'chaddr' and network address in the
- DHCPRELEASE message.
-
- Note that in this case, where the client retains its network
- address locally, the client will not normally relinquish its
- lease during a graceful shutdown. Only in the case where the
- client explicitly needs to relinquish its lease, e.g., the client
- is about to be moved to a different subnet, will the client send
- a DHCPRELEASE message.
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ DHCPREQUEST message four times, for a total delay of 60 seconds,
+ before restarting the initialization procedure. If the client
+ receives neither a DHCPACK or a DHCPNAK message after employing
+ the retransmission algorithm, the client MAY choose to use the
+ previously allocated network address and configuration parameters
+ for the remainder of the unexpired lease. This corresponds to
+ moving to BOUND state in the client state transition diagram shown
+ in figure 5.
+
+ 4. The client may choose to relinquish its lease on a network
+ address by sending a DHCPRELEASE message to the server. The
+ client identifies the lease to be released with its
+ 'client identifier', or 'chaddr' and network address in the
+ DHCPRELEASE message.
+
+ Note that in this case, where the client retains its network
+ address locally, the client will not normally relinquish its
+ lease during a graceful shutdown. Only in the case where the
+ client explicitly needs to relinquish its lease, e.g., the client
+ is about to be moved to a different subnet, will the client send
+ a DHCPRELEASE message.
3.3 Interpretation and representation of time values
@@ -1107,19 +1116,19 @@ DRAFT Dynamic Host Configuration Protocol December 1996
If a client has obtained a network address through some other means
(e.g., manual configuration), it may use a DHCPINFORM request message
- to obtain other local configuration parameters. Servers receiving a
- DHCPINFORM message construct a DHCPACK message with any local
- configuration parameters appropriate for the client without:
- allocating a new address, checking for an existing binding, filling
- in 'yiaddr' or including lease time parameters. The servers SHOULD
-Droms [Page 20]
+Droms Standards Track [Page 20]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ to obtain other local configuration parameters. Servers receiving a
+ DHCPINFORM message construct a DHCPACK message with any local
+ configuration parameters appropriate for the client without:
+ allocating a new address, checking for an existing binding, filling
+ in 'yiaddr' or including lease time parameters. The servers SHOULD
unicast the DHCPACK reply to the address given in the 'ciaddr' field
of the DHCPINFORM message.
@@ -1163,19 +1172,19 @@ DRAFT Dynamic Host Configuration Protocol December 1996
option to suggest the lease time it would like. Other options
representing "hints" at configuration parameters are allowed in a
DHCPDISCOVER or DHCPREQUEST message. However, additional options may
- be ignored by servers, and multiple servers may, therefore, not
- return identical values for some options. The 'requested IP address'
- option is to be filled in only in a DHCPREQUEST message when the
- client is verifying network parameters obtained previously. The
- client fills in the 'ciaddr' field only when correctly configured
-Droms [Page 21]
+Droms Standards Track [Page 21]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ be ignored by servers, and multiple servers may, therefore, not
+ return identical values for some options. The 'requested IP address'
+ option is to be filled in only in a DHCPREQUEST message when the
+ client is verifying network parameters obtained previously. The
+ client fills in the 'ciaddr' field only when correctly configured
with an IP address in BOUND, RENEWING or REBINDING state.
If a server receives a DHCPREQUEST message with an invalid 'requested
@@ -1219,19 +1228,19 @@ DRAFT Dynamic Host Configuration Protocol December 1996
tagged data items in the variable length option area. The options
area includes first a four-octet 'magic cookie' (which was described
in section 3), followed by the options. The last option must always
- be the 'end' option.
- DHCP uses UDP as its transport protocol. DHCP messages from a client
- to a server are sent to the 'DHCP server' port (67), and DHCP
- messages from a server to a client are sent to the 'DHCP client' port
-
-Droms [Page 22]
+Droms Standards Track [Page 22]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+ be the 'end' option.
+ DHCP uses UDP as its transport protocol. DHCP messages from a client
+ to a server are sent to the 'DHCP server' port (67), and DHCP
+ messages from a server to a client are sent to the 'DHCP client' port
(68). A server with multiple network address (e.g., a multi-homed
host) MAY use any of its network addresses in outgoing DHCP messages.
@@ -1275,19 +1284,19 @@ DRAFT Dynamic Host Configuration Protocol December 1996
If the options in a DHCP message extend into the 'sname' and 'file'
fields, the 'option overload' option MUST appear in the 'options'
field, with value 1, 2 or 3, as specified in RFC 1533. If the
- 'option overload' option is present in the 'options' field, the
- options in the 'options' field MUST be terminated by an 'end' option,
- and MAY contain one or more 'pad' options to fill the options field.
- The options in the 'sname' and 'file' fields (if in use as indicated
- by the 'options overload' option) MUST begin with the first octet of
-Droms [Page 23]
+Droms Standards Track [Page 23]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ 'option overload' option is present in the 'options' field, the
+ options in the 'options' field MUST be terminated by an 'end' option,
+ and MAY contain one or more 'pad' options to fill the options field.
+ The options in the 'sname' and 'file' fields (if in use as indicated
+ by the 'options overload' option) MUST begin with the first octet of
the field, MUST be terminated by an 'end' option, and MUST be
followed by 'pad' options to fill the remainder of the field. Any
individual option in the 'options', 'sname' and 'file' fields MUST be
@@ -1332,18 +1341,17 @@ DRAFT Dynamic Host Configuration Protocol December 1996
client may choose to reuse the same 'xid' or select a new 'xid' for
each retransmitted message.
- Normally, DHCP servers and BOOTP relay agents attempt to deliver
- DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
- unicast delivery. The IP destination address (in the IP header) is
- set to the DHCP 'yiaddr' address and the link-layer destination
-
-Droms [Page 24]
+Droms Standards Track [Page 24]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ Normally, DHCP servers and BOOTP relay agents attempt to deliver
+ DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
+ uicast delivery. The IP destination address (in the IP header) is
+ set to the DHCP 'yiaddr' address and the link-layer destination
address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
@@ -1388,18 +1396,18 @@ DRAFT Dynamic Host Configuration Protocol December 1996
interact; it is beyond the scope of the DHCP specification to
describe all of the administrative controls that system
administrators might want to use. Specific DHCP server
- implementations may incorporate any controls or policies desired by a
- network administrator.
-
- In some environments, a DHCP server will have to consider the values
-Droms [Page 25]
+Droms Standards Track [Page 25]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ implementations may incorporate any controls or policies desired by a
+ network administrator.
+
+ In some environments, a DHCP server will have to consider the values
of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
messages when determining the correct parameters for a particular
client.
@@ -1444,18 +1452,18 @@ DRAFT Dynamic Host Configuration Protocol December 1996
o DHCPINFORM
- Table 3 gives the use of the fields and options in a DHCP message by
- a server. The remainder of this section describes the action of the
- DHCP server for each possible incoming message.
-
-Droms [Page 26]
+Droms Standards Track [Page 26]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ Table 3 gives the use of the fields and options in a DHCP message by
+ a server. The remainder of this section describes the action of the
+ DHCP server for each possible incoming message.
+
4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
@@ -1464,20 +1472,20 @@ DRAFT Dynamic Host Configuration Protocol December 1996
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
- o The client's current address as recorded in the client's current
- binding, ELSE
+ o The client's current address as recorded in the client's current
+ binding, ELSE
- o The client's previous address as recorded in the client's (now
- expired or released) binding, if that address is in the server's
- pool of available addresses and not already allocated, ELSE
+ o The client's previous address as recorded in the client's (now
+ expired or released) binding, if that address is in the server's
+ pool of available addresses and not already allocated, ELSE
- o The address requested in the 'Requested IP Address' option, if that
- address is valid and not already allocated, ELSE
+ o The address requested in the 'Requested IP Address' option, if that
+ address is valid and not already allocated, ELSE
- o A new address allocated from the server's pool of available
- addresses; the address is selected based on the subnet from which
- the message was received (if 'giaddr' is 0) or on the address of
- the relay agent that forwarded the message ('giaddr' when not 0).
+ o A new address allocated from the server's pool of available
+ addresses; the address is selected based on the subnet from which
+ the message was received (if 'giaddr' is 0) or on the address of
+ the relay agent that forwarded the message ('giaddr' when not 0).
As described in section 4.2, a server MAY, for administrative
reasons, assign an address other than the one requested, or may
@@ -1501,17 +1509,16 @@ DRAFT Dynamic Host Configuration Protocol December 1996
The server must also choose an expiration time for the lease, as
follows:
- o IF the client has not requested a specific lease in the
- DHCPDISCOVER message and the client already has an assigned network
- address, the server returns the lease expiration time previously
-
-Droms [Page 27]
+Droms Standards Track [Page 27]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ o IF the client has not requested a specific lease in the
+ DHCPDISCOVER message and the client already has an assigned network
+ address, the server returns the lease expiration time previously
assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a
previously assigned address), ELSE
@@ -1527,103 +1534,61 @@ DRAFT Dynamic Host Configuration Protocol December 1996
lease (if the lease is acceptable to local policy) or select
another lease.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 28]
+Field DHCPOFFER DHCPACK DHCPNAK
+----- --------- ------- -------
+'op' BOOTREPLY BOOTREPLY BOOTREPLY
+'htype' (From "Assigned Numbers" RFC)
+'hlen' (Hardware address length in octets)
+'hops' 0 0 0
+'xid' 'xid' from client 'xid' from client 'xid' from client
+ DHCPDISCOVER DHCPREQUEST DHCPREQUEST
+ message message message
+'secs' 0 0 0
+'ciaddr' 0 'ciaddr' from 0
+ DHCPREQUEST or 0
+'yiaddr' IP address offered IP address 0
+ to client assigned to client
+'siaddr' IP address of next IP address of next 0
+ bootstrap server bootstrap server
+'flags' 'flags' from 'flags' from 'flags' from
+ client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
+ message message message
+'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
+ client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
+ message message message
+'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
+ client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
+ message message message
+'sname' Server host name Server host name (unused)
+ or options or options
+'file' Client boot file Client boot file (unused)
+ name or options name or options
+'options' options options
+
+
+
+Droms Standards Track [Page 28]
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- Field DHCPOFFER DHCPACK DHCPNAK
- ----- --------- ------- -------
- 'op' BOOTREPLY BOOTREPLY BOOTREPLY
- 'htype' (From "Assigned Numbers" RFC)
- 'hlen' (Hardware address length in octets)
- 'hops' 0 0 0
- 'xid' 'xid' from client 'xid' from client 'xid' from client
- DHCPDISCOVER DHCPREQUEST DHCPREQUEST
- message message message
- 'secs' 0 0 0
- 'ciaddr' 0 'ciaddr' from 0
- DHCPREQUEST or 0
- 'yiaddr' IP address offered IP address 0
- to client assigned to client
- 'siaddr' IP address of next IP address of next 0
- bootstrap server bootstrap server
- 'flags' 'flags' from 'flags' from 'flags' from
- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
- message message message
- 'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
- message message message
- 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
- message message message
- 'sname' Server host name Server host name (unused)
- or options or options
- 'file' Client boot file Client boot file (unused)
- name or options name or options
- 'options' options options
-
- Option DHCPOFFER DHCPACK DHCPNAK
- ------ --------- ------- -------
- Requested IP address MUST NOT MUST NOT MUST NOT
- IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
- MUST NOT (DHCPINFORM)
- Use 'file'/'sname' fields MAY MAY MUST NOT
- DHCP message type DHCPOFFER DHCPACK DHCPNAK
- Parameter request list MUST NOT MUST NOT MUST NOT
- Message SHOULD SHOULD SHOULD
- Client identifier MUST NOT MUST NOT MAY
- Vendor class identifier MAY MAY MAY
- Server identifier MUST MUST MUST
- Maximum message size MUST NOT MUST NOT MUST NOT
- All others MAY MAY MUST NOT
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+Option DHCPOFFER DHCPACK DHCPNAK
+------ --------- ------- -------
+Requested IP address MUST NOT MUST NOT MUST NOT
+IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
+ MUST NOT (DHCPINFORM)
+Use 'file'/'sname' fields MAY MAY MUST NOT
+DHCP message type DHCPOFFER DHCPACK DHCPNAK
+Parameter request list MUST NOT MUST NOT MUST NOT
+Message SHOULD SHOULD SHOULD
+Client identifier MUST NOT MUST NOT MAY
+Vendor class identifier MAY MAY MAY
+Server identifier MUST MUST MUST
+Maximum message size MUST NOT MUST NOT MUST NOT
+All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP servers
-
-
-
-Droms [Page 29]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
Once the network address and lease have been determined, the server
constructs a DHCPOFFER message with the offered configuration
parameters. It is important for all DHCP servers to return the same
@@ -1656,6 +1621,13 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-- The server MUST NOT return a value for that parameter,
+
+
+Droms Standards Track [Page 29]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
The server MUST supply as many of the requested parameters as
possible and MUST omit any parameters it cannot provide. The
server MUST include each requested parameter only once unless
@@ -1670,16 +1642,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
or DHCPREQUEST message), e.g., as configured by the network
administrator,
-
-
-
-
-
-Droms [Page 30]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
o Any parameters specific to this client's class (as identified
by the contents of the 'vendor class identifier'
option in the DHCPDISCOVER or DHCPREQUEST message),
@@ -1711,6 +1673,17 @@ DRAFT Dynamic Host Configuration Protocol December 1996
parameters in a DHCPDISCOVER message, it MUST include that list in
all subsequent messages.
+
+
+
+
+
+
+Droms Standards Track [Page 30]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
Any configuration parameters in the DHCPACK message SHOULD NOT
conflict with those in the earlier DHCPOFFER message to which the
client is responding. The client SHOULD use the parameters in the
@@ -1720,109 +1693,114 @@ DRAFT Dynamic Host Configuration Protocol December 1996
o DHCPREQUEST generated during SELECTING state:
- Client inserts the address of the selected server in 'server
- identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
- filled in with the yiaddr value from the chosen DHCPOFFER.
+ Client inserts the address of the selected server in 'server
+ identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
+ filled in with the yiaddr value from the chosen DHCPOFFER.
+
+ Note that the client may choose to collect several DHCPOFFER
+ messages and select the "best" offer. The client indicates its
+ selection by identifying the offering server in the DHCPREQUEST
+ message. If the client receives no acceptable offers, the client
+ may choose to try another DHCPDISCOVER message. Therefore, the
+ servers may not receive a specific DHCPREQUEST from which they can
+ decide whether or not the client has accepted the offer. Because
+ the servers have not committed any network address assignments on
+ the basis of a DHCPOFFER, servers are free to reuse offered
+ network addresses in response to subsequent requests. As an
+ implementation detail, servers SHOULD NOT reuse offered addresses
+ and may use an implementation-specific timeout mechanism to decide
+ when to reuse an offered address.
- Note that the client may choose to collect several DHCPOFFER
- messages and select the "best" offer. The client indicates its
- selection by identifying the offering server in the DHCPREQUEST
- message. If the client receives no acceptable offers, the client
+ o DHCPREQUEST generated during INIT-REBOOT state:
+ 'server identifier' MUST NOT be filled in, 'requested IP address'
+ option MUST be filled in with client's notion of its previously
+ assigned address. 'ciaddr' MUST be zero. The client is seeking to
+ verify a previously allocated, cached configuration. Server SHOULD
+ send a DHCPNAK message to the client if the 'requested IP address'
+ is incorrect, or is on the wrong network.
+
+ Determining whether a client in the INIT-REBOOT state is on the
+ correct network is done by examining the contents of 'giaddr', the
+ 'requested IP address' option, and a database lookup. If the DHCP
+ server detects that the client is on the wrong net (i.e., the
+ result of applying the local subnet mask or remote subnet mask (if
+ 'giaddr' is not zero) to 'requested IP address' option value
+ doesn't match reality), then the server SHOULD send a DHCPNAK
+ message to the client.
-Droms [Page 31]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
- may choose to try another DHCPDISCOVER message. Therefore, the
- servers may not receive a specific DHCPREQUEST from which they can
- decide whether or not the client has accepted the offer. Because
- the servers have not committed any network address assignments on
- the basis of a DHCPOFFER, servers are free to reuse offered network
- addresses in response to subsequent requests. As an implementation
- detail, servers SHOULD NOT reuse offered addresses and may use an
- implementation-specific timeout mechanism to decide when to reuse
- an offered address.
- o DHCPREQUEST generated during INIT-REBOOT state:
- 'server identifier' MUST NOT be filled in, 'requested IP address'
- option MUST be filled in with client's notion of its previously
- assigned address. 'ciaddr' MUST be zero. The client is seeking to
- verify a previously allocated, cached configuration. Server SHOULD
- send a DHCPNAK message to the client if the 'requested IP address'
- is incorrect, or is on the wrong network.
-
- Determining whether a client in the INIT-REBOOT state is on the
- correct network is done by examining the contents of 'giaddr', the
- 'requested IP address' option, and a database lookup. If the DHCP
- server detects that the client is on the wrong net (i.e., the
- result of applying the local subnet mask or remote subnet mask (if
- 'giaddr' is not zero) to 'requested IP address' option value
- doesn't match reality), then the server SHOULD send a DHCPNAK
- message to the client.
-
- If the network is correct, then the DHCP server should check if the
- client's notion of its IP address is correct. If not, then the
- server SHOULD send a DHCPNAK message to the client. If the DHCP
- server has no record of this client, then it MUST remain silent,
- and MAY output a warning to the network administrator. This
- behavior is necessary for peaceful coexistence of non-communicating
- DHCP servers on the same wire.
-
- If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on the
- same subnet as the server. The server MUST broadcast the DHCPNAK
- message to the 0xffffffff broadcast address because the client may
- not have a correct network address or subnet mask, and the client
- may not be answering ARP requests.
-
- If 'giaddr' is set in the DHCPREQUEST message, the client is on a
- different subnet. The server MUST set the broadcast bit in the
- DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
- client, because the client may not have a correct network address
- or subnet mask, and the client may not be answering ARP requests.
-
-
-
-
-Droms [Page 32]
+
+Droms Standards Track [Page 31]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ If the network is correct, then the DHCP server should check if
+ the client's notion of its IP address is correct. If not, then the
+ server SHOULD send a DHCPNAK message to the client. If the DHCP
+ server has no record of this client, then it MUST remain silent,
+ and MAY output a warning to the network administrator. This
+ behavior is necessary for peaceful coexistence of non-
+ communicating DHCP servers on the same wire.
+
+ If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
+ the same subnet as the server. The server MUST broadcast the
+ DHCPNAK message to the 0xffffffff broadcast address because the
+ client may not have a correct network address or subnet mask, and
+ the client may not be answering ARP requests.
+ If 'giaddr' is set in the DHCPREQUEST message, the client is on a
+ different subnet. The server MUST set the broadcast bit in the
+ DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
+ client, because the client may not have a correct network address
+ or subnet mask, and the client may not be answering ARP requests.
o DHCPREQUEST generated during RENEWING state:
- 'server identifier' MUST NOT be filled in, 'requested IP address'
- option MUST NOT be filled in, 'ciaddr' MUST be filled in with
- client's IP address. In this situation, the client is completely
- configured, and is trying to extend its lease. This message will be
- unicast, so no relay agents will be involved in its transmission.
- Because 'giaddr' is therefore not filled in, the DHCP server will
- trust the value in 'ciaddr', and use it when replying to the
- client.
+ 'server identifier' MUST NOT be filled in, 'requested IP address'
+ option MUST NOT be filled in, 'ciaddr' MUST be filled in with
+ client's IP address. In this situation, the client is completely
+ configured, and is trying to extend its lease. This message will
+ be unicast, so no relay agents will be involved in its
+ transmission. Because 'giaddr' is therefore not filled in, the
+ DHCP server will trust the value in 'ciaddr', and use it when
+ replying to the client.
- A client MAY choose to renew or extend its lease prior to T1. The
- server may choose not to extend the lease (as a policy decision by
- the network administrator), but should return a DHCPACK message
- regardless.
+ A client MAY choose to renew or extend its lease prior to T1. The
+ server may choose not to extend the lease (as a policy decision by
+ the network administrator), but should return a DHCPACK message
+ regardless.
o DHCPREQUEST generated during REBINDING state:
- 'server identifier' MUST NOT be filled in, 'requested IP address'
- option MUST NOT be filled in, 'ciaddr' MUST be filled in with
- client's IP address. In this situation, the client is completely
- configured, and is trying to extend its lease. This message MUST be
- broadcast to the 0xffffffff IP broadcast address. The DHCP server
- SHOULD check 'ciaddr' for correctness before replying to the
- DHCPREQUEST.
+ 'server identifier' MUST NOT be filled in, 'requested IP address'
+ option MUST NOT be filled in, 'ciaddr' MUST be filled in with
+ client's IP address. In this situation, the client is completely
+ configured, and is trying to extend its lease. This message MUST
+ be broadcast to the 0xffffffff IP broadcast address. The DHCP
+ server SHOULD check 'ciaddr' for correctness before replying to
+ the DHCPREQUEST.
+
+
+
+
+
+
+Droms Standards Track [Page 32]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
- The DHCPREQUEST from a REBINDING client is intended to accommodate
- sites that have multiple DHCP servers and a mechanism for
- maintaining consistency among leases managed by multiple servers.
- A DHCP server MAY extend a client's lease only if it has local
- administrative authority to do so.
+ The DHCPREQUEST from a REBINDING client is intended to accommodate
+ sites that have multiple DHCP servers and a mechanism for
+ maintaining consistency among leases managed by multiple servers.
+ A DHCP server MAY extend a client's lease only if it has local
+ administrative authority to do so.
4.3.3 DHCPDECLINE message
@@ -1841,13 +1819,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
4.3.5 DHCPINFORM message
-
-
-Droms [Page 33]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
The server responds to a DHCPINFORM message by sending a DHCPACK
message directly to the address given in the 'ciaddr' field of the
DHCPINFORM message. The server MUST NOT send a lease expiration time
@@ -1870,16 +1841,27 @@ DRAFT Dynamic Host Configuration Protocol December 1996
Table 4: Client messages from different states
+
+
+
+
+
+
+Droms Standards Track [Page 33]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
4.4 DHCP client behavior
Figure 5 gives a state-transition diagram for a DHCP client. A
client can receive the following messages from a server:
- o DHCPOFFER
+ o DHCPOFFER
- o DHCPACK
+ o DHCPACK
- o DHCPNAK
+ o DHCPNAK
The DHCPINFORM message is not shown in figure 5. A client simply
sends the DHCPINFORM and waits for DHCPACK messages. Once the client
@@ -1899,9 +1881,31 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 34]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 34]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
-------- -------
@@ -1955,9 +1959,9 @@ timers T1, T2 ------------ send DHCPREQUEST | |
-Droms [Page 35]
+Droms Standards Track [Page 35]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
4.4.1 Initialization and allocation of network address
@@ -2011,84 +2015,96 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-Droms [Page 36]
+Droms Standards Track [Page 36]
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
- DHCPINFORM DHCPRELEASE
- ----- ------------ ----------- -----------
- 'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
- 'htype' (From "Assigned Numbers" RFC)
- 'hlen' (Hardware address length in octets)
- 'hops' 0 0 0
- 'xid' selected by client 'xid' from server selected by
- DHCPOFFER message client
- 'secs' 0 or seconds since 0 or seconds since 0
- DHCP process started DHCP process started
- 'flags' Set 'BROADCAST' Set 'BROADCAST' 0
- flag if client flag if client
- requires broadcast requires broadcast
- reply reply
- 'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
- client's network address client's network
- network address (BOUND/RENEW/REBIND) address
- (DHCPINFORM) (DHCPRELEASE)
- 'yiaddr' 0 0 0
- 'siaddr' 0 0 0
- 'giaddr' 0 0 0
- 'chaddr' client's hardware client's hardware client's hardware
- address address address
- 'sname' options, if options, if (unused)
- indicated in indicated in
- 'sname/file' 'sname/file'
- option; otherwise option; otherwise
- unused unused
- 'file' options, if options, if (unused)
- indicated in indicated in
- 'sname/file' 'sname/file'
- option; otherwise option; otherwise
- unused unused
- 'options' options options (unused)
-
- Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
- DHCPINFORM DHCPRELEASE
- ------ ------------ ----------- -----------
- Requested IP address MAY MUST (in MUST
- (DISCOVER) SELECTING or (DHCPDECLINE),
- MUST NOT INIT-REBOOT) MUST NOT
- (INFORM) MUST NOT (in (DHCPRELEASE)
- BOUND or
- RENEWING)
- IP address lease time MAY MAY MUST NOT
- (DISCOVER)
- MUST NOT
-
-
-
-Droms [Page 37]
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
+ DHCPINFORM DHCPRELEASE
+----- ------------ ----------- -----------
+'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
+'htype' (From "Assigned Numbers" RFC)
+'hlen' (Hardware address length in octets)
+'hops' 0 0 0
+'xid' selected by client 'xid' from server selected by
+ DHCPOFFER message client
+'secs' 0 or seconds since 0 or seconds since 0
+ DHCP process started DHCP process started
+'flags' Set 'BROADCAST' Set 'BROADCAST' 0
+ flag if client flag if client
+ requires broadcast requires broadcast
+ reply reply
+'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
+ client's network address client's network
+ network address (BOUND/RENEW/REBIND) address
+ (DHCPINFORM) (DHCPRELEASE)
+'yiaddr' 0 0 0
+'siaddr' 0 0 0
+'giaddr' 0 0 0
+'chaddr' client's hardware client's hardware client's hardware
+ address address address
+'sname' options, if options, if (unused)
+ indicated in indicated in
+ 'sname/file' 'sname/file'
+ option; otherwise option; otherwise
+ unused unused
+'file' options, if options, if (unused)
+ indicated in indicated in
+ 'sname/file' 'sname/file'
+ option; otherwise option; otherwise
+ unused unused
+'options' options options (unused)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 37]
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- (INFORM)
- Use 'file'/'sname' fields MAY MAY MAY
- DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
- DHCPINFORM DHCPRELEASE
- Client identifier MAY MAY MAY
- Vendor class identifier MAY MAY MUST NOT
- Server identifier MUST NOT MUST (after MUST
- SELECTING)
- MUST NOT (after
- INIT-REBOOT,
- BOUND, RENEWING
- or REBINDING)
- Parameter request list MAY MAY MUST NOT
- Maximum message size MAY MAY MUST NOT
- Message SHOULD NOT SHOULD NOT SHOULD
- Site-specific MAY MAY MUST NOT
- All others MAY MAY MUST NOT
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
+ DHCPINFORM DHCPRELEASE
+------ ------------ ----------- -----------
+Requested IP address MAY MUST (in MUST
+ (DISCOVER) SELECTING or (DHCPDECLINE),
+ MUST NOT INIT-REBOOT) MUST NOT
+ (INFORM) MUST NOT (in (DHCPRELEASE)
+ BOUND or
+ RENEWING)
+IP address lease time MAY MAY MUST NOT
+ (DISCOVER)
+ MUST NOT
+ (INFORM)
+Use 'file'/'sname' fields MAY MAY MAY
+DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
+ DHCPINFORM DHCPRELEASE
+Client identifier MAY MAY MAY
+Vendor class identifier MAY MAY MUST NOT
+Server identifier MUST NOT MUST (after MUST
+ SELECTING)
+ MUST NOT (after
+ INIT-REBOOT,
+ BOUND, RENEWING
+ or REBINDING)
+Parameter request list MAY MAY MUST NOT
+Maximum message size MAY MAY MUST NOT
+Message SHOULD NOT SHOULD NOT SHOULD
+Site-specific MAY MAY MUST NOT
+All others MAY MAY MUST NOT
Table 5: Fields and options used by DHCP clients
@@ -2108,6 +2124,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
the client must fill in its own hardware address as the sender's
hardware address, and 0 as the sender's IP address, to avoid
confusing ARP caches in other hosts on the same subnet. If the
+
+
+
+Droms Standards Track [Page 38]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
network address appears to be in use, the client MUST send a
DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
reply to announce the client's new IP address and clear any outdated
@@ -2120,14 +2144,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
'requested IP address' option in the DHCPREQUEST message. The client
may request specific configuration parameters by including the
'parameter request list' option. The client generates and records a
-
-
-
-Droms [Page 38]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
random transaction identifier and inserts that identifier into the
'xid' field. The client records its own local time for later use in
computing the lease expiration. The client MUST NOT include a
@@ -2164,6 +2180,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
of time (60 seconds or 4 tries if using timeout suggested in section
4.1), then it SHOULD display a message informing the user of the
problem, and then SHOULD begin network processing using suitable
+
+
+
+Droms Standards Track [Page 39]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
defaults as per Appendix A.
4.4.4 Use of broadcast and unicast
@@ -2176,14 +2200,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
When the DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may use that address in the
-
-
-
-Droms [Page 39]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
The client may also use unicast to send DHCPINFORM messages to a
known DHCP server. If the client receives no response to DHCP
@@ -2221,6 +2237,13 @@ DRAFT Dynamic Host Configuration Protocol December 1996
network address, returns to BOUND state and may continue network
processing.
+
+
+Droms Standards Track [Page 40]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
If no DHCPACK arrives before time T2, the client moves to REBINDING
state and sends (via broadcast) a DHCPREQUEST message to extend its
lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
@@ -2233,13 +2256,6 @@ DRAFT Dynamic Host Configuration Protocol December 1996
random "fuzz" around a fixed value, to avoid synchronization of
client reacquisition.
-
-
-Droms [Page 40]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
A client MAY choose to renew or extend its lease prior to T1. The
server MAY choose to extend the client's lease according to policy
set by the network administrator. The server SHOULD return T1 and
@@ -2268,20 +2284,10 @@ DRAFT Dynamic Host Configuration Protocol December 1996
DHCPRELEASE message to the server. Note that the correct operation
of DHCP does not depend on the transmission of DHCPRELEASE messages.
-5. Acknowledgments
- The author thanks the many (and too numerous to mention!) members of
- the DHC WG for their tireless and ongoing efforts in the development
- of DHCP and this document.
- The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
- Mendonca in organizing DHCP interoperability testing sessions are
- gratefully acknowledged.
- The development of this document was supported in part by grants from
- the Corporation for National Research Initiatives (CNRI), Bucknell
- University and Sun Microsystems.
@@ -2289,12 +2295,24 @@ DRAFT Dynamic Host Configuration Protocol December 1996
+Droms Standards Track [Page 41]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
-Droms [Page 41]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
+5. Acknowledgments
+
+ The author thanks the many (and too numerous to mention!) members of
+ the DHC WG for their tireless and ongoing efforts in the development
+ of DHCP and this document.
+ The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
+ Mendonca in organizing DHCP interoperability testing sessions are
+ gratefully acknowledged.
+
+ The development of this document was supported in part by grants from
+ the Corporation for National Research Initiatives (CNRI), Bucknell
+ University and Sun Microsystems.
6. References
@@ -2329,53 +2347,53 @@ DRAFT Dynamic Host Configuration Protocol December 1996
[9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
Bucknell University, October 1993.
- [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
- Address Resolution Protocol", RFC 903, Stanford, June 1984.
- [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
- Mechanism for Distributed File Cache Consistency", In Proc. of
- the Twelfth ACM Symposium on Operating Systems Design, 1989.
- [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
- [13] Mockapetris, P., "Domain Names -- Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
+Droms Standards Track [Page 42]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+ [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
+ Address Resolution Protocol", RFC 903, Stanford, June 1984.
+ [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
+ Mechanism for Distributed File Cache Consistency", In Proc. of
+ the Twelfth ACM Symposium on Operating Systems Design, 1989.
-Droms [Page 42]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
+ [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+ [13] Mockapetris, P., "Domain Names -- Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
- [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
- November 1990.
+ [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
+ November 1990.
- [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
- Hosts", Work in Progress.
+ [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
+ Hosts", Work in Progress.
- [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
- USC/Information Sciences Institute, September 1981.
+ [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
+ USC/Information Sciences Institute, September 1981.
- [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
- USC/Information Sciences Institute, August 1993.
+ [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
+ USC/Information Sciences Institute, August 1993.
- [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
+ [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ USC/Information Sciences Institute, October 1994.
- [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
- Assignment of IP Addresses for use on an Ethernet. (Available
- from the Athena Project, MIT), 1989.
+ [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
+ Assignment of IP Addresses for use on an Ethernet. (Available
+ from the Athena Project, MIT), 1989.
- [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
- June 1981.
+ [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
+ June 1981.
- [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
- Protocol", RFC 1542, Carnegie Mellon University, October 1993.
+ [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
+ Protocol", RFC 1542, Carnegie Mellon University, October 1993.
7. Security Considerations
@@ -2386,6 +2404,14 @@ DRAFT Dynamic Host Configuration Protocol December 1996
difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure.
+
+
+
+Droms Standards Track [Page 43]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
Unauthorized DHCP servers may be easily set up. Such servers can
then send false and potentially disruptive information to clients
such as incorrect or duplicate IP addresses, incorrect routing
@@ -2400,26 +2426,17 @@ DRAFT Dynamic Host Configuration Protocol December 1996
claim all resources for itself, thereby denying resources to
legitimate clients.
-
-
-
-Droms [Page 43]
-
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
8. Author's Address
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
+ Ralph Droms
+ Computer Science Department
+ 323 Dana Engineering
+ Bucknell University
+ Lewisburg, PA 17837
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
+ Phone: (717) 524-1145
+ EMail: droms@bucknell.edu
- This document will expire on May 30, 1996.
@@ -2446,22 +2463,9 @@ DRAFT Dynamic Host Configuration Protocol December 1996
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 44]
+Droms Standards Track [Page 44]
-DRAFT Dynamic Host Configuration Protocol December 1996
+RFC 2131 Dynamic Host Configuration Protocol March 1997
A. Host Configuration Parameters
@@ -2515,5 +2519,5 @@ Key:
-Droms [Page 45]
-
+Droms Standards Track [Page 45]
+
diff --git a/doc/draft-ietf-dhc-options-1533update-06.txt b/doc/rfc2132.txt
index f62107ae..e9c4f4b3 100644
--- a/doc/draft-ietf-dhc-options-1533update-06.txt
+++ b/doc/rfc2132.txt
@@ -1,33 +1,24 @@
-Network Working Group S. Alexander
-INTERNET DRAFT Silicon Graphics, Inc.
-Obsoletes: draft-ietf-dhc-options-1533update-05.txt R. Droms
- Bucknell University
- December 1996
- Expires June 1997
- DHCP Options and BOOTP Vendor Extensions
- <draft-ietf-dhc-options-1533update-06.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.
+Network Working Group S. Alexander
+Request for Comments: 2132 Silicon Graphics, Inc.
+Obsoletes: 1533 R. Droms
+Category: Standards Track Bucknell University
+ March 1997
- 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.''
+ DHCP Options and BOOTP Vendor Extensions
+
+Status of this memo
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
Abstract
@@ -40,22 +31,14 @@ Abstract
This document specifies the current set of DHCP options. Future
options will be specified in separate RFCs. The current list of
- valid options is also available in
- ftp://ftp.isi.edu/in-notes/iana/assignments [22].
+ valid options is also available in ftp://ftp.isi.edu/in-
+ notes/iana/assignments [22].
All of the vendor information extensions defined in RFC 1497 [2] may
be used as DHCP options. The definitions given in RFC 1497 are
included in this document, which supersedes RFC 1497. All of the
DHCP options defined in this document, except for those specific to
DHCP as defined in section 9, may be used as BOOTP vendor information
-
-
-
-Alexander & Droms [Page 1]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
extensions.
Table of Contents
@@ -63,17 +46,25 @@ Table of Contents
1. Introduction .............................................. 2
2. BOOTP Extension/DHCP Option Field Format .................. 4
3. RFC 1497 Vendor Extensions ................................ 5
- 4. IP Layer Parameters per Host .............................. 12
- 5. IP Layer Parameters per Interface ........................ 15
- 6. Link Layer Parameters per Interface ....................... 19
- 7. TCP Parameters ............................................ 20
- 8. Application and Service Parameters ........................ 21
- 9. DHCP Extensions ........................................... 29
- 10. Defining new extensions ................................... 35
- 11. Acknowledgements .......................................... 35
- 12. References ................................................ 36
- 13. Security Considerations ................................... 37
- 14. Authors' Addresses ........................................ 37
+ 4. IP Layer Parameters per Host .............................. 11
+ 5. IP Layer Parameters per Interface ........................ 13
+ 6. Link Layer Parameters per Interface ....................... 16
+ 7. TCP Parameters ............................................ 17
+ 8. Application and Service Parameters ........................ 18
+ 9. DHCP Extensions ........................................... 25
+
+
+
+Alexander & Droms Standards Track [Page 1]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ 10. Defining new extensions ................................... 31
+ 11. Acknowledgements .......................................... 31
+ 12. References ................................................ 32
+ 13. Security Considerations ................................... 33
+ 14. Authors' Addresses ........................................ 34
1. Introduction
@@ -104,14 +95,6 @@ Table of Contents
Information on registering new options is contained in section 10.
This document updates the definition of DHCP/BOOTP options that
-
-
-
-Alexander & Droms [Page 2]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
appears in RFC1533. The classing mechanism has been extended to
include vendor classes as described in section 8.4 and 9.13. The new
procedure for defining new DHCP/BOOTP options in described in section
@@ -121,6 +104,18 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
been added in section 1.1. Text emphasizing the need for uniqueness
of client-identifiers has been added to section 9.14.
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 2]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
1.1 Requirements
Throughout this document, the words that are used to define the
@@ -129,157 +124,139 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
o "MUST"
- This word or the adjective "REQUIRED" means that the
- item is an absolute requirement of this specification.
+ This word or the adjective "REQUIRED" means that the item is an
+ absolute requirement of this specification.
o "MUST NOT"
- This phrase means that the item is an absolute prohibition
- of this specification.
+ This phrase means that the item is an absolute prohibition of
+ this specification.
o "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.
+ 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.
o "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 weighed before implementing any behavior
- described with this label.
+ 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 weighed before implementing any behavior
+ described with this label.
o "MAY"
- This word or the adjective "OPTIONAL" means that this item is
- truly optional. One vendor may choose 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.
+ This word or the adjective "OPTIONAL" means that this item is
+ truly optional. One vendor may choose 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.
+1.2 Terminology
+ This document uses the following terms:
+ o "DHCP client"
-Alexander & Droms [Page 3]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+ A DHCP client or "client" is an Internet host using DHCP to
+ obtain configuration parameters such as a network address.
-1.2 Terminology
- This document uses the following terms:
- o "DHCP client"
+Alexander & Droms Standards Track [Page 3]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
- A DHCP client or "client" is an Internet host using DHCP to obtain
- configuration parameters such as a network address.
o "DHCP server"
- A DHCP server of "server"is an Internet host that returns
- configuration parameters to DHCP clients.
+ A DHCP server of "server"is an Internet host that returns
+ configuration parameters to DHCP clients.
o "binding"
- A binding is a collection of configuration parameters, including
- at least an IP address, associated with or "bound to" a DHCP
- client. Bindings are managed by DHCP servers.
+ A binding is a collection of configuration parameters, including
+ at least an IP address, associated with or "bound to" a DHCP
+ client. Bindings are managed by DHCP servers.
2. BOOTP Extension/DHCP Option Field Format
- DHCP options have the same format as the BOOTP 'vendor extensions'
- defined in RFC 1497 [2]. Options may be fixed length or variable
- length. All options begin with a tag octet, which uniquely
- identifies the option. Fixed-length options without data consist of
- only a tag octet. Only options 0 and 255 are fixed length. All
- other options are variable-length with a length octet following the
- tag octet. The value of the length octet does not include the two
- octets specifying the tag and length. The length octet is followed
- by "length" octets of data.
- Options containing NVT ASCII data SHOULD NOT include a trailing NULL;
- however, the receiver of such options MUST be prepared to delete
- trailing nulls if they exist.
- The receiver MUST NOT
- require that a trailing null be included in the data. In the case
- of some variable-length
- options the length field is a constant but must still be specified.
- Any options defined subsequent to this document MUST contain a
- length octet even if the length is fixed or zero.
+ DHCP options have the same format as the BOOTP 'vendor extensions'
+ defined in RFC 1497 [2]. Options may be fixed length or variable
+ length. All options begin with a tag octet, which uniquely
+ identifies the option. Fixed-length options without data consist of
+ only a tag octet. Only options 0 and 255 are fixed length. All
+ other options are variable-length with a length octet following the
+ tag octet. The value of the length octet does not include the two
+ octets specifying the tag and length. The length octet is followed
+ by "length" octets of data. Options containing NVT ASCII data SHOULD
+ NOT include a trailing NULL; however, the receiver of such options
+ MUST be prepared to delete trailing nulls if they exist. The
+ receiver MUST NOT require that a trailing null be included in the
+ data. In the case of some variable-length options the length field
+ is a constant but must still be specified.
- All multi-octet quantities are in network byte-order.
+ Any options defined subsequent to this document MUST contain a length
+ octet even if the length is fixed or zero.
- When used with BOOTP, the first four octets of the vendor information
- field have been assigned to the "magic cookie" (as suggested in RFC
- 951). This field identifies the mode in which the succeeding data is
- to be interpreted. The value of the magic cookie is the 4 octet
+ All multi-octet quantities are in network byte-order.
+ When used with BOOTP, the first four octets of the vendor information
+ field have been assigned to the "magic cookie" (as suggested in RFC
+ 951). This field identifies the mode in which the succeeding data is
+ to be interpreted. The value of the magic cookie is the 4 octet
+ dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in
+ network byte order.
+ All of the "vendor extensions" defined in RFC 1497 are also DHCP
+ options.
+
+ Option codes 128 to 254 (decimal) are reserved for site-specific
+ options.
-Alexander & Droms [Page 4]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
- dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in
- network byte order.
- All of the "vendor extensions" defined in RFC 1497 are also DHCP
- options.
- Option codes 128 to 254 (decimal) are reserved for site-specific
- options.
+Alexander & Droms Standards Track [Page 4]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
- Except for the options in section 9, all options may be used with
- either DHCP or BOOTP.
+ Except for the options in section 9, all options may be used with
+ either DHCP or BOOTP.
- Many of these options have their default values specified in other
- documents. In particular, RFC 1122 [4] specifies default values for
- most IP and TCP configuration parameters.
+ Many of these options have their default values specified in other
+ documents. In particular, RFC 1122 [4] specifies default values for
+ most IP and TCP configuration parameters.
- Many options supply one or more 32-bit IP address. Use of IP
- addresses rather than fully-qualified Domain Names (FQDNs) may make
- future renumbering of IP hosts more difficult. Use of these addresses
- is discouraged at sites that may require renumbering.
+ Many options supply one or more 32-bit IP address. Use of IP
+ addresses rather than fully-qualified Domain Names (FQDNs) may make
+ future renumbering of IP hosts more difficult. Use of these
+ addresses is discouraged at sites that may require renumbering.
3. RFC 1497 Vendor Extensions
- This section lists the vendor extensions as defined in RFC
- 1497. They are defined here for completeness.
+ This section lists the vendor extensions as defined in RFC 1497.
+ They are defined here for completeness.
3.1. Pad Option
- The pad option can be used to cause subsequent fields to align on
- word boundaries.
+ The pad option can be used to cause subsequent fields to align on
+ word boundaries.
- The code for the pad option is 0, and its length is 1 octet.
+ The code for the pad option is 0, and its length is 1 octet.
Code
+-----+
| 0 |
+-----+
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 5]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
3.2. End Option
The end option marks the end of valid information in the vendor
@@ -300,6 +277,13 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
If both the subnet mask and the router option are specified in a DHCP
reply, the subnet mask option MUST be first.
+
+
+Alexander & Droms Standards Track [Page 5]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The code for the subnet mask option is 1, and its length is 4 octets.
Code Len Subnet Mask
@@ -322,20 +306,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 2 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 6]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
3.5. Router Option
The router option specifies a list of IP addresses for routers on the
@@ -360,6 +330,16 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
this option is 4 octets, and the length MUST always be a multiple of
4.
+
+
+
+
+
+Alexander & Droms Standards Track [Page 6]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
@@ -380,18 +360,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-Alexander & Droms [Page 7]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
3.8. Domain Name Server Option
The domain name server option specifies a list of Domain Name System
@@ -421,6 +389,13 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
+
+
+Alexander & Droms Standards Track [Page 7]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
3.10. Cookie Server Option
The cookie server option specifies a list of RFC 865 [9] cookie
@@ -435,19 +410,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 8]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
3.11. LPR Server Option
The LPR server option specifies a list of RFC 1179 [10] line printer
@@ -483,6 +445,13 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
servers available to the client. Servers SHOULD be listed in order
of preference.
+
+
+Alexander & Droms Standards Track [Page 8]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The code for this option is 11. The minimum length for this option
is 4 octets, and the length MUST always be a multiple of 4.
@@ -491,19 +460,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 9]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
3.14. Host Name Option
This option specifies the name of the client. The name may or may
@@ -547,17 +503,9 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 10]
+Alexander & Droms Standards Track [Page 9]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
3.17. Domain Name
@@ -596,26 +544,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 17 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 11]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
3.20. Extensions Path
A string to specify a file, retrievable via TFTP, which contains
@@ -628,6 +556,14 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
BOOTP Extensions Path field) within the file are
ignored.
+
+
+
+Alexander & Droms Standards Track [Page 10]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The code for this option is 18. Its minimum length is 1.
Code Len Extensions Pathname
@@ -653,25 +589,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 19 | 1 | 0/1 |
+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 12]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
4.2. Non-Local Source Routing Enable/Disable Option
This option specifies whether the client should configure its IP
@@ -696,6 +613,13 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
Any source routed datagram whose next-hop address does not match one
of the filters should be discarded by the client.
+
+
+Alexander & Droms Standards Track [Page 11]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
See [4] for further information.
The code for this option is 21. The minimum length of this option is
@@ -710,24 +634,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 13]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
4.4. Maximum Datagram Reassembly Size
This option specifies the maximum size datagram that the client
@@ -762,28 +668,19 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
The code for this option is 24, and its length is 4.
- Code Len Timeout
- +-----+-----+-----+-----+-----+-----+
- | 24 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 14]
+Alexander & Droms Standards Track [Page 12]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+ Code Len Timeout
+ +-----+-----+-----+-----+-----+-----+
+ | 24 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
4.7. Path MTU Plateau Table Option
This option specifies a table of MTU sizes to use when performing
@@ -819,27 +716,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 26 | 2 | m1 | m2 |
+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 15]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
5.2. All Subnets are Local Option
This option specifies whether or not the client may assume that all
@@ -849,6 +725,13 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
the same MTU. A value of 0 means that the client should assume that
some subnets of the directly connected network may have smaller MTUs.
+
+
+Alexander & Droms Standards Track [Page 13]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The code for this option is 27, and its length is 1.
Code Len Value
@@ -883,19 +766,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 29 | 1 | 0/1 |
+-----+-----+-----+
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 16]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
5.5. Mask Supplier Option
This option specifies whether or not the client should respond to
@@ -910,6 +780,14 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 30 | 1 | 0/1 |
+-----+-----+-----+
+
+
+
+Alexander & Droms Standards Track [Page 14]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
5.6. Perform Router Discovery Option
This option specifies whether or not the client should solicit
@@ -937,21 +815,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 32 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 17]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
5.8. Static Route Option
This option specifies a list of static routes that the client should
@@ -969,16 +832,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
The code for this option is 33. The minimum length of this option is
8, and the length MUST be a multiple of 8.
- Code Len Destination 1 Router 1
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- Destination 2 Router 2
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-
@@ -986,27 +839,19 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 18]
+Alexander & Droms Standards Track [Page 15]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+ Code Len Destination 1 Router 1
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 |
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ Destination 2 Router 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+ | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
6. Link Layer Parameters per Interface
@@ -1047,22 +892,20 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
client should use RFC 894 encapsulation. A value of 1 means that the
client should use RFC 1042 encapsulation.
- The code for this option is 36, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 36 | 1 | 0/1 |
- +-----+-----+-----+
-
+Alexander & Droms Standards Track [Page 16]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-Alexander & Droms [Page 19]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+ The code for this option is 36, and its length is 1.
+ Code Len Value
+ +-----+-----+-----+
+ | 36 | 1 | 0/1 |
+ +-----+-----+-----+
7. TCP Parameters
@@ -1105,20 +948,20 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
should not be sent. A value of 1 indicates that a garbage octet
should be sent.
- The code for this option is 39, and its length is 1.
- Code Len Value
- +-----+-----+-----+
- | 39 | 1 | 0/1 |
- +-----+-----+-----+
+Alexander & Droms Standards Track [Page 17]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-Alexander & Droms [Page 20]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+ The code for this option is 39, and its length is 1.
+ Code Len Value
+ +-----+-----+-----+
+ | 39 | 1 | 0/1 |
+ +-----+-----+-----+
8. Application and Service Parameters
@@ -1161,21 +1004,19 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
The code for this option is 42. Its minimum length is 4, and the
length MUST be a multiple of 4.
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-Alexander & Droms [Page 21]
+Alexander & Droms Standards Track [Page 18]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
8.4. Vendor Specific Information
This option is used by clients and servers to exchange vendor-
@@ -1217,6 +1058,16 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---
+
+
+
+
+
+Alexander & Droms Standards Track [Page 19]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
When encapsulated vendor-specific extensions are used, the
information bytes 1-n have the following format:
@@ -1225,13 +1076,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-Alexander & Droms [Page 22]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
8.5. NetBIOS over TCP/IP Name Server Option
The NetBIOS name server (NBNS) option specifies a list of RFC
@@ -1271,23 +1115,18 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
0x4 M-node
0x8 H-node
- In the above chart, the notation '0x' indicates a number in base-16
- (hexadecimal).
-
-
-
-
-
-
-Alexander & Droms [Page 23]
+Alexander & Droms Standards Track [Page 20]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+ In the above chart, the notation '0x' indicates a number in base-16
+ (hexadecimal).
+
The code for this option is 46. The length of this option is always
1.
@@ -1324,34 +1163,23 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
+8.10. X Window System Display Manager Option
+ This option specifies a list of IP addresses of systems that are
+ running the X Window System Display Manager and are available to the
+ client.
+ Addresses SHOULD be listed in order of preference.
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 24]
+Alexander & Droms Standards Track [Page 21]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-8.10. X Window System Display Manager Option
-
- This option specifies a list of IP addresses of systems that are
- running the X Window System Display Manager and are available to the
- client.
-
- Addresses SHOULD be listed in order of preference.
-
The code for the this option is 49. The minimum length of this option
is 4, and the length MUST be a multiple of 4.
@@ -1388,18 +1216,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-Alexander & Droms [Page 25]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
8.13. Mobile IP Home Agent option
This option specifies a list of IP addresses indicating mobile IP
@@ -1411,6 +1227,15 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
It is expected that the usual length will be four octets, containing
a single home agent's address.
+
+
+
+
+Alexander & Droms Standards Track [Page 22]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
Code Len Home Agent Addresses (zero or more)
+-----+-----+-----+-----+-----+-----+--
| 68 | n | a1 | a2 | a3 | a4 | ...
@@ -1444,18 +1269,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-Alexander & Droms [Page 26]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
8.16. Network News Transport Protocol (NNTP) Server Option
The NNTP server option specifies a list of NNTP available to the
@@ -1470,6 +1283,15 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
+
+
+
+
+Alexander & Droms Standards Track [Page 23]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
8.17. Default World Wide Web (WWW) Server Option
The WWW server option specifies a list of WWW available to the
@@ -1498,20 +1320,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 27]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
8.19. Default Internet Relay Chat (IRC) Server Option
The IRC server option specifies a list of IRC available to the
@@ -1532,6 +1340,14 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
available to the client. Servers SHOULD be listed in order of
preference.
+
+
+
+Alexander & Droms Standards Track [Page 24]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The code for the StreetTalk server option is 75. The minimum length
for this option is 4 octets, and the length MUST always be a multiple
of 4.
@@ -1556,18 +1372,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-Alexander & Droms [Page 28]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
9. DHCP Extensions
This section details the options that are specific to DHCP.
@@ -1591,6 +1395,15 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
server reply (DHCPOFFER), a DHCP server uses this option to specify
the lease time it is willing to offer.
+
+
+
+
+Alexander & Droms Standards Track [Page 25]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The time is in units of seconds, and is specified as a 32-bit
unsigned integer.
@@ -1612,18 +1425,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
additional fields after it concludes interpretation of the standard
option fields.
-
-
-
-
-
-
-
-Alexander & Droms [Page 29]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
The code for this option is 52, and its length is 1. Legal values
for this option are:
@@ -1640,8 +1441,8 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
9.4 TFTP server name
- This option is used to identify a TFTP server when the 'sname'
- field in the DHCP header has been used for DHCP options.
+ This option is used to identify a TFTP server when the 'sname' field
+ in the DHCP header has been used for DHCP options.
The code for this option is 66, and its minimum length is 1.
@@ -1650,6 +1451,15 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 66 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---
+
+
+
+
+Alexander & Droms Standards Track [Page 26]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
9.5 Bootfile name
This option is used to identify a bootfile when the 'file' field in
@@ -1662,24 +1472,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 67 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 30]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
9.6. DHCP Message Type
This option is used to convey the type of the DHCP message. The code
@@ -1717,25 +1509,18 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
The code for this option is 54, and its length is 4.
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 54 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 31]
+Alexander & Droms Standards Track [Page 27]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+ Code Len Address
+ +-----+-----+-----+-----+-----+-----+
+ | 54 | 4 | a1 | a2 | a3 | a4 |
+ +-----+-----+-----+-----+-----+-----+
+
9.8. Parameter Request List
This option is used by a DHCP client to request values for specified
@@ -1771,27 +1556,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 56 | n | c1 | c2 | ...
+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 32]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
9.10. Maximum DHCP Message Size
This option specifies the maximum length DHCP message that it is
@@ -1800,6 +1564,14 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
DHCPDISCOVER or DHCPREQUEST messages, but should not use the option
in DHCPDECLINE messages.
+
+
+
+Alexander & Droms Standards Track [Page 28]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
The code for this option is 57, and its length is 2. The minimum
legal value is 576 octets.
@@ -1838,16 +1610,6 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
| 59 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-Alexander & Droms [Page 33]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
9.13. Vendor class identifier
This option is used by DHCP clients to optionally identify the vendor
@@ -1858,6 +1620,14 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
identifier may encode the client's hardware configuration. Servers
not equipped to interpret the class-specific information sent by a
client MUST ignore it (although it may be reported). Servers that
+
+
+
+Alexander & Droms Standards Track [Page 29]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
respond SHOULD only use option 43 to return the vendor-specific
information to the client.
@@ -1891,6 +1661,13 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
administrators are responsible for choosing client-identifiers that
meet this requirement for uniqueness.
+ The code for this option is 61, and its minimum length is 2.
+
+ Code Len Type Client-Identifier
+ +-----+-----+-----+-----+-----+---
+ | 61 | n | t1 | i1 | i2 | ...
+ +-----+-----+-----+-----+-----+---
+
@@ -1899,17 +1676,12 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-Alexander & Droms [Page 34]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
- The code for this option is 61, and its minimum length is 2.
- Code Len Type Client-Identifier
- +-----+-----+-----+-----+-----+---
- | 61 | n | t1 | i1 | i2 | ...
- +-----+-----+-----+-----+-----+---
+Alexander & Droms Standards Track [Page 30]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
10. Defining new extensions
@@ -1925,7 +1697,7 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
4676 Admiralty Way
Marina del Rey, California 90292-6695
- or by email as: iana@isi.edu
+ or by email as: iana@iana.org
3. The author documents the new option, using the newly obtained
option number, as an Internet Draft.
@@ -1951,133 +1723,147 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
11. Acknowledgements
- The author thanks the many (and too numerous to mention!)
-
+ The author thanks the many (and too numerous to mention!) members of
+ the DHC WG for their tireless and ongoing efforts in the development
+ of DHCP and this document.
+ The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
+ Mendonca in organizing DHCP interoperability testing sessions are
+ gratefully acknowledged.
-Alexander & Droms [Page 35]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
- members of the DHC WG for their tireless and ongoing efforts in
- the development of DHCP and this document.
- The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and
- John Mendonca in organizing DHCP interoperability testing
- sessions are gratefully acknowledged.
+Alexander & Droms Standards Track [Page 31]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
- The development of this document was supported in part by grants
- from the Corporation for National Research Initiatives (CNRI),
- Bucknell University and Sun Microsystems.
+ The development of this document was supported in part by grants from
+ the Corporation for National Research Initiatives (CNRI), Bucknell
+ University and Sun Microsystems.
12. References
- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
- Bucknell University, October 1993.
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ Bucknell University, March 1997.
- [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
- USC/Information Sciences Institute, August 1993.
+ [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
+ USC/Information Sciences Institute, August 1993.
- [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
- Stanford University and Sun Microsystems, September 1985.
+ [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
+ Stanford University and Sun Microsystems, September 1985.
- [4] Braden, R., Editor, "Requirements for Internet Hosts -
- Communication Layers", STD 3, RFC 1122, USC/Information Sciences
- Institute, October 1989.
+ [4] Braden, R., Editor, "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, USC/Information Sciences
+ Institute, October 1989.
- [5] Mogul, J., and J. Postel, "Internet Standard Subnetting
- Procedure", STD 5, RFC 950, USC/Information Sciences Institute,
- August 1985.
+ [5] Mogul, J., and J. Postel, "Internet Standard Subnetting
+ Procedure", STD 5, RFC 950, USC/Information Sciences Institute,
+ August 1985.
- [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC
- 868, USC/Information Sciences Institute, SRI, May 1983.
+ [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC
+ 868, USC/Information Sciences Institute, SRI, May 1983.
- [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences
- Institute, August 1979.
+ [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences
+ Institute, August 1979.
- [8] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
+ [8] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
- [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
- USC/Information Sciences Institute, May 1983.
+ [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
+ USC/Information Sciences Institute, May 1983.
- [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
- Wollongong Group, August 1990.
+ [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
+ Wollongong Group, August 1990.
+ [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
+ December 1983.
+ [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
+ DECWRL, Stanford University, November 1990.
+ [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
+ Xerox PARC, September 1991.
-Alexander & Droms [Page 36]
-
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
- [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
- December 1983.
- [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
- DECWRL, Stanford University, November 1990.
+Alexander & Droms Standards Track [Page 32]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
- [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
- Xerox PARC, September 1991.
- [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893,
- U. C. Berkeley, April 1984.
+ [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893,
+ U. C. Berkeley, April 1984.
- [15] Hornig, C., "Standard for the Transmission of IP Datagrams over
- Ethernet Networks", RFC 894, Symbolics, April 1984.
+ [15] Hornig, C., "Standard for the Transmission of IP Datagrams over
+ Ethernet Networks", RFC 894, Symbolics, April 1984.
- [16] Postel, J. and J. Reynolds, "Standard for the Transmission of
- IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information
- Sciences Institute, February 1988.
+ [16] Postel, J. and J. Reynolds, "Standard for the Transmission of
+ IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information
+ Sciences Institute, February 1988.
- [17] Sun Microsystems, "System and Network Administration", March
- 1990.
+ [17] Sun Microsystems, "System and Network Administration", March
+ 1990.
- [18] Mills, D., "Internet Time Synchronization: The Network Time
- Protocol", RFC 1305, UDEL, March 1992.
+ [18] Mills, D., "Internet Time Synchronization: The Network Time
+ Protocol", RFC 1305, UDEL, March 1992.
- [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
- on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001,
- March 1987.
+ [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
+ on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001,
+ March 1987.
- [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
- on a TCP/UDP transport: Detailed Specifications", STD 19, RFC
- 1002, March 1987.
+ [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
+ on a TCP/UDP transport: Detailed Specifications", STD 19, RFC
+ 1002, March 1987.
- [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198,
- MIT Laboratory for Computer Science, January 1991.
+ [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198,
+ MIT Laboratory for Computer Science, January 1991.
- [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
- USC/Information Sciences Institute, July 1992.
+ [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ USC/Information Sciences Institute, July 1992.
13. Security Considerations
Security issues are not discussed in this memo.
-14. Authors' Addresses
- Steve Alexander
- Silicon Graphics, Inc.
- 2011 N. Shoreline Boulevard
-Alexander & Droms [Page 37]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 33]
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+14. Authors' Addresses
+
+ Steve Alexander
+ Silicon Graphics, Inc.
+ 2011 N. Shoreline Boulevard
Mailstop 510
Mountain View, CA 94043-1389
Phone: (415) 933-6172
EMail: sca@engr.sgi.com
+
Ralph Droms
Bucknell University
Lewisburg, PA 17837
@@ -2117,11 +1903,5 @@ DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-
-
-
-
-Alexander & Droms [Page 38]
-
+Alexander & Droms Standards Track [Page 34]
+
diff --git a/doc/rfc951.txt b/doc/rfc951.txt
new file mode 100644
index 00000000..86cd69e6
--- /dev/null
+++ b/doc/rfc951.txt
@@ -0,0 +1,684 @@
+
+
+Network Working Group Bill Croft (Stanford University)
+Request for Comments: 951 John Gilmore (Sun Microsystems)
+ September 1985
+
+ BOOTSTRAP PROTOCOL (BOOTP)
+
+
+1. Status of this Memo
+
+ This RFC suggests a proposed protocol for the ARPA-Internet
+ community, and requests discussion and suggestions for improvements.
+ Distribution of this memo is unlimited.
+
+2. Overview
+
+ This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
+ a diskless client machine to discover its own IP address, the address
+ of a server host, and the name of a file to be loaded into memory and
+ executed. The bootstrap operation can be thought of as consisting of
+ TWO PHASES. This RFC describes the first phase, which could be
+ labeled 'address determination and bootfile selection'. After this
+ address and filename information is obtained, control passes to the
+ second phase of the bootstrap where a file transfer occurs. The file
+ transfer will typically use the TFTP protocol [9], since it is
+ intended that both phases reside in PROM on the client. However
+ BOOTP could also work with other protocols such as SFTP [3] or
+ FTP [6].
+
+ We suggest that the client's PROM software provide a way to do a
+ complete bootstrap without 'user' interaction. This is the type of
+ boot that would occur during an unattended power-up. A mechanism
+ should be provided for the user to manually supply the necessary
+ address and filename information to bypass the BOOTP protocol and
+ enter the file transfer phase directly. If non-volatile storage is
+ available, we suggest keeping default settings there and bypassing
+ the BOOTP protocol unless these settings cause the file transfer
+ phase to fail. If the cached information fails, the bootstrap should
+ fall back to phase 1 and use BOOTP.
+
+ Here is a brief outline of the protocol:
+
+ 1. A single packet exchange is performed. Timeouts are used to
+ retransmit until a reply is received. The same packet field
+ layout is used in both directions. Fixed length fields of maximum
+ reasonable length are used to simplify structure definition and
+ parsing.
+
+ 2. An 'opcode' field exists with two values. The client
+ broadcasts a 'bootrequest' packet. The server then answers with a
+ 'bootreply' packet. The bootrequest contains the client's
+ hardware address and its IP address, if known.
+
+
+Croft & Gilmore [Page 1]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ 3. The request can optionally contain the name of the server the
+ client wishes to respond. This is so the client can force the
+ boot to occur from a specific host (e.g. if multiple versions of
+ the same bootfile exist or if the server is in a far distant
+ net/domain). The client does not have to deal with name / domain
+ services; instead this function is pushed off to the BOOTP server.
+
+ 4. The request can optionally contain the 'generic' filename to be
+ booted. For example 'unix' or 'ethertip'. When the server sends
+ the bootreply, it replaces this field with the fully qualified
+ path name of the appropriate boot file. In determining this name,
+ the server may consult his own database correlating the client's
+ address and filename request, with a particular boot file
+ customized for that client. If the bootrequest filename is a null
+ string, then the server returns a filename field indicating the
+ 'default' file to be loaded for that client.
+
+ 5. In the case of clients who do not know their IP addresses, the
+ server must also have a database relating hardware address to IP
+ address. This client IP address is then placed into a field in
+ the bootreply.
+
+ 6. Certain network topologies (such as Stanford's) may be such
+ that a given physical cable does not have a TFTP server directly
+ attached to it (e.g. all the gateways and hosts on a certain cable
+ may be diskless). With the cooperation of neighboring gateways,
+ BOOTP can allow clients to boot off of servers several hops away,
+ through these gateways. See the section 'Booting Through
+ Gateways' below. This part of the protocol requires no special
+ action on the part of the client. Implementation is optional and
+ requires a small amount of additional code in gateways and
+ servers.
+
+3. Packet Format
+
+ All numbers shown are decimal, unless indicated otherwise. The BOOTP
+ packet is enclosed in a standard IP [8] UDP [7] datagram. For
+ simplicity it is assumed that the BOOTP packet is never fragmented.
+ Any numeric fields shown are packed in 'standard network byte order',
+ i.e. high order bits are sent first.
+
+ In the IP header of a bootrequest, the client fills in its own IP
+ source address if known, otherwise zero. When the server address is
+ unknown, the IP destination address will be the 'broadcast address'
+ 255.255.255.255. This address means 'broadcast on the local cable,
+ (I don't know my net number)' [4].
+
+
+
+Croft & Gilmore [Page 2]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ The UDP header contains source and destination port numbers. The
+ BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
+ and 'BOOTP server' (67). The client sends requests using 'BOOTP
+ server' as the destination port; this is usually a broadcast. The
+ server sends replies using 'BOOTP client' as the destination port;
+ depending on the kernel or driver facilities in the server, this may
+ or may not be a broadcast (this is explained further in the section
+ titled 'Chicken/Egg issues' below). The reason TWO reserved ports
+ are used, is to avoid 'waking up' and scheduling the BOOTP server
+ daemons, when a bootreply must be broadcast to a client. Since the
+ server and other hosts won't be listening on the 'BOOTP client' port,
+ any such incoming broadcasts will be filtered out at the kernel
+ level. We could not simply allow the client to pick a 'random' port
+ number for the UDP source port field; since the server reply may be
+ broadcast, a randomly chosen port number could confuse other hosts
+ that happened to be listening on that port.
+
+ The UDP length field is set to the length of the UDP plus BOOTP
+ portions of the packet. The UDP checksum field can be set to zero by
+ the client (or server) if desired, to avoid this extra overhead in a
+ PROM implementation. In the 'Packet Processing' section below the
+ phrase '[UDP checksum.]' is used whenever the checksum might be
+ verified/computed.
+
+ FIELD BYTES DESCRIPTION
+ ----- ----- -----------
+
+ op 1 packet op code / message type.
+ 1 = BOOTREQUEST, 2 = BOOTREPLY
+
+ htype 1 hardware address type,
+ see ARP section in "Assigned Numbers" RFC.
+ '1' = 10mb ethernet
+
+ hlen 1 hardware address length
+ (eg '6' for 10mb ethernet).
+
+ hops 1 client sets to zero,
+ optionally used by gateways
+ in cross-gateway booting.
+
+ xid 4 transaction ID, a random number,
+ used to match this boot request with the
+ responses it generates.
+
+ secs 2 filled in by client, seconds elapsed since
+ client started trying to boot.
+
+
+Croft & Gilmore [Page 3]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ -- 2 unused
+
+ ciaddr 4 client IP address;
+ filled in by client in bootrequest if known.
+
+ yiaddr 4 'your' (client) IP address;
+ filled by server if client doesn't
+ know its own address (ciaddr was 0).
+
+ siaddr 4 server IP address;
+ returned in bootreply by server.
+
+ giaddr 4 gateway IP address,
+ used in optional cross-gateway booting.
+
+ chaddr 16 client hardware address,
+ filled in by client.
+
+ sname 64 optional server host name,
+ null terminated string.
+
+ file 128 boot file name, null terminated string;
+ 'generic' name or null in bootrequest,
+ fully qualified directory-path
+ name in bootreply.
+
+ vend 64 optional vendor-specific area,
+ e.g. could be hardware type/serial on request,
+ or 'capability' / remote file system handle
+ on reply. This info may be set aside for use
+ by a third phase bootstrap or kernel.
+
+4. Chicken / Egg Issues
+
+ How can the server send an IP datagram to the client, if the client
+ doesnt know its own IP address (yet)? Whenever a bootreply is being
+ sent, the transmitting machine performs the following operations:
+
+ 1. If the client knows its own IP address ('ciaddr' field is
+ nonzero), then the IP can be sent 'as normal', since the client
+ will respond to ARPs [5].
+
+ 2. If the client does not yet know its IP address (ciaddr zero),
+ then the client cannot respond to ARPs sent by the transmitter of
+ the bootreply. There are two options:
+
+ a. If the transmitter has the necessary kernel or driver hooks
+
+
+Croft & Gilmore [Page 4]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ to 'manually' construct an ARP address cache entry, then it can
+ fill in an entry using the 'chaddr' and 'yiaddr' fields. Of
+ course, this entry should have a timeout on it, just like any
+ other entry made by the normal ARP code itself. The
+ transmitter of the bootreply can then simply send the bootreply
+ to the client's IP address. UNIX (4.2 BSD) has this
+ capability.
+
+ b. If the transmitter lacks these kernel hooks, it can simply
+ send the bootreply to the IP broadcast address on the
+ appropriate interface. This is only one additional broadcast
+ over the previous case.
+
+5. Client Use of ARP
+
+ The client PROM must contain a simple implementation of ARP, e.g. the
+ address cache could be just one entry in size. This will allow a
+ second-phase-only boot (TFTP) to be performed when the client knows
+ the IP addresses and bootfile name.
+
+ Any time the client is expecting to receive a TFTP or BOOTP reply, it
+ should be prepared to answer an ARP request for its own IP to
+ hardware address mapping (if known).
+
+ Since the bootreply will contain (in the hardware encapsulation) the
+ hardware source address of the server/gateway, the client MAY be able
+ to avoid sending an ARP request for the server/gateway IP address to
+ be used in the following TFTP phase. However this should be treated
+ only as a special case, since it is desirable to still allow a
+ second-phase-only boot as described above.
+
+6. Comparison to RARP
+
+ An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
+ was proposed to allow a client to determine its IP address, given
+ that it knew its hardware address. However RARP had the disadvantage
+ that it was a hardware link level protocol (not IP/UDP based). This
+ means that RARP could only be implemented on hosts containing special
+ kernel or driver modifications to access these 'raw' packets. Since
+ there are many network kernels existent now, with each source
+ maintained by different organizations, a boot protocol that does not
+ require kernel modifications is a decided advantage.
+
+ BOOTP provides this hardware to IP address lookup function, in
+ addition to the other useful features described in the sections
+ above.
+
+
+
+Croft & Gilmore [Page 5]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+7. Packet Processing
+
+ 7.1. Client Transmission
+
+ Before setting up the packet for the first time, it is a good idea
+ to clear the entire packet buffer to all zeros; this will place
+ all fields in their default state. The client then creates a
+ packet with the following fields.
+
+ The IP destination address is set to 255.255.255.255. (the
+ broadcast address) or to the server's IP address (if known). The
+ IP source address and 'ciaddr' are set to the client's IP address
+ if known, else 0. The UDP header is set with the proper length;
+ source port = 'BOOTP client' port destination port = 'BOOTP
+ server' port.
+
+ 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware
+ address type as assigned in the ARP section of the "Assigned
+ Numbers" RFC. 'hlen' is set to the length of the hardware address,
+ e.g. '6' for 10mb ethernet.
+
+ 'xid' is set to a 'random' transaction id. 'secs' is set to the
+ number of seconds that have elapsed since the client has started
+ booting. This will let the servers know how long a client has
+ been trying. As the number gets larger, certain servers may feel
+ more 'sympathetic' towards a client they don't normally service.
+ If a client lacks a suitable clock, it could construct a rough
+ estimate using a loop timer. Or it could choose to simply send
+ this field as always a fixed value, say 100 seconds.
+
+ If the client knows its IP address, 'ciaddr' (and the IP source
+ address) are set to this value. 'chaddr' is filled in with the
+ client's hardware address.
+
+ If the client wishes to restrict booting to a particular server
+ name, it may place a null-terminated string in 'sname'. The name
+ used should be any of the allowable names or nicknames of the
+ desired host.
+
+ The client has several options for filling the 'file' name field.
+ If left null, the meaning is 'I want to boot the default file for
+ my machine'. A null file name can also mean 'I am only interested
+ in finding out client/server/gateway IP addresses, I dont care
+ about file names'.
+
+ The field can also be a 'generic' name such as 'unix' or
+
+
+
+Croft & Gilmore [Page 6]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ 'gateway'; this means 'boot the named program configured for my
+ machine'. Finally the field can be a fully directory qualified
+ path name.
+
+ The 'vend' field can be filled in by the client with
+ vendor-specific strings or structures. For example the machine
+ hardware type or serial number may be placed here. However the
+ operation of the BOOTP server should not DEPEND on this
+ information existing.
+
+ If the 'vend' field is used, it is recommended that a 4 byte
+ 'magic number' be the first item within 'vend'. This lets a
+ server determine what kind of information it is seeing in this
+ field. Numbers can be assigned by the usual 'magic number'
+ process --you pick one and it's magic. A different magic number
+ could be used for bootreply's than bootrequest's to allow the
+ client to take special action with the reply information.
+
+ [UDP checksum.]
+
+ 7.2. Client Retransmission Strategy
+
+ If no reply is received for a certain length of time, the client
+ should retransmit the request. The time interval must be chosen
+ carefully so as not to flood the network. Consider the case of a
+ cable containing 100 machines that are just coming up after a
+ power failure. Simply retransmitting the request every four
+ seconds will inundate the net.
+
+ As a possible strategy, you might consider backing off
+ exponentially, similar to the way ethernet backs off on a
+ collision. So for example if the first packet is at time 0:00,
+ the second would be at :04, then :08, then :16, then :32, then
+ :64. You should also randomize each time; this would be done
+ similar to the ethernet specification by starting with a mask and
+ 'and'ing that with with a random number to get the first backoff.
+ On each succeeding backoff, the mask is increased in length by one
+ bit. This doubles the average delay on each backoff.
+
+ After the 'average' backoff reaches about 60 seconds, it should be
+ increased no further, but still randomized.
+
+ Before each retransmission, the client should update the 'secs'
+ field. [UDP checksum.]
+
+
+
+
+
+Croft & Gilmore [Page 7]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ 7.3. Server Receives BOOTREQUEST
+
+ [UDP checksum.] If the UDP destination port does not match the
+ 'BOOTP server' port, discard the packet.
+
+ If the server name field (sname) is null (no particular server
+ specified), or sname is specified and matches our name or
+ nickname, then continue with packet processing.
+
+ If the sname field is specified, but does not match 'us', then
+ there are several options:
+
+ 1. You may choose to simply discard this packet.
+
+ 2. If a name lookup on sname shows it to be on this same cable,
+ discard the packet.
+
+ 3. If sname is on a different net, you may choose to forward
+ the packet to that address. If so, check the 'giaddr' (gateway
+ address) field. If 'giaddr' is zero, fill it in with my
+ address or the address of a gateway that can be used to get to
+ that net. Then forward the packet.
+
+ If the client IP address (ciaddr) is zero, then the client does
+ not know its own IP address. Attempt to lookup the client
+ hardware address (chaddr, hlen, htype) in our database. If no
+ match is found, discard the packet. Otherwise we now have an IP
+ address for this client; fill it into the 'yiaddr' (your IP
+ address) field.
+
+ We now check the boot file name field (file). The field will be
+ null if the client is not interested in filenames, or wants the
+ default bootfile. If the field is non-null, it is used as a
+ lookup key in a database, along with the client's IP address. If
+ there is a default file or generic file (possibly indexed by the
+ client address) or a fully-specified path name that matches, then
+ replace the 'file' field with the fully-specified path name of the
+ selected boot file. If the field is non-null and no match was
+ found, then the client is asking for a file we dont have; discard
+ the packet, perhaps some other BOOTP server will have it.
+
+ The 'vend' vendor-specific data field should now be checked and if
+ a recognized type of data is provided, client-specific actions
+ should be taken, and a response placed in the 'vend' data field of
+ the reply packet. For example, a workstation client could provide
+
+
+
+
+Croft & Gilmore [Page 8]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ an authentication key and receive from the server a capability for
+ remote file access, or a set of configuration options, which can
+ be passed to the operating system that will shortly be booted in.
+
+ Place my (server) IP address in the 'siaddr' field. Set the 'op'
+ field to BOOTREPLY. The UDP destination port is set to 'BOOTP
+ client'. If the client address 'ciaddr' is nonzero, send the
+ packet there; else if the gateway address 'giaddr' is nonzero, set
+ the UDP destination port to 'BOOTP server' and send the packet to
+ 'giaddr'; else the client is on one of our cables but it doesnt
+ know its own IP address yet --use a method described in the 'Egg'
+ section above to send it to the client. If 'Egg' is used and we
+ have multiple interfaces on this host, use the 'yiaddr' (your IP
+ address) field to figure out which net (cable/interface) to send
+ the packet to. [UDP checksum.]
+
+ 7.4. Server/Gateway Receives BOOTREPLY
+
+ [UDP checksum.] If 'yiaddr' (your [the client's] IP address)
+ refers to one of our cables, use one of the 'Egg' methods above to
+ forward it to the client. Be sure to send it to the 'BOOTP
+ client' UDP destination port.
+
+ 7.5. Client Reception
+
+ Don't forget to process ARP requests for my own IP address (if I
+ know it). [UDP checksum.] The client should discard incoming
+ packets that: are not IP/UDPs addressed to the boot port; are not
+ BOOTREPLYs; do not match my IP address (if I know it) or my
+ hardware address; do not match my transaction id. Otherwise we
+ have received a successful reply. 'yiaddr' will contain my IP
+ address, if I didnt know it before. 'file' is the name of the
+ file name to TFTP 'read request'. The server address is in
+ 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the
+ packets should be forwarded there first, in order to get to the
+ server.
+
+8. Booting Through Gateways
+
+ This part of the protocol is optional and requires some additional
+ code in cooperating gateways and servers, but it allows cross-gateway
+ booting. This is mainly useful when gateways are diskless machines.
+ Gateways containing disks (e.g. a UNIX machine acting as a gateway),
+ might as well run their own BOOTP/TFTP servers.
+
+ Gateways listening to broadcast BOOTREQUESTs may decide to forward or
+ rebroadcast these requests 'when appropriate'. For example, the
+
+
+Croft & Gilmore [Page 9]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ gateway could have, as part of his configuration tables, a list of
+ other networks or hosts to receive a copy of any broadcast
+ BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea
+ to simply globally rebroadcast the requests, since broadcast loops
+ will almost certainly occur.
+
+ The forwarding could begin immediately, or wait until the 'secs'
+ (seconds client has been trying) field passes a certain threshold.
+
+ If a gateway does decide to forward the request, it should look at
+ the 'giaddr' (gateway IP address) field. If zero, it should plug its
+ own IP address (on the receiving cable) into this field. It may also
+ use the 'hops' field to optionally control how far the packet is
+ reforwarded. Hops should be incremented on each forwarding. For
+ example, if hops passes '3', the packet should probably be discarded.
+ [UDP checksum.]
+
+ Here we have recommended placing this special forwarding function in
+ the gateways. But that does not have to be the case. As long as
+ some 'BOOTP forwarding agent' exists on the net with the booting
+ client, the agent can do the forwarding when appropriate. Thus this
+ service may or may not be co-located with the gateway.
+
+ In the case of a forwarding agent not located in the gateway, the
+ agent could save himself some work by plugging the broadcast address
+ of the interface receiving the bootrequest into the 'giaddr' field.
+ Thus the reply would get forwarded using normal gateways, not
+ involving the forwarding agent. Of course the disadvantage here is
+ that you lose the ability to use the 'Egg' non-broadcast method of
+ sending the reply, causing extra overhead for every host on the
+ client cable.
+
+9. Sample BOOTP Server Database
+
+ As a suggestion, we show a sample text file database that the BOOTP
+ server program might use. The database has two sections, delimited
+ by a line containing an percent in column 1. The first section
+ contains a 'default directory' and mappings from generic names to
+ directory/pathnames. The first generic name in this section is the
+ 'default file' you get when the bootrequest contains a null 'file'
+ string.
+
+ The second section maps hardware addresstype/address into an
+ ipaddress. Optionally you can also overide the default generic name
+ by supplying a ipaddress specific genericname. A 'suffix' item is
+ also an option; if supplied, any generic names specified by the
+ client will be accessed by first appending 'suffix' to the 'pathname'
+
+
+Croft & Gilmore [Page 10]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ appropriate to that generic name. If that file is not found, then
+ the plain 'pathname' will be tried. This 'suffix' option allows a
+ whole set of custom generics to be setup without a lot of effort.
+ Below is shown the general format; fields are delimited by one or
+ more spaces or tabs; trailing empty fields may be omitted; blank
+ lines and lines beginning with '#' are ignored.
+
+ # comment line
+
+ homedirectory
+ genericname1 pathname1
+ genericname2 pathname2
+ ...
+
+ % end of generic names, start of address mappings
+
+ hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
+ hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
+ ...
+
+ Here is a specific example. Note the 'hardwaretype' number is the
+ same as that shown in the ARP section of the 'Assigned Numbers' RFC.
+ The 'hardwaretype' and 'ipaddr' numbers are in decimal;
+ 'hardwareaddr' is in hex.
+
+ # last updated by smith
+
+ /usr/boot
+ vmunix vmunix
+ tip ethertip
+ watch /usr/diag/etherwatch
+ gate gate.
+
+ % end of generic names, start of address mappings
+
+ hamilton 1 02.60.8c.06.34.98 36.19.0.5
+ burr 1 02.60.8c.34.11.78 36.44.0.12
+ 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101
+ mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh
+ welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip
+ welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip
+
+ In the example above, if 'mjh-gateway' does a default boot, it will
+ get the file '/usr/boot/gate.mjh'.
+
+
+
+
+
+Croft & Gilmore [Page 11]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+10. Acknowledgements
+
+ Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
+ bootstraping [2] using RARP [1].
+
+ We would also like to acknowledge the previous work and comments of
+ Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
+
+REFERENCES
+
+ 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A
+ Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.
+
+ 2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC,
+ June, 1984.
+
+ 3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC,
+ September, 1984.
+
+ 4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC,
+ October, 1984.
+
+ 5. David Plummer. An Ethernet Address Resolution Protocol. RFC
+ 826, NIC, September, 1982.
+
+ 6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.
+
+ 7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.
+
+ 8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.
+
+ 9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC,
+ June, 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Croft & Gilmore [Page 12]
+
View Lorry Controller Status