mir/isc-dhcp
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-08-30 22:05:23 +00:00
Code Issues Releases Wiki Activity

New option docs; remove obsolete docs

Browse Source
This commit is contained in:
Ted Lemon
1996-02-26 09:37:16 +00:00
parent 445b21f78c
commit 05da297846
8 changed files with 283 additions and 3397 deletions
Download Patch File Download Diff File Expand all files Collapse all files

188
doc/dhc-minutes-94dec.txt
View File

@@ -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.

267
doc/dns-minutes-93nov.txt
View File

@@ -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

110
doc/draft-ietf-dhc-new-options-00.txt Normal file
View File

@@ -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]

62
doc/draft-ietf-dhc-options-04.txt Normal file
View File

@@ -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

111
doc/draft-ietf-dhc-options-opt127-01.txt Normal file
View File

@@ -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]

1254
doc/draft-ietf-dnsind-dynDNS-00.txt
View File

File diff suppressed because it is too large Load Diff

5
doc/draft-ohta-dynamic-dns-00.txt
View File

@@ -1,5 +0,0 @@
This Internet-Draft was deleted. For more information, send a message to
Internet-Drafts@cnri.reston.va.us

1683
doc/rfc1533.txt
View File

File diff suppressed because it is too large Load Diff