+++ /dev/null
-
-CURRENT_MEETING_REPORT_
-
-Reported by Walt Wimer/CMU
-
-Minutes of the Dynamic Host Configuration Working Group (DHC)
-
-The DHC Working Group met on 7 December and 9 December at the 31st IETF.
-
-
-Document Status
-
-The most recent Internet-Draft of the DHCP specification includes
-several changes based on the results of the latest interoperability
-testing. Based on the results of that testing, and a review of the
-Standards process RFC, the working group decided it would be appropriate
-to ask that DHCP be considered for ``Draft Standard'' status. As soon
-as a revision of the current Internet-Draft is completed, the
-specification for DHCP will be submitted for review.
-
-A few, minor changes have been made to RFC 1541 based on questions
-raised during the latest interoperability testing. Two new options have
-been defined since RFC 1533: 62, NetWare/IP domain and 63, NetWare/IP
-option.
-
-The working group agreed that the minimum lease requirement (one hour)
-should be made advisory rather than mandatory.
-
-
-Implementations
-
-The following list of implementations was compiled from information
-given by working group attendees.
-
- _____________________________________________________________________
- || | | | ||
- || Vendor |Client |Server |Relay agent ||
- ||___________________|___________________|_______________|_____________||
- || FTP Software |DOS/Windows |Windows | ||
- ||___________________|___________________|NT_(beta)______|_____________||
- || SunSoft |DOS/Windows |Solaris 2.0 |in server ||
- ||___________________|Solaris_(beta?)____|_______________|_____________||
- || Microsoft |DOS/Windows |NT |in server ||
- || |NT | | ||
- ||___________________|Windows95_beta_____|_______________|_____________||
- || Competitive |??? |Solaris | ||
- ||_Automation________|___________________|_______________|_____________||
- || Apple |Newton | | ||
- ||___________________|Mac_(beta)_________|_______________|_____________||
- || WIDE project |Unix, BSD386 |Unix, BSD386 |Unix, BSD386 ||
- ||_(free,_avail_2/95)|News,_SunOS________|News,_SunOS____|News,_SunOS_ ||
- ||_Silicon_Graphics__|IRIX_(soon)________|IRIX___________|_____________||
- || Hewlett Packard |X-terminal |HP/UX (June 95)|in server ||
- ||___________________|___________________|_______________|HP_router____||
- || IBM |OS/2 (soon) |OS/2 (soon) | ||
- || |AIX (soon) |AIX (soon) | ||
- ||___________________|___________________|AS/400_(soon)__|_____________||
- || cisco Systems |Terminal server? | |routers ||
- || |(proxy for | | ||
- ||___________________|terminal_clients?)_|_______________|_____________||
- || Novell |NetWare/IP |NetWare/IP | ||
- ||___________________|(spring)___________|(later)________|_____________||
- || Shiva |Proxy for | | ||
- ||___________________|dial-in_clients____|_______________|_____________||
-
-
-Future Interoperability Test
-
-There was some discussion of a future interoperability test. Suggested
-venues include Bucknell University (summer '95), CMU (no specific time),
-next IETF (March '95) and remote via the Internet (?!?!). The working
-group will hold a discussion about the next interoperability testing via
-electronic mail.
-
-
-Outstanding Issues
-
-The working group discussed some outstanding issues and generated some
-solutions:
-
-
- o New options: TFTP server address, bootfile name, to be registered
- with IANA.
-
- o Some clients will already have an IP address, not otherwise
- registered or managed by DHCP. Those clients will only want local
- configuration parameters, not an address. A new DHCP message,
- DHCPINFORM, will be defined for parameter requests.
-
- o There was some question about the definition and interpretation of
- ``client identifiers.'' The working group confirmed that a
- ``client identifier'' is an opaque, unique identifier. Text will
- be added to the protocol specification to clarify this issue and to
- advise that ``client identifiers'' must be unique. ``Client
- identifier'' type 0 will indicate ``an opaque string of
- characters.''
-
-
-The issue of security was discussed. The primary concern is to detect
-and avoid spoof/unauthorized servers. Some sites are also concerned
-about unauthorized clients. The consensus was that a public key
-identification and authorization mechanism should be developed as an
-optional DHCP service.
-
-Ralph Droms presented a preliminary proposal for a server-server
-protocol to allow automatic management of DHCP bindings by multiple DHCP
-servers at a single site. The goals are to increase availability and
-reliability through redundancy of address allocation and binding
-servers, and through load sharing. The basic model, based on a proposal
-by Jeff Mogul, is to assign each allocatable address and allocated
-binding to a specific ``owner'' server. That owner has modification
-privileges, while all other servers have read-only privileges. Servers
-use TCP connections and a simple protocol to replicate copies of new
-bindings and transfer ownership of addresses to balance the pool of
-available addresses.
-
-The hard part is bindings that are released early, prior to expiration.
-Those released bindings must be reported to all other servers, so those
-servers do not respond with stale data in the future. However, servers
-may be inaccessible. The proposed solution was to add an ``owner''
-option; clients would select responses from the ``owner'' in favor of
-all other responses.
-
-The suggestion was made that multiple DHCP servers might be able to use
-an underlying distributed database like DNS, NIS+ or Oracle. Questions
-were raised about the scalability of the proposed scheme -- suppose many
-clients send simultaneous update requests, how often should updates be
-replicated, what about combinatoric explosion with the number of
-servers?
-
-
-IPv6 Issues
-
-The second meeting began with a discussion of several IPv6 issues. IPv6
-address configuration has three basic forms:
-
-
- 1. Intra-link scope address (client forms address all on its own)
-
- 2. ``Stateless'' servers (e.g., in routers using some simple
- assignment algorithm)
- 3. Stateful servers (`a la IPv4 DHCP)
-
-
-Regardless of how addresses are managed, IPv6 will need some other
-mechanism(s) to obtain other configuration parameters. Some members of
-the IPv6 design team claim there will be no other parameters.
-
-The following action items were identified:
-
-
- o Someone to enumerate all IPv6 network layer parameters.
- Mike Carney volunteered.
-
- o Extensions/changes to DHCP protocol format for IPv6.
- Walt Wimer volunteered.
-
-
-Dynamic Addressing
-
-Next, the working group discussed the problem of dynamic updates to DNS
-from DHCP information (dynamic addressing). For simple registration of
-DNS hostnames for individual DHCP clients, what should we do? Should
-client be responsible for contacting DNS server directly, or should DHCP
-server contact DNS on behalf of client? It will be necessary to clarify
-DNS configuration/update mechanism with DNS Working Group. One solution
-to the question of who does the update would be to define a DHCP option
-for client to say whether it will do the registration with DNS directly
-or whether client wants DHCP server to take care of it. DHCP server may
-need a way to veto the client's preference. This permits a simple
-client (such as an embedded hub, probe, etc.) to let the DHCP server do
-everything (DHCP server probably has necessary credentials to update DNS
-while client probably does not). Or, a more sophisticated client can
-update its ``home'' DNS directly (for example, a mobile notebook
-computer belonging to XYZ, Inc. can be taken to an IETF get a local IP
-address from the IETF DHCP server, but then directly update XYZ.COM's
-DNS server in order to maintain an XYZ.COM name). The problem of name
-collisions was unresolved - should the client or the server be
-responsible? Masataka Ohta volunteered to do a DHCP-to-DNS interaction
-proposal
-
-
-DHCP and SNMP
-
-Finally, the working group considered DHCP and SNMP. The working group
-chair asked if there were any MIB writers in the audience. The scribe
-thought there was a volunteer but did not catch the name.
-
+++ /dev/null
-
-CURRENT_MEETING_REPORT_
-
-Reported by Rob Austein/Epilogue Technology
-
-Minutes of the Domain Name System Working Group (DNS)
-
-
-Documents
-
-Three new DNS-related Informational RFCs have come out recently.
-RFC 1535 (also known as ``the EDU.COM emergency RFC'') details problems
-with a widely-used but ill-advised DNS search heuristic, and proposes a
-solution. RFC 1536 details common DNS implementation errors, with
-proposed solutions; this document was accepted as a DNS Working Group
-project at the 27th IETF (Amsterdam), completed, and accepted on the
-mailing list. RFC 1537 details common DNS configuration errors; while
-it was never formally accepted as a DNS Working Group document, it was
-reviewed by the working group members. These three RFCs are closely
-related and cross-reference each other, so, on advice of the RFC Editor,
-the DNS Working Group Chair approved ``fast track'' publication of these
-documents on behalf of the Working Group. If anybody has serious
-problems with these documents, blame it on the Chair.
-
-Dave Perkins reported on the current status of the DNS MIB documents on
-behalf of the Network Management Area Directorate (NMDIR). Basically,
-there are no remaining hard problems, just some remaining detail work.
-One of the authors, Rob Austein, has received a detailed list of
-remaining concerns, none of which appear to be show-stoppers. It should
-be possible to get these documents out the door before the 29th IETF in
-Seattle. Dave pointed out two design issues that are not objections but
-of which he thinks the DNS Working Group should be aware:
-
-
- 1. Due to SNMP protocol limitations, the length limits on DNS names
- used as indices to ``conceptual tables'' in the MIBs will be
- shorter than the DNS name length limit of 255 octets. Based on
- analysis of current usage, this should not be a problem, so we'll
- flag it with a warning statement in the document but otherwise
- leave it alone.
- 2. The most recent versions of the documents (not yet released as
- Internet-Drafts) use the SNMPv2 SMI rather than the SNMPv1 SMI, in
- order to clear up some problems with unsigned 32-bit integers.
- NMDIR wants to be sure that the DNS Working Group realizes that
- this means only SNMPv2-capable implementations will be able to use
- these MIBs.
-
-
-DNS Security Sub-Group
-
-James Galvin gave a report on the meeting held by the DNS Security
-``sub-group'' (a spin off from the DNS Working Group at the 26th IETF in
-Columbus).
-
-
- The DNS Security design team of the DNS Working Group met for
- one morning at the Houston IETF. The discussion began with a
- call for threats that the members of the group were most
- concerned about. The list included the following:
-
- o disclosure of the data - some expressed a desire to be
- able to encrypt the data in responses
-
- o modification of the data
-
- o masquerade of the origin of the data
-
- o masquerade of a secondary - some expressed a desire to be
- able to reliably identify both peers in a zone transfer;
- this would provide the basis for controlling access to
- zone transfers
-
- During the discussion of these threats it was agreed to accept
- the following assumptions:
-
- 1. DNS data is ``public''
- 2. backward/co-existence compatibility is required
-
- With respect to the first, accepting it set aside any further
- discussion of the threat of disclosure of the data. The second
- assumption is included explicitly to remind everyone that we do
- not want parallel DNS systems in the Internet.
- In addition, it was explicitly agreed that we would not address
- authentication of secondaries or access control issues. Thus,
- the current list of desired security services is:
-
- o data integrity
- o data origin authentication
-
- It was noted that a digital signature mechanism would support
- the desired services.
- The meeting continued with a brainstorming period during which
- the desired functional requirements of a secure DNS were
- collected. This list does not represent mandatory
- functionality but, rather, it is desired functionality. It was
- agreed that this list was subject to discussion on the mailing
- list for a period of time that would conclude on November 30.
- The requirements are listed here in no particular order.
-
- o sites must be able to support at least their internal
- users in the presence of external network failures
-
- o it should be possible for a site to pre-configure other
- authoritative servers without having to query the
- ``system'' to find the server
-
- o it should be possible to request services only from
- security enhanced servers, only from non-security enhanced
- servers, or to indicate that either is acceptable
-
- o it should be possible to recognize security enhanced
- responses
-
- o it should be possible to assign cryptographic keys (make
- use of the security services) to leaf nodes in the DNS
- tree, i.e., fully qualified domain names
-
- o it should be possible to not trust secondary servers
-
- o a mechanism must exist for revoking cryptographic keys
- that works within the DNS time-to-live framework
-
- o security services should be supported with no additional
- DNS queries beyond what would be required if security was
- not supported
-
- o it must be possible to ensure that cached data expires
- according to its TTL
-
- The meeting concluded with agreement on the following three
- milestones.
-
- 1. The desired functional requirements are to be reviewed and
- agreed upon by November 30.
-
- 2. Strawman proposals that meet as many of the desired
- requirements as possible are due by January 31, 1994.
-
- 3. The group would produce a single, draft proposal at the
- next IETF meeting, March 1994.
-
-
-
-The DNS Security effort will be spun off as a separate working group in
-the Service Applications Area (SAP), as soon as James can get the
-charter approved. The DNS Security mailing list is
-dns-security@tis.com; requests to subscribe should be sent to
-dns-security-request@tis.com.
-
-Discussion of the incremental zone transfer protocol
-(draft-ietf-dns-ixfr-00.txt) was deferred because none of the authors
-were present at the meeting. Comments on this draft should be sent to
-the authors and/or the Namedroppers mailing list.
-
-
-
-DNS Efforts to Support SIPP
-
-Sue Thomson gave a brief report on current DNS efforts to support SIPP
-(the merger of the SIP and PIP proposals). See the latest version of
-the Internet-Draft, draft-ietf-sip-sippdns-nn.txt, for details.
-
-
-DNS Reliability Issues - Boeing
-
-Ed King gave a presentation on DNS reliability issues in Boeing's
-production environment. Ed has to support DNS on a corporate network
-with thousands of subnets and DNS software from many vendors in a
-production environment that never shuts down and where an interruption
-to DNS services due to a power hit can leave hundreds of engineers
-sitting idle waiting for their workstations to finish booting. Much of
-the problem is that each vendor has their own slightly different (and
-often more than slightly broken) interface between DNS, local host
-tables, and the vendor's own pet name resolution mechanism. Replacing
-or repairing all the DNS software in an environment isn't economically
-feasible, so the most constructive approach seems to be to write a ``DNS
-Requirements'' document to use as a reference when pressuring vendors to
-fix their DNS implementations. The DNS portion of the Host Requirements
-documents (RFC 1123 section 6.1) and the newly published DNS ``Common
-Errors'' Informational RFCs are good starting points, but companies like
-Boeing need a document that has the force of a standard and that goes
-into more detail on interface design issues than Host Requirements does.
-
-No definite decision was reached as a result of Ed's presentation, but
-watch Namedroppers for further discussion and probably a call to form a
-working group.
-
-
-DNS Support for DHC and Mobile Hosts
-
-Masataka Ohta gave a presentation on a possible way to implement some of
-the DNS support needed for dynamic host configuration and mobile hosts.
-The presentation went into more detail than there is room for in these
-minutes, so expect to see a summary of this on the Namedroppers list.
-
-
-The Future of the DNS Working Group
-
-Dave Crocker spoke about the future of the DNS Working Group. As has
-been discussed at previous meetings, the DNS Working Group as currently
-organized doesn't really fit well into the current IETF organizational
-framework. Accordingly, Dave asks that DNS reorganize itself more along
-the current IETF pattern. The proposal is to move the ``permanent''
-functions of the DNS Working Group (DNS oversight within the IETF,
-mostly) into the SAP Area Directorate, that Dave will be forming ``Real
-Soon Now,'' while reincarnating specific closed-ended tasks as separate
-working groups within the SAP Area. The SAP Area Directorate will hold
-open meetings at regular intervals, so that there will still be a forum
-for overall DNS design work. For formal purposes, the current DNS
-Working Group will probably be retroactively construed as having been
-the DNS MIB Working Group, and will be closed down as soon as the DNS
-MIB documents hit the streets. As a practical matter, and in the
-Chair's opinion, the current DNS Working Group will effectively
-reconstitute itself as the attendees of the DNS portion of the SAP Area
-Directorate open meetings. Dave expects to have the reorganization
-completed by the 29th IETF in Seattle.
-
-The discussion that followed Dave's statement made it clear that there
-are people with strong feelings on both sides of this issue (keep the
-DNS Working Group as it is versus reorganize per Dave's plan). Unless
-somebody feels strongly enough about this to make a formal appeal, the
-reorganization will probably go through.
-
-
-Attendees
-
-Steve Alexander stevea@lachman.com
-Garrett Alexander gda@tycho.ncsc.mil
-Robert Austein sra@epilogue.com
-Anders Baardsgaad anders@cc.uit.no
-Alireza Bahreman bahreman@bellcore.com
-William Barns barns@gateway.mitre.org
-Stephen Crocker crocker@tis.com
-Donald Eastlake dee@skidrow.lkg.dec.com
-Havard Eidnes havard.eidnes@runit.sintef.no
-Erik Fair fair@apple.com
-Roger Fajman raf@cu.nih.gov
-Patrik Faltstrom paf@nada.kth.se
-Antonio Fernandez afa@thumper.bellcore.com
-James Fielding jamesf@arl.army.mil
-James Galvin galvin@tis.com
-Chris Gorsuch chrisg@lobby.ti.com
-Ronald Jacoby rj@sgi.com
-Rick Jones raj@cup.hp.com
-Charlie Kaufman kaufman@zk3.dec.com
-Elizabeth Kaufman kaufman@biomded.med.yale.edu
-Stephen Kent kent@bbn.com
-Edwin King eek@atc.boeing.com
-Paul Lambert paul_lambert@email.mot.com
-Walter Lazear lazear@gateway.mitre.org
-Lars-Johan Liman liman@ebone.net
-John Linn linn@security.ov.com
-Jun Matsukata jm@eng.isas.ac.jp
-Paul Mockapetris pvm@darpa.mil
-Sath Nelakonda sath@lachman.com
-Masataka Ohta mohta@cc.titech.ac.jp
-Michael Patton map@bbn.com
-Jon Postel postel@isi.edu
-Jeffrey Schiller jis@mit.edu
-Richard Schmalgemeier rgs@merit.edu
-Michael St. Johns stjohns@arpa.mil
-John Stewart jstewart@cnri.reston.va.us
-Theodore Ts'o tytso@mit.edu
-Walter Wimer walter.wimer@andrew.cmu.edu
-David Woodgate David.Woodgate@its.csiro.au
-Weiping Zhao zhao@nacsis.ac.jp
-
--- /dev/null
+
+Network Working Group R. Droms
+INTERNET DRAFT Bucknell University
+Obsoletes: February 1996
+ Expires August 1996
+
+
+ Procedure for Defining New DHCP Options
+ <draft-ietf-dhc-new-options-00.txt>
+
+Status of this memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its areas,
+ and its working groups. Note that other groups may also distribute
+ working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ To learn the current status of any Internet-Draft, please check the
+ ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+ Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+ munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+ ftp.isi.edu (US West Coast).
+
+Abstract
+
+ The Dynamic Host Configuration Protocol (DHCP) provides a
+ framework for passing configuration information to hosts on a TCP/IP
+ network. Configuration parameters and other control information are
+ carried in tagged data items that are stored in the 'options' field
+ of the DHCP message. The data items themselves are also called
+ "options."
+
+ This document describes the procedure for defining new DHCP options.
+ The procedure will guarantee that:
+
+ * allocation of new option numbers is coordinated from a single
+ authority,
+ * new options are reviewed for technical correctness and
+ appropriateness, and
+ * documentation for new options is complete and published.
+
+
+
+
+
+
+
+Droms [Page 1]
+\f
+DRAFT Procedure for Defining New DHCP Options February 1996
+
+
+Procedure
+
+ The author of a new DHCP option will follow these steps to obtain
+ acceptance of the option as a part of the DHCP Internet Standard:
+
+ 1. The author devises the new option.
+ 2. The author requests a number for the new option from IANA.
+ 3. The author documents the new option, using the newly obtained
+ option number, as an Internet Draft.
+ 4. The author submits the Internet Draft for review through the IETF
+ standards process as defined in "Internet Official Protocol
+ Standards" (STD 1). The new option will be submitted for eventual
+ acceptance as an Internet Standard.
+ 5. The new option progresses through the IETF standards process; the
+ new option will be reviewed by the Dynamic Host Configuration
+ Working Group (if that group still exists), or as an Internet
+ Draft not submitted by an IETF working group.
+ 6. If the new option fails to gain acceptance as an Internet
+ Standard, the assigned option number will be returned to IANA for
+ reassignment.
+
+Acceptance and publication
+
+ If this procedure is accepted, it will be added to the DHCP options
+ specification as an Appendix.
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Ralph Droms
+ Computer Science Department
+ 323 Dana Engineering
+ Bucknell University
+ Lewisburg, PA 17837
+
+ Phone: (717) 524-1145
+ EMail: droms@bucknell.edu
+
+
+
+
+
+
+
+
+
+
+
+Droms [Page 2]
+\f
--- /dev/null
+
+
+A new Request for Comments is now available in online RFC libraries.
+
+
+ RFC 1533:
+
+ Title: DHCP Options and BOOTP Vendor Extensions
+ Author: S. Alexander & R. Droms
+ Mailbox: stevea@lachman.com, droms@bucknell.edu
+ Pages: 30
+ Characters: 50,919
+ Obsoletes: 1497, 1395, 1084, 1048
+
+
+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
+RFC specifies the current set of DHCP options. This document will be
+periodically updated as new options are defined. Each superseding
+document will include the entire current list of valid options. This
+RFC is the product of the Dynamic Host Configuration Working Group of
+the IETF.
+
+This is now a Proposed Standard Protocol.
+
+This RFC 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" for the standardization state and status
+of this protocol. Distribution of this memo is unlimited.
+
+This announcement is sent to the IETF list and the RFC-DIST list.
+Requests to be added to or deleted from the IETF distribution list
+should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added
+to or deleted from the RFC-DIST distribution list should be sent to
+RFC-REQUEST@NIC.DDN.MIL.
+
+Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
+an EMAIL message to "rfc-info@ISI.EDU" with the message body
+"help: ways_to_get_rfcs". For example:
+
+ To: rfc-info@ISI.EDU
+ Subject: getting rfcs
+
+ help: ways_to_get_rfcs
+
+Requests for special distribution should be addressed to either the
+author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless
+specifically noted otherwise on the RFC itself, all RFCs are for
+unlimited distribution.
+
+Submissions for Requests for Comments should be sent to
+RFC-EDITOR@ISI.EDU. Please consult RFC 1111, "Instructions to RFC
+Authors", for further information.
+
+
+Joyce K. Reynolds
+USC/Information Sciences Institute
+
--- /dev/null
+
+
+Network Working Group R. Droms
+INTERNET DRAFT Bucknell University
+Obsoletes: draft-ietf-dhc-options-opt127-00.txt February 1996
+ Expires August 1996
+
+
+ An Extension to the DHCP Option Codes
+ <draft-ietf-dhc-options-opt127-01.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.
+
+
+
+
+Droms [Page 1]
+\f
+DRAFT An extension to the DHCP Option Codes February 1996
+
+
+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.
+
+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 2]
+\f
+++ /dev/null
-
-
-
-
-
-
-DNSIND Working Group Susan Thomson (Bellcore)
-INTERNET-DRAFT Yakov Rekhter (IBM)
-<draft-ietf-dnsind-dynDNS-00.txt> Jim Bound (DEC)
- January 31, 1995
-
-
- Extending the Domain Name System (DNS) to Perform Dynamic Updates
-
-
-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. Internet Drafts may be updated, replaced, or obsoleted by
- other documents at any time. It is not appropriate to use Internet
- Drafts as reference material or to cite them other than as a "working
- draft" or "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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
- munnari.oz.au.
-
-
-Abstract
-
- The Domain Name System currently only supports queries on a
- statically configured database. This document describes extensions to
- the Domain Name System to enable name servers to accept requests to
- update the database dynamically. Extensions include support for
- adding and deleting a set of names and associated resource records
- within a zone atomically and the definition of a new resource record
- that enables update requests to be serialized.
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 1]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-1. INTRODUCTION
-
-
- The Domain Name System currently only supports queries on a stati-
- cally configured database. This document describes extensions to the
- Domain Name System to enable name servers to accept requests to
- update the database dynamically.
-
- Section 2 provides an overview of the update function. Section 3
- describes the update message format and Sections 4 and 5 describe
- name server and resolver behavior when processing dynamic updates in
- more detail. Examples of usage are described in Section 6. A new
- resource record useful for serializing update requests is defined in
- Section 7 and security considerations are discussed in Section 8.
-
-
-
-2. OVERVIEW
-
- A domain name identifies a node within the domain name space tree
- structure. Each node has a set of Resource Records (RRs).
-
- The extensions to the DNS protocol enable name servers to accept
- requests to update the names space and RRs associated with nodes in
- the name space dynamically. An update request is an atomic transac-
- tion consisting of a set of operations on names and RRs in a zone.
- The operations may be one of four types:
-
- 1. Add new name and associated with it a set of records to zone
- (ADDNEW)
-
- This operation is only successful if the name of the records
- does not already exist in the zone. The effect of the operation
- is to create a new node in the name space and add records to
- this node.
-
- 2. Add records associated with an existing name to zone (ADDEXIST)
-
- This operation is only successful if the name the records are
- associated with exists in the zone. The effect of the operation
- is to update records that belong to an existing node in the name
- space.
-
- 3. Add name and associated with it a set of records to zone,
- whether name exists or not (ADD)
-
-
-
-Expires July 31, 1995 [Page 2]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- If the name already exists, then the semantics of this operation
- is the same as ADDEXIST. If the name doesn't exist, then the
- semantics of this operation is the same as ADDNEW.
-
- 4. Delete records from zone (DELETE)
-
- This operation is only successful if the specified records
- exist. However, it is possible to specify that all resource
- records associated with a name, class and type must be deleted
- without explicitly deleting each and every one of them. This is
- done using a wildcard data field in the resource record.
-
-
- The update protocol allows several operations to be performed on sets
- of records with different owner names and record types, provided all
- names are contained within a single zone. The effect of an update
- transaction is to perform all of the operations in the transaction,
- if all can be performed successfully, or none at all. If the zone
- serial number in the SOA RR is not explicitly updated in an update
- request, a side-effect of a successful update transaction may be to
- update the zone serial number. A successful update is applied syn-
- chronously to the database by the primary name server for the zone,
- and the updates are transferred to secondary name servers asynchro-
- nously.
-
- Some of the operations depend on comparing an existing record with a
- record specified in an update. Two records are considered to be the
- same if their name, class, type, data length and value are the same.
- The time-to-live field is specifically excluded from comparison. The
- effect of wildcard names and data fields are discussed in Section 3.
-
- The message format used to implement an atomic transaction has a
- similar structure to that of a query, but the contents of some of the
- fields differ. An entity that initiates an update indicates in an
- update message the update operations to be performed along with the
- records to be updated. A name server responds to an update request
- by (a) indicating that the update has been successfully applied to
- the database at the primary name server, (b) indicating that the name
- server is not authoritative for the records specified, or (c) indi-
- cating an error.
-
- An update may be carried in a UDP datagram or a TCP connection.
-
-
-
-
-
-
-Expires July 31, 1995 [Page 3]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-3. UPDATE MESSAGE FORMAT
-
-
- The message format has the following structure: the message header,
- which is similar to that of the query, and the message body, which
- consists of four sections, one per operation type. The four sections
- are in the order listed: the delete section, the add new record sec-
- tion, the add existing record section and the plain add secion. Each
- section contains the records that need to have the associated opera-
- tion applied.
-
-
-
-3.1. Header Section
-
-
-
-
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | DELCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | AECOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ACOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
- The differences between the query header and the update header are in
- the values that certain fields can assume, and in the semantics of
- certain fields.
-
- There is a new operation code (value to be defined) to specify an
- update request in the Opcode field.
-
-
- UPDATE TBD
-
-
-
-
-Expires July 31, 1995 [Page 4]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- This Opcode distinguishes the update header from the query header.
- This document specifies the semantics of the fields in the update
- header only.
-
- Besides a new operation code, there are also new return codes. The
- four count fields have different semantics: they contain the number
- of records in the DELETE section, the number of records in the ADDNEW
- section, the number of records in the ADDEXIST section and the number
- of records in the ADD section, respectively.
-
- The other fields remain the same, except that they apply to update
- requests rather than queries. Note the AA bit is set in a response if
- and only if a server is authoritative for ALL nodes specified in the
- request. Also, the TC bit is not applicable to updates.
-
- The fields are set as follows in update requests and responses:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 5]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- ID A 16 bit identifier assigned by the entity that
- generates any kind of request. This identifier is
- copied in the corresponding reply and can be used by the
- requestor to match up replies to outstanding requests.
-
- QR A one bit field that specifies whether this message is a
- request (0), or a response (1).
-
- OPCODE A four bit field that specifies the kind of request in
- this message. This value is set by the originator of a
- request and copied into the response. In addition to
- the values defined in RFC1034, this document defines the
- following value:
-
- TBD an update request (UPDATE)
-
-
- AA Authoritative Answer - this bit is valid in responses,
- and specifies that the responding name server is an
- authority for all domain names in the message body.
-
- TC Bit is set to zero in an update request and copied into
- the response. The TC bit is ignored on receipt of a
- request or response.
-
-
- RD Recursion Desired - this bit may be set in a request and
- is copied into the response. If RD is set, it directs
- the name server to pursue the request recursively.
- Recursive update support is optional.
-
- RA Recursion Available - this be is set or cleared in a
- response, and denotes whether recursive update support is
- available in the name server.
-
- Z Reserved for future use. Must be zero in all requests
- and responses.
-
- RCODE Response code - this 4 bit field is set as part of
- responses. The values and semantics of update responses
- are as follows:
-
- 0 No error condition
-
- 1 Format error - The name server was
-
-
-
-Expires July 31, 1995 [Page 6]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- unable to interpret the request.
-
- 2 Server failure - The name server was
- unable to process this request due to a
- problem with the name server.
-
- 3 Name Error - Meaningful only for
- responses from an authoritative name
- server, this code signifies that one or
- more of the domain names referenced in
- the update request does not exist.
-
- 4 Not Implemented - The name server does
- not support the specified operation.
-
- 5 Refused - The name server refuses to
- perform the specified operation for
- policy reasons.
-
- 6 Alias Error - This code indicates that the
- domain name specified in an update is an
- alias.
-
- 7 Name Exists Error - This code indicates
- the name already exists. This return code
- is only meaningful from a server
- in response to an ADDNEW operation.
-
- 8 Record Not Exist Error - This code
- indicates that the resource record does
- not exist.
- This return code is only meaningful from a
- server in response to a DELETE operation.
-
- 9 Too many Zones Error - This code
- indicates that the records to be
- updated exist in more than one zone.
-
- 10 SERIAL RR Error - This code
- indicates that an operation on the
- SERIAL record is in error.
-
- 11 Permission Denied - This code indicates
- that the client has insufficient authority
- to perform the update.
-
-
-
-Expires July 31, 1995 [Page 7]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- DELCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the DELETE section. Always zero in a
- response.
-
- ANCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the ADDNEW section. Always zero
- in a response.
-
- AECOUNT an unsigned 16 bit integer specifying the number of
- resource records in the ADDEXIST section.
- Always zero in a response.
-
- ACOUNT an unsigned 16 bit integer specifying the number of
- resource records in the ADD section.
- Always zero in a response.
-
-
-
-3.2. Testing for Resource Record Equality
-
-
- The update operations require that records be compared. In particu-
- lar, the DELETE operation requires that the records to be deleted
- must exist. It has already been stated that records are tested for
- equality by comparing their name, class, type, data length and data
- values. The time-to-live value is excluded from the comparison.
-
- The comparison of character strings in names and in data fields is
- case-insensitive. For two names to match, they must match label by
- label. A non-wildcard label never matches the '*' label, i.e. names
- must exist explicitly in a zone to be matched by a record specified
- in an update; the use of a wildcard name in a zone does not imply
- existence for updates.
-
- In a DELETE operation, it is sometimes convenient to specify that all
- records associated with a certain name that are of a given class and
- type be deleted without specifying all existing records explicitly. A
- record with a data field containing the '*' character and a data
- length field of one is defined to match data in any other record.
-
- DISCUSSION: I believe the '*' data value does not match existing
- legal data values, expect for the NULL record, which is experimental
- and not supported by BIND.
-
-
-
-
-
-Expires July 31, 1995 [Page 8]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-4. NAME SERVER BEHAVIOR
-
-
- From a client's perspective, any authoritative server can process an
- update request. Non-authoritative name servers forward the request to
- an authoritative name server if recursive service is specified or
- indicate to the client that the server is not authoritative for the
- records to be updated.
-
- From a server's perspective, only the primary authoritative name
- server actually performs the update request. A secondary name server
- is responsible for forwarding the request to the primary name server
- for the zone. As mentioned above, a non-authoritative name server is
- also responsible for forwarding the update request to the primary, if
- recursive service is desired by the client and it is available.
- Unlike a secondary, however, a non-authoritative name server will
- need to determine the name servers authoritative for the domain names
- to be updated by asking other names servers for referrals if the
- information is not cached locally. A secondary name server will have
- this information preconfigured. Note that the forwarding of an update
- message is done synchronously on an update request, whether it is
- performed by a secondary name server or a non-authoritative server
- that provides recursive service. That is, a name server will wait
- for a response to a forwarded update request before returning the
- response to the client.
-
-
-
-4.1. Maintaining Internal Consistency
-
-
- Zone consistency between primary and secondaries is achieved through
- asynchronous zone transfer. Either full zone transfer as currently
- defined can be used, or incremental zone transfer when it becomes
- available[IXFR]. The proposed Notify mechanism[NOTIFY] may also be
- used to cause zone transfers to happen earlier than would otherwise
- be determined by the zone refresh time.
-
-
-
-4.2. Algorithm
-
-
- On receiving an update request, the server's behavior will depend on
- whether recursive service is requested and available. If recursive
-
-
-
-Expires July 31, 1995 [Page 9]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- service is requested and available, the server determines the set of
- authoritative name servers for the nodes specified in the transac-
- tion. The server sends the update to the set of name servers, waits
- for the response, and returns the response to the resolver.
-
- If recursive service is not requested or is not available, then the
- name server checks to see whether the update is in a zone for which
- it is authoritative. If so, the server attempts to perform the update
- if the name server is primary for the zone. If the name server is
- secondary for the zone, the server forwards the update to the pri-
- mary name server, waits for the response and returns the response to
- the resolver. Otherwise, if the name server is not authoritative for
- the zone to be updated, an error is returned.
-
- The algorithm for name server behavior is explained in more detail
- below (adapted from [RFC1034]):
-
- 1. Indicate in the response whether update recursion is available
- or not. If recursive service is available and requested, then
- the server uses the local resolver or a copy of its algorithm
- (Section 4) to perform the update operation. Otherwise, go to
- step 2.
-
- 2 Determine the names (RRNAMEs) associated with all records to be
- updated in the transaction. For each RRNAME, search the avail-
- able zones for the zone which is the nearest to RRNAME.
-
- a) If no zone is found, return a non-authoritative response
- indicating no error. Exit.
-
- b) If more than one zone is found, return a response indicat-
- ing that the update request is not restricted to a single
- zone. Exit.
-
- Otherwise, go to step 3.
-
- 3. If this is a secondary name server for the zone, forward the
- request to the primary and wait for the response. Send the
- response to the resolver. Exit. (A secondary may do further
- checking of the update request before sending to the primary for
- processing, if desired.) Otherwise, go to step 4.
-
- 4. Start the transaction
-
- 5. For each RRNAME in the update request, start matching down,
-
-
-
-Expires July 31, 1995 [Page 10]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- label by label, in the zone (found in step 2). For each label,
- test for the following cases:
-
- a) If the whole RRNAME is matched, we have found the node to
- be updated.
-
- If the record at the node is a CNAME, and RRTYPE does not
- match CNAME, abort the transaction and return an authorita-
- tive response indicating an alias error.
-
- If the operation is ADDNEW, abort the transaction and
- return an authoritative response indicating that the name
- already exists.
-
- If the operation is ADDEXIST or ADD, check if the specified
- record already exists. If so, ignore.
-
- If the operation is DELETE, check if the specified record
- exists in the zone. If not, abort the transaction and
- return an authoritative response indicating that the record
- does not exist.
-
- Otherwise, perform the update operation tentatively.
-
- b) If we have a referral, abort the transaction. Return a
- non-authoritative response indicating no error. Exit.
-
- c) If at some label, a match is impossible (i.e. the label
- does not exist), and the operation is ADDEXIST or DELETE,
- abort the transaction and return an authoritative response
- indicating that the name does not exist.
-
- Otherwise, perform the update operation tentatively.
-
- 6 Commit the transaction. If the zone serial number has not been
- explicitly updated as part of the transaction, the zone serial
- number may or may not be incremented at this time. Indicate in
- the response that the server is authoritative and return a suc-
- cessful response. Exit.
-
- At the start of a transaction, the zone must be locked to prevent
- concurrent interleaving of concurrent update requests. The zone is
- unlocked at the end of a (successful or unsuccessful) transaction.
- Aborting a transaction requires that any changes made so far must be
- rolled back. Committing a transaction means that the changes are
-
-
-
-Expires July 31, 1995 [Page 11]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- applied to the zone and are visible to subsequent queries to the pri-
- mary. (It is an implementation matter whether the master file is
- updated at this time or later. The point is that the changes are made
- persistent, e.g. in a log on stable storage, and are added to the
- cached copy of the zone.) If the zone serial number is not explicitly
- updated in a request, a primary name server may update the zone
- serial number when committing each transaction, or periodically,
- after some number of transactions or time has passed, depending on
- policy. The effect of incrementing the serial number periodically
- rather than on each transaction means that a secondary may not detect
- that a zone has been updated as quickly as it otherwise would do. On
- the other hand, updating the serial number periodically makes it pos-
- sible to slow incrementing of the serial number in situations where
- many updates occur close together in time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 12]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-5. RESOLVER BEHAVIOR
-
-
- A resolver provides the application interface to name servers. A
- resolver must enable applications to perform both standard queries
- and updates.
-
- A stub resolver performs no resolution function itself, but must
- either be configured with a list of name servers that provide recur-
- sive service, i.e. name servers that can perform requests on the
- resolver's behalf, or be configured with the names of authoritative
- servers of zones that this resolver is known to be responsible for
- updating.
-
- A full-service resolver traverses the domain name space itself, pos-
- sibly querying several name servers to find the name servers authori-
- tative for the zone to be updated. A full-service resolver performs
- an update operation as follows (adapted from [RFC1034]):
-
- 1. If a resolver has direct access to a name server's authoritative
- data, determine the names (RRNAMEs) associated with all records
- to be updated in the transaction. For each RRNAME, search the
- available zones for the zone which is authoritative for RRNAME.
-
- a) If more than one zone is found, return a response indicat-
- ing that the update request is not restricted to a single
- zone. Exit.
-
- b) If a single authoritative zone is found, perform the update
- transaction in the relevant zone as outlined in Section
- 4.2. Exit.
-
- 2. If the zone is non-local, find the best servers to ask for any
- or all RRNAMEs. If the resolver finds that the RRNAMEs cannot be
- in the same zone, it returns a response indicating that the
- update is not constrained to a single zone and exits.
-
- 3. Send a query to one of the servers for any RRNAME, RRCLASS and
- RRTYPE to be updated in the zone.
-
- 4. Analyze the response:
-
- a) If the response is authoritative, go to step 5
-
- b) If the response contains better delegation information,
-
-
-
-Expires July 31, 1995 [Page 13]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- cache the delegation information and go to step 2.
-
- c) If the response shows a server failure or other bizarre
- contents, delete the server from the list of servers and go
- back to step 3.
-
- 5. Send an update to an authoritative name server.
-
- 6. Analyze the response:
-
- a) If the response shows a server failure or other bizarre
- contents, delete the server from the list of servers and go
- back to step 5.
-
- b) Otherwise, return the response to the client.
-
- The data structures used to represent the state of a query in pro-
- gress in the resolver are the same as that specified in RFC1034,
- except that the list that represents the resolver's best guess about
- which name servers to ask may include additional information per-
- tinent to updates, e.g. which in a set of authoritative name servers
- accept update requests for a given zone (some name servers may refuse
- to accept update requests) and the relative performance of the name
- servers (primary may provide better performance than secondaries).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 14]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-6. EXAMPLES
-
- A wide range of update functions can be achieved using a combination
- of the four update operations. To illustrate this, we use a simple
- zone consisting of the following records:
-
-
- xyz.com. SOA ns.xyz.com sysadm.xyz.com
- ( ... )
- NS ns.xyz.com.
-
- ns.xyz.com. A 128.96.33.22
-
- foo.xyz.com. A 128.96.33.33
- A 128.96.34.34
-
-
- For example, one of the A records belonging to foo.xyz.com can be
- modified by first deleting it and adding the new.
-
-
- DELETE foo.xyz.com A 128.96.33.33
-
- ADD foo.xyz.com A 128.96.44.44
-
-
- Both ADD or ADDEXIST would work in the above example to add the
- replacement record.
-
- The canonical name of a host can be changed from "foo" to "bar" and
- the old name "foo" made an alias, by sending an update transaction
- consisting of the following three operations:
-
-
- DELETE foo.xyz.com A 128.96.33.33
- foo.xyz.com A 128.96.34.34
-
- ADDEXIST foo.xyz.com CNAME bar.xyz.com
-
- ADDNEW bar.xyz.com A 128.61.44.33
-
-
-
- Alternatively, the A records belonging to "foo" need not be individu-
- ally deleted. The wildcard data field can be used to delete all
-
-
-
-Expires July 31, 1995 [Page 15]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- records associated with "foo" as follows:
-
-
- DELETE foo.xyz.com A *
-
-
- Also, both of the above add operations could be replaced by ADD.
- However, the existence checks would not then be applied.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 16]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-7. SERIAL RESOURCE RECORD
-
-
- A new resource record is defined that can be used to serialize update
- requests. Serialization is needed if updates can be concurrent or the
- update is dependent on the database being in a certain state. In
- particular, serialisation may be necessary to protect against dupli-
- cate messages. Duplicate messages arise when the transport protocol
- used does not guarantee otherwise, or when resolvers retransmit mes-
- sages because the transport protocol is unreliable. Also, malicious
- clients may deliberately replay old update requests.
-
- In general, to serialize requests, a token needs to be associated
- with the set of records to be updated. This token must be set to a
- different value on each update. The SERIAL resource record is defined
- to hold this token and to indicate the set of records associated with
- the token. The SERIAL record has the same name, class, and TTL
- values as the records to be protected. The name may contain the wild-
- card label in which case the SERIAL record covers all records in the
- zone (of the type specified in the data field), and can be used to
- serialize updates at the granularity of a zone. The data field of
- the record contains the type of the records protected and the token
- itself. The type may be any valid record type, or it may contain type
- ANY which means that the token covers all records associated with the
- name specified. The token is a 64-bit number (the exact definition of
- which is to be discussed below).
-
- The data field of the record is as follows:
-
-
-
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RR type covered |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- | token |
- | |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
- To update the SERIAL record, a client MUST delete the current record
- explicitly and then add the new record with the new token value. The
-
-
-
-Expires July 31, 1995 [Page 17]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- SERIAL record is the only record where the use of the wildcard data
- field when deleting records is invalid. This restriction ensures
- that the update of the token is itself serialized, by making sure
- that the change from the current token value to the new token value
- is done in a mutually exclusive manner.
-
- For example, given a zone containing a SERIAL RR as follows:
-
-
- xyz.com. SOA ns.xyz.com sysadm.xyz.com
- ( ... )
- NS ns.xyz.com.
-
- ns.xyz.com. A 128.96.33.22
-
- foo.xyz.com. SERIAL A 2157449756503
- A 128.96.33.33
- A 128.96.34.34
-
-
- Updates to the A records would be serialized by using the following
- operations:
-
-
- DELETE foo.xyz.com SERIAL A 2157449756503
- foo.xyz.com A *
-
- ADD foo.xyz.com SERIAL A 7575470909833451
- foo.xyz.com A 128.96.44.44
- foo.xyz.com A 128.96.55.55
-
-
- FOR DISCUSSION: One approach would be to define the token as a random
- number. However, update serialization is only as good as the random
- numbers generated. If clients cannot be trusted to generate unique
- random numbers or it is too expensive to do so, an alternative
- approach is to define the token as a sequence number. This approach
- is cheap to implement, but does require that the name server inter-
- pret the value of the data field of the SERIAL RR added to determine
- that it is appropriately set. Another approach is to have the server
- responsible for generating the next token (in any way it liked). This
- also requires the server to interpret the data field of the SERIAL
- RR.
-
-
-
-
-
-Expires July 31, 1995 [Page 18]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-8. SECURITY CONSIDERATIONS
-
-
- DNS updates must be able to be made secure. The security mechanism
- must provide data origin authentication, data integrity and protec-
- tion against replay. Data confidentiality is not required.
-
- The signature records defined in [DNSSEC] can be used to ensure that
- each set of records of a particular name, type and class are updated
- by an entity that has the appropriate authority. The signature
- record is updated along with the associated records in an update
- transaction. The SIG RR must sign all records associated with a name,
- class and type, not only those updated in the request. The "time
- signed" timestamp in the SIG record may be used to protect against
- replay if it is defined that, when updated, it must have a value
- greater than the current value and be set to a time not too far in
- the future.
-
- Note that a signature record only covers records of a particular
- name, class and type. Thus, while the integrity of each set of
- records of the same name, class and type updated in a transaction can
- be assured, the integrity of a set of updates records with different
- names or types is not. To ensure integrity of the entire message, a
- network layer security protocol should be used if available. Alterna-
- tively, a SIG RR signing the entire message can be placed at the end
- of the last section of a message as explained in [DNSSEC]. If SIG
- records are not used to authenticate individual updates, the SERIAL
- record will need to be used to ensure against replay.
-
- Note that a SIG RR is not only used to authenticate an update
- request, but is stored along with the authenticated data in DNS to
- authenticate subsequent queries for the data.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 19]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-9. OPEN ISSUES
-
-
-
- 1. Should non-recursive updates perform referrals when an update is
- sent to a non-authoritative server?
-
-
- This is a bit less clean for updates than for queries, since
- multiple nodes can be specified in an atomic transaction. (A
- referral need only be to one of the nodes specified - any one
- will do.
-
- On the other hand, using queries to locate authoritative servers
- before sending an update is likely to be less efficient than
- using updates only. However, caching of queries should alleviate
- this.
-
- The usefulness of having updates perform referrals is not clear:
-
- a) While updates need to be reliable and hence might be car-
- ried using TCP, the recommended approach to get referrals
- is UDP.
-
- b) As a practical matter, it cannot be required that all name
- servers in DNS support dynamic updates. Thus, queries will
- always have to be used as the fallback mechanism for locat-
- ing the authoritative name servers for a dynamic zone.
-
- This document as it stands does not specify referrals.
-
-
-
-10. ACKNOWLEDGEMENTS
-
-
- We would like to thank the DNSIND working group for their valuable
- input, in particular, Donald Eastlake.
-
-
-
-11. REFERENCES
-
-
-
-
-
-
-Expires July 31, 1995 [Page 20]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
- [RFC1034]
- P. Mockapetris, "Domain Names - Concepts and Facilities", RFC
- 1034, USC/Information Sciences Institute, November 1987.
-
- [RFC1035]
- P. Mockapetris, "Domain Names - Implementation and Specifica-
- tion", RFC 1035, USC/Information Sciences Institute, November
- 1987.
-
- [DNSSEC]
- Donald E. Eastlake and Charles W. Kaufman, "Domain Name System
- Protocol Security Extensions", Internet Draft, March 1994,
- <draft-ietf-dnssec-secext-03.txt>.
-
- [IXFR]M. Ohta, "Incremental Zone Transfer", Internet Draft, November
- 1994.
-
- [NOTIFY]
- P. Vixie, "Notify: a mechanism for prompt notification of
- authority zone changes", Internet Draft, November 1994, <draft-
- ietf-dnsind-notify-00.txt>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 21]
-
-
-
-
-
-\fINTERNET-DRAFT Dynamic DNS Updates January 1995
-
-
-Authors' Addresses
-
-
- Susan Thomson
- Bellcore
- 445 South Street
- Morristown, NJ 07960
- Phone: (201) 829-4514
- email: set@thumper.bellcore.com
-
- Yakov Rekhter
- T.J. Watson Research Center IBM Corporation
- P.O. Box 740, H3-D40,
- Yorktown Heights, NY 10598
- Phone: (914) 784-7361
- email: yakov@watson.ibm.com
-
- Jim Bound
- Digital Equipment Corporation
- 110 Spitbrook Road ZK3-3/U14
- Nashua, NH 03062-2698
- Phone: (603) 881-0400
- email: bound@zk3.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires July 31, 1995 [Page 22]
-
-
+++ /dev/null
-
-This Internet-Draft was deleted. For more information, send a message to
-
- Internet-Drafts@cnri.reston.va.us
-
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Alexander
-Request for Comments: 1533 Lachman Technology, Inc.
-Obsoletes: 1497, 1395, 1084, 1048 R. Droms
-Category: Standards Track Bucknell University
- October 1993
-
-
- DHCP Options and BOOTP Vendor Extensions
-
-Status of this Memo
-
- This RFC 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" for the standardization state and status
- of this protocol. Distribution of this memo is unlimited.
-
-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. This
- document will be periodically updated as new options are defined.
- Each superseding document will include the entire current list of
- valid options.
-
- 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
- extensions.
-
-Table of Contents
-
- 1. Introduction .............................................. 2
- 2. BOOTP Extension/DHCP Option Field Format .................. 2
- 3. RFC 1497 Vendor Extensions ................................ 3
- 4. IP Layer Parameters per Host .............................. 10
- 5. IP Layer Parameters per Interface ........................ 13
- 6. Link Layer Parameters per Interface ....................... 16
- 7. TCP Parameters ............................................ 17
- 8. Application and Service Parameters ........................ 18
-
-
-
-Alexander & Droms [Page 1]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- 9. DHCP Extensions ........................................... 23
- 10. Extensions ................................................ 27
- 11. Acknowledgements .......................................... 28
- 12. References ................................................ 28
- 13. Security Considerations ................................... 19
- 14. Authors' Addresses ........................................ 30
-
-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.
-
-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. In the case of some variable-length
- options the length field is a constant but must still be specified.
-
-
-
-
-Alexander & Droms [Page 2]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- Any options defined subsequent to this document should 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
- 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.
-
-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 3]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 signed 32-bit integer.
-
- 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 4]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 5]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 6]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 7]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 8]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 9]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 10]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 11]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 12]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 13]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 14]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 15]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-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 |
- +-----+-----+-----+
-
-
-
-
-
-
-
-Alexander & Droms [Page 16]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 |
- +-----+-----+-----+
-
-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 |
- +-----+-----+-----+
-
-
-
-
-
-
-
-Alexander & Droms [Page 17]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 |
- +-----+-----+-----+
-
-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 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-
-
-
-Alexander & Droms [Page 18]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-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 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:
-
-
-
-Alexander & Droms [Page 19]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- 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 | ... | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-
-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 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 20]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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).
-
- The code for this option is 46. The length of this option is always
- 1.
-
- Code Len Node Type
- +-----+-----+-----------+
- | 46 | 1 | see above |
- +-----+-----+-----------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 21]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-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 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-Alexander & Droms [Page 22]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-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.
-
- The code for this option is 52, and its length is 1. Legal values
- for this option are:
-
-
-
-
-
-Alexander & Droms [Page 23]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- 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. 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
-
- Code Len Type
- +-----+-----+-----+
- | 53 | 1 | 1-7 |
- +-----+-----+-----+
-
-9.5. 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 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.
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 24]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- The code for this option is 54, and its length is 4.
-
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 54 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.6. 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.7. 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 25]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-9.8. 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.9. 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.10. 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 26]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-9.11. Class-identifier
-
- This option is used by DHCP clients to optionally identify the type
- and configuration of a DHCP client. The information is a string of n
- octets, interpreted by servers. Vendors and sites may choose to
- define specific 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).
-
- The code for this option is 60, and its minimum length is 1.
-
- Code Len Class-Identifier
- +-----+-----+-----+-----+---
- | 60 | n | i1 | i2 | ...
- +-----+-----+-----+-----+---
-
-9.12. 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 consist of a type-value pair, similar to the
-
- It is expected that this field will typically contain a hardware type
- and hardware address, but this is not required. Current legal values
- for hardware types are defined in [22].
-
- The code for this option is 61, and its minimum length is 2.
-
- Code Len Type Client-Identifier
- +-----+-----+-----+-----+-----+---
- | 61 | n | t1 | i1 | i2 | ...
- +-----+-----+-----+-----+-----+---
-
-10. Extensions
-
- Additional generic data fields may be registered 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
-
-
-
-Alexander & Droms [Page 27]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- Implementation specific use of undefined generic types (those in the
- range 61-127) may conflict with other implementations, and
- registration is required.
-
-11. Acknowledgements
-
- The authors would like to thank Philip Almquist for his feedback on
- this document. The comments of the DHCP Working Group are also
- gratefully acknowledged. In particular, Mike Carney and Jon Dreyer
- from SunSelect suggested the current format of the Vendor-specific
- Information option.
-
- RFC 1497 is based on earlier work by Philip Prindeville, with help
- from Drew Perkins, Bill Croft, and Steve Deering.
-
-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.
-
-
-
-
-
-Alexander & Droms [Page 28]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
- [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
- Wollongong Group, August 1990.
-
- [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
- December 1983.
-
- [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
- DECWRL, Stanford University, November 1990.
-
- [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
- Xerox PARC, September 1991.
-
- [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 1340,
- USC/Information Sciences Institute, July 1992.
-
-13. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-
-Alexander & Droms [Page 29]
-\f
-RFC 1533 DHCP Options and BOOTP Vendor Extensions October 1993
-
-
-14. Authors' Addresses
-
- Steve Alexander
- Lachman Technology, Inc.
- 1901 North Naper Boulevard
- Naperville, IL 60563-8895
-
- Phone: (708) 505-9555 x256
- EMail: stevea@lachman.com
-
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms [Page 30]
-\f
\ No newline at end of file
projects / thirdparty / dhcp.git / commitdiff
