draft-ietf-dhc-v6exts-08.txt   draft-ietf-dhc-v6exts-09.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems INTERNET DRAFT Sun Microsystems
30 October 1997 13 March 1998
Extensions for the Dynamic Host Configuration Protocol for IPv6 Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-v6exts-08.txt draft-ietf-dhc-v6exts-09.txt
Status of This Memo Status of This Memo
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Working Group of the Internet Engineering Task Force (IETF).
Comments should be submitted to the dhcp-v6@bucknell.edu mailing Comments should be submitted to the dhcp-v6@bucknell.edu mailing
list. list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
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
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check To view the entire list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 [3] (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. The method for specifying new extensions is also valid extensions. The method for specifying new extensions is also
included in this document. included in this document.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. DHCPv6 Extension Field Format 2 2. DHCPv6 Extension Field Format 2
2.1. Character Encoding and String Issues . . . . . . . . . . 2 2.1. Character Encoding and String Issues . . . . . . . . . . 2
2.2. Typed Scope Lists . . . . . . . . . . . . . . . . . . . . 3
3. IP Address Extension 3 3. IP Address Extension 4
3.1. Client Considerations for the IP Address extension . . . 6 3.1. Client Considerations for the IP Address extension . . . 7
3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6 3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 7
3.1.2. Use with the DHCP Request message . . . . . . . . 7 3.1.2. Use with the DHCP Request message . . . . . . . . 8
3.1.3. Receiving as part of the DHCP Reply message . . . 8 3.1.3. Receiving as part of the DHCP Reply message . . . 9
3.1.4. Use with the DHCP Release message . . . . . . . . 8 3.1.4. Use with the DHCP Release message . . . . . . . . 10
3.2. Server Considerations for the IP Address extension . . . 9 3.2. Server Considerations for the IP Address extension . . . 10
3.2.1. Use with the DHCP Advertise message . . . . . . . 9 3.2.1. Use with the DHCP Advertise message . . . . . . . 10
3.2.2. Receiving a DHCP Request with the IP Address 3.2.2. Receiving a DHCP Request with the IP Address
Extension . . . . . . . . . . . . . . . . 9 Extension . . . . . . . . . . . . . . . . 10
3.2.3. Use with the DHCP Reply message . . . . . . . . . 10 3.2.3. Use with the DHCP Reply message . . . . . . . . . 11
3.2.4. Use with the DHCP Reconfigure message . . . . . . 11 3.2.4. Use with the DHCP Reconfigure message . . . . . . 12
3.2.5. Receiving a DHCP Release with the IP Address 3.2.5. Receiving a DHCP Release with the IP Address
Extension . . . . . . . . . . . . . . . . 11 Extension . . . . . . . . . . . . . . . . 12
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11 3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 12
4. General Extensions 11 4. General Extensions 12
4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 11 4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 13
4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 12 4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 13
4.2.2. An Example . . . . . . . . . . . . . . . . . . . 13 4.2.2. An Example . . . . . . . . . . . . . . . . . . . 15
4.2.3. Timezone 0ption Precedence . . . . . . . . . . . 14 4.2.3. Timezone Extension Precedence . . . . . . . . . . 15
4.3. Domain Name Server Extension . . . . . . . . . . . . . . 14 4.3. Domain Name Server Extension . . . . . . . . . . . . . . 15
4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 16
5. Application and Service Parameters 15 5. Application and Service Parameters 16
5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 15 5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 16
5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 17 5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 18
5.3. Network Time Protocol Servers Extension . . . . . . . . . 17 5.3. Network Time Protocol Servers Extension . . . . . . . . . 19
5.4. Network Information Service Domain Extension . . . . . . 18 5.4. Network Information Service Domain Extension . . . . . . 19
5.5. Network Information Servers Extension . . . . . . . . . . 18 5.5. Network Information Servers Extension . . . . . . . . . . 20
5.6. Network Information Service+ Domain Extension . . . . . . 18 5.6. Network Information Service+ Domain Extension . . . . . . 20
5.7. Network Information Service+ Servers Extension . . . . . 19 5.7. Network Information Service+ Servers Extension . . . . . 20
5.8. Vendor Specific Information . . . . . . . . . . . . . . . 19 6. TCP Parameters 21
6. TCP Parameters 20 6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 20
7. DHCPv6 Extensions 21 7. DHCPv6 Extensions 21
7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 21 7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 21
7.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 21 7.2. Platform Specific Information . . . . . . . . . . . . . . 22
7.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 22 7.3. Platform Class Identifier . . . . . . . . . . . . . . . . 23
7.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 22 7.4. Class Identifier . . . . . . . . . . . . . . . . . . . . 24
7.5. Client-Server Authentication Extension . . . . . . . . . 23 7.5. Reconfigure Multicast Address . . . . . . . . . . . . . . 25
7.6. Client Key Selection Extension . . . . . . . . . . . . . 24 7.6. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 25
7.7. DHCP Relay ICMP Error Message Format . . . . . . . . . . 25
7.7.1. ICMP Extension Client Considerations . . . . . . 26
7.7.2. ICMP Extension Relay Considerations . . . . . . . 26
7.8. Client-Server Authentication Extension . . . . . . . . . 26
7.9. Client Key Selection Extension . . . . . . . . . . . . . 27
8. End extension specification 25 8. End extension specification 28
9. Security Considerations 25 9. Security Considerations 28
9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 25 9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
9.2. Default Authentication Algorithm . . . . . . . . . . . . 25 9.2. Default Authentication Algorithm . . . . . . . . . . . . 29
10. Defining New Extensions 26 10. Defining New Extensions 29
11. Acknowledgements 28 11. Acknowledgements 31
Chair's Address 30 Chair's Address 33
Author's Address 30 Author's Address 33
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 [3]. 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 [4]. 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.
skipping to change at page 1, line 159 skipping to change at page 1, line 167
- 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 [20], and not will be satisfied by the Service Location Protocol [24], and not
DHCPv6. DHCP is expected to be used for the kinds of configuration DHCPv6. DHCP is expected to be used for the kinds of configuration
that enable clients to become fully functional as self-contained that enable clients to become fully functional as self-contained
network entities, but not the kinds of configuration that might be network entities, but not the kinds of configuration that might be
required by applications running above the network or transport layer required by applications running above the network or transport layer
protocol levels. protocol levels.
2. DHCPv6 Extension Field Format 2. DHCPv6 Extension Field Format
Extensions may be fixed length or variable length. All extensions Extensions may be fixed length or variable length. All extensions
begin with a type field, which is two octets long and uniquely begin with a type field, which is two octets long and uniquely
skipping to change at page 3, line 17 skipping to change at page 3, line 17
way to mix US-ASCII and UNICODE, for example. All responses MUST be way to mix US-ASCII and UNICODE, for example. All responses MUST be
in the character set of the request or use US-ASCII. If a request is 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 status code of 24in a DHCP Reply message in this server returns a status code of 24in a DHCP Reply message in this
case. Requests using US-ASCII (MIBEnum value == 3) will never fail case. Requests using US-ASCII (MIBEnum value == 3) will never fail
for this reason, since all DHCP entities MUST be able to accept this for this reason, since all DHCP entities MUST be able to accept this
character set. All DNS-related strings are presumed to be encoded in character set. All DNS-related strings are presumed to be encoded in
US-ASCII. US-ASCII.
2.2. Typed Scope Lists
In Service Location Protocol, multiple service types can be hosted on
the same network node. However, DHCP typically configures computers
based on their IP address. It is possible that different service
types on the same computer would be administered from different
scopes. Thus, extensions 16 and 17 have additional syntax to allow
this more detailed style of service configuration.
In particular, the list of scopes contained in the extensions is
syntactically separated into lists pertaining to each service type.
Grammatically, a typed-scope-list in a DHCPOFFER is structured as
follows:
typed-scope-list = one or more maybe-typed-scope-items,
separated by commas
maybe-typed-scope-item = typed-scope-item, or scope-list
typed-scope-item = '(' service-type '=' scope-list ')'
scope-list = one or more scope-items, comma-separated
A typed-scope-list in a DHCPREQUEST is structured as follows:
typed-scope-list = one or more maybe-typed-scope-items,
separated by commas
maybe-typed-scope-item = typed-scope-item, or
maybe-empty-scope-list
typed-scope-item = '(' service-type '=' maybe-empty-scope-list ')'
maybe-empty-scope-list = zero or more scope-items, comma-separated
A service type has the format defined in [10], and a scope-item has
the format defined in [11] for "strval". Basically, a scope-item is
a character string that has alphanumeric characters not including
control characters or `(',`)',`,', \',`!',`<',`=',`>', or `~' Service
schemes are special cases of schemes as defined for general URLs [3].
The typed-scope-list MAY contain both untyped-scope-lists and
typed-scope-lists. Each scope-item in each untyped-scope-list
applies to every service type on the node.
As an example, the scope-list ``A,B,C'' denotes scopes A, B and C
for all service types on the client. In a DHCPREQUEST, this scope
string would indicate that the client wishes a directory agent which
supports ANY of these three scopes. In a DHCPOFFER, the scope
indicates that the directory agent supports ALL of the three scopes.
Suppose instead that service types "netman" and "proxystuff" are
residing on a DHCP client. Then, the typed-scope-list in a DHCPOFFER
could be,
(netman=mgmt),(proxystuff=math-dept,labs)
Assuming the DHCP client with two service types "netman" and
"proxystuff" did not make any scope restriction, a corresponding
typed-scope-list in a DHCPREQUEST could be,
(netman=),(proxystuff=)
asking for scopes for those service types.
3. IP Address Extension 3. IP Address Extension
The IP Address extension is the most essential of all the DHCPv6 The IP Address extension is the most essential of all the DHCPv6
extensions. It can be used by both client and server in various extensions. It can be used by both client and server in various
ways. Since the IP Address extension can be used more than once in ways. Since the IP Address extension can be used more than once in
the same DHCP message, all information relevant to a particular IPv6 the same DHCP message, all information relevant to a particular IPv6
allocation has to be collected together in the same extension. Some allocation has to be collected together in the same extension. Some
of the fields within the IP Address extension can specify how DNS may of the fields within the IP Address extension can specify how DNS may
be updated [21]. be updated [25].
To ask for an IP address in a DHCP Request message, a client includes To ask for an IP address in a DHCP Request message, a client includes
an IP Address Extension. To renew or extend the lifetime of a an IP Address Extension. To renew or extend the lifetime of a
particular IP address, the client puts that address in the client particular IP address, the client puts that address in the client
address field. To request the allocation of a new but unspecified IP address field. To request the allocation of a new but unspecified IP
address, the client omits the client address field. The IP address address, the client omits the client address field. The IP address
returned by the server in the latter case will be compatible with a returned by the server in the latter case will be compatible with a
subnet prefix of the link to which the client is currently attached. routing prefix of the link to which the client is currently attached.
An IP Address Extension can contain at most one IP address. To An IP Address Extension can contain at most one IP address. To
specify more than one IP address, multiple extensions are used. specify more than one IP address, multiple extensions are used.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status |C|L|Q|A|P| reserved | pfx-size | | status |C|L|Q|A|P| reserved | pfx-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 36 skipping to change at page 7, line 4
(YXDOMAIN) (YXDOMAIN)
39 Some RRset that ought not to exist, does exist 39 Some RRset that ought not to exist, does exist
(YXRRSET) (YXRRSET)
40 Some RRset that ought to exist, does not exist 40 Some RRset that ought to exist, does not exist
(NXRRSET) (NXRRSET)
41 The server is not authoritative for the zone named in 41 The server is not authoritative for the zone named in
the Zone Section (NOTAUTH) the Zone Section (NOTAUTH)
42 A name used in the Prerequisite or Update Section 42 A name used in the Prerequisite or Update Section
is not within the zone denoted by the Zone Section is not within the zone denoted by the Zone Section
(NOTZONE) (NOTZONE)
Status values 33through 42are described more fully within RFC Status values 33through 42are described more fully within RFC
2136 [21]. Up-to-date values for the values of the status field are 2136 [25]. Up-to-date values for the values of the status field are
specified in the most recent "Assigned Numbers" [16]. To inform the specified in the most recent "Assigned Numbers" [20]. To inform the
client of the DYNDNS [21] error return codes (i.e., nonzero return client of the DYNDNS [25] error return codes (i.e., nonzero return
codes) received by the DHCPv6 server the client MUST assume the codes) received by the DHCPv6 server the client MUST assume the
status codes 32 through 42 are formed as follows: status codes 32 through 42 are formed as follows:
status code = 32 + DYNDNS Error Code status code = 32 + DYNDNS Error Code
The DNS name can be a host name, which does not contain the '.' The DNS name can be a host name, which does not contain the '.'
ASCII character as a separator between DNS hierarchy components. Any ASCII character as a separator between DNS hierarchy components. Any
name containing the '.' is treated as a Fully Qualified Domain Name name containing the '.' is treated as a Fully Qualified Domain Name
(FQDN). The length of the DNS name may be determined by subtracting, (FQDN). The length of the DNS name may be determined by subtracting,
from the Length, the length of those fixed length fields which are from the Length, the length of those fixed length fields which are
present. If the last octet of the DNS name is not zero, the IP present.
Address Extension MUST be rejected, with status 23.
If the 'Q' bit is set, the values or actions requested by the C, L, If the 'Q' bit is set, the values or actions requested by the C, L,
A, and P bits are required, and MUST be provided, or the extension A, and P bits are required, and MUST be provided, or the extension
MUST be rejected with status code 22. MUST be rejected with status code 22.
If the 'Q' bit is set, and if the 'A' bit is set, the server MUST If the 'Q' bit is set, and if the 'A' bit is set, the server MUST
ensure that the DNS is updated with a new AAAA record, as specified ensure that the DNS is updated with a new AAAA record, as specified
by the client's FQDN, before responding with the corresponding DHCP by the client's FQDN, before responding with the corresponding DHCP
Reply. Likewise, if the 'Q' bit is set, and if the 'P' bit is Reply. Likewise, if the 'Q' bit is set, and if the 'P' bit is
set, the server MUST ensure that the DNS is updated with a new PTR set, the server MUST ensure that the DNS is updated with a new PTR
record, as specified by the client's FQDN, before responding with the record, as specified by the client's FQDN, before responding with the
corresponding DHCP Reply. corresponding DHCP Reply.
A DHCP client can include an IP address in its IP Address extension A DHCP client can include an IP address in its IP Address extension
and set the 'A' bit and/or 'P' bit to ask the DHCP Server to use that and set the 'A' bit and/or 'P' bit to ask the DHCP Server to use that
address for updating DNS. This can be done even with IP addresses address for updating DNS. This can be done even with IP addresses
obtained by Stateless Address Autoconfiguration [19]. If the client obtained by Stateless Address Autoconfiguration [23]. If the client
wishes to have its FQDN associated with one of several existing IP wishes to have its FQDN associated with one of several existing IP
addresses which it has received from the DHCP Server, the client MUST addresses which it has received from the DHCP Server, the client MUST
supply that IP address in the IP address extension along with the supply that IP address in the IP address extension along with the
FQDN. FQDN.
3.1. Client Considerations for the IP Address extension 3.1. Client Considerations for the IP Address extension
3.1.1. Address Lifetimes 3.1.1. Address Lifetimes
An IP address returned to a client has a preferred and valid An IP address returned to a client has a preferred and valid
skipping to change at page 6, line 45 skipping to change at page 8, line 12
to expire, or request a new address or the same address before the to expire, or request a new address or the same address before the
lease actually expires. If the client does not make a new Request lease actually expires. If the client does not make a new Request
for an address, the server SHOULD assume the client does not want for an address, the server SHOULD assume the client does not want
that address. The server MAY provide that address to another client that address. The server MAY provide that address to another client
requesting an address. requesting an address.
The client MAY request values for the lifetimes, but the client MUST The client MAY request values for the lifetimes, but the client MUST
use the lifetimes provided by the server response. use the lifetimes provided by the server response.
When the preferred lifetime of an IP address expires, the client's When the preferred lifetime of an IP address expires, the client's
address becomes a deprecated address. See [7] for required handling address becomes a deprecated address. See [9] for required handling
of deprecated IP addresses. Before an address for a DHCPv6 client's of deprecated IP addresses. Before an address for a DHCPv6 client's
interface becomes deprecated, the client SHOULD request a new address interface becomes deprecated, the client SHOULD request a new address
for that interface, or make a new DHCP Request for the existing for that interface, or make a new DHCP Request for the existing
address (which can result in the address receiving an updated address (which can result in the address receiving an updated
preferred lifetime). preferred lifetime).
When the client requests an IP address from the DHCPv6 server, the When the client requests an IP address from the DHCPv6 server, the
client MUST keep track of when the request was issued. When the client MUST keep track of when the request was issued. When the
client receives a successful reply from the DHCPv6 server, it MUST client receives a successful reply from the DHCPv6 server, it MUST
decrement the received Lifetimes by the amount of time between the decrement the received Lifetimes by the amount of time between
transmission of the DHCP Request and the reception of the DHCP Reply. the transmission of the DHCP Request and the reception of the
In this way, the client is best assured that its address lifetimes corresponding DHCP Reply. In this way, the client is best assured
will not expire at the DHCP Server before they expire at the client. that its address lifetimes 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 MUST set the In a DHCP Request (for each address extension), a client MUST set the
status code to zero. status code to zero.
In a DHCP Request (for each address extension), a client MAY: In a DHCP Request (for each address extension), a client MAY:
- include an IP address and/or a DNS name (which may be a host name - include an IP address and/or a DNS name (which may be a host name
or a FQDN). or a FQDN).
skipping to change at page 8, line 18 skipping to change at page 9, line 35
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.
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 [3]), it first inspects the status to see Reply which it accepts (see [4]), it first inspects the status to see
whether the requested information has been granted. If the status is whether the requested information has been granted. If the status is
nonzero, the client should log the error, display the error condition nonzero, the client should log the error, display the error condition
for action by the user and/or the network administrator. Nonzero for action by the user and/or the network administrator. Nonzero
status almost always indicates that the client will be need to modify status almost always indicates that the client will be need to modify
its request before it could be satisfied by the replying DHCP server, its request before it could be satisfied by the replying DHCP server,
or alternatively that the replying DHCP server will need to be given or alternatively that the replying DHCP server will need to be given
updated configuration information for the client. updated configuration information for the client.
Upon reception of a new IP address with a lifetime, the client MUST Upon reception of a new IP address with a lifetime, the client MUST
perform Duplicate Address Detection (DAD) [19]; however, if the perform Duplicate Address Detection (DAD) [23]; however, if the
address has already been allocated to the client and it is merely address has already been allocated to the client and it is merely
renewing the lifetime of the address, the client does not have to renewing the lifetime of the address, the client does not have to
perform DAD each time. If the client receives an IP address with perform DAD each time. If the client receives an IP address with
zero valid lifetime, the client MUST immediately discontinue using zero valid lifetime, the client MUST immediately discontinue using
that IP address. that IP address.
3.1.4. Use with the DHCP Release message 3.1.4. Use with the DHCP Release message
In DHCP Release (for each address extension): In DHCP Release (for each address extension):
skipping to change at page 9, line 5 skipping to change at page 10, line 22
- the server MUST update DNS to delete the AAAA record or records - the server MUST update DNS to delete the AAAA record or records
that the server originally used when updating DNS when the that the server originally used when updating DNS when the
address was allocated to the client, and likewise for the PTR address was allocated to the client, and likewise for the PTR
record (regardless of the setting of the 'A' or 'P' bits in the record (regardless of the setting of the 'A' or 'P' bits in the
address extension). address extension).
- If the client, on the other hand, took charge of the DNS updates, - If the client, on the other hand, took charge of the DNS updates,
it MUST perform the corresponding deletions before issuing the it MUST perform the corresponding deletions before issuing the
DHCP Release. DHCP Release.
The client SHOULD provide a specific IP address in the extension. If The client MUST provide a specific IP address in the extension.
only the DNS name is provided, all client AAAA records for that name
will be deleted.
3.2. Server Considerations for the IP Address extension 3.2. Server Considerations for the IP Address extension
3.2.1. Use with the DHCP Advertise message 3.2.1. Use with the DHCP Advertise message
In DHCP Advertise (for each address extension), the Server can In DHCP Advertise (for each address extension), the Server can
indicate: indicate:
- the client's FQDN or host name - the client's FQDN or host name
skipping to change at page 9, line 34 skipping to change at page 10, line 49
If the server sets the 'A' bit, it is willing to perform DNS updates If the server sets the 'A' bit, it is willing to perform DNS updates
to AAAA records on behalf of the client. Likewise, if the server to AAAA records on behalf of the client. Likewise, if the server
sets the 'P' bit, it is willing to perform DNS updates to PTR records sets the 'P' bit, it is willing to perform DNS updates to PTR records
on behalf of the client. on behalf of the client.
3.2.2. Receiving a DHCP Request with the IP Address Extension 3.2.2. Receiving a DHCP Request with the IP Address Extension
When a server receives a request for an IP address, it consults its When a server receives a request for an IP address, it consults its
allocation tables and determines an IP address appropriate for the allocation tables and determines an IP address appropriate for the
requesting client and the link to which the client is attached. The requesting client and the link to which the client is attached.
link can be determined by the Agent address in the DHCP Request The link can be determined by the Agent address prefix in the DHCP
message header, or, when there is no relay, by the link of the Request message header, or, when there is no relay, by the link of
interface on which the request was received. This is true in the the interface on which the request was received. This is true in the
latter case because the client and the server have to be on the same latter case because the client and the server have to be on the same
link when there is no Agent address included in the message header. link when there is no server address included in the message header.
If the client has requested that the server perform DNS updates as If the client has requested that the server perform DNS updates as
part of the IP address allocation and configuration, the server part of the IP address allocation and configuration, the server
MUST maintain this fact as part of the client's binding. Then, if MUST maintain this fact as part of the client's binding. Then, if
the client eventually releases the IP address (see the DHCP Releas the client eventually releases the IP address (see the DHCP Releas
message in [3]), the server MUST perform the reverse service by message in [4]), the server MUST perform the reverse service by
updating DNS again as needed. updating DNS again as needed.
3.2.3. Use with the DHCP Reply message 3.2.3. Use with the DHCP Reply message
In a DHCP Reply message (for each address extension) the server MUST In a DHCP Reply message (for each address extension) the server MUST
indicate in the IP address extension indicate in the IP address extension
- the preferred lifetime - the preferred lifetime
- the valid lifetime - the valid lifetime
skipping to change at page 10, line 24 skipping to change at page 11, line 34
- 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) - (by setting the 'A' bit) whether AAAA has been updated by the DNS
- whether PTR has been DNS updated (by setting the 'P' bit) - (by setting the 'P' bit) whether PTR has been updated by the DNS
If the client requests updates, and sets the 'Q' bit, the server MUST If the client requests updates, and sets the 'Q' bit, the server MUST
NOT issue the DHCP Reply until after receiving positive indication NOT issue the DHCP Reply until after receiving positive indication
that the DNS update has indeed been performed. If the 'Q' bit has that the DNS update has indeed been performed. If the 'Q' bit has
been set, and the server cannot honor the IP address extension, it been set, and the server cannot honor the IP address extension, it
MUST return a DHCP reply with the status 22. MUST return a DHCP reply with the status 22.
Otherwise, the client can subsequently update DNS if needed (i.e., Otherwise, the client can subsequently update DNS if needed (i.e.,
the server didn't do it). the server didn't do it).
skipping to change at page 12, line 9 skipping to change at page 13, line 29
4.2. IEEE 1003.1 POSIX Timezone extension 4.2. IEEE 1003.1 POSIX Timezone extension
DHCP includes an extension for the specification of the Universal DHCP includes an extension for the specification of the Universal
Coordinated Time Offset (type 2, defined in section 4.1), which is Coordinated Time Offset (type 2, defined in section 4.1), which is
defined as a two's complement 32-bit integer representing the offset defined as a two's complement 32-bit integer representing the offset
in seconds from UTC. Unfortunately, the UTC offset extension does not in seconds from UTC. Unfortunately, the UTC offset extension does not
provide enough information for an Internet client to determine such provide enough information for an Internet client to determine such
timezone-related details as the timezone names, daylight savings time timezone-related details as the timezone names, daylight savings time
start and end times in addition to the timezone UTC offsets. This start and end times in addition to the timezone UTC offsets. This
extension (analogous to that proposed for DHCPv4 [5]) allows delivery extension (analogous to that proposed for DHCPv4 [6]) allows delivery
of timezone information in the form of a IEEE 1003.1 POSIX Timezone of timezone information in the form of a IEEE 1003.1 POSIX Timezone
specifier [9]. specifier [13].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE 1003.1 POSIX Timezone string (variable length) ... | IEEE 1003.1 POSIX Timezone string (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The extension type is 3. This IEEE 1003.1 POSIX Timezone is detailed The extension type is 3. This IEEE 1003.1 POSIX Timezone is detailed
skipping to change at page 14, line 5 skipping to change at page 15, line 24
fourth or the fifth week. Week '1' is the first week in fourth or the fifth week. Week '1' is the first week in
which the 'd' day occurs. which the 'd' day occurs.
4.2.2. An Example 4.2.2. An Example
For Eastern USA time zone, 1986, the Posix timezone string is as For Eastern USA time zone, 1986, the Posix timezone string is as
follows: follows:
EST5EDT4,116/02:00:00,298/02:00:00 EST5EDT4,116/02:00:00,298/02:00:00
4.2.3. Timezone 0ption Precedence 4.2.3. Timezone Extension Precedence
If a DHCP client receives both the Time Offset (type 2) and the POSIX 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 Timezone (type 3) extension in a DHCP reply message, the client MUST
discard the value of the Time Offset (type 2) extension and utilize discard the value of the Time Offset (type 2) extension and utilize
the POSIX Timezone Option. The DHCP client MAY notify the user that the POSIX Timezone Extension. The DHCP client MAY notify the user
it is resolving the conflict by discarding the Time Offset (type 2) that it is resolving the conflict by discarding the Time Offset (type
extension. 2) extension.
If a DHCP client finds that the POSIX Timezone extension value is If a DHCP client finds that the POSIX Timezone extension value is
misformatted, it SHOULD notify the the user of the problem and MUST misformatted, it SHOULD notify the the user of the problem and MUST
discard the entire extension value. discard the entire extension value.
4.3. Domain Name Server Extension 4.3. Domain Name Server Extension
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | 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 [15] name servers available to the client. Servers SHOULD be System [19] name servers available to the client. Servers SHOULD be
listed in order of preference. listed in order of preference.
The Type for the domain name server extension is 6. The minimum The Type for the domain name server extension is 6. The minimum
Length for this extension is 16 octets, and the Length MUST always be Length for this extension is 16 octets, and the Length MUST always be
a multiple of 16. a multiple of 16.
4.4. Domain Name 4.4. Domain Name
This extension specifies the default domain name that client should This extension specifies the default domain name that client should
use when resolving hostnames via the Domain Name System. use when resolving hostnames via the Domain Name System.
skipping to change at page 15, line 19 skipping to change at page 16, line 38
take the part of the FQDN after the first '.' octet as the Domain take the part of the FQDN after the first '.' octet as the Domain
Name. Name.
5. Application and Service Parameters 5. Application and Service Parameters
This section details some miscellaneous extensions used to configure This section details some miscellaneous extensions used to configure
miscellaneous applications and services. miscellaneous applications and services.
5.1. Directory Agent Extension 5.1. Directory Agent Extension
Entities using the Service Location Protocol [20] need to find out Entities using the Service Location Protocol [24] need to find out
the address of Directory Agents in order to transact messages. They the address of Directory Agents in order to transact messages. They
may need to discover the correct scope to be used in conjunction with may need to discover the correct scope to be used in conjunction with
the service attributes which are exchanged using the Service Location the service attributes which are exchanged using the Service Location
Protocol. The scope MAY be denoted in any standardized character Protocol. The scope MAY be denoted in any standardized character
set. set.
This extension requests or specifies a Directory Agent (DA), along This extension requests or specifies a Directory Agent (DA), along
with zero or more scopes supported by that DA. Note that this with zero or more scopes supported by that DA. Note that this
extension MAY be included multiple times in the same DHCP Request or extension MAY be included multiple times in the same DHCP Request or
DHCP Reply. If so, then the extensions SHOULD be included in order DHCP Reply. If so, then the extensions SHOULD be included in order
of decreasing preference. 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 | |D|F|M|S| reserved | DA length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Directory Agent (variable length) ... | Directory Agent (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) Service Scope (variable length) ... | (if present) Typed-Scope-List (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16 Type 16
Length (unsigned integer, variable) The length of the Extension Length (unsigned integer, variable) The length of the Extension
in octets. in octets.
Char Encoding D If the 'D' bit is set, the Directory Agent field and the
The standardized encoding for the characters denoting the DA Length fields are present.
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 F If the 'F' bit is set, the Directory Agent is indicated
present. by including its variable length host name or Fully
Qualified Domain Name (FQDN) instead of its IP address.
M If the 'M' bit is set, the Directory Agent address 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 S If the 'S' bit is set, the scope is present.
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
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, The Fully Qualified Domain Name (FQDN), host name, or IP
or IP address of the Directory Agent (see following address of the Directory Agent.
description).
Service Scope Typed Scope List
The characters denoting the scope. The length of the The characters denoting the scope (see Section reftsl).
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 16. Length MUST be 16.
Note that more than one Directory Agent extension may be present in Note that more than one Directory Agent extension may be present in
a DHCP message. Each such extension may have the same or different a DHCP message. Each such extension may have the same or different
scope. The client may request any Directory Agent with a particular scope.
scope, by including the Directory Agent extension in a DHCP Request
message with no Directory Agent address included (the 'D' bit set to The client may request any Directory Agent with a particular scope,
zero), and the characters denoting the scope. by including the Directory Agent extension in a DHCP Request message
with no Directory Agent address included (the 'D' bit set to zero),
and the characters denoting the scope.
The length of the Typed Scope List is only indicated implicitly
by the overall length of the extension. This string is NOT null
terminated.
The format of the Typed Scope List field is described in section 2.2.
Extension 16 MUST include one or more scopes if a DA address is
returned. Using extension 16, it is not possible for different
service types on the same node to be configured with different
directory agents. In other words, all service types on the same node
will be configured with the same directory agent.
5.2. Service Scope Extension 5.2. Service Scope Extension
This extension indicates a scope that should be used by a Service This extension indicates a scope that should be used by a Service
Agent (SA) [20], when responding to Service Request messages as Agent (SA) [24], when responding to Service Request messages as
specified by the Service Location Protocol. This extension MAY be specified by the Service Location Protocol. This extension MAY be
included multiple times in the same DHCP Request or DHCP Reply. included multiple times in the same DHCP Request or DHCP Reply.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Service Scope ... | Typed-Scope-List ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 17 Type 17
Length (unsigned integer, variable) The length of the Extension Length (unsigned integer, variable) The length of the Extension
in octets. in octets.
Char Encoding Typed-Scope-List
The standardized encoding for the characters denoting the see Section 2.2.
scope.
Service Scope The Typed-Scope-List is described in Section 2.2. The DHCP
the characters denoting the scope. client (i.e., user agent or service agent) which receives this
extension will use the indicated scope for in all SLP requests and
registrations. The scope string must be UTF8 character encoded.
This string is not null terminated.
Note that more than one Service Scope extension may be present in a DHCP clients MAY use extension 79 to request scopes for one or more
DHCP message. The length of the scope is only indicated implicitly particular service types. Note that more than one Service Scope
by the overall length of the extension. extension may be present in a DHCP message. The length of the scope
is only indicated implicitly by the overall length of the extension.
5.3. Network Time Protocol Servers Extension 5.3. Network Time Protocol Servers Extension
This extension specifies a list of IP addresses indicating NTP [13] This extension specifies a list of IP addresses indicating NTP [17]
servers available to the client. Servers SHOULD be listed in order servers available to the client. Servers SHOULD be listed in order
of preference. of preference.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP server addresses | | NTP server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for this extension is 18. Its minimum Length is 16, and the The type for this extension is 18. Its minimum Length is 16, and the
Length MUST be a multiple of 16. Length MUST be a multiple of 16.
5.4. Network Information Service Domain Extension 5.4. Network Information Service Domain Extension
This extension specifies the name of the client's NIS [12] domain. This extension specifies the name of the client's NIS [16] domain.
The domain is formatted as a character string consisting of The domain is formatted as a character string consisting of
characters from the US-ASCII character set. characters from the US-ASCII character set.
The type for this extension is 19. Its minimum Length is 1. The type for this extension is 19. Its minimum Length is 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS Domain Name (variable length) ... | NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.5. Network Information Servers Extension 5.5. Network Information Servers Extension
This extension specifies a list of IP addresses indicating NIS [12] This extension specifies a list of IP addresses indicating NIS [16]
servers available to the client. Servers SHOULD be listed in order servers available to the client. Servers SHOULD be listed in order
of preference. of preference.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS server addresses | | NIS server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for this extension is 20. Its minimum Length is 16, and the The type for this extension is 20. Its minimum Length is 16, and the
Length MUST be a multiple of 16. Length MUST be a multiple of 16.
5.6. Network Information Service+ Domain Extension 5.6. Network Information Service+ Domain Extension
This extension specifies the name of the client's NIS+ [12] This extension specifies the name of the client's NIS+ [16]
domain. The domain is formatted as a character string consisting of domain. The domain is formatted as a character string consisting of
characters from the US-ASCII character set. characters from the US-ASCII character set.
The type for this extension is 21. Its minimum Length is 1. The type for this extension is 21. Its minimum Length is 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ Client Domain Name (variable length) ... | NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7. Network Information Service+ Servers Extension 5.7. Network Information Service+ Servers Extension
This extension specifies a list of IP addresses indicating NIS+ [12] This extension specifies a list of IP addresses indicating NIS+ [16]
servers available to the client. Servers SHOULD be listed in order servers available to the client. Servers SHOULD be listed in order
of preference. of preference.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses | | NIS+ server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for this extension is 22. Its minimum Length is 16, and the The code for this extension is 22. Its minimum Length is 16, and the
Length MUST be a multiple of 16. Length MUST be a multiple of 16.
5.8. Vendor Specific Information
This extension is used by clients and servers to exchange vendor-
specific information. The information is an opaque collection of
data, presumably interpreted by vendor-specific code on the clients
and servers. The definition of this information is vendor specific.
The vendor is indicated in the class-identifier extension. Servers
not equipped to interpret the vendor-specific information sent by a
client MUST ignore it (although it may be reported). Clients which
do not receive desired vendor-specific information SHOULD make an
attempt to operate without it, although they may do so (and announce
they are doing so) in a degraded mode.
If a vendor encodes more than one item of information in this
extension, then the vendor MUST encode the extension using
"Encapsulated vendor-specific extensions" as described below:
The Encapsulated vendor-specific extensions field MUST be encoded
as a sequence of type/length/value fields of identical syntax to
the fields defined in every other DHCPv6 extension. Extension
65535 (END), if present, signifies the end of the encapsulated
vendor extensions, not the end of the vendor extensions field.
If no extension 65535 is present, then the end of the enclosing
vendor-specific information field is taken as the end of the
encapsulated vendor-specific extensions field.
The Type for this extension is 31 and its minimum Length is 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When encapsulated vendor-specific extensions are used, each one has
the same format as just shown. In other words, all vendor-specific
extensions are encoded in Type-Length-Value (TLV) format. More than
one vendor-specific extension can, therefore, be included in the same
DHCP "Vendor Specific Information" extension.
6. TCP Parameters 6. TCP Parameters
This section lists the extensions that affect the operation of the This section lists the extensions that affect the operation of the
TCP layer on a per-interface basis. TCP layer on a per-interface basis.
6.1. TCP Keepalive Interval Extension 6.1. TCP Keepalive Interval Extension
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 15 skipping to change at page 22, line 6
7. DHCPv6 Extensions 7. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6. This section details the extensions that are specific to DHCPv6.
7.1. Maximum DHCPv6 Message Size Extension 7.1. Maximum DHCPv6 Message Size Extension
This extension specifies the maximum size in octets of any DHCPv6 This extension specifies the maximum size in octets of any DHCPv6
message that the sender of the extension is willing to accept. The message that the sender of the extension is willing to accept. The
size is specified as an unsigned 16-bit integer. A client may use size is specified as an unsigned 16-bit integer. A client may use
the maximum DHCPv6 message size extension in DHCP Request messages, the maximum DHCPv6 message size extension in DHCP Request messages,
but SHOULD NOT use the extension in DHCP Solicit messages (see [3]), but MUST NOT use the extension in other DHCP messages (see [4]).
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 40, and its Length is 2. The minimum
permissible value is 1500. permissible value is 1500.
7.2. Class Identifier 7.2. Platform Specific Information
A platform is defined as the combination of hardware and operating
system (OS).
This extension is used by clients and servers to exchange
client-platform-specific information. The information is an opaque
collection of data, presumably interpreted by platform-specific code
on the clients. The definition of this information is platform
specific. Clients identify their platform through the use of the
Platform Class identifier extension (see Section 7.3). Clients which
do not receive platform specific information SHOULD make an attempt
to operate without it, although they may do so (and announce that
they are doing so) in a degraded mode.
If a Platform vendor encodes more than one item of information in
this extension, then the vendor MUST encode the extension using
"Encapsulated platform-specific extensions" as described below.
The Encapsulated platform-specific extensions field MUST be
encoded as a sequence of type/length/value fields of identical
syntax to the form defined for DHCPv6 extensions. Extension
65535 (END), if present, signifies the end of the encapsulated
platform extensions, not the end of the platform extensions field.
If no extension 65535 is present, then the end of the enclosing
platform-specific information field is taken as the end of the
encapsulated platform-specific extensions field.
The Type for this extension is 48 and its minimum Length is 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Platform-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When encapsulated platform-specific extensions are used, each one has
the same format as just shown. In other words, all platform-specific
extensions are encoded in Type-Length-Value (TLV) format. More than
one platform-specific extension can, therefore, be included in the
same DHCP "Platform Specific Information" extension.
DHCP servers which support the configuration of Platform Specific
Information extensions, and which have been configured with
configuration information specific to some number of Platform Class
Identifiers MUST select and return only those platform-specific
extensions which match the Platform Class Identifier provided by the
DHCP client.
7.3. Platform Class Identifier
This extension is used by a DHCP client to identify the hardware type
and operating system platform it is hosted on. The extension value
itself is an opaque value to a DHCP server, and is only used by the
DHCP server to "lookup" Platform Specific Extensions associated with
clients of a certain platform class.
Servers not equipped to interpret the platform class identifier
specified by a client MUST ignore it (although it may be reported).
Otherwise, servers SHOULD respond with the set of extensions
corresponding to the platform class identifier specified by the
client.
Note that unlike the User Class Identifier, the Platform Class
Identifier does not need to be echoed back to the DHCP client because
there can be one and only one Platform Class Identifier for a client.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Platform Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 49. The platform class identifier is
a string of characters in the character set specified by the Char
Encoding field (see section 2.1), of length "Length"-2 octets. The
platform class identifier represents the hardware and Operating
system class of which the client is a member.
In order to prevent collisions in the Platform Class Identifier
namespace, we recommend that platform vendors prefix their Platform
Class Identifiers with their Stock symbol or some other globally
recognized authority. For example, Platform Class Identifiers for
Sun Microsystems Inc platforms would be prefaced by "SUNW", the
NASDAQ stock symbol for Sun.
7.4. 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 22, line 15 skipping to change at page 24, line 46
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 string of characters in the character The Type for this extension is 64. The class identifier is a string
set specified by the Char Encoding field (see section 2.1), of of characters in the character set specified by the Char Encoding
length "Length"-2 octets. The class identifier represents the class field (see section 2.1), of length "Length"-2 octets. The class
identifier of which the client is a member. identifier represents the class identifier of which the client is a
member.
7.3. Reconfigure Multicast Address 7.5. 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.
7.4. Renumber DHCPv6 Server Address 7.6. Renumber DHCPv6 Server Address
A DHCPv6 server can instruct its clients to change their internal A DHCPv6 server can instruct its clients to change their internal
records to reflect the server's newly renumbered IP address, by using records to reflect the server's newly renumbered IP address, by using
the "Renumber DHCPv6 Server Address" extension. This extension may the "Renumber DHCPv6 Server Address" extension. This extension may
be sent with the DHCP Reconfigure message, and thus can be multicast be sent with the DHCP Reconfigure message, and thus can be multicast
to all of the server's clients instead of being unicast to each one to all of the server's clients instead of being unicast to each one
individually. individually.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | 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.
7.5. Client-Server Authentication Extension 7.7. DHCP Relay ICMP Error Message Format
A DHCP Relay ICMP Message extension is used to inform a client of
an ICMP Error message the relay received after forwarding a client
Solicit or Request message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Error Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the DHCP Relay ICMP Message extension is 68, and the
Length is the length of the ICMP error message received by the
relay [8].
7.7.1. ICMP Extension Client Considerations
When a client sends a Solicit or Request message it can be forwarded
by a relay. When the relay forwards messages for a client the
network may return an ICMP error [8] message to the relay. If the
relay can determine the client's link-local address within the
UDP payload of the ICMP returned error message payload, the relay
will send the client a DHCP Relay ICMP Error message as defined in
section 7.7.2.
The client MAY record these messages based on the ICMP type and
reason codes provided in the ICMP Error payload [8], for future use
or for system logging purposes. How the client uses this information
is implementation dependent.
7.7.2. ICMP Extension Relay Considerations
If the relay receives an ICMP error message after forwarding a client
Solicit or Request message, it should look in the payload of the
ICMP message [8], to see if it can determine the clients link-local
address in the server Advertise or Reply message. If it can the
relay should forward a DHCP Relay ICMP Error message received to the
client as specified in section 7.7.1, by using the clients link-local
address from the ICMP error message as the IP source address in the
IP header sent to the client. If the relay cannot determine the
clients link-local address in the ICMP error message the packet MUST
be silently discarded.
7.8. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 49 skipping to change at page 27, line 29
Length (unsigned integer, variable) 4 for the SPI, plus 8 for Length (unsigned integer, variable) 4 for the SPI, plus 8 for
the replay protection, plus the number of octets in the the replay protection, plus the number of octets in the
Authenticator. Authenticator.
SPI A Security Parameters index [2] identifying which SPI A Security Parameters index [2] identifying which
security context among those available between the DHCPv6 security context among those available between the DHCPv6
client and server. client and server.
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [14](NTP) A 64-bit timestamp (in Network Time Protocol [18](NTP)
format) (see section 9.1). format) (see section 9.1).
Authenticator Authenticator
(variable length) (See Section 9.2.) (variable length) (See Section 9.2.)
This authentication extension remedies the inability of IPsec to This authentication extension remedies the inability of IPsec to
provide for non end-to-end authentication, since authentication is provide for non end-to-end authentication, since authentication is
needed even when the client has no IPv6 address of large enough scope needed even when the client has no IPv6 address of large enough scope
to reach the DHCP server. The extension can be originated by either to reach the DHCP server. The extension can be originated by either
the DHCPv6 Client or DHCPv6 server to authenticate the rest of the the DHCPv6 Client or DHCPv6 server to authenticate the rest of the
data in the DHCPv6 message. The default authentication algorithm is data in the DHCPv6 message. The default authentication algorithm is
defined in section 9.2. defined in section 9.2.
Note that SPI values 0 through 255 are reserved and, if used, MUST Note that SPI values 0 through 255 are reserved and, if used, MUST
conform to the security context defined by that value in the most conform to the security context defined by that value in the most
recent Assigned Numbers RFC (e.g., [17]). recent Assigned Numbers RFC (e.g., [21]).
7.6. Client Key Selection Extension 7.9. 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 24, line 46 skipping to change at page 28, line 25
Type 85 Type 85
Length 4 Length 4
SPI A Security Parameters index [2] identifying a security SPI A Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts context between a pair of nodes among the contexts
available in the security association defined between available in the security association defined between
the DHCPv6 client and server. SPI values 0 through 255 the DHCPv6 client and server. SPI values 0 through 255
are reserved and, if used, MUST conform to the security are reserved and, if used, MUST conform to the security
context defined by that value as defined in the most context defined by that value as defined in the most
recent Assigned Numbers RFC (e.g., [8]). recent Assigned Numbers RFC (e.g., [12]).
8. End extension specification 8. End extension specification
The end extension marks the end of valid information in the vendor The end extension marks the end of valid information in the vendor
field. The Type for the end extension is 65535, and its Length is 2 field. The Type for the end extension is 65535, and its Length is 2
octets; there is no Length field for the end extension. octets; there is no Length field for the end extension.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 65535 | | 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Security Considerations 9. Security Considerations
There is an urgent need to define some security protocol for use There is an urgent need to define some security protocol for use
with DHCPv6, since otherwise malicious parties could create numerous with DHCPv6, since otherwise malicious parties could create numerous
denial-of-service style attacks based on depleting available server denial-of-service style attacks based on depleting available server
resources or providing corrupted or infected data to unsuspecting resources or providing corrupted or infected data to unsuspecting
clients. The following sections discuss aspects of security relevant clients. The following sections discuss aspects of security relevant
for users of the Client-Server Authentication extension 7.5. See for users of the Client-Server Authentication extension 7.8. See
also the Security Considerations in the companion specification [3]. also the Security Considerations in the companion specification [4].
9.1. Replay Protection 9.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [14](NTP) format, is A 64-bit timestamp, in Network Time Protocol [18](NTP) format, is
used to protect against replay of previous authenticated messages used to protect against replay of previous authenticated messages
by malicious agents. The NTP timestamp value used in the extension by malicious agents. The NTP timestamp value used in the extension
MUST be chosen, and verified, to be larger than values used by the MUST be chosen, and verified, to be larger than values used by the
originator in previous Client-Server Authentication extensions. originator in previous Client-Server Authentication extensions.
On the other hand, the timestamp value MUST also be chosen (and On the other hand, the timestamp value MUST also be chosen (and
verified) to be no greater than one year more than the last known verified) to be no greater than one year more than the last known
value (if any) used by the originator. value (if any) used by the originator.
9.2. Default Authentication Algorithm 9.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [11], using The default authentication algorithm is HMAC [15], using
keyed-MD5 [18]. Given a secret key K, and "data" the information to keyed-MD5 [22]. Given a secret key K, and "data" the information to
be authenticated, HMAC_result is computed as follows: be authenticated, HMAC_result is computed as follows:
1. opad := 0x36363636363636363636363636363636 (128 bits) 1. opad := 0x36363636363636363636363636363636 (128 bits)
2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
3. zero_extended_key := K extended by zeroes to be 128 bits long 3. zero_extended_key := K extended by zeroes to be 128 bits long
4. opadded_key := zero_extended_key XOR opad 4. opadded_key := zero_extended_key XOR opad
5. ipadded_key := zero_extended_key XOR ipad 5. ipadded_key := zero_extended_key XOR ipad
6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))
The key K is the shared secret defined by the security association The key K is the shared secret defined by the security association
between the client and server and by the SPI value specified in between the client and server and by the SPI value specified in
the Authentication Extension. The "data" is the stream of octets the Authentication Extension. The "data" is the stream of octets
in all previous fields in the DHCPv6 message and extensions. The in all previous fields in the DHCPv6 message and extensions. The
authenticator is the 128-bit value HMAC_result. authenticator is the 128-bit value HMAC_result.
skipping to change at page 26, line 39 skipping to change at page 30, line 19
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, California 90292-6695 Marina del Rey, California 90292-6695
or by email as: iana@isi.edu or by email as: iana@isi.edu
3. The author documents the new extension, using the newly obtained 3. The author documents the new extension, using the newly obtained
extension number, as an Internet Draft. extension number, as an Internet Draft.
4. The author submits the Internet Draft for review through the 4. The author submits the Internet Draft for review through the
IETF standards process as defined in "Internet Official Protocol IETF standards process as defined in "Internet Official Protocol
Standards" [10]. The new extension will be submitted for Standards" [14]. The new extension will be submitted for
eventual acceptance as an Internet Standard. eventual acceptance as an Internet Standard.
5. The new extension progresses through the IETF standards 5. The new extension progresses through the IETF standards
process; the new extension will be reviewed by the Dynamic Host process; the new extension will be reviewed by the Dynamic Host
Configuration Working Group (if that group still exists), or as Configuration Working Group (if that group still exists), or as
an Internet Draft not submitted by an IETF working group. an Internet Draft not submitted by an IETF working group.
6. If the new extension fails to gain acceptance as an Internet 6. If the new extension fails to gain acceptance as an Internet
Standard, the assigned extension number will be returned to IANA Standard, the assigned extension number will be returned to IANA
for reassignment. for reassignment.
skipping to change at page 28, line 11 skipping to change at page 31, line 11
appropriateness, and appropriateness, and
* documentation for new extensions is complete and published. * documentation for new extensions is complete and published.
11. 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 Mike Carney for his
helpful suggestions for the Service Location extensions. Thanks to many helpful comments, as well as contributing the design of the
Matt Crawford and Erik Nordmark for their careful review as part of Platform Specific Information and Platform Class Identifier. Thanks
the Last Call process. to Erik Guttman for his 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. Jim Bound also
provided all the necessary design and text for the DHCP Relay ICMP
Error Message Extension.
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993. Extensions. RFC 1533, October 1993.
[2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol [3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-11.txt, May 1997. (work in for IPv6. draft-ietf-dhc-dhcpv6-11.txt, May 1997. (work in
progress). progress).
[4] 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.
[5] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone [6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications. draft-ietf-dhc-timezone-01.txt, January 1997. Specifications. draft-ietf-dhc-timezone-01.txt, January 1997.
(work in progress). (work in progress).
[6] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, [7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996. February 1996.
[7] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [8] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885,
December 1995.
[9] 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 [10] E. Guttman, C. Perkins, and J. Kempf. Service Templates and
service: Schemes. draft-ietf-svrloc-service-scheme-05.txt,
November 1997. (work in progress).
[11] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txT,
March 1998. (work in progress).
[12] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994. Routing Encapsulation (GRE). RFC 1701, October 1994.
[9] IEEE. 1003.1 POSIX Timezone Specification, 1988. [13] IEEE. 1003.1 POSIX Timezone Specification, 1988.
[10] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1, [14] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
July 1997. July 1997.
[11] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing [15] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997. for Message Authentication. RFC 2104, February 1997.
[12] Sun Microsystems. System and Network Administration, March [16] Sun Microsystems. System and Network Administration, March
1992. 1992.
[13] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for [17] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI. RFC 2030, October 1996. IPv4, IPv6 and OSI. RFC 2030, October 1996.
[14] David L. Mills. Network Time Protocol (Version 3): [18] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[15] P. Mockapetris. Domain Names - Concepts and Facilities. STD [19] P. Mockapetris. Domain Names - Concepts and Facilities. IETF
13, November 1987. STD 13, November 1987.
[16] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2, [20] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2,
October 1994. October 1994.
[17] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, [21] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994. October 1994.
[18] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [22] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[19] S. Thomson and T. Narten. IPv6 stateless address [23] S. Thomson and T. Narten. IPv6 Stateless Address
autoconfiguration. RFC 1971, August 1996. Autoconfiguration. RFC 1971, August 1996.
[20] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [24] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. RFC 2165, July 1997.
[21] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [25] 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
skipping to change at page 30, line 31 skipping to change at page 33, line 31
Charles E. Perkins Charles E. Perkins
Technology Development Group Technology Development Group
Mail Stop MPK15-214 Mail Stop MPK15-214
Room 2682 Room 2682
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, California 94303 Palo Alto, California 94303
USA USA
Phone: +1-415-786-6464 Phone: +1-650-786-6464
Fax: +1-415-786-6445 Fax: +1-650-786-6445
email: charles.perkins@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/