+++ /dev/null
-
-Network Working Group R. Droms, Editor
-INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-authentication-02.txt November 1996
- Expires May 1997
-
-
- Authentication for DHCP Messages
- <draft-ietf-dhc-authentication-03.txt>
-
-Status of this memo
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-Abstract
-
- The Dynamic Host Configuration Protocol (DHCP) [1] provides a
- framework for passing configuration information to hosts on a TCP/IP
- network. In some situations, network administrators may wish to
- constrain the allocation of addresses to authorized hosts.
- Additionally, some network administrators may wish to provide for
- authentication of the source and contents of DHCP messages. This
- document defines a new DHCP option through which authorization
- tickets can be easily generated and newly attached hosts with proper
- authorization can be automatically configured from an authenticated
- DHCP server.
-
-1. Introduction
-
- DHCP transports protocol stack configuration parameters from
- centrally administered servers to TCP/IP hosts. Among those
- parameters are an IP address. DHCP servers can be configured to
- dynamically allocate addresses from a pool of addresses, eliminating
- a manual step in configuration of TCP/IP hosts.
-
-
-
-
-Droms [Page 1]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-DRAFT Authentication for DHCP Messages November 1996
-
-
-6. References
-
- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
- Bucknell University, October 1993.
-
- [2] Rivest, R., "The MD5 Message-Digest Algorithm",
- RFC-1321, April 1992.
-
- [3] Krawczyk H., M. Bellare and R. Canetti, "HMAC: Keyed-Hashing for
- Message Authentication" <draft-ietf-ipsec-hmac-md5-01.txt> (work in
- progress), August 1996.
-
- [4] Mills, D., "Network Time Protocol (Version 3)", RFC-1305, March
- 1992.
-
-7. Acknowledgments
-
- Jeff Schiller and Christian Huitema developed this scheme during a
- terminal room BOF at the Dallas IETF meeting, December 1995. The
- author transcribed the notes from that discussion, which form the
- basis for this document. The editor appreciates Jeff's and
- Christian's patience in reviewing this document and its earlier
- drafts.
-
- Thanks also to John Wilkins, Ran Atkinson and Shawn Mamros for
- reviewing this document, and to Thomas Narten for reviewing earlier
- drafts of this document.
-
-8. Security considerations
-
- This document describes authentication and verification mechanisms
- for DHCP.
-
-9. Author's address
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-Droms [Page 7]
-\f
-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]
-\f
+++ /dev/null
-
-
-Network Working Group Yakov Rekhter
-Internet Draft Cisco Systems
-Expiration Date: April 1997 October 1996
-
-
- Interaction between DHCP and DNS
- draft-ietf-dhc-dhcp-dns-02.txt
-
-
-1. Status of this Memo
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-
-2. Abstract
-
- DHCP provides a powerful mechanism for IP host autoconfiguration.
- However, the autoconfiguration provided by DHCP does not include
- updating DNS, and specifically updating the name to address and
- address to name mappings maintained by DNS.
-
- This document specifies how DHCP clients and servers should use the
- Dynamic DNS Updates mechanism to update the DNS name to address and
- address to name mapping, so that the mappings for DHCP clients would
- be consistent with the IP addresses that the clients acquire via
- DHCP.
-
-
-
-
-
-
-
-
-
-
-
-Yakov Rekhter \f[Page 1]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
-3. Interaction between DHCP and DNS
-
- DNS [RFC1034, RFC1035] maintains (among other things) the information
- about mapping between hosts' Fully Qualified Domain Names (FQDNs)
- [RFC1594] and IP addresses assigned to the hosts. The information is
- maintained in two types of Resource Records (RRs): A and PTR. The A
- RR contains mapping from a FQDN to an IP address; the PTR RR contains
- mapping from an IP address to a FQDN.
-
- DHCP [RFC1541] provides a mechanism by which a host (a DHCP client)
- could acquire certain configuration information, and specifically its
- IP address(es). However, DHCP does not provide any mechanisms to
- update the DNS RRs that contain the information about mapping between
- the host's FQDN and its IP address(es) (A and PTR RRs). Thus the
- information maintained by DNS for a DHCP client may be incorrect - a
- host (the client) could acquire its address by using DHCP, but the A
- RR for the host's FQDN wouldn't reflect the address that the host
- acquired, and the PTR RR for the acquired address wouldn't reflect
- the host's FQDN.
-
- Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS
- information to be updated DNS over a network.
-
- The Dynamic DNS Update protocol can be used to maintain consistency
- between the information stored in the A and PTR RRs and the actual
- address assignment done via DHCP. When a host with a particular FQDN
- acquires its IP address via DHCP, the A RR associated with the host's
- FQDN would be updated (by using the Dynamic DNS Updates protocol) to
- reflect the new address. Likewise, when an IP address gets assigned
- to a host with a particular FQDN, the PTR RR associated with this
- address would be updated (using the Dynamic DNS Updates protocol) to
- reflect the new FQDN.
-
-
-4. Models of operations
-
- When a DHCP client acquires a new address, both the A RR (for the
- client's FQDN) and the PTR RR (for the acquired address) have to be
- updated. Therefore, we have two separate Dynamic DNS Update
- transactions. Acquiring an address via DHCP involves two entities: a
- DHCP client and a DHCP server. In principle each of these entities
- could perform none, one, or both of the transactions. However, upon
- some introspection one could realize that not all permutations make
- sense. This document covers the possible design permutations:
-
- (1) DHCP client updates the A RR, DHCP server updates the PTR
- RR
-
-
-
-
-Yakov Rekhter \f[Page 2]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
- (2) DHCP server updates both the A and the PTR RRs
-
- One could observe that the only difference between these two cases is
- whether the FQDN to IP address mapping is updated by a DHCP client or
- by a DHCP server. The IP address to FQDN mapping is updated by a DHCP
- server in both cases.
-
-
-4.1. Client FQDN Option
-
- To update the IP address to FQDN mapping a DHCP server needs to know
- FQDN of the client to which the server leases the address. To allow
- the client to convey its FQDN to the server this document defines a
- new option, called "Client FQDN".
-
- The code for this option is 81. Its minimum length is 4.
-
-
-
- Code Len Flags RCODE1 RCODE2 Domain Name
- +------+------+------+------+------+------+--
- | TBD | n | 0/1 | | | ...
- +------+------+------+------+------+------+--
-
-
-
- The Flags field allows a DHCP client to indicate to a DHCP server
- whether the client wants the server to be responsible for updating
- the FQDN to IP address mapping (if Flags is set to 1), or whether the
- client wants to take this responsibility (if Flags is set to 0).
-
- The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to
- a DHCP client the Response Code from Dynamic DNS Updates.
-
- The Domain Name part of the option carries FQDN of a client.
-
-
-
-4.2. DHCP Client behavior
-
- If a client wants to be responsible for updating the FQDN to IP
- address mapping for the FQDN and address(es) used by the client, then
- the client shall include the Client FQDN option in the DHCPREQUEST
- message originated by the client. The Flags field in the option shall
- be set to 0. Once the client's DHCP configuration is completed (the
- client receives a DHCPACK message, and successfully completed a final
- check on the parameters passed in the message), the client shall
- originate an update for the A RR (associated with the client's FQDN).
-
-
-
-Yakov Rekhter \f[Page 3]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
- The update shall be originated following the procedures described in
- [DynDNS].
-
-
- If a client does not want to be responsible for updating the FQDN to
- IP address mapping for the FQDN and address(es) used by the client,
- then the client shall include the Client FQDN option in the
- DHCPREQUEST message originated by the client. The Flags field in the
- option shall be set to 1.
-
-
- A client should set the RCODE1 and RCODE2 fields in the Client FQDN
- option to 0 when sending the option.
-
- Whether the client wants to be responsible for updating the FQDN to
- IP address mapping, or whether the client wants to delegate this
- responsibility to a server is a local to the client matter. The
- choice between the two alternatives may be based on a particular
- security model that is used with the Dynamic DNS Update protocol
- (e.g., only a client may have sufficient credentials to perform
- updates to the FQDN to IP address mapping for its FQDN).
-
- If a client releases its address lease prior to the lease expiration
- time, and the client is responsible for updating its A RR(s), the
- client should delete the A RR (following the procedures described in
- [DynDNS]) associated with the leased address before sending DHCP
- RELEASE message.
-
-
-4.3. DHCP Server behavior
-
- When a server receives a DHCPREQUEST message from a client, if the
- message contains the Client FQDN option, and the server replies to
- the message with a DHCPACK message, the server shall originate an
- update for the PTR RR (associated with the address leased to the
- client). The server shall originate the update before the server
- sends the DHCPACK message to the client. The update shall be
- originated following the procedures described in [DynDNS]. The RCODE
- from the update [DynDNS] should be carried to the client in the
- RCODE1 field of the Client FQDN option in the DHCPACK message. The
- RCODE2 field should be set to 0.
-
- In addition, if the Client FQDN option carried in the DHCPREQUEST
- message has its Flags field set to 1, then the server shall originate
- an update for the A RR (associated with the FQDN carried in the
- option). The server shall originate the update before the server
- sends the DHCPACK message to the client. The update shall be
- originated following the procedures described in [DynDNS]. The RCODE
-
-
-
-Yakov Rekhter \f[Page 4]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
- from the update [DynDNS] should be carried to the client in the
- RCODE2 field of the Client FQDN option in the DHCPACK message.
-
- When a server receives a DHCPREQUEST message from a client, and the
- message contains the Client FQDN option, the server shall ignore the
- value carried in the RCODE1 and RCODE2 fields of the option.
-
- When a DHCP server sends the Client FQDN option to a client in the
- DHCPACK message, the server should copy the Flags and the Domain Name
- fields from the Client FQDN option that the client sent to the server
- in the DHCPREQUEST message.
-
-
- If a server originates updates for both the A and PTR RRs, then the
- order in which the updates are generated is not significant.
-
-
- If a server detects that a lease on an address that the server leases
- to a client expires, the server should delete the PTR RR associated
- with the address. In addition, if the client authorized the server to
- update its A RR, the server should also delete the A RR. The deletion
- should follow the procedures described in [DynDNS].
-
- If a server terminates a lease on an address prior to the lease
- expiration time, the server should delete the PTR RR associated with
- the address. In addition, if the client (that leased the address)
- authorized the server to update its A RR, the server should also
- delete the A RR. The deletion should follow the procedures described
- in [DynDNS].
-
-
-5. Updating other RRs
-
- The procedures described in this document cover updates only to the A
- and PTR RRs. Updating other types of RRs is outside the scope of this
- document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yakov Rekhter \f[Page 5]
-
-
-
-
-
-Internet Draft draft-ietf-dhc-dhcp-dns-02.txt October 1996
-
-
-6. Security Considerations
-
- Security issues are not discussed in this document.
-
-
-7. References
-
- [RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
- RFC1034, 11/01/1987
-
- [RFC1035] P. Mockapetris, "Domain names - implementation and
- specification", RFC1035, 11/01/1987
-
- [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541,
- 10/27/1993
-
- [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and
- Answer Answers to Commonly asked ``New Internet User'' Questions",
- RFC1594, 03/11/1994
-
- [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates
- in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS-
- 09.txt
-
-
-
-8. Acknowledgements
-
- Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms
- (Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron),
- and Michael Patton (BBN) for their review and comments.
-
-
-9. Author Information
-
-
- Yakov Rekhter
- cisco Systems, Inc.
- 170 Tasman Dr.
- San Jose, CA 95134
- Phone: (914) 528-0090
- email: yakov@cisco.com
-
-
-
-
-
-
-
-
-
-Yakov Rekhter \f[Page 6]
-
-
+++ /dev/null
-
-
-Network Working Group R. Droms
-INTERNET DRAFT Bucknell University
-Obsoletes: draft-ietf-dhc-options-opt127-01.txt April 1996
- Expires October 1996
-
-
- An Extension to the DHCP Option Codes
- <draft-ietf-dhc-options-opt127-02.txt>
-
-Status of this memo
-
- This document is an Internet-Draft. Internet-Drafts are working
- documents of the Internet Engineering Task Force (IETF), its areas,
- and its working groups. Note that other groups may also distribute
- working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- To learn the current status of any Internet-Draft, please check the
- ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
- Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
- munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-Abstract
-
- The Dynamic Host Configuration Protocol (DHCP) provides a framework
- for passing configuration information to hosts on a TCP/IP network.
- This document defines a new option to extend the available option
- codes.
-
-Introduction
-
- The Dynamic Host Configuration Protocol (DHCP) [1] provides a
- framework for passing configuration information to hosts on a TCP/IP
- network. Configuration parameters and other control information are
- carried in tagged data items that are stored in the 'options' field
- of the DHCP message. The data items themselves are also called
- "options."
-
- Each option is assigned a one-octet option code. Options 128-254 are
- reserved for local use and at this time over half of the available
- options in the range 0-127 and option 255 have been assigned. This
- document defines a new option to extend the available option codes
- and new option to request the parameters represented by those new
-
-
-
-Droms [Page 1]
-\f
-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]
-\f
-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]
-\f
projects / thirdparty / dhcp.git / commitdiff
