diff options
| author | Ted Lemon <source@isc.org> | 1996-02-26 09:37:16 +0000 |
|---|---|---|
| committer | Ted Lemon <source@isc.org> | 1996-02-26 09:37:16 +0000 |
| commit | 05da297846b0e057cb52c1ef2bfd93d59e7090e4 (patch) | |
| tree | 0f684597780164c6835a5cc6172261cff154c24c /doc | |
| parent | 445b21f78cf3be4e87a2610e1aef3f2e308ffc99 (diff) | |
| download | isc-dhcp-05da297846b0e057cb52c1ef2bfd93d59e7090e4.tar.gz | |
New option docs; remove obsolete docs
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/dhc-minutes-94dec.txt | 188 | ||||
| -rw-r--r-- | doc/dns-minutes-93nov.txt | 267 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-new-options-00.txt | 110 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-options-04.txt | 62 | ||||
| -rw-r--r-- | doc/draft-ietf-dhc-options-opt127-01.txt | 111 | ||||
| -rw-r--r-- | doc/draft-ietf-dnsind-dynDNS-00.txt | 1254 | ||||
| -rw-r--r-- | doc/draft-ohta-dynamic-dns-00.txt | 5 | ||||
| -rw-r--r-- | doc/rfc1533.txt | 1683 |
8 files changed, 283 insertions, 3397 deletions
diff --git a/doc/dhc-minutes-94dec.txt b/doc/dhc-minutes-94dec.txt deleted file mode 100644 index a1beb766..00000000 --- a/doc/dhc-minutes-94dec.txt +++ /dev/null @@ -1,188 +0,0 @@ - -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. - diff --git a/doc/dns-minutes-93nov.txt b/doc/dns-minutes-93nov.txt deleted file mode 100644 index aa028020..00000000 --- a/doc/dns-minutes-93nov.txt +++ /dev/null @@ -1,267 +0,0 @@ - -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 - diff --git a/doc/draft-ietf-dhc-new-options-00.txt b/doc/draft-ietf-dhc-new-options-00.txt new file mode 100644 index 00000000..adf332a5 --- /dev/null +++ b/doc/draft-ietf-dhc-new-options-00.txt @@ -0,0 +1,110 @@ + +Network Working Group R. Droms +INTERNET DRAFT Bucknell University +Obsoletes: February 1996 + Expires August 1996 + + + Procedure for Defining New DHCP Options + <draft-ietf-dhc-new-options-00.txt> + +Status of this memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + To learn the current status of any Internet-Draft, please check the + ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + +Abstract + + The Dynamic Host Configuration Protocol (DHCP) provides a + framework for passing configuration information to hosts on a TCP/IP + network. Configuration parameters and other control information are + carried in tagged data items that are stored in the 'options' field + of the DHCP message. The data items themselves are also called + "options." + + This document describes the procedure for defining new DHCP options. + The procedure will guarantee that: + + * allocation of new option numbers is coordinated from a single + authority, + * new options are reviewed for technical correctness and + appropriateness, and + * documentation for new options is complete and published. + + + + + + + +Droms [Page 1] + +DRAFT Procedure for Defining New DHCP Options February 1996 + + +Procedure + + The author of a new DHCP option will follow these steps to obtain + acceptance of the option as a part of the DHCP Internet Standard: + + 1. The author devises the new option. + 2. The author requests a number for the new option from IANA. + 3. The author documents the new option, using the newly obtained + option number, as an Internet Draft. + 4. The author submits the Internet Draft for review through the IETF + standards process as defined in "Internet Official Protocol + Standards" (STD 1). The new option will be submitted for eventual + acceptance as an Internet Standard. + 5. The new option progresses through the IETF standards process; the + new option will be reviewed by the Dynamic Host Configuration + Working Group (if that group still exists), or as an Internet + Draft not submitted by an IETF working group. + 6. If the new option fails to gain acceptance as an Internet + Standard, the assigned option number will be returned to IANA for + reassignment. + +Acceptance and publication + + If this procedure is accepted, it will be added to the DHCP options + specification as an Appendix. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Ralph Droms + Computer Science Department + 323 Dana Engineering + Bucknell University + Lewisburg, PA 17837 + + Phone: (717) 524-1145 + EMail: droms@bucknell.edu + + + + + + + + + + + +Droms [Page 2] + diff --git a/doc/draft-ietf-dhc-options-04.txt b/doc/draft-ietf-dhc-options-04.txt new file mode 100644 index 00000000..ad5937a4 --- /dev/null +++ b/doc/draft-ietf-dhc-options-04.txt @@ -0,0 +1,62 @@ + + +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 + diff --git a/doc/draft-ietf-dhc-options-opt127-01.txt b/doc/draft-ietf-dhc-options-opt127-01.txt new file mode 100644 index 00000000..aaa90ad3 --- /dev/null +++ b/doc/draft-ietf-dhc-options-opt127-01.txt @@ -0,0 +1,111 @@ + + +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] + +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] + diff --git a/doc/draft-ietf-dnsind-dynDNS-00.txt b/doc/draft-ietf-dnsind-dynDNS-00.txt deleted file mode 100644 index 1bbfdad8..00000000 --- a/doc/draft-ietf-dnsind-dynDNS-00.txt +++ /dev/null @@ -1,1254 +0,0 @@ - - - - - - -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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - - - - - INTERNET-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] - - diff --git a/doc/draft-ohta-dynamic-dns-00.txt b/doc/draft-ohta-dynamic-dns-00.txt deleted file mode 100644 index f361d776..00000000 --- a/doc/draft-ohta-dynamic-dns-00.txt +++ /dev/null @@ -1,5 +0,0 @@ - -This Internet-Draft was deleted. For more information, send a message to - - Internet-Drafts@cnri.reston.va.us - diff --git a/doc/rfc1533.txt b/doc/rfc1533.txt deleted file mode 100644 index 39677787..00000000 --- a/doc/rfc1533.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] -
\ No newline at end of file |