diff options
| author | Ted Lemon <source@isc.org> | 2000-09-02 01:07:41 +0000 |
|---|---|---|
| committer | Ted Lemon <source@isc.org> | 2000-09-02 01:07:41 +0000 |
| commit | 74e55a1ed4d2eac317773b2b7a789b669395b943 (patch) | |
| tree | b748890ee3b5328abd3c8df3393f93da854aab6f /doc | |
| parent | 8189c3946c6c65f7cf376be331703aa4aa6747ad (diff) | |
| download | isc-dhcp-74e55a1ed4d2eac317773b2b7a789b669395b943.tar.gz | |
Obsolete some old drafts.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/draft-ietf-dhc-authentication-14.txt | 893 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-dhcp-09.txt | 2519 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-dhcp-dns-02.txt | 356 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-dhcp-dns-12.txt | 1072 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-new-options-00.txt | 110 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-options-1533update-06.txt | 2127 | ||||
| -rw-r--r-- | doc/rfc2485.txt | 227 | ||||
| -rw-r--r-- | doc/rfc2489.txt | 283 |
8 files changed, 2475 insertions, 5112 deletions
diff --git a/doc/draft-ietf-dhc-authentication-14.txt b/doc/draft-ietf-dhc-authentication-14.txt new file mode 100644 index 00000000..43a1f8ae --- /dev/null +++ b/doc/draft-ietf-dhc-authentication-14.txt @@ -0,0 +1,893 @@ +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + diff --git a/doc/draft-ietf-dhc-dhcp-09.txt b/doc/draft-ietf-dhc-dhcp-09.txt deleted file mode 100644 index 399e2de3..00000000 --- a/doc/draft-ietf-dhc-dhcp-09.txt +++ /dev/null @@ -1,2519 +0,0 @@ - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/draft-ietf-dhc-dhcp-dns-02.txt b/doc/draft-ietf-dhc-dhcp-dns-02.txt deleted file mode 100644 index b85ed12e..00000000 --- a/doc/draft-ietf-dhc-dhcp-dns-02.txt +++ /dev/null @@ -1,356 +0,0 @@ - - -Network Working Group Yakov Rekhter -Internet Draft Cisco Systems -Expiration Date: April 1997 October 1996 - - - Interaction between DHCP and DNS - draft-ietf-dhc-dhcp-dns-02.txt - - -1. Status of this Memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - - -2. Abstract - - DHCP provides a powerful mechanism for IP host autoconfiguration. - However, the autoconfiguration provided by DHCP does not include - updating DNS, and specifically updating the name to address and - address to name mappings maintained by DNS. - - This document specifies how DHCP clients and servers should use the - Dynamic DNS Updates mechanism to update the DNS name to address and - address to name mapping, so that the mappings for DHCP clients would - be consistent with the IP addresses that the clients acquire via - DHCP. - - - - - - - - - - - -Yakov Rekhter [Page 1] - - - - - -Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996 - - -3. Interaction between DHCP and DNS - - DNS [RFC1034, RFC1035] maintains (among other things) the information - about mapping between hosts' Fully Qualified Domain Names (FQDNs) - [RFC1594] and IP addresses assigned to the hosts. The information is - maintained in two types of Resource Records (RRs): A and PTR. The A - RR contains mapping from a FQDN to an IP address; the PTR RR contains - mapping from an IP address to a FQDN. - - DHCP [RFC1541] provides a mechanism by which a host (a DHCP client) - could acquire certain configuration information, and specifically its - IP address(es). However, DHCP does not provide any mechanisms to - update the DNS RRs that contain the information about mapping between - the host's FQDN and its IP address(es) (A and PTR RRs). Thus the - information maintained by DNS for a DHCP client may be incorrect - a - host (the client) could acquire its address by using DHCP, but the A - RR for the host's FQDN wouldn't reflect the address that the host - acquired, and the PTR RR for the acquired address wouldn't reflect - the host's FQDN. - - Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS - information to be updated DNS over a network. - - The Dynamic DNS Update protocol can be used to maintain consistency - between the information stored in the A and PTR RRs and the actual - address assignment done via DHCP. When a host with a particular FQDN - acquires its IP address via DHCP, the A RR associated with the host's - FQDN would be updated (by using the Dynamic DNS Updates protocol) to - reflect the new address. Likewise, when an IP address gets assigned - to a host with a particular FQDN, the PTR RR associated with this - address would be updated (using the Dynamic DNS Updates protocol) to - reflect the new FQDN. - - -4. Models of operations - - When a DHCP client acquires a new address, both the A RR (for the - client's FQDN) and the PTR RR (for the acquired address) have to be - updated. Therefore, we have two separate Dynamic DNS Update - transactions. Acquiring an address via DHCP involves two entities: a - DHCP client and a DHCP server. In principle each of these entities - could perform none, one, or both of the transactions. However, upon - some introspection one could realize that not all permutations make - sense. This document covers the possible design permutations: - - (1) DHCP client updates the A RR, DHCP server updates the PTR - RR - - - - -Yakov Rekhter [Page 2] - - - - - -Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996 - - - (2) DHCP server updates both the A and the PTR RRs - - One could observe that the only difference between these two cases is - whether the FQDN to IP address mapping is updated by a DHCP client or - by a DHCP server. The IP address to FQDN mapping is updated by a DHCP - server in both cases. - - -4.1. Client FQDN Option - - To update the IP address to FQDN mapping a DHCP server needs to know - FQDN of the client to which the server leases the address. To allow - the client to convey its FQDN to the server this document defines a - new option, called "Client FQDN". - - The code for this option is 81. Its minimum length is 4. - - - - Code Len Flags RCODE1 RCODE2 Domain Name - +------+------+------+------+------+------+-- - | TBD | n | 0/1 | | | ... - +------+------+------+------+------+------+-- - - - - The Flags field allows a DHCP client to indicate to a DHCP server - whether the client wants the server to be responsible for updating - the FQDN to IP address mapping (if Flags is set to 1), or whether the - client wants to take this responsibility (if Flags is set to 0). - - The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to - a DHCP client the Response Code from Dynamic DNS Updates. - - The Domain Name part of the option carries FQDN of a client. - - - -4.2. DHCP Client behavior - - If a client wants to be responsible for updating the FQDN to IP - address mapping for the FQDN and address(es) used by the client, then - the client shall include the Client FQDN option in the DHCPREQUEST - message originated by the client. The Flags field in the option shall - be set to 0. Once the client's DHCP configuration is completed (the - client receives a DHCPACK message, and successfully completed a final - check on the parameters passed in the message), the client shall - originate an update for the A RR (associated with the client's FQDN). - - - -Yakov Rekhter [Page 3] - - - - - -Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996 - - - The update shall be originated following the procedures described in - [DynDNS]. - - - If a client does not want to be responsible for updating the FQDN to - IP address mapping for the FQDN and address(es) used by the client, - then the client shall include the Client FQDN option in the - DHCPREQUEST message originated by the client. The Flags field in the - option shall be set to 1. - - - A client should set the RCODE1 and RCODE2 fields in the Client FQDN - option to 0 when sending the option. - - Whether the client wants to be responsible for updating the FQDN to - IP address mapping, or whether the client wants to delegate this - responsibility to a server is a local to the client matter. The - choice between the two alternatives may be based on a particular - security model that is used with the Dynamic DNS Update protocol - (e.g., only a client may have sufficient credentials to perform - updates to the FQDN to IP address mapping for its FQDN). - - If a client releases its address lease prior to the lease expiration - time, and the client is responsible for updating its A RR(s), the - client should delete the A RR (following the procedures described in - [DynDNS]) associated with the leased address before sending DHCP - RELEASE message. - - -4.3. DHCP Server behavior - - When a server receives a DHCPREQUEST message from a client, if the - message contains the Client FQDN option, and the server replies to - the message with a DHCPACK message, the server shall originate an - update for the PTR RR (associated with the address leased to the - client). The server shall originate the update before the server - sends the DHCPACK message to the client. The update shall be - originated following the procedures described in [DynDNS]. The RCODE - from the update [DynDNS] should be carried to the client in the - RCODE1 field of the Client FQDN option in the DHCPACK message. The - RCODE2 field should be set to 0. - - In addition, if the Client FQDN option carried in the DHCPREQUEST - message has its Flags field set to 1, then the server shall originate - an update for the A RR (associated with the FQDN carried in the - option). The server shall originate the update before the server - sends the DHCPACK message to the client. The update shall be - originated following the procedures described in [DynDNS]. The RCODE - - - -Yakov Rekhter [Page 4] - - - - - -Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996 - - - from the update [DynDNS] should be carried to the client in the - RCODE2 field of the Client FQDN option in the DHCPACK message. - - When a server receives a DHCPREQUEST message from a client, and the - message contains the Client FQDN option, the server shall ignore the - value carried in the RCODE1 and RCODE2 fields of the option. - - When a DHCP server sends the Client FQDN option to a client in the - DHCPACK message, the server should copy the Flags and the Domain Name - fields from the Client FQDN option that the client sent to the server - in the DHCPREQUEST message. - - - If a server originates updates for both the A and PTR RRs, then the - order in which the updates are generated is not significant. - - - If a server detects that a lease on an address that the server leases - to a client expires, the server should delete the PTR RR associated - with the address. In addition, if the client authorized the server to - update its A RR, the server should also delete the A RR. The deletion - should follow the procedures described in [DynDNS]. - - If a server terminates a lease on an address prior to the lease - expiration time, the server should delete the PTR RR associated with - the address. In addition, if the client (that leased the address) - authorized the server to update its A RR, the server should also - delete the A RR. The deletion should follow the procedures described - in [DynDNS]. - - -5. Updating other RRs - - The procedures described in this document cover updates only to the A - and PTR RRs. Updating other types of RRs is outside the scope of this - document. - - - - - - - - - - - - - - - -Yakov Rekhter [Page 5] - - - - - -Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996 - - -6. Security Considerations - - Security issues are not discussed in this document. - - -7. References - - [RFC1034] P. Mockapetris, "Domain names - concepts and facilities", - RFC1034, 11/01/1987 - - [RFC1035] P. Mockapetris, "Domain names - implementation and - specification", RFC1035, 11/01/1987 - - [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541, - 10/27/1993 - - [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and - Answer Answers to Commonly asked ``New Internet User'' Questions", - RFC1594, 03/11/1994 - - [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates - in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS- - 09.txt - - - -8. Acknowledgements - - Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms - (Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron), - and Michael Patton (BBN) for their review and comments. - - -9. Author Information - - - Yakov Rekhter - cisco Systems, Inc. - 170 Tasman Dr. - San Jose, CA 95134 - Phone: (914) 528-0090 - email: yakov@cisco.com - - - - - - - - - -Yakov Rekhter [Page 6] - - diff --git a/doc/draft-ietf-dhc-dhcp-dns-12.txt b/doc/draft-ietf-dhc-dhcp-dns-12.txt new file mode 100644 index 00000000..c97ba625 --- /dev/null +++ b/doc/draft-ietf-dhc-dhcp-dns-12.txt @@ -0,0 +1,1072 @@ + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + diff --git a/doc/draft-ietf-dhc-new-options-00.txt b/doc/draft-ietf-dhc-new-options-00.txt deleted file mode 100644 index adf332a5..00000000 --- a/doc/draft-ietf-dhc-new-options-00.txt +++ /dev/null @@ -1,110 +0,0 @@ - -Network Working Group R. Droms -INTERNET DRAFT Bucknell University -Obsoletes: February 1996 - Expires August 1996 - - - Procedure for Defining New DHCP Options - <draft-ietf-dhc-new-options-00.txt> - -Status of this memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) provides a - framework for passing configuration information to hosts on a TCP/IP - network. Configuration parameters and other control information are - carried in tagged data items that are stored in the 'options' field - of the DHCP message. The data items themselves are also called - "options." - - This document describes the procedure for defining new DHCP options. - The procedure will guarantee that: - - * allocation of new option numbers is coordinated from a single - authority, - * new options are reviewed for technical correctness and - appropriateness, and - * documentation for new options is complete and published. - - - - - - - -Droms [Page 1] - -DRAFT Procedure for Defining New DHCP Options February 1996 - - -Procedure - - The author of a new DHCP option will follow these steps to obtain - acceptance of the option as a part of the DHCP Internet Standard: - - 1. The author devises the new option. - 2. The author requests a number for the new option from IANA. - 3. The author documents the new option, using the newly obtained - option number, as an Internet Draft. - 4. The author submits the Internet Draft for review through the IETF - standards process as defined in "Internet Official Protocol - Standards" (STD 1). The new option will be submitted for eventual - acceptance as an Internet Standard. - 5. The new option progresses through the IETF standards process; the - new option will be reviewed by the Dynamic Host Configuration - Working Group (if that group still exists), or as an Internet - Draft not submitted by an IETF working group. - 6. If the new option fails to gain acceptance as an Internet - Standard, the assigned option number will be returned to IANA for - reassignment. - -Acceptance and publication - - If this procedure is accepted, it will be added to the DHCP options - specification as an Appendix. - -Security Considerations - - Security issues are not discussed in this memo. - -Author's Address - - Ralph Droms - Computer Science Department - 323 Dana Engineering - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - - - - - - - - - - -Droms [Page 2] - diff --git a/doc/draft-ietf-dhc-options-1533update-06.txt b/doc/draft-ietf-dhc-options-1533update-06.txt deleted file mode 100644 index f62107ae..00000000 --- a/doc/draft-ietf-dhc-options-1533update-06.txt +++ /dev/null @@ -1,2127 +0,0 @@ - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/rfc2485.txt b/doc/rfc2485.txt new file mode 100644 index 00000000..752b03c5 --- /dev/null +++ b/doc/rfc2485.txt @@ -0,0 +1,227 @@ + + + + + + +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] + +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] + +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] + +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] + diff --git a/doc/rfc2489.txt b/doc/rfc2489.txt new file mode 100644 index 00000000..42e066ec --- /dev/null +++ b/doc/rfc2489.txt @@ -0,0 +1,283 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + |