draft-ietf-dhc-v6exts-07.txt   draft-ietf-dhc-v6exts-08.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems INTERNET DRAFT Sun Microsystems
30 July 1997 30 October 1997
Extensions for the Dynamic Host Configuration Protocol for IPv6 Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-v6exts-07.txt draft-ietf-dhc-v6exts-08.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 37 skipping to change at page 1, line 36
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, 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), nic.nordu.net (North Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6) The Dynamic Host Configuration Protocol for IPv6 [3] (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 Each superseding document will include the entire current list of
valid extensions. 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 2
2.1. Character Encoding and String Issues . . . . . . . . . . 2 2.1. Character Encoding and String Issues . . . . . . . . . . 2
3. IP Address Extension 3 3. IP Address Extension 3
3.1. Client Considerations for the IP Address extension . . . 6 3.1. Client Considerations for the IP Address extension . . . 6
3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6 3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6
3.1.2. Use with the DHCP Request message . . . . . . . . 7 3.1.2. Use with the DHCP Request message . . . . . . . . 7
3.1.3. Receiving as part of the DHCP Reply message . . . 8 3.1.3. Receiving as part of the DHCP Reply message . . . 8
3.1.4. Use with the DHCP Release message . . . . . . . . 9 3.1.4. Use with the DHCP Release message . . . . . . . . 8
3.2. Server Considerations for the IP Address extension . . . 9 3.2. Server Considerations for the IP Address extension . . . 9
3.2.1. Use with the DHCP Advertise message . . . . . . . 9 3.2.1. Use with the DHCP Advertise message . . . . . . . 9
3.2.2. Receiving a DHCP Request with the IP Address 3.2.2. Receiving a DHCP Request with the IP Address
Extension . . . . . . . . . . . . . . . . 9 Extension . . . . . . . . . . . . . . . . 9
3.2.3. Use with the DHCP Reply message . . . . . . . . . 10 3.2.3. Use with the DHCP Reply message . . . . . . . . . 10
3.2.4. Use with the DHCP Reconfigure message . . . . . . 11 3.2.4. Use with the DHCP Reconfigure message . . . . . . 11
3.2.5. Receiving a DHCP Release with the IP Address 3.2.5. Receiving a DHCP Release with the IP Address
Extension . . . . . . . . . . . . . . . . 11 Extension . . . . . . . . . . . . . . . . 11
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11 3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11
4. General Extensions 11 4. General Extensions 11
4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 12 4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 11
4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 12 4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 12
4.2.2. An Example . . . . . . . . . . . . . . . . . . . 14 4.2.2. An Example . . . . . . . . . . . . . . . . . . . 13
4.2.3. Timezone 0ption Precedence . . . . . . . . . . . 14 4.2.3. Timezone 0ption Precedence . . . . . . . . . . . 14
4.3. Domain Name Server Extension . . . . . . . . . . . . . . 15 4.3. Domain Name Server Extension . . . . . . . . . . . . . . 14
4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 14
5. Application and Service Parameters 15 5. Application and Service Parameters 15
5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 16 5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 15
5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 17 5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 17
5.3. Network Time Protocol Servers Extension . . . . . . . . . 18 5.3. Network Time Protocol Servers Extension . . . . . . . . . 17
5.4. Network Information Service Domain Extension . . . . . . 19 5.4. Network Information Service Domain Extension . . . . . . 18
5.5. Network Information Servers Extension . . . . . . . . . . 19 5.5. Network Information Servers Extension . . . . . . . . . . 18
5.6. Network Information Service+ Domain Extension . . . . . . 19 5.6. Network Information Service+ Domain Extension . . . . . . 18
5.7. Network Information Service+ Servers Extension . . . . . 20 5.7. Network Information Service+ Servers Extension . . . . . 19
5.8. Vendor Specific Information . . . . . . . . . . . . . . . 20 5.8. Vendor Specific Information . . . . . . . . . . . . . . . 19
6. TCP Parameters 20
6. TCP Parameters 21 6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 20
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21
7. DHCPv6 Extensions 22 7. DHCPv6 Extensions 21
7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 22 7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 21
7.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 22 7.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 21
7.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 23 7.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 22
7.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 23 7.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 22
7.5. Client-Server Authentication Extension . . . . . . . . . 24 7.5. Client-Server Authentication Extension . . . . . . . . . 23
7.6. Client Key Selection Extension . . . . . . . . . . . . . 25 7.6. Client Key Selection Extension . . . . . . . . . . . . . 24
8. End extension specification 26 8. End extension specification 25
9. Security Considerations 26 9. Security Considerations 25
9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 26 9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 25
9.2. Default Authentication Algorithm . . . . . . . . . . . . 26 9.2. Default Authentication Algorithm . . . . . . . . . . . . 25
10. Defining New Extensions 27 10. Defining New Extensions 26
11. Acknowledgements 29 11. Acknowledgements 28
Chair's Address 31 Chair's Address 30
Author's Address 31 Author's Address 30
1. Introduction 1. Introduction
This document specifies extensions for use with the Dynamic This document specifies extensions for use with the Dynamic
Host Configuration Protocol for IP version 6, DHVPv6. The full Host Configuration Protocol for IP version 6, DHVPv6. The full
description of DHCPv6 message formats may be found in the DHCPv6 description of DHCPv6 message formats may be found in the DHCPv6
specification document [4]. In this document, several words are used specification document [3]. In this document, several words are used
to signify the requirements of the specification, in accordance with to signify the requirements of the specification, in accordance with
RFC 2119 [5]. These words (MUST, SHOULD, MAY, MUST NOT, etc) are RFC 2119 [4]. These words (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 format of information in the last field
of DHCPv6 messages ('extensions'). The extensions defined within of DHCPv6 messages ('extensions'). The extensions defined within
this document specify a generalized use of this area for giving this document specify a generalized use of this area for giving
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 single DHCPv6 server that is
shared among heterogeneous clients may choose to define other, site- shared among heterogeneous clients may choose to define other, site-
specific formats for the use of the 'extensions' field. specific formats for the use of the 'extensions' field.
skipping to change at page 1, line 160 skipping to change at page 1, line 159
- TCP - TCP
- Vendor Specific - 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 [21], and not will be satisfied by the Service Location Protocol [20], 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
DHCPv6 extensions have the same format as the BOOTP "vendor Extensions may be fixed length or variable length. All extensions
extensions" [2]. Extensions may be fixed length or variable length. begin with a type field, which is two octets long and uniquely
All extensions begin with a type field, which is two octets long and identifies the extension. Fixed length extensions without data
uniquely identifies the extension. Fixed length extensions without consist of only the two octet type field. Only extension 65535 is
data consist of only the two octet type field. Only extension 65535 fixed length. All other extensions are variable length with a two
is fixed length. All other extensions are variable length with a two
octet unsigned integer Length field following the type octets. The octet unsigned integer Length field following the type octets. The
value of the Length field does not include the four octets specifying value of the Length field does not include the four octets specifying
the type and length. The Length field is followed by "length" octets the type and length. The Length field is followed by "length" octets
of data. In the case of some extensions the length field is a of data. In the case of some extensions the length field is a
constant but MUST still be specified. In each case, unless otherwise constant but MUST still be specified. In each case, unless otherwise
specified, the length field specifies the length of the extension in specified, the length field specifies the length of the extension in
octets. Any extensions defined subsequent to this document should octets. Any extensions defined subsequent to this document should
contain a Length field even if the length is fixed or zero. There contain a Length field even if the length is fixed or zero. There
is no particular requirement for alignment of the data fields within is no particular requirement for alignment of the data fields within
existing DHCPv6 extensions. existing DHCPv6 extensions.
Unrecognized extensions SHOULD be skipped by ignoring the number of Unrecognized extensions SHOULD be skipped by ignoring the number of
octets specified in the length field, and processing continued for 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 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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
US-ASCII. US-ASCII.
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 [22]. be updated [21].
To ask for an IP address in a DHCP Request message, a client includes To ask for an IP address in a DHCP Request message, a client includes
an IP Address Extension. To renew or extend the lifetime of a an IP Address Extension. To renew or extend the lifetime of a
particular IP address, the client puts that address in the client particular IP address, the client puts that address in the client
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
subnet prefix of the link to which the client is currently attached. subnet 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pfx-size | status |C|L|Q|A|P| reserved | | status |C|L|Q|A|P| reserved | pfx-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 4, line 24 skipping to change at page 4, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 Type 1
Length (unsigned integer, variable) The length of the Extension Length (unsigned integer, variable) The length of the Extension
in octets. in octets.
pfx-size
If the client address is present (the 'C' bit is set), a
nonzero pfx-size is the number of leftmost bits of the
client's IPv6 address which make up the routing prefix.
Otherwise, if the 'C' bit is not set, pfx-size MUST be
zero.
status If the server is unable to honor the client's request, status If the server is unable to honor the client's request,
the reason is indicated in the status. the reason is indicated in the status.
C If the 'C' bit is set, the field containing the IP C If the 'C' bit is set, the field containing the IP
address for the client is present in the extension. address for the client is present in the extension.
L If the 'L' bit is set, the preferred and valid lifetimes L If the 'L' bit is set, the preferred and valid lifetimes
are present in the extension. are present in the extension.
Q If the 'Q' bit is set, the fields included by the client Q If the 'Q' bit is set, the fields included by the client
skipping to change at page 5, line 11 skipping to change at page 4, line 32
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
If the client address is present (the 'C' bit is set), a
nonzero pfx-size is the number of leftmost bits of the
client's IPv6 address which make up the routing prefix.
Otherwise, if the 'C' bit is not set, pfx-size MUST be
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
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 null-terminated string of ASCII octets) The DNS name (a string of ASCII octets) to be used by the
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
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 34 dynDNS Not Available at this time (SERVFAIL)
35 Some name that ought to exist, does not exist. 35 Some name that ought to exist, does not exist
36 The name server does not support the specified Opcode. (NXDOMAIN)
36 dynDNS Not Implemented 36 The name server does not support the specified Opcode
(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. 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
39 Some RRset that ought not to exist, does exist. (YXDOMAIN)
40 Some RRset that ought to exist, does not exist. 39 Some RRset that ought not to exist, does exist
(YXRRSET)
40 Some RRset that ought to exist, does not exist
(NXRRSET)
41 The server is not authoritative for the zone named in 41 The server is not authoritative for the zone named in
the Zone Section. the Zone Section (NOTAUTH)
42 A name used in the Prerequisite or Update Section is 42 A name used in the Prerequisite or Update Section
not within the zone denoted by the Zone Section. is not within the zone denoted by the Zone Section
34 Authoritative DNS Server could not be found (NOTZONE)
Status values 34through 21are described more fully within RFC Status values 33through 42are described more fully within RFC
2136 [22]. Up-to-date values for the values of the status field are 2136 [21]. Up-to-date values for the values of the status field are
specified in the most recent "Assigned Numbers" [17]. To inform the specified in the most recent "Assigned Numbers" [16]. To inform the
client of the DYNDNS [22] error return codes (i.e., nonzero return client of the DYNDNS [21] error return codes (i.e., nonzero return
codes) received by the DHCPv6 server the client MUST assume the codes) received by the DHCPv6 server the client MUST assume the
status codes 32 through 42 are formed as follows: status codes 32 through 42 are formed as follows:
status code = 32 + DYNDNS Error Code status code = 32 + DYNDNS Error Code
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
skipping to change at page 6, line 34 skipping to change at page 6, line 20
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 can be done even with IP addresses
obtained by Stateless Address Autoconfiguration [20]. obtained by Stateless Address Autoconfiguration [19]. If the client
wishes to have its FQDN associated with one of several existing IP
addresses which it has received from the DHCP Server, the client MUST
supply that IP address in the IP address extension along with the
FQDN.
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 has a preferred and valid
lifetime. The valid lifetime represents the lease for addresses lifetime. The valid lifetime represents the lease for addresses
provided to the client, from the server. provided to the client, from the server.
The client SHOULD make a new Request for any address that is about The client SHOULD make a new Request for any address that is about
to expire, or request a new address or the same address before the 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 lease actually expires. If the client does not make a new Request
for an address, the server SHOULD assume the client does not want for an address, the server SHOULD assume the client does not want
that address. The server MAY provide that address to another client that address. The server MAY provide that address to another client
requesting an address. requesting an address.
The client MAY request values for the lifetimes, but the client MUST The client MAY request values for the lifetimes, but the client MUST
use the lifetimes provided by the server response. 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 [8] for required handling address becomes a deprecated address. See [7] 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).
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 the decrement the received Lifetimes by the amount of time between the
skipping to change at page 8, line 26 skipping to change at page 8, line 15
Request, by specifying the 'Q' (Required) bit. Request, by specifying the 'Q' (Required) bit.
When a client requests an IP address, it MUST maintain a record for When a client requests an IP address, it MUST maintain a record for
the server which allocates that address, so that the client can (if the server which allocates that address, so that the client can (if
necessary) in the future 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.
Note that if a client wishes to specify a lifetime for its IP
address, it normally only needs to specify a value for the preferred
lifetime, not the valid lifetime.
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 which it accepts (see [3]), it first inspects the status to see
whether the requested information has been granted. If the status is whether the requested information has been granted. If the status is
nonzero, the client should log the error, display the error condition nonzero, the client should log the error, display the error condition
for action by the user and/or the network administrator. Nonzero for action by the user and/or the network administrator. Nonzero
status almost always indicates that the client will be need to modify status almost always indicates that the client will be need to modify
its request before it could be satisfied by the replying DHCP server, its request before it could be satisfied by the replying DHCP server,
or alternatively that the replying DHCP server will need to be given or 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) [20]; however, if the perform Duplicate Address Detection (DAD) [19]; 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 DHCP Release (for each address extension):
skipping to change at page 9, line 22 skipping to change at page 9, line 5
- the server MUST update DNS to delete the AAAA record or records - the server MUST update DNS to delete the AAAA record or records
that the server originally used when updating DNS when the that the server originally used when updating DNS when the
address was allocated to the client, and likewise for the PTR address was allocated to the client, and likewise for the PTR
record (regardless of the setting of the 'A' or 'P' bits in the record (regardless of the setting of the 'A' or 'P' bits in the
address extension). address extension).
- If the client, on the other hand, took charge of the DNS updates, - If the client, on the other hand, took charge of the DNS updates,
it MUST perform the corresponding deletions before issuing the it MUST perform the corresponding deletions before issuing the
DHCP Release. DHCP Release.
If the DNS name is provided ONLY all client AAAA records for that The client SHOULD provide a specific IP address in the extension. If
name will be deleted. only the DNS name is provided, all client AAAA records for that name
will be deleted.
3.2. Server Considerations for the IP Address extension 3.2. Server Considerations for the IP Address extension
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 cllient's FQDN or host name - the client's FQDN or host name
- the preferred lifetime - the preferred lifetime
- the valid lifetime
- whether DNS will accept new names for the address (via the 'A' - whether DNS will accept new names for the address (via the 'A'
bit) bit)
If the server sets the 'A' bit, it is willing to perform DNS updates If the server sets the 'A' bit, it is willing to perform DNS updates
to AAAA records on behalf of the client. Likewise, if the server to AAAA records on behalf of the client. Likewise, if the server
sets the 'P' bit, it is willing to perform DNS updates to PTR records sets the 'P' bit, it is willing to perform DNS updates to PTR records
on behalf of the client. on behalf of the client.
3.2.2. Receiving a DHCP Request with the IP Address Extension 3.2.2. Receiving a DHCP Request with the IP Address Extension
When a server receives a request for an IP address, it consults its When a server receives a request for an IP address, it consults its
allocation tables and determines an IP address appropriate for the allocation tables and determines an IP address appropriate for the
requesting client and the subnet to which the client is attached. requesting client and the link to which the client is attached. The
The subnet can be determined by the Agent address in the DHCP Request link can be determined by the Agent address in the DHCP Request
message header, or, when there is no relay, by the subnet of the 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 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
subnet when there is no Agent address included in the message header. link when there is no Agent 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 Releas
message in [4]), the server MUST perform the reverse service by message in [3]), 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 preferred lifetime - the preferred lifetime
- the valid lifetime - the valid lifetime
skipping to change at page 11, line 6 skipping to change at page 10, line 43
Otherwise, the client can subsequently update DNS if needed (i.e., Otherwise, the client can subsequently update DNS if needed (i.e.,
the server didn't do it). 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 zero out the preferred lifetime and extensions, one to reduce the the preferred lifetime and reduce the
reduce the valid lifetime for the old address, and another to give valid lifetime for the old address, and another to give the client
the client its new address. its new address.
On a practical note, note also that if the DHCP administrator uses On a practical note, if the DHCP administrator uses site-local
site-local addresses for IP address allocation to clients, there will addresses for IP address allocation to clients, there will be less
be less need for renumbering whenever the site moves to a new site need for renumbering whenever the site moves to a new site prefix or
prefix or set of site prefixes. set of site prefixes. Of course, this only works when the site does
not need global addresses.
3.2.4. Use with the DHCP Reconfigure message 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
indicate the DNS name. indicate the DNS name.
3.2.5. Receiving a DHCP Release with the IP Address Extension 3.2.5. Receiving a DHCP Release with the IP Address Extension
When a DHCP client releases its IP address, by including an When a DHCP client releases its IP address, by including an
appropriate IP Address Extension with the DHCP Release message, the appropriate IP Address Extension with the DHCP Release message, the
skipping to change at page 12, line 29 skipping to change at page 12, line 9
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 DHCP includes an extension for the specification of the Universal
Coordinated Time Offset (type 2, defined in section 4.1), which is Coordinated Time Offset (type 2, defined in section 4.1), which is
defined as a two's complement 32-bit integer representing the offset defined as a two's complement 32-bit integer representing the offset
in seconds from UTC. Unfortunately, the UTC offset extension does not in seconds from UTC. Unfortunately, the UTC offset extension does not
provide enough information for an Internet client to determine such provide enough information for an Internet client to determine such
timezone-related details as the timezone names, daylight savings time timezone-related details as the timezone names, daylight savings time
start and end times in addition to the timezone UTC offsets. This start and end times in addition to the timezone UTC offsets. This
extension (analogous to that proposed for DHCPv4 [6]) allows delivery extension (analogous to that proposed for DHCPv4 [5]) allows delivery
of timezone information in the form of a IEEE 1003.1 POSIX Timezone of timezone information in the form of a IEEE 1003.1 POSIX Timezone
specifier [10]. specifier [9].
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 | 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 The extension type is 3. This IEEE 1003.1 POSIX Timezone is detailed
skipping to change at page 15, line 17 skipping to change at page 14, line 30
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 | 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 [16] name servers available to the client. Servers SHOULD be System [15] 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 Type for the domain name server extension is 6. The minimum
Length for this extension is 16 octets, and the Length MUST always be Length for this extension is 16 octets, and the Length MUST always 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.
skipping to change at page 15, line 39 skipping to change at page 15, line 5
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name (variable length) ... | Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 10. Its minimum Length is 1. The Type for this extension is 10. Its minimum Length is 1.
The domain name is a null-terminated ASCII string, Length octets in The domain name is a ASCII string, Length octets in size.
size, including the terminating zero octet.
If the Domain Name extension is not specified, and the IP Address If the Domain Name extension is not specified, and the IP Address
extension received by a client contains a FQDN, then the client may 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 take the part of the FQDN after the first '.' octet as the Domain
Name. 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. Directory Agent Extension
Entities using the Service Location Protocol [21] need to find out Entities using the Service Location Protocol [20] need to find out
the address of Directory Agents in order to transact messages. They the address of Directory Agents in order to transact messages. They
may need to discover the correct scope to be used in conjunction with may need to discover the correct scope to be used in conjunction with
the service attributes which are exchanged using the Service Location the service attributes which are exchanged using the Service Location
Protocol. The scope MAY be denoted in any standardized character Protocol. The scope MAY be denoted in any standardized character
set. set.
This extension requests or specifies a Directory Agent (DA), along This extension requests or specifies a Directory Agent (DA), along
with zero or more scopes supported by that DA. Note that this with zero or more scopes supported by that DA. Note that this
extension MAY be included multiple times in the same DHCP Request or extension MAY be included multiple times in the same DHCP Request or
DHCP Reply. If so, then the extensions SHOULD be included in order DHCP Reply. If so, then the extensions SHOULD be included in order
skipping to change at page 17, line 25 skipping to change at page 16, line 38
description). description).
Service Scope Service Scope
The characters denoting the scope. The length of the The characters denoting the scope. The length of the
scope is only indicated implicitly by the overall length scope is only indicated implicitly by the overall length
of the extension. of the extension.
In order to simplify administration of the configuration of Directory In order to simplify administration of the configuration of Directory
Agents for Service Location Protocol clients, the Directory Agent Agents for Service Location Protocol clients, the Directory Agent
can be indicated by presenting its FQDN or host name instead of its can be indicated by presenting its FQDN or host name instead of its
IP address. This allows renumbering to proceed more smoothly [7]. IP address. This allows renumbering to proceed more smoothly [6].
When the FQDN or host name is used, the server sets the 'F' bit. The When the FQDN or host name is used, the server sets the 'F' bit. The
host name can be distinguished from the FQDN by the presence of a '.' host name can be distinguished from the FQDN by the presence of a '.'
character. In any case, the DA length field is set to be the length character. In any case, the DA length field is set to be the length
of the Directory Agent field. When the 'F' bit is not set, the DA of the Directory Agent field. When the '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. The client may request any Directory Agent with a particular scope. The client may request any Directory Agent with a particular
scope, by including the Directory Agent extension in a DHCP Request scope, by including the Directory Agent extension in a DHCP Request
message with no Directory Agent address included (the 'D' bit set to message with no Directory Agent address included (the 'D' bit set to
zero), and the characters denoting the scope. zero), and the characters denoting the scope.
5.2. Service Scope Extension 5.2. 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) [21], when responding to Service Request messages as Agent (SA) [20], when responding to Service Request messages as
specified by the Service Location Protocol. This extension MAY be specified by the Service Location Protocol. This extension MAY be
included multiple times in the same DHCP Request or DHCP Reply. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Service Scope ... | Char Encoding | Service Scope ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 33 skipping to change at page 17, line 38
Service Scope Service Scope
the characters denoting the scope. the characters denoting the scope.
Note that more than one Service Scope extension may be present in a Note that more than one Service Scope extension may be present in a
DHCP message. The length of the scope is only indicated implicitly DHCP message. The length of the scope is only indicated implicitly
by the overall length of the extension. by the overall length of the extension.
5.3. Network Time Protocol Servers Extension 5.3. Network Time Protocol Servers Extension
This extension specifies a list of IP addresses indicating NTP [14] This extension specifies a list of IP addresses indicating NTP [13]
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 | 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 type for this extension is 18. Its minimum Length is 16, and the
Length MUST be a multiple of 16. Length MUST be a multiple of 16.
5.4. Network Information Service Domain Extension 5.4. Network Information Service Domain Extension
This extension specifies the name of the client's NIS [13] domain. This extension specifies the name of the client's NIS [12] domain.
The domain is formatted as a character string consisting of 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 type for this extension is 19. Its minimum Length is 1. The type for this extension is 19. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS Domain Name (variable length) ... | NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. Network Information Servers Extension 5.5. Network Information Servers Extension
This extension specifies a list of IP addresses indicating NIS [13] This extension specifies a list of IP addresses indicating NIS [12]
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 | 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 type for this extension is 20. Its minimum Length is 16, and the
Length MUST be a multiple of 16. Length MUST be a multiple of 16.
5.6. Network Information Service+ Domain Extension 5.6. Network Information Service+ Domain Extension
This extension specifies the name of the client's NIS+ [13] This extension specifies the name of the client's NIS+ [12]
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 type for this extension is 21. Its minimum Length 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ Client Domain Name (variable length) ... | NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7. Network Information Service+ Servers Extension 5.7. Network Information Service+ Servers Extension
This extension specifies a list of IP addresses indicating NIS+ [13] This extension specifies a list of IP addresses indicating NIS+ [12]
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses | | NIS+ server addresses |
| (16 octets each) | | (16 octets each) |
skipping to change at page 22, line 17 skipping to change at page 21, line 15
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 16-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 SHOULD NOT use the extension in DHCP Solicit messages (see [4]), but SHOULD NOT use the extension in DHCP Solicit messages (see [3]),
and MUST NOT use the extension in other DHCP messages. and MUST NOT use the extension in other DHCP messages.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max DHCPv6 Message Length | | Max DHCPv6 Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 44 skipping to change at page 23, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator (variable length) ... | Authenticator (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 84 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 [3] identifying which SPI A Security Parameters index [2] identifying which
security context among those available between the DHCPv6 security context among those available between the DHCPv6
client and server. client and server.
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [15](NTP) A 64-bit timestamp (in Network Time Protocol [14](NTP)
format) (see section 9.1). format) (see section 9.1).
Authenticator Authenticator
(variable length) (See Section 9.2.) (variable length) (See Section 9.2.)
This authentication extension remedies the inability of IPsec to This authentication extension remedies the inability of IPsec to
provide for non end-to-end authentication, since authentication is provide for non end-to-end authentication, since authentication is
needed even when the client has no IPv6 address of large enough scope needed even when the client has no IPv6 address of large enough scope
to reach the DHCP server. The extension can be originated by either to reach the DHCP server. The extension can be originated by either
the DHCPv6 Client or DHCPv6 server to authenticate the rest of the the DHCPv6 Client or DHCPv6 server to authenticate the rest of the
data in the DHCPv6 message. The default authentication algorithm is data in the DHCPv6 message. The default authentication algorithm is
defined in section 9.2. defined in section 9.2.
Note that SPI values 0 through 255 are reserved and, if used, MUST Note that SPI values 0 through 255 are reserved and, if used, MUST
conform to the security context defined by that value in the most conform to the security context defined by that value in the most
recent Assigned Numbers RFC (e.g., [18]). recent Assigned Numbers RFC (e.g., [17]).
7.6. Client Key Selection Extension 7.6. 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
skipping to change at page 25, line 40 skipping to change at page 24, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | | Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 85 Type 85
Length 4 Length 4
SPI A Security Parameters index [3] identifying a security SPI A Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts context between a pair of nodes among the contexts
available in the security association defined between available in the security association defined between
the DHCPv6 client and server. SPI values 0 through 255 the DHCPv6 client and server. SPI values 0 through 255
are reserved and, if used, MUST conform to the security are reserved and, if used, MUST conform to the security
context defined by that value as defined in the most context defined by that value as defined in the most
recent Assigned Numbers RFC (e.g., [9]). recent Assigned Numbers RFC (e.g., [8]).
8. End extension specification 8. End extension specification
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 25 skipping to change at page 25, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Security Considerations 9. Security Considerations
There is an urgent need to define some security protocol for use There is an urgent need to define some security protocol for use
with DHCPv6, since otherwise malicious parties could create numerous with DHCPv6, since otherwise malicious parties could create numerous
denial-of-service style attacks based on depleting available server denial-of-service style attacks based on depleting available server
resources or providing corrupted or infected data to unsuspecting resources or providing corrupted or infected data to unsuspecting
clients. The following sections discuss aspects of security relevant clients. The following sections discuss aspects of security relevant
for users of the Client-Server Authentication extension 7.5. See for users of the Client-Server Authentication extension 7.5. See
also the Security Considerations in the companion specification [4]. also the Security Considerations in the companion specification [3].
9.1. Replay Protection 9.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [15](NTP) format, is A 64-bit timestamp, in Network Time Protocol [14](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 9.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [12], using The default authentication algorithm is HMAC [11], using
keyed-MD5 [19]. Given a secret key K, and "data" the information to keyed-MD5 [18]. 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
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.
skipping to change at page 27, line 41 skipping to change at page 26, line 39
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 3. The author documents the new extension, using the newly obtained
extension number, as an Internet Draft. extension number, as an Internet Draft.
4. The author submits the Internet Draft for review through the 4. The author submits the Internet Draft for review through the
IETF standards process as defined in "Internet Official Protocol IETF standards process as defined in "Internet Official Protocol
Standards" [11]. The new extension will be submitted for Standards" [10]. The new extension will be submitted for
eventual acceptance as an Internet Standard. eventual acceptance as an Internet Standard.
5. The new extension progresses through the IETF standards 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 6. 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.
skipping to change at page 29, line 21 skipping to change at page 28, line 21
by Steve Alexander and Ralph Droms. Thanks to Erik Guttman for his by Steve Alexander and Ralph Droms. Thanks to Erik Guttman for his
helpful suggestions for the Service Location extensions. Thanks to helpful suggestions for the Service Location extensions. Thanks to
Matt Crawford and Erik Nordmark for their careful review as part of Matt Crawford and Erik Nordmark for their careful review as part of
the Last Call process. the Last Call process.
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] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
Extensions. RFC 2132, March 1997.
[3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol [3] 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-11.txt, May 1997. (work in
progress). progress).
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement [4] 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 [5] 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, [6] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996. February 1996.
[8] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [7] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[9] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic [8] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994. Routing Encapsulation (GRE). RFC 1701, October 1994.
[10] IEEE. 1003.1 POSIX Timezone Specification, 1988. [9] IEEE. 1003.1 POSIX Timezone Specification, 1988.
[11] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1, [10] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
July 1997. July 1997.
[12] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing [11] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997. for Message Authentication. RFC 2104, February 1997.
[13] Sun Microsystems. System and Network Administration, March [12] Sun Microsystems. System and Network Administration, March
1992. 1992.
[14] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for [13] 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.
[15] David L. Mills. Network Time Protocol (Version 3): [14] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[16] P. Mockapetris. Domain Names - Concepts and Facilities. STD [15] P. Mockapetris. Domain Names - Concepts and Facilities. STD
13, November 1987. 13, November 1987.
[17] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2, [16] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2,
October 1994. October 1994.
[18] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, [17] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994. October 1994.
[19] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [18] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[20] S. Thomson and T. Narten. IPv6 stateless address [19] S. Thomson and T. Narten. IPv6 stateless address
autoconfiguration. RFC 1971, August 1996. autoconfiguration. RFC 1971, August 1996.
[21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [20] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. RFC 2165, July 1997.
[22] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [21] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
in the Domain Name System (DNS). RFC 2136, April 1997. in the Domain Name System (DNS). RFC 2136, April 1997.
Chair's Addresses Chair's Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
 End of changes. 

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