Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems Laboratories
J. Bound
Compaq Computer Corp.
25 February 1999
Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-v6exts-11.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] (DHCPv6)
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 DHCPv6 message. The data items themselves
are also called "extensions." This document specifies the current
set of DHCPv6 extensions, which will be periodically updated as new
extensions are defined.
Perkins, Bound Expires 25 August 1999 [Page i]
Internet Draft DHCPv6 Extensions 25 February 1999
Contents
Status of This Memo i
Abstract i
1. Introduction 1
2. DHCPv6 Extension Field Format 2
3. IP Address Extension 3
3.1. Client Considerations for the IP Address extension . . . 7
3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 7
3.1.2. Use with the DHCP Request message . . . . . . . . 7
3.1.3. Receiving as part of the DHCP Reply message . . . 8
3.1.4. Use with the DHCP Release message . . . . . . . . 9
3.2. Server Considerations for the IP Address extension . . . 9
3.2.1. Use with the DHCP Advertise message . . . . . . . 9
3.2.2. Receiving a DHCP Request with the IP Address
Extension . . . . . . . . . . . . . . . . 10
3.2.3. Use with the DHCP Reply message . . . . . . . . . 10
3.2.4. Use with the DHCP Reconfigure message . . . . . . 11
3.2.5. Receiving a DHCP Release with the IP Address
Extension . . . . . . . . . . . . . . . . 11
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11
4. General Extensions 11
4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 12
4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 13
4.2.2. An Example . . . . . . . . . . . . . . . . . . . 14
4.3. Domain Name Server Extension . . . . . . . . . . . . . . 14
4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 15
5. Application and Service Parameters 15
5.1. Service Location Protocol extensions . . . . . . . . . . 15
5.1.1. Typed Scope Lists . . . . . . . . . . . . . . . . 15
5.1.2. Directory Agent Extension . . . . . . . . . . . . 17
5.1.3. Service Scope Extension . . . . . . . . . . . . . 18
5.2. Network Time Protocol Servers Extension . . . . . . . . . 19
5.3. Network Information Service (NIS and NIS+) extensions . . 20
5.3.1. NIS Domain Extension . . . . . . . . . . . . . . 20
5.3.2. NIS Servers Extension . . . . . . . . . . . . . . 20
5.3.3. NIS+ Domain Extension . . . . . . . . . . . . . . 20
5.3.4. NIS+ Servers Extension . . . . . . . . . . . . . 21
6. TCP Parameters 21
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21
Perkins, Bound Expires 25 August 1999 [Page ii]
Internet Draft DHCPv6 Extensions 25 February 1999
7. DHCPv6 Extensions 22
7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 22
7.2. DHCP Retransmission and Configuration Parameter Extension 22
7.3. Platform Specific Information . . . . . . . . . . . . . . 23
7.4. Platform Class Identifier . . . . . . . . . . . . . . . . 24
7.5. Class Identifier . . . . . . . . . . . . . . . . . . . . 25
7.6. Reconfigure Multicast Address . . . . . . . . . . . . . . 26
7.7. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 26
7.8. DHCP Relay ICMP Error Message Format . . . . . . . . . . 27
7.8.1. ICMP Extension Client Considerations . . . . . . 27
7.8.2. ICMP Extension Relay Considerations . . . . . . . 27
7.9. Client-Server Authentication Extension . . . . . . . . . 28
7.10. Client Key Selection Extension . . . . . . . . . . . . . 29
8. End Extension 29
9. Resource-Server Associations 30
10. Security Considerations 30
10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
10.2. Default Authentication Algorithm . . . . . . . . . . . . 30
11. IANA Considerations 31
12. Acknowledgements 32
13. Full Copyright Statement 32
Chair's Address 36
Author's Addresses 36
1. Introduction
This document specifies extensions for use with the Dynamic Host
Configuration Protocol for IP version 6, DHCPv6. DHCPv6 message
formats are described in the DHCPv6 specification 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 DHCPv6 messages. The extensions defined
within this document specify a generalized way to distribute
information useful to a wide class of machines, operating systems
and configurations. Sites with a DHCPv6 server that is shared among
heterogeneous clients may choose to define other, site-specific
formats for the use of the 'extensions' field.
Perkins, Bound Expires 25 August 1999 [Page 1]
Internet Draft DHCPv6 Extensions 25 February 1999
Section 2 of this memo describes the formats of DHCPv6 extensions.
Information on registering new extensions is contained in section 11.
The other sections organize the format descriptions of various
extensions according to their general type, as follows:
- IP Address extension
- General host configuration
- Application and Service Parameters
- TCP
- DHCPv6
Future applications will make extensive use of an ever-increasing
number and variety of network services. It is expected that client
needs for creating connections with these future network services
will be satisfied by the Service Location Protocol [27], and not
DHCPv6. DHCP is expected to be used for the kinds of configuration
that enable clients to become fully functional as self-contained
network entities, but not the kinds of configuration that might be
required by applications running above the network or transport layer
protocol levels.
2. DHCPv6 Extension Field Format
Extensions may be fixed length or variable length. All extensions
begin with a type field, which is two octets long and uniquely
identifies the extension. Every extension, except extension number
65535, has a two octet unsigned integer Length field following the
type field. The value of the Length field does not include the
four octets specifying the type and length. For some extensions
the Length field is always the same number, but it MUST still be
specified. In each case, unless otherwise specified, the Length
field specifies the length of the extension data in octets. There
is no particular requirement for alignment of data fields within
existing DHCPv6 extensions. Any extensions defined subsequent to
this document MUST contain a two-octet Length field even if the
length is fixed or zero.
Unrecognized extensions SHOULD be 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 extension type 64 (see section 7.1), DHCP entities MUST assume
that that the maximum DHCP message size including extensions is 1280
octets.
Perkins, Bound Expires 25 August 1999 [Page 2]
Internet Draft DHCPv6 Extensions 25 February 1999
All multi-octet quantities are in network byte-order.
Extension types 32768 to 65534 (decimal) are reserved for
site-specific extensions.
All of the extensions described in this document will 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.
All strings are encoded in UTF-8, which includes US-ASCII as a
subset.
3. IP Address Extension
The IP Address extension is the most essential of all the DHCPv6
extensions. It can be used by both client and server in various
ways. Since the IP Address extension can be used more than once in
the same DHCP message, all information relevant to a particular IPv6
allocation has to be collected together in the same extension. Some
of the fields within the IP Address extension can specify how DNS may
be updated [28].
To ask for an IP address in a DHCP Request message, a client includes
an IP Address Extension. To renew or extend the lifetime of a
particular IP address, the client puts that address in the client
address field. To request the allocation of a new but unspecified IP
address, the client omits the client address field. The IP address
returned by the server in the latter case will be compatible with a
routing prefix of the link to which the client is currently attached.
An IP Address Extension can contain at most one IP address. To
specify more than one IP address, multiple extensions are used.
Perkins, Bound Expires 25 August 1999 [Page 3]
Internet Draft DHCPv6 Extensions 25 February 1999
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|L|Q|A|P| reserved | prefix-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| client 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 If the server is unable to honor the client's request,
the reason is indicated in the status.
C If the 'C' bit is set, the field containing the IP
address for the client is present in the extension.
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.
A If the 'A' bit is set, the client requests that the
server updates DNS with a new AAAA 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.
prefix-size
If the client address is present (the 'C' bit is set), a
nonzero prefix-size is the number of leftmost bits of the
Perkins, Bound Expires 25 August 1999 [Page 4]
Internet Draft DHCPv6 Extensions 25 February 1999
client's IPv6 address which make up the routing prefix.
Otherwise, if the 'C' bit is not set, prefix-size MUST be
zero.
client address
The IP address to be allocated by the server for use by
the client (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
DNS name
The DNS name (a string of ASCII octets) to be used by the
client (variable length).
The following values for the status field are defined within this
document:
0 request granted, no errors
18 Security parameters failed for this client
20 Resource AAAA Record Parameter Problem
21 Resource PTR Record Parameter Problem
22 Unable to honor required extension parameters
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)
Perkins, Bound Expires 25 August 1999 [Page 5]
Internet Draft DHCPv6 Extensions 25 February 1999
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)
Status values 33 through 42 are described more fully within Dynamic
Updates to DNS (RFC 2136 [28]). Up-to-date values for the values
of the status field are specified in the most recent "Assigned
Numbers" [23].
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, L,
A, and P bits are required, and MUST be provided, or the extension
MUST be rejected with status code 22, indicating that the server was
unable to honor the required extension parameters
If the 'Q' bit is set, and if the 'A' bit is set, the server MUST
ensure that the DNS is updated with a new AAAA record, as specified
by the client's FQDN, before responding with the corresponding DHCP
Reply. Likewise, if the 'Q' bit is set, and if the 'P' bit is
set, the server MUST ensure that the DNS is updated with a new PTR
record, as specified by the client's FQDN, before responding with the
corresponding DHCP Reply.
A DHCP client can include an IP address in its IP Address extension
and set the 'A' bit and/or 'P' bit to ask the DHCP Server to use that
address for updating DNS. This MAY be done even with IP addresses
obtained by Stateless Address Autoconfiguration [26]. 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 record, and the server
SHOULD update the PTR record. The IP Address extension permit
Perkins, Bound Expires 25 August 1999 [Page 6]
Internet Draft DHCPv6 Extensions 25 February 1999
clients and servers to use a different behavior than the default, and
they MAY set the 'Q' and 'A' bits to suit their needs.
3.1. Client Considerations for the IP Address extension
3.1.1. Address Lifetimes
An IP address returned to a client in a DHCP Reply message has a
preferred and valid lifetime. The valid lifetime represents the
lease for addresses provided to the client, from the server. The
client MAY request values for the lifetimes, but the client MUST use
the lifetimes provided by the server response.
When the preferred lifetime of an IP address expires, the client's
address becomes a deprecated address. See [11] for required handling
of deprecated IP addresses. Before an address for a DHCPv6 client's
interface becomes deprecated, the client SHOULD request a new address
for that interface, or make a new DHCP Request for the existing
address (which can result in the address receiving an updated
preferred lifetime). If the client does not make a new Request for
an address before the valid lifetime expires, the server SHOULD
assume the client does not want that address. After it expires, the
server MAY provide that address to another client.
3.1.2. Use with the DHCP Request message
In a DHCP Request (for each address extension), a client MUST set the
status code to zero.
In a DHCP Request (for each address extension), a client MAY:
- include an IP address and/or a DNS name (which may be a host name
or a FQDN).
- set the prefix-size field to zero. If nonzero, the IP address
MUST be included, and the prefix-size MUST correspond to the
appropriate routing prefix for that IP address.
- set the 'A' bit to request that the server update DNS with a new
AAAA record, as specified by the client's FQDN.
- set the 'P' bit to request that the server update DNS with a new
PTR record, as specified by the client's FQDN.
- indicate the minimum preferred (and/or valid) lifetime, by
supplying a value for the field(s).
Perkins, Bound Expires 25 August 1999 [Page 7]
Internet Draft DHCPv6 Extensions 25 February 1999
- specify whether address, name and lifetimes (if present) are
advisory -or- mandatory, by setting the 'Q' bit.
A client may include multiple IP Address extensions in a single DHCP
Request. A client indicates that it cannot accept any configuration
information other than that listed in the IP Address extension (e.g.,
IP address) to the DHCP Request, by specifying the 'Q' (Required)
bit.
If the information in the IP extension is advisory, a server may send
different parameters than requested in the DHCP Reply. Otherwise,
the server MUST reject the Request if it cannot be fulfilled. A
server can always supply a greater value for the lifetimes than that
requested by the client, even if the 'Q' bit is set. If the client
wishes to have a smaller lifetime than the server supplies, the
client MAY use the DHCP Release mechanism to relinquish it.
When a client requests an IP address, it MUST maintain a record
(called a ``resource-server association'', and explained in
section 9) for the server which allocates that address, so that the
client can (if necessary) in the future
- Extend the lifetime with the same server, or
- Release the address, using DHCP Release.
3.1.3. Receiving as part of the DHCP Reply message
When the client receives an IP address extension as part of a DHCP
Reply [4], it first inspects the status to see whether the requested
information 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. Nonzero 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 with a lifetime, the client MUST
perform Duplicate Address Detection (DAD) [26]; however, if the
address has already been allocated to the client and it is merely
renewing the lifetime of the address, the client does not have to
perform DAD each time. If the client receives an IP address with
zero valid lifetime, the client MUST immediately discontinue using
that IP address.
Perkins, Bound Expires 25 August 1999 [Page 8]
Internet Draft DHCPv6 Extensions 25 February 1999
3.1.4. Use with the DHCP Release message
In a DHCP Release message, the client MUST provide at least one
specific IP address in the extension.
For each address extension:
- the client may include a name (which may be a host name or a
FQDN).
- if the server originally updated DNS with one or more AAAA
records for allocated IP addresses, the server MUST update DNS to
delete those records, and likewise for the PTR record (regardless
of the setting of the 'A' or 'P' bits in the address extension).
- If the client, on the other hand, made the DNS updates, it MUST
perform the corresponding deletions before issuing the DHCP
Release.
3.2. Server Considerations for the IP Address extension
This section contains information specifying the handling of the IP
Address extension by DHCP servers.
3.2.1. Use with the DHCP Advertise message
In DHCP Advertise (for each address extension), the Server can
indicate:
- the client's FQDN or host name
- the preferred lifetime
- the valid lifetime
- whether DNS will accept new names for the address (via the 'A'
bit)
If the server sets the 'A' bit, it is willing to perform DNS updates
to AAAA records on behalf of the client. Likewise, if the server
sets the 'P' bit, it is willing to perform DNS updates to PTR records
on behalf of the client.
Perkins, Bound Expires 25 August 1999 [Page 9]
Internet Draft DHCPv6 Extensions 25 February 1999
3.2.2. Receiving a DHCP Request with the IP Address Extension
When a server receives a request for an IP address, it consults its
allocation tables and determines an IP address appropriate for the
requesting client and the link to which the client is attached.
The link can be determined by the Agent address prefix in the DHCP
Request message header, or, when there is no relay, by the link of
the interface on which the request was received. This is true in the
latter case because the client and the server have to be on the same
link when there is no server address included in the message header.
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 (see the DHCP Release
message in [4]), the server MUST perform the reverse service by
updating DNS again as needed.
3.2.3. Use with the DHCP Reply message
In a DHCP Reply message (for each address extension) the server MUST
indicate in the IP address extension the following information:
- the preferred lifetime
- the valid lifetime
- the status of the request
If the Reply is a response to a DHCP Release, the lifetimes MUST both
be zero.
In a DHCP Reply message, for each address extension) the server MAY
indicate the following information:
- the DNS name
- (by setting the 'A' bit) whether AAAA has been updated by the DNS
- (by setting the 'P' bit) whether PTR has been updated by the DNS
If the client requests updates, and sets the 'Q' bit, the server MUST
NOT issue the DHCP Reply until after receiving positive indication
that the DNS update has indeed been performed. If the 'Q' bit has
been set, and the server cannot honor the IP address extension, it
MUST return a DHCP reply with the status 22.
Otherwise, the client MAY attempt to update DNS if needed.
Perkins, Bound Expires 25 August 1999 [Page 10]
Internet Draft DHCPv6 Extensions 25 February 1999
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.
On a practical note, if the DHCP administrator uses site-local
addresses for IP address allocation to clients, there will be less
need for renumbering whenever the site moves to a new site prefix or
set of site prefixes. Of course, this only works when the site does
not need global addresses.
3.2.4. Use with the DHCP Reconfigure message
In DHCP Reconfigure (for each address extension) the server MAY
indicate the DNS name.
3.2.5. Receiving a DHCP Release with the IP Address Extension
When a DHCP client releases its IP address, by including an
appropriate IP Address Extension with the DHCP Release message, the
server determines whether or not it was originally responsible for
updating the DNS AAAA record or PTR record for the client. If so,
then the server must also perform the reverse service by updating DNS
again to delete the client records.
3.3. DHCP Relay Considerations
The DHCP Relay MUST NOT change any information in any DHCPv6
Extension fields. All Extension information flows between DHCPv6
Server and DHCPv6 Client without modification by any Relay.
4. General Extensions
The following extensions are important for many DHCPv6 clients, and
are not specific to any upper-level protocol.
Perkins, Bound Expires 25 August 1999 [Page 11]
Internet Draft DHCPv6 Extensions 25 February 1999
4.1. Time Offset
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 = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The time offset field specifies the offset of the client's clock
in seconds from Coordinated Universal Time (UTC). The offset is
expressed as a signed (two's complement) 32-bit integer.
4.2. IEEE 1003.1 POSIX Timezone extension
Extension type 2, defined in section 4.1, specifies the Universal
Coordinated Time (UTC) offset. Unfortunately, the UTC offset
extension does not provide enough information for an Internet
client to determine such timezone-related details as the timezone
names, daylight savings time start and end times in addition to the
timezone UTC offsets. This extension (analogous to that proposed
for DHCPv4 [6]) allows delivery of timezone information in the form
of a IEEE 1003.1 POSIX Timezone specifier [15], as detailed in
section 4.2.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 = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE 1003.1 POSIX Timezone string (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a DHCP client receives both the Time Offset (type 2) and the POSIX
Timezone (type 3) extension in a DHCP reply message, the client MUST
discard the value of the Time Offset (type 2) extension and utilize
the POSIX Timezone Extension. The DHCP client MAY notify the user
that it is resolving the conflict by discarding the Time Offset (type
2) extension.
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.
Perkins, Bound Expires 25 August 1999 [Page 12]
Internet Draft DHCPv6 Extensions 25 February 1999
4.2.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
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.
Perkins, Bound Expires 25 August 1999 [Page 13]
Internet Draft DHCPv6 Extensions 25 February 1999
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.
4.2.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 16, and End is 298.
4.3. 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 = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name System server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Domain Name Server extension specifies a list of Domain Name
System [22] 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.
Perkins, Bound Expires 25 August 1999 [Page 14]
Internet Draft DHCPv6 Extensions 25 February 1999
4.4. Domain Name
This extension specifies the default domain name 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 = 10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 1. The domain name is a
ASCII string, Length octets in size. If the Domain Name 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.
5. Application and Service Parameters
This section details some miscellaneous extensions used to configure
miscellaneous applications and services.
5.1. Service Location Protocol extensions
This subsection describes DHCP extensions useful for a client to
begin operations using the Service Location Protocol (SLP) [27].
5.1.1. Typed Scope Lists
In Service Location Protocol, multiple service types can be hosted on
the same network node. However, DHCP typically configures computers
based on their IP address. It is possible that different service
types on the same computer would be administered from different
scopes. Thus, extensions 16 and 17 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 in a DHCP Reply is structured as
follows:
typed-scope-list = one or more maybe-typed-scope-items,
separated by commas
Perkins, Bound Expires 25 August 1999 [Page 15]
Internet Draft DHCPv6 Extensions 25 February 1999
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 in a DHCP Request 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
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 [12], and a scope-item has
the format defined in [13] 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 [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.
Perkins, Bound Expires 25 August 1999 [Page 16]
Internet Draft DHCPv6 Extensions 25 February 1999
5.1.2. Directory Agent Extension
Entities using the Service Location Protocol (SLP) [27] 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.
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 = 16 | 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.
Perkins, Bound Expires 25 August 1999 [Page 17]
Internet Draft DHCPv6 Extensions 25 February 1999
Directory Agent
The FQDN, host name, or IP address of the Directory
Agent.
Typed-Scope-List
The string denoting the typed-scope-list (see
Section 5.1.1).
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 [7]. 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 section 5.1.1.
The `M' bit MUST NOT be set when the extension is used as part of a
DHCP Request message.
Extension 16 MUST include one or more scopes if a DA address is
returned. Using extension 16, 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.1.3. Service Scope Extension
This extension indicates a scope that should be used by a Service
Agent (SA) [27], 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.
Perkins, Bound Expires 25 August 1999 [Page 18]
Internet Draft DHCPv6 Extensions 25 February 1999
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 = 17 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed-Scope-List ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length (unsigned integer, variable) The length of the Extension
in octets.
Typed-Scope-List
see Section 5.1.1.
The Typed-Scope-List is described in Section 5.1.1. 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 17 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.2. Network Time Protocol Servers Extension
This extension specifies a list of IP addresses indicating NTP [20]
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 = 18 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 16, and the Length MUST be a
multiple of 16.
Perkins, Bound Expires 25 August 1999 [Page 19]
Internet Draft DHCPv6 Extensions 25 February 1999
5.3. Network Information Service (NIS and NIS+) extensions
This subsection describes DHCPv6 extensions useful for NIS and NIS+
clients.
5.3.1. NIS Domain Extension
This extension specifies the name of the client's NIS [19] domain.
The domain is formatted as a character string consisting of
characters from the US-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 = 19 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3.2. NIS Servers Extension
This extension specifies a list of IP addresses indicating NIS [19]
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 = 20 | 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.3.3. NIS+ Domain Extension
This extension specifies the name of the client's NIS+ [19]
domain. The domain is formatted as a character string consisting of
characters from the US-ASCII character set. The minimum Length for
this extension is 1.
Perkins, Bound Expires 25 August 1999 [Page 20]
Internet Draft DHCPv6 Extensions 25 February 1999
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 = 21 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3.4. NIS+ Servers Extension
This extension specifies a list of IP addresses indicating NIS+ [19]
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 = 22 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 16, and the Length MUST be a
multiple of 16.
6. TCP Parameters
This section lists the extensions that affect the operation of the
TCP layer on a per-interface basis.
6.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 = 32 | 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
Perkins, Bound Expires 25 August 1999 [Page 21]
Internet Draft DHCPv6 Extensions 25 February 1999
keepalive messages on connections unless specifically requested by an
application.
The Length for this extension is 4.
7. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6.
7.1. Maximum DHCPv6 Message Size Extension
This extension specifies the maximum size in octets of any DHCPv6
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 DHCPv6 message size extension in DHCP Request messages,
but MUST NOT use the extension in other DHCP messages (see [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 = 40 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max DHCPv6 Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this extension is 4. The minimum permissible value is
1280 [11].
7.2. DHCP Retransmission and Configuration Parameter Extension
This extension allows configuration of values for DHCP
retransmission and configuration parameters, as specified
for use when sending or receiving DHCPv6 messages [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 = 41 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP Parameter Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Parameter Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this extension is either 4 or 8. If a client uses
this extension as part of a DHCP Request message, the New Parameter
Perkins, Bound Expires 25 August 1999 [Page 22]
Internet Draft DHCPv6 Extensions 25 February 1999
Value field does not have to be used as part of the extension. The
following table shows the current parameter names, their associated
Parameter Identifier, and their default values.
Parameter Name ParamID Default Value
=============================================================
CLIENT_ADV_WAIT 1 2000 milliseconds
DEFAULT_SOLICIT_HOPCOUNT 2 4
SERVER_MIN_ADV_DELAY 3 100 milliseconds
SERVER_MAX_ADV_DELAY 4 1000 millisecond
REQUEST_MSG_MIN_RETRANS 5 10 retransmissions
REPLY_MSG_TIMEOUT 6 2000 milliseconds
REPLY_MSG_RETRANS_INTERVAL 7 2000 milliseconds
RECONF_MSG_TIMEOUT 8 12000 milliseconds
RECONF_MSG_MIN_RETRANS 9 10 retransmissions
RECONF_MSG_RETRANS_INTERVAL 10 12000 milliseconds
RECONF_MMSG_MIN_RESP 11 2000 milliseconds
RECONF_MMSG_MAX_RESP 12 10000 milliseconds
MIN_SOLICIT_DELAY 13 1000 millisecond
MAX_SOLICIT_DELAY 14 5000 milliseconds
XID_TIMEOUT 15 600000 milliseconds
RECONF_MULTICAST_REQUEST_WAIT 16 120000 miliseconds
All timing parameters are measured in milliseconds. DHCP
clients MUST be able to process this extension when part
of a DHCP Reply message, and be able to reconfigure their
values for DEFAULT_SOLICIT_HOPCOUNT, REQUEST_MSG_MIN_RETRANS,
and REPLY_MSG_TIMEOUT, REPLY_MSG_RETRANS_INTERVAL, and
RECONF_MULTICAST_REQUEST_WAIT. Servers MAY refuse client
requests for configuration of the server's internal configuration
variables. Alternatively, a server MAY keep separate configuration
variables for any requesting client that are different than for
clients which do not make such requests.
7.3. Platform Specific Information
A platform is defined as the combination of hardware and operating
system (OS).
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 7.4). Clients which
do not receive platform specific information SHOULD make an attempt
Perkins, Bound Expires 25 August 1999 [Page 23]
Internet Draft DHCPv6 Extensions 25 February 1999
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 DHCPv6 extensions. Extension
65535 (END), if present, signifies the end of the encapsulated
platform extensions, not the end of the platform extensions field.
If no extension 65535 is present, then the end of the enclosing
platform-specific information field is taken as the end of the
encapsulated platform-specific extensions field.
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 = 48 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 4.
When encapsulated platform-specific extensions are used, each one
has the same format as for general DHCP extensions, as defined
in section 2. In other words, all platform-specific extensions
are encoded in Type-Length-Value (TLV) format. More than one
platform-specific extension can, therefore, be included in the same
DHCP "Platform Specific Information" extension.
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.
7.4. Platform Class Identifier
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.
Perkins, Bound Expires 25 August 1999 [Page 24]
Internet Draft DHCPv6 Extensions 25 February 1999
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.
Note that unlike the User Class Identifier, the Platform Class
Identifier does not need to be echoed back to the 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 = 49 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The platform class identifier is a string of 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, we recommend that platform vendors prefix their Platform
Class Identifiers with their Stock symbol or some other globally
recognized authority. For example, Platform Class Identifiers for
Sun Microsystems Inc platforms would be prefaced by "SUNW", the
NASDAQ stock symbol for Sun.
7.5. Class Identifier
This extension is used by a DHCP client to optionally identify the
type or category of user or applications it represents.
DHCP administrators may define specific class identifiers to convey
information about a client's software configuration or about its
user's preferences. For example, an identifier may specify that
a particular DHCP client is a member of the class "accounting
auditors", which have special service needs such as a particular
database server. Alternatively, the identifier may encode the
client's hardware configuration.
Servers not equipped to interpret the 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 class identifier specified by the
client. Further, if the server responds with the set of extensions
Perkins, Bound Expires 25 August 1999 [Page 25]
Internet Draft DHCPv6 Extensions 25 February 1999
corresponding to the given class identifier, it MUST return this
extension (with the given class identifier value) to the 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 = 64 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The class identifier is a string of Length octets. The class
identifier represents the class identifier of which the client is a
member.
7.6. Reconfigure Multicast Address
A DHCPv6 server can instruct its clients to join a multicast group
for the purposes of receiving DHCPv6 Reconfigure messages. This will
allow a server to reconfigure all of its clients at once; such a
feature will be useful when renumbering becomes necessary.
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 = 66 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reconfigure Multicast Address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.7. Renumber DHCPv6 Server Address
A DHCPv6 server can instruct its clients to change their internal
records to reflect the server's newly renumbered IP address, by using
the Renumber DHCPv6 Server Address extension. This extension may be
sent with the DHCP Reconfigure message, and thus can be multicast
to all of the server's clients instead of being unicast to each one
individually.
Perkins, Bound Expires 25 August 1999 [Page 26]
Internet Draft DHCPv6 Extensions 25 February 1999
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 = 67 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New DHCPv6 Server Address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.8. DHCP Relay ICMP Error Message Format
A DHCP Relay ICMP Message extension is used to inform a client of an
ICMP Error message received by the relay after forwarding a client
Solicit or Request message. A node which is not a DHCP Relay MUST
NOT transmit this extension in any DHCP 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 = 68 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Error Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length of the DHCP Relay ICMP Message extension is the length of
the ICMP error message received by the relay [9].
7.8.1. ICMP Extension Client Considerations
When a client sends a Solicit or Request message it may often be
forwarded by a relay. When the relay forwards messages for a client
the network may return an ICMP error [9] message to the relay. The
relay determines the client's link-local address within the UDP
payload of the ICMP returned error message payload, and sends the
client a DHCP Relay ICMP Error message as defined in section 7.8.2.
The client MAY record these messages based on the ICMP type and
reason codes provided in the ICMP Error payload [9], for future use
or for system logging purposes. How the client uses this information
is implementation dependent.
7.8.2. ICMP Extension Relay Considerations
If the relay receives an ICMP error message after forwarding a
client's DHCP Solicit or Request message, it MUST inspect the
Perkins, Bound Expires 25 August 1999 [Page 27]
Internet Draft DHCPv6 Extensions 25 February 1999
payload of the ICMP message [9], to determine the client's link-local
address. The relay MUST check that it is a link-local address; if
not, the ICMP error message MUST be silently discarded. Otherwise,
the relay should forward the ICMP Error message to the client as
specified in section 7.8.1, by using the client's link-local address
from the ICMP error message as the IP destination address in the
IP header sent to the client. If the relay cannot determine the
client's link-local address in the ICMP error message the packet MUST
be silently discarded.
7.9. Client-Server Authentication Extension
Exactly one Client-Server Authentication Extension MAY be present
in any DHCPv6 message transmitted between a client and server (or
vice-versa). If present, it MUST be the last 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 = 84 | 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 [2] identifying a security
context from among those available between the DHCPv6
client and server.
Replay Protection
A 64-bit timestamp (in Network Time Protocol [21](NTP)
format) (see section 10.1).
Authenticator
(variable length) (See Section 10.2.)
This authentication extension remedies the inability of IPsec [17]
to provide for non end-to-end authentication, since authentication
is needed even when the client has no IPv6 address of large enough
scope to reach the DHCP server. The extension can be originated by
Perkins, Bound Expires 25 August 1999 [Page 28]
Internet Draft DHCPv6 Extensions 25 February 1999
either the client or server to authenticate the rest of the data in
the DHCPv6 message. The default authentication algorithm, which MUST
be supported by all clients and servers, is defined in section 10.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., [16]).
7.10. Client Key Selection Extension
A DHCPv6 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 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 = 85 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SPI is a Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts available in the
security association defined between the DHCPv6 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., [14]).
8. End Extension
The end extension marks the end of valid information in the vendor
field. The Type for the end extension is 65535, and its Length is 2
octets; there is no Length field for the end extension.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perkins, Bound Expires 25 August 1999 [Page 29]
Internet Draft DHCPv6 Extensions 25 February 1999
9. Resource-Server Associations
Some extensions may cause a client to receive allocated resources.
When the client wishes to release such resources before the
allocation has expired, the client will need to contact the server
which allocated that resource. Thus, the resource needs to be
associated to the server that made the allocation. This association
is maintained in a data structure called a resource-server
association for the appropriate extensions.
The only extension currently defined which requires the maintenance
of such a resource-server association is the IP Address extension,
which is extension type 1 (see section 3).
10. Security Considerations
A security protocol is urgently needed for use with DHCPv6, 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 7.9. See also the
Security Considerations in the companion specification [4].
10.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [21](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.
10.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [18], using
keyed-MD5 [24]. Given a secret key K, and "data" the information to
be authenticated, HMAC_result is computed as follows:
1. opad := 0x36363636363636363636363636363636 (128 bits)
2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
3. zero_extended_key := K extended by zeroes to be 128 bits long
Perkins, Bound Expires 25 August 1999 [Page 30]
Internet Draft DHCPv6 Extensions 25 February 1999
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 DHCPv6 message and extensions. The
authenticator is the 128-bit value HMAC_result.
11. IANA Considerations
This document MAY be superseded by new documents for DHCPv6
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" [16]. 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
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.
Perkins, Bound Expires 25 August 1999 [Page 31]
Internet Draft DHCPv6 Extensions 25 February 1999
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.
12. 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.
13. 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
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.
Perkins, Bound Expires 25 August 1999 [Page 32]
Internet Draft DHCPv6 Extensions 25 February 1999
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."
Perkins, Bound Expires 25 August 1999 [Page 33]
Internet Draft DHCPv6 Extensions 25 February 1999
References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993.
[2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-14.txt, February 1999. (work
in progress).
[5] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications. draft-ietf-dhc-timezone-01.txt, January 1997.
(work in progress).
[7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996.
[8] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885,
December 1995.
[9] A. Conta and S. Deering. RFC 2463: Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification, December 1998. Obsoletes RFC1885 [8]. Status:
DRAFT STANDARD.
[10] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995.
[11] S. Deering and R. Hinden. RFC 2460: Internet Protocol, Version
6 (IPv6) specification, December 1998. Obsoletes RFC1883 [10].
Status: DRAFT STANDARD.
[12] E. Guttman, C. Perkins, and J. Kempf. Service Templates and
service: Schemes. draft-ietf-svrloc-service-scheme-05.txt,
November 1997. (work in progress).
[13] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txt,
March 1998. (work in progress).
Perkins, Bound Expires 25 August 1999 [Page 34]
Internet Draft DHCPv6 Extensions 25 February 1999
[14] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994.
[15] IEEE. 1003.1 POSIX Timezone Specification, 1988.
[16] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
May 1998.
[17] Stephen Kent and Randall Atkinson. IP Authentication Header.
draft-ietf-ipsec-auth-header-07.txt, July 1998. (work in
progress).
[18] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997.
[19] Sun Microsystems. System and Network Administration, March
1992.
[20] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI. RFC 2030, October 1996.
[21] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March
1992.
[22] P. Mockapetris. Domain Names - Concepts and Facilities. IETF
STD 13, November 1987.
[23] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2,
October 1994.
[24] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992.
[25] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. RFC 1971, August 1996.
[26] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address
autoconfiguration, December 1998. Obsoletes RFC1971 [25].
Status: DRAFT STANDARD.
[27] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997.
[28] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
in the Domain Name System (DNS). RFC 2136, April 1997.
Perkins, Bound Expires 25 August 1999 [Page 35]
Internet Draft DHCPv6 Extensions 25 February 1999
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
Author's Addresses
Questions about this memo can be directed to:
Charles E. Perkins Jim Bound
Sun Microsystems Laboratories Compaq Computer Corporation
Mail Stop MPK15-214, Room 2682 ZKO3-3/U14
15 Network Circle 110 Spitbrook Road
Menlo Park, CA 94025 Nashua, NH 03062
USA USA
Phone: +1 650 786-6464 Phone: +1-603-884-0400
EMail: cperkins@eng.sun.com EMail: bound@zk3.dec.com
Fax: +1 650 786-6445
web: http://www.svrloc.org/~charliep
Perkins, Bound Expires 25 August 1999 [Page 36]