draft-ietf-dhc-v6exts-06.txt   draft-ietf-dhc-v6exts-07.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems INTERNET DRAFT Sun Microsystems
26 May 1997 30 July 1997
Extensions for DHCPv6 Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-v6exts-06.txt draft-ietf-dhc-v6exts-07.txt
Status of This Memo Status of This Memo
This document is a submission to the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF).
should be submitted to the dhcp-v6@bucknell.edu mailing list. Comments should be submitted to the dhcp-v6@bucknell.edu mailing
list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
skipping to change at page 1, line 40 skipping to change at page 1, line 41
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 [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 Each superseding document will include the entire current list of
valid extensions. valid extensions.
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. IPv6 Address Extension 3 3. IP Address Extension 3
3.1. Client Considerations for the IPv6 Address extension . . 5 3.1. Client Considerations for the IP Address extension . . . 6
3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 5 3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6
3.1.2. Use with the DHCP Request message . . . . . . . . 6 3.1.2. Use with the DHCP Request message . . . . . . . . 7
3.1.3. Receiving as part of the DHCP Reply message . . . 7 3.1.3. Receiving as part of the DHCP Reply message . . . 8
3.1.4. Use with the DHCP Release message . . . . . . . . 7 3.1.4. Use with the DHCP Release message . . . . . . . . 9
3.2. Server Considerations for the IPv6 Address extension . . 7 3.2. Server Considerations for the IP Address extension . . . 9
3.2.1. Use with the DHCP Advertise message . . . . . . . 7 3.2.1. Use with the DHCP Advertise message . . . . . . . 9
3.2.2. Receiving a DHCP Request with the IPv6 Address 3.2.2. Receiving a DHCP Request with the IP Address
Extension . . . . . . . . . . . . . . . . 8
3.2.3. Use with the DHCP Reply message . . . . . . . . . 8
3.2.4. Use with the DHCP Reconfigure message . . . . . . 9
3.2.5. Receiving a DHCP Release with the IPv6 Address
Extension . . . . . . . . . . . . . . . . 9 Extension . . . . . . . . . . . . . . . . 9
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 9 3.2.3. Use with the DHCP Reply message . . . . . . . . . 10
3.2.4. Use with the DHCP Reconfigure message . . . . . . 11
4. General Extensions 9 3.2.5. Receiving a DHCP Release with the IP Address
4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 10 Extension . . . . . . . . . . . . . . . . 11
4.2. Domain Name Server Extension . . . . . . . . . . . . . . 10 3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11
4.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 11
5. Service Location Extensions 11
6. Directory Agent Extension 12
7. Service Scope Extension 13
8. IP Layer Parameters per Interface 14 4. General Extensions 11
8.1. Static Route Extension . . . . . . . . . . . . . . . . . 14 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 12
4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 12
4.2.2. An Example . . . . . . . . . . . . . . . . . . . 14
4.2.3. Timezone 0ption Precedence . . . . . . . . . . . 14
4.3. Domain Name Server Extension . . . . . . . . . . . . . . 15
4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 15
9. TCP Parameters 15 5. Application and Service Parameters 15
9.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 15 5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 16
5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 17
5.3. Network Time Protocol Servers Extension . . . . . . . . . 18
5.4. Network Information Service Domain Extension . . . . . . 19
5.5. Network Information Servers Extension . . . . . . . . . . 19
5.6. Network Information Service+ Domain Extension . . . . . . 19
5.7. Network Information Service+ Servers Extension . . . . . 20
5.8. Vendor Specific Information . . . . . . . . . . . . . . . 20
10. Vendor Specific Information 15 6. TCP Parameters 21
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21
11. DHCPv6 Extensions 16 7. DHCPv6 Extensions 22
11.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 16 7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 22
11.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 17 7.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 22
11.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 17 7.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 23
11.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 18 7.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 23
11.5. Client-Server Authentication Extension . . . . . . . . . 19 7.5. Client-Server Authentication Extension . . . . . . . . . 24
11.6. Client Key Selection Extension . . . . . . . . . . . . . 20 7.6. Client Key Selection Extension . . . . . . . . . . . . . 25
12. End extension specification 20 8. End extension specification 26
13. Security Considerations 20 9. Security Considerations 26
13.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 21 9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 26
13.2. Default Authentication Algorithm . . . . . . . . . . . . 21 9.2. Default Authentication Algorithm . . . . . . . . . . . . 26
14. Defining New Extensions 21 10. Defining New Extensions 27
15. Acknowledgements 23 11. Acknowledgements 29
Chair's Address 25 Chair's Address 31
Author's Address 25 Author's Address 31
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 [4]. 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 [5]. 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.
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 14. Information on registering new extensions is contained in section 10.
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 - Miscellaneous host configuration
- Service Location configuration - Service Location configuration
- Miscellaneous network layer - Miscellaneous network layer
- 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 [15], and not will be satisfied by the Service Location Protocol [21], 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 DHCPv6 extensions have the same format as the BOOTP "vendor
extensions" [2]. Extensions may be fixed length or variable length. extensions" [2]. Extensions may be fixed length or variable length.
All extensions begin with a type field which is two octets long, All extensions begin with a type field, which is two octets long and
which uniquely identifies the extension. Fixed length extensions uniquely identifies the extension. Fixed length extensions without
without data consist of only the two octet type field. Only data consist of only the two octet type field. Only extension 65535
extension 65535 is fixed length. All other extensions are variable is fixed length. All other extensions are variable length with a two
length with a two octet 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 two 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 variable length extensions the length of data. In the case of some extensions the length field is a
field is a constant but MUST still be specified. constant but MUST still be specified. In each case, unless otherwise
specified, the length field specifies the length of the extension in
octets. Any extensions defined subsequent to this document should
contain a Length field even if the length is fixed or zero. There
is no particular requirement for alignment of the data fields within
existing DHCPv6 extensions.
Any extensions defined subsequent to this document should contain a Unrecognized extensions SHOULD be skipped by ignoring the number of
length field of two octets in length even if the length is fixed or octets specified in the length field, and processing continued for
zero. Unknown options MAY be skipped by ignoring the number of bytes subsequent extensions. Unless and until specified otherwise by use
specified in the length field. All multi-octet quantities are in of extension type 64 (see section 7.1), DHCP entities MUST assume
network byte-order. that the maximum DHCP message size including extensions is 1500
octets.
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. default values specified, if any. Whenever an extension is received
as part of a DHCP message, any reserved fields of the message MUST
be ignored, and processing continued as if the reserved fields were
zero.
2.1. Character Encoding and String Issues 2.1. Character Encoding and String Issues
Values for character encoding can be found in the Internet Assigned Certain extensions (e.g., type 16 described in section 5.1) have
Numbers Authority's (IANA) database 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 http://www.isi.edu/in-notes/iana/assignments/character-sets
and have the values referred by the MIBEnum value. Note that in some 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 character sets, each character may require two or more octets of data
for its representation. for its representation.
The encoding will determine the interpretation of all character data The encoding will determine the interpretation of all character data
in the corresponding fields of particular extensions. There is no in the corresponding fields of particular extensions. There is no
way to mix ASCII and UNICODE, for example. All responses MUST be in way to mix US-ASCII and UNICODE, for example. All responses MUST be
the character set of the request or use US-ASCII. If a request is 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 sent to a DHCP server, which is unable to manipulate or store the
character set of the incoming message, the request will fail. The character set of the incoming message, the request will fail. The
server returns a CHARSET_NOT_UNDERSTOOD error (24) in a DHCP Reply server returns a status code of 24in a DHCP Reply message in this
message in this case. Requests using US-ASCII (MIBEnum value == 3) case. Requests using US-ASCII (MIBEnum value == 3) will never fail
will never fail for this reason, since all DHCP entities MUST be able for this reason, since all DHCP entities MUST be able to accept this
to accept this character set. All DNS-related strings are presumed character set. All DNS-related strings are presumed to be encoded in
to be encoded in US-ASCII. US-ASCII.
3. IPv6 Address Extension 3. IP Address Extension
The IPv6 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 IPv6 Address option 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 IPv6 Address extension can specify how of the fields within the IP Address extension can specify how DNS may
DNS [16] may be updated. be updated [22].
An IPv6 Address Extension can contain at most one IPv6 address. To To ask for an IP address in a DHCP Request message, a client includes
specify more than one IPv6 address, multiple extensions are used. To an IP Address Extension. To renew or extend the lifetime of a
ask for an IPv6 address in a DHCP Request message, a client includes particular IP address, the client puts that address in the client
an IPv6 Address Extension. To renew or extend the lifetime of a address field. To request the allocation of a new but unspecified IP
particular IPv6 address, the client puts that address in the client address, the client omits the client address field. The IP address
address field. To request the allocation of a new but unspecified returned by the server in the latter case will be compatible with a
IPv6 address, the client omits the client address field. The IPv6 subnet prefix of the link to which the client is currently attached.
address returned by the server in the latter case will be compatible
with a subnet prefix of the link to which the client is currently An IP Address Extension can contain at most one IP address. To
attached. 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 | error-code |C|L|Q|A|P| reserved | | pfx-size | status |C|L|Q|A|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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 (variable) The length of the Extension. Length (unsigned integer, variable) The length of the Extension
in octets.
pfx-size pfx-size
If the client address is present (the 'C' bit is set), If the client address is present (the 'C' bit is set), a
a nonzero pfx-size indicates the length of the routing nonzero pfx-size is the number of leftmost bits of the
prefix, counting the number of leading 1 bits to be client's IPv6 address which make up the routing prefix.
applied to the client's IPv6 address to get the routing Otherwise, if the 'C' bit is not set, pfx-size MUST be
prefix. Otherwise, if the 'C' bit is not set, pfx-size zero.
MUST be zero.
error-code
If the server is unable to honor the client's request,
the reason is indicated in the error-code. Current
values are as follows:
0 request granted, no errors status If the server is unable to honor the client's request,
16 dynDNS Not Available at this time the reason is indicated in the status.
17 dynDNS Not Implemented
18 Authentication failed for this client
19 Authoritative DNS Server could not be found
20 Resource AAAA Record Parameter Problem
21 Resource PTR Record Parameter Problem
22 Unable to honor required extension parameters
23 DNS name string error
C If the 'C' bit is set, the field containing the IPv6 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
are required, and must be made available by the server or are required, and must be made available by the server or
else the extension must be rejected. else the extension must be rejected.
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.
client address client address
The IPv6 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 IPv6 address in seconds The preferred lifetime of the IP address in seconds
valid lifetime valid lifetime
The valid lifetime of the IPv6 address in seconds The valid lifetime of the IP address in seconds
DNS name DNS name
The DNS name (a zero-terminated string of ASCII octets) The DNS name (a null-terminated string of ASCII octets)
to be used by the client (variable length). to be used by the client (variable length).
The following values for the status field are defined within this
document:
0 request granted, no errors
18 Security parameters failed for this client
20 Resource AAAA Record Parameter Problem
21 Resource PTR Record Parameter Problem
22 Unable to honor required extension parameters
23 DNS name string error
33 The name server was unable to interpret the request
due to a format error.
34 dynDNS Not Available at this time
35 Some name that ought to exist, does not exist.
36 The name server does not support the specified Opcode.
36 dynDNS Not Implemented
37 The name server refuses to perform the specified
operation for policy or security reasons.
38 Some name that ought not to exist, does exist.
39 Some RRset that ought not to exist, does exist.
40 Some RRset that ought to exist, does not exist.
41 The server is not authoritative for the zone named in
the Zone Section.
42 A name used in the Prerequisite or Update Section is
not within the zone denoted by the Zone Section.
34 Authoritative DNS Server could not be found
Status values 34through 21are described more fully within RFC
2136 [22]. Up-to-date values for the values of the status field are
specified in the most recent "Assigned Numbers" [17]. To inform the
client of the DYNDNS [22] 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
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. If the last byte of the DNS name is not zero, the IPv6 present. If the last octet of the DNS name is not zero, the IP
Address Extension MUST be rejected, with error code 23. Address Extension MUST be rejected, with status 23.
If the 'Q' bit is set, the values or actions requested by the C, L,
A, and P bits are required, and MUST be provided, or the extension
MUST be rejected with status code 22.
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.
3.1. Client Considerations for the IPv6 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
address for updating DNS. This can be done even with IP addresses
obtained by Stateless Address Autoconfiguration [20].
3.1. Client Considerations for the IP Address extension
3.1.1. Address Lifetimes 3.1.1. Address Lifetimes
An IPv6 address returned to a client has a preferred and valid An IP address returned to a client has a preferred and valid
lifetime. The lifetimes represent the lease for addresses provided lifetime. The valid lifetime represents the lease for addresses
to the client, from the server. provided to the client, from the server.
The DHCPv6 philosophy is that the client has the responsibility to The client SHOULD make a new Request for any address that is about
make a new Request for an address that is about to expire, or request to expire, or request a new address or the same address before the
a new address or the same address before the lease actually expires. lease actually expires. If the client does not make a new Request
If the client does not make a new Request for an address, the server for an address, the server SHOULD assume the client does not want
MUST assume the client does not want that address. The server MAY that address. The server MAY provide that address to another client
provide that address to another client requesting an address. requesting an address.
The client MAY request a value for the lifetimes returned by a The client MAY request values for the lifetimes, but the client MUST
server, but the client MUST use the lifetimes provided by the server use the lifetimes provided by the server response.
response.
When the preferred lifetime of an IPv6 address expires, the client's When the preferred lifetime of an IP address expires, the client's
address becomes a deprecated address. See [7] for required handling address becomes a deprecated address. See [8] for required handling
of deprecated IPv6 addresses. When 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 IPv6 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
transmission of the DHCP Request and the reception of the DHCP Reply. transmission of the DHCP Request and the reception of the DHCP Reply.
In this way, the client is best assured that its address lifetimes In this way, the client is best assured that its address lifetimes
will not expire at the DHCP Server before they expire at the client. will not expire at the DHCP Server before they 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 may: In a DHCP Request (for each address extension), a client MUST set the
status code to zero.
- include an IPv6 address and/or a DNS name (which may be a host In a DHCP Request (for each address extension), a client MAY:
name or a FQDN).
- include an IP address and/or a DNS name (which may be a host name
or a FQDN).
- 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.
- specify whether address and/or name and/or lifetime (if present) - indicate the minimum preferred (and/or valid) lifetime, by
is advisory -or- mandatory; supplying a value for the field(s).
- indicate the minimum preferred lifetime - specify whether address, name and lifetimes (if present) are
advisory -or- mandatory, by setting the 'Q' bit.
If the Request is advisory, a server may send different parameters If the Request is advisory, a server may send different parameters
than requested in the DHCP Reply. Otherwise, if the Request is than requested in the DHCP Reply. Otherwise, if the Request is
mandatory, the server MUST reject the Request if it cannot be mandatory, the server MUST reject the Request if it cannot be
fulfilled. 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. The server that receives the Request is not absolutely
required to honor the client's Request. A DHCP client indicates that required to honor the client's Request. A DHCP client indicates that
it cannot accept anything other than the configuration information it cannot accept anything other than the configuration information
(e.g., IP address) listed in the IP Address extension to the DHCP (e.g., IP address) listed in the IP Address extension to the DHCP
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
skipping to change at page 7, line 4 skipping to change at page 8, line 23
required to honor the client's Request. A DHCP client indicates that required to honor the client's Request. A DHCP client indicates that
it cannot accept anything other than the configuration information it cannot accept anything other than the configuration information
(e.g., IP address) listed in the IP Address extension to the DHCP (e.g., IP address) listed in the IP Address extension to the DHCP
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 error-code Reply which it accepts (see [4]), it first inspects the status to see
to see whether the requested information has been granted. If the whether the requested information has been granted. If the status is
error-code is nonzero, the client should log the error, display nonzero, the client should log the error, display the error condition
the error condition for action by the user and/or the network for action by the user and/or the network administrator. Nonzero
administrator. Nonzero error-codes almost always indicate that status almost always indicates that the client will be need to modify
the client will be need to modify its request before it could be its request before it could be satisfied by the replying DHCP server,
satisfied by the replying DHCP server, or alternatively that the or alternatively that the replying DHCP server will need to be given
replying DHCP server will need to be given updated configuration updated configuration information for the client.
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) [14]; however, if the perform Duplicate Address Detection (DAD) [20]; 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 a new 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):
- the client may include an IPv6 address and/or a DNS name (which - the client may include an IP address and/or a DNS name (which may
may be a host name or a FQDN). be a host name or a FQDN).
- the server MUST update DNS to delete the AAAA record if the - the server MUST update DNS to delete the AAAA record or records
server originally updated DNS when the address was allocated to that the server originally used when updating DNS when the
the client, and likewise for the PTR record (regardless of the address was allocated to the client, and likewise for the PTR
setting of the 'A' or 'P' bits in the address extension). 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 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.
3.2. Server Considerations for the IPv6 Address extension If the DNS name is provided ONLY all client AAAA records for that
name will be deleted.
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 FQDN or host name - the cllient's FQDN or host name
- the preferred lifetime - the preferred 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 or PTR records on behalf of the client. to AAAA records on behalf of the client. Likewise, if the server
sets the 'P' bit, it is willing to perform DNS updates to PTR records
on behalf of the client.
3.2.2. Receiving a DHCP Request with the IPv6 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
allocation tables and determines an IP address appropriate for the
requesting client and the subnet to which the client is attached.
The subnet can be determined by the Agent address in the DHCP Request
message header, or, when there is no relay, by the subnet of the
interface on which the request was received. This is true in the
latter case because the client and the server have to be on the same
subnet 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 IPv6 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 IPv6 address (by including an the client eventually releases the IP address (see the DHCP Releas
appropriate IPv6 Address with the DHCP Release message), the server message in [4]), the server MUST perform the reverse service by
can 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 indicate in the IP address extension
- 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 DNS name - the DNS name
- whether AAAA has been DNS updated (by setting the 'A' bit) - whether AAAA has been DNS updated (by setting the 'A' bit)
- whether PTR has been DNS updated (by setting the 'P' bit) - whether PTR has been DNS updated (by setting the 'P' bit)
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 error code 22. MUST return a DHCP reply with the status 22.
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 invalidate the old address, and another to give extensions, one to reduce the zero out the preferred lifetime and
reduce the valid lifetime for the old address, and another to give
the client its new address. the client its new address.
On a practical note, note also that if the DHCP administrator uses
site-local addresses for IP address allocation to clients, there will
be less need for renumbering whenever the site moves to a new site
prefix or set of site prefixes.
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 IPv6 Address Extension 3.2.5. Receiving a DHCP Release with the IP Address Extension
When a DHCP client releases its IPv6 address, by including an When a DHCP client releases its IP address, by including an
appropriate IPv6 Address Extension with the DHCP Release message, the appropriate IP Address Extension with the DHCP Release message, the
server determines whether or not it was originally responsible for server determines whether or not it was originally responsible for
updating the DNS AAAA record or PTR record for the client. If so, updating the DNS AAAA record or PTR record for the client. If so,
then the server must also perform the reverse service by updating DNS then the server must also perform the reverse service by updating DNS
again to delete the client records. again to delete the client records.
3.3. DHCP Relay Considerations 3.3. DHCP Relay Considerations
The DHCP Relay MUST NOT change any information in any DHCPv6 The DHCP Relay MUST NOT change any information in any DHCPv6
Extension fields. All Extension information flows between DHCPv6 Extension fields. All Extension information flows between DHCPv6
Server and DHCPv6 Client without modification by any Relay. Server and DHCPv6 Client without modification by any Relay.
skipping to change at page 10, line 15 skipping to change at page 12, line 15
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Offset | | Time Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for the time offset extension is 2, and its length is 4 The Type for the time offset extension is 2, and its Length is 4
octets. The time offset field specifies the offset of the client's octets. The time offset field specifies the offset of the client's
subnet in seconds from Coordinated Universal Time (UTC). The offset clock in seconds from Coordinated Universal Time (UTC). The offset is
is expressed as a signed 32-bit integer. expressed as a signed (two's complement) 32-bit integer.
4.2. Domain Name Server Extension 4.2. IEEE 1003.1 POSIX Timezone extension
DHCP includes an extension for the specification of the Universal
Coordinated Time Offset (type 2, defined in section 4.1), which is
defined as a two's complement 32-bit integer representing the offset
in seconds from UTC. Unfortunately, the UTC offset extension does not
provide enough information for an Internet client to determine such
timezone-related details as the timezone names, daylight savings time
start and end times in addition to the timezone UTC offsets. This
extension (analogous to that proposed for DHCPv4 [6]) allows delivery
of timezone information in the form of a IEEE 1003.1 POSIX Timezone
specifier [10].
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE 1003.1 POSIX Timezone string (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The extension type is 3. This IEEE 1003.1 POSIX Timezone is detailed
next, in section 4.2.1.
4.2.1. IEEE 1003.1 POSIX Timezone specifier
.
The format of the IEEE 1003.1 POSIX timezone string is specified as
StdOffset[Dst[Offset],[Start[/Time],End[/Time]]]
where '[' and ']' enclose optional fields, '|' indicates choice
of exactly one of the alternatives, ',' and '/' represent literal
characters present in the string, and:
Std three or more octets for the standard timezone (Std).
Any characters (or case) except a leading colon, digits,
comma, minus or plus sign are allowed.
Offset Indicates the value one must add to local time to
arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset
following Std is required. Digits are always interpreted
as decimal number. If preceded by a '-', the timezone is
east of the Prime Meridian, otherwise it is west ('+' is
optional) The permissible values for hh[:mm[:ss]] are as
follows:
hh 0 <= hh <= 23
mm 0 <= mm <= 60
ss 0 <= ss <= 60
Offset has no default value.
Dst three or more octets for the daylight savings timezone.
If Dst is missing, then daylight savings time does not
apply in this locale. If no Offset follows Dst, then
Dst is assumed to be one hour ahead of standard time.
Any characters (or case) except a leading colon, digits,
comma, minus or plus sign are allowed.
Start Indicates the day of the year, in one of the formats
indicated below, when to change to daylight savings time.
The 'Time' field (which follows immediately after a '/'
character, if present) indicates when the change is made,
in local time.
End Indicate the day of the year, in one of the formats
indicated below, when to change back from daylight
savings time. The 'Time' field (which follows
immediately after a '/' character, if present) indicates
when the change is made, in local time.
Time Time has the same format as Offset, except that no
leading '-' or '+' is permitted. The default is
02:00:00.
The day of the year can be given in one of the following formats:
Jn The julian day n, (1 <= n <= 365). Leap days are not
counted.
n zero-based julian day, (0 <= n <= 365). Leap days are
counted so it is possible to refer to Feb 29.
Mm.n.d The 'd'th day, (0 <= d <= 6) of week 'n' of month 'm' of
the year (1 <= n <= 5, 1 <= m <= 12, where week 5 means
last 'd' day in month 'm' which may occur in either the
fourth or the fifth week. Week '1' is the first week in
which the 'd' day occurs.
4.2.2. An Example
For Eastern USA time zone, 1986, the Posix timezone string is as
follows:
EST5EDT4,116/02:00:00,298/02:00:00
4.2.3. Timezone 0ption Precedence
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 Option. 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
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 [12] name servers available to the client. Servers SHOULD be System [16] 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.3. Domain Name 4.4. Domain Name
This extension specifies the domain name that client should use when This extension specifies the default domain name that client should
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 | 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 null-terminated ASCII string, Length octets in
size, including the terminating zero octet. size, including the terminating zero octet.
If the Domain Name extension is not specified, and the IPv6 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. Service Location Extensions 5. Application and Service Parameters
Entities using the Service Location Protocol [15] need to find out This section details some miscellaneous extensions used to configure
the address of Directory Agents in order to transact messages. In miscellaneous applications and services.
certain other instances they 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.
Note that each extension listed below MAY be included multiple times 5.1. Directory Agent Extension
in the same DHCP Request or DHCP Reply. If so, then the extensions
SHOULD be included in order of decreasing preference.
6. Directory Agent Extension Entities using the Service Location Protocol [21] need to find out
the address of Directory Agents in order to transact messages. They
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 This extension requests or specifies a Directory Agent (DA), along
with zero or more scopes supported by that DA. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | DA length |D|M|F|S| rsv | | Char Encoding | DA length |D|M|F|S| rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Directory Agent (variable length) ... | Directory Agent (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) Service Scope (variable length) ... | (if present) Service Scope (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 16 Type 16
Length (variable) The length of the extension. Length (unsigned integer, variable) The length of the Extension
in octets.
Char Encoding
The standardized encoding for the characters denoting the
scope.
DA Length (unsigned integer, variable) The length of the Directory
Agent field in octets.
D If the 'D' bit is set, the Directory Agent field is D If the 'D' bit is set, the Directory Agent field is
present. present.
F If the 'F' bit is set, the Directory Agent is indicated
by including its variable length host name or Fully
Qualified Domain Name (FQDN) instead of its 4 octet 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 is
the only one that may be used, and multicast methods for the only one that may be used, and multicast methods for
discovering Directory Agents MUST NOT be used. discovering Directory Agents MUST NOT be used.
F If the 'F' bit is set, the Directory Agent is indicated
by including its variable length host name or Fully
Qualified Domain Name (FQDN) instead of its 16 octet IP
address.
S If the 'S' bit is set, the scope is present, encoded in S If the 'S' bit is set, the scope is present, encoded in
the indicated character set. the indicated character set.
rsv reserved; ignored upon reception; MUST be sent as zero rsv reserved; ignored upon reception; MUST be sent as zero
DA Length The length (in octets) of the Directory Agent field.
Directory Agent Directory Agent
The Fully Qualified Domain Name (FQDN), host name, or IP The Fully Qualified Domain Name (FQDN), host name,
address of the Directory Agent. or IP address of the Directory Agent (see following
description).
Char Encoding
The standardized encoding for the characters denoting the
scope.
Service Scope Service Scope
The characters denoting the scope. The characters denoting the scope. The length of the
scope is only indicated implicitly by the overall length
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 [6]. IP address. This allows renumbering to proceed more smoothly [7].
When the FQDN or host name is used, the server sets the 'F' bit. The 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 4. 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 message with no Directory Agent address included (the 'D' bit set to
to zero), and the characters denoting the scope. The length of the zero), and the characters denoting the scope.
scope is only indicated implicitly by the overall length of the
extension.
7. 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) [15], when responding to Service Request messages as Agent (SA) [21], when responding to Service Request messages as
specified by the Service Location Protocol. specified by the Service Location Protocol. This extension MAY 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Service Scope ... | Char Encoding | Service Scope ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code 17 Type 17
Length (variable) The length of the extension. Length (unsigned integer, variable) The length of the Extension
in octets.
Char Encoding Char Encoding
The standardized encoding for the characters denoting the The standardized encoding for the characters denoting the
scope. scope.
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.
8. IP Layer Parameters per Interface 5.3. Network Time Protocol Servers Extension
This section details the extensions that affect the operation of the
IP layer on a per-interface basis. It is expected that a client can
issue multiple requests, one per interface, in order to configure
interfaces with their specific parameters.
8.1. Static Route Extension This extension specifies a list of IP addresses indicating NTP [14]
servers available to the client. Servers SHOULD be listed in order
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination address 1 | | NTP server addresses |
| (16 octets) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router address 1 |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination address 2 |
| (16 octets) | The type for this extension is 18. Its minimum Length is 16, and the
Length MUST be a multiple of 16.
5.4. Network Information Service Domain Extension
This extension specifies the name of the client's NIS [13] domain.
The domain is formatted as a character string consisting of
characters from the US-ASCII character set.
The type for this extension is 19. Its minimum Length is 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router address 2 | | Type | Length |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|additional Destination/Router address pairs (32 octets each) ... | NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This extension specifies a list of static routes that the client 5.5. Network Information Servers Extension
should install in its routing cache. If multiple routes to the same
destination are specified, they are listed in the order in which the
client should make use of them.
The routes consist of a list of IP address pairs. The first address This extension specifies a list of IP addresses indicating NIS [13]
is the destination address, and the second address is the router for servers available to the client. Servers SHOULD be listed in order
the destination. of preference.
Link-local addresses are illegal destinations for a static route. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 24. The minimum length of this The type for this extension is 20. Its minimum Length is 16, and the
extension is 32, and the length MUST be a multiple of 32. Length MUST be a multiple of 16.
9. TCP Parameters 5.6. Network Information Service+ Domain Extension
This section lists the extensions that affect the operation of the This extension specifies the name of the client's NIS+ [13]
TCP layer on a per-interface basis. domain. The domain is formatted as a character string consisting of
characters from the US-ASCII character set.
9.1. TCP Keepalive Interval Extension 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive Time Interval | | NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This extension specifies the interval (in seconds) that the 5.7. Network Information Service+ Servers Extension
client TCP should wait before sending a keepalive message on a TCP
connection. The time is specified as a 32-bit unsigned integer.
A value of zero indicates that the client should not generate
keepalive messages on connections unless specifically requested by an
application.
The Type for this extension is 32, and its length is 4. This extension specifies a list of IP addresses indicating NIS+ [13]
servers available to the client. Servers SHOULD be listed in order
of preference.
10. Vendor Specific Information 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses |
| (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for this extension is 22. Its minimum Length is 16, and the
Length MUST be a multiple of 16.
5.8. Vendor Specific Information
This extension is used by clients and servers to exchange vendor- This extension is used by clients and servers to exchange vendor-
specific information. The information is an opaque collection of specific information. The information is an opaque collection of
data, presumably interpreted by vendor-specific code on the clients data, presumably interpreted by vendor-specific code on the clients
and servers. The definition of this information is vendor specific. and servers. The definition of this information is vendor specific.
The vendor is indicated in the class-identifier extension. Servers The vendor is indicated in the class-identifier extension. Servers
not equipped to interpret the vendor-specific information sent by a not equipped to interpret the vendor-specific information sent by a
client MUST ignore it (although it may be reported). Clients which client MUST ignore it (although it may be reported). Clients which
do not receive desired vendor-specific information SHOULD make an do not receive desired vendor-specific information SHOULD make an
attempt to operate without it, although they may do so (and announce attempt to operate without it, although they may do so (and announce
skipping to change at page 16, line 4 skipping to change at page 21, line 10
If a vendor encodes more than one item of information in this If a vendor encodes more than one item of information in this
extension, then the vendor MUST encode the extension using extension, then the vendor MUST encode the extension using
"Encapsulated vendor-specific extensions" as described below: "Encapsulated vendor-specific extensions" as described below:
The Encapsulated vendor-specific extensions field MUST be encoded The Encapsulated vendor-specific extensions field MUST be encoded
as a sequence of type/length/value fields of identical syntax to as a sequence of type/length/value fields of identical syntax to
the fields defined in every other DHCPv6 extension. Extension the fields defined in every other DHCPv6 extension. Extension
65535 (END), if present, signifies the end of the encapsulated 65535 (END), if present, signifies the end of the encapsulated
vendor extensions, not the end of the vendor extensions field. vendor extensions, not the end of the vendor 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
vendor-specific information field is taken as the end of the vendor-specific information field is taken as the end of the
encapsulated vendor-specific extensions field. encapsulated vendor-specific extensions field.
The Type for this extension is 40 and its minimum Length is 4. The Type for this extension is 31 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-specific extension information ... | Vendor-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When encapsulated vendor-specific extensions are used, each one has When encapsulated vendor-specific extensions are used, each one has
the same format as just shown. In other words, all vendor-specific the same format as just shown. In other words, all vendor-specific
extensions are encoded in Type-Length-Value (TLV) format. More than extensions are encoded in Type-Length-Value (TLV) format. More than
one vendor-specific extension can, therefore, be included in the same one vendor-specific extension can, therefore, be included in the same
DHCP "Vendor Specific Information" extension. DHCP "Vendor Specific Information" extension.
11. DHCPv6 Extensions 6. TCP Parameters
This section lists the extensions that affect the operation of the
TCP layer on a per-interface basis.
6.1. TCP Keepalive Interval Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive Time Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This extension specifies the interval (in seconds) that the
client TCP should wait before sending a keepalive message on a TCP
connection. The time is specified as a 32-bit unsigned integer.
A value of zero indicates that the client should not generate
keepalive messages on connections unless specifically requested by an
application.
The Type for this extension is 32, and its Length is 4.
7. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6. This section details the extensions that are specific to DHCPv6.
11.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 [4]),
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 64, and its length is 2. The minimum The Type for this extension is 64, and its Length is 2. The minimum
legal value is 1500. permissible value is 1500.
11.2. Class Identifier 7.2. 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
skipping to change at page 17, line 34 skipping to change at page 23, line 15
identifier value) to the client. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Class Identifier ... | Char Encoding | Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The class identifier is a zero-terminated string of characters in the The class identifier is a string of characters in the character
character set specified by the Char Encoding field (see section 2.1), set specified by the Char Encoding field (see section 2.1), of
of length "Length"-2 octets including the terminating null octet. length "Length"-2 octets. The class identifier represents the class
The class identifier represents the class identifier of which the identifier of which the client is a member.
client is a member.
11.3. Reconfigure Multicast Address 7.3. 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reconfigure Multicast Address | | Reconfigure Multicast Address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the Reconfigure Multicast Address is 66, and the length The Type of the Reconfigure Multicast Address is 66, and the Length
is 16. is 16.
11.4. Renumber DHCPv6 Server Address 7.4. 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 IPv6 address, by records to reflect the server's newly renumbered IP address, by using
using the "Renumber DHCPv6 Server Address" extension. This extension the "Renumber DHCPv6 Server Address" extension. This extension may
may be sent with the DHCP Reconfigure message, and thus can be be sent with the DHCP Reconfigure message, and thus can be multicast
multicast to all of the server's clients instead of being unicast to to all of the server's clients instead of being unicast to each one
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 The Type of the Renumber DHCPv6 Server Address is 67, and the Length
is 16. is 16.
11.5. Client-Server Authentication Extension 7.5. 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 | 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 Type 84
Length 4 for the SPI, plus 8 for the replay protection, plus the Length (unsigned integer, variable) 4 for the SPI, plus 8 for
number of bytes in the Authenticator. the replay protection, plus the number of octets in the
Authenticator.
SPI A Security Parameters index [3] identifying a security SPI A Security Parameters index [3] identifying which
context between a pair of nodes among the contexts security context among those available between the DHCPv6
available in the security association defined between client and server.
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., [8]).
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [11](NTP) A 64-bit timestamp (in Network Time Protocol [15](NTP)
format) (see section 13.1). format) (see section 9.1).
Authenticator Authenticator
(variable length) (See Section 13.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 needs has no valid IPv6 address. The needed even when the client has no IPv6 address of large enough scope
extension can be originated by either the DHCPv6 Client or DHCPv6 to reach the DHCP server. The extension can be originated by either
server to authenticate the rest of the data in the DHCPv6 message. the DHCPv6 Client or DHCPv6 server to authenticate the rest of the
The default authentication algorithm is defined in section 13.2. data in the DHCPv6 message. The default authentication algorithm is
defined in section 9.2.
11.6. Client Key Selection Extension 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
recent Assigned Numbers RFC (e.g., [18]).
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 31 skipping to change at page 25, line 46
Type 85 Type 85
Length 4 Length 4
SPI A Security Parameters index [3] identifying a security SPI A Security Parameters index [3] 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., [8]). recent Assigned Numbers RFC (e.g., [9]).
12. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 65535 | | 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13. 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 11.5. for users of the Client-Server Authentication extension 7.5. See
also the Security Considerations in the companion specification [4].
13.1. Replay Protection 9.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [11](NTP) format, is A 64-bit timestamp, in Network Time Protocol [15](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.
13.2. Default Authentication Algorithm 9.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [10], using The default authentication algorithm is HMAC [12], using
keyed-MD5 [13]. Given a secret key K, and "data" the information to keyed-MD5 [19]. 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 bytes 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.
14. Defining New Extensions 10. Defining New Extensions
Implementation specific use of undefined extensions (including those Implementation specific use of undefined extensions (including those
in the range 86-32767) may conflict with other implementations, and in the range 86-32767) may conflict with other implementations, and
registration is required. registration is required.
The author of a new DHCP option MUST follow these steps to obtain The author of a new DHCP extension MUST follow these steps to obtain
acceptance of the option as a part of the DHCP Internet Standard: acceptance of the extension as a part of the DHCP Internet Standard:
1. The author devises the new option. 1. The author devises the new extension.
2. The author requests a number for the new option from IANA by 2. 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 option, using the newly obtained 3. The author documents the new extension, using the newly obtained
option 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" [9]. The new option will be submitted for eventual Standards" [11]. The new extension will be submitted for
acceptance as an Internet Standard. eventual acceptance as an Internet Standard.
5. The new option progresses through the IETF standards process; the 5. The new extension progresses through the IETF standards
new option will be reviewed by the Dynamic Host Configuration process; the new extension will be reviewed by the Dynamic Host
Working Group (if that group still exists), or as an Internet Configuration Working Group (if that group still exists), or as
Draft not submitted by an IETF working group. an Internet Draft not submitted by an IETF working group.
6. If the new option fails to gain acceptance as an Internet 6. If the new extension fails to gain acceptance as an Internet
Standard, the assigned option number will be returned to IANA for Standard, the assigned extension number will be returned to IANA
reassignment. for reassignment.
This procedure for defining new extensions will ensure that: This procedure for defining new extensions will ensure that:
* allocation of new option numbers is coordinated from a single * allocation of new extension numbers is coordinated from a single
authority, authority,
* new options are reviewed for technical correctness and * new extensions are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new options is complete and published. * documentation for new extensions is complete and published.
15. Acknowledgements 11. 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 Erik Guttman for his by Steve Alexander and Ralph Droms. Thanks to Erik Guttman for his
helpful suggestions for the Service Location extensions. helpful suggestions for the Service Location extensions. Thanks to
Matt Crawford and Erik Nordmark for their careful review as part of
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] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 2132, March 1997. Extensions. RFC 2132, March 1997.
[3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[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-10.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 [5] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997. Levels. RFC 2119, March 1997.
[6] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, [6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications. draft-ietf-dhc-timezone-01.txt, January 1997.
(work in progress).
[7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996. February 1996.
[7] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[8] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic [9] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994. Routing Encapsulation (GRE). RFC 1701, October 1994.
[9] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1, [10] IEEE. 1003.1 POSIX Timezone Specification, 1988.
February 1997.
[10] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing [11] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
July 1997.
[12] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997. for Message Authentication. RFC 2104, February 1997.
[11] David L. Mills. Network Time Protocol (Version 3): [13] Sun Microsystems. System and Network Administration, March
1992.
[14] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI. RFC 2030, October 1996.
[15] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[12] P. Mockapetris. Domain Names - Concepts and Facilities. STD [16] P. Mockapetris. Domain Names - Concepts and Facilities. STD
13, November 1987. 13, November 1987.
[13] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [17] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2,
October 1994.
[18] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994.
[19] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[14] S. Thomson and T. Narten. IPv6 stateless address [20] S. Thomson and T. Narten. IPv6 stateless address
autoconfiguration. RFC 1971, August 1996. autoconfiguration. RFC 1971, August 1996.
[15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol, April 1997. draft-ietf-svrloc-protocol-17.txt Location Protocol. RFC 2165, July 1997.
(work in progress).
[16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [22] 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
Lewisburg, PA 17837 Lewisburg, PA 17837
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 Perkins Charles E. Perkins
Mail Stop UPAL01-550 Technology Development Group
Netcentricity Group Mail Stop MPK15-214
Room 2682
Sun Microsystems, Inc. Sun Microsystems, Inc.
2550 Garcia Avenue 901 San Antonio Road
Mountain View, CA 94043 Palo Alto, California 94303
USA
Work: +1-415-336-7153 Phone: +1-415-786-6464
Fax: +1-415-336-0673 Fax: +1-415-786-6445
E-mail: cperkins@corp.sun.com email: charles.perkins@Sun.COM
 End of changes. 

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