--- /dev/null
+Network Working Group R. Droms, Editor
+INTERNET DRAFT Bucknell University
+Obsoletes: draft-ietf-dhc-authentication-13.txt W. Arbaugh, Editor
+ University of Maryland
+ July 2000
+ Expires December 2000
+
+
+ Authentication for DHCP Messages
+ <draft-ietf-dhc-authentication-14.txt>
+
+Status of this memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. 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."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt, and the list of
+ Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+ The Dynamic Host Configuration Protocol (DHCP) 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 [1] 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
+
+
+
+Droms, Arbaugh [Page 1]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ a manual step in configuration of TCP/IP hosts.
+
+ 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.
+
+ DISCUSSION:
+
+ This draft combines the original Schiller-Huitema-Droms
+ authentication mechanism defined in a previous Internet Draft with
+ the "delayed authentication" proposal developed by Bill Arbaugh.
+
+1.1 DHCP threat model
+
+ The threat to DHCP is inherently an insider threat (assuming a
+ properly configured network where BOOTP ports are blocked on the
+ enterprise's perimeter gateways.) Regardless of the gateway
+ configuration, however, the potential attacks by insiders and
+ outsiders are the same.
+
+ The attack specific to a DHCP client is the possibility of the
+ establishment of a "rogue" server with the intent of providing
+ incorrect configuration information to the client. The motivation for
+ doing so may be to establish a "man in the middle" attack or it may
+ be for a "denial of service" attack.
+
+ There is another threat to DHCP clients from mistakenly or
+ accidentally configured DHCP servers that answer DHCP client requests
+ with unintentionally incorrect configuration parameters.
+
+ The threat specific to a DHCP server is an invalid client
+ masquerading as a valid client. The motivation for this may be for
+ "theft of service", or to circumvent auditing for any number of
+ nefarious purposes.
+
+ The threat common to both the client and the server is the resource
+ "denial of service" (DoS) attack. These attacks typically involve the
+ exhaustion of valid addresses, or the exhaustion of CPU or network
+ bandwidth, and are present anytime there is a shared resource. In
+
+
+
+Droms, Arbaugh [Page 2]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ current practice, redundancy mitigates DoS attacks the best.
+
+1.2 Design goals
+
+ These are the goals that were used in the development of the
+ authentication protocol, listed in order of importance:
+
+ 1. Address the threats presented in Section 1.1.
+ 2. Avoid changing the current protocol.
+ 3. Limit state required by the server.
+ 4. Limit complexity (complexity breeds design and implementation
+ errors).
+
+1.3 Requirements Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [5].
+
+1.4 DHCP 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 or "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:
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Length | Protocol | Algorithm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RDM | Replay Detection (64 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Replay cont. | |
+ +-+-+-+-+-+-+-+-+ |
+
+
+
+Droms, Arbaugh [Page 3]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ | |
+ | Authentication Information |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+ The code for the authentication option is TBD, and the length field
+ contains the length of the protocol, RDM, algorithm, Replay Detection
+ fields and authentication information fields in octets.
+
+ The protocol field defines the particular technique for
+ authentication used in the option. New protocols are defined as
+ described in Section 6.
+
+ The algorithm field defines the specific algorithm within the
+ technique identified by the protocol field.
+
+ The Replay Detection field is per the RDM, and the authentication
+ information field is per the protocol in use.
+
+ The Replay Detection Method (RDM) field determines the type of replay
+ detection used in the Replay Detection field.
+
+ If the RDM field contains 0x00, the replay detection field MUST be
+ set to the value of a monotonically increasing counter. 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. This
+ method MUST be supported by all protocols.
+
+ Other values of the RDM field are reserved for future definition
+ according to the procedures described in section 6.
+
+ This document defines two protocols in sections 4 and 5, 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 6.
+
+3. Interaction with Relay Agents
+
+ 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 be set to zero for the computation of any hash function over the
+ message header. Additionally, a relay agent may append the DHCP relay
+ agent information option 82 [7] as the last option in a message to
+ servers. If a server finds option 82 included in a received message,
+ the server MUST compute any hash function as if the option were NOT
+ included in the message without changing the order of options.
+
+
+
+Droms, Arbaugh [Page 4]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ Whenever the server sends back option 82 to a relay agent, the server
+ MUST not include the option in the computation of any hash function
+ over the message.
+
+
+4. Protocol 0
+
+ If the protocol field is 0, the authentication information field
+ holds a simple authentication token:
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Length |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 0 0 0 0 0| Replay Detection (64 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Replay cont. | |
+ +-+-+-+-+-+-+-+-+ |
+ | |
+ | Authentication Information |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ 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 only useful for rudimentary protection against
+ 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.
+
+
+5. Protocol 1
+
+
+
+
+Droms, Arbaugh [Page 5]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ If the protocol field is 1, the message is using the "delayed
+ authentication" mechanism. In delayed authentication, the client
+ requests authentication in its DHCPDISCOVER message and the server
+ replies with a DHCPOFFER message that includes authentication
+ information. This authentication information contains a nonce value
+ generated by the source as a message authentication code (MAC) to
+ provide message authentication and entity authentication.
+
+ This document defines the use of a particular technique based on the
+ HMAC protocol [3] using the MD5 hash [2].
+
+5.1 Management Issues
+
+ The "delayed authentication" protocol does not attempt to address
+ situations where a client may roam from one administrative domain to
+ another, i.e. interdomain roaming. This protocol is focused on
+ solving the intradomain problem where the out-of-band exchange of a
+ shared secret is feasible.
+
+5.2 Format
+
+ The format of the authentication request in a DHCPDISCOVER message
+ for protocol 1 is:
+
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RDM | Replay Detection (64 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Replay cont. |
+ +-+-+-+-+-+-+-+-+
+
+
+ The format of the authentication information for protocol 1 is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, Arbaugh [Page 6]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Length |0 0 0 0 0 0 0 1| Algorithm |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RDM | Replay Detection (64 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Replay cont. | Secret ID (32 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | secret id cont| HMAC-MD5 (128 bits) ....
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ This document defines one technique for use with protocol 1, which is
+ identified by setting the algorithm field to 1. Other techniques
+ that use different algorithms may be defined by future
+ specifications, see section 6. The following definitions will be
+ used in the description of the authentication information for
+ protocol 1, algorithm 1:
+
+ Replay Detection - as defined by the RDM field
+ K - a secret value shared between the source and
+ destination of the message; each secret has a
+ unique identifier (not shown in figures)
+ secret ID - the unique identifier for the secret value
+ used to generate the MAC for this message
+ HMAC-MD5 - the MAC generating function [3, 2].
+
+ The sender computes the MAC using the HMAC generation algorithm [3]
+ and the MD5 hash function [2]. The entire DHCP message (except as
+ noted below), including the DHCP message header and the options
+ field, is used as input to the HMAC-MD5 computation function. The
+ 'secret ID' field MUST be set to the identifier of the secret used to
+ generate the MAC.
+
+ DISCUSSION:
+
+ Algorithm 1 specifies the use of HMAC-MD5. Use of a different
+ technique, such as HMAC-SHA, will be specified as a separate
+ protocol.
+
+ Protocol 1 requires a shared secret key for each client on each
+ DHCP server with which that client may wish to use the DHCP
+ protocol. Each secret key has a unique identifier that can be
+ used by a receiver to determine which secret was used to generate
+ the MAC in the DHCP message. Therefore, protocol 1 may not scale
+ well in an architecture in which a DHCP client connects to
+ multiple administrative domains.
+
+
+
+Droms, Arbaugh [Page 7]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ Note that the meaning of an authentication option can be changed
+ by removing the secret ID, and MAC, transforming an authentication
+ option with authentication information into a request for
+ authentication. Therefore, the authentication request form of
+ this option can only appear in a DHCPDISCOVER message or a
+ DHCPINFORM message.
+
+5.3 Message validation
+
+ To validate an incoming message, the receiver first checks that
+ the value in the replay detection field is acceptable according to
+ the replay detection method specified by the RDM field. Next, the
+ receiver computes the MAC as described in [3]. The receiver MUST
+ set the 'MAC' field of the authentication option to all 0s for
+ computation of the MAC, and 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 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.
+
+ Section 3 provides additional information on handling messages
+ that include option 82 (Relay Agents).
+
+5.4 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 SHOULD
+ be initially distributed to the client through some out-of-band
+ mechanism, and SHOULD be stored locally on the client for use in
+ all authenticated DHCP messages. Once the client has been given
+ its key, it SHOULD 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, or be able to obtain in a secure
+ manner, 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. However,
+ the sharing of keys is strongly discouraged as it allows for
+ unauthorized clients to masquerade as authorized clients by
+ obtaining a copy of the shared key. 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.5 Client considerations
+
+
+
+
+Droms, Arbaugh [Page 8]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ This section describes the behavior of a DHCP client using
+ authentication protocol 1.
+
+5.5.1 INIT state
+
+ When in INIT state, the client uses protocol 1 as follows:
+
+ 1. The client MUST include the authentication request option in
+ its DHCPDISCOVER message along with option 61 [6] to identify
+ itself uniquely to the server.
+
+ 2. The client MUST validate any DHCPOFFER messages that include
+ authentication information using the mechanism specified in
+ section 5.3. The client MUST discard any messages which fail
+ to pass validation and MAY log the validation failure. The
+ client selects one DHCPOFFER message as its selected
+ configuration. If none of the DHCPOFFER messages received by
+ the client include authentication information, the client MAY
+ choose an unauthenticated message as its selected
+ configuration. The client SHOULD be configurable to accept or
+ reject unauthenticated DHCPOFFER messages.
+ 3. The client replies with a DHCPREQUEST message that MUST include
+ authentication information encoded with the same secret used by
+ the server in the selected DHCPOFFER message.
+ 4. The client MUST validate the DHCPACK message from the server.
+ The client MUST discard the DHCPACK if the message fails to
+ pass validation and MAY log the validation failure. If the
+ DHCPACK fails to pass validation, the client MUST revert to
+ INIT state and returns to step 1. The client MAY choose to
+ remember which server replied with a DHCPACK message that
+ failed to pass validation and discard subsequent messages from
+ that server.
+
+5.5.2 INIT-REBOOT state
+
+ When in INIT-REBOOT state, the client MUST use the secret it used
+ in its DHCPREQUEST message to obtain its current configuration to
+ generate authentication information for the DHCPREQUEST message.
+ The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK
+ messages if no authenticated messages were received. The client
+ MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
+ messages as specified in section 3.2 of [1].
+
+5.5.3 RENEWING state
+
+ When in RENEWING state, the client uses the secret it used in its
+ initial DHCPREQUEST message to obtain its current configuration to
+ generate authentication information for the DHCPREQUEST message.
+
+
+
+Droms, Arbaugh [Page 9]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ If client receives no DHCPACK messages or none of the DHCPACK
+ messages pass validation, the client behaves as if it had not
+ received a DHCPACK message in section 4.4.5 of the DHCP
+ specification [1].
+
+5.5.4 REBINDING state
+
+ When in REBINDING state, the client uses the secret it used in its
+ initial DHCPREQUEST message to obtain its current configuration to
+ generate authentication information for the DHCPREQUEST message.
+ If client receives no DHCPACK messages or none of the DHCPACK
+ messages pass validation, the client behaves as if it had not
+ received a DHCPACK message in section 4.4.5 of the DHCP
+ specification [1].
+
+5.5.5 DHCPINFORM message
+
+ Since the client already has some configuration information, the
+ client may also have established a shared secret value, K, with a
+ server. Therefore, the client SHOULD use the authentication
+ request as in a DHCPDISCOVER message when a shared secret value
+ exists. The client MUST treat any received DHCPACK messages as it
+ does DHCPOFFER messages, see section 5.5.1.
+
+5.5.6 DHCPRELEASE message
+
+ Since the client is already in the BOUND state, the client will
+ have a security association already established with the server.
+ Therefore, the client MUST include authentication information with
+ the DHCPRELEASE message.
+
+5.6 Server considerations
+
+ This section describes the behavior of a server in response to
+ client messages using authentication protocol 1.
+
+5.6.1 General considerations
+
+ Each server maintains a list of secrets and identifiers for those
+ secrets that it shares with clients and potential clients. This
+ information must be maintained in such a way that the server can:
+
+ * Identify an appropriate secret and the identifier for that
+ secret for use with a client that the server may not have
+ previously communicated with
+ * Retrieve the secret and identifier used by a client to which the
+ server has provided previous configuration information
+
+
+
+
+Droms, Arbaugh [Page 10]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ Each server MUST save the counter from the previous authenticated
+ message. A server MUST discard any incoming message which fails
+ the replay detection check as defined by the RDM avoid replay
+ attacks.
+
+ DISCUSSION:
+
+ The authenticated DHCPREQUEST message from a client in INIT-
+ REBOOT state can only be validated by servers that used the
+ same secret in their DHCPOFFER messages. Other servers will
+ discard the DHCPREQUEST messages. Thus, only servers that used
+ the secret selected by the client will be able to determine
+ that their offered configuration information was not selected
+ and the offered network address can be returned to the server's
+ pool of available addresses. The servers that cannot validate
+ the DHCPREQUEST message will eventually return their offered
+ network addresses to their pool of available addresses as
+ described in section 3.1 of the DHCP specification [1].
+
+5.6.2 After receiving a DHCPDISCOVER message
+
+ The server selects a secret for the client and includes
+ authentication information in the DHCPOFFER message as specified
+ in section 5, above. The server MUST record the identifier of the
+ secret selected for the client and use that same secret for
+ validating subsequent messages with the client.
+
+5.6.3 After receiving a DHCPREQUEST message
+
+ The server uses the secret identified in the message and validates
+ the message as specified in section 5.3. If the message fails to
+ pass validation or the server does not know the secret identified
+ by the 'secret ID' field, the server MUST discard the message and
+ MAY choose to log the validation failure.
+
+ If the message passes the validation procedure, the server
+ responds as described in the DHCP specification. The server MUST
+ include authentication information generated as specified in
+ section 5.2.
+
+5.6.4 After receiving a DHCPINFORM message
+
+ The server MAY choose to accept unauthenticated DHCPINFORM
+ messages, or only accept authenticated DHCPINFORM messages based
+ on a site policy.
+
+ When a client includes the authentication request in a DHCPINFORM
+ message, the server MUST respond with an authenticated DHCPACK
+
+
+
+Droms, Arbaugh [Page 11]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ message. If the server does not have a shared secret value
+ established with the sender of the DHCPINFORM message, then the
+ server MAY respond with an unauthenticated DHCPACK message, or a
+ DHCPNAK if the server does not accept unauthenticated clients
+ based on the site policy, or the server MAY choose not to respond
+ to the DHCPINFORM message.
+
+6. IANA Considerations
+
+ The author of a new DHCP authentication protocol, algorithm or
+ replay detection method will follow these steps to obtain
+ acceptance of the new procedure as a part of the DHCP Internet
+ Standard:
+
+ 1. The author devises the new authentication protocol, algorithm
+ or replay detection method.
+ 2. The author documents the new technique as an Internet Draft.
+ The protocol, algorithm or RDM code for any new procedure is
+ left as "To Be Determined" (TBD).
+ 3. The author submits the Internet Draft for review through the
+ IETF standards process as defined in "Internet Official
+ Protocol Standards" (STD 1).
+ 4. The new protocol progresses through the IETF standards process;
+ the specification of the new protocol 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. If the option is accepted as a Standard, the
+ specification for the option is published as a separate RFC.
+ 5. At the time of acceptance as a Proposed Internet Standard and
+ publication as an RFC, IANA assigns a DHCP authentication
+ protocol number to the new protocol.
+
+ This procedure for defining new authentication protocols will
+ ensure that:
+
+ * allocation of new protocol numbers is coordinated from a single
+ authority,
+ * new protocols are reviewed for technical correctness and
+ appropriateness, and
+ * documentation for new protocols is complete and published.
+
+
+ DISCUSSION:
+ This procedure is patterned after the procedure for acceptance
+ of new DHCP options.
+
+7. References
+
+
+
+
+Droms, Arbaugh [Page 12]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ Bucknell University, March 1997.
+
+ [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," RFC-2104, February 1997.
+
+ [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
+ 1992.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels," RFC-2219, March 1997.
+
+ [6] Henry, M., "DHCP Option 61 UUID Type Definition,"
+ <draft-henry-DHCP-opt61-UUID-type-00.txt> (work in
+ progress, November 1998.
+
+ [7] Patrick, M., "DHCP Relay Agent Information Option,"
+ <draft-ietf-dhc-agent-options-05.txt> (work in progress),
+ November 1998.
+
+ [8] Gupta, V., "Flexible Authentication for DHCP Messages,"
+ <draft-gupta-dhcp-auth-00.txt> (work in progress, June
+ 1998.
+
+8. Acknowledgments
+
+ Jeff Schiller and Christian Huitema developed this scheme during a
+ terminal room BOF at the Dallas IETF meeting, December 1995. The
+ editor 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.
+
+ The "delayed authentication" mechanism used in section 5 is due to
+ Bill Arbaugh. The threat model and requirements in sections 1.1
+ and 1.2 come from Bill's negotiation protocol proposal. The
+ attendees of an interim meeting of the DHC WG held in June, 1998,
+ including Peter Ford, Kim Kinnear, Glenn Waters, Rob Stevens, Bill
+ Arbaugh, Baiju Patel, Carl Smith, Thomas Narten, Stewart Kwan,
+ Munil Shah, Olafur Gudmundsson, Robert Watson, Ralph Droms, Mike
+ Dooley, Greg Rabil and Arun Kapur, developed the threat model and
+ reviewed several alternative proposals.
+
+ The replay detection method field is due to Vipul Gupta [8].
+
+
+
+
+Droms, Arbaugh [Page 13]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ Other input from Bill Sommerfield is gratefully acknowledged.
+
+ Thanks also to John Wilkins, Ran Atkinson, Shawn Mamros and Thomas
+ Narten for reviewing earlier drafts of this document.
+
+9. Security considerations
+
+ This document describes authentication and verification mechanisms
+ for DHCP.
+
+10. Editors' addresses
+
+ Ralph Droms
+ Computer Science Department
+ 323 Dana Engineering
+ Bucknell University
+ Lewisburg, PA 17837
+
+ Phone: (717) 524-1145
+ EMail: droms@bucknell.edu
+
+ Bill Arbaugh
+ Department of Computer Science
+ University of Maryland
+ A.V. Williams Building
+ College Park, MD 20742
+
+ Phone: (301) 455-2774
+ Email: waa@cs.umd.edu
+
+10. Expiration
+
+ This document will expire on December 31, 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, Arbaugh [Page 14]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of developing
+ Internet standards in which case the procedures for copyrights defined
+ in the Internet Standards process must be followed, or as required to
+ translate it into languages other than English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
+ NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
+ WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, Arbaugh [Page 15]
+\f
+DRAFT Authentication for DHCP Messages March 2000
+
+
+ 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 [6],
+ subnet address, e.g. 192.168.1.0), which must be unique to that
+ client. That is, K = MAC(MK, unique-id), where MK is a secret master
+ key and MAC is a keyed one-way function such as HMAC-MD5.
+
+ 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.
+
+ To avoid compromis of this key management system, the master key, MK,
+ MUST NOT be stored by any clients. The client SHOULD only be given
+ its key, K. If MK is compromised, a new MK SHOULD be chosen and all
+ clients given new individual keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, Arbaugh [Page 16]
+\f
+++ /dev/null
-
-
-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.
-
- 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.
- 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.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 5
- 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
-
-
-
-Droms [Page 1]
-\f
-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
- 3.1 Client-server interaction - allocating a network address. . . 13
- 3.2 Client-server interaction - reusing a previously allocated
- network address . . . . . . . . . . . . . . . . . . . . . . . 17
- 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.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
- 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
-
-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
- servers when allocating a new network address. . . . . . . . . 15
- 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
- 4. Client messages from various states. . . . . . . . . . . . . . 33
- 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
-
-1. Introduction
-
- The Dynamic Host Configuration Protocol (DHCP) provides configuration
- parameters to Internet hosts. DHCP consists of two components: a
- protocol for delivering host-specific configuration parameters from a
- DHCP server to a host and a mechanism for allocation of network
- addresses to hosts.
-
-
-
-Droms [Page 2]
-\f
-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
- document, the term "server" refers to a host providing initialization
- parameters through DHCP, and the term "client" refers to a host
- requesting initialization parameters from a DHCP server.
-
- A host should not act as a DHCP server unless explicitly configured
- to do so by a system administrator. The diversity of hardware and
- protocol implementations in the Internet would preclude reliable
- operation if random hosts were allowed to respond to DHCP requests.
- For example, IP requires the setting of many parameters within the
- protocol implementation software. Because IP can be used on many
- 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
- 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
- guaranteed to avoid allocation of duplicate network addresses.
-
- DHCP supports three mechanisms for IP address allocation. In
- "automatic allocation", DHCP assigns a permanent IP address to a
- client. In "dynamic allocation", DHCP assigns an IP address to a
- client for a limited period of time (or until the client explicitly
- relinquishes the address). In "manual allocation", a client's IP
- address is assigned by the network administrator, and DHCP is used
- simply to convey the assigned address to the client. A particular
- network will use one or more of these mechanisms, depending on the
- policies of the network administrator.
-
- Dynamic allocation is the only one of the three mechanisms that
- allows automatic reuse of an address that is no longer needed by the
- client to which it was assigned. Thus, dynamic allocation is
- particularly useful for assigning an address to a client that will be
- connected to the network only temporarily or for sharing a limited
- pool of IP addresses among a group of clients that do not need
- permanent IP addresses. Dynamic allocation may also be a good choice
- for assigning an IP address to a new client being permanently
- connected to a network where IP addresses are sufficiently scarce
- that it is important to reclaim them when old clients are retired.
- Manual allocation allows DHCP to be used to eliminate the error-prone
- process of manually configuring hosts with IP addresses in
- environments where (for whatever reasons) it is desirable to manage
- IP address assignment outside of the DHCP mechanisms.
-
- 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]
-\f
-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
- segment.
-
-1.1 Changes to RFC 1541
-
- This document updates the DHCP protocol specification that appears in
- RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
- section 3.4, 4.3 and 4.4 for details. The classing mechanism for
- identifying DHCP clients to DHCP servers has been extended to include
- "vendor" classes as defined in sections 4.2 and 4.3. The minimum
- lease time restriction has been removed. Finally, many editorial
- changes have been made to clarify the text as a result of experience
- gained in DHCP interoperability tests.
-
-1.2 Related Work
-
- There are several Internet protocols and related mechanisms that
- address some parts of the dynamic host configuration problem. The
- Reverse Address Resolution Protocol (RARP) [10] (through the
- extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
- addresses the problem of network address discovery, and includes an
- automatic IP address assignment mechanism. The Trivial File Transfer
- Protocol (TFTP) [20] provides for transport of a boot image from a
- boot server. The Internet Control Message Protocol (ICMP) [16]
- provides for informing hosts of additional routers via "ICMP
- redirect" messages. ICMP also can provide subnet mask information
- through the "ICMP mask request" message and other information through
- the (obsolete) "ICMP information request" message. Hosts can locate
- routers through the ICMP router discovery mechanism [8].
-
- BOOTP is a transport mechanism for a collection of configuration
- information. BOOTP is also extensible, and official extensions [17]
- have been defined for several configuration parameters. Morgan has
- proposed extensions to BOOTP for dynamic IP address assignment [15].
- The Network Information Protocol (NIP), used by the Athena project at
- MIT, is a distributed mechanism for dynamic IP address assignment
- [19]. The Resource Location Protocol RLP [1] provides for location
- of higher level services. Sun Microsystems diskless workstations use
- a boot procedure that employs RARP, TFTP and an RPC mechanism called
- "bootparams" to deliver configuration information and operating
- system code to diskless hosts. (Sun Microsystems, Sun Workstation
- and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
- networks also use DRARP and an auto-installation mechanism to
- automate the configuration of new hosts in an existing network.
-
- In other related work, the path minimum transmission unit (MTU)
-
-
-
-Droms [Page 4]
-\f
-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].
- Finally, the Host Requirements RFCs [3, 4] mention specific
- requirements for host reconfiguration and suggest a scenario for
- initial configuration of diskless hosts.
-
-1.3 Problem definition and issues
-
- DHCP is designed to supply DHCP clients with the configuration
- parameters defined in the Host Requirements RFCs. After obtaining
- parameters via DHCP, a DHCP client should be able to exchange packets
- with any other host in the Internet. The TCP/IP stack parameters
- supplied by DHCP are listed in Appendix A.
-
- 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
- particular subnet.
-
- DHCP allows but does not require the configuration of client
- parameters not directly related to the IP protocol. DHCP also does
- not address registration of newly configured clients with the Domain
- Name System (DNS) [12, 13].
-
- DHCP is not intended for use in configuring routers.
-
-1.4 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.
-
-
-
-
-
-
-
-
-
-Droms [Page 5]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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.
-
- 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.5 Terminology
-
- This document uses the following terms:
-
- o "DHCP client"
-
- 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.
-
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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.
-
-1.6 Design goals
-
- The following list gives general design goals for DHCP.
-
- o DHCP should be a mechanism rather than a policy. DHCP must
- allow local system administrators control over configuration
- parameters where desired; e.g., local system administrators
- 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.
-
- 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.
-
- 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
- reliability and increase performance.
-
- o DHCP must coexist with statically configured, non-participating
- hosts and with existing network protocol implementations.
-
- o DHCP must interoperate with the BOOTP relay agent behavior as
- described by RFC 951 and by RFC 1542 [21].
-
- o DHCP must provide service to existing BOOTP clients.
-
- The following list gives design goals specific to the transmission of
- the network layer parameters. DHCP must:
-
-
-
-
-
-
-
-Droms [Page 7]
-\f
-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 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,
-
- o Support fixed or permanent allocation of configuration
- parameters to specific clients.
-
-2. Protocol Summary
-
- From the client's point of view, DHCP is an extension of the BOOTP
- mechanism. This behavior allows existing BOOTP clients to
- interoperate with DHCP servers without requiring any change to the
- clients' initialization software. RFC 1542 [2] details the
- interactions between BOOTP and DHCP clients and servers [9]. There
- are some new, optional transactions that optimize the interaction
- between DHCP clients and servers that are described in sections 3 and
- 4.
-
- Figure 1 gives the format of a DHCP message and table 1 describes
- each of the fields in the DHCP message. The numbers in parentheses
- indicate the size of each field in octets. The names for the fields
- given in the figure will be used throughout this document to refer to
- the fields in DHCP messages.
-
- There are two primary differences between DHCP and BOOTP. First,
- DHCP defines mechanisms through which clients can be assigned a
- network address for a finite lease, allowing for serial reassignment
- of network addresses to different clients. Second, DHCP provides the
- mechanism for a client to acquire all of the IP configuration
- parameters that it needs in order to operate.
-
- DHCP introduces a small change in terminology intended to clarify the
- meaning of one of the fields. What was the "vendor extensions" field
- in BOOTP has been re-named the "options" field in DHCP. Similarly,
- the tagged data items that were used inside the BOOTP "vendor
- extensions" field, which were formerly referred to as "vendor
- extensions," are now termed simply "options."
-
-
-
-
-Droms [Page 8]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | op (1) | htype (1) | hlen (1) | hops (1) |
- +---------------+---------------+---------------+---------------+
- | xid (4) |
- +-------------------------------+-------------------------------+
- | secs (2) | flags (2) |
- +-------------------------------+-------------------------------+
- | ciaddr (4) |
- +---------------------------------------------------------------+
- | yiaddr (4) |
- +---------------------------------------------------------------+
- | siaddr (4) |
- +---------------------------------------------------------------+
- | giaddr (4) |
- +---------------------------------------------------------------+
- | |
- | chaddr (16) |
- | |
- | |
- +---------------------------------------------------------------+
- | |
- | sname (64) |
- +---------------------------------------------------------------+
- | |
- | file (128) |
- +---------------------------------------------------------------+
- | |
- | options (variable) |
- +---------------------------------------------------------------+
-
- Figure 1: Format of a DHCP message
-
- DHCP defines a new 'client identifier' option that is used to pass an
- explicit client identifier to a DHCP server. This change eliminates
- the overloading of the 'chaddr' field in BOOTP messages, where
- 'chaddr' is used both as a hardware address for transmission of BOOTP
- reply messages and as a client identifier. The 'client identifier'
- is an opaque key, not to be interpreted by the server; for example,
- the 'client identifier' may contain a hardware address, identical to
- the contents of the 'chaddr' field, or it may contain another type of
- identifier, such as a DNS name. The 'client identifier' chosen by a
- DHCP client MUST be unique to that client within the subnet to which
- the client is attached. If the client uses a 'client identifier' in
- one message, it MUST use that same identifier in all subsequent
- messages, to ensure that all servers correctly identify the client.
-
-
-
-
-Droms [Page 9]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- DHCP clarifies the interpretation of the 'siaddr' field as the
- address of the server to use in the next step of the client's
- bootstrap process. A DHCP server may return its own address in the
- 'siaddr' field, if the server is prepared to supply the next
- bootstrap service (e.g., delivery of an operating system executable
- image). A DHCP server always returns its own address in the 'server
- identifier' option.
-
- FIELD OCTETS DESCRIPTION
- ----- ------ -----------
-
- op 1 Message op code / message type.
- 1 = BOOTREQUEST, 2 = BOOTREPLY
- htype 1 Hardware address type, see ARP section in "Assigned
- Numbers" RFC; e.g., '1' = 10mb ethernet.
- hlen 1 Hardware address length (e.g. '6' for 10mb
- ethernet).
- hops 1 Client sets to zero, optionally used by relay agents
- when booting via a relay agent.
- xid 4 Transaction ID, a random number chosen by the
- client, used by the client and server to associate
- messages and responses between a client and a
- server.
- secs 2 Filled in by client, seconds elapsed since client
- 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.
- yiaddr 4 'your' (client) IP address.
- siaddr 4 IP address of next server to use in bootstrap;
- returned in DHCPOFFER, DHCPACK by server.
- giaddr 4 Relay agent IP address, used in booting via a
- relay agent.
- chaddr 16 Client hardware address.
- sname 64 Optional server host name, null terminated string.
- file 128 Boot file name, null terminated string; "generic"
- name or null in DHCPDISCOVER, fully qualified
- directory-path name in DHCPOFFER.
- options var Optional parameters field. See the options
- documents for a list of defined options.
-
- 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
- length 312 octets. This requirement implies that a DHCP client must
- be prepared to receive a message of up to 576 octets, the minimum IP
-
-
-
-Droms [Page 10]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- datagram size an IP host must be prepared to accept [3]. DHCP
- clients may negotiate the use of larger DHCP messages through the
- 'maximum DHCP message size' option. The options field may be further
- extended into the 'file' and 'sname' fields.
-
- In the case of a client using DHCP for initial configuration (before
- the client's TCP/IP software has been completely configured), DHCP
- requires creative use of the client's TCP/IP software and liberal
- interpretation of RFC 1122. The TCP/IP software SHOULD accept and
- forward to the IP layer any IP packets delivered to the client's
- hardware address before the IP address is configured; DHCP servers
- and BOOTP relay agents may not be able to deliver DHCP messages to
- 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
- defined as the BROADCAST (B) flag. The semantics of this flag are
- discussed in section 4.1 of this document. The remaining bits of the
- flags field are reserved for future use. They MUST be set to zero by
- clients and ignored by servers and relay agents. Figure 2 gives the
- format of the 'flags' field.
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |B| MBZ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- B: BROADCAST flag
-
- MBZ: MUST BE ZERO (reserved for future use)
-
- Figure 2: Format of the 'flags' field
-
-
-2.1 Configuration parameters repository
-
- The first service provided by DHCP is to provide persistent storage
- of network parameters for network clients. The model of DHCP
- persistent storage is that the DHCP service stores a key-value entry
- for each client, where the key is some unique identifier (for
- example, an IP subnet number and a unique identifier within the
- subnet) and the value contains the configuration parameters for the
- client.
-
-
-
-Droms [Page 11]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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
- hardware address on different subnets, and for hardware addresses
- that may not be globally unique. Alternately, the key might be the
- pair (IP-subnet-number, hostname), allowing the server to assign
- parameters intelligently to a DHCP client that has been moved to a
- different subnet or has changed hardware addresses (perhaps because
- 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.
-
-2.2 Dynamic allocation of network addresses
-
- The second service provided by DHCP is the allocation of temporary or
- permanent network (IP) addresses to clients. The basic mechanism for
- the dynamic allocation of network addresses is simple: a client
- requests the use of an address for some period of time. The
- allocation mechanism (the collection of DHCP servers) guarantees not
- to reallocate that address within the requested time and attempts to
- return the same network address each time the client requests an
- address. In this document, the period over which a network address
- is allocated to a client is referred to as a "lease" [11]. The
- client may extend its lease with subsequent requests. The client may
- issue a message to release the address back to the server when the
- client no longer needs the address. The client may ask for a
- permanent assignment by asking for an infinite lease. Even when
- assigning "permanent" addresses, a server may choose to give out
- lengthy but non-infinite leases to allow detection of the fact that
- the client has been retired.
-
- In some environments it will be necessary to reassign network
- addresses due to exhaustion of available addresses. In such
- environments, the allocation mechanism will reuse addresses whose
- lease has expired. The server should use whatever information is
- available in the configuration information repository to choose an
- 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,
-
-
-
-Droms [Page 12]
-\f
-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.
-
-
-3. The Client-Server Protocol
-
- DHCP uses the BOOTP message format defined in RFC 951 and given in
- table 1 and figure 1. The 'op' field of each DHCP message sent from
- a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
- 'op' field of each DHCP message sent from a server to a client.
-
- The first four octets of the 'options' field of the DHCP message
- contain the (decimal) values 99, 130, 83 and 99, respectively (this
- is the same magic cookie as is defined in RFC 1497 [17]). The
- remainder of the 'options' field consists of a list of tagged
- parameters that are called "options". All of the "vendor extensions"
- listed in RFC 1497 are also DHCP options. RFC 1533 gives the
- complete set of options defined for use with DHCP.
-
- Several options have been defined so far. One particular option -
- the "DHCP message type" option - must be included in every DHCP
- message. This option defines the "type" of the DHCP message.
- Additional options may be allowed, required, or not allowed,
- depending on the DHCP message type.
-
- Throughout this document, DHCP messages that include a 'DHCP message
- type' option will be referred to by the type of the message; e.g., a
- DHCP message with 'DHCP message type' option type 1 will be referred
- to as a "DHCPDISCOVER" message.
-
-3.1 Client-server interaction - allocating a network address
-
- The following summary of the protocol exchanges between clients and
- servers refers to the DHCP messages described in table 2. The
- timeline diagram in figure 3 shows the timing relationships in a
- typical client-server interaction. If the client already knows its
- address, some steps may be omitted; this abbreviated interaction is
- described in section 3.2.
-
- 1. The client broadcasts a DHCPDISCOVER message on its local physical
- subnet. The DHCPDISCOVER message MAY include options that suggest
- values for the network address and lease duration. BOOTP relay
- agents may pass the message on to DHCP servers not on the same
- physical subnet.
-
-
-
-
-
-
-
-Droms [Page 13]
-\f
-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
- reserve the offered network address, although the protocol will
- 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
- 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
- allocated addresses. The server transmits the DHCPOFFER message
- to the client, using the BOOTP relay agent if necessary.
-
- Message Use
- ------- ---
-
- DHCPDISCOVER - Client broadcast to locate available servers.
-
- DHCPOFFER - Server to client in response to DHCPDISCOVER with
- offer of configuration parameters.
-
- DHCPREQUEST - Client message to servers either (a) requesting
- offered parameters from one server and implicitly
- declining offers from all others, (b) confirming
- correctness of previously allocated address after,
- e.g., system reboot, or (c) extending the lease on a
- particular network address.
-
- DHCPACK - Server to client with configuration parameters,
- including committed network address.
-
- DHCPNAK - Server to client indicating client's notion of network
- address is incorrect (e.g., client has moved to new
- subnet) or client's lease as expired
-
- DHCPDECLINE - Client to server indicating network address is already
- in use.
-
- DHCPRELEASE - Client to server relinquishing network address and
- cancelling remaining lease.
-
- DHCPINFORM - Client to server, asking only for local configuration
- parameters; client already has externally configured
- network address.
-
- Table 2: DHCP messages
-
-
-
-
-
-Droms [Page 14]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- Server Client Server
- (not selected) (selected)
-
- v v v
- | | |
- | Begins initialization |
- | | |
- | _____________/|\_____________ |
- |/ DHCPDISCOVER | DHCPDISCOVER \|
- | | |
- Determines | Determines
- configuration | configuration
- | | |
- |\ | ____________/|
- | \_________ | /DHCPOFFER |
- | DHCPOFFER\ |/ |
- | \ | |
- | Collects replies |
- | \| |
- | Selects configuration |
- | | |
- | _____________/|\_____________ |
- |/ DHCPREQUEST | DHCPREQUEST \|
- | | |
- | | Commits configuration
- | | |
- | | _____________/|
- | |/ DHCPACK |
- | | |
- | Initialization complete |
- | | |
- . . .
- . . .
- | | |
- | Graceful shutdown |
- | | |
- | |\_____________ |
- | | DHCPRELEASE \|
- | | |
- | | Discards lease
- | | |
- v v v
- Figure 3: Timeline diagram of messages exchanged between DHCP
- client and servers when allocating a new network address
-
-
-
-
-
-
-
-Droms [Page 15]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 3. The client receives one or more DHCPOFFER messages from one or more
- servers. The client may choose to wait for multiple responses.
- The client chooses one server from which to request configuration
- parameters, based on the configuration parameters offered in the
- DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
- that MUST include the 'server identifier' option to indicate which
- server it has selected, and that MAY include other options
- specifying desired configuration values. The 'requested IP
- address' option MUST be set to the value of 'yiaddr' in the
- DHCPOFFER message from the server. This DHCPREQUEST message is
- broadcast and relayed through DHCP/BOOTP relay agents. To help
- ensure that any BOOTP relay agents forward the DHCPREQUEST message
- to the same set of DHCP servers that received the original
- DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
- value in the DHCP message header's 'secs' field and be sent to the
- same IP broadcast address as the original DHCPDISCOVER message.
- The client times out and retransmits the DHCPDISCOVER message if
- the client receives no DHCPOFFER messages.
-
- 4. The servers receive the DHCPREQUEST broadcast from the client.
- Those servers not selected by the DHCPREQUEST message use the
- message as notification that the client has declined that server's
- offer. The server selected in the DHCPREQUEST message commits the
- binding for the client to persistent storage and responds with a
- DHCPACK message containing the configuration parameters for the
- requesting client. The combination of 'client identifier' or
- 'chaddr' and assigned network address constitute a unique
- identifier for the client's lease and are used by both the client
- and server to identify a lease referred to in any DHCP messages.
- Any configuration parameters in the DHCPACK message SHOULD NOT
- conflict with those in the earlier DHCPOFFER message to which the
- client is responding. The server SHOULD NOT check the offered
- network address at this point. The 'yiaddr' field in the DHCPACK
- messages is filled in with the selected network address.
-
- If the selected server is unable to satisfy the DHCPREQUEST message
- (e.g., the requested network address has been allocated), the
- server SHOULD respond with a DHCPNAK message.
-
- A server MAY choose to mark addresses offered to clients in
- DHCPOFFER messages as unavailable. The server SHOULD mark an
- address offered to a client in a DHCPOFFER message as available if
- the server receives no DHCPREQUEST message from that client.
-
- 5. The client receives the DHCPACK message with configuration
- parameters. The client SHOULD perform a final check on the
- parameters (e.g., ARP for allocated network address), and notes the
- duration of the lease specified in the DHCPACK message. At this
-
-
-
-Droms [Page 16]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- point, the client is configured. If the client detects that the
- address is already in use (e.g., through the use of ARP), the
- client MUST send a DHCPDECLINE message to the server and restarts
- the configuration process. The client SHOULD wait a minimum of ten
- seconds before restarting the configuration process to avoid
- excessive network traffic in case of looping.
-
- If the client receives a DHCPNAK message, the client restarts the
- configuration process.
-
- The client times out and retransmits the DHCPREQUEST message if the
- client receives neither a DHCPACK or 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 reverts to INIT state and
- restarts the initialization process. The client SHOULD notify the
- user that the initialization process has failed and is restarting.
-
- 6. 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. If the
- client used a 'client identifier' when it obtained the lease, it
- MUST use the same 'client identifier' in the DHCPRELEASE message.
-
-3.2 Client-server interaction - reusing a previously allocated network
- address
-
- If a client remembers and wishes to reuse a previously allocated
- network address, a client may choose to omit some of the steps
- described in the previous section. The timeline diagram in figure 4
- shows the timing relationships in a typical client-server interaction
- for a client reusing a previously allocated network address.
-
- 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
- network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- DHCPREQUEST message.
-
- 2. Servers with knowledge of the client's configuration parameters
- respond with a DHCPACK message to the client. Servers SHOULD NOT
- check that the client's network address is already in use; the
- client may respond to ICMP Echo Request messages at this point.
-
- Server Client Server
-
- v v v
- | | |
- | Begins |
- | initialization |
- | | |
- | /|\ |
- | ___________/ | \___________ |
- | /DHCPREQUEST | 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]
-\f
-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]
-\f
-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.
-
-3.3 Interpretation and representation of time values
-
- A client acquires a lease for a network address for a fixed period of
- time (which may be infinite). Throughout the protocol, times are to
- be represented in units of seconds. The time value of 0xffffffff is
- reserved to represent "infinity".
-
- As clients and servers may not have synchronized clocks, times are
- represented in DHCP messages as relative times, to be interpreted
- with respect to the client's local clock. Representing relative
- times in units of seconds in an unsigned 32 bit word gives a range of
- relative times from 0 to approximately 100 years, which is sufficient
- for the relative times to be measured using DHCP.
-
- The algorithm for lease duration interpretation given in the previous
- paragraph assumes that client and server clocks are stable relative
- to each other. If there is drift between the two clocks, the server
- may consider the lease expired before the client does. To
- compensate, the server may return a shorter lease duration to the
- client than the server commits to its local database of client
- information.
-
-3.4 Obtaining parameters with externally configured network address
-
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- unicast the DHCPACK reply to the address given in the 'ciaddr' field
- of the DHCPINFORM message.
-
- The server SHOULD check the network address in a DHCPINFORM message
- for consistency, but MUST NOT check for an existing lease. The
- server forms a DHCPACK message containing the configuration
- parameters for the requesting client and sends the DHCPACK message
- directly to the client.
-
-3.5 Client parameters in DHCP
-
- Not all clients require initialization of all parameters listed in
- Appendix A. Two techniques are used to reduce the number of
- parameters transmitted from the server to the client. First, most of
- the parameters have defaults defined in the Host Requirements RFCs;
- if the client receives no parameters from the server that override
- the defaults, a client uses those default values. Second, in its
- initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
- server with a list of specific parameters the client is interested
- in. If the client includes a list of parameters in a DHCPDISCOVER
- message, it MUST include that list in any subsequent DHCPREQUEST
- messages.
-
- The client SHOULD include the 'maximum DHCP message size' option to
- let the server know how large the server may make its DHCP messages.
- The parameters returned to a client may still exceed the space
- allocated to options in a DHCP message. In this case, two additional
- options flags (which must appear in the 'options' field of the
- message) indicate that the 'file' and 'sname' fields are to be used
- for options.
-
- The client can inform the server which configuration parameters the
- client is interested in by including the 'parameter request list'
- option. The data portion of this option explicitly lists the options
- requested by tag number.
-
- In addition, the client may suggest values for the network address
- and lease time in the DHCPDISCOVER message. The client may include
- the 'requested IP address' option to suggest that a particular IP
- address be assigned, and may include the 'IP address lease time'
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- with an IP address in BOUND, RENEWING or REBINDING state.
-
- If a server receives a DHCPREQUEST message with an invalid 'requested
- IP address', the server SHOULD respond to the client with a DHCPNAK
- message and may choose to report the problem to the system
- administrator. The server may include an error message in the
- 'message' option.
-
-3.6 Use of DHCP in clients with multiple interfaces
-
- A client with multiple network interfaces must use DHCP through each
- interface independently to obtain configuration information
- parameters for those separate interfaces.
-
-3.7 When clients should use DHCP
-
- A client SHOULD use DHCP to reacquire or verify its IP address and
- network parameters whenever the local network parameters may have
- changed; e.g., at system boot time or after a disconnection from the
- local network, as the local network configuration may change without
- the client's or user's knowledge.
-
- If a client has knowledge of a previous network address and is unable
- to contact a local DHCP server, the client may continue to use the
- previous network address until the lease for that address expires.
- If the lease expires before the client can contact a DHCP server, the
- client must immediately discontinue use of the previous network
- address and may inform local users of the problem.
-
-4. Specification of the DHCP client-server protocol
-
- In this section, we assume that a DHCP server has a block of network
- addresses from which it can satisfy requests for new addresses. Each
- server also maintains a database of allocated addresses and leases in
- local permanent storage.
-
-4.1 Constructing and sending DHCP messages
-
- DHCP clients and servers both construct DHCP messages by filling in
- fields in the fixed format section of the message and appending
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- (68). A server with multiple network address (e.g., a multi-homed
- host) MAY use any of its network addresses in outgoing DHCP messages.
-
- The 'server identifier' field is used both to identify a DHCP server
- in a DHCP message and as a destination address from clients to
- servers. A server with multiple network addresses MUST be prepared
- to to accept any of its network addresses as identifying that server
- in a DHCP message. To accommodate potentially incomplete network
- connectivity, a server MUST choose an address as a 'server
- identifier' that, to the best of the server's knowledge, is reachable
- from the client. For example, if the DHCP server and the DHCP client
- are connected to the same subnet (i.e., the 'giaddr' field in the
- message from the client is zero), the server SHOULD select the IP
- address the server is using for communication on that subnet as the
- 'server identifier'. If the server is using multiple IP addresses on
- that subnet, any such address may be used. If the server has
- received a message through a DHCP relay agent, the server SHOULD
- choose an address from the interface on which the message was
- recieved as the 'server identifier' (unless the server has other,
- better information on which to make its choice). DHCP clients MUST
- use the IP address provided in the 'server identifier' option for any
- unicast requests to the DHCP server.
-
- DHCP messages broadcast by a client prior to that client obtaining
- its IP address must have the source address field in the IP header
- set to 0.
-
- If the 'giaddr' field in a DHCP message from a client is non-zero,
- the server sends any return messages to the 'DHCP server' port on the
- BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
- field is zero and the 'ciaddr' field is nonzero, then the server
- unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
- If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
- set, then the server broadcasts DHCPOFFER and DHCPACK messages to
- 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
- 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
- messages to the client's hardware address and 'yiaddr' address. In
- all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
- messages to 0xffffffff.
-
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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
- entirely contained in that field. The options in the 'options' field
- MUST be interpreted first, so that any 'option overload' options may
- be interpreted. The 'file' field MUST be interpreted next (if the
- 'option overload' option indicates that the 'file' field contains
- DHCP options), followed by the 'sname' field.
-
- The values to be passed in an 'option' tag may be too long to fit in
- the 255 octets available to a single option (e.g., a list of routers
- in a 'router' option [21]). Options may appear only once, unless
- otherwise specified in the options document. The client concatenates
- the values of multiple instances of the same option into a single
- parameter list for configuration.
-
- DHCP clients are responsible for all message retransmission. The
- client MUST adopt a retransmission strategy that incorporates a
- randomized exponential backoff algorithm to determine the delay
- between retransmissions. The delay between retransmissions SHOULD be
- chosen to allow sufficient time for replies from the server to be
- delivered based on the characteristics of the internetwork between
- the client and the server. For example, in a 10Mb/sec Ethernet
- internetwork, the delay before the first retransmission SHOULD be 4
- seconds randomized by the value of a uniform random number chosen
- from the range -1 to +1. Clients with clocks that provide resolution
- granularity of less than one second may choose a non-integer
- randomization value. The delay before the next retransmission SHOULD
- be 8 seconds randomized by the value of a uniform number chosen from
- the range -1 to +1. The retransmission delay SHOULD be doubled with
- subsequent retransmissions up to a maximum of 64 seconds. The client
- MAY provide an indication of retransmission attempts to the user as
- an indication of the progress of the configuration process.
-
- The 'xid' field is used by the client to match incoming DHCP messages
- with pending requests. A DHCP client MUST choose 'xid's in such a
- way as to minimize the chance of using an 'xid' identical to one used
- by another client. For example, a client may choose a different,
- random initial 'xid' each time the client is rebooted, and
- subsequently use sequential 'xid's until the next reboot. Selecting
- a new 'xid' for each retransmission is an implementation decision. A
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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
- IP address (leading to a deadlock in which the client's IP address
- cannot be delivered until the client has been configured with an IP
- address).
-
- A client that cannot receive unicast IP datagrams until its protocol
- software has been configured with an IP address SHOULD set the
- BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
- DHCPREQUEST messages that client sends. The BROADCAST bit will
- provide a hint to the DHCP server and BOOTP relay agent to broadcast
- any messages to the client on the client's subnet. A client that can
- receive unicast IP datagrams before its protocol software has been
- configured SHOULD clear the BROADCAST bit to 0. The BOOTP
- clarifications document discusses the ramifications of the use of the
- BROADCAST bit [21].
-
- A server or relay agent sending or relaying a DHCP message directly
- to a DHCP client (i.e., not to a relay agent specified in the
- 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
- field. If this bit is set to 1, the DHCP message SHOULD be sent as
- an IP broadcast using an IP broadcast address (preferably 0xffffffff)
- as the IP destination address and the link-layer broadcast address as
- the link-layer destination address. If the BROADCAST bit is cleared
- to 0, the message SHOULD be sent as an IP unicast to the IP address
- specified in the 'yiaddr' field and the link-layer address specified
- in the 'chaddr' field. If unicasting is not possible, the message
- MAY be sent as an IP broadcast using an IP broadcast address
- (preferably 0xffffffff) as the IP destination address and the link-
- layer broadcast address as the link-layer destination address.
-
-4.2 DHCP server administrative controls
-
- DHCP servers are not required to respond to every DHCPDISCOVER and
- DHCPREQUEST message they receive. For example, a network
- administrator, to retain stringent control over the clients attached
- to the network, may choose to configure DHCP servers to respond only
- to clients that have been previously registered through some external
- mechanism. The DHCP specification describes only the interactions
- between clients and servers when the clients and servers choose to
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
- messages when determining the correct parameters for a particular
- client.
-
- A DHCP server needs to use some unique identifier to associate a
- client with its lease. The client MAY choose to explicitly provide
- the identifier through the 'client identifier' option. If the client
- supplies a 'client identifier', the client MUST use the same 'client
- identifier' in all subsequent messages, and the server MUST use that
- identifier to identify the client. If the client does not provide a
- 'client identifier' option, the server MUST use the contents of the
- 'chaddr' field to identify the client. It is crucial for a DHCP
- client to use an identifier unique within the subnet to which the
- client is attached in the 'client identifier' option. Use of
- 'chaddr' as the client's unique identifier may cause unexpected
- results, as that identifier may be associated with a hardware
- interface that could be moved to a new client. Some sites may choose
- to use a manufacturer's serial number as the 'client identifier', to
- avoid unexpected changes in a clients network address due to transfer
- of hardware interfaces among computers. Sites may also choose to use
- a DNS name as the 'client identifier', causing address leases to be
- associated with the DNS name rather than a specific hardware box.
-
- DHCP clients are free to use any strategy in selecting a DHCP server
- among those from which the client receives a DHCPOFFER message. The
- client implementation of DHCP SHOULD provide a mechanism for the user
- to select directly the 'vendor class identifier' values.
-
-4.3 DHCP server behavior
-
- A DHCP server processes incoming DHCP messages from a client based on
- the current state of the binding for that client. A DHCP server can
- receive the following messages from a client:
-
- o DHCPDISCOVER
-
- o DHCPREQUEST
-
- o DHCPDECLINE
-
- o DHCPRELEASE
-
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
-4.3.1 DHCPDISCOVER message
-
- When a server receives a DHCPDISCOVER message from a client, the
- server chooses a network address for the requesting client. If no
- address is available, the server may choose to report the problem to
- 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 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 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
- refuse to allocate an address to a particular client even though free
- addresses are available.
-
- Note that, in some network architectures (e.g., internets with more
- than one IP subnet assigned to a physical network segment), it may be
- the case that the DHCP client should be assigned an address from a
- different subnet than the address recorded in 'giaddr'. Thus, DHCP
- does not require that the client be assigned as address from the
- subnet in 'giaddr'. A server is free to choose some other subnet,
- and it is beyond the scope of the DHCP specification to describe ways
- in which the assigned IP address might be chosen.
-
- While not required for correct operation of DHCP, the server SHOULD
- NOT reuse the selected network address before the client responds to
- the server's DHCPOFFER message. The server may choose to record the
- address as offered to the client.
-
- 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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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
-
- o IF the client has not requested a specific lease in the
- DHCPDISCOVER message and the client does not have an assigned
- network address, the server assigns a locally configured default
- lease time, ELSE
-
- o IF the client has requested a specific lease in the DHCPDISCOVER
- message (regardless of whether the client has an assigned network
- address), the server may choose either to return the requested
- lease (if the lease is acceptable to local policy) or select
- another lease.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 28]
-\f
-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
-
- Table 3: Fields and options used by DHCP servers
-
-
-
-
-Droms [Page 29]
-\f
-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
- parameters (with the possible exception of a newly allocated network
- address) to ensure predictable client behavior regardless of which
- server the client selects. The configuration parameters MUST be
- selected by applying the following rules in the order given below.
- The network administrator is responsible for configuring multiple
- DHCP servers to ensure uniform responses from those servers. The
- server MUST return to the client:
-
- o The client's network address, as determined by the rules given
- earlier in this section,
-
- o The expiration time for the client's lease, as determined by the
- rules given earlier in this section,
-
- o Parameters requested by the client, according to the following
- rules:
-
- -- IF the server has been explicitly configured with a default
- value for the parameter, the server MUST include that value
- in an appropriate option in the 'option' field, ELSE
-
- -- IF the server recognizes the parameter as a parameter
- defined in the Host Requirements Document, the server MUST
- include the default value for that parameter as given in the
- Host Requirements Document in an appropriate option in the
- 'option' field, ELSE
-
- -- The server MUST NOT return a value for that parameter,
-
- 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
- explicitly allowed in the DHCP Options and BOOTP Vendor
- Extensions document.
-
- o Any parameters from the existing binding that differ from the Host
- Requirements Document defaults,
-
- o Any parameters specific to this client (as identified by
- the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
- or DHCPREQUEST message), e.g., as configured by the network
- administrator,
-
-
-
-
-
-
-Droms [Page 30]
-\f
-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),
- e.g., as configured by the network administrator; the parameters
- MUST be identified by an exact match between the client's vendor
- class identifiers and the client's classes identified in the
- server,
-
- o Parameters with non-default values on the client's subnet.
-
- The server MAY choose to return the 'vendor class identifier' used to
- determine the parameters in the DHCPOFFER message to assist the
- client in selecting which DHCPOFFER to accept. The server inserts
- the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
- the DHCPOFFER message and sends the DHCPOFFER message to the
- requesting client.
-
-4.3.2 DHCPREQUEST message
-
- A DHCPREQUEST message may come from a client responding to a
- DHCPOFFER message from a server, from a client verifying a previously
- allocated IP address or from a client extending the lease on a
- network address. If the DHCPREQUEST message contains a 'server
- identifier' option, the message is in response to a DHCPOFFER
- message. Otherwise, the message is a request to verify or extend an
- existing lease. If the client uses a 'client identifier' in a
- DHCPREQUEST message, it MUST use that same 'client identifier' in all
- subsequent messages. If the client included a list of requested
- parameters in a DHCPDISCOVER message, it MUST include that list in
- all subsequent messages.
-
- 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
- DHCPACK message for configuration.
-
- Clients send DHCPREQUEST messages as follows:
-
- 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.
-
- 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
-
-
-
-Droms [Page 31]
-\f
-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]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- 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.
-
- 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.
-
- 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
-
- If the server receives a DHCPDECLINE message, the client has
- discovered through some other means that the suggested network
- address is already in use. The server MUST mark the network address
- as not available and SHOULD notify the local system administrator of
- a possible configuration problem.
-
-4.3.4 DHCPRELEASE message
-
- Upon receipt of a DHCPRELEASE message, the server marks the network
- address as not allocated. The server SHOULD retain a record of the
- client's initialization parameters for possible reuse in response to
- subsequent requests from the client.
-
-4.3.5 DHCPINFORM message
-
-
-
-Droms [Page 33]
-\f
-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
- to the client and SHOULD NOT fill in 'yiaddr'. The server includes
- other parameters in the DHCPACK message as defined in section 4.3.1.
-
-4.3.6 Client messages
-
- Table 4 details the differences between messages from clients in
- various states.
-
- ---------------------------------------------------------------------
- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
- ---------------------------------------------------------------------
- |broad/unicast |broadcast |broadcast |unicast |broadcast |
- |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
- |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
- |ciaddr |zero |zero |IP address |IP address|
- ---------------------------------------------------------------------
-
- Table 4: Client messages from different states
-
-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 DHCPACK
-
- 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
- has selected its parameters, it has completed the configuration
- process.
-
- Table 5 gives the use of the fields and options in a DHCP message by
- a client. The remainder of this section describes the action of the
- DHCP client for each possible incoming message. The description in
- the following section corresponds to the full configuration procedure
- previously described in section 3.1, and the text in the subsequent
- section corresponds to the abbreviated configuration procedure
- described in section 3.2.
-
-
-
-
-
-
-Droms [Page 34]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- -------- -------
-| | +-------------------------->| |<-------------------+
-| INIT- | | +-------------------->| INIT | |
-| REBOOT |DHCPNAK/ +---------->| |<---+ |
-| |Restart| | ------- | |
- -------- | DHCPNAK/ | | |
- | Discard offer | -/Send DHCPDISCOVER |
--/Send DHCPREQUEST | | |
- | | | DHCPACK v | |
- ----------- | (not accept.)/ ----------- | |
-| | | Send DHCPDECLINE | | |
-| REBOOTING | | | | SELECTING |<----+ |
-| | | / | | |DHCPOFFER/ |
- ----------- | / ----------- | |Collect |
- | | / | | | replies |
-DHCPACK/ | / +----------------+ +-------+ |
-Record lease, set| | v Select offer/ |
-timers T1, T2 ------------ send DHCPREQUEST | |
- | +----->| | DHCPNAK, Lease expired/ |
- | | | REQUESTING | Halt network |
- DHCPOFFER/ | | | |
- Discard ------------ | |
- | | | | ----------- |
- | +--------+ DHCPACK/ | | |
- | Record lease, set -----| REBINDING | |
- | timers T1, T2 / | | |
- | | DHCPACK/ ----------- |
- | v Record lease, set ^ |
- +----------------> ------- /timers T1,T2 | |
- +----->| |<---+ | |
- | | BOUND |<---+ | |
- DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
- DHCPNAK/Discard ------- | Broadcast Halt network
- | | | | DHCPREQUEST |
- +-------+ | DHCPACK/ | |
- T1 expires/ Record lease, set | |
- Send DHCPREQUEST timers T1, T2 | |
- to leasing server | | |
- | ---------- | |
- | | |------------+ |
- +->| RENEWING | |
- | |----------------------------+
- ----------
- Figure 5: State-transition diagram for DHCP clients
-
-
-
-
-
-
-
-Droms [Page 35]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
-4.4.1 Initialization and allocation of network address
-
- The client begins in INIT state and forms a DHCPDISCOVER message.
- The client SHOULD wait a random time between one and ten seconds to
- desynchronize the use of DHCP at startup. The client sets 'ciaddr'
- to 0x00000000. The client MAY request specific parameters by
- including the 'parameter request list' option. The client MAY
- suggest a network address and/or lease time by including the
- 'requested IP address' and 'IP address lease time' options. The
- client MUST include its hardware address in the 'chaddr' field, if
- necessary for delivery of DHCP reply messages. The client MAY
- include a different unique identifier in the 'client identifier'
- option, as discussed in section 4.2. If the client included a list
- of requested parameters in a DHCPDISCOVER message, it MUST include
- that list in all subsequent messages.
-
- The client generates and records a 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 then broadcasts the DHCPDISCOVER on the local hardware
- broadcast address to the 0xffffffff IP broadcast address and 'DHCP
- server' UDP port.
-
- If the 'xid' of an arriving DHCPOFFER message does not match the
- 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
- must be silently discarded. Any arriving DHCPACK messages must be
- silently discarded.
-
- The client collects DHCPOFFER messages over a period of time, selects
- one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
- messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
- from the previously used server) and extracts the server address from
- the 'server identifier' option in the DHCPOFFER message. The time
- over which the client collects messages and the mechanism used to
- select one DHCPOFFER are implementation dependent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 36]
-\f
-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]
-\f
-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
-
- Table 5: Fields and options used by DHCP clients
-
- If the parameters are acceptable, the client records the address of
- the server that supplied the parameters from the 'server identifier'
- field and sends that address in the 'server identifier' field of a
- DHCPREQUEST broadcast message. Once the DHCPACK message from the
- server arrives, the client is initialized and moves to BOUND state.
- The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
- message. The client records the lease expiration time as the sum of
- the time at which the original request was sent and the duration of
- the lease from the DHCPACK message. The client SHOULD perform a
- check on the suggested address to ensure that the address is not
- already in use. For example, if the client is on a network that
- supports ARP, the client may issue an ARP request for the suggested
- request. When broadcasting an ARP request for the suggested address,
- 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
- 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
- ARP cache entries in hosts on the client's subnet.
-
-4.4.2 Initialization with known network address
-
- The client begins in INIT-REBOOT state and sends a DHCPREQUEST
- message. The client MUST insert its known network address as a
- '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]
-\f
-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
- 'server identifier' in the DHCPREQUEST message. The client then
- broadcasts the DHCPREQUEST on the local hardware broadcast address to
- the 'DHCP server' UDP port.
-
- Once a DHCPACK message with an 'xid' field matching that in the
- client's DHCPREQUEST message arrives from any server, the client is
- initialized and moves to BOUND state. The client records the lease
- expiration time as the sum of the time at which the DHCPREQUEST
- message was sent and the duration of the lease from the DHCPACK
- message.
-
-4.4.3 Initialization with an externally assigned network address
-
- The client sends a DHCPINFORM message. The client may request
- specific configuration parameters by including the 'parameter request
- list' option. The client generates and records a random transaction
- identifier and inserts that identifier into the 'xid' field. The
- client places its own network address in the 'ciaddr' field. The
- client SHOULD NOT request lease time parameters.
-
- The client then unicasts the DHCPINFORM to the DHCP server if it
- knows the server's address, otherwise it broadcasts the message to
- the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
- directed to the 'DHCP server' UDP port.
-
- Once a DHCPACK message with an 'xid' field matching that in the
- client's DHCPINFORM message arrives from any server, the client is
- initialized.
-
- If the client does not receive a DHCPACK within a reasonable period
- 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
- defaults as per Appendix A.
-
-4.4.4 Use of broadcast and unicast
-
- The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
- messages, unless the client knows the address of a DHCP server. The
- client unicasts DHCPRELEASE messages to the server. Because the
- client is declining the use of the IP address supplied by the server,
- the client broadcasts DHCPDECLINE messages.
-
- 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]
-\f
-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
- messages sent to the IP address of a known DHCP server, the DHCP
- client reverts to using the IP broadcast address.
-
-4.4.5 Reacquisition and expiration
-
- The client maintains two times, T1 and T2, that specify the times at
- which the client tries to extend its lease on its network address.
- T1 is the time at which the client enters the RENEWING state and
- attempts to contact the server that originally issued the client's
- network address. T2 is the time at which the client enters the
- REBINDING state and attempts to contact any server. T1 MUST be
- earlier than T2, which, in turn, MUST be earlier than the time at
- which the client's lease will expire.
-
- To avoid the need for synchronized clocks, T1 and T2 are expressed in
- options as relative times [2].
-
- At time T1 the client moves to RENEWING state and sends (via unicast)
- a DHCPREQUEST message to the server to extend its lease. The client
- sets the 'ciaddr' field in the DHCPREQUEST to its current network
- address. The client records the local time at which the DHCPREQUEST
- message is sent for computation of the lease expiration time. The
- client MUST NOT include a 'server identifier' in the DHCPREQUEST
- message.
-
- Any DHCPACK messages that arrive with an 'xid' that does not match
- the 'xid' of the client's DHCPREQUEST message are silently discarded.
- When the client receives a DHCPACK from the server, the client
- computes the lease expiration time as the sum of the time at which
- the client sent the DHCPREQUEST message and the duration of the lease
- in the DHCPACK message. The client has successfully reacquired its
- network address, returns to BOUND state and may continue network
- processing.
-
- 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
- current network address. The client MUST NOT include a 'server
- identifier' in the DHCPREQUEST message.
-
- Times T1 and T2 are configurable by the server through options. T1
- defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
- duration_of_lease). Times T1 and T2 SHOULD be chosen with some
- random "fuzz" around a fixed value, to avoid synchronization of
- client reacquisition.
-
-
-
-Droms [Page 40]
-\f
-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
- T2, and their values SHOULD be adjusted from their original values to
- take account of the time remaining on the lease.
-
- In both RENEWING and REBINDING states, if the client receives no
- response to its DHCPREQUEST message, the client SHOULD wait one-half
- of the remaining time until T2 (in RENEWING state) and one-half of
- the remaining lease time (in REBINDING state), down to a minimum of
- 60 seconds, before retransmitting the DHCPREQUEST message.
-
- If the lease expires before the client receives a DHCPACK, the client
- moves to INIT state, MUST immediately stop any other network
- processing and requests network initialization parameters as if the
- client were uninitialized. If the client then receives a DHCPACK
- allocating that client its previous network address, the client
- SHOULD continue network processing. If the client is given a new
- network address, it MUST NOT continue using the previous network
- address and SHOULD notify the local users of the problem.
-
-4.4.6 DHCPRELEASE
-
- If the client no longer requires use of its assigned network address
- (e.g., the client is gracefully shut down), the client sends a
- 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.
-
-
-
-
-
-
-
-
-
-Droms [Page 41]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
-6. References
-
- [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
- 1983.
-
- [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
- University, October 1993.
-
- [3] 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 --
- Application and Support, STD 3, RFC 1123, USC/Information
- Sciences Institute, October 1989.
-
- [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
- (DRARP)", Work in Progress.
-
- [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
- Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
- Communications Review), 20(4):50--59, 1990.
-
- [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
- Stanford and SUN Microsystems, September 1985.
-
- [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
- PARC, September 1991.
-
- [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 [Page 42]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
- [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.
-
- [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.
-
- [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
- [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.
-
- [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
- Protocol", RFC 1542, Carnegie Mellon University, October 1993.
-
-7. Security Considerations
-
- DHCP is built directly on UDP and IP which are as yet inherently
- insecure. Furthermore, DHCP is generally intended to make
- maintenance of remote and/or diskless hosts easier. While perhaps
- not impossible, configuring such hosts with passwords or keys may be
- difficult and inconvenient. Therefore, DHCP in its current form is
- quite insecure.
-
- 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
- information (including spoof routers, etc.), incorrect domain
- nameserver addresses (such as spoof nameservers), and so on.
- Clearly, once this seed information is in place, an attacker can
- further compromise affected systems.
-
- Malicious DHCP clients could masquerade as legitimate clients and
- retrieve information intended for those legitimate clients. Where
- dynamic allocation of resources is used, a malicious client could
- claim all resources for itself, thereby denying resources to
- legitimate clients.
-
-
-
-
-Droms [Page 43]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
-8. Author's Address
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
- This document will expire on May 30, 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms [Page 44]
-\f
-DRAFT Dynamic Host Configuration Protocol December 1996
-
-
-A. Host Configuration Parameters
-
- IP-layer_parameters,_per_host:_
-
- Be a router on/off HRC 3.1
- Non-local source routing on/off HRC 3.3.5
- Policy filters for
- non-local source routing (list) HRC 3.3.5
- Maximum reassembly size integer HRC 3.3.2
- Default TTL integer HRC 3.2.1.7
- PMTU aging timeout integer MTU 6.6
- MTU plateau table (list) MTU 7
- IP-layer_parameters,_per_interface:_
- IP address (address) HRC 3.3.1.6
- Subnet mask (address mask) HRC 3.3.1.6
- MTU integer HRC 3.3.3
- All-subnets-MTU on/off HRC 3.3.3
- Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
- Perform mask discovery on/off HRC 3.2.2.9
- Be a mask supplier on/off HRC 3.2.2.9
- Perform router discovery on/off RD 5.1
- Router solicitation address (address) RD 5.1
- Default routers, list of:
- router address (address) HRC 3.3.1.6
- preference level integer HRC 3.3.1.6
- Static routes, list of:
- destination (host/subnet/net) HRC 3.3.1.2
- destination mask (address mask) HRC 3.3.1.2
- type-of-service integer HRC 3.3.1.2
- first-hop router (address) HRC 3.3.1.2
- ignore redirects on/off HRC 3.3.1.2
- PMTU integer MTU 6.6
- perform PMTU discovery on/off MTU 6.6
-
- Link-layer_parameters,_per_interface:_
- Trailers on/off HRC 2.3.1
- ARP cache timeout integer HRC 2.3.2.1
- Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
-
- TCP_parameters,_per_host:_
- TTL integer HRC 4.2.2.19
- Keep-alive interval integer HRC 4.2.3.6
- Keep-alive data size 0/1 HRC 4.2.3.6
-
-Key:
-
- MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
- RD = Router Discovery (RFC 1256, Proposed Standard)
-
-
-
-Droms [Page 45]
-
+++ /dev/null
-
-
-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 \f[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 \f[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 \f[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 \f[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 \f[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 \f[Page 6]
-
-
--- /dev/null
+
+
+DHC Working Group M. Stapp
+Internet-Draft Y. Rekhter
+Expires: September 2000 Cisco Systems, Inc.
+ March 10, 2000
+
+
+ Interaction between DHCP and DNS
+ <draft-ietf-dhc-dhcp-dns-12.txt>
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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 view the entire list of Internet-Draft Shadow Directories, see
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 2000.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ DHCP provides a powerful mechanism for IP host configuration.
+ However, the configuration capability provided by DHCP does not
+ include updating DNS, and specifically updating the name to address
+ and address to name mappings maintained in the DNS.
+
+ This document specifies how DHCP clients and servers should use the
+ Dynamic DNS Updates mechanism in RFC2136[5] to update the DNS name
+ to address and address to name mappings so that the mappings for
+ DHCP clients will be consistent with the IP addresses that the
+ clients acquire via DHCP.
+
+
+
+
+
+
+
+Stapp & Rekhter Expires September 2000 [Page 1]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+Table of Contents
+
+ 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3
+ 4. Issues with DDNS in DHCP Environments . . . . . . . . . . . 4
+ 4.1 Name Collisions . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2 Multiple DHCP servers . . . . . . . . . . . . . . . . . . . 6
+ 4.3 Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6
+ 4.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . . 6
+ 4.4 DNS RR TTLs . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Client FQDN Option . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3 The Domain Name Field . . . . . . . . . . . . . . . . . . . 10
+ 6. DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 10
+ 7. DHCP Server behavior . . . . . . . . . . . . . . . . . . . . 12
+ 8. Procedures for performing DNS updates . . . . . . . . . . . 14
+ 8.1 Adding A RRs to DNS . . . . . . . . . . . . . . . . . . . . 14
+ 8.2 Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 15
+ 8.3 Removing Entries from DNS . . . . . . . . . . . . . . . . . 15
+ 8.4 Updating other RRs . . . . . . . . . . . . . . . . . . . . . 16
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . 16
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
+ References . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp & Rekhter Expires September 2000 [Page 2]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119[6].
+
+2. Introduction
+
+ DNS (RFC1034[1], RFC1035[2]) maintains (among other things) the
+ information about mapping between hosts' Fully Qualified Domain
+ Names (FQDNs) RFC1594[4] 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. The Dynamic
+ DNS Updates specification (RFC2136[5]) describes a mechanism that
+ enables DNS information to be updated over a network.
+
+ DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client)
+ can acquire certain configuration information, along with 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.
+
+ 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
+ is 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.
+
+ Although this document refers to the A and PTR DNS record types and
+ to DHCP assignment of IPv4 addresses, the same procedures and
+ requirements apply for updates to the analogous RR types that are
+ used when clients are assigned IPv6 addresses via DHCPv6.
+
+3. Models of Operation
+
+ When a DHCP client acquires a new address, a site's administrator
+ may desire that one or both of the A RR for the client's FQDN and
+ the PTR RR for the acquired address be updated. Therefore, two
+ separate Dynamic DNS Update transactions occur. Acquiring an address
+
+
+Stapp & Rekhter Expires September 2000 [Page 3]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ 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, in practice not all permutations make
+ sense. This document covers these possible design permutations:
+
+ 1. DHCP client updates the A RR, DHCP server updates the PTR RR
+ 2. DHCP server updates both the A and the PTR RRs
+
+ 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.
+
+ The reason these two are important, while others are unlikely, has
+ to do with authority over the respective DNS domain names. A DHCP
+ client may be given authority over mapping its own A RRs, or that
+ authority may be restricted to a server to prevent the client from
+ listing arbitrary addresses or associating its address with
+ arbitrary domain names. In all cases, the only reasonable place for
+ the authority over the PTR RRs associated with the address is in the
+ DHCP server that allocates the address.
+
+ In any case, whether a site permits all, some, or no DHCP servers
+ and clients to perform DNS updates into the zones which it controls
+ is entirely a matter of local administrative policy. This document
+ does not require any specific administrative policy, and does not
+ propose one. The range of possible policies is very broad, from
+ sites where only the DHCP servers have been given credentials that
+ the DNS servers will accept, to sites where each individual DHCP
+ client has been configured with credentials which allow the client
+ to modify its own domain name. Compliant implementations MAY support
+ some or all of these possibilities. Furthermore, this specification
+ applies only to DHCP client and server processes: it does not apply
+ to other processes which initiate dynamic DNS updates.
+
+ This document describes a new DHCP option which a client can use to
+ convey all or part of its domain name to a DHCP server.
+ Site-specific policy determines whether DHCP servers use the names
+ that clients offer or not, and what DHCP servers may do in cases
+ where clients do not supply domain names.
+
+4. Issues with DDNS in DHCP Environments
+
+ There are two DNS update situations that require special
+ consideration in DHCP environments: cases where more than one DHCP
+ client has been configured with the same FQDN, and cases where more
+ than one DHCP server has been given authority to perform DNS updates
+ in a zone. In these cases, it is possible for DNS records to be
+ modified in inconsistent ways unless the updaters have a mechanism
+ that allows them to detect anomolous situations. If DNS updaters can
+
+
+Stapp & Rekhter Expires September 2000 [Page 4]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ detect these situations, site administrators can configure the
+ updaters' behavior so that the site's policies can be enforced. We
+ use the term "Name Collisions" to refer to cases where more than one
+ DHCP client has been associated with a single FQDN. This
+ specification describes a mechanism designed to allow updaters to
+ detect these situations, and requires that DHCP implementations use
+ this mechanism by default.
+
+4.1 Name Collisions
+
+ How can the entity updating an A RR (either the DHCP client or DHCP
+ server) detect that a domain name has an A RR which is already in
+ use by a different DHCP client? Similarly, should a DHCP client or
+ server update a domain name which has an A RR that has been
+ configured by an administrator? In either of these cases, the
+ domain name in question would either have an additional A RR, or
+ would have its original A RR replaced by the new record. Either of
+ these effects may be considered undesirable by some sites. Different
+ authority and credential models have different levels of exposure to
+ name collisions.
+
+ 1. Client updates A RR, uses Secure DNS Update with credentials
+ that are associated with the client's FQDN, and exclusive to the
+ client. Name collisions in this scenario are unlikely (though
+ not impossible), since the client has received credentials
+ specific to the name it desires to use. This implies that the
+ name has already been allocated (through some implementation- or
+ organization-specific procedure) to that client.
+
+ 2. Client updates A RR, uses Secure DNS Update with credentials
+ that are valid for any name in the zone. Name collisions in this
+ scenario are possible, since the credentials necessary for the
+ client to update DNS are not necessarily name-specific. Thus,
+ for the client to be attempting to update a unique name requires
+ the existence of some administrative procedure to ensure client
+ configuration with unique names.
+
+ 3. Server updates the A RR, uses a name for the client which is
+ known to the server. Name collisions in this scenario are likely
+ unless prevented by the server's name configuration procedures.
+ See Section 9 for security issues with this form of deployment.
+
+ 4. Server updates the A RR, uses a name supplied by the client.
+ Name collisions in this scenario are highly likely, even with
+ administrative procedures designed to prevent them. (This
+ scenario is a popular one in real-world deployments in many
+ types of organizations.) See Section 9 for security issues with
+ this type of deployment.
+
+
+ Scenarios 2, 3, and 4 rely on administrative procedures to ensure
+ name uniqueness for DNS updates, and these procedures may break
+ down. Experience has shown that, in fact, these procedures will
+ break down at least occasionally. The question is what to do when
+
+
+Stapp & Rekhter Expires September 2000 [Page 5]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ these procedures break down or, for example in scenario #4, may not
+ even exist.
+
+ In all cases of name collisions, the desire is to offer two modes of
+ operation to the administrator of the combined DHCP-DNS capability:
+ first-update-wins (i.e., the first updating entity gets the name) or
+ most-recent-update-wins (i.e., the last updating entity for a name
+ gets the name).
+
+4.2 Multiple DHCP servers
+
+ If multiple DHCP servers are able to update the same DNS zones, or
+ if DHCP servers are performing A RR updates on behalf of DHCP
+ clients, and more than one DHCP server may be able to serve
+ addresses to the same DHCP clients, the DHCP servers should be able
+ to provide reasonable and consistent DNS name update behavior for
+ DHCP clients.
+
+4.3 Use of the DHCID RR
+
+ A solution to both of these problems is for the updating entities
+ (both DHCP clients and DHCP servers) to be able to detect that
+ another entity has been associated with a DNS name, and to offer
+ administrators the opportunity to configure update behavior.
+
+ Specifically, a DHCID RR, described in DHCID RR[12] is used to
+ associate client identification information with a DNS name and the
+ A RR associated with that name. When either a client or server adds
+ an A RR for a client, it also adds a DHCID RR which specifies a
+ unique client identity (based on a "client specifier" created from
+ the client's client-id or MAC address). In this model, only one A
+ RR is associated with a given DNS name at a time.
+
+ By associating this ownership information with each A RR,
+ cooperating DNS updating entities may determine whether their client
+ is the first or last updater of the name (and implement the
+ appropriately configured administrative policy), and DHCP clients
+ which currently have a host name may move from one DHCP server to
+ another without losing their DNS name.
+
+ The specific algorithms utilizing the DHCID RR to signal client
+ ownership are explained below. The algorithms only work in the case
+ where the updating entities all cooperate -- this approach is
+ advisory only and is not substitute for DNS security, nor is it
+ replaced by DNS security.
+
+4.3.1 Format of the DHCID RRDATA
+
+ The DHCID RR used to hold the DHCP client's identity is formatted as
+
+
+Stapp & Rekhter Expires September 2000 [Page 6]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ follows:
+
+ The name of the DHCID RR is the name of the A or PTR RR which refers
+ to the DHCP client.
+
+ The RDATA section of a DHCID RR in transmission contains RDLENGTH
+ bytes of binary data. From the perspective of DHCP clients and
+ servers, the DHC resource record consists of a 16-bit identifier
+ type, followed by one or more bytes representing the actual
+ identifier. There are two possible forms for a DHCID RR - one that
+ is used when the client's link-layer address is being used to
+ identify it, and one that is used when some DHCP option that the
+ DHCP client has sent is being used to identify it.
+
+
+ DISCUSSION:
+ Implementors should note that the actual identifying data is
+ never placed into the DNS directly. Instead, the client-identity
+ data is used as the input into a one-way hash algorithm, and the
+ output of that hash is then used as DNS RRDATA. This has been
+ specified in order to avoid placing data about DHCP clients that
+ some sites might consider sensitive into the DNS.
+
+ When the updater is using the client's link-layer address, the first
+ two bytes of the DHCID RRDATA MUST be zero. To generate the rest of
+ the resource record, the updater MUST compute a one-way hash using
+ the MD5[13] algorithm across a buffer containing the client's
+ network hardware type and link-layer address. Specifically, the
+ first byte of the buffer contains the network hardware type as it
+ appears in the DHCP htype field of the client's DHCPREQUEST message.
+ All of the significant bytes of the chaddr field in the client's
+ DHCPREQUEST message follow, in the same order in which the bytes
+ appear in the DHCPREQUEST message. The number of significant bytes
+ in the chaddr field is specified in the hlen field of the
+ DHCPREQUEST message.
+
+ When the updater is using a DHCP option sent by the client in its
+ DHCPREQUEST message, the first two bytes of the DHCID RR MUST be the
+ option code of that option, in network byte order. For example, if
+ the DHCP client identifier option is being used, the first byte of
+ the DHCID RR should be zero, and the second byte should be 61
+ decimal. The rest of the DHCID RR MUST contain the results of
+ computing a one-way hash across the payload of the option being
+ used, using the MD5 algorithm. The payload of a DHCP option consists
+ of the bytes of the option following the option code and length.
+
+ In order for independent DHCP implementations to be able to use the
+ DHCID RR as a prerequisite in dynamic DNS updates, each updater must
+ be able to reliably choose the same identifier that any other would
+ choose. To make this possible, we specify a prioritization which
+
+
+Stapp & Rekhter Expires September 2000 [Page 7]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ will ensure that for any given DHCP client request, any updater will
+ select the same client-identity data. All updaters MUST use this
+ order of prioritization by default, but all implementations SHOULD
+ be configurable to use a different prioritization if so desired by
+ the site administrators. Because of the possibility of future
+ changes in the DHCP protocol, implementors SHOULD check for updated
+ versions of this draft when implementing new DHCP clients and
+ servers which can perform DDNS updates, and also when releasing new
+ versions of existing clients and servers.
+
+ DHCP clients and servers should use the following forms of client
+ identification, starting with the most preferable, and finishing
+ with the least preferable. If the client does not send any of these
+ forms of identification, the DHCP/DDNS interaction is not defined by
+ this specification. The most preferable form of identification is
+ the Globally Unique Identifier Option [TBD]. Next is the DHCP
+ Client Identifier option. Last is the client's link-layer address,
+ as conveyed in its DHCPREQUEST message. Implementors should note
+ that the link-layer address cannot be used if there are no
+ significant bytes in the chaddr field of the DHCP client's request,
+ because this does not constitute a unique identifier.
+
+4.4 DNS RR TTLs
+
+ RRs associated with DHCP clients may be more volatile than
+ statically configured RRs. DHCP clients and servers which perform
+ dynamic updates should attempt to specify resource record TTLs which
+ reflect this volatility, in order to minimize the possibility that
+ there will be stale records in resolvers' caches. A reasonable basis
+ for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the
+ expected lease duration might be reasonable defaults. Because
+ configured DHCP lease times vary widely from site to site, it may
+ also be desirable to establish a fixed TTL ceiling. DHCP clients and
+ servers MAY allow administrators to configure the TTLs they will
+ supply, possibly as a fraction of the actual lease time, or as a
+ fixed value.
+
+5. Client FQDN Option
+
+ To update the IP address to FQDN mapping a DHCP server needs to know
+ the 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 DHCP option, called "Client FQDN". The FQDN Option
+ also contains Flags and RCode fields which DHCP servers can use to
+ convey information about DNS updates to clients.
+
+ Clients MAY send the FQDN option, setting appropriate Flags values,
+ in both their DISCOVER and REQUEST messages. If a client sends the
+ FQDN option in its DISCOVER message, it MUST send the option in
+
+
+Stapp & Rekhter Expires September 2000 [Page 8]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ subsequent REQUEST messages.
+
+ The code for this option is 81. Its minimum length is 4.
+
+
+ Code Len Flags RCODE1 RCODE2 Domain Name
+ +------+------+------+------+------+------+--
+ | 81 | n | | | | ...
+ +------+------+------+------+------+------+--
+
+
+5.1 The Flags Field
+
+
+ 0 1 2 3 4 5 6 7
+ +-+-+-+-+-+-+-+-+
+ | MBZ |E|O|S|
+ +-+-+-+-+-+-+-+-+
+
+
+ When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or
+ DHCPREQUEST messages, it sets the right-most bit (labelled "S") to
+ indicate that it will not perform any Dynamic DNS updates, and that
+ it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS
+ update on its behalf. If this bit is clear, the client indicates
+ that it intends to maintain its own FQDN-to-IP mapping update.
+
+ If a DHCP server intends to take responsibility for the A RR update
+ whether or not the client sending the FQDN option has set the "S"
+ bit, it sets both the "O" bit and the "S" bit, and sends the FQDN
+ option in its DHCPOFFER and/or DHCPACK messages.
+
+ The data in the Domain Name field may appear in one of two formats:
+ ASCII, or DNS-style binary encoding (without compression, of
+ course), as described in RFC1035[2]. A client which sends the FQDN
+ option MUST set the "E" bit to indicate that the data in the Domain
+ Name field is DNS binary encoded. If a server receives an FQDN
+ option from a client, and intends to include an FQDN option in its
+ reply, it MUST use the same encoding that the client used. The DNS
+ encoding is recommended. The use of ASCII-encoded domain-names is
+ fragile, and the use of ASCII encoding in this option should be
+ considered deprecated.
+
+ The remaining bits in the Flags field are reserved for future
+ assignment. DHCP clients and servers which send the FQDN option MUST
+ set the MBZ bits to 0, and they MUST ignore values in the part of
+ the field labelled "MBZ".
+
+
+
+
+Stapp & Rekhter Expires September 2000 [Page 9]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+5.2 The RCODE Fields
+
+ The RCODE1 and RCODE2 fields are used by a DHCP server to indicate
+ to a DHCP client the Response Code from any A or PTR RR Dynamic DNS
+ Updates it has performed. The server may also use these fields to
+ indicate whether it has attempted such an update before sending the
+ DHCPACK message. Each of these fields is one byte long.
+
+ Implementors should note that EDNS0 describes a mechanism for
+ extending the length of a DNS RCODE to 12 bits. EDNS0 is specified
+ in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a
+ Dynamic DNS Update will be carried in the Client FQDN DHCP Option.
+ This provides enough number space to accomodate the RCODEs defined
+ in the Dynamic DNS Update specification.
+
+5.3 The Domain Name Field
+
+ The Domain Name part of the option carries all or part of the FQDN
+ of a DHCP client. A client may be configured with a fully-qualified
+ domain name, or with a partial name that is not fully-qualified. If
+ a client knows only part of its name, it MAY send a single label,
+ indicating that it knows part of the name but does not necessarily
+ know the zone in which the name is to be embedded. The data in the
+ Domain Name field may appear in one of two formats: ASCII (with no
+ terminating NULL), or DNS encoding as specified in RFC1035[2]. If
+ the DHCP client wishes to use DNS encoding, it MUST set the
+ third-from-rightmost bit in the Flags field (the "E" bit); if it
+ uses ASCII encoding, it MUST clear the "E" bit.
+
+ A DHCP client that can only send a single label using ASCII encoding
+ includes a series of ASCII characters in the Domain Name field,
+ excluding the "." (dot) character. The client SHOULD follow the
+ character-set recommendations of RFC1034[1] and RFC1035[2]. A client
+ using DNS binary encoding which wants to suggest part of its FQDN
+ MAY send a non-terminal sequence of labels in the Domain Name part
+ of the option.
+
+6. DHCP Client behavior
+
+ The following describes the behavior of a DHCP client that
+ implements the Client FQDN option.
+
+ If a client that owns/maintains its own FQDN 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 MUST include the
+ Client FQDN option in the DHCPREQUEST message originated by the
+ client. A DHCP client MAY choose to include the Client FQDN option
+ in its DISCOVER messages as well as its REQUEST messages. The
+ rightmost ("S") bit in the Flags field in the option MUST be set to
+
+
+Stapp & Rekhter Expires September 2000 [Page 10]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ 0. Once the client's DHCP configuration is completed (the client
+ receives a DHCPACK message, and successfully completes a final check
+ on the parameters passed in the message), the client MAY originate
+ an update for the A RR (associated with the client's FQDN). The
+ update MUST be originated following the procedures described in
+ RFC2136[5] and Section 8. If the DHCP server from which the client
+ is requesting a lease includes the FQDN option in its ACK message,
+ and if the server sets both the "S" and the "O" bits (the two
+ rightmost bits) in the option's flags field, the DHCP client MUST
+ NOT initiate an update for the name in the Domain Name field.
+
+ A client can choose to delegate the responsibility for updating the
+ FQDN to IP address mapping for the FQDN and address(es) used by the
+ client to the server. In order to inform the server of this choice,
+ the client SHOULD include the Client FQDN option in its DHCPREQUEST
+ message. The rightmost (or "S") bit in the Flags field in the option
+ MUST be set to 1. A client which delegates this responsibility MUST
+ NOT attempt to perform a Dynamic DNS update for the name in the
+ Domain Name field of the FQDN option. The client MAY supply an FQDN
+ in the Client FQDN option, or it MAY supply a single label (the
+ most-specific label), or it MAY leave that field empty as a signal
+ to the server to generate an FQDN for the client in any manner the
+ server chooses.
+
+ Since there is a possibility that the DHCP server may be configured
+ to complete or replace a domain name that the client was configured
+ to send, the client might find it useful to send the FQDN option in
+ its DISCOVER messages. If the DHCP server returns different Domain
+ Name data in its OFFER message, the client could use that data in
+ performing its own eventual A RR update, or in forming the FQDN
+ option that it sends in its REQUEST message. There is no requirement
+ that the client send identical FQDN option data in its DISCOVER and
+ REQUEST messages. In particular, if a client has sent the FQDN
+ option to its server, and the configuration of the client changes so
+ that its notion of its domain name changes, it MAY send the new name
+ data in an FQDN option when it communicates with the server again.
+ This may allow the DHCP server to update the name associated with
+ the PTR record, and, if the server updated the A record representing
+ the client, to delete that record and attempt an update for the
+ client's current domain name.
+
+ A client that delegates the responsibility for updating the FQDN to
+ IP address mapping to a server might not receive any indication
+ (either positive or negative) from the server whether the server was
+ able to perform the update. In this case the client MAY use a DNS
+ query to check whether the mapping is updated.
+
+ A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN
+ option to 0 when sending the option.
+
+
+Stapp & Rekhter Expires September 2000 [Page 11]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ If a client releases its lease prior to the lease expiration time
+ and the client is responsible for updating its A RR, the client
+ SHOULD delete the A RR (following the procedures described in
+ Section 8) associated with the leased address before sending a DHCP
+ RELEASE message. Similarly, if a client was responsible for updating
+ its A RR, but is unable to renew its lease, the client SHOULD
+ attempt to delete the A RR before its lease expires. A DHCP client
+ which has not been able to delete an A RR which it added (because it
+ has lost the use of its DHCP IP address) should attempt to notify
+ its administrator.
+
+7. 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 may be configured to
+ originate an update for the PTR RR (associated with the address
+ leased to the client). Any such update MUST be originated following
+ the procedures described in Section 8. The server MAY complete the
+ update before the server sends the DHCPACK message to the client. In
+ this case the RCODE from the update MUST be carried to the client in
+ the RCODE1 field of the Client FQDN option in the DHCPACK message.
+ Alternatively, the server MAY send the DHCPACK message to the client
+ without waiting for the update to be completed. In this case the
+ RCODE1 field of the Client FQDN option in the DHCPACK message MUST
+ be set to 255. The choice between the two alternatives is entirely
+ determined by the configuration of the DHCP server. Servers SHOULD
+ support both configuration options.
+
+ When a server receives a DHCPREQUEST message containing the Client
+ FQDN option, the server MUST ignore the values carried in the RCODE1
+ and RCODE2 fields of the option.
+
+ In addition, if the Client FQDN option carried in the DHCPREQUEST
+ message has the "S" bit in its Flags field set, then the server MAY
+ originate an update for the A RR (associated with the FQDN carried
+ in the option) if it is configured to do so by the site's
+ administrator, and if it has the necessary credentials. The server
+ MAY be configured to use the name supplied in the client's FQDN
+ option, or it MAY be configured to modify the supplied name, or
+ substitute a different name.
+
+ Any such update MUST be originated following the procedures
+ described in Section 8. The server MAY originate the update before
+ the server sends the DHCPACK message to the client. In this case the
+ RCODE from the update [RFC2136] MUST be carried to the client in the
+ RCODE2 field of the Client FQDN option in the DHCPACK message.
+ Alternatively the server MAY send the DHCPACK message to the client
+ without waiting for the update to be completed. In this case the
+
+
+Stapp & Rekhter Expires September 2000 [Page 12]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ RCODE2 field of the Client FQDN option in the DHCPACK message MUST
+ be set to 255. The choice between the two alternatives is entirely
+ up to the DHCP server. In either case, if the server intends to
+ perform the DNS update and the client's REQUEST message included the
+ FQDN option, the server SHOULD include the FQDN option in its ACK
+ message, and MUST set the "S" bit in the option's Flags field.
+
+ Even if the Client FQDN option carried in the DHCPREQUEST message
+ has the "S" bit in its Flags field clear (indicating that the client
+ wants to update the A RR), the server MAY be configured by the local
+ administrator to update the A RR on the client's behalf. A server
+ which is configured to override the client's preference SHOULD
+ include an FQDN option in its ACK message, and MUST set both the "O"
+ and "S" bits in the FQDN option's Flags field. The update MUST be
+ originated following the procedures described in Section 8. The
+ server MAY originate the update before the server sends the DHCPACK
+ message to the client. In this case the RCODE from the update
+ [RFC2136] MUST be carried to the client in the RCODE2 field of the
+ Client FQDN option in the DHCPACK message. Alternatively, the server
+ MAY send the DHCPACK message to the client without waiting for the
+ update to be completed. In this case the RCODE2 field of the Client
+ FQDN option in the DHCPACK message MUST be set to 255. Whether the
+ DNS update occurs before or after the DHCPACK is sent is entirely up
+ to the DHCP server's configuration.
+
+ When a DHCP server sends the Client FQDN option to a client in the
+ DHCPACK message, the DHCP server SHOULD send its notion of the
+ complete FQDN for the client in the Domain Name field. The server
+ MAY simply copy the Domain Name field from the Client FQDN option
+ that the client sent to the server in the DHCPREQUEST message. The
+ DHCP server MAY be configured to complete or modify the domain name
+ which a client sent, or it MAY be configured to substitute a
+ different name. If the server initiates a DDNS update which is not
+ complete until after the server has replied to the DHCP client, the
+ server's The server MUST use the same encoding format (ASCII or DNS
+ binary encoding) that the client used in the FQDN option in its
+ DHCPREQUEST, and MUST set the "E" bit in the option's Flags field
+ accordingly.
+
+ If a client's DHCPREQUEST message doesn't carry the Client FQDN
+ option (e.g., the client doesn't implement the Client FQDN option),
+ the server MAY be configured to update either or both of the A and
+ PTR RRs. The updates MUST be originated following the procedures
+ described in Section 8.
+
+ If a server detects that a lease on an address that the server
+ leases to a client has expired, the server SHOULD delete any PTR RR
+ which it added via dynamic update. In addition, if the server added
+ an A RR on the client's behalf, the server SHOULD also delete the A
+
+
+Stapp & Rekhter Expires September 2000 [Page 13]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ RR. The deletion MUST follow the procedures described in Section 8.
+
+ If a server terminates a lease on an address prior to the lease's
+ expiration time, for instance by sending a DHCPNAK to a client, the
+ server SHOULD delete any PTR RR which it associated with the address
+ via DNS Dynamic Update. In addition, if the server took
+ responsibility for an A RR, the server SHOULD also delete that A RR.
+ The deletion MUST follow the procedures described in Section 8.
+
+8. Procedures for performing DNS updates
+
+8.1 Adding A RRs to DNS
+
+ When a DHCP client or server intends to update an A RR, it first
+ prepares a DNS UPDATE query which includes as a prerequisite the
+ assertion that the name does not exist. The update section of the
+ query attempts to add the new name and its IP address mapping (an A
+ RR), and the DHCID RR with its unique client-identity.
+
+ If this update operation succeeds, the updater can conclude that it
+ has added a new name whose only RRs are the A and DHCID RR records.
+ The A RR update is now complete (and a client updater is finished,
+ while a server might proceed to perform a PTR RR update).
+
+ If the first update operation fails with YXDOMAIN, the updater can
+ conclude that the intended name is in use. The updater then
+ attempts to confirm that the DNS name is not being used by some
+ other host. The updater prepares a second UPDATE query in which the
+ prerequisite is that the desired name has attached to it a DHCID RR
+ whose contents match the client identity. The update section of
+ this query deletes the existing A records on the name, and adds the
+ A record that matches the DHCP binding and the DHCID RR with the
+ client identity.
+
+ If this query succeeds, the updater can conclude that the current
+ client was the last client associated with the domain name, and that
+ the name now contains the updated A RR. The A RR update is now
+ complete (and a client updater is finished, while a server would
+ then proceed to perform a PTR RR update).
+
+ If the second query fails with NXRRSET, the updater must conclude
+ that the client's desired name is in use by another host. At this
+ juncture, the updater can decide (based on some administrative
+ configuration outside of the scope of this document) whether to let
+ the existing owner of the name keep that name, and to (possibly)
+ perform some name disambiguation operation on behalf of the current
+ client, or to replace the RRs on the name with RRs that represent
+ the current client. If the configured policy allows replacement of
+ existing records, the updater submits a query that deletes the
+
+
+Stapp & Rekhter Expires September 2000 [Page 14]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ existing A RR and the existing DHCID RR, adding A and DHCID RRs that
+ represent the IP address and client-identity of the new client.
+
+
+ DISCUSSION:
+ The updating entity may be configured to allow the existing DNS
+ records on the domain name to remain unchanged, and to perform
+ disambiguation on the name of the current client in order to
+ attempt to generate a similar but unique name for the current
+ client. In this case, once another candidate name has been
+ generated, the updater should restart the process of adding an A
+ RR as specified in this section.
+
+8.2 Adding PTR RR Entries to DNS
+
+ The DHCP server submits a DNS query which deletes all of the PTR RRs
+ associated with the lease IP address, and adds a PTR RR whose data
+ is the client's (possibly disambiguated) host name. The server also
+ adds a DHCID RR specified in Section 4.3.
+
+8.3 Removing Entries from DNS
+
+ The most important consideration in removing DNS entries is be sure
+ that an entity removing a DNS entry is only removing an entry that
+ it added, or for which an administrator has explicitly assigned it
+ responsibility.
+
+ When a lease expires or a DHCP client issues a DHCPRELEASE request,
+ the DHCP server SHOULD delete the PTR RR that matches the DHCP
+ binding, if one was successfully added. The server's update query
+ SHOULD assert that the name in the PTR record matches the name of
+ the client whose lease has expired or been released.
+
+ The entity chosen to handle the A record for this client (either the
+ client or the server) SHOULD delete the A record that was added when
+ the lease was made to the client.
+
+ In order to perform this delete, the updater prepares an UPDATE
+ query which contains two prerequisites. The first prerequisite
+ asserts that the DHCID RR exists whose data is the client identity
+ described in Section 4.3. The second prerequisite asserts that the
+ data in the A RR contains the IP address of the lease that has
+ expired or been released.
+
+ If the query fails, the updater MUST NOT delete the DNS name. It
+ may be that the host whose lease on the server has expired has moved
+ to another network and obtained a lease from a different server,
+ which has caused the client's A RR to be replaced. It may also be
+ that some other client has been configured with a name that matches
+ the name of the DHCP client, and the policy was that the last client
+
+
+Stapp & Rekhter Expires September 2000 [Page 15]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ to specify the name would get the name. In this case, the DHCID RR
+ will no longer match the updater's notion of the client-identity of
+ the host pointed to by the DNS name.
+
+8.4 Updating other RRs
+
+ The procedures described in this document only cover updates to the
+ A and PTR RRs. Updating other types of RRs is outside the scope of
+ this document.
+
+9. Security Considerations
+
+ Unauthenticated updates to the DNS can lead to tremendous confusion,
+ through malicious attack or through inadvertent misconfiguration.
+ Administrators should be wary of permitting unsecured DNS updates to
+ zones which are exposed to the global Internet. Both DHCP clients
+ and servers SHOULD use some form of update request origin
+ authentication procedure (e.g., Simple Secure DNS Update[11]) when
+ performing DNS updates.
+
+ Whether a DHCP client may be responsible for updating an FQDN to IP
+ address mapping, or whether this is the responsibility of the DHCP
+ server is a site-local matter. The choice between the two
+ alternatives may be based on the 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).
+
+ Whether a DHCP server is always responsible for updating the FQDN to
+ IP address mapping (in addition to updating the IP to FQDN mapping),
+ regardless of the wishes of an individual DHCP client, is also a
+ site-local matter. The choice between the two alternatives may be
+ based on the security model that is being used with dynamic DNS
+ updates. In cases where a DHCP server is performing DNS updates on
+ behalf of a client, the DHCP server should be sure of the DNS name
+ to use for the client, and of the identity of the client.
+
+ Currently, it is difficult for DHCP servers to develop much
+ confidence in the identities of its clients, given the absence of
+ entity authentication from the DHCP protocol itself. There are many
+ ways for a DHCP server to develop a DNS name to use for a client,
+ but only in certain relatively unusual circumstances will the DHCP
+ server know for certain the identity of the client. If DHCP
+ Authentication[10] becomes widely deployed this may become more
+ customary.
+
+ One example of a situation which offers some extra assurances is one
+ where the DHCP client is connected to a network through an MCNS
+ cable modem, and the CMTS (head-end) of the cable modem ensures that
+
+
+Stapp & Rekhter Expires September 2000 [Page 16]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ MAC address spoofing simply does not occur. Another example of a
+ configuration that might be trusted is one where clients obtain
+ network access via a network access server using PPP. The NAS itself
+ might be obtaining IP addresses via DHCP, encoding a client
+ identification into the DHCP client-id option. In this case, the
+ network access server as well as the DHCP server might be operating
+ within a trusted environment, in which case the DHCP server could be
+ configured to trust that the user authentication and authorization
+ procedure of the remote access server was sufficient, and would
+ therefore trust the client identification encoded within the DHCP
+ client-id.
+
+10. Acknowledgements
+
+ Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter
+ Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear,
+ Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield,
+ Michael Patton, and Glenn Stump for their review and comments.
+
+References
+
+ [1] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
+ 1034, Nov 1987.
+
+ [2] Mockapetris, P., "Domain names - Implementation and
+ Specification", RFC 1035, Nov 1987.
+
+ [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [4] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and
+ Answers to Commonly asked ``New Internet User'' Questions", RFC
+ 1594, March 1994.
+
+ [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+ Updates in the Domain Name System", RFC 2136, April 1997.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+ [7] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
+ August 1999.
+
+ [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)
+ (draft-ietf-dnsext-tsig-*)", July 1999.
+
+
+Stapp & Rekhter Expires September 2000 [Page 17]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+ [10] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages
+ (draft-ietf-dhc-authentication-*)", June 1999.
+
+ [11] Wellington, B., "Simple Secure DNS Dynamic Updates
+ (draft-ietf-dnsext-simple-secure-update-*)", June 1999.
+
+ [12] Gustafsson, A., "A DNS RR for encoding DHCP client identity
+ (draft-ietf-dnsext-dhcid-rr-*)", October 1999.
+
+ [13] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
+ April 1992.
+
+Authors' Addresses
+
+ Mark Stapp
+ Cisco Systems, Inc.
+ 250 Apollo Dr.
+ Chelmsford, MA 01824
+ US
+
+ Phone: 978.244.8498
+ EMail: mjs@cisco.com
+
+ Yakov Rekhter
+ Cisco Systems, Inc.
+ 170 Tasman Dr.
+ San Jose, CA 95134
+ US
+
+ Phone: 914.235.2128
+ EMail: yakov@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp & Rekhter Expires September 2000 [Page 18]
+\f
+Internet-Draft Interaction between DHCP and DNS March 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp & Rekhter Expires September 2000 [Page 19]
+\f
+++ /dev/null
-
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-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.
-
- 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. 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 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].
-
- 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]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
- extensions.
-
-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
-
-1. Introduction
-
- This document specifies options for use with both the Dynamic Host
- Configuration Protocol and the Bootstrap Protocol.
-
- The full description of DHCP packet formats may be found in the DHCP
- specification document [1], and the full description of BOOTP packet
- formats may be found in the BOOTP specification document [3]. This
- document defines the format of information in the last field of DHCP
- packets ('options') and of BOOTP packets ('vend'). The remainder of
- this section defines a generalized use of this area for giving
- information useful to a wide class of machines, operating systems and
- configurations. Sites with a single DHCP or BOOTP server that is
- shared among heterogeneous clients may choose to define other, site-
- specific formats for the use of the 'options' field.
-
- Section 2 of this memo describes the formats of DHCP options and
- BOOTP vendor extensions. Section 3 describes options defined in
- previous documents for use with BOOTP (all may also be used with
- DHCP). Sections 4-8 define new options intended for use with both
- DHCP and BOOTP. Section 9 defines options used only in DHCP.
-
- References further describing most of the options defined in sections
- 2-6 can be found in section 12. The use of the options defined in
- section 9 is described in the DHCP specification [1].
-
- Information on registering new options is contained in section 10.
-
- This document updates the definition of DHCP/BOOTP options that
-
-
-
-Alexander & Droms [Page 2]
-\f
-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
- 10. Several new options, including NIS+ domain and servers, Mobile
- IP home agent, SMTP server, TFTP server and Bootfile server, have
- been added. Text giving definitions used throughout the document has
- been added in section 1.1. Text emphasizing the need for uniqueness
- of client-identifiers has been added to section 9.14.
-
-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.
-
- 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.
-
-
-
-
-Alexander & Droms [Page 3]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-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.
-
- 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.
-
-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.
-
- 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
-
-
-
-Alexander & Droms [Page 4]
-\f
-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.
-
- 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 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.
-
-3.1. Pad Option
-
- 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.
-
- Code
- +-----+
- | 0 |
- +-----+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 5]
-\f
-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
- field. Subsequent octets should be filled with pad options.
-
- The code for the end option is 255, and its length is 1 octet.
-
- Code
- +-----+
- | 255 |
- +-----+
-
-3.3. Subnet Mask
-
- The subnet mask option specifies the client's subnet mask as per RFC
- 950 [5].
-
- If both the subnet mask and the router option are specified in a DHCP
- reply, the subnet mask option MUST be first.
-
- The code for the subnet mask option is 1, and its length is 4 octets.
-
- Code Len Subnet Mask
- +-----+-----+-----+-----+-----+-----+
- | 1 | 4 | m1 | m2 | m3 | m4 |
- +-----+-----+-----+-----+-----+-----+
-
-3.4. Time Offset
-
- The time offset field specifies the offset of the client's subnet in
- seconds from Coordinated Universal Time (UTC). The offset is
- expressed as a two's complement 32-bit integer. A positive offset
- indicates a location east of the zero meridian and a negative offset
- indicates a location west of the zero meridian.
-
- The code for the time offset option is 2, and its length is 4 octets.
-
- Code Len Time Offset
- +-----+-----+-----+-----+-----+-----+
- | 2 | 4 | n1 | n2 | n3 | n4 |
- +-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 6]
-\f
-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
- client's subnet. Routers SHOULD be listed in order of preference.
-
- The code for the router option is 3. The minimum length for the
- router option is 4 octets, and the length MUST always be a multiple
- of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.6. Time Server Option
-
- The time server option specifies a list of RFC 868 [6] time servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the time server option is 4. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.7. Name Server Option
-
- The name server option specifies a list of IEN 116 [7] name servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the name server option is 5. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 7]
-\f
-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
- (STD 13, RFC 1035 [8]) name servers available to the client. Servers
- SHOULD be listed in order of preference.
-
- The code for the domain name server option is 6. The minimum length
- for this option is 4 octets, and the length MUST always be a multiple
- of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.9. Log Server Option
-
- The log server option specifies a list of MIT-LCS UDP log servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the log server option is 7. The minimum length for this
- option is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.10. Cookie Server Option
-
- The cookie server option specifies a list of RFC 865 [9] cookie
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- The code for the log server option is 8. The minimum length for this
- option is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 8]
-\f
-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
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- The code for the LPR server option is 9. The minimum length for this
- option is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.12. Impress Server Option
-
- The Impress server option specifies a list of Imagen Impress servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the Impress server option is 10. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.13. Resource Location Server Option
-
- This option specifies a list of RFC 887 [11] Resource Location
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- 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.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 9]
-\f
-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
- not be qualified with the local domain name (see section 3.17 for the
- preferred way to retrieve the domain name). See RFC 1035 for
- character set restrictions.
-
- The code for this option is 12, and its minimum length is 1.
-
- Code Len Host Name
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.15. Boot File Size Option
-
- This option specifies the length in 512-octet blocks of the default
- boot image for the client. The file length is specified as an
- unsigned 16-bit integer.
-
- The code for this option is 13, and its length is 2.
-
- Code Len File Size
- +-----+-----+-----+-----+
- | 13 | 2 | l1 | l2 |
- +-----+-----+-----+-----+
-
-3.16. Merit Dump File
-
- This option specifies the path-name of a file to which the client's
- core image should be dumped in the event the client crashes. The
- path is formatted as a character string consisting of characters from
- the NVT ASCII character set.
-
- The code for this option is 14. Its minimum length is 1.
-
- Code Len Dump File Pathname
- +-----+-----+-----+-----+-----+-----+---
- | 14 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 10]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-3.17. Domain Name
-
- This option specifies the domain name that client should use when
- resolving hostnames via the Domain Name System.
-
- The code for this option is 15. Its minimum length is 1.
-
- Code Len Domain Name
- +-----+-----+-----+-----+-----+-----+--
- | 15 | n | d1 | d2 | d3 | d4 | ...
- +-----+-----+-----+-----+-----+-----+--
-
-3.18. Swap Server
-
- This specifies the IP address of the client's swap server.
-
- The code for this option is 16 and its length is 4.
-
- Code Len Swap Server Address
- +-----+-----+-----+-----+-----+-----+
- | 16 | n | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-3.19. Root Path
-
- This option specifies the path-name that contains the client's root
- disk. The path is formatted as a character string consisting of
- characters from the NVT ASCII character set.
-
- The code for this option is 17. Its minimum length is 1.
-
- Code Len Root Disk Pathname
- +-----+-----+-----+-----+-----+-----+---
- | 17 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 11]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-3.20. Extensions Path
-
- A string to specify a file, retrievable via TFTP, which contains
- information which can be interpreted in the same way as the 64-octet
- vendor-extension field within the BOOTP response, with the following
- exceptions:
-
- - the length of the file is unconstrained;
- - all references to Tag 18 (i.e., instances of the
- BOOTP Extensions Path field) within the file are
- ignored.
-
- The code for this option is 18. Its minimum length is 1.
-
- Code Len Extensions Pathname
- +-----+-----+-----+-----+-----+-----+---
- | 18 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-4. IP Layer Parameters per Host
-
- This section details the options that affect the operation of the IP
- layer on a per-host basis.
-
-4.1. IP Forwarding Enable/Disable Option
-
- This option specifies whether the client should configure its IP
- layer for packet forwarding. A value of 0 means disable IP
- forwarding, and a value of 1 means enable IP forwarding.
-
- The code for this option is 19, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 19 | 1 | 0/1 |
- +-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 12]
-\f
-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
- layer to allow forwarding of datagrams with non-local source routes
- (see Section 3.3.5 of [4] for a discussion of this topic). A value
- of 0 means disallow forwarding of such datagrams, and a value of 1
- means allow forwarding.
-
- The code for this option is 20, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 20 | 1 | 0/1 |
- +-----+-----+-----+
-
-4.3. Policy Filter Option
-
- This option specifies policy filters for non-local source routing.
- The filters consist of a list of IP addresses and masks which specify
- destination/mask pairs with which to filter incoming source routes.
-
- Any source routed datagram whose next-hop address does not match one
- of the filters should be discarded by the client.
-
- See [4] for further information.
-
- The code for this option is 21. The minimum length of this option is
- 8, and the length MUST be a multiple of 8.
-
- Code Len Address 1 Mask 1
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- | 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- Address 2 Mask 2
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 13]
-\f
-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
- should be prepared to reassemble. The size is specified as a 16-bit
- unsigned integer. The minimum value legal value is 576.
-
- The code for this option is 22, and its length is 2.
-
- Code Len Size
- +-----+-----+-----+-----+
- | 22 | 2 | s1 | s2 |
- +-----+-----+-----+-----+
-
-4.5. Default IP Time-to-live
-
- This option specifies the default time-to-live that the client should
- use on outgoing datagrams. The TTL is specified as an octet with a
- value between 1 and 255.
-
- The code for this option is 23, and its length is 1.
-
- Code Len TTL
- +-----+-----+-----+
- | 23 | 1 | ttl |
- +-----+-----+-----+
-
-4.6. Path MTU Aging Timeout Option
-
- This option specifies the timeout (in seconds) to use when aging Path
- MTU values discovered by the mechanism defined in RFC 1191 [12]. The
- timeout is specified as a 32-bit unsigned integer.
-
- 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]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-4.7. Path MTU Plateau Table Option
-
- This option specifies a table of MTU sizes to use when performing
- Path MTU Discovery as defined in RFC 1191. The table is formatted as
- a list of 16-bit unsigned integers, ordered from smallest to largest.
- The minimum MTU value cannot be smaller than 68.
-
- The code for this option is 25. Its minimum length is 2, and the
- length MUST be a multiple of 2.
-
- Code Len Size 1 Size 2
- +-----+-----+-----+-----+-----+-----+---
- | 25 | n | s1 | s2 | s1 | s2 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-5. IP Layer Parameters per Interface
-
- This section details the options that affect the operation of the IP
- layer on a per-interface basis. It is expected that a client can
- issue multiple requests, one per interface, in order to configure
- interfaces with their specific parameters.
-
-5.1. Interface MTU Option
-
- This option specifies the MTU to use on this interface. The MTU is
- specified as a 16-bit unsigned integer. The minimum legal value for
- the MTU is 68.
-
- The code for this option is 26, and its length is 2.
-
- Code Len MTU
- +-----+-----+-----+-----+
- | 26 | 2 | m1 | m2 |
- +-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 15]
-\f
-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
- subnets of the IP network to which the client is connected use the
- same MTU as the subnet of that network to which the client is
- directly connected. A value of 1 indicates that all subnets share
- 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.
-
- The code for this option is 27, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 27 | 1 | 0/1 |
- +-----+-----+-----+
-
-5.3. Broadcast Address Option
-
- This option specifies the broadcast address in use on the client's
- subnet. Legal values for broadcast addresses are specified in
- section 3.2.1.3 of [4].
-
- The code for this option is 28, and its length is 4.
-
- Code Len Broadcast Address
- +-----+-----+-----+-----+-----+-----+
- | 28 | 4 | b1 | b2 | b3 | b4 |
- +-----+-----+-----+-----+-----+-----+
-
-5.4. Perform Mask Discovery Option
-
- This option specifies whether or not the client should perform subnet
- mask discovery using ICMP. A value of 0 indicates that the client
- should not perform mask discovery. A value of 1 means that the
- client should perform mask discovery.
-
- The code for this option is 29, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 29 | 1 | 0/1 |
- +-----+-----+-----+
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 16]
-\f
-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
- subnet mask requests using ICMP. A value of 0 indicates that the
- client should not respond. A value of 1 means that the client should
- respond.
-
- The code for this option is 30, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 30 | 1 | 0/1 |
- +-----+-----+-----+
-
-5.6. Perform Router Discovery Option
-
- This option specifies whether or not the client should solicit
- routers using the Router Discovery mechanism defined in RFC 1256
- [13]. A value of 0 indicates that the client should not perform
- router discovery. A value of 1 means that the client should perform
- router discovery.
-
- The code for this option is 31, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 31 | 1 | 0/1 |
- +-----+-----+-----+
-
-5.7. Router Solicitation Address Option
-
- This option specifies the address to which the client should transmit
- router solicitation requests.
-
- The code for this option is 32, and its length is 4.
-
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 32 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 17]
-\f
-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
- install in its routing cache. If multiple routes to the same
- destination are specified, they are listed in descending order of
- priority.
-
- The routes consist of a list of IP address pairs. The first address
- is the destination address, and the second address is the router for
- the destination.
-
- The default route (0.0.0.0) is an illegal destination for a static
- route. See section 3.5 for information about the router option.
-
- 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 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 18]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-6. Link Layer Parameters per Interface
-
- This section lists the options that affect the operation of the data
- link layer on a per-interface basis.
-
-6.1. Trailer Encapsulation Option
-
- This option specifies whether or not the client should negotiate the
- use of trailers (RFC 893 [14]) when using the ARP protocol. A value
- of 0 indicates that the client should not attempt to use trailers. A
- value of 1 means that the client should attempt to use trailers.
-
- The code for this option is 34, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 34 | 1 | 0/1 |
- +-----+-----+-----+
-
-6.2. ARP Cache Timeout Option
-
- This option specifies the timeout in seconds for ARP cache entries.
- The time is specified as a 32-bit unsigned integer.
-
- The code for this option is 35, and its length is 4.
-
- Code Len Time
- +-----+-----+-----+-----+-----+-----+
- | 35 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-6.3. Ethernet Encapsulation Option
-
- This option specifies whether or not the client should use Ethernet
- Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) encapsulation
- if the interface is an Ethernet. A value of 0 indicates that the
- 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 [Page 19]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-7. TCP Parameters
-
- This section lists the options that affect the operation of the TCP
- layer on a per-interface basis.
-
-7.1. TCP Default TTL Option
-
- This option specifies the default TTL that the client should use when
- sending TCP segments. The value is represented as an 8-bit unsigned
- integer. The minimum value is 1.
-
- The code for this option is 37, and its length is 1.
-
- Code Len TTL
- +-----+-----+-----+
- | 37 | 1 | n |
- +-----+-----+-----+
-
-7.2. TCP Keepalive Interval Option
-
- This option specifies the interval (in seconds) that the client TCP
- should wait before sending a keepalive message on a TCP connection.
- The time is specified as a 32-bit unsigned integer. A value of zero
- indicates that the client should not generate keepalive messages on
- connections unless specifically requested by an application.
-
- The code for this option is 38, and its length is 4.
-
- Code Len Time
- +-----+-----+-----+-----+-----+-----+
- | 38 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-7.3. TCP Keepalive Garbage Option
-
- This option specifies the whether or not the client should send TCP
- keepalive messages with a octet of garbage for compatibility with
- older implementations. A value of 0 indicates that a garbage octet
- 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 [Page 20]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-8. Application and Service Parameters
-
- This section details some miscellaneous options used to configure
- miscellaneous applications and services.
-
-8.1. Network Information Service Domain Option
-
- This option specifies the name of the client's NIS [17] domain. The
- domain is formatted as a character string consisting of characters
- from the NVT ASCII character set.
-
- The code for this option is 40. Its minimum length is 1.
-
- Code Len NIS Domain Name
- +-----+-----+-----+-----+-----+-----+---
- | 40 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-8.2. Network Information Servers Option
-
- This option specifies a list of IP addresses indicating NIS servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for this option is 41. Its minimum length is 4, and the
- length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.3. Network Time Protocol Servers Option
-
- This option specifies a list of IP addresses indicating NTP [18]
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- 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]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-8.4. Vendor Specific Information
-
- This option is used by clients and servers to exchange vendor-
- specific information. The information is an opaque object of n
- octets, presumably interpreted by vendor-specific code on the clients
- and servers. The definition of this information is vendor specific.
- The vendor is indicated in the vendor class identifier option.
- Servers not equipped to interpret the vendor-specific information
- sent by a client MUST ignore it (although it may be reported).
- Clients which do not receive desired vendor-specific information
- SHOULD make an attempt to operate without it, although they may do so
- (and announce they are doing so) in a degraded mode.
-
- If a vendor potentially encodes more than one item of information in
- this option, then the vendor SHOULD encode the option using
- "Encapsulated vendor-specific options" as described below:
-
- The Encapsulated vendor-specific options field SHOULD be encoded as a
- sequence of code/length/value fields of identical syntax to the DHCP
- options field with the following exceptions:
-
- 1) There SHOULD NOT be a "magic cookie" field in the encapsulated
- vendor-specific extensions field.
-
- 2) Codes other than 0 or 255 MAY be redefined by the vendor within
- the encapsulated vendor-specific extensions field, but SHOULD
- conform to the tag-length-value syntax defined in section 2.
-
- 3) Code 255 (END), if present, signifies the end of the
- encapsulated vendor extensions, not the end of the vendor
- extensions field. If no code 255 is present, then the end of
- the enclosing vendor-specific information field is taken as the
- end of the encapsulated vendor-specific extensions field.
-
- The code for this option is 43 and its minimum length is 1.
-
- Code Len Vendor-specific information
- +-----+-----+-----+-----+---
- | 43 | n | i1 | i2 | ...
- +-----+-----+-----+-----+---
-
- When encapsulated vendor-specific extensions are used, the
- information bytes 1-n have the following format:
-
- Code Len Data item Code Len Data item Code
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-
-
-
-Alexander & Droms [Page 22]
-\f
-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
- 1001/1002 [19] [20] NBNS name servers listed in order of preference.
-
- The code for this option is 44. The minimum length of the option is
- 4 octets, and the length must always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
- | 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-8.6. NetBIOS over TCP/IP Datagram Distribution Server Option
-
- The NetBIOS datagram distribution server (NBDD) option specifies a
- list of RFC 1001/1002 NBDD servers listed in order of preference. The
- code for this option is 45. The minimum length of the option is 4
- octets, and the length must always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
- | 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-8.7. NetBIOS over TCP/IP Node Type Option
-
- The NetBIOS node type option allows NetBIOS over TCP/IP clients which
- are configurable to be configured as described in RFC 1001/1002. The
- value is specified as a single octet which identifies the client type
- as follows:
-
- Value Node Type
- ----- ---------
- 0x1 B-node
- 0x2 P-node
- 0x4 M-node
- 0x8 H-node
-
- In the above chart, the notation '0x' indicates a number in base-16
- (hexadecimal).
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 23]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
- The code for this option is 46. The length of this option is always
- 1.
-
- Code Len Node Type
- +-----+-----+-----------+
- | 46 | 1 | see above |
- +-----+-----+-----------+
-
-8.8. NetBIOS over TCP/IP Scope Option
-
- The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
- parameter for the client as specified in RFC 1001/1002. See [19],
- [20], and [8] for character-set restrictions.
-
- The code for this option is 47. The minimum length of this option is
- 1.
-
- Code Len NetBIOS Scope
- +-----+-----+-----+-----+-----+-----+----
- | 47 | n | s1 | s2 | s3 | s4 | ...
- +-----+-----+-----+-----+-----+-----+----
-
-8.9. X Window System Font Server Option
-
- This option specifies a list of X Window System [21] Font servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for this option is 48. The minimum length of this option is
- 4 octets, and the length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 24]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-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.
-
- Code Len Address 1 Address 2
-
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-8.11. Network Information Service+ Domain Option
-
- This option specifies the name of the client's NIS+ [17] domain. The
- domain is formatted as a character string consisting of characters
- from the NVT ASCII character set.
-
- The code for this option is 64. Its minimum length is 1.
-
- Code Len NIS Client Domain Name
- +-----+-----+-----+-----+-----+-----+---
- | 64 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-8.12. Network Information Service+ Servers Option
-
- This option specifies a list of IP addresses indicating NIS+ servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for this option is 65. Its minimum length is 4, and the
- length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 25]
-\f
-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
- home agents available to the client. Agents SHOULD be listed in
- order of preference.
-
- The code for this option is 68. Its minimum length is 0 (indicating
- no home agents are available) and the length MUST be a multiple of 4.
- It is expected that the usual length will be four octets, containing
- a single home agent's address.
-
- Code Len Home Agent Addresses (zero or more)
- +-----+-----+-----+-----+-----+-----+--
- | 68 | n | a1 | a2 | a3 | a4 | ...
- +-----+-----+-----+-----+-----+-----+--
-
-8.14. Simple Mail Transport Protocol (SMTP) Server Option
-
- The SMTP server option specifies a list of SMTP servers available to
- the client. Servers SHOULD be listed in order of preference.
-
- The code for the SMTP server option is 69. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.15. Post Office Protocol (POP3) Server Option
-
- The POP3 server option specifies a list of POP3 available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the POP3 server option is 70. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 26]
-\f
-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
- client. Servers SHOULD be listed in order of preference.
-
- The code for the NNTP server option is 71. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.17. Default World Wide Web (WWW) Server Option
-
- The WWW server option specifies a list of WWW available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the WWW server option is 72. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.18. Default Finger Server Option
-
- The Finger server option specifies a list of Finger available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the Finger server option is 73. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 27]
-\f
-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
- client. Servers SHOULD be listed in order of preference.
-
- The code for the IRC server option is 74. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.20. StreetTalk Server Option
-
- The StreetTalk server option specifies a list of StreetTalk servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- 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.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.21. StreetTalk Directory Assistance (STDA) Server Option
-
- The StreetTalk Directory Assistance (STDA) server option specifies a
- list of STDA servers available to the client. Servers SHOULD be
- listed in order of preference.
-
- The code for the StreetTalk Directory Assistance server option is 76.
- The minimum length for this option is 4 octets, and the length MUST
- always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 28]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-9. DHCP Extensions
-
- This section details the options that are specific to DHCP.
-
-9.1. Requested IP Address
-
- This option is used in a client request (DHCPDISCOVER) to allow the
- client to request that a particular IP address be assigned.
-
- The code for this option is 50, and its length is 4.
-
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 50 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.2. IP Address Lease Time
-
- This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
- to allow the client to request a lease time for the IP address. In a
- server reply (DHCPOFFER), a DHCP server uses this option to specify
- the lease time it is willing to offer.
-
- The time is in units of seconds, and is specified as a 32-bit
- unsigned integer.
-
- The code for this option is 51, and its length is 4.
-
- Code Len Lease Time
- +-----+-----+-----+-----+-----+-----+
- | 51 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.3. Option Overload
-
- This option is used to indicate that the DHCP 'sname' or 'file'
- fields are being overloaded by using them to carry DHCP options. A
- DHCP server inserts this option if the returned parameters will
- exceed the usual space allotted for options.
-
- If this option is present, the client interprets the specified
- additional fields after it concludes interpretation of the standard
- option fields.
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 29]
-\f
-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:
-
- Value Meaning
- ----- --------
- 1 the 'file' field is used to hold options
- 2 the 'sname' field is used to hold options
- 3 both fields are used to hold options
-
- Code Len Value
- +-----+-----+-----+
- | 52 | 1 |1/2/3|
- +-----+-----+-----+
-
-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.
-
- The code for this option is 66, and its minimum length is 1.
-
- Code Len TFTP server
- +-----+-----+-----+-----+-----+---
- | 66 | n | c1 | c2 | c3 | ...
- +-----+-----+-----+-----+-----+---
-
-9.5 Bootfile name
-
- This option is used to identify a bootfile when the 'file' field in
- the DHCP header has been used for DHCP options.
-
- The code for this option is 67, and its minimum length is 1.
-
- Code Len Bootfile name
- +-----+-----+-----+-----+-----+---
- | 67 | n | c1 | c2 | c3 | ...
- +-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 30]
-\f
-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
- for this option is 53, and its length is 1. Legal values for this
- option are:
-
- Value Message Type
- ----- ------------
- 1 DHCPDISCOVER
- 2 DHCPOFFER
- 3 DHCPREQUEST
- 4 DHCPDECLINE
- 5 DHCPACK
- 6 DHCPNAK
- 7 DHCPRELEASE
- 8 DHCPINFORM
-
- Code Len Type
- +-----+-----+-----+
- | 53 | 1 | 1-9 |
- +-----+-----+-----+
-
-9.7. Server Identifier
-
- This option is used in DHCPOFFER and DHCPREQUEST messages, and may
- optionally be included in the DHCPACK and DHCPNAK messages. DHCP
- servers include this option in the DHCPOFFER in order to allow the
- client to distinguish between lease offers. DHCP clients use the
- contents of the 'server identifier' field as the destination address
- for any DHCP messages unicast to the DHCP server. DHCP clients also
- indicate which of several lease offers is being accepted by including
- this option in a DHCPREQUEST message.
-
- The identifier is the IP address of the selected server.
-
- 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]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
-9.8. Parameter Request List
-
- This option is used by a DHCP client to request values for specified
- configuration parameters. The list of requested parameters is
- specified as n octets, where each octet is a valid DHCP option code
- as defined in this document.
-
- 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 55. Its minimum length is 1.
-
- Code Len Option Codes
- +-----+-----+-----+-----+---
- | 55 | n | c1 | c2 | ...
- +-----+-----+-----+-----+---
-
-9.9. Message
-
- This option is used by a DHCP server to provide an error message to a
- DHCP client in a DHCPNAK message in the event of a failure. A client
- may use this option in a DHCPDECLINE message to indicate the why the
- client declined the offered parameters. The message consists of n
- octets of NVT ASCII text, which the client may display on an
- available output device.
-
- The code for this option is 56 and its minimum length is 1.
-
- Code Len Text
- +-----+-----+-----+-----+---
- | 56 | n | c1 | c2 | ...
- +-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 32]
-\f
-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
- willing to accept. The length is specified as an unsigned 16-bit
- integer. A client may use the maximum DHCP message size option in
- DHCPDISCOVER or DHCPREQUEST messages, but should not use the option
- in DHCPDECLINE messages.
-
- The code for this option is 57, and its length is 2. The minimum
- legal value is 576 octets.
-
- Code Len Length
- +-----+-----+-----+-----+
- | 57 | 2 | l1 | l2 |
- +-----+-----+-----+-----+
-
-9.11. Renewal (T1) Time Value
-
- This option specifies the time interval from address assignment until
- the client transitions to the RENEWING state.
-
- The value is in units of seconds, and is specified as a 32-bit
- unsigned integer.
-
- The code for this option is 58, and its length is 4.
-
- Code Len T1 Interval
- +-----+-----+-----+-----+-----+-----+
- | 58 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.12. Rebinding (T2) Time Value
-
- This option specifies the time interval from address assignment until
- the client transitions to the REBINDING state.
-
- The value is in units of seconds, and is specified as a 32-bit
- unsigned integer.
-
- The code for this option is 59, and its length is 4.
-
- Code Len T2 Interval
- +-----+-----+-----+-----+-----+-----+
- | 59 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-
-
-
-
-
-Alexander & Droms [Page 33]
-\f
-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
- type and configuration of a DHCP client. The information is a string
- of n octets, interpreted by servers. Vendors may choose to define
- specific vendor class identifiers to convey particular configuration
- or other identification information about a client. For example, the
- 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
- respond SHOULD only use option 43 to return the vendor-specific
- information to the client.
-
- The code for this option is 60, and its minimum length is 1.
-
- Code Len Vendor class Identifier
- +-----+-----+-----+-----+---
- | 60 | n | i1 | i2 | ...
- +-----+-----+-----+-----+---
-
-9.14. Client-identifier
-
- This option is used by DHCP clients to specify their unique
- identifier. DHCP servers use this value to index their database of
- address bindings. This value is expected to be unique for all
- clients in an administrative domain.
-
- Identifiers SHOULD be treated as opaque objects by DHCP servers.
-
- The client identifier MAY consist of type-value pairs similar to the
- 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
- of a hardware type and hardware address. In this case the type field
- SHOULD be one of the ARP hardware types defined in STD2 [22]. A
- hardware type of 0 (zero) should be used when the value field
- contains an identifier other than a hardware address (e.g. a fully
- qualified domain name).
-
- For correct identification of clients, each client's client-
- identifier MUST be unique among the client-identifiers used on the
- subnet to which the client is attached. Vendors and system
- administrators are responsible for choosing client-identifiers that
- meet this requirement for uniqueness.
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 34]
-\f
-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 | ...
- +-----+-----+-----+-----+-----+---
-
-
-10. Defining new extensions
-
- 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 by
- contacting:
- Internet Assigned Numbers Authority (IANA)
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, California 90292-6695
-
- or by email as: iana@isi.edu
-
- 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.
-
- This procedure for defining new extensions will ensure 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.
-
-11. Acknowledgements
-
- The author thanks the many (and too numerous to mention!)
-
-
-
-Alexander & Droms [Page 35]
-\f
-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.
-
- 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.
-
- [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.
-
- [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.
-
- [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.
-
- [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.
-
- [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
- Wollongong Group, August 1990.
-
-
-
-
-Alexander & Droms [Page 36]
-\f
-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.
-
- [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.
-
- [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.
-
- [17] Sun Microsystems, "System and Network Administration", March
- 1990.
-
- [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.
-
- [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.
-
- [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]
-\f
-DRAFT DHCP Options and BOOTP Vendor Extensions December 1996
-
-
- Mailstop 510
- Mountain View, CA 94043-1389
-
- Phone: (415) 933-6172
- EMail: sca@engr.sgi.com
-
- Ralph Droms
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 38]
-
--- /dev/null
+
+
+
+
+
+
+Network Working Group S. Drach
+Request for Comments: 2485 Sun Microsystems
+Category: Standards Track January 1999
+
+
+
+ DHCP Option for The Open Group's User Authentication Protocol
+
+Status of this Memo
+
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ This document defines a DHCP [1] option that contains a list of
+ pointers to User Authentication Protocol servers that provide user
+ authentication services for clients that conform to The Open Group
+ Network Computing Client Technical Standard [2].
+
+Introduction
+
+ The Open Group Network Computing Client Technical Standard, a product
+ of The Open Group's Network Computing Working Group (NCWG), defines a
+ network computing client user authentication facility named the User
+ Authentication Protocol (UAP).
+
+ UAP provides two levels of authentication, basic and secure. Basic
+ authentication uses the Basic Authentication mechanism defined in the
+ HTTP 1.1 [3] specification. Secure authentication is simply basic
+ authentication encapsulated in an SSLv3 [4] session.
+
+ In both cases, a UAP client needs to obtain the IP address and port
+ of the UAP service. Additional path information may be required,
+ depending on the implementation of the service. A URL [5] is an
+ excellent mechanism for encapsulation of this information since many
+ UAP servers will be implemented as components within legacy HTTP/SSL
+ servers.
+
+
+
+
+
+
+Drach Standards Track [Page 1]
+\f
+RFC 2485 DCHP Option for the Open Group's UAP January 1999
+
+
+ Most UAP clients have no local state and are configured when booted
+ through DHCP. No existing DHCP option [6] has a data field that
+ contains a URL. Option 72 contains a list of IP addresses for WWW
+ servers, but it is not adequate since a port and/or path can not be
+ specified. Hence there is a need for an option that contains a list
+ of URLs.
+
+User Authentication Protocol Option
+
+ This option specifies a list of URLs, each pointing to a user
+ authentication service that is capable of processing authentication
+ requests encapsulated in the User Authentication Protocol (UAP). UAP
+ servers can accept either HTTP 1.1 or SSLv3 connections. If the list
+ includes a URL that does not contain a port component, the normal
+ default port is assumed (i.e., port 80 for http and port 443 for
+ https). If the list includes a URL that does not contain a path
+ component, the path /uap is assumed.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Length | URL list
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code 98
+
+ Length The length of the data field (i.e., URL list) in
+ bytes.
+
+ URL list A list of one or more URLs separated by the ASCII
+ space character (0x20).
+
+References
+
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [2] Technical Standard: Network Computing Client, The Open Group,
+ Document Number C801, October 1998.
+
+ [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2068, January 1997.
+
+ [4] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol,
+ Version 3.0", Netscape Communications Corp., November 1996.
+ Standards Information Base, The Open Group,
+ http://www.db.opengroup.org/sib.htm#SSL_3.
+
+
+
+Drach Standards Track [Page 2]
+\f
+RFC 2485 DCHP Option for the Open Group's UAP January 1999
+
+
+ [5] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [6] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+Security Considerations
+
+ DHCP currently provides no authentication or security mechanisms.
+ Potential exposures to attack are discussed in section 7 of the DHCP
+ protocol specification.
+
+ The User Authentication Protocol does not have a means to detect
+ whether or not the client is communicating with a rogue
+ authentication service that the client contacted because it received
+ a forged or otherwise compromised UAP option from a DHCP service
+ whose security was compromised. Even secure authentication does not
+ provide relief from this type of attack. This security exposure is
+ mitigated by the environmental assumptions documented in the Network
+ Computing Client Technical Standard.
+
+Author's Address
+
+ Steve Drach
+ Sun Microsystems, Inc.
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+
+ Phone: (650) 960-1300
+ EMail: drach@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drach Standards Track [Page 3]
+\f
+RFC 2485 DCHP Option for the Open Group's UAP January 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Drach Standards Track [Page 4]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group R. Droms
+Request for Comments: 2489 Bucknell University
+BCP: 29 January 1999
+Category: Best Current Practice
+
+
+ Procedure for Defining New DHCP Options
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+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."
+
+ New DHCP options may be defined after the publication of the DHCP
+ specification to accommodate requirements for conveyance of new
+ configuration parameters. This document describes the procedure for
+ defining new DHCP options.
+
+1. 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." [2]
+
+ 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 Best Current Practice [Page 1]
+\f
+RFC 2489 Defining New DCHP Options January 1999
+
+
+ As indicated in "Guidelines for Writing an IANA Considerations
+ Section in RFCs" (see references), IANA acts as a central authority
+ for assignment of numbers such as DHCP option codes. The new
+ procedure outlined in this document will provide guidance to IANA in
+ the assignment of new option codes.
+
+2. Overview and background
+
+ The procedure described in this document modifies and clarifies the
+ procedure for defining new options in RFC 2131 [2]. The primary
+ modification is to the time at which a new DHCP option is assigned an
+ option number. In the procedure described in this document, the
+ option number is not assigned until specification for the option is
+ about to be published as an RFC.
+
+ Since the publication of RFC 2132, the option number space for
+ publically defined DHCP options (1-127) has almost been exhausted.
+ Many of the defined option numbers have not been followed up with
+ Internet Drafts submitted to the DHC WG. There has been a lack of
+ specific guidance to IANA from the DHC WG as to the assignment of
+ DHCP option numbers
+
+ The procedure as specified in RFC 2132 does not clearly state that
+ new options are to be reviewed individually for technical
+ correctness, appropriateness and complete documentation. RFC 2132
+ also does not require that new options are to be submitted to the
+ IESG for review, and that the author of the option specification is
+ responsible for bringing new options to the attention of the IESG.
+ Finally, RFC 2132 does not make clear that newly defined options are
+ not to be incorporated into products, included in other
+ specifications or otherwise used until the specification for the
+ option is published as an RFC.
+
+ In the future, new DHCP option codes will be assigned by IETF
+ consensus. New DHCP options will be documented in RFCs approved by
+ the IESG, and the codes for those options will be assigned at the
+ time the relevant RFCs are published. Typically, the IESG will seek
+ input on prospective assignments from appropriate sources (e.g., a
+ relevant Working Group if one exists). Groups of related options may
+ be combined into a single specification and reviewed as a set by the
+ IESG. Prior to assignment of an option code, it is not appropriate
+ to incorporate new options into products, include the specification
+ in other documents or otherwise make use of the new options.
+
+ The DHCP option number space (1-254) is split into two parts. The
+ site-specific options (128-254) are defined as "Private Use" and
+ require no review by the DHC WG. The public options (1-127) are
+
+
+
+
+Droms Best Current Practice [Page 2]
+\f
+RFC 2489 Defining New DCHP Options January 1999
+
+
+ defined as "Specification Required" and new options must be reviewed
+ prior to assignment of an option number by IANA. The details of the
+ review process are given in the following section of this document.
+
+3. Procedure
+
+ The author of a new DHCP option will follow these steps to obtain
+ approval for the option and publication of the specification of the
+ option as an RFC:
+
+ 1. The author devises the new option.
+
+ 2. The author documents the new option, leaving the option code as
+ "To Be Determined" (TBD), as an Internet Draft.
+
+ The requirement that the new option be documented as an Internet
+ Draft is a matter of expediency. In theory, the new option could
+ be documented on the back of an envelope for submission; as a
+ practical matter, the specification will eventually become an
+ Internet Draft as part of the review process.
+
+ 3. The author submits the Internet Draft for review by the IESG.
+ Preferably, the author will submit the Internet Draft to the DHC
+ Working Group, but the author may choose to submit the Internet
+ Draft directly to the IESG.
+
+ Note that simply publishing the new option as an Internet Draft
+ does not automatically bring the option to the attention of the
+ IESG. The author of the new option must explicitly forward a
+ request for action on the new option to the DHC WG or the IESG.
+
+ 4. The specification of the new option is reviewed by the IESG. The
+ specification is reviewed by the DHC WG (if it exists) or by the
+ IETF. If the option is accepted for inclusion in the DHCP
+ specification, the specification of the option is published as an
+ RFC. It may be published as either a standards-track or a non-
+ standards-track RFC.
+
+ 5. At the time of publication as an RFC, IANA assigns a DHCP option
+ number to the new option.
+
+4. References
+
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+
+
+Droms Best Current Practice [Page 3]
+\f
+RFC 2489 Defining New DCHP Options January 1999
+
+
+ [3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
+ RFC 2142, November 1997.
+
+ [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+5. Security Considerations
+
+ Information that creates or updates an option number assignment needs
+ to be authenticated.
+
+ An analysis of security issues is required for all newly defined DHCP
+ options. The description of security issues in the specification of
+ new options must be as accurate as possible. The specification for a
+ new option may reference the "Security Considerations" section in the
+ DHCP specification [1]; e.g. (from "NetWare/IP Domain Name and
+ Information" [3]):
+
+ DHCP currently provides no authentication or security mechanisms.
+ Potential exposures to attack are discussed in section 7 of the
+ DHCP protocol specification [RFC 2131].
+
+6. IANA Considerations
+
+ RFC 2132 provided guidance to the IANA on the procedure it should
+ follow when assigning option numbers for new DHCP options. This
+ document updates and replaces those instructions. In particular,
+ IANA is requested to assign DHCP option numbers only for options that
+ have been approved for publication as RFCs; i.e., documents that have
+ been approved through "IETF consensus" as defined in RFC 2434 [4].
+
+7. 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 Best Current Practice [Page 4]
+\f
+RFC 2489 Defining New DCHP Options January 1999
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Best Current Practice [Page 5]
+\f
projects / thirdparty / dhcp.git / commitdiff
