From: Ted Lemon Date: Sat, 6 Dec 1997 12:22:22 +0000 (+0000) Subject: Not implemented in 2.0 X-Git-Tag: V2-BETA-2~10 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=175064c3b755640ed2b971978459f8bbe25b7dfa;p=thirdparty%2Fdhcp.git Not implemented in 2.0 --- diff --git a/doc/draft-ietf-dhc-authentication-03.txt b/doc/draft-ietf-dhc-authentication-03.txt deleted file mode 100644 index 5be035841..000000000 --- a/doc/draft-ietf-dhc-authentication-03.txt +++ /dev/null @@ -1,446 +0,0 @@ - -Network Working Group R. Droms, Editor -INTERNET DRAFT Bucknell University -Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996 - Expires May 1997 - - - Authentication for DHCP Messages - - -Status of this memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) [1] provides a - framework for passing configuration information to hosts on a TCP/IP - network. In some situations, network administrators may wish to - constrain the allocation of addresses to authorized hosts. - Additionally, some network administrators may wish to provide for - authentication of the source and contents of DHCP messages. This - document defines a new DHCP option through which authorization - tickets can be easily generated and newly attached hosts with proper - authorization can be automatically configured from an authenticated - DHCP server. - -1. Introduction - - DHCP transports protocol stack configuration parameters from - centrally administered servers to TCP/IP hosts. Among those - parameters are an IP address. DHCP servers can be configured to - dynamically allocate addresses from a pool of addresses, eliminating - a manual step in configuration of TCP/IP hosts. - - - - -Droms [Page 1] - -DRAFT Authentication for DHCP Messages November 1996 - - - Some network administrators may wish to provide authentication of the - source and contents of DHCP messages. For example, clients may be - subject to denial of service attacks through the use of bogus DHCP - servers, or may simply be misconfigured due to unintentionally - instantiated DHCP servers. Network administrators may wish to - constrain the allocation of addresses to authorized hosts to avoid - denial of service attacks in "hostile" environments where the network - medium is not physically secured, such as wireless networks or - college residence halls. - - This document defines a technique that can provide both entity - authentication and message authentication. - -1.1 Requirements - - Throughout this document, the words that are used to define the - significance of particular requirements are capitalized. These words - are: - - o "MUST" - - This word or the adjective "REQUIRED" means that the - item is an absolute requirement of this specification. - - o "MUST NOT" - - This phrase means that the item is an absolute prohibition - of this specification. - - o "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to ignore - this item, but the full implications should be understood and - the case carefully weighed before choosing a different course. - - o "SHOULD NOT" - - This phrase means that there may exist valid reasons in - particular circumstances when the listed behavior is acceptable - or even useful, but the full implications should be understood - and the case carefully weighed before implementing any behavior - described with this label. - - - - - - - - -Droms [Page 2] - -DRAFT Authentication for DHCP Messages November 1996 - - - o "MAY" - - This word or the adjective "OPTIONAL" means that this item is - truly optional. One vendor may choose to include the item - because a particular marketplace requires it or because it - enhances the product, for example; another vendor may omit the - same item. - -1.2 Terminology - - This document uses the following terms: - - o "DHCP client" - - A DHCP client or "client" is an Internet host using DHCP to obtain - configuration parameters such as a network address. - - o "DHCP server" - - A DHCP server of "server"is an Internet host that returns - configuration parameters to DHCP clients. - -2. Format of the authentication option - - The following diagram defines the format of the DHCP - authentication option: - - - +----------+----------+----------+ - | Code | Length | Protocol | - +----------+----------+----------+-----------+--- - | Authentication information ... - +----------+----------+----------+-----------+--- - - - The code for the authentication option is TBD, and the length field - contains the length of the protocol and authentication information - fields in octets. The protocol field defines the particular - technique for authentication used in the option. - - This document defines two protocols in sections 3 and 4, encoded with - protocol field values 0 and 1. Protocol field values 2-254 are - reserved for future use. Other protocols may be defined according to - the procedure described in section 5. - -3. Protocol 0 - - If the protocol field is 0, the authentication information field - - - -Droms [Page 3] - -DRAFT Authentication for DHCP Messages November 1996 - - - holds a simple authentication token: - - - +----------+----------+----------+ - | Code | n+1 | 0 | - +----------+----------+----------+-----------+------ - | Authentication token (n octets) ... - +----------+----------+----------+-----------+------ - - - The authentication token is an opaque, unencoded value known to both - the sender and receiver. The sender inserts the authentication token - in the DHCP message and the receiver matches the token from the - message to the shared token. If the authentication option is present - and the token from the message does not match the shared token, the - receiver MUST discard the message. - - Protocol 0 may be used to pass a plain-text password and provides - only weak entity authentication and no message authentication. This - protocol is useful for rudimentary protection against, e.g., - inadvertently instantiated DHCP servers. - - DISCUSSION: - - The intent here is to pass a constant, non-computed token such as - a plain-text password. Other types of entity authentication using - computed tokens such as Kerberos tickets or one-time passwords - will be defined as separate protocols. - - -4. Protocol 1 - - If the protocol field is 1, the authentication information contains - an encrypted value generated by the source as a message - authentication code (MAC) to provide message authentication and - entity authentication. - - This technique is based on the HMAC protocol [3] using the MD5 hash - {2]. - - - - - - - - - - - - -Droms [Page 4] - -DRAFT Authentication for DHCP Messages November 1996 - - -4.1 Format - - The format of the authentication information for protocol 1 is: - - - +----------+----------+----------+ - | Code | n | 1 | - +----------+----------+----------+----------+- - | Counter (8 octets) ... - +----------+----------+----------+----------+- - | MAC ... - +----------+----------+----------+----------+- - - The following definitions will be used in the description of the - authentication information for protocol 1: - - K - a secret value shared between the source and destination - of the message - Counter - the value of a 64-bit monotonically increasing counter - HMAC-MD5 - the MAC generating function as defined by [3] and [2] - - The sender computes the MAC as described in [3]. The 'counter' field - of the authentication option MUST be set to the value of a - monotonically increasing counter and the 'MAC' field of the - authentication option MUST be set to all 0s for the computation of - the MAC. Because a DHCP relay agent may alter the values of the - 'giaddr' and 'hops' fields in the DHCP message, the contents of those - two fields MUST also be set to zero for the computation of the - message digest. Using a counter value such as the current time of - day (e.g., an NTP-format timestamp [4]) can reduce the danger of - replay attacks. - - DISCUSSION: - - Protocol 1 specifies the use of HMAC-MD5. Use of a different - technique, such as HMAC-SHA, will be specified as a separate - protocol. - -4.2 Message validation - - To validate an incoming message, the receiver checks the 'counter' - field and computes the MAC as described in [3]. If the 'counter' - field does not contain a value larger than the last value of - 'counter' used by the sender, the receiver MUST discard the incoming - message. The receiver MUST set the 'MAC' field of the authentication - option to all 0s for computation of the MAC. Because a DHCP relay - agent may alter the values of the 'giaddr' and 'hops' fields in the - DHCP message, the contents of those two fields MUST also be set to - - - -Droms [Page 5] - -DRAFT Authentication for DHCP Messages November 1996 - - - zero for the computation of the MAC. If the MAC computed by the - receiver does not match the MAC contained in the authentication - option, the receiver MUST discard the DHCP message. - -4.3 Key utilization - - Each DHCP client has a key, K. The client uses its key to encode any - messages it sends to the server and to authenticate and verify any - messages it receives from the server. The client's key must be - initially distributed to the client through some out-of-band - mechanism, and must be stored locally on the client for use in all - authenticated DHCP messages. Once the client has been given its key, - it may use that key for all transactions even if the client's - configuration changes; e.g., if the client is assigned a new network - address. - - Each DHCP server must know the keys for all authorized clients. If - all clients use the same key, clients can perform both entity and - message authentication for all messages received from servers. - Servers will be able to perform message authentication. To - authenticate the identity of individual clients, each client must be - configured with a unique key. Appendix A describes a technique for - key management. - -5. Definition of new authentication protocols - - The author of a new DHCP option will follow these steps to obtain - acceptance of the option as a part of the DHCP Internet Standard: - - 1. The author devises the new authentication protocol. - 2. The author documents the new protocol as an Internet Draft. - 3. The author submits the Internet Draft for review through the IETF - standards process as defined in "Internet Official Protocol - Standards" (STD 1). The new protocol will be submitted for - eventual acceptance as an Internet Standard. - 4. The new protocol progresses through the IETF standards process; - the new option will be reviewed by the Dynamic Host Configuration - Working Group (if that group still exists), or as an Internet - Draft not submitted by an IETF working group. - - This procedure for defining new authentication protocols will ensure - that: - - * new options are reviewed for technical correctness and - appropriateness, and - * documentation for new options is complete and published. - - - - - -Droms [Page 6] - -DRAFT Authentication for DHCP Messages November 1996 - - -6. References - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, - Bucknell University, October 1993. - - [2] Rivest, R., "The MD5 Message-Digest Algorithm", - RFC-1321, April 1992. - - [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for - Message Authentication" (work in - progress), August 1996. - - [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March - 1992. - -7. Acknowledgments - - Jeff Schiller and Christian Huitema developed this scheme during a - terminal room BOF at the Dallas IETF meeting, December 1995. The - author transcribed the notes from that discussion, which form the - basis for this document. The editor appreciates Jeff's and - Christian's patience in reviewing this document and its earlier - drafts. - - Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for - reviewing this document, and to Thomas Narten for reviewing earlier - drafts of this document. - -8. Security considerations - - This document describes authentication and verification mechanisms - for DHCP. - -9. Author's address - - Ralph Droms - Computer Science Department - 323 Dana Engineering - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - - - - - - - -Droms [Page 7] - -DRAFT Authentication for DHCP Messages November 1996 - - - Appendix A - Key Management Technique - - To avoid centralized management of a list of random keys, suppose K for - each client is generated from the pair (client identifier, subnet - address), which must be unique to that client. That is, K = MD5(MK, - unique-id), where MK is a secret master key and MD5 is some encoding - function. - - Without knowledge of the master key MK, an unauthorized client cannot - generate its own key K. The server can quickly validate an incoming - message from a new client by regenerating K from the client-id. For known - clients, the server can choose to recover the client's K dynamically from - the client-id in the DHCP message, or can choose to precompute and cache - all of the Ks a priori. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms [Page 8] - diff --git a/doc/draft-ietf-dhc-dhcp-dns-02.txt b/doc/draft-ietf-dhc-dhcp-dns-02.txt deleted file mode 100644 index b85ed12e2..000000000 --- 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-options-opt127-02.txt b/doc/draft-ietf-dhc-options-opt127-02.txt deleted file mode 100644 index d42a33ea5..000000000 --- a/doc/draft-ietf-dhc-options-opt127-02.txt +++ /dev/null @@ -1,167 +0,0 @@ - - -Network Working Group R. Droms -INTERNET DRAFT Bucknell University -Obsoletes: draft-ietf-dhc-options-opt127-01.txt April 1996 - Expires October 1996 - - - An Extension to the DHCP Option Codes - - -Status of this memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - To learn the current status of any Internet-Draft, please check the - ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - -Abstract - - The Dynamic Host Configuration Protocol (DHCP) provides a framework - for passing configuration information to hosts on a TCP/IP network. - This document defines a new option to extend the available option - codes. - -Introduction - - The Dynamic Host Configuration Protocol (DHCP) [1] provides a - framework for passing configuration information to hosts on a TCP/IP - network. Configuration parameters and other control information are - carried in tagged data items that are stored in the 'options' field - of the DHCP message. The data items themselves are also called - "options." - - Each option is assigned a one-octet option code. Options 128-254 are - reserved for local use and at this time over half of the available - options in the range 0-127 and option 255 have been assigned. This - document defines a new option to extend the available option codes - and new option to request the parameters represented by those new - - - -Droms [Page 1] - -DRAFT An extension to the DHCP Option Codes April 1996 - - - option codes. - -Definition of option 127 - - Option code 127 indicates that the DHCP option has a two-octet - extended option code. The format of these options is: - - Extended - Code Len option code Data... - +-----+-----+-----+-----+-----+-----+---- - | 127 | XXX | oh | ol | d1 | d2 | ... - +-----+-----+-----+-----+-----+-----+---- - - Other than the two-octet extended option code, these options are - encoded and carried in DHCP messages identically to the options - defined in RFC 1533 [2]. The high-order and low-order octets of the - extended option code are stored in 'oh' and 'ol', respectively. The - number of octets given in the 'len' field includes the two-octet - extended option code. - - The two-octet extended option codes will be assigned through the - mechanisms defined for the assignment of new options [3] after the - current one-octet option codes have been exhausted. - -Definition of option 126 - - This option is used by a DHCP client to request values for specified - configuration paramaters that are identified by extended option codes - as defined above. The list of n requested parameters is specified as - 2n octets, where each pair of octets is a valid extended option code. - - The client MAY list the options in order of preference. The DHCP - server is not required to return the options in the requested order, - but MUST try to insert the requested options in the order requested - by the client. - - The code for this option is 126. Its minimum length is 2. - - Extended - Code Len option codes - +-----+-----+-----+-----+-----+-----+---- - | 126 | XXX | c1h | c1l | c2h | c2l | ... - +-----+-----+-----+-----+-----+-----+---- - - - - - - - - -Droms [Page 2] - -DRAFT An extension to the DHCP Option Codes April 1996 - - -References - - [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531, - Bucknell University, October 1993. - - [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 1533, Lachman Associates, October 1993. - - [3] Droms, R., "Procedure for Defining New DHCP Options", Work in - progress, February, 1996. - -Security Considerations - - Security issues are not discussed in this document. - -Author's Address - - Ralph Droms - Computer Science Department - 323 Dana Engineering - Bucknell University - Lewisburg, PA 17837 - - Phone: (717) 524-1145 - EMail: droms@bucknell.edu - - - - - - - - - - - - - - - - - - - - - - - - - - -Droms [Page 3] -