draft-ietf-dhc-v6exts-09.txt   draft-ietf-dhc-v6exts-10.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems INTERNET DRAFT Sun Microsystems
13 March 1998 8 July 1998
Extensions for the Dynamic Host Configuration Protocol for IPv6 Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-v6exts-09.txt draft-ietf-dhc-v6exts-10.txt
Status of This Memo Status of This Memo
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Working Group of the Internet Engineering Task Force (IETF).
Comments should be submitted to the dhcp-v6@bucknell.edu mailing Comments should be submitted to the dhcp-v6@bucknell.edu mailing
list. list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6) The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6)
provides a framework for passing configuration information to hosts provides a framework for passing configuration information to hosts
on a TCP/IP network. Configuration parameters and other control on a TCP/IP network. Configuration parameters and other control
information are carried in typed data items that are stored in the information are carried in typed data items that are stored in the
"extensions" field of the DHCPv6 message. The data items themselves "extensions" field of the DHCPv6 message. The data items themselves
are also called "extensions." are also called "extensions."
This document specifies the current set of DHCPv6 extensions. This This document specifies the current set of DHCPv6 extensions. This
document will be periodically updated as new extensions are defined. document will be periodically updated as new extensions are defined.
Each superseding document will include the entire current list of
valid extensions. The method for specifying new extensions is also
included in this document.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. DHCPv6 Extension Field Format 2 2. DHCPv6 Extension Field Format 1
2.1. Character Encoding and String Issues . . . . . . . . . . 2
2.2. Typed Scope Lists . . . . . . . . . . . . . . . . . . . . 3
3. IP Address Extension 4 3. IP Address Extension 2
3.1. Client Considerations for the IP Address extension . . . 7 3.1. Client Considerations for the IP Address extension . . . 6
3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 7 3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6
3.1.2. Use with the DHCP Request message . . . . . . . . 8 3.1.2. Use with the DHCP Request message . . . . . . . . 6
3.1.3. Receiving as part of the DHCP Reply message . . . 9 3.1.3. Receiving as part of the DHCP Reply message . . . 7
3.1.4. Use with the DHCP Release message . . . . . . . . 10 3.1.4. Use with the DHCP Release message . . . . . . . . 8
3.2. Server Considerations for the IP Address extension . . . 10 3.2. Server Considerations for the IP Address extension . . . 8
3.2.1. Use with the DHCP Advertise message . . . . . . . 10 3.2.1. Use with the DHCP Advertise message . . . . . . . 8
3.2.2. Receiving a DHCP Request with the IP Address 3.2.2. Receiving a DHCP Request with the IP Address
Extension . . . . . . . . . . . . . . . . 10 Extension . . . . . . . . . . . . . . . . 9
3.2.3. Use with the DHCP Reply message . . . . . . . . . 11 3.2.3. Use with the DHCP Reply message . . . . . . . . . 9
3.2.4. Use with the DHCP Reconfigure message . . . . . . 12 3.2.4. Use with the DHCP Reconfigure message . . . . . . 10
3.2.5. Receiving a DHCP Release with the IP Address 3.2.5. Receiving a DHCP Release with the IP Address
Extension . . . . . . . . . . . . . . . . 12 Extension . . . . . . . . . . . . . . . . 10
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 12 3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 10
4. General Extensions 12 4. General Extensions 11
4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 13 4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 11
4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 13 4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 12
4.2.2. An Example . . . . . . . . . . . . . . . . . . . 15 4.2.2. An Example . . . . . . . . . . . . . . . . . . . 13
4.2.3. Timezone Extension Precedence . . . . . . . . . . 15 4.3. Domain Name Server Extension . . . . . . . . . . . . . . 13
4.3. Domain Name Server Extension . . . . . . . . . . . . . . 15 4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 16
5. Application and Service Parameters 16 5. Application and Service Parameters 14
5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 16 5.1. Service Location Protocol extensions . . . . . . . . . . 14
5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 18 5.1.1. Typed Scope Lists . . . . . . . . . . . . . . . . 14
5.3. Network Time Protocol Servers Extension . . . . . . . . . 19 5.1.2. Directory Agent Extension . . . . . . . . . . . . 16
5.4. Network Information Service Domain Extension . . . . . . 19 5.1.3. Service Scope Extension . . . . . . . . . . . . . 17
5.5. Network Information Servers Extension . . . . . . . . . . 20 5.2. Network Time Protocol Servers Extension . . . . . . . . . 18
5.6. Network Information Service+ Domain Extension . . . . . . 20 5.3. Network Information Service (NIS and NIS+) extensions . . 19
5.7. Network Information Service+ Servers Extension . . . . . 20 5.3.1. NIS Domain Extension . . . . . . . . . . . . . . 19
6. TCP Parameters 21 5.3.2. NIS Servers Extension . . . . . . . . . . . . . . 19
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21 5.3.3. NIS+ Domain Extension . . . . . . . . . . . . . . 19
5.3.4. NIS+ Servers Extension . . . . . . . . . . . . . 20
6. TCP Parameters 20
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 20
7. DHCPv6 Extensions 21 7. DHCPv6 Extensions 21
7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 21 7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 21
7.2. Platform Specific Information . . . . . . . . . . . . . . 22 7.2. DHCP Retransmission and Configuration Parameter Extension 21
7.3. Platform Class Identifier . . . . . . . . . . . . . . . . 23 7.3. Platform Specific Information . . . . . . . . . . . . . . 22
7.4. Class Identifier . . . . . . . . . . . . . . . . . . . . 24 7.4. Platform Class Identifier . . . . . . . . . . . . . . . . 23
7.5. Reconfigure Multicast Address . . . . . . . . . . . . . . 25 7.5. Class Identifier . . . . . . . . . . . . . . . . . . . . 24
7.6. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 25 7.6. Reconfigure Multicast Address . . . . . . . . . . . . . . 25
7.7. DHCP Relay ICMP Error Message Format . . . . . . . . . . 25 7.7. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 25
7.7.1. ICMP Extension Client Considerations . . . . . . 26 7.8. DHCP Relay ICMP Error Message Format . . . . . . . . . . 26
7.7.2. ICMP Extension Relay Considerations . . . . . . . 26 7.8.1. ICMP Extension Client Considerations . . . . . . 26
7.8. Client-Server Authentication Extension . . . . . . . . . 26 7.8.2. ICMP Extension Relay Considerations . . . . . . . 26
7.9. Client Key Selection Extension . . . . . . . . . . . . . 27 7.9. Client-Server Authentication Extension . . . . . . . . . 27
7.10. Client Key Selection Extension . . . . . . . . . . . . . 28
8. End extension specification 28 8. End Extension 28
9. Security Considerations 28 9. Resource-Server Associations 28
9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
9.2. Default Authentication Algorithm . . . . . . . . . . . . 29
10. Defining New Extensions 29 10. Security Considerations 29
10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
10.2. Default Authentication Algorithm . . . . . . . . . . . . 29
11. Acknowledgements 31 11. IANA Considerations 30
Chair's Address 33 12. Acknowledgements 31
Author's Address 33 13. Full Copyright Statement 31
Chair's Address 34
Author's Address 34
1. Introduction 1. Introduction
This document specifies extensions for use with the Dynamic This document specifies extensions for use with the Dynamic Host
Host Configuration Protocol for IP version 6, DHVPv6. The full Configuration Protocol for IP version 6, DHCPv6. DHCPv6 message
description of DHCPv6 message formats may be found in the DHCPv6 formats are described in the DHCPv6 specification document [4]. In
specification document [4]. In this document, several words are used this document, several words are used to signify the requirements
to signify the requirements of the specification, in accordance with of the specification, in accordance with RFC 2119 [5]. These words
RFC 2119 [5]. These words (MUST, SHOULD, MAY, MUST NOT, etc) are (MUST, SHOULD, MAY, MUST NOT, etc) are often capitalized.
often capitalized.
This document defines the format of information in the last field This document defines the overall format of information in the
of DHCPv6 messages ('extensions'). The extensions defined within 'extensions' field of DHCPv6 messages. The extensions defined
this document specify a generalized use of this area for giving within this document specify a generalized way to distribute
information useful to a wide class of machines, operating systems information useful to a wide class of machines, operating systems
and configurations. Sites with a single DHCPv6 server that is and configurations. Sites with a DHCPv6 server that is shared among
shared among heterogeneous clients may choose to define other, site- heterogeneous clients may choose to define other, site-specific
specific formats for the use of the 'extensions' field. formats for the use of the 'extensions' field.
Section 2 of this memo describes the formats of DHCPv6 extensions. Section 2 of this memo describes the formats of DHCPv6 extensions.
Information on registering new extensions is contained in section 10. Information on registering new extensions is contained in section 11.
The other sections organize the format descriptions of various The other sections organize the format descriptions of various
extensions according to their general type, as follows: extensions according to their general type, as follows:
- IP Address extension - IP Address extension
- Miscellaneous host configuration - General host configuration
- Service Location configuration
- Miscellaneous network layer - Application and Service Parameters
- TCP - TCP
- Vendor Specific
- DHCPv6 - DHCPv6
Future applications will make extensive use of an ever-increasing Future applications will make extensive use of an ever-increasing
number and variety of network services. It is expected that client number and variety of network services. It is expected that client
needs for creating connections with these future network services needs for creating connections with these future network services
will be satisfied by the Service Location Protocol [24], and not will be satisfied by the Service Location Protocol [24], and not
DHCPv6. DHCP is expected to be used for the kinds of configuration DHCPv6. DHCP is expected to be used for the kinds of configuration
that enable clients to become fully functional as self-contained that enable clients to become fully functional as self-contained
network entities, but not the kinds of configuration that might be network entities, but not the kinds of configuration that might be
required by applications running above the network or transport layer required by applications running above the network or transport layer
protocol levels. protocol levels.
2. DHCPv6 Extension Field Format 2. DHCPv6 Extension Field Format
Extensions may be fixed length or variable length. All extensions Extensions may be fixed length or variable length. All extensions
begin with a type field, which is two octets long and uniquely begin with a type field, which is two octets long and uniquely
identifies the extension. Fixed length extensions without data identifies the extension. Every extension, except extension number
consist of only the two octet type field. Only extension 65535 is 65535, has a two octet unsigned integer Length field following the
fixed length. All other extensions are variable length with a two type field. The value of the Length field does not include the
octet unsigned integer Length field following the type octets. The four octets specifying the type and length. For some extensions
value of the Length field does not include the four octets specifying the Length field is always the same number, but it MUST still be
the type and length. The Length field is followed by "length" octets specified. In each case, unless otherwise specified, the Length
of data. In the case of some extensions the length field is a field specifies the length of the extension data in octets. There
constant but MUST still be specified. In each case, unless otherwise is no particular requirement for alignment of data fields within
specified, the length field specifies the length of the extension in existing DHCPv6 extensions. Any extensions defined subsequent to
octets. Any extensions defined subsequent to this document should this document MUST contain a two-octet Length field even if the
contain a Length field even if the length is fixed or zero. There length is fixed or zero.
is no particular requirement for alignment of the data fields within
existing DHCPv6 extensions.
Unrecognized extensions SHOULD be skipped by ignoring the number of Unrecognized extensions SHOULD be ignored by skipping over the number
octets specified in the length field, and processing continued for of octets specified in the length field, and processing continued for
subsequent extensions. Unless and until specified otherwise by use subsequent extensions. Unless and until specified otherwise by use
of extension type 64 (see section 7.1), DHCP entities MUST assume of extension type 64 (see section 7.1), DHCP entities MUST assume
that that the maximum DHCP message size including extensions is 1500 that that the maximum DHCP message size including extensions is 1500
octets. octets.
All multi-octet quantities are in network byte-order. All multi-octet quantities are in network byte-order.
Extension types 32768 to 65534 (decimal) are reserved for Extension types 32768 to 65534 (decimal) are reserved for
site-specific extensions. site-specific extensions.
All of the extensions described in this document will also have their All of the extensions described in this document will also have their
default values specified, if any. Whenever an extension is received default values specified, if any. Whenever an extension is received
as part of a DHCP message, any reserved fields of the message MUST as part of a DHCP message, any reserved fields of the message MUST
be ignored, and processing continued as if the reserved fields were be ignored, and processing continued as if the reserved fields were
zero. zero. Typically, the value of the Type field is shown directly in
the format illustration, and for some fixed-length extensions the
2.1. Character Encoding and String Issues value of the Length field is also shown in the format illustration
for the extension.
Certain extensions (e.g., type 16 described in section 5.1) have
fields which can use various character encodings. Values for
character encoding can be found in the Internet Assigned Numbers
Authority's (IANA) database
http://www.isi.edu/in-notes/iana/assignments/character-sets
and have the values referred by the MIBEnum value. Note that in some
character sets, each character may require two or more octets of data
for its representation.
The encoding will determine the interpretation of all character data
in the corresponding fields of particular extensions. There is no
way to mix US-ASCII and UNICODE, for example. All responses MUST be
in the character set of the request or use US-ASCII. If a request is
sent to a DHCP server, which is unable to manipulate or store the
character set of the incoming message, the request will fail. The
server returns a status code of 24 in a DHCP Reply message in this
case. Requests using US-ASCII (MIBEnum value == 3) will never fail
for this reason, since all DHCP entities MUST be able to accept this
character set. All DNS-related strings are presumed to be encoded in
US-ASCII.
2.2. 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 DHCPOFFER 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 in a DHCPREQUEST 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 [10], and a scope-item has
the format defined in [11] 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.
As an example, the scope-list ``A,B,C'' denotes scopes A, B and C
for all service types on the client. In a DHCPREQUEST, this scope
string would indicate that the client wishes a directory agent which
supports ANY of these three scopes. In a DHCPOFFER, 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 DHCPOFFER
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 DHCPREQUEST could be,
(netman=),(proxystuff=)
asking for scopes for those service types. All strings are encoded in UTF-8, which includes US-ASCII as a
subset.
3. IP Address Extension 3. IP Address Extension
The IP Address extension is the most essential of all the DHCPv6 The IP Address extension is the most essential of all the DHCPv6
extensions. It can be used by both client and server in various 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 ways. Since the IP Address extension can be used more than once in
the same DHCP message, all information relevant to a particular IPv6 the same DHCP message, all information relevant to a particular IPv6
allocation has to be collected together in the same extension. Some allocation has to be collected together in the same extension. Some
of the fields within the IP Address extension can specify how DNS may of the fields within the IP Address extension can specify how DNS may
be updated [25]. be updated [25].
skipping to change at page 5, line 8 skipping to change at page 3, line 13
address field. To request the allocation of a new but unspecified IP address field. To request the allocation of a new but unspecified IP
address, the client omits the client address field. The IP address address, the client omits the client address field. The IP address
returned by the server in the latter case will be compatible with a 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. routing prefix of the link to which the client is currently attached.
An IP Address Extension can contain at most one IP address. To An IP Address Extension can contain at most one IP address. To
specify more than one IP address, multiple extensions are used. specify more than one IP address, multiple extensions are used.
0 1 2 3 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 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 | Length | | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status |C|L|Q|A|P| reserved | pfx-size | | status |C|L|Q|A|P| reserved | prefix-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| client address (16 octets) | | client address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) preferred lifetime (4 octets) | | (if present) preferred lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) valid lifetime (4 octets) | | (if present) valid lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) DNS name (variable length) ... | (if present) DNS name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 50 skipping to change at page 4, line 7
A If the 'A' bit is set, the client requests that that A If the 'A' bit is set, the client requests that that
the the server updates DNS with a new AAAA record, as the the server updates DNS with a new AAAA record, as
specified by the client's FQDN. specified by the client's FQDN.
P If the 'P' bit is set, the client requests that that P If the 'P' bit is set, the client requests that that
the the server updates DNS with a new PTR record, as the the server updates DNS with a new PTR record, as
specified by the client's FQDN. specified by the client's FQDN.
reserved MUST be zero. reserved MUST be zero.
pfx-size prefix-size
If the client address is present (the 'C' bit is set), a If the client address is present (the 'C' bit is set), a
nonzero pfx-size is the number of leftmost bits of the nonzero prefix-size is the number of leftmost bits of the
client's IPv6 address which make up the routing prefix. client's IPv6 address which make up the routing prefix.
Otherwise, if the 'C' bit is not set, pfx-size MUST be Otherwise, if the 'C' bit is not set, prefix-size MUST be
zero. zero.
client address client address
The IP address to be allocated by the server for use by The IP address to be allocated by the server for use by
the client (16 octets long). the client (16 octets long).
preferred lifetime preferred lifetime
The preferred lifetime of the IP address in seconds The preferred lifetime of the IP address in seconds
valid lifetime valid lifetime
skipping to change at page 6, line 26 skipping to change at page 4, line 32
The valid lifetime of the IP address in seconds The valid lifetime of the IP address in seconds
DNS name DNS name
The DNS name (a string of ASCII octets) to be used by the The DNS name (a string of ASCII octets) to be used by the
client (variable length). client (variable length).
The following values for the status field are defined within this The following values for the status field are defined within this
document: document:
0 request granted, no errors 0 request granted, no errors
18 Security parameters failed for this client 18 Security parameters failed for this client
20 Resource AAAA Record Parameter Problem 20 Resource AAAA Record Parameter Problem
21 Resource PTR Record Parameter Problem 21 Resource PTR Record Parameter Problem
22 Unable to honor required extension parameters 22 Unable to honor required extension parameters
23 DNS name string error 23 DNS name string error
24 dynDNS Not Implemented 24 dynDNS Not Implemented
25 Authoritative DNS Server could not be found 25 Authoritative DNS Server could not be found
33 The name server was unable to interpret the request 33 The name server was unable to interpret the request
due to a format error. due to a format error.
34 dynDNS Not Available at this time (SERVFAIL)
34 dynDNS unavailable at this time (SERVFAIL)
35 Some name that ought to exist, does not exist 35 Some name that ought to exist, does not exist
(NXDOMAIN) (NXDOMAIN)
36 The name server does not support the specified Opcode 36 The name server does not support the specified Opcode
(NOTIMP) (NOTIMP)
37 The name server refuses to perform the specified 37 The name server refuses to perform the specified
operation for policy or security reasons (REFUSED) operation for policy or security reasons (REFUSED)
38 Some name that ought not to exist, does exist 38 Some name that ought not to exist, does exist
(YXDOMAIN) (YXDOMAIN)
39 Some RRset that ought not to exist, does exist 39 Some RRset that ought not to exist, does exist
(YXRRSET) (YXRRSET)
40 Some RRset that ought to exist, does not exist 40 Some RRset that ought to exist, does not exist
(NXRRSET) (NXRRSET)
41 The server is not authoritative for the zone named in 41 The server is not authoritative for the zone named in
the Zone Section (NOTAUTH) the Zone Section (NOTAUTH)
42 A name used in the Prerequisite or Update Section 42 A name used in the Prerequisite or Update Section
is not within the zone denoted by the Zone Section is not within the zone denoted by the Zone Section
(NOTZONE) (NOTZONE)
Status values 33 through 42 are described more fully within RFC
2136 [25]. Up-to-date values for the values of the status field are
specified in the most recent "Assigned Numbers" [20]. To inform the
client of the DYNDNS [25] error return codes (i.e., nonzero return
codes) received by the DHCPv6 server the client MUST assume the
status codes 32 through 42 are formed as follows:
status code = 32 + DYNDNS Error Code Status values 33 through 42 are described more fully within Dynamic
Updates to DNS (RFC 2136 [25]). Up-to-date values for the values
of the status field are specified in the most recent "Assigned
Numbers" [21].
The DNS name can be a host name, which does not contain the '.' The DNS name can be a host name, which does not contain the '.'
ASCII character as a separator between DNS hierarchy components. Any ASCII character as a separator between DNS hierarchy components. Any
name containing the '.' is treated as a Fully Qualified Domain Name name containing the '.' is treated as a Fully Qualified Domain Name
(FQDN). The length of the DNS name may be determined by subtracting, (FQDN). The length of the DNS name may be determined by subtracting,
from the Length, the length of those fixed length fields which are from the Length, the length of those fixed length fields which are
present. present.
If the 'Q' bit is set, the values or actions requested by the C, L, 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 A, and P bits are required, and MUST be provided, or the extension
MUST be rejected with status code 22. 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 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 ensure that the DNS is updated with a new AAAA record, as specified
by the client's FQDN, before responding with the corresponding DHCP 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 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 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 record, as specified by the client's FQDN, before responding with the
corresponding DHCP Reply. corresponding DHCP Reply.
A DHCP client can include an IP address in its IP Address extension 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 and set the 'A' bit and/or 'P' bit to ask the DHCP Server to use that
address for updating DNS. This can be done even with IP addresses address for updating DNS. This MAY be done even with IP addresses
obtained by Stateless Address Autoconfiguration [23]. If the client obtained by Stateless Address Autoconfiguration [23]. If the client
wishes to have its FQDN associated with one of several existing IP wishes to have its FQDN associated with one of several existing IP
addresses which it has received from the DHCP Server, the client MUST addresses which it has received from the DHCP Server, the client MUST
supply that IP address in the IP address extension along with the supply that IP address in the IP address extension along with the
FQDN. FQDN.
3.1. Client Considerations for the IP Address extension 3.1. Client Considerations for the IP Address extension
3.1.1. Address Lifetimes 3.1.1. Address Lifetimes
An IP address returned to a client has a preferred and valid An IP address returned to a client in a DHCP Reply message has a
lifetime. The valid lifetime represents the lease for addresses preferred and valid lifetime. The valid lifetime represents the
provided to the client, from the server. lease for addresses provided to the client, from the server. The
client MAY request values for the lifetimes, but the client MUST use
The client SHOULD make a new Request for any address that is about the lifetimes provided by the server response.
to expire, or request a new address or the same address before the
lease actually expires. If the client does not make a new Request
for an address, the server SHOULD assume the client does not want
that address. The server MAY provide that address to another client
requesting an address.
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 When the preferred lifetime of an IP address expires, the client's
address becomes a deprecated address. See [9] for required handling address becomes a deprecated address. See [9] for required handling
of deprecated IP addresses. Before an address for a DHCPv6 client's of deprecated IP addresses. Before an address for a DHCPv6 client's
interface becomes deprecated, the client SHOULD request a new address interface becomes deprecated, the client SHOULD request a new address
for that interface, or make a new DHCP Request for the existing for that interface, or make a new DHCP Request for the existing
address (which can result in the address receiving an updated address (which can result in the address receiving an updated
preferred lifetime). 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.
When the client requests an IP address from the DHCPv6 server, the When the client requests an IP address from the DHCPv6 server, the
client MUST keep track of when the request was issued. When the client MUST keep track of when the request was issued. When the
client receives a successful reply from the DHCPv6 server, it MUST client receives a successful reply from the DHCPv6 server, it MUST
decrement the received Lifetimes by the amount of time between decrement the received Lifetimes by the amount of time between
the transmission of the DHCP Request and the reception of the the transmission of the DHCP Request and the reception of the
corresponding DHCP Reply. In this way, the client is best assured corresponding DHCP Reply. In this way, the client may expect that
that its address lifetimes will not expire at the DHCP Server before its address lifetimes will not expire at the DHCP Server before they
they expire at the client. expire at the client.
3.1.2. Use with the DHCP Request message 3.1.2. Use with the DHCP Request message
In a DHCP Request (for each address extension), a client MUST set the In a DHCP Request (for each address extension), a client MUST set the
status code to zero. status code to zero.
In a DHCP Request (for each address extension), a client MAY: 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 - include an IP address and/or a DNS name (which may be a host name
or a FQDN). or a FQDN).
- set the prefix-size field to zero. If nonzero, the IP address
MUST be included, and the 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 - set the 'A' bit to request that the server update DNS with a new
AAAA record, as specified by the client's FQDN; if the 'Q' bit is AAAA record, as specified by the client's FQDN; if the 'Q' bit is
also set, this update MUST be completed before responding with also set, this update MUST be completed before responding with
the corresponding DHCP Reply. the corresponding DHCP Reply.
- set the 'P' bit to request that the server update DNS with a new - set the 'P' bit to request that the server update DNS with a new
PTR record, as specified by the client's FQDN; if the 'Q' bit is PTR record, as specified by the client's FQDN; if the 'Q' bit is
also set, this update MUST be completed before responding with also set, this update MUST be completed before responding with
the corresponding DHCP Reply. the corresponding DHCP Reply.
- indicate the minimum preferred (and/or valid) lifetime, by - indicate the minimum preferred (and/or valid) lifetime, by
supplying a value for the field(s). supplying a value for the field(s).
- specify whether address, name and lifetimes (if present) are - specify whether address, name and lifetimes (if present) are
advisory -or- mandatory, by setting the 'Q' bit. advisory -or- mandatory, by setting the 'Q' bit.
If the Request is advisory, a server may send different parameters
than requested in the DHCP Reply. Otherwise, if the Request is
mandatory, 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.
A client may include multiple IP Address extensions in a single DHCP A client may include multiple IP Address extensions in a single DHCP
Request. The server that receives the Request is not absolutely Request. A client indicates that it cannot accept any configuration
required to honor the client's Request. A DHCP client indicates that information other than that listed in the IP Address extension (e.g.,
it cannot accept anything other than the configuration information IP address) to the DHCP Request, by specifying the 'Q' (Required)
(e.g., IP address) listed in the IP Address extension to the DHCP bit.
Request, by specifying the 'Q' (Required) bit.
When a client requests an IP address, it MUST maintain a record for If the information in the IP extension is advisory, a server may send
the server which allocates that address, so that the client can (if different parameters than requested in the DHCP Reply. Otherwise,
necessary) in the future 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 - Extend the lifetime with the same server, or
- Release the address, using DHCP Release. - Release the address, using DHCP Release.
3.1.3. Receiving as part of the DHCP Reply message 3.1.3. Receiving as part of the DHCP Reply message
When the client receives an IP address extension as part of a DHCP When the client receives an IP address extension as part of a DHCP
Reply which it accepts (see [4]), it first inspects the status to see Reply [4], it first inspects the status to see whether the requested
whether the requested information has been granted. If the status is information has been granted. If the status is nonzero, the client
nonzero, the client should log the error, display the error condition should log the error, and display the error condition for action
for action by the user and/or the network administrator. Nonzero by the user and/or the network administrator. Nonzero status
status almost always indicates that the client will be need to modify almost always indicates that the client will be need to modify its
its request before it could be satisfied by the replying DHCP server, request before it could be satisfied by the replying DHCP server, or
or alternatively that the replying DHCP server will need to be given alternatively that the replying DHCP server will need to be given
updated configuration information for the client. updated configuration information for the client.
Upon reception of a new IP address with a lifetime, the client MUST Upon reception of a new IP address with a lifetime, the client MUST
perform Duplicate Address Detection (DAD) [23]; however, if the perform Duplicate Address Detection (DAD) [23]; however, if the
address has already been allocated to the client and it is merely address has already been allocated to the client and it is merely
renewing the lifetime of the address, the client does not have to renewing the lifetime of the address, the client does not have to
perform DAD each time. If the client receives an IP address with perform DAD each time. If the client receives an IP address with
zero valid lifetime, the client MUST immediately discontinue using zero valid lifetime, the client MUST immediately discontinue using
that IP address. that IP address.
3.1.4. Use with the DHCP Release message 3.1.4. Use with the DHCP Release message
In DHCP Release (for each address extension): In a DHCP Release message, the client MUST provide at least one
specific IP address in the extension.
- the client may include an IP address and/or a DNS name (which may For each address extension:
be a host name or a FQDN).
- the server MUST update DNS to delete the AAAA record or records - the client may include a name (which may be a host name or a
that the server originally used when updating DNS when the FQDN).
address was allocated to the client, 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, took charge of the DNS updates, - if the server originally updated DNS with one or more AAAA
it MUST perform the corresponding deletions before issuing the records for allocated IP addresses, the server MUST update DNS to
DHCP Release. delete those records, and likewise for the PTR record (regardless
of the setting of the 'A' or 'P' bits in the address extension).
The client MUST provide a specific IP address in the 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 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 3.2.1. Use with the DHCP Advertise message
In DHCP Advertise (for each address extension), the Server can In DHCP Advertise (for each address extension), the Server can
indicate: indicate:
- the client's FQDN or host name - the client's FQDN or host name
- the preferred lifetime - the preferred lifetime
- the valid lifetime - the valid lifetime
skipping to change at page 11, line 11 skipping to change at page 9, line 26
requesting client and the link to which the client is attached. requesting client and the link to which the client is attached.
The link can be determined by the Agent address prefix in the DHCP 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 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 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 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. link when there is no server address included in the message header.
If the client has requested that the server perform DNS updates as If the client has requested that the server perform DNS updates as
part of the IP address allocation and configuration, the server part of the IP address allocation and configuration, the server
MUST maintain this fact as part of the client's binding. Then, if MUST maintain this fact as part of the client's binding. Then, if
the client eventually releases the IP address (see the DHCP Releas the client eventually releases the IP address (see the DHCP Release
message in [4]), the server MUST perform the reverse service by message in [4]), the server MUST perform the reverse service by
updating DNS again as needed. updating DNS again as needed.
3.2.3. Use with the DHCP Reply message 3.2.3. Use with the DHCP Reply message
In a DHCP Reply message (for each address extension) the server MUST In a DHCP Reply message (for each address extension) the server MUST
indicate in the IP address extension indicate in the IP address extension the following information:
- the preferred lifetime - the preferred lifetime
- the valid lifetime - the valid lifetime
- the status of the request - the status of the request
If the Reply is a response to a DHCP Release, the lifetimes MUST both If the Reply is a response to a DHCP Release, the lifetimes MUST both
be zero. be zero.
In a DHCP Reply message, for each address extension) the server MAY In a DHCP Reply message, for each address extension) the server MAY
indicate indicate the following information:
- the DNS name - the DNS name
- (by setting the 'A' bit) whether AAAA has been updated by the DNS - (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 - (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 If the client requests updates, and sets the 'Q' bit, the server MUST
NOT issue the DHCP Reply until after receiving positive indication NOT issue the DHCP Reply until after receiving positive indication
that the DNS update has indeed been performed. If the 'Q' bit has 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 been set, and the server cannot honor the IP address extension, it
MUST return a DHCP reply with the status 22. MUST return a DHCP reply with the status 22.
Otherwise, the client can subsequently update DNS if needed (i.e., Otherwise, the client MAY attempt to update DNS if needed.
the server didn't do it).
If the server receives a DHCP Request from one of its clients If the server receives a DHCP Request from one of its clients
whose address it wishes to invalidate, it can cause the client to whose address it wishes to invalidate, it can cause the client to
discontinue use of the old address by including valid and preferred discontinue use of the old address by including valid and preferred
lifetimes with a value of zero. lifetimes with a value of zero.
To perform renumbering, the server will include two IP address To perform renumbering, the server will include two IP address
extensions, one to reduce the the preferred lifetime and reduce the extensions, one to reduce the preferred and valid lifetimes for the
valid lifetime for the old address, and another to give the client old address, and another to give the client its new address.
its new address.
On a practical note, if the DHCP administrator uses site-local On a practical note, if the DHCP administrator uses site-local
addresses for IP address allocation to clients, there will be less addresses for IP address allocation to clients, there will be less
need for renumbering whenever the site moves to a new site prefix or 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 set of site prefixes. Of course, this only works when the site does
not need global addresses. not need global addresses.
3.2.4. Use with the DHCP Reconfigure message 3.2.4. Use with the DHCP Reconfigure message
In DHCP Reconfigure (for each address extension) the server MAY In DHCP Reconfigure (for each address extension) the server MAY
skipping to change at page 13, line 10 skipping to change at page 11, line 15
4. General Extensions 4. General Extensions
The following extensions are important for many DHCPv6 clients, and The following extensions are important for many DHCPv6 clients, and
are not specific to any upper-level protocol. are not specific to any upper-level protocol.
4.1. Time Offset 4.1. Time Offset
0 1 2 3 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 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 | Length | | Type = 2 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Offset | | Time Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for the time offset extension is 2, and its Length is 4 The time offset field specifies the offset of the client's clock
octets. The time offset field specifies the offset of the client's in seconds from Coordinated Universal Time (UTC). The offset is
clock in seconds from Coordinated Universal Time (UTC). The offset is
expressed as a signed (two's complement) 32-bit integer. expressed as a signed (two's complement) 32-bit integer.
4.2. IEEE 1003.1 POSIX Timezone extension 4.2. IEEE 1003.1 POSIX Timezone extension
DHCP includes an extension for the specification of the Universal Extension type 2, defined in section 4.1, specifies the Universal
Coordinated Time Offset (type 2, defined in section 4.1), which is Coordinated Time (UTC) offset. Unfortunately, the UTC offset
defined as a two's complement 32-bit integer representing the offset extension does not provide enough information for an Internet
in seconds from UTC. Unfortunately, the UTC offset extension does not client to determine such timezone-related details as the timezone
provide enough information for an Internet client to determine such names, daylight savings time start and end times in addition to the
timezone-related details as the timezone names, daylight savings time timezone UTC offsets. This extension (analogous to that proposed
start and end times in addition to the timezone UTC offsets. This for DHCPv4 [6]) allows delivery of timezone information in the form
extension (analogous to that proposed for DHCPv4 [6]) allows delivery of a IEEE 1003.1 POSIX Timezone specifier [13], as detailed in
of timezone information in the form of a IEEE 1003.1 POSIX Timezone section 4.2.1.
specifier [13].
0 1 2 3 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 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 | Length | | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE 1003.1 POSIX Timezone string (variable length) ... | IEEE 1003.1 POSIX Timezone string (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The extension type is 3. This IEEE 1003.1 POSIX Timezone is detailed If a DHCP client receives both the Time Offset (type 2) and the POSIX
next, in section 4.2.1. 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.
4.2.1. IEEE 1003.1 POSIX Timezone specifier 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.
. 4.2.1. IEEE 1003.1 POSIX Timezone specifier
The format of the IEEE 1003.1 POSIX timezone string is specified as The format of the IEEE 1003.1 POSIX timezone string is specified as
StdOffset[Dst[Offset],[Start[/Time],End[/Time]]] StdOffset[Dst[Offset],[Start[/Time],End[/Time]]]
where '[' and ']' enclose optional fields, '|' indicates choice where '[' and ']' enclose optional fields, '|' indicates choice
of exactly one of the alternatives, ',' and '/' represent literal of exactly one of the alternatives, ',' and '/' represent literal
characters present in the string, and: characters present in the string, and:
Std three or more octets for the standard timezone (Std). Std three or more octets for the standard timezone (Std).
Any characters (or case) except a leading colon, digits, Any characters (or case) except a leading colon, digits,
comma, minus or plus sign are allowed. comma, minus or plus sign are allowed.
Offset Indicates the value one must add to local time to Offset Indicates the value one must add to local time to
arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset
skipping to change at page 15, line 24 skipping to change at page 13, line 36
fourth or the fifth week. Week '1' is the first week in fourth or the fifth week. Week '1' is the first week in
which the 'd' day occurs. which the 'd' day occurs.
4.2.2. An Example 4.2.2. An Example
For Eastern USA time zone, 1986, the Posix timezone string is as For Eastern USA time zone, 1986, the Posix timezone string is as
follows: follows:
EST5EDT4,116/02:00:00,298/02:00:00 EST5EDT4,116/02:00:00,298/02:00:00
4.2.3. Timezone Extension Precedence Here, `5' is the Offset for Std, and `4' is the Offset for Dst.
Start is 16, and End is 298.
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.
4.3. Domain Name Server Extension 4.3. Domain Name Server Extension
0 1 2 3 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 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 | Length | | Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name System server addresses | | Domain Name System server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Domain Name Server extension specifies a list of Domain Name
The domain name server extension specifies a list of Domain Name System [20] name servers available to the client. Servers SHOULD be
System [19] name servers available to the client. Servers SHOULD be
listed in order of preference. listed in order of preference.
The Type for the domain name server extension is 6. The minimum The minimum Length for this extension is 16 octets, and MUST always
Length for this extension is 16 octets, and the Length MUST always be be a multiple of 16.
a multiple of 16.
4.4. Domain Name 4.4. Domain Name
This extension specifies the default domain name that client should This extension specifies the default domain name that client should
use when resolving hostnames via the Domain Name System. use when resolving hostnames via the Domain Name System.
0 1 2 3 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 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 | Length | | Type = 10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name (variable length) ... | Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 10. Its minimum Length is 1. The minimum Length for this extension is 1. The domain name is a
ASCII string, Length octets in size. If the Domain Name extension
The domain name is a ASCII string, Length octets in size. 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
If the Domain Name extension is not specified, and the IP Address the first '.' octet as the Domain Name.
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 5. Application and Service Parameters
This section details some miscellaneous extensions used to configure This section details some miscellaneous extensions used to configure
miscellaneous applications and services. miscellaneous applications and services.
5.1. Directory Agent Extension 5.1. Service Location Protocol extensions
Entities using the Service Location Protocol [24] need to find out This subsection describes DHCP extensions useful for a client to
the address of Directory Agents in order to transact messages. They begin operations using the Service Location Protocol (SLP) [24].
may need to discover the correct scope to be used in conjunction with
the service attributes which are exchanged using the Service Location
Protocol. The scope MAY be denoted in any standardized character
set.
This extension requests or specifies a Directory Agent (DA), along 5.1.1. Typed Scope Lists
with zero or more scopes supported by that DA. Note that this
extension MAY be included multiple times in the same DHCP Request or In Service Location Protocol, multiple service types can be hosted on
DHCP Reply. If so, then the extensions SHOULD be included in order the same network node. However, DHCP typically configures computers
of decreasing preference. 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
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 [10], and a scope-item has
the format defined in [11] 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.
5.1.2. Directory Agent Extension
Entities using the Service Location Protocol (SLP) [24] 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
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 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 | Length | | Type = 16 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|F|M|S| reserved | DA length | |D|F|M|T| reserved | DA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Directory Agent (variable length) ... | Directory Agent (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) Typed-Scope-List (variable length) ... | (if present) Typed-Scope-List (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16
Length (unsigned integer, variable) The length of the Extension Length (unsigned integer, variable) The length of the Extension
in octets. in octets.
D If the 'D' bit is set, the Directory Agent field and the D If the 'D' bit is set, the Directory Agent field and the
DA Length fields are present. DA Length fields are present.
F If the 'F' bit is set, the Directory Agent is indicated F If the 'F' bit is set, the Directory Agent is indicated
by including its variable length host name or Fully by including its variable length host name or Fully
Qualified Domain Name (FQDN) instead of its IP address. Qualified Domain Name (FQDN) instead of its IP address.
M If the 'M' bit is set, the Directory Agent address is M If the 'M' bit is set, the Directory Agent address
the only one that may be used, and multicast methods for MUST be present, and multicast methods for discovering
discovering Directory Agents MUST NOT be used. Directory Agents MUST NOT be used.
S If the 'S' bit is set, the scope is present. T If the 'T' bit is set, the Typed-Scope-List is present.
rsv reserved; ignored upon reception; MUST be sent as zero rsv reserved; ignored upon reception; MUST be sent as zero
DA Length
DA Length The length (in octets) of the Directory Agent field. The length (in octets) of the Directory Agent field.
Directory Agent Directory Agent
The Fully Qualified Domain Name (FQDN), host name, or IP The FQDN, host name, or IP address of the Directory
address of the Directory Agent. Agent.
Typed Scope List Typed-Scope-List
The characters denoting the scope (see Section reftsl). The string denoting the typed-scope-list (see
Section 5.1.1).
In order to simplify administration of the configuration of Directory In order to simplify administration of the configuration of DAs for
Agents for Service Location Protocol clients, the Directory Agent clients using SLP, the DA can be indicated by presenting its host
can be indicated by presenting its FQDN or host name instead of its name or FQDN instead of its IP address. This allows renumbering to
IP address. This allows renumbering to proceed more smoothly [7]. proceed more smoothly [7]. When the FQDN or host name is used, the
When the FQDN or host name is used, the server sets the 'F' bit. The server sets the 'F' bit. The host name can be distinguished from the
host name can be distinguished from the FQDN by the presence of a '.' FQDN by the presence of a '.' character. In any case, the DA length
character. In any case, the DA length field is set to be the length field is set to be the length of the Directory Agent field. When the
of the Directory Agent field. When the 'F' bit is not set, the DA 'F' bit is not set, the DA Length MUST be 16.
Length MUST be 16.
Note that more than one Directory Agent extension may be present in Note that more than one Directory Agent extension may be present in
a DHCP message. Each such extension may have the same or different a DHCP message. Each such extension may have the same or different
scope. typed-scope-list. The client may request any Directory Agent with
a particular scope, by including the Directory Agent extension in a
The client may request any Directory Agent with a particular scope, DHCP Request message with no Directory Agent address included (the
by including the Directory Agent extension in a DHCP Request message 'D' bit set to zero), and a nonempty typed-scope-list. The length
with no Directory Agent address included (the 'D' bit set to zero), of the Typed-Scope-List is only indicated implicitly by the overall
and the characters denoting the scope. length of the extension. The format of the Typed-Scope-List field is
described in section 5.1.1.
The length of the Typed Scope List is only indicated implicitly
by the overall length of the extension. This string is NOT null
terminated.
The format of the Typed Scope List field is described in section 2.2. 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 Extension 16 MUST include one or more scopes if a DA address is
returned. Using extension 16, it is not possible for different returned. Using extension 16, it is not possible for different
service types on the same node to be configured with different service types on the same node to be configured with different
directory agents. In other words, all service types on the same node directory agents. In other words, all service agents of the same
will be configured with the same directory agent. service type on the same node will be configured with the same
directory agent.
5.2. Service Scope Extension 5.1.3. Service Scope Extension
This extension indicates a scope that should be used by a Service This extension indicates a scope that should be used by a Service
Agent (SA) [24], when responding to Service Request messages as Agent (SA) [24], when responding to Service Request messages as
specified by the Service Location Protocol. This extension MAY be specified by the Service Location Protocol (SLP). This extension MAY
included multiple times in the same DHCP Request or DHCP Reply. be included multiple times in the same DHCP Request or DHCP Reply.
0 1 2 3 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 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 | Length | | Type = 17 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed-Scope-List ... | Typed-Scope-List ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 17
Length (unsigned integer, variable) The length of the Extension Length (unsigned integer, variable) The length of the Extension
in octets. in octets.
Typed-Scope-List Typed-Scope-List
see Section 2.2. see Section 5.1.1.
The Typed-Scope-List is described in Section 2.2. The DHCP The Typed-Scope-List is described in Section 5.1.1. The DHCP
client (i.e., user agent or service agent) which receives this client (i.e., user agent or service agent) which receives this
extension will use the indicated scope for in all SLP requests and extension will use the indicated scope for in all SLP requests and
registrations. The scope string must be UTF8 character encoded. registrations.
This string is not null terminated.
DHCP clients MAY use extension 79 to request scopes for one or more DHCP clients MAY use extension 17 to request scopes for one or more
particular service types. Note that more than one Service Scope particular service types. Note that more than one Service Scope
extension may be present in a DHCP message. The length of the scope extension may be present in a DHCP message. The length of the
is only indicated implicitly by the overall length of the extension. typed-scope-list is only indicated implicitly by the overall length
of the extension.
5.3. Network Time Protocol Servers Extension 5.2. Network Time Protocol Servers Extension
This extension specifies a list of IP addresses indicating NTP [17] This extension specifies a list of IP addresses indicating NTP [18]
servers available to the client. Servers SHOULD be listed in order servers available to the client. Servers SHOULD be listed in order
of preference. of preference.
0 1 2 3 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 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 | Length | | Type = 18 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP server addresses | | NTP server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for this extension is 18. Its minimum Length is 16, and the The minimum Length for this extension is 16, and the Length MUST be a
Length MUST be a multiple of 16. multiple of 16.
5.4. Network Information Service Domain Extension 5.3. Network Information Service (NIS and NIS+) extensions
This extension specifies the name of the client's NIS [16] domain. This subsection describes DHCPv6 extensions useful for NIS and NIS+
The domain is formatted as a character string consisting of clients.
characters from the US-ASCII character set.
The type for this extension is 19. Its minimum Length is 1. 5.3.1. NIS Domain Extension
This extension specifies the name of the client's NIS [17] 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
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 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 | Length | | Type = 19 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS Domain Name (variable length) ... | NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. Network Information Servers Extension 5.3.2. NIS Servers Extension
This extension specifies a list of IP addresses indicating NIS [16] This extension specifies a list of IP addresses indicating NIS [17]
servers available to the client. Servers SHOULD be listed in order servers available to the client. Servers SHOULD be listed in order
of preference. of preference.
0 1 2 3 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 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 | Length | | Type = 20 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS server addresses | | NIS server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for this extension is 20. Its minimum Length is 16, and the The minimum Length for this extension is 16, and the Length MUST be a
Length MUST be a multiple of 16. multiple of 16.
5.6. Network Information Service+ Domain Extension 5.3.3. NIS+ Domain Extension
This extension specifies the name of the client's NIS+ [16] This extension specifies the name of the client's NIS+ [17]
domain. The domain is formatted as a character string consisting of domain. The domain is formatted as a character string consisting of
characters from the US-ASCII character set. characters from the US-ASCII character set. The minimum Length for
this extension is 1.
The type for this extension is 21. Its minimum Length is 1.
0 1 2 3 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 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 | Length | | Type = 21 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ Client Domain Name (variable length) ... | NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7. Network Information Service+ Servers Extension 5.3.4. NIS+ Servers Extension
This extension specifies a list of IP addresses indicating NIS+ [16] This extension specifies a list of IP addresses indicating NIS+ [17]
servers available to the client. Servers SHOULD be listed in order servers available to the client. Servers SHOULD be listed in order
of preference. of preference.
0 1 2 3 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 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 | Length | | Type = 22 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses | | NIS+ server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for this extension is 22. Its minimum Length is 16, and the The minimum Length for this extension is 16, and the Length MUST be a
Length MUST be a multiple of 16. multiple of 16.
6. TCP Parameters 6. TCP Parameters
This section lists the extensions that affect the operation of the This section lists the extensions that affect the operation of the
TCP layer on a per-interface basis. TCP layer on a per-interface basis.
6.1. TCP Keepalive Interval Extension 6.1. TCP Keepalive Interval Extension
0 1 2 3 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 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 | Length | | Type = 32 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive Time Interval | | Keepalive Time Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This extension specifies the interval (in seconds) that the This extension specifies the interval (in seconds) that the
client TCP should wait before sending a keepalive message on a TCP client TCP should wait before sending a keepalive message on a TCP
connection. The time is specified as a 32-bit unsigned integer. connection. The time is specified as a 32-bit unsigned integer.
A value of zero indicates that the client should not generate A value of zero indicates that the client should not generate
keepalive messages on connections unless specifically requested by an keepalive messages on connections unless specifically requested by an
application. application.
The Type for this extension is 32, and its Length is 4. The Length for this extension is 4.
7. DHCPv6 Extensions 7. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6. This section details the extensions that are specific to DHCPv6.
7.1. Maximum DHCPv6 Message Size Extension 7.1. Maximum DHCPv6 Message Size Extension
This extension specifies the maximum size in octets of any DHCPv6 This extension specifies the maximum size in octets of any DHCPv6
message that the sender of the extension is willing to accept. The message that the sender of the extension is willing to accept. The
size is specified as an unsigned 16-bit integer. A client may use size is specified as an unsigned 32-bit integer. A client may use
the maximum DHCPv6 message size extension in DHCP Request messages, the maximum DHCPv6 message size extension in DHCP Request messages,
but MUST NOT use the extension in other DHCP messages (see [4]). but MUST NOT use the extension in other DHCP messages (see [4]).
0 1 2 3 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 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 | Length | | Type = 40 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max DHCPv6 Message Length | | Max DHCPv6 Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 40, and its Length is 2. The minimum The Length for this extension is 4. The minimum permissible value is
permissible value is 1500. 1500.
7.2. Platform Specific Information 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
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
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. 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 A platform is defined as the combination of hardware and operating
system (OS). system (OS).
This extension is used by clients and servers to exchange This extension is used by clients and servers to exchange
client-platform-specific information. The information is an opaque client-platform-specific information. The information is an opaque
collection of data, presumably interpreted by platform-specific code collection of data, presumably interpreted by platform-specific code
on the clients. The definition of this information is platform on the clients. The definition of this information is platform
specific. Clients identify their platform through the use of the specific. Clients identify their platform through the use of the
Platform Class identifier extension (see Section 7.3). Clients which Platform Class identifier extension (see Section 7.4). Clients which
do not receive platform specific information SHOULD make an attempt do not receive platform specific information SHOULD make an attempt
to operate without it, although they may do so (and announce that to operate without it, although they may do so (and announce that
they are doing so) in a degraded mode. they are doing so) in a degraded mode.
If a Platform vendor encodes more than one item of information in If a Platform vendor encodes more than one item of information in
this extension, then the vendor MUST encode the extension using this extension, then the vendor MUST encode the extension using
"Encapsulated platform-specific extensions" as described below. "Encapsulated platform-specific extensions" as described below.
The Encapsulated platform-specific extensions field MUST be The Encapsulated platform-specific extensions field MUST be
encoded as a sequence of type/length/value fields of identical encoded as a sequence of type/length/value fields of identical
syntax to the form defined for DHCPv6 extensions. Extension syntax to the form defined for DHCPv6 extensions. Extension
65535 (END), if present, signifies the end of the encapsulated 65535 (END), if present, signifies the end of the encapsulated
platform extensions, not the end of the platform extensions field. platform extensions, not the end of the platform extensions field.
If no extension 65535 is present, then the end of the enclosing If no extension 65535 is present, then the end of the enclosing
platform-specific information field is taken as the end of the platform-specific information field is taken as the end of the
encapsulated platform-specific extensions field. encapsulated platform-specific extensions field.
The Type for this extension is 48 and its minimum Length is 4.
0 1 2 3 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 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 | Length | | Type = 48 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform-specific extension information ... | Platform-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When encapsulated platform-specific extensions are used, each one has The minimum Length for this extension is 4.
the same format as just shown. In other words, all platform-specific
extensions are encoded in Type-Length-Value (TLV) format. More than When encapsulated platform-specific extensions are used, each one
one platform-specific extension can, therefore, be included in the has the same format as for general DHCP extensions, as defined
same DHCP "Platform Specific Information" extension. 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 DHCP servers which support the configuration of Platform Specific
Information extensions, and which have been configured with Information extensions, and which have been configured with
configuration information specific to some number of Platform Class configuration information specific to some number of Platform Class
Identifiers MUST select and return only those platform-specific Identifiers MUST select and return only those platform-specific
extensions which match the Platform Class Identifier provided by the extensions which match the Platform Class Identifier provided by the
DHCP client. DHCP client.
7.3. Platform Class Identifier 7.4. Platform Class Identifier
This extension is used by a DHCP client to identify the hardware type This extension is used by a DHCP client to identify the hardware type
and operating system platform it is hosted on. The extension value 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 itself is an opaque value to a DHCP server, and is only used by the
DHCP server to "lookup" Platform Specific Extensions associated with DHCP server to "lookup" Platform Specific Extensions associated with
clients of a certain platform class. clients of a certain platform class.
Servers not equipped to interpret the platform class identifier Servers not equipped to interpret the platform class identifier
specified by a client MUST ignore it (although it may be reported). specified by a client MUST ignore it (although it may be reported
Otherwise, servers SHOULD respond with the set of extensions to the DHCP administrator). Otherwise, servers SHOULD respond with
corresponding to the platform class identifier specified by the the set of extensions corresponding to the platform class identifier
client. specified by the client.
Note that unlike the User Class Identifier, the Platform Class Note that unlike the User Class Identifier, the Platform Class
Identifier does not need to be echoed back to the DHCP client because 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. there can be one and only one Platform Class Identifier for a client.
0 1 2 3 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 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 | Length | | Type = 49 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Platform Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 49. The platform class identifier is | Platform Class Identifier ...
a string of characters in the character set specified by the Char +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Encoding field (see section 2.1), of length "Length"-2 octets. The
platform class identifier represents the hardware and Operating The platform class identifier is a string of characters of Length
system class of which the client is a member. 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 In order to prevent collisions in the Platform Class Identifier
namespace, we recommend that platform vendors prefix their Platform namespace, we recommend that platform vendors prefix their Platform
Class Identifiers with their Stock symbol or some other globally Class Identifiers with their Stock symbol or some other globally
recognized authority. For example, Platform Class Identifiers for recognized authority. For example, Platform Class Identifiers for
Sun Microsystems Inc platforms would be prefaced by "SUNW", the Sun Microsystems Inc platforms would be prefaced by "SUNW", the
NASDAQ stock symbol for Sun. NASDAQ stock symbol for Sun.
7.4. Class Identifier 7.5. Class Identifier
This extension is used by a DHCP client to optionally identify the This extension is used by a DHCP client to optionally identify the
type or category of user or applications it represents. type or category of user or applications it represents.
DHCP administrators may define specific class identifiers to convey DHCP administrators may define specific class identifiers to convey
information about a client's software configuration or about its information about a client's software configuration or about its
user's preferences. For example, an identifier may specify that user's preferences. For example, an identifier may specify that
a particular DHCP client is a member of the class "accounting a particular DHCP client is a member of the class "accounting
auditors", which have special service needs such as a particular auditors", which have special service needs such as a particular
database server. Alternatively, the identifier may encode the database server. Alternatively, the identifier may encode the
client's hardware configuration. client's hardware configuration.
Servers not equipped to interpret the class identifier specified by Servers not equipped to interpret the class identifier specified by
a client MUST ignore it (although it may be reported). Otherwise, a client MUST ignore it (although it may be reported to the DHCP
servers SHOULD respond with the set of extensions corresponding to administrator). Otherwise, servers SHOULD respond with the set of
the class identifier specified by the client. Further, if the server extensions corresponding to the class identifier specified by the
responds with the set of extensions corresponding to the given class client. Further, if the server responds with the set of extensions
identifier, it MUST return this extension (with the given class corresponding to the given class identifier, it MUST return this
identifier value) to the client. extension (with the given class identifier value) to the client.
0 1 2 3 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 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 | Length | | Type = 64 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 64. The class identifier is a string The class identifier is a string of Length octets. The class
of characters in the character set specified by the Char Encoding
field (see section 2.1), of length "Length"-2 octets. The class
identifier represents the class identifier of which the client is a identifier represents the class identifier of which the client is a
member. member.
7.5. Reconfigure Multicast Address 7.6. Reconfigure Multicast Address
A DHCPv6 server can instruct its clients to join a multicast group A DHCPv6 server can instruct its clients to join a multicast group
for the purposes of receiving DHCPv6 Reconfigure messages. This will for the purposes of receiving DHCPv6 Reconfigure messages. This will
allow a server to reconfigure all of its clients at once; such a allow a server to reconfigure all of its clients at once; such a
feature will be useful when renumbering becomes necessary. feature will be useful when renumbering becomes necessary.
0 1 2 3 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 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 | Length | | Type = 66 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reconfigure Multicast Address | | Reconfigure Multicast Address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the Reconfigure Multicast Address is 66, and the Length 7.7. Renumber DHCPv6 Server Address
is 16.
7.6. Renumber DHCPv6 Server Address
A DHCPv6 server can instruct its clients to change their internal A DHCPv6 server can instruct its clients to change their internal
records to reflect the server's newly renumbered IP address, by using records to reflect the server's newly renumbered IP address, by using
the "Renumber DHCPv6 Server Address" extension. This extension may the Renumber DHCPv6 Server Address extension. This extension may be
be sent with the DHCP Reconfigure message, and thus can be multicast 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 to all of the server's clients instead of being unicast to each one
individually. individually.
0 1 2 3 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 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 | Length | | Type = 67 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New DHCPv6 Server Address | | New DHCPv6 Server Address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the Renumber DHCPv6 Server Address is 67, and the Length 7.8. DHCP Relay ICMP Error Message Format
is 16.
7.7. DHCP Relay ICMP Error Message Format
A DHCP Relay ICMP Message extension is used to inform a client of A DHCP Relay ICMP Message extension is used to inform a client of an
an ICMP Error message the relay received after forwarding a client ICMP Error message received by the relay after forwarding a client
Solicit or Request message. 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
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 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 | Length | | Type = 68 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Error Message | | ICMP Error Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the DHCP Relay ICMP Message extension is 68, and the The Length of the DHCP Relay ICMP Message extension is the length of
Length is the length of the ICMP error message received by the the ICMP error message received by the relay [8].
relay [8].
7.7.1. ICMP Extension Client Considerations 7.8.1. ICMP Extension Client Considerations
When a client sends a Solicit or Request message it can be forwarded When a client sends a Solicit or Request message it may often be
by a relay. When the relay forwards messages for a client the forwarded by a relay. When the relay forwards messages for a client
network may return an ICMP error [8] message to the relay. If the the network may return an ICMP error [8] message to the relay. The
relay can determine the client's link-local address within the relay determines the client's link-local address within the UDP
UDP payload of the ICMP returned error message payload, the relay payload of the ICMP returned error message payload, and sends the
will send the client a DHCP Relay ICMP Error message as defined in client a DHCP Relay ICMP Error message as defined in section 7.8.2.
section 7.7.2.
The client MAY record these messages based on the ICMP type and The client MAY record these messages based on the ICMP type and
reason codes provided in the ICMP Error payload [8], for future use reason codes provided in the ICMP Error payload [8], for future use
or for system logging purposes. How the client uses this information or for system logging purposes. How the client uses this information
is implementation dependent. is implementation dependent.
7.7.2. ICMP Extension Relay Considerations 7.8.2. ICMP Extension Relay Considerations
If the relay receives an ICMP error message after forwarding a client If the relay receives an ICMP error message after forwarding a
Solicit or Request message, it should look in the payload of the client's DHCP Solicit or Request message, it MUST inspect the
ICMP message [8], to see if it can determine the clients link-local payload of the ICMP message [8], to determine the client's link-local
address in the server Advertise or Reply message. If it can the address. The relay MUST check that it is a link-local address; if
relay should forward a DHCP Relay ICMP Error message received to the not, the ICMP error message MUST be silently discarded. Otherwise,
client as specified in section 7.7.1, by using the clients link-local the relay should forward the ICMP Error message to the client as
address from the ICMP error message as the IP source address in the 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 IP header sent to the client. If the relay cannot determine the
clients link-local address in the ICMP error message the packet MUST client's link-local address in the ICMP error message the packet MUST
be silently discarded. be silently discarded.
7.8. Client-Server Authentication Extension 7.9. Client-Server Authentication Extension
Exactly one Client-Server Authentication Extension MAY be present Exactly one Client-Server Authentication Extension MAY be present
in any DHCPv6 message transmitted between a client and server (or in any DHCPv6 message transmitted between a client and server (or
vice-versa). If present, it MUST be the last extension. vice-versa). If present, it MUST be the last extension.
0 1 2 3 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 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 | Length | | Type = 84 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | | Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Protection | | Replay Protection |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator (variable length) ... | Authenticator (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 84
Length (unsigned integer, variable) 4 for the SPI, plus 8 for Length (unsigned integer, variable) 4 for the SPI, plus 8 for
the replay protection, plus the number of octets in the the replay protection, plus the number of octets in the
Authenticator. Authenticator.
SPI A Security Parameters index [2] identifying which SPI A Security Parameters Index [2] identifying a security
security context among those available between the DHCPv6 context from among those available between the DHCPv6
client and server. client and server.
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [18](NTP) A 64-bit timestamp (in Network Time Protocol [19](NTP)
format) (see section 9.1). format) (see section 10.1).
Authenticator Authenticator
(variable length) (See Section 9.2.) (variable length) (See Section 10.2.)
This authentication extension remedies the inability of IPsec to This authentication extension remedies the inability of IPsec [15]
provide for non end-to-end authentication, since authentication is to provide for non end-to-end authentication, since authentication
needed even when the client has no IPv6 address of large enough scope is needed even when the client has no IPv6 address of large enough
to reach the DHCP server. The extension can be originated by either scope to reach the DHCP server. The extension can be originated by
the DHCPv6 Client or DHCPv6 server to authenticate the rest of the either the client or server to authenticate the rest of the data in
data in the DHCPv6 message. The default authentication algorithm is the DHCPv6 message. The default authentication algorithm, which MUST
defined in section 9.2. be supported by all clients and servers, is defined in section 10.2.
Note that SPI values 0 through 255 are reserved and, if used, MUST SPI values 0 through 255 are reserved and, if used, MUST conform
conform to the security context defined by that value in the most to the security context defined by that value in the most recent
recent Assigned Numbers RFC (e.g., [21]). Assigned Numbers RFC (e.g., [14]).
7.9. Client Key Selection Extension 7.10. Client Key Selection Extension
A DHCPv6 server may wish to indicate to a prospective client which A DHCPv6 server may wish to indicate to a prospective client which
SPI it must use to authenticate subsequent messages, using the SPI it must use to authenticate subsequent messages, using the
Client-Server Authentication Extension. In such cases, the server Client-Server Authentication Extension. In such cases, the server
includes the Client Key Selection Extension in its DHCP Advertise includes the Client Key Selection Extension in its DHCP Advertise
message. message.
0 1 2 3 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 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 | Length | | Type = 85 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | | Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 85 The SPI is a Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts available in the
Length 4 security association defined between the DHCPv6 client and server.
SPI values 0 through 255 are reserved and, if used, MUST conform to
SPI A Security Parameters index [2] identifying a security the security context defined by that value as defined in the most
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., [12]). recent Assigned Numbers RFC (e.g., [12]).
8. End extension specification 8. End Extension
The end extension marks the end of valid information in the vendor 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 field. The Type for the end extension is 65535, and its Length is 2
octets; there is no Length field for the end extension. octets; there is no Length field for the end extension.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 65535 | | Type = 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Security Considerations 9. Resource-Server Associations
There is an urgent need to define some security protocol for use Some extensions may cause a client to receive allocated resources.
with DHCPv6, since otherwise malicious parties could create numerous When the client wishes to release such resources before the
denial-of-service style attacks based on depleting available server allocation has expired, the client will need to contact the server
resources or providing corrupted or infected data to unsuspecting which allocated that resource. Thus, the resource needs to be
clients. The following sections discuss aspects of security relevant associated to the server that made the allocation. This association
for users of the Client-Server Authentication extension 7.8. See is maintained in a data structure called a resource-server
also the Security Considerations in the companion specification [4]. association for the appropriate extensions.
9.1. Replay Protection 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).
A 64-bit timestamp, in Network Time Protocol [18](NTP) format, is 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 [19](NTP) format, is
used to protect against replay of previous authenticated messages used to protect against replay of previous authenticated messages
by malicious agents. The NTP timestamp value used in the extension by malicious agents. The NTP timestamp value used in the extension
MUST be chosen, and verified, to be larger than values used by the MUST be chosen, and verified, to be larger than values used by the
originator in previous Client-Server Authentication extensions. originator in previous Client-Server Authentication extensions.
On the other hand, the timestamp value MUST also be chosen (and 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 verified) to be no greater than one year more than the last known
value (if any) used by the originator. value (if any) used by the originator.
9.2. Default Authentication Algorithm 10.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [15], using The default authentication algorithm is HMAC [16], using
keyed-MD5 [22]. Given a secret key K, and "data" the information to keyed-MD5 [22]. Given a secret key K, and "data" the information to
be authenticated, HMAC_result is computed as follows: be authenticated, HMAC_result is computed as follows:
1. opad := 0x36363636363636363636363636363636 (128 bits) 1. opad := 0x36363636363636363636363636363636 (128 bits)
2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
3. zero_extended_key := K extended by zeroes to be 128 bits long 3. zero_extended_key := K extended by zeroes to be 128 bits long
4. opadded_key := zero_extended_key XOR opad 4. opadded_key := zero_extended_key XOR opad
skipping to change at page 29, line 40 skipping to change at page 30, line 7
5. ipadded_key := zero_extended_key XOR ipad 5. ipadded_key := zero_extended_key XOR ipad
6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))
The key K is the shared secret defined by the security association The key K is the shared secret defined by the security association
between the client and server and by the SPI value specified in between the client and server and by the SPI value specified in
the Authentication Extension. The "data" is the stream of octets the Authentication Extension. The "data" is the stream of octets
in all previous fields in the DHCPv6 message and extensions. The in all previous fields in the DHCPv6 message and extensions. The
authenticator is the 128-bit value HMAC_result. authenticator is the 128-bit value HMAC_result.
10. Defining New Extensions 11. IANA Considerations
Implementation specific use of undefined extensions (including those This document MAY be superseded by new documents for DHCPv6
in the range 86-32767) may conflict with other implementations, and extensions, which will then include the entire current list of valid
registration is required. extensions. This section details the method for specifying new
extensions.
The author of a new DHCP extension MUST follow these steps to obtain Implementation specific use of undefined extensions (all those in the
acceptance of the extension as a part of the DHCP Internet Standard: range 86-32767 inclusive) may conflict with other implementations,
and registration is required.
1. The author devises the new extension. 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:
2. The author requests a number for the new extension from IANA by 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" [14]. 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: contacting:
Internet Assigned Numbers Authority (IANA) Internet Assigned Numbers Authority (IANA)
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, California 90292-6695 Marina del Rey, California 90292-6695
or by email as: iana@isi.edu or by email as: iana@isi.edu
3. The author documents the new extension, using the newly obtained 4. The new extension progresses through the IETF standards
extension number, as an Internet Draft.
4. The author submits the Internet Draft for review through the
IETF standards process as defined in "Internet Official Protocol
Standards" [14]. The new extension will be submitted for
eventual acceptance as an Internet Standard.
5. The new extension progresses through the IETF standards
process; the new extension will be reviewed by the Dynamic Host process; the new extension will be reviewed by the Dynamic Host
Configuration Working Group (if that group still exists), or as Configuration Working Group (if that group still exists), or as
an Internet Draft not submitted by an IETF working group. an Internet Draft not submitted by an IETF working group.
6. If the new extension fails to gain acceptance as an Internet 5. If the new extension fails to gain acceptance as an Internet
Standard, the assigned extension number will be returned to IANA Standard, the assigned extension number will be returned to IANA
for reassignment. for reassignment.
This procedure for defining new extensions will ensure that: This procedure for defining new extensions will ensure that:
* allocation of new extension numbers is coordinated from a single * allocation of new extension numbers is coordinated from a single
authority, authority,
* new extensions are reviewed for technical correctness and * new extensions are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new extensions is complete and published. * documentation for new extensions is complete and published.
11. Acknowledgements 12. Acknowledgements
Thanks to Jim Bound for his frequent review, helpful suggestions, and Thanks to Jim Bound for his frequent review, helpful suggestions, and
design assistance. Ralph Droms has also made many, many suggestions design assistance. Ralph Droms has also made many, many suggestions
which have been incorporated into this draft. The original form of which have been incorporated into this draft. The original form of
this internet draft was copied directly from RFC1533 [1], written this internet draft was copied directly from RFC1533 [1], written
by Steve Alexander and Ralph Droms. Thanks to Mike Carney for his by Steve Alexander and Ralph Droms. Thanks to Mike Carney for his
many helpful comments, as well as contributing the design of the many helpful comments, as well as contributing the design of the
Platform Specific Information and Platform Class Identifier. Thanks Platform Specific Information and Platform Class Identifier. Thanks
to Erik Guttman for his helpful suggestions for the Service Location to Erik Guttman for his helpful suggestions for the Service Location
extensions. Thanks to Matt Crawford and Erik Nordmark for their extensions. Thanks to Matt Crawford and Erik Nordmark for their
careful review as part of the Last Call process. Jim Bound also careful review as part of the Last Call process. Jim Bound also
provided all the necessary design and text for the DHCP Relay ICMP provided all the necessary design and text for the DHCP Relay ICMP
Error Message Extension. Error Message Extension.
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.
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."
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993. Extensions. RFC 1533, October 1993.
[2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource [3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994. Locators (URL). RFC 1738, December 1994.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-11.txt, May 1997. (work in for IPv6. draft-ietf-dhc-dhcpv6-14.txt, June 1998. (work in
progress). progress).
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement [5] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997. Levels. RFC 2119, March 1997.
[6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone [6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications. draft-ietf-dhc-timezone-01.txt, January 1997. Specifications. draft-ietf-dhc-timezone-01.txt, January 1997.
(work in progress). (work in progress).
[7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, [7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996. February 1996.
[8] A. Conta and S. Deering. Internet Control Message Protocol [8] A. Conta and S. Deering. Internet Control Message Protocol
skipping to change at page 32, line 10 skipping to change at page 32, line 41
December 1995. December 1995.
[9] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [9] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[10] E. Guttman, C. Perkins, and J. Kempf. Service Templates and [10] E. Guttman, C. Perkins, and J. Kempf. Service Templates and
service: Schemes. draft-ietf-svrloc-service-scheme-05.txt, service: Schemes. draft-ietf-svrloc-service-scheme-05.txt,
November 1997. (work in progress). November 1997. (work in progress).
[11] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service [11] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txT, Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txt,
March 1998. (work in progress). March 1998. (work in progress).
[12] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic [12] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994. Routing Encapsulation (GRE). RFC 1701, October 1994.
[13] IEEE. 1003.1 POSIX Timezone Specification, 1988. [13] IEEE. 1003.1 POSIX Timezone Specification, 1988.
[14] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1, [14] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
July 1997. May 1998.
[15] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing [15] Stephen Kent and Randall Atkinson. IP Authentication Header.
draft-ietf-ipsec-auth-header-07.txt, July 1998. (work in
progress).
[16] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997. for Message Authentication. RFC 2104, February 1997.
[16] Sun Microsystems. System and Network Administration, March [17] Sun Microsystems. System and Network Administration, March
1992. 1992.
[17] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for [18] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI. RFC 2030, October 1996. IPv4, IPv6 and OSI. RFC 2030, October 1996.
[18] David L. Mills. Network Time Protocol (Version 3): [19] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[19] P. Mockapetris. Domain Names - Concepts and Facilities. IETF [20] P. Mockapetris. Domain Names - Concepts and Facilities. IETF
STD 13, November 1987. STD 13, November 1987.
[20] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2, [21] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2,
October 1994.
[21] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994. October 1994.
[22] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [22] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[23] S. Thomson and T. Narten. IPv6 Stateless Address [23] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. RFC 1971, August 1996. Autoconfiguration. RFC 1971, August 1996.
[24] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [24] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. RFC 2165, July 1997.
skipping to change at page 33, line 24 skipping to change at page 34, line 24
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Charles E. Perkins Charles E. Perkins
Technology Development Group Technology Development Group
Mail Stop MPK15-214 Mail Stop MPK15-214, Room 2682
Room 2682
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 15 Network Drive
Palo Alto, California 94303 Menlo Park, California 94025
USA USA
Phone: +1-650-786-6464 Phone: +1-650-786-6464
Fax: +1-650-786-6445 Fax: +1-650-786-6445
email: charles.perkins@Sun.COM email: charles.perkins@Sun.COM
web: http://www.svrloc.org/~charliep
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/