draft-ietf-dhc-v6exts-10.txt   draft-ietf-dhc-v6exts-11.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems INTERNET DRAFT Sun Microsystems Laboratories
8 July 1998 J. Bound
Compaq Computer Corp.
25 February 1999
Extensions for the Dynamic Host Configuration Protocol for IPv6 Extensions for the Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-v6exts-10.txt draft-ietf-dhc-v6exts-11.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 and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, 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 view the entire list of current Internet-Drafts, please check The list of current Internet-Drafts can be accessed at:
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern http://www.ietf.org/ietf/1id-abstracts.txt
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
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, which will be periodically updated as new
This document specifies the current set of DHCPv6 extensions. This extensions are defined.
document will be periodically updated as new extensions are defined.
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 1 2. DHCPv6 Extension Field Format 2
3. IP Address Extension 2 3. IP Address Extension 3
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 . . . . . . . . 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 . . . . . . . . 8 3.1.4. Use with the DHCP Release message . . . . . . . . 9
3.2. Server Considerations for the IP Address extension . . . 8 3.2. Server Considerations for the IP Address extension . . . 9
3.2.1. Use with the DHCP Advertise message . . . . . . . 8 3.2.1. Use with the DHCP Advertise message . . . . . . . 9
3.2.2. Receiving a DHCP Request with the IP Address 3.2.2. Receiving a DHCP Request with the IP Address
Extension . . . . . . . . . . . . . . . . 9
3.2.3. Use with the DHCP Reply message . . . . . . . . . 9
3.2.4. Use with the DHCP Reconfigure message . . . . . . 10
3.2.5. Receiving a DHCP Release with the IP Address
Extension . . . . . . . . . . . . . . . . 10 Extension . . . . . . . . . . . . . . . . 10
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 10 3.2.3. Use with the DHCP Reply message . . . . . . . . . 10
3.2.4. Use with the DHCP Reconfigure message . . . . . . 11
3.2.5. Receiving a DHCP Release with the IP Address
Extension . . . . . . . . . . . . . . . . 11
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11
4. General Extensions 11 4. General Extensions 11
4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 11 4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 14
4.3. Domain Name Server Extension . . . . . . . . . . . . . . 13 4.3. Domain Name Server Extension . . . . . . . . . . . . . . 14
4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 15
5. Application and Service Parameters 14 5. Application and Service Parameters 15
5.1. Service Location Protocol extensions . . . . . . . . . . 14 5.1. Service Location Protocol extensions . . . . . . . . . . 15
5.1.1. Typed Scope Lists . . . . . . . . . . . . . . . . 14 5.1.1. Typed Scope Lists . . . . . . . . . . . . . . . . 15
5.1.2. Directory Agent Extension . . . . . . . . . . . . 16 5.1.2. Directory Agent Extension . . . . . . . . . . . . 17
5.1.3. Service Scope Extension . . . . . . . . . . . . . 17 5.1.3. Service Scope Extension . . . . . . . . . . . . . 18
5.2. Network Time Protocol Servers Extension . . . . . . . . . 18 5.2. Network Time Protocol Servers Extension . . . . . . . . . 19
5.3. Network Information Service (NIS and NIS+) extensions . . 19 5.3. Network Information Service (NIS and NIS+) extensions . . 20
5.3.1. NIS Domain Extension . . . . . . . . . . . . . . 19 5.3.1. NIS Domain Extension . . . . . . . . . . . . . . 20
5.3.2. NIS Servers Extension . . . . . . . . . . . . . . 19 5.3.2. NIS Servers Extension . . . . . . . . . . . . . . 20
5.3.3. NIS+ Domain Extension . . . . . . . . . . . . . . 19 5.3.3. NIS+ Domain Extension . . . . . . . . . . . . . . 20
5.3.4. NIS+ Servers Extension . . . . . . . . . . . . . 20 5.3.4. NIS+ Servers Extension . . . . . . . . . . . . . 21
6. TCP Parameters 20
6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 20
7. DHCPv6 Extensions 21 6. TCP Parameters 21
7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 21 6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21
7.2. DHCP Retransmission and Configuration Parameter Extension 21 7. DHCPv6 Extensions 22
7.3. Platform Specific Information . . . . . . . . . . . . . . 22 7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 22
7.4. Platform Class Identifier . . . . . . . . . . . . . . . . 23 7.2. DHCP Retransmission and Configuration Parameter Extension 22
7.5. Class Identifier . . . . . . . . . . . . . . . . . . . . 24 7.3. Platform Specific Information . . . . . . . . . . . . . . 23
7.6. Reconfigure Multicast Address . . . . . . . . . . . . . . 25 7.4. Platform Class Identifier . . . . . . . . . . . . . . . . 24
7.7. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 25 7.5. Class Identifier . . . . . . . . . . . . . . . . . . . . 25
7.8. DHCP Relay ICMP Error Message Format . . . . . . . . . . 26 7.6. Reconfigure Multicast Address . . . . . . . . . . . . . . 26
7.8.1. ICMP Extension Client Considerations . . . . . . 26 7.7. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 26
7.8.2. ICMP Extension Relay Considerations . . . . . . . 26 7.8. DHCP Relay ICMP Error Message Format . . . . . . . . . . 27
7.9. Client-Server Authentication Extension . . . . . . . . . 27 7.8.1. ICMP Extension Client Considerations . . . . . . 27
7.10. Client Key Selection Extension . . . . . . . . . . . . . 28 7.8.2. ICMP Extension Relay Considerations . . . . . . . 27
7.9. Client-Server Authentication Extension . . . . . . . . . 28
7.10. Client Key Selection Extension . . . . . . . . . . . . . 29
8. End Extension 28 8. End Extension 29
9. Resource-Server Associations 28 9. Resource-Server Associations 30
10. Security Considerations 29 10. Security Considerations 30
10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 29 10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
10.2. Default Authentication Algorithm . . . . . . . . . . . . 29 10.2. Default Authentication Algorithm . . . . . . . . . . . . 30
11. IANA Considerations 30 11. IANA Considerations 31
12. Acknowledgements 31 12. Acknowledgements 32
13. Full Copyright Statement 31 13. Full Copyright Statement 32
Chair's Address 34 Chair's Address 36
Author's Address 34 Author's Addresses 36
1. Introduction 1. Introduction
This document specifies extensions for use with the Dynamic Host This document specifies extensions for use with the Dynamic Host
Configuration Protocol for IP version 6, DHCPv6. DHCPv6 message Configuration Protocol for IP version 6, DHCPv6. DHCPv6 message
formats are described in the DHCPv6 specification document [4]. In formats are described in the DHCPv6 specification document [4]. In
this document, several words are used to signify the requirements this document, several words are used to signify the requirements
of the specification, in accordance with RFC 2119 [5]. These words of the specification, in accordance with RFC 2119 [5]. These words
(MUST, SHOULD, MAY, MUST NOT, etc) are often capitalized. (MUST, SHOULD, MAY, MUST NOT, etc) are often capitalized.
skipping to change at page 1, line 162 skipping to change at page 2, line 23
- Application and Service Parameters - Application and Service Parameters
- TCP - TCP
- DHCPv6 - DHCPv6
Future applications will make extensive use of an ever-increasing Future applications will make extensive use of an ever-increasing
number and variety of network services. It is expected that client number and variety of network services. It is expected that client
needs for creating connections with these future network services needs for creating connections with these future network services
will be satisfied by the Service Location Protocol [24], and not will be satisfied by the Service Location Protocol [27], 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 2, line 18 skipping to change at page 2, line 50
field specifies the length of the extension data in octets. There field specifies the length of the extension data in octets. There
is no particular requirement for alignment of data fields within is no particular requirement for alignment of data fields within
existing DHCPv6 extensions. Any extensions defined subsequent to existing DHCPv6 extensions. Any extensions defined subsequent to
this document MUST contain a two-octet Length field even if the this document MUST contain a two-octet Length field even if the
length is fixed or zero. length is fixed or zero.
Unrecognized extensions SHOULD be ignored by skipping over the number Unrecognized extensions SHOULD be ignored by skipping over the number
of octets specified in the length field, and processing continued for of octets specified in the length field, and processing continued for
subsequent extensions. Unless and until specified otherwise by use subsequent extensions. Unless and until specified otherwise by use
of extension type 64 (see section 7.1), DHCP entities MUST assume of extension type 64 (see section 7.1), DHCP entities MUST assume
that that the maximum DHCP message size including extensions is 1500 that that the maximum DHCP message size including extensions is 1280
octets. octets.
All multi-octet quantities are in network byte-order. All multi-octet quantities are in network byte-order.
Extension types 32768 to 65534 (decimal) are reserved for Extension types 32768 to 65534 (decimal) are reserved for
site-specific extensions. site-specific extensions.
All of the extensions described in this document will also have their All of the extensions described in this document will also have their
default values specified, if any. Whenever an extension is received default values specified, if any. Whenever an extension is received
as part of a DHCP message, any reserved fields of the message MUST as part of a DHCP message, any reserved fields of the message MUST
skipping to change at page 2, line 46 skipping to change at page 3, line 30
subset. subset.
3. IP Address Extension 3. IP Address Extension
The IP Address extension is the most essential of all the DHCPv6 The IP Address extension is the most essential of all the DHCPv6
extensions. It can be used by both client and server in various extensions. It can be used by both client and server in various
ways. Since the IP Address extension can be used more than once in ways. Since the IP Address extension can be used more than once in
the same DHCP message, all information relevant to a particular IPv6 the same DHCP message, all information relevant to a particular IPv6
allocation has to be collected together in the same extension. Some allocation has to be collected together in the same extension. Some
of the fields within the IP Address extension can specify how DNS may of the fields within the IP Address extension can specify how DNS may
be updated [25]. be updated [28].
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
routing prefix of the link to which the client is currently attached. routing prefix of the link to which the client is currently attached.
An IP Address Extension can contain at most one IP address. To An IP Address Extension can contain at most one IP address. To
specify more than one IP address, multiple extensions are used. specify more than one IP address, multiple extensions are used.
skipping to change at page 3, line 45 skipping to change at page 4, line 40
C If the 'C' bit is set, the field containing the IP C If the 'C' bit is set, the field containing the IP
address for the client is present in the extension. address for the client is present in the extension.
L If the 'L' bit is set, the preferred and valid lifetimes L If the 'L' bit is set, the preferred and valid lifetimes
are present in the extension. are present in the extension.
Q If the 'Q' bit is set, the fields included by the client Q If the 'Q' bit is set, the fields included by the client
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 the
the the server updates DNS with a new AAAA record, as server updates DNS with a new AAAA record, as specified
specified by the client's FQDN. 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 the
the the server updates DNS with a new PTR record, as server updates DNS with a new PTR record, as specified by
specified by the client's FQDN. the client's FQDN.
reserved MUST be zero. reserved MUST be zero.
prefix-size prefix-size
If the client address is present (the 'C' bit is set), a If the client address is present (the 'C' bit is set), a
nonzero prefix-size is the number of leftmost bits of the nonzero prefix-size is the number of leftmost bits of the
client's IPv6 address which make up the routing prefix. client's IPv6 address which make up the routing prefix.
Otherwise, if the 'C' bit is not set, prefix-size MUST be Otherwise, if the 'C' bit is not set, prefix-size MUST be
zero. zero.
skipping to change at page 5, line 22 skipping to change at page 6, line 17
40 Some RRset that ought to exist, does not exist 40 Some RRset that ought to exist, does not exist
(NXRRSET) (NXRRSET)
41 The server is not authoritative for the zone named in 41 The server is not authoritative for the zone named in
the Zone Section (NOTAUTH) the Zone Section (NOTAUTH)
42 A name used in the Prerequisite or Update Section 42 A name used in the Prerequisite or Update Section
is not within the zone denoted by the Zone Section is not within the zone denoted by the Zone Section
(NOTZONE) (NOTZONE)
Status values 33 through 42 are described more fully within Dynamic Status values 33 through 42 are described more fully within Dynamic
Updates to DNS (RFC 2136 [25]). Up-to-date values for the values Updates to DNS (RFC 2136 [28]). Up-to-date values for the values
of the status field are specified in the most recent "Assigned of the status field are specified in the most recent "Assigned
Numbers" [21]. Numbers" [23].
The DNS name can be a host name, which does not contain the '.' The DNS name can be a host name, which does not contain the '.'
ASCII character as a separator between DNS hierarchy components. Any ASCII character as a separator between DNS hierarchy components. Any
name containing the '.' is treated as a Fully Qualified Domain Name name containing the '.' is treated as a Fully Qualified Domain Name
(FQDN). The length of the DNS name may be determined by subtracting, (FQDN). The length of the DNS name may be determined by subtracting,
from the Length, the length of those fixed length fields which are from the Length, the length of those fixed length fields which are
present. present.
If the 'Q' bit is set, the values or actions requested by the C, L, If the 'Q' bit is set, the values or actions requested by the C, L,
A, and P bits are required, and MUST be provided, or the extension A, and P bits are required, and MUST be provided, or the extension
skipping to change at page 5, line 49 skipping to change at page 6, line 44
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 MAY be done even with IP addresses address for updating DNS. This MAY be done even with IP addresses
obtained by Stateless Address Autoconfiguration [23]. If the client obtained by Stateless Address Autoconfiguration [26]. 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.
By default, the client SHOULD update the AAAA record, and the server
SHOULD update the PTR record. The IP Address extension permit
clients and servers to use a different behavior than the default, and
they MAY set the 'Q' and 'A' bits to suit their needs.
3.1. Client Considerations for the IP Address extension 3.1. Client Considerations for the IP Address extension
3.1.1. Address Lifetimes 3.1.1. Address Lifetimes
An IP address returned to a client in a DHCP Reply message has a An IP address returned to a client in a DHCP Reply message has a
preferred and valid lifetime. The valid lifetime represents the preferred and valid lifetime. The valid lifetime represents the
lease for addresses provided to the client, from the server. The lease for addresses provided to the client, from the server. The
client MAY request values for the lifetimes, but the client MUST use client MAY request values for the lifetimes, but the client MUST use
the lifetimes provided by the server response. the lifetimes provided by the server response.
When the preferred lifetime of an IP address expires, the client's When the preferred lifetime of an IP address expires, the client's
address becomes a deprecated address. See [9] for required handling address becomes a deprecated address. See [11] 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). If the client does not make a new Request for preferred lifetime). If the client does not make a new Request for
an address before the valid lifetime expires, the server SHOULD an address before the valid lifetime expires, the server SHOULD
assume the client does not want that address. After it expires, the assume the client does not want that address. After it expires, the
server MAY provide that address to another client. server MAY provide that address to another client.
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 receives a successful reply from the DHCPv6 server, it MUST
decrement the received Lifetimes by the amount of time between
the transmission of the DHCP Request and the reception of the
corresponding DHCP Reply. In this way, the client may expect 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).
- set the prefix-size field to zero. If nonzero, the IP address - set the prefix-size field to zero. If nonzero, the IP address
MUST be included, and the the prefix-size MUST correspond to the MUST be included, and the prefix-size MUST correspond to the
appropriate routing prefix for that IP address. appropriate routing prefix for that IP address.
- set the 'A' bit to request that the server update DNS with a new - set the 'A' bit to request that the server update DNS with a new
AAAA record, as specified by the client's FQDN; if the 'Q' bit is AAAA record, as specified by the client's FQDN.
also set, this update MUST be completed before responding with
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.
also set, this update MUST be completed before responding with
the corresponding DHCP Reply.
- indicate the minimum preferred (and/or valid) lifetime, by - indicate the minimum preferred (and/or valid) lifetime, by
supplying a value for the field(s). supplying a value for the field(s).
- specify whether address, name and lifetimes (if present) are - specify whether address, name and lifetimes (if present) are
advisory -or- mandatory, by setting the 'Q' bit. advisory -or- mandatory, by setting the 'Q' bit.
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. A client indicates that it cannot accept any configuration Request. A client indicates that it cannot accept any configuration
information other than that listed in the IP Address extension (e.g., information other than that listed in the IP Address extension (e.g.,
skipping to change at page 8, line 8 skipping to change at page 8, line 44
Reply [4], it first inspects the status to see whether the requested Reply [4], it first inspects the status to see whether the requested
information has been granted. If the status is nonzero, the client information has been granted. If the status is nonzero, the client
should log the error, and display the error condition for action should log the error, and display the error condition for action
by the user and/or the network administrator. Nonzero status by the user and/or the network administrator. Nonzero status
almost always indicates that the client will be need to modify its almost always indicates that the client will be need to modify its
request before it could be satisfied by the replying DHCP server, or request before it could be satisfied by the replying DHCP server, or
alternatively that the replying DHCP server will need to be given alternatively that the replying DHCP server will need to be given
updated configuration information for the client. updated configuration information for the client.
Upon reception of a new IP address with a lifetime, the client MUST Upon reception of a new IP address with a lifetime, the client MUST
perform Duplicate Address Detection (DAD) [23]; however, if the perform Duplicate Address Detection (DAD) [26]; 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 a DHCP Release message, the client MUST provide at least one In a DHCP Release message, the client MUST provide at least one
specific IP address in the extension. specific IP address in the extension.
skipping to change at page 11, line 33 skipping to change at page 12, line 28
4.2. IEEE 1003.1 POSIX Timezone extension 4.2. IEEE 1003.1 POSIX Timezone extension
Extension type 2, defined in section 4.1, specifies the Universal Extension type 2, defined in section 4.1, specifies the Universal
Coordinated Time (UTC) offset. Unfortunately, the UTC offset Coordinated Time (UTC) offset. Unfortunately, the UTC offset
extension does not provide enough information for an Internet extension does not provide enough information for an Internet
client to determine such timezone-related details as the timezone client to determine such timezone-related details as the timezone
names, daylight savings time start and end times in addition to the names, daylight savings time start and end times in addition to the
timezone UTC offsets. This extension (analogous to that proposed timezone UTC offsets. This extension (analogous to that proposed
for DHCPv4 [6]) allows delivery of timezone information in the form for DHCPv4 [6]) allows delivery of timezone information in the form
of a IEEE 1003.1 POSIX Timezone specifier [13], as detailed in of a IEEE 1003.1 POSIX Timezone specifier [15], as detailed in
section 4.2.1. section 4.2.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 = 3 | Length | | Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEEE 1003.1 POSIX Timezone string (variable length) ... | IEEE 1003.1 POSIX Timezone string (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 4 skipping to change at page 14, line 43
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 = 6 | Length | | Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name System server addresses | | Domain Name System server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Domain Name Server extension specifies a list of Domain Name The Domain Name Server extension specifies a list of Domain Name
System [20] name servers available to the client. Servers SHOULD be System [22] name servers available to the client. Servers SHOULD be
listed in order of preference. listed in order of preference.
The minimum Length for this extension is 16 octets, and MUST always The minimum Length for this extension is 16 octets, and MUST always
be a multiple of 16. be 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 14, line 38 skipping to change at page 15, line 32
the first '.' octet as the Domain Name. the first '.' octet as the Domain Name.
5. Application and Service Parameters 5. Application and Service Parameters
This section details some miscellaneous extensions used to configure This section details some miscellaneous extensions used to configure
miscellaneous applications and services. miscellaneous applications and services.
5.1. Service Location Protocol extensions 5.1. Service Location Protocol extensions
This subsection describes DHCP extensions useful for a client to This subsection describes DHCP extensions useful for a client to
begin operations using the Service Location Protocol (SLP) [24]. begin operations using the Service Location Protocol (SLP) [27].
5.1.1. Typed Scope Lists 5.1.1. Typed Scope Lists
In Service Location Protocol, multiple service types can be hosted on In Service Location Protocol, multiple service types can be hosted on
the same network node. However, DHCP typically configures computers the same network node. However, DHCP typically configures computers
based on their IP address. It is possible that different service based on their IP address. It is possible that different service
types on the same computer would be administered from different types on the same computer would be administered from different
scopes. Thus, extensions 16 and 17 have additional syntax to allow scopes. Thus, extensions 16 and 17 have additional syntax to allow
this more detailed style of service configuration. this more detailed style of service configuration.
skipping to change at page 15, line 26 skipping to change at page 16, line 17
A typed-scope-list in a DHCP Request is structured as follows: A typed-scope-list in a DHCP Request is structured as follows:
typed-scope-list = one or more maybe-typed-scope-items, typed-scope-list = one or more maybe-typed-scope-items,
separated by commas separated by commas
maybe-typed-scope-item = typed-scope-item, or maybe-typed-scope-item = typed-scope-item, or
maybe-empty-scope-list maybe-empty-scope-list
typed-scope-item = '(' service-type '=' maybe-empty-scope-list ')' typed-scope-item = '(' service-type '=' maybe-empty-scope-list ')'
maybe-empty-scope-list = zero or more scope-items, comma-separated 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 A service type has the format defined in [12], and a scope-item has
the format defined in [11] for "strval". Basically, a scope-item is the format defined in [13] for "strval". Basically, a scope-item is
a character string that has alphanumeric characters not including a character string that has alphanumeric characters not including
control characters or `(',`)',`,', \',`!',`<',`=',`>', or `~' Service control characters or `(',`)',`,', \',`!',`<',`=',`>', or `~' Service
schemes are special cases of schemes as defined for general URLs [3]. schemes are special cases of schemes as defined for general URLs [3].
The typed-scope-list MAY contain both untyped-scope-lists and The typed-scope-list MAY contain both untyped-scope-lists and
typed-scope-lists. Each scope-item in each untyped-scope-list typed-scope-lists. Each scope-item in each untyped-scope-list
applies to every service type on the node. The string containing the applies to every service type on the node. The string containing the
typed-scope-list is NOT null-terminated. The typed-scope-list string typed-scope-list is NOT null-terminated. The typed-scope-list string
must be UTF-8 character encoded. must be UTF-8 character encoded.
skipping to change at page 16, line 4 skipping to change at page 16, line 44
Suppose instead that service types "netman" and "proxystuff" are Suppose instead that service types "netman" and "proxystuff" are
residing on a DHCP client. Then, the typed-scope-list in a DHCP residing on a DHCP client. Then, the typed-scope-list in a DHCP
Reply could be, Reply could be,
(netman=mgmt),(proxystuff=math-dept,labs) (netman=mgmt),(proxystuff=math-dept,labs)
Assuming the DHCP client with two service types "netman" and Assuming the DHCP client with two service types "netman" and
"proxystuff" did not make any scope restriction, a corresponding "proxystuff" did not make any scope restriction, a corresponding
typed-scope-list in a DHCP Request could be, typed-scope-list in a DHCP Request could be,
(netman=),(proxystuff=) (netman=),(proxystuff=)
asking for scopes for those service types. asking for scopes for those service types.
5.1.2. Directory Agent Extension 5.1.2. Directory Agent Extension
Entities using the Service Location Protocol (SLP) [24] need to find Entities using the Service Location Protocol (SLP) [27] need to find
out the address of one or more Directory Agents in order to transact out the address of one or more Directory Agents in order to transact
messages, and possibly the correct scope to be used in conjunction messages, and possibly the correct scope to be used in conjunction
with the service attributes which are exchanged using the Service with the service attributes which are exchanged using the Service
Location Protocol. Location Protocol.
The Directory Agent extension requests or specifies a Directory Agent The Directory Agent extension requests or specifies a Directory Agent
(DA), along with zero or more scopes supported by that DA. Note (DA), along with zero or more scopes supported by that DA. Note
that this extension MAY be included multiple times in the same DHCP that this extension MAY be included multiple times in the same DHCP
Request or DHCP Reply. If so, then the extensions SHOULD be included Request or DHCP Reply. If so, then the extensions SHOULD be included
in order of decreasing preference. in order of decreasing preference.
skipping to change at page 17, line 47 skipping to change at page 18, line 45
Extension 16 MUST include one or more scopes if a DA address is Extension 16 MUST include one or more scopes if a DA address is
returned. Using extension 16, it is not possible for different returned. Using extension 16, it is not possible for different
service types on the same node to be configured with different service types on the same node to be configured with different
directory agents. In other words, all service agents of the same directory agents. In other words, all service agents of the same
service type on the same node will be configured with the same service type on the same node will be configured with the same
directory agent. directory agent.
5.1.3. Service Scope Extension 5.1.3. Service Scope Extension
This extension indicates a scope that should be used by a Service This extension indicates a scope that should be used by a Service
Agent (SA) [24], when responding to Service Request messages as Agent (SA) [27], when responding to Service Request messages as
specified by the Service Location Protocol (SLP). This extension MAY specified by the Service Location Protocol (SLP). This extension MAY
be included multiple times in the same DHCP Request or DHCP Reply. be included multiple times in the same DHCP Request or DHCP Reply.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 17 | Length | | Type = 17 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed-Scope-List ... | Typed-Scope-List ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 32 skipping to change at page 19, line 32
registrations. registrations.
DHCP clients MAY use extension 17 to request scopes for one or more DHCP clients MAY use extension 17 to request scopes for one or more
particular service types. Note that more than one Service Scope particular service types. Note that more than one Service Scope
extension may be present in a DHCP message. The length of the extension may be present in a DHCP message. The length of the
typed-scope-list is only indicated implicitly by the overall length typed-scope-list is only indicated implicitly by the overall length
of the extension. of the extension.
5.2. Network Time Protocol Servers Extension 5.2. Network Time Protocol Servers Extension
This extension specifies a list of IP addresses indicating NTP [18] This extension specifies a list of IP addresses indicating NTP [20]
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 = 18 | Length | | Type = 18 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP server addresses | | NTP server addresses |
| (16 octets each) | | (16 octets each) |
skipping to change at page 19, line 12 skipping to change at page 20, line 12
The minimum Length for this extension is 16, and the Length MUST be a The minimum Length for this extension is 16, and the Length MUST be a
multiple of 16. multiple of 16.
5.3. Network Information Service (NIS and NIS+) extensions 5.3. Network Information Service (NIS and NIS+) extensions
This subsection describes DHCPv6 extensions useful for NIS and NIS+ This subsection describes DHCPv6 extensions useful for NIS and NIS+
clients. clients.
5.3.1. NIS Domain Extension 5.3.1. NIS Domain Extension
This extension specifies the name of the client's NIS [17] domain. This extension specifies the name of the client's NIS [19] 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. The minimum Length for characters from the US-ASCII character set. The minimum Length for
this extension is 1. this extension is 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 19 | Length | | Type = 19 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS Domain Name (variable length) ... | NIS Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3.2. NIS Servers Extension 5.3.2. NIS Servers Extension
This extension specifies a list of IP addresses indicating NIS [17] This extension specifies a list of IP addresses indicating NIS [19]
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 = 20 | Length | | Type = 20 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS server addresses | | NIS server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The minimum Length for this extension is 16, and the Length MUST be a The minimum Length for this extension is 16, and the Length MUST be a
multiple of 16. multiple of 16.
5.3.3. NIS+ Domain Extension 5.3.3. NIS+ Domain Extension
This extension specifies the name of the client's NIS+ [17] This extension specifies the name of the client's NIS+ [19]
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. The minimum Length for characters from the US-ASCII character set. The minimum Length for
this extension is 1. this extension is 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 21 | Length | | Type = 21 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ Client Domain Name (variable length) ... | NIS+ Client Domain Name (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3.4. NIS+ Servers Extension 5.3.4. NIS+ Servers Extension
This extension specifies a list of IP addresses indicating NIS+ [17] This extension specifies a list of IP addresses indicating NIS+ [19]
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 = 22 | Length | | Type = 22 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NIS+ server addresses | | NIS+ server addresses |
| (16 octets each) | | (16 octets each) |
skipping to change at page 21, line 30 skipping to change at page 22, line 30
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 40 | Length = 4 | | Type = 40 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max DHCPv6 Message Length | | Max DHCPv6 Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length for this extension is 4. The minimum permissible value is The Length for this extension is 4. The minimum permissible value is
1500. 1280 [11].
7.2. DHCP Retransmission and Configuration Parameter Extension 7.2. DHCP Retransmission and Configuration Parameter Extension
This extension allows configuration of values for DHCP This extension allows configuration of values for DHCP
retransmission and configuration parameters, as specified retransmission and configuration parameters, as specified
for use when sending or receiving DHCPv6 messages [4]. for use when sending or receiving DHCPv6 messages [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 25 skipping to change at page 23, line 25
REPLY_MSG_TIMEOUT 6 2000 milliseconds REPLY_MSG_TIMEOUT 6 2000 milliseconds
REPLY_MSG_RETRANS_INTERVAL 7 2000 milliseconds REPLY_MSG_RETRANS_INTERVAL 7 2000 milliseconds
RECONF_MSG_TIMEOUT 8 12000 milliseconds RECONF_MSG_TIMEOUT 8 12000 milliseconds
RECONF_MSG_MIN_RETRANS 9 10 retransmissions RECONF_MSG_MIN_RETRANS 9 10 retransmissions
RECONF_MSG_RETRANS_INTERVAL 10 12000 milliseconds RECONF_MSG_RETRANS_INTERVAL 10 12000 milliseconds
RECONF_MMSG_MIN_RESP 11 2000 milliseconds RECONF_MMSG_MIN_RESP 11 2000 milliseconds
RECONF_MMSG_MAX_RESP 12 10000 milliseconds RECONF_MMSG_MAX_RESP 12 10000 milliseconds
MIN_SOLICIT_DELAY 13 1000 millisecond MIN_SOLICIT_DELAY 13 1000 millisecond
MAX_SOLICIT_DELAY 14 5000 milliseconds MAX_SOLICIT_DELAY 14 5000 milliseconds
XID_TIMEOUT 15 600000 milliseconds XID_TIMEOUT 15 600000 milliseconds
RECONF_MULTICAST_REQUEST_WAIT 16 120000 miliseconds
All timing parameters are measured in milliseconds. DHCP All timing parameters are measured in milliseconds. DHCP
clients MUST be able to process this extension when part of a clients MUST be able to process this extension when part
DHCP Reply message, and be able to reconfigure their values of a DHCP Reply message, and be able to reconfigure their
for DEFAULT_SOLICIT_HOPCOUNT, REQUEST_MSG_MIN_RETRANS, and values for DEFAULT_SOLICIT_HOPCOUNT, REQUEST_MSG_MIN_RETRANS,
REPLY_MSG_TIMEOUT, REPLY_MSG_RETRANS_INTERVAL. Servers MAY and REPLY_MSG_TIMEOUT, REPLY_MSG_RETRANS_INTERVAL, and
refuse client requests for configuration of the server's internal RECONF_MULTICAST_REQUEST_WAIT. Servers MAY refuse client
configuration variables. Alternatively, a server MAY keep separate requests for configuration of the server's internal configuration
configuration variables for any requesting client that are different variables. Alternatively, a server MAY keep separate configuration
than for clients which do not make such requests. variables for any requesting client that are different than for
clients which do not make such requests.
7.3. Platform Specific Information 7.3. Platform Specific Information
A platform is defined as the combination of hardware and operating A platform is defined as the combination of hardware and operating
system (OS). system (OS).
This extension is used by clients and servers to exchange This extension is used by clients and servers to exchange
client-platform-specific information. The information is an opaque client-platform-specific information. The information is an opaque
collection of data, presumably interpreted by platform-specific code collection of data, presumably interpreted by platform-specific code
on the clients. The definition of this information is platform on the clients. The definition of this information is platform
skipping to change at page 26, line 21 skipping to change at page 27, line 30
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 68 | Length | | Type = 68 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICMP Error Message | | ICMP Error Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length of the DHCP Relay ICMP Message extension is the length of The Length of the DHCP Relay ICMP Message extension is the length of
the ICMP error message received by the relay [8]. the ICMP error message received by the relay [9].
7.8.1. ICMP Extension Client Considerations 7.8.1. ICMP Extension Client Considerations
When a client sends a Solicit or Request message it may often be When a client sends a Solicit or Request message it may often be
forwarded by a relay. When the relay forwards messages for a client forwarded by a relay. When the relay forwards messages for a client
the network may return an ICMP error [8] message to the relay. The the network may return an ICMP error [9] message to the relay. The
relay determines the client's link-local address within the UDP relay determines the client's link-local address within the UDP
payload of the ICMP returned error message payload, and sends the payload of the ICMP returned error message payload, and sends the
client a DHCP Relay ICMP Error message as defined in section 7.8.2. client a DHCP Relay ICMP Error message as defined in section 7.8.2.
The client MAY record these messages based on the ICMP type and The client MAY record these messages based on the ICMP type and
reason codes provided in the ICMP Error payload [8], for future use reason codes provided in the ICMP Error payload [9], for future use
or for system logging purposes. How the client uses this information or for system logging purposes. How the client uses this information
is implementation dependent. is implementation dependent.
7.8.2. ICMP Extension Relay Considerations 7.8.2. ICMP Extension Relay Considerations
If the relay receives an ICMP error message after forwarding a If the relay receives an ICMP error message after forwarding a
client's DHCP Solicit or Request message, it MUST inspect the client's DHCP Solicit or Request message, it MUST inspect the
payload of the ICMP message [8], to determine the client's link-local payload of the ICMP message [9], to determine the client's link-local
address. The relay MUST check that it is a link-local address; if address. The relay MUST check that it is a link-local address; if
not, the ICMP error message MUST be silently discarded. Otherwise, not, the ICMP error message MUST be silently discarded. Otherwise,
the relay should forward the ICMP Error message to the client as the relay should forward the ICMP Error message to the client as
specified in section 7.8.1, by using the client's link-local address specified in section 7.8.1, by using the client's link-local address
from the ICMP error message as the IP destination address in the from the ICMP error message as the IP destination address in the
IP header sent to the client. If the relay cannot determine the IP header sent to the client. If the relay cannot determine the
client's link-local address in the ICMP error message the packet MUST client's link-local address in the ICMP error message the packet MUST
be silently discarded. be silently discarded.
7.9. Client-Server Authentication Extension 7.9. Client-Server Authentication Extension
skipping to change at page 27, line 33 skipping to change at page 28, line 42
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 a security SPI A Security Parameters Index [2] identifying a security
context from among those available between the DHCPv6 context from among those available between the DHCPv6
client and server. client and server.
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [19](NTP) A 64-bit timestamp (in Network Time Protocol [21](NTP)
format) (see section 10.1). format) (see section 10.1).
Authenticator Authenticator
(variable length) (See Section 10.2.) (variable length) (See Section 10.2.)
This authentication extension remedies the inability of IPsec [15] This authentication extension remedies the inability of IPsec [17]
to provide for non end-to-end authentication, since authentication to provide for non end-to-end authentication, since authentication
is needed even when the client has no IPv6 address of large enough is needed even when the client has no IPv6 address of large enough
scope to reach the DHCP server. The extension can be originated by scope to reach the DHCP server. The extension can be originated by
either the client or server to authenticate the rest of the data in either the client or server to authenticate the rest of the data in
the DHCPv6 message. The default authentication algorithm, which MUST the DHCPv6 message. The default authentication algorithm, which MUST
be supported by all clients and servers, is defined in section 10.2. be supported by all clients and servers, is defined in section 10.2.
SPI values 0 through 255 are reserved and, if used, MUST conform SPI values 0 through 255 are reserved and, if used, MUST conform
to the security context defined by that value in the most recent to the security context defined by that value in the most recent
Assigned Numbers RFC (e.g., [14]). Assigned Numbers RFC (e.g., [16]).
7.10. Client Key Selection Extension 7.10. Client Key Selection Extension
A DHCPv6 server may wish to indicate to a prospective client which A DHCPv6 server may wish to indicate to a prospective client which
SPI it must use to authenticate subsequent messages, using the SPI it must use to authenticate subsequent messages, using the
Client-Server Authentication Extension. In such cases, the server Client-Server Authentication Extension. In such cases, the server
includes the Client Key Selection Extension in its DHCP Advertise includes the Client Key Selection Extension in its DHCP Advertise
message. message.
0 1 2 3 0 1 2 3
skipping to change at page 28, line 26 skipping to change at page 29, line 33
| Type = 85 | Length = 4 | | Type = 85 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | | Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SPI is a Security Parameters index [2] identifying a security The SPI is a Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts available in the context between a pair of nodes among the contexts available in the
security association defined between the DHCPv6 client and server. security association defined between the DHCPv6 client and server.
SPI values 0 through 255 are reserved and, if used, MUST conform to 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 the security context defined by that value as defined in the most
recent Assigned Numbers RFC (e.g., [12]). recent Assigned Numbers RFC (e.g., [14]).
8. End Extension 8. End Extension
The end extension marks the end of valid information in the vendor The end extension marks the end of valid information in the vendor
field. The Type for the end extension is 65535, and its Length is 2 field. The Type for the end extension is 65535, and its Length is 2
octets; there is no Length field for the end extension. octets; there is no Length field for the end extension.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 21 skipping to change at page 30, line 31
A security protocol is urgently needed for use with DHCPv6, since A security protocol is urgently needed for use with DHCPv6, since
otherwise malicious parties could create numerous denial-of-service otherwise malicious parties could create numerous denial-of-service
style attacks based on depleting available server resources or style attacks based on depleting available server resources or
providing corrupted or infected data to unsuspecting clients. The providing corrupted or infected data to unsuspecting clients. The
following sections discuss aspects of security relevant for users following sections discuss aspects of security relevant for users
of the Client-Server Authentication extension 7.9. See also the of the Client-Server Authentication extension 7.9. See also the
Security Considerations in the companion specification [4]. Security Considerations in the companion specification [4].
10.1. Replay Protection 10.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [19](NTP) format, is A 64-bit timestamp, in Network Time Protocol [21](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.
10.2. Default Authentication Algorithm 10.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [16], using The default authentication algorithm is HMAC [18], using
keyed-MD5 [22]. Given a secret key K, and "data" the information to keyed-MD5 [24]. 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
skipping to change at page 30, line 26 skipping to change at page 31, line 35
and registration is required. and registration is required.
The following steps MUST be followed by the author of any new DHCP The following steps MUST be followed by the author of any new DHCP
extension, in order to obtain acceptance of the extension as a part extension, in order to obtain acceptance of the extension as a part
of the DHCP Internet Standard: of the DHCP Internet Standard:
1. The author documents the new extension as an Internet Draft. 1. The author documents the new extension as an Internet Draft.
2. The author submits the Internet Draft for review through the 2. 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" [14]. The new extension will be submitted for Standards" [16]. The new extension will be submitted for
eventual acceptance as an Internet Standard. eventual acceptance as an Internet Standard.
3. The author requests a number for the new extension from IANA by 3. The author requests a number for the new extension from IANA by
contacting: contacting:
Internet Assigned Numbers Authority (IANA) Internet Assigned Numbers Authority (IANA)
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, California 90292-6695 Marina del Rey, California 90292-6695
or by email as: iana@isi.edu or by email as: iana@isi.edu
skipping to change at page 31, line 4 skipping to change at page 32, line 13
an Internet Draft not submitted by an IETF working group. an Internet Draft not submitted by an IETF working group.
5. If the new extension fails to gain acceptance as an Internet 5. If the new extension fails to gain acceptance as an Internet
Standard, the assigned extension number will be returned to IANA Standard, the assigned extension number will be returned to IANA
for reassignment. for reassignment.
This procedure for defining new extensions will ensure that: This procedure for defining new extensions will ensure that:
* allocation of new extension numbers is coordinated from a single * allocation of new extension numbers is coordinated from a single
authority, authority,
* new extensions are reviewed for technical correctness and * new extensions are reviewed for technical correctness and
appropriateness, and appropriateness, and
* documentation for new extensions is complete and published. * documentation for new extensions is complete and published.
12. Acknowledgements 12. Acknowledgements
Thanks to Jim Bound for his frequent review, helpful suggestions, and The original form of this internet draft was copied directly from
design assistance. Ralph Droms has also made many, many suggestions RFC1533 [1], written by Steve Alexander and Ralph Droms. Thanks to
which have been incorporated into this draft. The original form of Mike Carney for his many helpful comments, as well as contributing
this internet draft was copied directly from RFC1533 [1], written the design of the Platform Specific Information and Platform Class
by Steve Alexander and Ralph Droms. Thanks to Mike Carney for his Identifier. Thanks to Erik Guttman for his helpful suggestions
many helpful comments, as well as contributing the design of the for the Service Location extensions. Thanks to Ralph Droms, Matt
Platform Specific Information and Platform Class Identifier. Thanks Crawford, Thomas Narten, and Erik Nordmark for their careful review
to Erik Guttman for his helpful suggestions for the Service Location as part of the Last Call process.
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.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved. Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
skipping to change at page 32, line 16 skipping to change at page 34, line 16
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993. Extensions. RFC 1533, October 1993.
[2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource [3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
Locators (URL). RFC 1738, December 1994. Locators (URL). RFC 1738, December 1994.
[4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-14.txt, June 1998. (work in for IPv6. draft-ietf-dhc-dhcpv6-14.txt, February 1999. (work
progress). in progress).
[5] S. Bradner. Key Words for Use in RFCs to Indicate Requirement [5] S. Bradner. Key Words for Use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997. Levels. RFC 2119, March 1997.
[6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone [6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications. draft-ietf-dhc-timezone-01.txt, January 1997. Specifications. draft-ietf-dhc-timezone-01.txt, January 1997.
(work in progress). (work in progress).
[7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, [7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996. February 1996.
[8] A. Conta and S. Deering. Internet Control Message Protocol [8] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885, (ICMPv6) for the Internet Protocol Version 6 (IPv6). RFC 1885,
December 1995. December 1995.
[9] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [9] A. Conta and S. Deering. RFC 2463: Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification, December 1998. Obsoletes RFC1885 [8]. Status:
DRAFT STANDARD.
[10] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[10] E. Guttman, C. Perkins, and J. Kempf. Service Templates and [11] S. Deering and R. Hinden. RFC 2460: Internet Protocol, Version
6 (IPv6) specification, December 1998. Obsoletes RFC1883 [10].
Status: DRAFT STANDARD.
[12] E. Guttman, C. Perkins, and J. Kempf. Service Templates and
service: Schemes. draft-ietf-svrloc-service-scheme-05.txt, service: Schemes. draft-ietf-svrloc-service-scheme-05.txt,
November 1997. (work in progress). November 1997. (work in progress).
[11] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service [13] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service
Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txt, Location Protocol version 2. draft-ietf-svrloc-protocol-v2-04.txt,
March 1998. (work in progress). March 1998. (work in progress).
[12] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic [14] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994. Routing Encapsulation (GRE). RFC 1701, October 1994.
[13] IEEE. 1003.1 POSIX Timezone Specification, 1988. [15] IEEE. 1003.1 POSIX Timezone Specification, 1988.
[14] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1, [16] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
May 1998. May 1998.
[15] Stephen Kent and Randall Atkinson. IP Authentication Header. [17] Stephen Kent and Randall Atkinson. IP Authentication Header.
draft-ietf-ipsec-auth-header-07.txt, July 1998. (work in draft-ietf-ipsec-auth-header-07.txt, July 1998. (work in
progress). progress).
[16] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing [18] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997. for Message Authentication. RFC 2104, February 1997.
[17] Sun Microsystems. System and Network Administration, March [19] Sun Microsystems. System and Network Administration, March
1992. 1992.
[18] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for [20] 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.
[19] David L. Mills. Network Time Protocol (Version 3): [21] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[20] P. Mockapetris. Domain Names - Concepts and Facilities. IETF [22] P. Mockapetris. Domain Names - Concepts and Facilities. IETF
STD 13, November 1987. STD 13, November 1987.
[21] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2, [23] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2,
October 1994. October 1994.
[22] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [24] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[23] S. Thomson and T. Narten. IPv6 Stateless Address [25] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. RFC 1971, August 1996. Autoconfiguration. RFC 1971, August 1996.
[24] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [26] S. Thomson and T. Narten. RFC 2462: IPv6 stateless address
autoconfiguration, December 1998. Obsoletes RFC1971 [25].
Status: DRAFT STANDARD.
[27] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. RFC 2165, July 1997. Location Protocol. RFC 2165, July 1997.
[25] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates [28] 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 Addresses
Questions about this memo can be directed to: Questions about this memo can be directed to:
Charles E. Perkins Charles E. Perkins Jim Bound
Technology Development Group Sun Microsystems Laboratories Compaq Computer Corporation
Mail Stop MPK15-214, Room 2682 Mail Stop MPK15-214, Room 2682 ZKO3-3/U14
Sun Microsystems, Inc. 15 Network Circle 110 Spitbrook Road
15 Network Drive Menlo Park, CA 94025 Nashua, NH 03062
Menlo Park, California 94025 USA USA
USA
Phone: +1-650-786-6464 Phone: +1 650 786-6464 Phone: +1-603-884-0400
Fax: +1-650-786-6445 EMail: cperkins@eng.sun.com EMail: bound@zk3.dec.com
email: charles.perkins@Sun.COM Fax: +1 650 786-6445
web: http://www.svrloc.org/~charliep web: http://www.svrloc.org/~charliep
 End of changes. 

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