Internet Engineering Task Force J. Bound
INTERNET DRAFT Compaq Computer Corp.
DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6exts-11.txt Sun Microsystems, Inc
C. Perkins
Nokia Research Center
5 May 2000
Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-dhcpv6exts-12.txt
Status of This Memo
This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcp-v6@bucknell.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
The Dynamic Host Configuration Protocol for IPv6 [4] (DHCP) provides
a framework for passing configuration information to hosts on
a TCP/IP network. Configuration parameters and other control
information are carried in typed data items that are stored in the
``extensions'' field of the DHCP message. The data items themselves
are also called ``extensions.'' This document specifies the initial
set of DHCP extensions, which will be periodically updated as new
extensions are defined until this document reaches proposed standard.
Bound, Carney, Perkins Expires 5 November 2000 [Page i]
Internet Draft DHCP Extensions for IPv6 5 May 2000
After that time, individual extensions will be defined in separate
documents, to be reviewed by the DHCP WG (if it still exists) and the
IESG.
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. DHCP Extension Field Format 2
3. DHCP Relay Considerations 4
4. Releasable Resource Extensions 4
4.1. IP Address Extension . . . . . . . . . . . . . . . . . . 4
4.1.1. IP Address Lifetimes . . . . . . . . . . . . . . 8
4.1.2. Client Considerations . . . . . . . . . . . . . . 9
4.1.3. Server Considerations . . . . . . . . . . . . . . 11
5. General Extensions 14
5.1. IEEE 1003.1 POSIX Timezone Extension . . . . . . . . . . 14
5.1.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 15
5.1.2. An Example: . . . . . . . . . . . . . . . . . . . 16
5.2. Domain Name Server Extension . . . . . . . . . . . . . . 17
5.3. Domain Name Suffix Extension . . . . . . . . . . . . . . 17
5.4. Service Location Protocol Directory Agent Extension . . . 17
5.5. Service Location Protocol Service Scope Extension . . . . 19
5.6. Network Time Protocol Servers Extension . . . . . . . . . 22
5.7. Network Information Service (NIS) Domain Name Extension . 22
5.8. Network Information Service (NIS) Servers Extension . . . 23
5.9. Network Information Service V2 (NIS+) Domain Extension . 23
5.10. Network Information Service V2 (NIS+) Servers Extension . 23
5.11. TCP-specific Extensions . . . . . . . . . . . . . . . . . 24
5.11.1. TCP Keepalive Interval Extension . . . . . . . . 24
6. DHCP-specific Extensions 24
6.1. Maximum DHCP Message Size Extension . . . . . . . . . . . 25
6.2. DHCP Retransmission and Configuration Parameter Extension 25
6.3. Extension Request Extension (ERE) . . . . . . . . . . . . 26
6.3.1. Client Considerations . . . . . . . . . . . . . . 26
6.3.2. Server Considerations . . . . . . . . . . . . . . 26
6.4. Subnet Prefix Extension . . . . . . . . . . . . . . . . . 26
6.4.1. Client Considerations . . . . . . . . . . . . . . 27
6.4.2. Server Considerations . . . . . . . . . . . . . . 27
6.5. Platform Specific Information Extension . . . . . . . . . 27
Bound, Carney, Perkins Expires 5 November 2000 [Page ii]
Internet Draft DHCP Extensions for IPv6 5 May 2000
6.6. Platform Class Identifier Extension . . . . . . . . . . . 28
6.6.1. Client Considerations . . . . . . . . . . . . . . 29
6.6.2. Server Considerations . . . . . . . . . . . . . . 29
6.7. User Class Identifier Extension . . . . . . . . . . . . . 29
6.7.1. Client Considerations . . . . . . . . . . . . . . 30
6.7.2. Server Considerations . . . . . . . . . . . . . . 30
6.8. Reconfigure Multicast Address Extension . . . . . . . . . 30
6.9. Renumber DHCP Server Address Extension . . . . . . . . . 31
6.10. Client-Server Authentication Extension . . . . . . . . . 31
6.11. Client Key Selection Extension . . . . . . . . . . . . . 32
7. Security Considerations 33
7.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 33
7.2. Default Authentication Algorithm . . . . . . . . . . . . 33
8. IANA Considerations 34
9. Acknowledgements 35
10. Full Copyright Statement 35
Chair's Address 39
Authors' Addresses 39
1. Introduction
This document specifies extensions for use with the Dynamic Host
Configuration Protocol for IP version 6 (DHCP). The DHCP message
formats are described in the DHCP protocol document [4]. In this
document, several words are used to signify the requirements of the
specification, in accordance with RFC 2119 [5]. These words (MUST,
SHOULD, MAY, MUST NOT, etc) are often capitalized.
This document defines the overall format of information in the
``extensions'' field of DHCP messages. The extensions defined
within this document specify a generalized way to distribute
information useful to a wide class of devices, operating systems
and configurations. Sites with a DHCP server that is shared among
heterogeneous clients may choose to define other, site-specific
formats for the use of the ``extensions'' field.
Section 2 of this memo describes the formats of DHCP extensions.
Information on registering new extensions is contained in section 8.
The other sections organize the format descriptions of various
extensions according to their general type, as follows:
o Releasable Resource Extensions (section 4)
Bound, Carney, Perkins Expires 5 November 2000 [Page 1]
Internet Draft DHCP Extensions for IPv6 5 May 2000
o General Extensions (section 5)
* TCP-specific Extensions
o DHCP-specific Extensions (section 6)
Future applications will make extensive use of an ever-increasing
number and variety of network services. It is expected that client
requirements for locating these network services will be satisfied
by the Service Location Protocol [20], and not the DHCP. The DHCP
is expected to be used for the kinds of configuration that enable
clients to become fully functional as self-contained network
entities.
2. DHCP Extension Field Format
Extensions may be fixed length or variable length. All extensions
begin with a ``Type'' field, which is a an two octet unsigned
network-order integer that uniquely identifies the extension. Every
extension has a two octet unsigned network-order integer ``Length''
field following the ``Type'' field. The ``Length'' field contains
the number of octets of extension data that follow the ``Length''
field. Thus, the ``Length'' field value does not include the number
of octets needed to carry the ``Type'' and ``Length'' fields. For
some extensions, the ``Length'' field is always the same number, but
it MUST still be specified. There is no requirement for alignment of
data fields within existing DHCP extensions. Any extensions defined
subsequent to this document MUST contain a two-octet ``Length'' field
even if the value it would contain would always be fixed or zero.
Unrecognized extensions MUST be silently ignored by skipping over the
number of octets specified in the ``Length'' field, and processing
continued for subsequent extensions. Unless and until specified
otherwise by use of the ``Maximum DHCP message size'' extension
(section 6.1), DHCP implementations MUST assume that that the maximum
DHCP message size including extensions is limited to 1280 octets.
All multi-octet quantities are in network-order.
Extension Type 0 (zero) is reserved.
There can be 65535 different extensions, which are divided up into
the following ranges:
Releasable Resource Range (1--8192)
Extensions carrying data which identifies a resource which is
leased by the server to a client for a finite period of time
Bound, Carney, Perkins Expires 5 November 2000 [Page 2]
Internet Draft DHCP Extensions for IPv6 5 May 2000
known as a ``lease''. The client agrees to stop using the
resource when the lease expires, and the server guarantees that
it will not allocate the resource to another client until the
lease expires or the client signals that it is done using the
resource.
A server MUST NOT return a releasable resource to a client
unless the client explicitly requests an instance of that
resource from the server. This requirement ensures that only
clients capable of managing a releasable resource receive them.
A client MUST remember which server allocated the client a
releasable resource, in order to contact that server to extend
the lease on the resource or release the resource back to the
server when it is finished with it.
As of this writing, the only example of a type of releasable
resource is an IP address, carried in the ``IP Address
Extension'' (section 4.1). See the ``DHCP for IPv6'' companion
document ([4]) for more details.
General Range (8193-49152)
Extensions in this range are informational in nature, and may
point to resources which may be shared by any number of nodes.
General extension proposals are reviewed by the DHC WG and IESG
for general usefulness to the IETF community at large.
Servers MAY return any general range extension to clients if
administrative policy requires it; however, a server SHOULD
only return general extensions if the client requests them
using the ``Extension Request Extension'' (ERE) (section 6.3).
Examples of general extensions include Domain Name Service
parameters, Network Time Protocol (NTP, [14]) parameters,
those carrying information pertaining to the DHCP, such
as the ``Maximum DHCP Message Size'' (section 6.1), ``DHCP
Retransmission and Configuration Parameter'' (section 6.2, and
``Platform Specific Information'' (section 6.5) Extensions.
Site-specific Range (49153--65535)
Extensions in this range are reserved for use by Site managers
(administrators of the DHCP domain). Their type and content is
entirely up to the administrator. DHCP implementations SHOULD
permit the definition of site-specific extensions, including
such information as data type and format. Note that both
client and server implementations MAY need to be configured in
order to properly exchange site extensions.
Bound, Carney, Perkins Expires 5 November 2000 [Page 3]
Internet Draft DHCP Extensions for IPv6 5 May 2000
A server SHOULD only return site-specific extensions to the
client if it explicitly requests them using the ``Extension
Request Extension'' (ERE) (section 6.3).
All of the extensions described in this document MUST also have
their default values specified, if any. Whenever an extension is
received as part of a DHCP message, any reserved fields of the
message MUST be ignored, and processing continued as if the reserved
fields were zero. Typically, the value of the ``Type'' field is
shown directly in the format illustration, and for some fixed-length
extensions the value of the ``Length'' field is also shown in the
format illustration for the extension.
3. DHCP Relay Considerations
The DHCP Relay MUST NOT change any information in any DHCP Extension
fields. All Extension information flows between DHCP Server and DHCP
Client without modification by any Relay.
4. Releasable Resource Extensions
Releasable resource extensions contain data identifying a specific
resource leased by the server to the client for a specific period of
time known as a ``lease''. Because the allocation of such extensions
requires extension-specific management of the lease by both the
client and the server, these extensions MUST only be returned to the
client if they have been explicitly requested by the client.
How the resource and its lease is managed is resource-specific
(extension-specific).
A client MUST remember in non-volatile storage which server allocated
which releasable resource, in order to appropriately manage the lease
associated with that resource.
As of this writing, the only example of a releasable resource is
an IP address, which is carried in the ``IP Address Extension'',
discussed below.
4.1. IP Address Extension
The IP address extension is used by clients and servers to refer to
a particular IP address and related information such as the status
of the host name associated with the IP address. All information
relevant to a particular IP address allocation has been collected
together within the ``IP address'' extension.
Bound, Carney, Perkins Expires 5 November 2000 [Page 4]
Internet Draft DHCP Extensions for IPv6 5 May 2000
The ``lease'' feature of the ``IP address'' extension is implemented
by the ``Preferred lifetime'' and ``Valid lifetime'' fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status |C|I|L|Q|A|P| reserved |scope| prefix-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| IP address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) preferred lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) valid lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) DNS name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
Length (unsigned integer, variable) The length of the Extension
in octets.
status The receiver's result of its attempt to honor the
sender's request.
C If the ``C'' bit is set, the field containing the IP
address is present in the extension.
I If the ``I'' bit is set, the client is informing the
server that the IP address listed *was not* received from
DHCP (e.g. received from Stateless Autoconfiguration,
or manually configured). The ``I'' bit MUST NOT be set
if the ``C'' bit is not set (IP address field MUST be
present). The ``L'' bit MUST NOT be set if the ``I'' bit
is set.
L If the ``L'' bit is set, the preferred and valid
lifetimes are present in the extension.
Q If the ``Q'' bit is set, the fields included by the
client are required, and must be made available by the
server or else the extension must be rejected.
Bound, Carney, Perkins Expires 5 November 2000 [Page 5]
Internet Draft DHCP Extensions for IPv6 5 May 2000
A If the ``A'' bit is set, the client requests that
the server updates DNS with a new AAAA/A6 record, as
specified by the client's FQDN.
P If the ``P'' bit is set, the client requests that the
server updates DNS with a new PTR record, as specified by
the client's FQDN.
reserved MUST be zero.
scope
This 3-bit field is used by the client to request an IP
address of a certain scope. The 3 bits form a number
(0--7) which can have the following settings:
0 Don't Care
1 Globally-scoped address
2 Site local-scoped address
3 reserved
4 reserved
5 reserved
6 reserved
7 reserved
prefix-len
If the IP address field is present (the ``C'' bit is
set), a non-zero prefix-len is the number of left-most
bits of the IP address which make up the subnet prefix.
Otherwise, if the ``C'' bit is not set, prefix-len MUST
be zero. The prefix-len field is 7-bits in length.
IP address
The IP address to be conveyed to the receiver from the
sender. (16 octets long).
preferred lifetime
The preferred lifetime of the IP address in seconds.
valid lifetime
The valid lifetime of the IP address in seconds.
Bound, Carney, Perkins Expires 5 November 2000 [Page 6]
Internet Draft DHCP Extensions for IPv6 5 May 2000
DNS name
The DNS name (a string of NVT-ASCII octets) associated
with the IP address.
The following values for the status field are defined within this
document:
0 request granted, no errors
1 IP address is already in use by a different node
2 Extension settings (bit combinations) illegal
3 IP address scope requested is not available
4 IP address requested by client is not available
18 Security parameters failed for this client
20 Resource AAAA/A6 Record Parameter Problem
21 Resource PTR Record Parameter Problem
23 DNS name string error
24 dynDNS Not Implemented
25 Authoritative DNS Server could not be found
33 The name server was unable to interpret the request
due to a format error.
34 dynDNS unavailable at this time (SERVFAIL)
35 Some name that ought to exist, does not exist
(NXDOMAIN)
36 The name server does not support the specified Opcode
(NOTIMP)
37 The name server refuses to perform the specified
operation for policy or security reasons (REFUSED)
38 Some name that ought not to exist, does exist
(YXDOMAIN)
39 Some RRset that ought not to exist, does exist
(YXRRSET)
40 Some RRset that ought to exist, does not exist
(NXRRSET)
41 The server is not authoritative for the zone named in
the Zone Section (NOTAUTH)
42 A name used in the Prerequisite or Update Section
is not within the zone denoted by the Zone Section
(NOTZONE)
Bound, Carney, Perkins Expires 5 November 2000 [Page 7]
Internet Draft DHCP Extensions for IPv6 5 May 2000
Status values 33 through 42 are described more fully within Dynamic
Updates to DNS (RFC 2136 [21]). Up-to-date values for the values
of the status field are specified in the most recent ``Assigned
Numbers'' document [17].
The DNS name can be a host name, which does not contain the ``.''
ASCII character as a separator between DNS hierarchy components.
Any name containing the ``.'' is treated as a Fully Qualified
Domain Name (FQDN). The length of the DNS name may be determined by
subtracting, from the Length, the length of those fixed length fields
which are present.
If the ``Q'' bit is set, the values or actions requested by the C, I,
L, A, P bits and the scope field are required, and MUST be provided,
or the extension MUST be rejected with the appropriate ``status''
field value, indicating the reason why the server was unable to
fulfill the required extension attributes. The ``Q'' bit is NEVER
used by the server in ``IP address'' extensions it generates.
A DHCP client can include an IP address in its IP Address extension
and set the ``I'' bit and the ``A'' bit and/or ``P'' bit to ask the
DHCP Server to use the information contained in the extension to
update the DNS on the client's behalf. This would be done for IP
addresses obtained by a method other than the DHCP, such as Stateless
Address Autoconfiguration, RFC 2462 [19].
If the client wishes to have its FQDN associated with one of several
existing IP addresses which it has received from the DHCP Server, the
client MUST supply that IP address in the IP address extension along
with the FQDN.
By default, the client SHOULD update the AAAA/A6 (See [7] for
information about the A6 record type) record, and the server SHOULD
update the PTR record. The IP Address extension permit clients and
servers to use a different behavior than the default through the use
of the 'Q' and 'A' bits and associated fields.
4.1.1. IP Address Lifetimes
The lifetime value contained in the ``preferred'' and ``valid''
fields is a value relative to when the sender sent the message
containing the ``IP address'' extension. The receiver adds these
times to the current clock time in order to determine the absolute
times for the ``preferred'' and ``valid'' lifetimes.
Bound, Carney, Perkins Expires 5 November 2000 [Page 8]
Internet Draft DHCP Extensions for IPv6 5 May 2000
4.1.2. Client Considerations
Sent in a DHCP Request Message
In a DHCP Request message (for each IP address extension), a
client MUST initialize the ``status'' field value to zero.
A client may include multiple IP Address extensions in a single
DHCP Request, in order to request as many IP addresses of
varying scopes or subnet prefixes as it requires.
In a DHCP Request (for each address extension), a client MAY:
o Request that any IP address of a specific scope be
returned. The client does this by setting the scope
value to the desired value. The ``C'' bit and prefix-len
fields MUST NOT be set, as the client is not requesting a
particular IP address.
o Request the lease of some IP address on a specific network
(subnet prefix) or a specific IP address (interface ID
specified). The client does this by setting the ``C'' bit
and including the desired information in the ``IP address''
and ``prefix-len'' fields in the extension. Note that
the client MUST set the prefix-len field to the number of
left-most bits representing the subnet prefix, even if it
is requesting a specific IP address.
o Ask that the IP address returned have the ``preferred''
and ``valid'' lifetimes suggested by the client. The
client does this by setting the ``L'' bit and including the
desired lifetime values in the ``preferred'' and ``valid''
lifetime fields. The client MUST use the lifetimes
returned by the DHCP server.
o Request that the DHCP server perform a DNS AAAA/A6 record
update (``A'' bit is set) and/or DNS PTR record update
(``P'' bit is set) for either an IP address the server will
assign (``I'' bit not set) or the IP address the client
has provided (``I'' bit set) which it acquired through a
means other than DHCP, for the host name or Fully Qualified
Domain Name (FQDN) the client has provided.
o Specify that the attributes of the request carried by the
``IP address'' extension are required by the client by
setting the ``Q'' bit.
Bound, Carney, Perkins Expires 5 November 2000 [Page 9]
Internet Draft DHCP Extensions for IPv6 5 May 2000
Received in a DHCP Reply Message in response to a DHCP Request
When the client receives an IP address extension within a DHCP
Reply message, it first validates that the bits / fields set in
the extension are valid. If they aren't, the client generates
a DHCP Release message including the ill-formed IP address
extension, and sets the ``status'' field to 2, and sends it to
the server. If the extension is valid, the client inspects
the ``status'' field value to see whether the client's request
has been granted. If the status is nonzero, the client should
log the error, and display the error condition for action by
the user and/or the network administrator. Non-zero status
almost always indicates that the client will be need to modify
its request before it could be satisfied by the replying DHCP
server, or alternatively that the replying DHCP server will
need to be given updated configuration information for the
client.
Upon reception of a new IP address, the client MUST perform
Duplicate Address Detection (DAD) as specified in RFC
2462 [19]. If the IP address has already been allocated to the
client and the client is merely requesting a renewal of the
lifetime of the IP address, the client MUST NOT perform DAD, as
it is using this IP address. If the client finds that the new
IP address is in use by another node, the client forms a DHCP
Release message including the IP address extension containing
the in-use IP address, and sets the ``status'' field value
to 1, and sends the Release to the DHCP server.
If the client receives an IP address with zero valid lifetime
and:
- The DHCP Reply message has been authenticated, the client
MUST immediately discontinue using that IP address.
- The DHCP Reply message has no authentication, the client
sets the valid lifetime for the address to 2 hours.
When the preferred lifetime of an IP address leased from the
DHCP server is 80% exhausted, the client SHOULD begin sending
DHCP requests to the server requesting a renewal of the lease
on that IP address. If the client is unsuccessful at its
attempts and the valid lifetime expires, the client MUST
immediately stop using that IP address.
Sent in a DHCP Release Message
A client sends IP address extension(s) in a DHCP Release
message when:
Bound, Carney, Perkins Expires 5 November 2000 [Page 10]
Internet Draft DHCP Extensions for IPv6 5 May 2000
o It is releasing an IP address back to the server because it
is finished using it.
o It has discovered through DAD that the IP address assigned
by the DHCP server is already being used by a different
node.
o The IP address extension received from the DHCP server has
an illegal combination of bit/fields settings.
o The client wishes to delete the DNS records associated with
the IP address/hostname it will present to the server.
4.1.3. Server Considerations
This section contains information specifying the handling of the ``IP
Address'' extension by DHCP servers.
Note that a server implementation MUST scan its client bindings from
time to time to locate bindings whose lifetimes have expired. Those
bindings SHOULD be deleted, and any DNS operations performed which
are recorded in those bindings MUST be reversed.
The DHCP Advertise Message and the ``IP address'' Extension
The ``IP address'' extension is not used in the DHCP Advertise
message.
Received in a DHCP Request Message
When a server processes an ``IP address'' extension within a
DHCP Request, the server first validates the combination of
bits / fields contained within the extension. If these bits /
fields are set incorrectly, the server generates a DHCP Reply
message, which includes the incorrect IP address extension
from the client's request, with the ``status'' field set to 2,
thereby notifying the client of the error. If the IP address
extension is correct, the server processes the extension as
follows:
o If no IP address field is present, then the client is
requesting that the server allocate an IP address of the
scope identified by the ``scope'' field value. If the IP
address field is present and the ``I'' bit is not set, then
the client is requesting the assignment of:
* A specific IP address (interface ID present)
Bound, Carney, Perkins Expires 5 November 2000 [Page 11]
Internet Draft DHCP Extensions for IPv6 5 May 2000
* Any IP address in the specified network (interface ID
is zero)
The prefix-len field specifies the length of the subnet
prefix in either case.
The server consults its allocation tables and attempts
to select an IP address meeting the client's request
which is appropriate for the link to which the client is
attached. The link can be determined by the contents of
the relay-agent address and prefix-len fields of the DHCP
Request message. If these fields are set, then the client
is off-link, otherwise the client is attached to one of the
same links as the server.
o If the client is requesting that the server update the DNS
on its behalf (either for the IP address the server will
assign or the one it provided which was acquired through
some other means (not the DHCP)), the server makes the
appropriate DNS dynamic update requests and records the
status of the update within the ``status'' field of the IP
address extension it will include in the DHCP Reply message
sent to the client. If the ``Q'' bit is set, then the
server will ensure that the DNS operation has completed
successfully before responding to the client. If the ``Q''
bit is not set, then the server SHOULD register the update
request with the DNS, and MAY immediately return its DHCP
Reply without waiting for the result of the DNS operation.
If the client has requested that the server perform
DNS updates as part of the IP address allocation and
configuration, the server MUST maintain this fact as part
of the client's binding. Then, if the client eventually
releases the IP address by sending a DHCP Release message
or the lifetimes associated with the IP address expire
because the client has not renewed them, the server MUST
perform the reverse service by updating DNS again to remove
the changes it has made on the client's behalf.
o If the client has set the ``Q'' bit, then all fields
within the IP address extension which represent attributes
of interest to the client are requirements, and must be
met, otherwise a DHCP Reply message is generated with the
``status'' field set identifying the portion of the request
the server could not fulfill. Note that if more than one
attribute of the request could not be provided, the server
can only identify one of the problems in the ``status''
field.
Bound, Carney, Perkins Expires 5 November 2000 [Page 12]
Internet Draft DHCP Extensions for IPv6 5 May 2000
Sent in a DHCP Reply Message in response to a DHCP Request
If the server is assigning an IP address (or extending the
lifetimes of an existing IP address binding the client holds),
the server MUST include an IP address extension for the IP
address with the following settings:
- the preferred lifetime
- the valid lifetime
If the DHCP Reply is a response to a DHCP Release, the
lifetimes MUST both be zero.
If the server has performed DNS operations on behalf of the
client, it sets the ``A'' and ``P'' bits if the AAAA/A6 record
and PTR record respectively have been updated by the DNS.
The ``status'' field of the extension MUST be set by the server
indicating the result of the server's attempt to honor the
client's IP address-related request.
If the server receives a DHCP Request from one of its clients
whose address it wishes to invalidate, it can cause the client
to discontinue use of the old address by including valid and
preferred lifetimes with a value of zero.
To perform renumbering, the server will include two IP address
extensions, one to reduce the preferred and valid lifetimes
for the old address, and another to give the client its new
address.
Received in a DHCP Release Message
When a server processes an ``IP address'' extension within a
DHCP Release, the server first validates the combination of
bits / fields contained within the extension. If these bits /
fields are set incorrectly, the server generates a DHCP Reply
message, which includes the incorrect IP address extension
from the client's request, with the ``status'' field set to 2,
thereby notifying the client of the error. If the IP address
extension is correct, the server continues to processes the
extension.
The client generates a DHCP Release for the following reasons:
o Client is finished with the IP address. In this case, the
client has determined it no longer needs the IP address,
and is returning it to the server for use by other clients.
Bound, Carney, Perkins Expires 5 November 2000 [Page 13]
Internet Draft DHCP Extensions for IPv6 5 May 2000
The server removes the IP address from the client's
binding, returning it to the general pool of IP addresses.
If the server has performed DNS operations on behalf of the
client regarding this IP address, the server contacts the
DNS service and deletes the changes it has made regarding
the FQDN/IP address. The server generates a DHCP Reply
including the client's IP address extension, with the
``status'' field set to indicate the results of the release
operation.
o Client has discovered through DAD that the IP address is
already in use by another node. The server MUST mark
the errant IP address as unavailable for assignment, and
SHOULD generate a log message indicating the problem to
the administrator. The server then generates a DHCP Reply
message containing the client's IP address extension, with
the ``status'' field set to 0 to indicate that it has
received the client's release.
o The client has requested that the DHCP server serve as a
DNS update proxy for a name associated with an IP address
that it acquired outside of the DHCP. The server will undo
the DNS operations it performed on behalf of this client,
deletes its knowledge of those operations, and generates
a DHCP Reply message including the client's IP address
extension with the ``status'' field set to indicate the
result of the release operation.
The ``IP Address'' Extension and the DHCP Reconfigure-init
Messages
A server MUST NOT include an ``IP address'' extension in DHCP
Reconfigure or DHCP Reconfigure-init messages. IP addresses
may be changed during the DHCP Request/Reply exchange set in
motion by DHCP Reconfigure-init message(s).
5. General Extensions
General extensions (in the range 8193-49152) are important for many
DHCP clients, and are not specific to any upper-level protocol.
5.1. IEEE 1003.1 POSIX Timezone Extension
This extension allows delivery of timezone information in the form of
a IEEE 1003.1 POSIX Timezone specifier, as detailed in section 5.1.1.
Bound, Carney, Perkins Expires 5 November 2000 [Page 14]
Internet Draft DHCP Extensions for IPv6 5 May 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8193 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE 1003.1 POSIX Timezone string (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a DHCP client finds that the POSIX Timezone extension value is
misformatted, it SHOULD notify the the user of the problem and MUST
discard the entire extension value.
5.1.1. IEEE 1003.1 POSIX Timezone specifier
The format of the IEEE 1003.1 POSIX timezone string is specified as
StdOffset[Dst[Offset],[Start[/Time],End[/Time]]]
where '[' and ']' enclose optional fields, '|' indicates choice
of exactly one of the alternatives, ',' and '/' represent literal
characters present in the string, and:
Std three or more octets for the standard timezone (Std).
Any characters (or case) except a leading colon, digits,
comma, minus or plus sign are allowed.
Offset Indicates the value one must add to local time to
arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset
following Std is required. Digits are always interpreted
as decimal number. If preceded by a '-', the timezone is
east of the Prime Meridian, otherwise it is west ('+' is
optional) The permissible values for hh[:mm[:ss]] are as
follows:
hh 0 <= hh <= 23
mm 0 <= mm <= 60
ss 0 <= ss <= 60
Offset has no default value.
Dst three or more octets for the daylight savings timezone.
If Dst is missing, then daylight savings time does not
Bound, Carney, Perkins Expires 5 November 2000 [Page 15]
Internet Draft DHCP Extensions for IPv6 5 May 2000
apply in this locale. If no Offset follows Dst, then
Dst is assumed to be one hour ahead of standard time.
Any characters (or case) except a leading colon, digits,
comma, minus or plus sign are allowed.
Start Indicates the day of the year, in one of the formats
indicated below, when to change to daylight savings time.
The ``Time'' field (which follows immediately after a
``/'' character, if present) indicates when the change is
made, in local time.
End Indicate the day of the year, in one of the formats
indicated below, when to change back from daylight
savings time. The ``Time'' field (which follows
immediately after a ``/'' character, if present)
indicates when the change is made, in local time.
Time Time has the same format as Offset, except that no
leading ``-'' or ``+'' is permitted. The default is
02:00:00.
The day of the year can be given in one of the following formats:
Jn The julian day n, (1 <= n <= 365). Leap days are not
counted.
n Zero-based julian day, (0 <= n <= 365). Leap days are
counted so it is possible to refer to Feb 29.
Mm.n.d The ``d''th day, (0 <= d <= 6) of week ``n'' of month
``m'' of the year (1 <= n <= 5, 1 <= m <= 12, where week
5 means last ``d'' day in month ``m'' which may occur in
either the fourth or the fifth week. Week ``1'' is the
first week in which the ``d'' day occurs.
5.1.2. An Example:
For Eastern USA time zone, 1986, the Posix timezone string is as
follows:
EST5EDT4,116/02:00:00,298/02:00:00
Here, ``5'' is the Offset for Std, and ``4'' is the Offset for Dst.
Start is the 116th day at 2am, and End is 298th day at 2am.
Bound, Carney, Perkins Expires 5 November 2000 [Page 16]
Internet Draft DHCP Extensions for IPv6 5 May 2000
5.2. Domain Name Server Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8194 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name System server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Domain Name Server extension specifies a list of Domain Name
System (STD13 [16]) name servers available to the client. Servers
SHOULD be listed in order of preference.
The minimum Length for this extension is 16 octets, and MUST always
be a multiple of 16.
5.3. Domain Name Suffix Extension
This extension specifies the default domain name suffix that client
should use when resolving hostnames via the Domain Name System.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8195 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name Suffix (variable length) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum length for this extension is 1. The domain name is a
NVT-ASCII string, ``Length'' octets in size. If the Domain Name
Suffix extension is not specified, and the IP Address extension
received by a client contains a FQDN, then the client MAY take the
part of the FQDN after the first ``.'' octet as the Domain Name
Suffix.
5.4. Service Location Protocol Directory Agent Extension
Entities using the Service Location Protocol (SLP) [20] need to find
out the address of one or more Directory Agents in order to transact
messages, and possibly the correct scope to be used in conjunction
with the service attributes which are exchanged using the Service
Location Protocol.
Bound, Carney, Perkins Expires 5 November 2000 [Page 17]
Internet Draft DHCP Extensions for IPv6 5 May 2000
The Directory Agent extension requests or specifies a Directory Agent
(DA), along with zero or more scopes supported by that DA. Note
that this extension MAY be included multiple times in the same DHCP
Request or DHCP Reply. If so, then the extensions SHOULD be included
in order of decreasing preference.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8196 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|F|M|T| reserved | DA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Directory Agent (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) Typed-Scope-List (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (unsigned integer, variable) The length of the Extension
in octets.
D If the ``D'' bit is set, the Directory Agent field and
the DA Length fields are present.
F If the ``F'' bit is set, the Directory Agent is indicated
by including its variable length host name or Fully
Qualified Domain Name (FQDN) instead of its IP address.
M If the ``M'' bit is set, the Directory Agent address
MUST be present, and multicast methods for discovering
Directory Agents MUST NOT be used.
T If the ``T'' bit is set, the Typed-Scope-List is present.
rsv reserved; ignored upon reception; MUST be sent as zero
DA Length
The length (in octets) of the Directory Agent field.
Directory Agent
The FQDN, host name, or IP address of the Directory
Agent.
Typed-Scope-List
The string denoting the typed-scope-list formatted
as explained in the description of the service scope
extension (section 5.5).
Bound, Carney, Perkins Expires 5 November 2000 [Page 18]
Internet Draft DHCP Extensions for IPv6 5 May 2000
In order to simplify administration of the configuration of DAs for
clients using SLP, the DA can be indicated by presenting its host
name or FQDN instead of its IP address. This allows renumbering to
proceed more smoothly as outlined in RFC1900 [6]. When the FQDN or
host name is used, the server sets the ``F'' bit. The host name can
be distinguished from the FQDN by the presence of a ``.'' character.
In any case, the DA length field is set to be the length of the
Directory Agent field. When the ``F'' bit is not set, the DA Length
MUST be 16.
Note that more than one Directory Agent extension may be present in
a DHCP message. Each such extension may have the same or different
typed-scope-list. The client may request any Directory Agent with
a particular scope, by including the Directory Agent extension in a
DHCP Request message with no Directory Agent address included (the
``D'' bit set to zero), and a nonempty typed-scope-list. The length
of the Typed-Scope-List is only indicated implicitly by the overall
length of the extension.
The format of the Typed-Scope-List field is described in the service
scope extension (section 5.5).
The ``M'' bit MUST NOT be set when the extension is used as part of a
DHCP Request message.
Extension type 8196 MUST include one or more scopes if a DA address
is returned. Using extension type 8196, it is not possible for
different service types on the same node to be configured with
different directory agents. In other words, all service agents of
the same service type on the same node will be configured with the
same directory agent.
5.5. Service Location Protocol Service Scope Extension
This extension indicates a scope that should be used by a Service
Agent (SA) as described in RFC 2165 [20], when responding to Service
Request messages as specified by the Service Location Protocol (SLP).
This extension MAY be included multiple times in the same DHCP
Request or DHCP Reply.
Bound, Carney, Perkins Expires 5 November 2000 [Page 19]
Internet Draft DHCP Extensions for IPv6 5 May 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8197 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed-Scope-List ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (unsigned integer, variable) The length of the Extension
in octets.
Typed-Scope-List
In Service Location Protocol (SLP) [20], multiple
service types can be hosted on the same network node.
It is possible that different service types on the same
computer would be administered from different scopes.
Thus, extension types 8196 and 8197 have additional
syntax to allow this more detailed style of service
configuration.
In particular, the list of scopes contained in the
extensions is syntactically separated into lists
pertaining to each service type.
Grammatically, a typed-scope-list extension in a DHCP
Reply is structured as follows:
typed-scope-list = one or more
maybe-typed-scope-items,
separated by commas
maybe-typed-scope-item =
typed-scope-item,
or scope-list
typed-scope-item = '(' service-type
'=' scope-list ')'
scope-list = one or more
scope-items, comma-separated
A typed-scope-list extension in a DHCP Request is
structured as follows:
typed-scope-list = one or more
maybe-typed-scope-items,
separated by commas
Bound, Carney, Perkins Expires 5 November 2000 [Page 20]
Internet Draft DHCP Extensions for IPv6 5 May 2000
maybe-typed-scope-item = typed-scope-item,
or maybe-empty-scope-list
typed-scope-item = '(' service-type '='
maybe-empty-scope-list ')'
maybe-empty-scope-list = zero or
more scope-items, comma-separated
A service type has the format defined in RFC 2609 ([9]),
and a scope-item has the format defined in RFC 2608
([10]) for ``strval''. Basically, a scope-item is
a character string that has alphanumeric characters
not including control characters or `(',`)',`,',
\',`!',`<',`=',`>', or `"' Service schemes are special
cases of schemes as defined for general URLs in RFC 1738
([3]).
The typed-scope-list MAY contain both untyped-scope-lists
and typed-scope-lists. Each scope-item in each
untyped-scope-list applies to every service type on the
node. The string containing the typed-scope-list is NOT
null-terminated. The typed-scope-list string must be
UTF-8 character encoded.
As an example, the scope-list ``A,B,C'' denotes scopes A,
B and C for all service types on the client. In a DHCP
Request, this scope string would indicate that the client
wishes a directory agent which supports ANY of these
three scopes. In a DHCP Reply, the scope indicates that
the directory agent supports ALL of the three scopes.
Suppose instead that service types ``netman'' and
``proxystuff'' are residing on a DHCP client. Then, the
typed-scope-list in a DHCP Reply could be:
(netman=mgmt),(proxystuff=math-dept,labs)
Assuming the DHCP client with two service types
``netman'' and ``proxystuff'' did not make any scope
restriction, a corresponding typed-scope-list in a DHCP
Request could be:
(netman=),(proxystuff=)
asking for scopes for those service types.
Bound, Carney, Perkins Expires 5 November 2000 [Page 21]
Internet Draft DHCP Extensions for IPv6 5 May 2000
The Typed-Scope-List is described in section 5.5. The DHCP
client (i.e., user agent or service agent) which receives this
extension will use the indicated scope for in all SLP requests and
registrations.
DHCP clients MAY use extension 8197 to request scopes for one or
more particular service types. Note that more than one Service
Scope extension may be present in a DHCP message. The length of the
typed-scope-list is only indicated implicitly by the overall length
of the extension.
5.6. Network Time Protocol Servers Extension
This extension specifies a list of IP addresses indicating NTP [13]
servers available to the client. Servers SHOULD be listed in order
of preference.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8198 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 16, and the Length MUST be a
multiple of 16.
5.7. Network Information Service (NIS) Domain Name Extension
This extension specifies the name of the client's NIS domain. The
domain is formatted as a character string consisting of characters
from the NVT-ASCII character set. The minimum length for this
extension is 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8199 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bound, Carney, Perkins Expires 5 November 2000 [Page 22]
Internet Draft DHCP Extensions for IPv6 5 May 2000
5.8. Network Information Service (NIS) Servers Extension
This extension specifies a list of IP addresses indicating NIS
servers available to the client. Servers SHOULD be listed in order
of preference.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8200 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 16, and the length MUST be a
multiple of 16.
5.9. Network Information Service V2 (NIS+) Domain Extension
This extension specifies the name of the client's NIS+ domain. The
domain is formatted as a character string consisting of characters
from the NVT-ASCII character set. The minimum Length for this
extension is 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.10. Network Information Service V2 (NIS+) Servers Extension
This extension specifies a list of IP addresses indicating NIS+
servers available to the client. Servers SHOULD be listed in order
of preference.
Bound, Carney, Perkins Expires 5 November 2000 [Page 23]
Internet Draft DHCP Extensions for IPv6 5 May 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8202 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 16, and the length MUST be a
multiple of 16.
5.11. TCP-specific Extensions
This section lists the extensions that affect the operation of the
TCP layer on a per-interface basis.
5.11.1. TCP Keepalive Interval Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive Time Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This extension 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 length for this extension is 4.
6. DHCP-specific Extensions
This section details the extensions that are used by the DHCP.
Bound, Carney, Perkins Expires 5 November 2000 [Page 24]
Internet Draft DHCP Extensions for IPv6 5 May 2000
6.1. Maximum DHCP Message Size Extension
This extension specifies the maximum size in octets of any DHCP
message that the sender of the extension is willing to accept.
The size is specified as an unsigned 32-bit integer. A client
may use the maximum DHCP message size extension in DHCP Request
messages, but MUST NOT use the extension in other DHCP messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8204 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max DHCP Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this extension is 4. The minimum permissible value is
1280, as specified in RFC 2460 [8].
6.2. DHCP Retransmission and Configuration Parameter Extension
This extension allows configuration of values for DHCP
retransmission and configuration variables, as specified for
use when sending or receiving DHCP messages. These variables
are discussed in detail in the section on ``Configuration
Variables'' in the ``DHCP for IPv6'' companion document [4].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Configuration Variable Identifier (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Variable Value (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length for this extension is 10 octets. The ``Configuration
Variable Identifier'' field carries an unsigned 16-bit network-order
integer representing the configuration variable. The ``New Variable
Value'' field carries a 64-bit network-order integer representing the
value of the configuration variable. If a client uses this extension
in a DHCP Request message, then the ``New Variable Value'' field
MUST be 0 (zero). If a client does not receive a setting for the
``Configuration Variable Identifier'' it has requested, it MUST use
Bound, Carney, Perkins Expires 5 November 2000 [Page 25]
Internet Draft DHCP Extensions for IPv6 5 May 2000
the default values defined in the ``Configuration Variables'' section
of the ``DHCP for IPv6'' document [4].
6.3. Extension Request Extension (ERE)
The ``Extension Request Extension'' (ERE) MAY be used by DHCP
implementations to indicate which DHCP extensions they are interested
in (client), or what DHCP information (e.g. extensions) are
available (server).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8206 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | B | C | D | E | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The extension contains a list of extension ``Type'' values indicating
the extension of interest. Since an extension ``Type'' field is
an unsigned two-octet network-order integer, each extension is
identified by two-octets. Thus, the Length field MUST always be
an even number. Extension types listed in the ERE are listed in
priority order, with the extensions of highest priority listed before
those of lower priority. One and only one ERE extension is permitted
within a DHCP message.
6.3.1. Client Considerations
If the client implementation supports it, the client SHOULD generate
a Extensions Request Extension identifying which extensions it is
interested in and include it in its DHCP Request messages.
6.3.2. Server Considerations
If a server receives a DHCP request with an ERE extension present,
the server SHOULD attempt to provide valid values for all the
information requested.
6.4. Subnet Prefix Extension
The ``Subnet Prefix'' extension is a DHCP server-only extension used
to advertise what networks are available on the client's link. Each
extension carries a single subnet prefix.
Bound, Carney, Perkins Expires 5 November 2000 [Page 26]
Internet Draft DHCP Extensions for IPv6 5 May 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Len (number of left-most bits) (1 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Prefix Octets (variable number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A subnet prefix is specified by the ``Subnet Prefix Octets'' field
and the ``Prefix-Len'' field. The ``Subnet Prefix Octets'' field
is large enough to contain all the bits of the subnet prefix. Any
unused bits in the last octet of this field MUST be set to off
(zero).
The length of this extension is variable.
6.4.1. Client Considerations
Clients MAY use the ``Subnet Prefix'' extension value to request
one or more IP addresses on that network. A client does this by
forming an ``IP address'' extension with the value of the ``Subnet
Prefix Octets'' field copied into the high-order portion of the ``IP
address'' field (``C'' bit set) and the ``Prefix-len'' value copied
into the ``prefix-len'' field of the ``IP address'' extension for
each IP address desired on the advertised network.
6.4.2. Server Considerations
In response to a client's DHCP Solicit message (``P'' bit set),
a server SHOULD return one ``Prefix'' extension for each of the
networks it is configured to manage that exist on the client's link
in the resultant DHCP Advertise message. A server SHOULD NOT include
``Prefix'' extensions in its Advertise messages if the client has not
requested them (``P'' bit NOT set).
If a server receives a DHCP Request message with ``Prefix''
extension(s), that DHCP Request message MUST be dropped.
6.5. Platform Specific Information Extension
A platform is defined as the combination of hardware and operating
system (OS).
Bound, Carney, Perkins Expires 5 November 2000 [Page 27]
Internet Draft DHCP Extensions for IPv6 5 May 2000
This extension is used by clients and servers to exchange
client-platform-specific information. The information is an opaque
collection of data, presumably interpreted by platform-specific code
on the clients. The definition of this information is platform
specific. Clients identify their platform through the use of the
Platform Class identifier extension (see Section 6.6). Clients which
do not receive platform specific information SHOULD make an attempt
to operate without it, although they may do so (and announce that
they are doing so) in a degraded mode.
If a platform vendor encodes more than one item of information in
this extension, then the vendor MUST encode the extension using
``Encapsulated platform-specific extensions'' as described below.
The ``Encapsulated platform-specific extensions'' field MUST be
encoded as a sequence of type/length/value fields of identical syntax
to the form defined for DHCP extensions (see section 2), encapsulated
within the ``Platform Specific Information Extension''.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum length for this extension is 4.
DHCP servers which support the configuration of ``Platform Specific
Information'' extensions, and which have been configured with
configuration information specific to some number of ``Platform Class
Identifiers'' MUST select and return only those platform-specific
extensions which match the ``Platform Class Identifier'' provided by
the DHCP client.
6.6. Platform Class Identifier Extension
This extension is used by a DHCP client to identify the hardware type
and operating system platform it is hosted on. The extension value
itself is an opaque value to a DHCP server, and is only used by the
DHCP server to "lookup" Platform Specific Extensions associated with
clients of a certain platform class. DHCP servers SHOULD also allow
the association of other extensions (Releasable, General, etc) with
clients of a certain platform class.
Note that unlike the ``User Class Identifier'' (see section 6.7, the
``Platform Class Identifier'' does not need to be echoed back to the
Bound, Carney, Perkins Expires 5 November 2000 [Page 28]
Internet Draft DHCP Extensions for IPv6 5 May 2000
DHCP client because there can be one and only one ``Platform Class
Identifier'' for a client.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8209 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum length for this extension is 4.
The ``Platform Class Identifier'' is a string of UTF-8 characters
of Length octets. The ``Platform Class Identifier'' represents the
hardware and operating system class of which the client is a member.
In order to prevent collisions in the ``Platform Class Identifier''
namespace, DHCP client vendors MUST prefix their ``Platform Class
Identifiers'' with their stock symbol or some other globally
recognized organizational identifier. For example, ``Platform Class
Identifiers'' for Sun Microsystems Inc platforms would be prefaced
by ``SUNW'', the NASDAQ stock symbol for Sun. Those associated with
Microsoft platforms would be prefaced by ``MSFT''.
6.6.1. Client Considerations
If the client wishes platform-specific data, it includes a platform
class identifier extension identifying its platform type.
6.6.2. Server Considerations
Servers not equipped to interpret the platform class identifier
specified by a client MUST ignore it (although it may be reported
to the DHCP administrator). Otherwise, servers SHOULD respond with
the set of extensions corresponding to the platform class identifier
specified by the client.
6.7. User Class Identifier Extension
This extension is used by a DHCP client to optionally identify the
type or category of user or applications it represents.
Network administrators may define specific user class identifiers to
convey information about a client's software configuration or about
Bound, Carney, Perkins Expires 5 November 2000 [Page 29]
Internet Draft DHCP Extensions for IPv6 5 May 2000
its user's preferences. For example, an identifier may specify that
a particular machine hosting a DHCP client is a member of the class
``accounting auditors'', which have special service needs such as a
particular database server or printer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum length for this extension is 4.
The user class identifier is a UTF-8 string of Length octets.
The value of the ``User Class Identifier'' is selected by the
administrator of the DHCP domain containing the all members of this
class. Thus, a ``User Class Identifier'' need only be unique within
the DHCP domain, although the administrator MAY choose to prefix the
``User Class Identifier'' with the department name in order to reduce
the possibility of ``User Class Identifier'' name space collisions.
6.7.1. Client Considerations
If the client is configured to request user class-specific data, it
includes a User Class identifier extension for each user class it is
configured with.
6.7.2. Server Considerations
Servers not equipped to interpret the user class identifier specified
by a client MUST ignore it (although it may be reported to the
network administrator). Otherwise, servers SHOULD respond with
the set of extensions corresponding to the user class identifier
specified by the client. Further, if the server responds with the
set of extensions corresponding to the given user class identifier,
it MUST echo the client's user class identifier extension back to the
client.
6.8. Reconfigure Multicast Address Extension
A DHCP server can instruct its clients to join one or more multicast
groups for the purposes of receiving DHCP Reconfigure or DHCP
Reconfigure-init messages. The DHCP server accomplishes this by
Bound, Carney, Perkins Expires 5 November 2000 [Page 30]
Internet Draft DHCP Extensions for IPv6 5 May 2000
returning a ``Reconfigure Multicast Address Extension'' for each
multicast address associated with the group. See the ``DHCP for
IPv6'' document [4] for more details on the use of this extension.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8211 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reconfigure Multicast Address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this extension is 16.
6.9. Renumber DHCP Server Address Extension
A DHCP server can instruct its clients to change their internal
records to reflect the server's newly renumbered IP address, by using
the ``Renumber DHCP Server Address Extension''. This extension
SHOULD be sent in the DHCP Reconfigure message.
The server includes both its previous IP address and its new IP
address. Providing the previous IP address allows clients to update
only those resource associations owned by this server.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8212 | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous DHCP Server Address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New DHCP Server Address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this extension is 32.
6.10. Client-Server Authentication Extension
Exactly one ``Client-Server Authentication Extension'' MAY be present
in any DHCP message transmitted between a client and server (or
vice-versa). If present, it MUST be the last extension.
Bound, Carney, Perkins Expires 5 November 2000 [Page 31]
Internet Draft DHCP Extensions for IPv6 5 May 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8213 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Protection |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (unsigned integer, variable) 4 for the SPI, plus 8 for
the replay protection, plus the number of octets in the
Authenticator.
SPI A Security Parameters Index (SPI) [2] identifying a
security context from among those available between the
DHCP client and server.
Replay Protection
A 64-bit timestamp (in Network Time Protocol (NTP) [15]
format) (see section 7.1).
Authenticator
(variable length) (See Section 7.2.)
This authentication extension remedies the inability of IPsec (RFC
2402 [11]) to provide for non end-to-end authentication, since
authentication is needed even when the client has no IPv6 address
with enough scope to reach the DHCP server. The extension can be
originated by either the client or server to authenticate the rest of
the data in the DHCP message. The default authentication algorithm,
which MUST be supported by all clients and servers, is defined in
section 7.2.
SPI values 0 through 255 are reserved and, if used, MUST conform
to the security context defined by that value in the most recent
Assigned Numbers RFC (e.g., STD1 [17]).
6.11. Client Key Selection Extension
A DHCP server may wish to indicate to a prospective client which
SPI it must use to authenticate subsequent messages, using the
``Client-Server Authentication Extension''. In such cases, the
Bound, Carney, Perkins Expires 5 November 2000 [Page 32]
Internet Draft DHCP Extensions for IPv6 5 May 2000
server includes the ``Client Key Selection Extension'' in its DHCP
Advertise message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8214 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Security Parameters Index (SPI) [2] identifies a security
context between a pair of nodes among the contexts available in the
security association defined between the DHCP client and server.
SPI values 0 through 255 are reserved and, if used, MUST conform to
the security context defined by that value as defined in the most
recent Assigned Numbers RFC (e.g.,STD1 [17]).
7. Security Considerations
A security protocol is urgently needed for use with DHCP, since
otherwise malicious parties could create numerous denial-of-service
style attacks based on depleting available server resources or
providing corrupted or infected data to unsuspecting clients. The
following sections discuss aspects of security relevant for users
of the Client-Server Authentication extension 6.10. See also the
Security Considerations in the companion specification [4].
7.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [15](NTP) format, is
used to protect against replay of previous authenticated messages
by malicious agents. The NTP timestamp value used in the extension
MUST be chosen, and verified, to be larger than values used by the
originator in previous Client-Server Authentication extensions.
On the other hand, the timestamp value MUST also be chosen (and
verified) to be no greater than one year more than the last known
value (if any) used by the originator.
7.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [12], using
keyed-MD5 [18]. Given a secret key K, and "data" the information to
be authenticated, HMAC_result is computed as follows:
Bound, Carney, Perkins Expires 5 November 2000 [Page 33]
Internet Draft DHCP Extensions for IPv6 5 May 2000
1. opad := 0x36363636363636363636363636363636 (128 bits)
2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
3. zero_extended_key := K extended by zeroes to be 128 bits long
4. opadded_key := zero_extended_key XOR opad
5. ipadded_key := zero_extended_key XOR ipad
6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))
The key K is the shared secret defined by the security association
between the client and server and by the SPI value specified in
the Authentication Extension. The "data" is the stream of octets
in all previous fields in the DHCP message and extensions. The
authenticator is the 128-bit value HMAC_result.
8. IANA Considerations
This document MAY be superseded by new documents for DHCP extensions,
which will then include the entire current list of valid extensions.
This section details the method for specifying new extensions.
Implementation specific use of undefined extensions (all those in the
range 86-32767 inclusive) may conflict with other implementations,
and registration is required.
The following steps MUST be followed by the author of any new DHCP
extension, in order to obtain acceptance of the extension as a part
of the DHCP Internet Standard:
1. The author documents the new extension as an Internet Draft.
2. The author submits the Internet Draft for review through the
IETF standards process as defined in "Internet Official Protocol
Standards" [17]. The new extension will be submitted for
eventual acceptance as an Internet Standard.
3. The author requests a number for the new extension from IANA by
contacting:
Internet Assigned Numbers Authority (IANA)
USC/Information Sciences Institute
4676 Admiralty Way
Bound, Carney, Perkins Expires 5 November 2000 [Page 34]
Internet Draft DHCP Extensions for IPv6 5 May 2000
Marina del Rey, California 90292-6695
or by email as: iana@isi.edu
4. The new extension progresses through the IETF standards
process; the new extension 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.
5. If the new extension fails to gain acceptance as an Internet
Standard, the assigned extension number will be returned to IANA
for reassignment.
This procedure for defining new extensions will ensure that:
* allocation of new extension numbers is coordinated from a single
authority,
* new extensions are reviewed for technical correctness and
appropriateness, and
* documentation for new extensions is complete and published.
9. Acknowledgements
The original form of this internet draft was copied directly from
RFC1533 [1], written by Steve Alexander and Ralph Droms. Thanks to
Mike Carney for his many helpful comments, as well as contributing
the design of the Platform Specific Information and Platform Class
Identifier. Thanks to Erik Guttman for his helpful suggestions
for the Service Location extensions. Thanks to Ralph Droms, Matt
Crawford, Thomas Narten, and Erik Nordmark for their careful review
as part of the Last Call process.
10. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However,
this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society
or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures
Bound, Carney, Perkins Expires 5 November 2000 [Page 35]
Internet Draft DHCP Extensions for IPv6 5 May 2000
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Bound, Carney, Perkins Expires 5 November 2000 [Page 36]
Internet Draft DHCP Extensions for IPv6 5 May 2000
References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. Request for Comments (Proposed Standard) 1533,
Internet Engineering Task Force, October 1993.
[2] R. Atkinson. IP Authentication Header. Request for Comments
(Proposed Standard) 1826, Internet Engineering Task Force,
August 1995.
[3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). Request for Comments (Proposed Standard) 1738,
Internet Engineering Task Force, December 1994.
[4] J. Bound, M. Carney, and C. Perkins. DHCP for IPv6.
draft-ietf-dhc-dhcpv6-15.txt, May 2000. (work in progress).
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[6] B. Carpenter and Y. Rekhter. Renumbering Needs Work. Request
for Comments (Informational) 1900, Internet Engineering Task
Force, February 1996.
[7] M. Crawford, C. Huitema, and S. Thomson. DNS Extensions to
Support IPv6 Address Aggregation and Renumbering.
draft-ietf-ipngwg-dns-lookups-07.txt, 2000. (work in progress).
[8] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[9] E. Guttman, C. Perkins, and J. Kempf. Service Templates and
Service: Schemes. Request for Comments (Proposed Standard)
2609, Internet Engineering Task Force, June 1999.
[10] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol, Version 2. Request for Comments (Proposed
Standard) 2608, Internet Engineering Task Force, June 1999.
[11] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[12] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
for Message Authentication. Request for Comments
(Informational) 2104, Internet Engineering Task Force,
February 1997.
Bound, Carney, Perkins Expires 5 November 2000 [Page 37]
Internet Draft DHCP Extensions for IPv6 5 May 2000
[13] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI. Request for Comments (Informational) 2030,
Internet Engineering Task Force, October 1996.
[14] D. L. Mills. Internet time synchronization: The Network Time
Protocol. Request for Comments 1129, Internet Engineering Task
Force, October 1989.
[15] David L. Mills. Network Time Protocol (version 3)
Specification, Implementation. Request for Comments (Draft
Standard) 1305, Internet Engineering Task Force, March 1992.
[16] P. V. Mockapetris. Domain names - concepts and facilities.
Request for comments (standard), Internet Engineering Task
Force, November 1987.
[17] J. Reynolds and R. Braden. Internet Official Protocol Sandards.
Request for comments (proposed standard), Internet Engineering
Task Force, March 2000.
[18] R. Rivest. The MD5 Message-Digest Algorithm. Request for
Comments (Informational) 1321, Internet Engineering Task Force,
April 1992.
[19] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
[20] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. Request for Comments (Proposed Standard)
2165, Internet Engineering Task Force, June 1997.
[21] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic
Updates in the Domain Name System (DNS UPDATE). Request for
Comments (Proposed Standard) 2136, Internet Engineering Task
Force, April 1997.
Bound, Carney, Perkins Expires 5 November 2000 [Page 38]
Internet Draft DHCP Extensions for IPv6 5 May 2000
Chair's Addresses
The working group can be contacted via the current chair:
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
Authors' Addresses
Questions about this memo can be directed to:
Jim Bound
Compaq Computer Corporation
Mail Stop: ZK03-3/U14
110 Spitbrook Road
Nashua, NH 03062
USA
Phone: +1-603-884-0400
Email: bound@zk3.dec.com
Mike Carney
Sun Microsystems, Inc
Mail Stop: UMPK17-202
901 San Antonio Road
Palo Alto, CA 94303-4900
USA
Phone: +1-650-786-4171
Email: mwc@eng.sun.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Bound, Carney, Perkins Expires 5 November 2000 [Page 39]
