draft-ietf-dhc-v6exts-05.txt   draft-ietf-dhc-v6exts-06.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT Sun Microsystems INTERNET DRAFT Sun Microsystems
27 February 1997 26 May 1997
Extensions for DHCPv6 Extensions for DHCPv6
draft-ietf-dhc-v6exts-05.txt draft-ietf-dhc-v6exts-06.txt
Status of This Memo Status of This Memo
This document is a submission to the Dynamic Host Configuration This document is a submission to the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcp-v6@bucknell.edu mailing list. should be submitted to the dhcp-v6@bucknell.edu mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
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 the To learn the current status of any Internet-Draft, please check
``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 (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 [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. valid extensions.
skipping to change at page 1, line 59 skipping to change at page 1, line 59
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. DHCPv6 Extension Field Format 2 2. DHCPv6 Extension Field Format 2
2.1. Character Encoding and String Issues . . . . . . . . . . 2 2.1. Character Encoding and String Issues . . . . . . . . . . 2
3. Padding and End extension specifications 3 3. IPv6 Address Extension 3
3.1. Pad Extension . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Client Considerations for the IPv6 Address extension . . 5
3.2. End Extension . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 5
3.1.2. Use with the DHCP Request message . . . . . . . . 6
4. IPv6 Address Extension 3 3.1.3. Receiving as part of the DHCP Reply message . . . 7
4.1. Client Considerations for the IPv6 Address extension . . 6 3.1.4. Use with the DHCP Release message . . . . . . . . 7
4.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6 3.2. Server Considerations for the IPv6 Address extension . . 7
4.1.2. Use with the DHCP Request message . . . . . . . . 6 3.2.1. Use with the DHCP Advertise message . . . . . . . 7
4.1.3. Receiving as part of the DHCP Reply message . . . 7 3.2.2. Receiving a DHCP Request with the IPv6 Address
4.1.4. Use with the DHCP Release message . . . . . . . . 7
4.2. Server Considerations for the IPv6 Address extension . . 8
4.2.1. Use with the DHCP Advertise message . . . . . . . 8
4.2.2. Receiving a DHCP Request with the IPv6 Address
Extension . . . . . . . . . . . . . . . . 8 Extension . . . . . . . . . . . . . . . . 8
4.2.3. Use with the DHCP Reply message . . . . . . . . . 8 3.2.3. Use with the DHCP Reply message . . . . . . . . . 8
4.2.4. Use with the DHCP Reconfigure message . . . . . . 9 3.2.4. Use with the DHCP Reconfigure message . . . . . . 9
4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 9 3.2.5. Receiving a DHCP Release with the IPv6 Address
Extension . . . . . . . . . . . . . . . . 9
3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 9
5. General Extensions 9 4. General Extensions 9
5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Domain Name Server Extension . . . . . . . . . . . . . . 10 4.2. Domain Name Server Extension . . . . . . . . . . . . . . 10
5.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 11
6. Service Location Extensions 11 5. Service Location Extensions 11
6.1. Directory Agent Extension . . . . . . . . . . . . . . . . 11
6.2. Service Scope Extension . . . . . . . . . . . . . . . . . 12
7. IP Layer Parameters per Interface 13 6. Directory Agent Extension 12
7.1. Static Route Extension . . . . . . . . . . . . . . . . . 13
8. TCP Parameters 14 7. Service Scope Extension 13
8.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 14
9. Vendor Specific Information 14
10. DHCPv6 Extensions 16 8. IP Layer Parameters per Interface 14
10.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 16 8.1. Static Route Extension . . . . . . . . . . . . . . . . . 14
10.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 16
10.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 17
10.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 17
10.5. Client-Server Authentication Extension . . . . . . . . . 18
11. Security Considerations 19 9. TCP Parameters 15
11.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 19 9.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 15
11.2. Default Authentication Algorithm . . . . . . . . . . . . 19
12. New Extensions 20 10. Vendor Specific Information 15
13. Acknowledgements 20 11. DHCPv6 Extensions 16
11.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 16
11.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 17
11.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 17
11.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 18
11.5. Client-Server Authentication Extension . . . . . . . . . 19
11.6. Client Key Selection Extension . . . . . . . . . . . . . 20
Chair's Address 22 12. End extension specification 20
Author's Address 22 13. Security Considerations 20
13.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 21
13.2. Default Authentication Algorithm . . . . . . . . . . . . 21
14. Defining New Extensions 21
15. Acknowledgements 23
Chair's Address 25
Author's Address 25
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]. specification document [4]. In this document, several words are used
to signify the requirements of the specification, in accordance with
RFC 2119 [5]. These words (MUST, SHOULD, MAY, MUST NOT, etc) are
often capitalized.
This document defines the format of information in the last field This document defines the format of information in the last field
of DHCPv6 messages ('extensions'). The extensions defined within of DHCPv6 messages ('extensions'). The extensions defined within
this document specify a generalized use of this area for giving this document specify a generalized use of this area for giving
information useful to a wide class of machines, operating systems information useful to a wide class of machines, operating systems
and configurations. Sites with a single DHCPv6 server that is and configurations. Sites with a single DHCPv6 server that is
shared among heterogeneous clients may choose to define other, site- shared among heterogeneous clients may choose to define other, site-
specific formats for the use of the 'extensions' field. specific formats for the use of the 'extensions' field.
Section 2 of this memo describes the formats of DHCPv6 extensions. Section 2 of this memo describes the formats of DHCPv6 extensions.
Information on registering new extensions is contained in section 12. Information on registering new extensions is contained in section 14.
The other sections organize the format descriptions of various The other sections organize the format descriptions of various
extensions according to their general type, as follows: extensions according to their general type, as follows:
- IP Address extension - IP Address extension
- Miscellaneous host configuration - Miscellaneous host configuration
- Service Location configuration - Service Location configuration
- Miscellaneous network layer - Miscellaneous network layer
- TCP - TCP
- Vendor Specific - Vendor Specific
- DHCPv6 - DHCPv6
Future applications will make extensive use of an ever-increasing Future applications will make extensive use of an ever-increasing
number and variety of network services. It is expected that client number and variety of network services. It is expected that client
needs for creating connections with these future network services needs for creating connections with these future network services
will be satisfied by the Service Location Protocol [12], and not will be satisfied by the Service Location Protocol [15], and not
DHCPv6. DHCP is expected to be used for the kinds of configuration DHCPv6. DHCP is expected to be used for the kinds of configuration
that enable clients to become fully functional as self-contained that enable clients to become fully functional as self-contained
network entities, but not the kinds of configuration that might be network entities, but not the kinds of configuration that might be
required by applications running above the network or transport layer required by applications running above the network or transport layer
protocol levels. protocol levels.
2. DHCPv6 Extension Field Format 2. DHCPv6 Extension Field Format
DHCPv6 extensions have the same format as the BOOTP "vendor DHCPv6 extensions have the same format as the BOOTP "vendor
extensions" defined in RFC 1497 [9]. Extensions may be fixed length extensions" [2]. Extensions may be fixed length or variable length.
or variable length. All extensions except for the pad extension All extensions begin with a type field which is two octets long,
begin with a type field which is two octets long, which uniquely which uniquely identifies the extension. Fixed length extensions
identifies the extension. Fixed length extensions without data without data consist of only the two octet type field. Only
consist of only the two octet type field. Only extensions 0 and extension 65535 is fixed length. All other extensions are variable
65535 are fixed length. All other extensions are variable length length with a two octet length field following the type octets. The
with a two octet length field following the type octets. The value value of the length field does not include the two octets specifying
of the length octets does not include the two octets specifying the the type and length. The length field is followed by "length" octets
type and length. The length octet is followed by "length" octets
of data. In the case of some variable length extensions the length of data. In the case of some variable length extensions the length
field is a constant but must still be specified. field is a constant but MUST still be specified.
Any extensions defined subsequent to this document should contain a Any extensions defined subsequent to this document should contain a
length field of two octets in length even if the length is fixed or length field of two octets in length even if the length is fixed or
zero. Unknown options MAY be skipped by ignoring the number of bytes zero. Unknown options MAY be skipped by ignoring the number of bytes
specified in the length octets. All multi-octet quantities are in specified in the length field. All multi-octet quantities are in
network byte-order. network byte-order.
Extension types 32768 to 65534 (decimal) are reserved for Extension types 32768 to 65534 (decimal) are reserved for
site-specific extensions. site-specific extensions.
All of the extensions described in this document will also have their All of the extensions described in this document will also have their
default values specified, if any. default values specified, if any.
2.1. Character Encoding and String Issues 2.1. Character Encoding and String Issues
Values for character encoding can be found in the Internet Assigned Values for character encoding can be found in the Internet Assigned
Numbers Authority's (IANA) database Numbers Authority's (IANA) database
http://www.isi.edu/in-notes/iana/assignments/character-sets http://www.isi.edu/in-notes/iana/assignments/character-sets
and have the values referred by the MIBEnum value. and have the values referred by the MIBEnum value. Note that in some
character sets, each character may require two or more octets of data
for its representation.
The encoding will determine the interpretation of all character data The encoding will determine the interpretation of all character data
in the corresponding fields of particular extensions. There is no in the corresponding fields of particular extensions. There is no
way to mix ASCII and UNICODE, for example. All responses must be in way to mix ASCII and UNICODE, for example. All responses MUST be in
the character set of the request or use US-ASCII. If a request is the character set of the request or use US-ASCII. If a request is
sent to a DHCP server, which is unable to manipulate or store the sent to a DHCP server, which is unable to manipulate or store the
character set of the incoming message, the request will fail. The character set of the incoming message, the request will fail. The
server returns a CHARSET_NOT_UNDERSTOOD error (24) in a DHCP Reply server returns a CHARSET_NOT_UNDERSTOOD error (24) in a DHCP Reply
message in this case. Requests using US-ASCII (MIBEnum value == 3) message in this case. Requests using US-ASCII (MIBEnum value == 3)
will never fail for this reason, since all DHCP entities must be able will never fail for this reason, since all DHCP entities MUST be able
to accept this character set. All DNS-related strings are presumed to accept this character set. All DNS-related strings are presumed
to be encoded in US-ASCII. to be encoded in US-ASCII.
3. Padding and End extension specifications 3. IPv6 Address Extension
3.1. Pad Extension
The pad extension can be used to cause subsequent fields to align on
word boundaries.
The Type for the pad extension is 0, and its length is 1 octet.
Type
+-----+
| 0 |
+-----+
3.2. End Extension
The end extension marks the end of valid information in the vendor
field. Subsequent octets should be filled with pad extensions.
The Type for the end extension is 65535, and its length is 2 octets.
Type
+-----+-----+
| 65535 |
+-----+-----+
4. IPv6 Address Extension
The IPv6 Address extension is the most essential of all the DHCPv6 The IPv6 Address extension is the most essential of all the DHCPv6
extensions. It can be used by both client and server in various extensions. It can be used by both client and server in various
ways. Since the IPv6 Address option can be used more than once in ways. Since the IPv6 Address option can be used more than once in
the same DHCP message, all information relevant to a particular IPv6 the same DHCP message, all information relevant to a particular IPv6
allocation has to be collected together in the same extension. Some allocation has to be collected together in the same extension. Some
of the fields within the IPv6 Address extension can specify how of the fields within the IPv6 Address extension can specify how
DNS [13] may be updated. DNS [16] may be updated.
An IPv6 Address Extension can contain at most one IPv6 address. To An IPv6 Address Extension can contain at most one IPv6 address. To
specify more than one IPv6 address, multiple extensions are used. specify more than one IPv6 address, multiple extensions are used. To
ask for an IPv6 address in a DHCP Request message, a client includes
an IPv6 Address Extension. To renew or extend the lifetime of a
particular IPv6 address, the client puts that address in the client
address field. To request the allocation of a new but unspecified
IPv6 address, the client omits the client address field. The IPv6
address returned by the server in the latter case will be compatible
with a subnet prefix of the link to which the client is currently
attached.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pfx-size | error-code |C|L|Q|A|P| reserved | | pfx-size | error-code |C|L|Q|A|P| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| client address (16 octets) | | client address (16 octets) |
skipping to change at page 5, line 14 skipping to change at page 4, line 32
C If the 'C' bit is set, the field containing the IPv6 C If the 'C' bit is set, the field containing the IPv6
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 server MUST ensure that the A If the 'A' bit is set, the client requests that that
DNS is updated with a new AAAA record, as specified the the server updates DNS with a new AAAA record, as
by the client's FQDN, before responding with the specified by the client's FQDN.
corresponding DHCP Reply.
P If the 'P' bit is set, the server MUST ensure that the P If the 'P' bit is set, the client requests that that
DNS is updated with a new PTR record, as specified by the the the server updates DNS with a new PTR record, as
client's FQDN, before responding with the corresponding specified by the client's FQDN.
DHCP Reply.
reserved MUST be zero. reserved MUST be zero.
client address client address
The IPv6 address to be allocated by the server for use by The IPv6 address to be allocated by the server for use by
the client (16 octets long). the client (16 octets long).
preferred lifetime preferred lifetime
The preferred lifetime of the IPv6 address in seconds The preferred lifetime of the IPv6 address in seconds
skipping to change at page 6, line 5 skipping to change at page 5, line 16
to be used by the client (variable length). to be used by the client (variable length).
The DNS name can be a host name, which does not contain the '.' The DNS name can be a host name, which does not contain the '.'
ASCII character as a separator between DNS hierarchy components. Any ASCII character as a separator between DNS hierarchy components. Any
name containing the '.' is treated as a Fully Qualified Domain Name name containing the '.' is treated as a Fully Qualified Domain Name
(FQDN). The length of the DNS name may be determined by subtracting, (FQDN). The length of the DNS name may be determined by subtracting,
from the Length, the length of those fixed length fields which are from the Length, the length of those fixed length fields which are
present. If the last byte of the DNS name is not zero, the IPv6 present. If the last byte of the DNS name is not zero, the IPv6
Address Extension MUST be rejected, with error code 23. Address Extension MUST be rejected, with error code 23.
4.1. Client Considerations for the IPv6 Address extension 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
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
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
corresponding DHCP Reply.
4.1.1. Address Lifetimes 3.1. Client Considerations for the IPv6 Address extension
3.1.1. Address Lifetimes
An IPv6 address returned to a client has a preferred and valid An IPv6 address returned to a client has a preferred and valid
lifetime. The lifetimes represent the lease for addresses provided lifetime. The lifetimes represent the lease for addresses provided
to the client, from the server. to the client, from the server.
The DHCPv6 philosophy is that the client has the responsibility to The DHCPv6 philosophy is that the client has the responsibility to
make a new Request for an address that is about to expire, or request make a new Request for an address that is about to expire, or request
a new address or the same address before the lease actually expires. a new address or the same address before the lease actually expires.
If the client does not make a new Request for an address, the server If the client does not make a new Request for an address, the server
MUST assume the client does not want that address. The server MAY MUST assume the client does not want that address. The server MAY
provide that address to another client requesting an address. provide that address to another client requesting an address.
The client MAY request a value for the lifetimes returned by a The client MAY request a value for the lifetimes returned by a
server, but the client MUST use the lifetimes provided by the server server, but the client MUST use the lifetimes provided by the server
response. response.
When the preferred lifetime of an IPv6 address expires, the client's When the preferred lifetime of an IPv6 address expires, the client's
address becomes a deprecated address. See [4] for required handling address becomes a deprecated address. See [7] for required handling
of deprecated IPv6 addresses. When an address for a DHCPv6 client's of deprecated IPv6 addresses. When an address for a DHCPv6 client's
interface becomes deprecated, the processing of the lifetime SHOULD interface becomes deprecated, the client SHOULD request a new address
request a new address for that interface, or make a new DHCP Request for that interface, or make a new DHCP Request for the existing
for the existing address (which can result in the address receiving address (which can result in the address receiving an updated
an updated preferred lifetime). preferred lifetime).
When the client requests an IPv6 address from the DHCPv6 server, the When the client requests an IPv6 address from the DHCPv6 server, the
client MUST keep track of when the request was issued. When the client MUST keep track of when the request was issued. When the
client receives a successful reply from the DHCPv6 server, it MUST client receives a successful reply from the DHCPv6 server, it MUST
decrement the received Lifetimes by the amount of time between the decrement the received Lifetimes by the amount of time between the
transmission of the DHCP Request and the reception of the DHCP Reply. transmission of the DHCP Request and the reception of the DHCP Reply.
In this way, the client is best assured that its address lifetimes In this way, the client is best assured that its address lifetimes
will not expire at the DHCP Server before they expire at the client. will not expire at the DHCP Server before they expire at the client.
4.1.2. Use with the DHCP Request message 3.1.2. Use with the DHCP Request message
In a DHCP Request (for each address extension), a client may: In a DHCP Request (for each address extension), a client may:
- include an IPv6 address and/or DNS name and/or FQDN. - include an IPv6 address and/or a DNS name (which may be a host
name or a FQDN).
- request that server send updated AAAA and/or PTR records to the - set the 'A' bit to request that the server update DNS with a new
DNS. AAAA record, as specified by the client's FQDN; if the 'Q' bit is
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
PTR record, as specified by the client's FQDN; if the 'Q' bit is
also set, this update MUST be completed before responding with
the corresponding DHCP Reply.
- specify whether address and/or name and/or lifetime (if present) - specify whether address and/or name and/or lifetime (if present)
is advisory -or- mandatory; is advisory -or- mandatory;
- indicate the minimum preferred lifetime - indicate the minimum preferred lifetime
If the Request is advisory, a server may send different parameters If the Request is advisory, a server may send different parameters
than requested in the DHCP Reply. Otherwise, if the Request is than requested in the DHCP Reply. Otherwise, if the Request is
mandatory, the server must reject the Request if it cannot be mandatory, the server MUST reject the Request if it cannot be
fulfilled. fulfilled.
A client may include multiple IP Address extensions in a single DHCP A client may include multiple IP Address extensions in a single DHCP
Request. The server that receives the Request is not absolutely Request. The server that receives the Request is not absolutely
required to honor the client's Request. A DHCP client indicates that required to honor the client's Request. A DHCP client indicates that
it cannot accept anything other than the configuration information it cannot accept anything other than the configuration information
(e.g., IP address) listed in the IP Address extension to the DHCP (e.g., IP address) listed in the IP Address extension to the DHCP
Request, by specifying the 'Q' (Required) bit. Request, by specifying the 'Q' (Required) bit.
When a client requests an IP address, it MUST maintain a record for When a client requests an IP address, it MUST maintain a record for
the server which allocates that address, so that the client can (if the server which allocates that address, so that the client can (if
necessary) in the future necessary) in the future
- Renew 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.
4.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 error-code Reply which it accepts (see [4]), it first inspects the error-code
to see whether the requested information has been granted. If the to see whether the requested information has been granted. If the
error-code is nonzero, the client should log the error, display error-code is nonzero, the client should log the error, display
the error condition for action by the user and/or the network the error condition for action by the user and/or the network
administrator. Nonzero error-codes almost always indicate that the administrator. Nonzero error-codes almost always indicate that
client will be unable to use DHCP services until the client's request the client will be need to modify its request before it could be
can be modified, or until the DHCP server can be given updated satisfied by the replying DHCP server, or alternatively that the
configuration information for the client. replying DHCP server will need to be given 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) [11]; however, if the perform Duplicate Address Detection (DAD) [14]; however, if the
address has already been allocated to the client and it is merely address has already been allocated to the client and it is merely
renewing the lifetime of the address, the client does not have to renewing the lifetime of the address, the client does not have to
perform DAD each time. If the client receives a new IP address with perform DAD each time. If the client receives a new 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.
4.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):
- Client can include an IPv6 address and/or name and/or FQDN. - the client may include an IPv6 address and/or a DNS name (which
may be a host name or a FQDN).
- Server MUST update DNS to delete the AAAA record if the server - the server MUST update DNS to delete the AAAA record if the
originally updated DNS when the address was allocated to the server originally updated DNS when the address was allocated to
client. Likewise for the PTR record. the client, and likewise for the PTR record (regardless of the
setting of the 'A' or 'P' bits in the address extension).
- If the client, on the other hand, took charge of the DNS updates, - If the 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.
4.2. Server Considerations for the IPv6 Address extension 3.2. Server Considerations for the IPv6 Address extension
4.2.1. Use with the DHCP Advertise message 3.2.1. Use with the DHCP Advertise message
In DHCP Advertise (for each address extension), the Server can In DHCP Advertise (for each address extension), the Server can
indicate: indicate:
- the FQDN - the FQDN or host name
- the preferred lifetime - the preferred lifetime
- whether DNS will accept new names for the address (via the 'A' - whether DNS will accept new names for the address (via the 'A'
bit) bit)
4.2.2. Receiving a DHCP Request with the IPv6 Address Extension If the server sets the 'A' bit, it is willing to perform DNS updates
to AAAA or PTR records on behalf of the client.
3.2.2. Receiving a DHCP Request with the IPv6 Address Extension
If the client has requested that the server perform DNS updates as If the client has requested that the server perform DNS updates as
part of the IPv6 address allocation and configuration, the server part of the IPv6 address allocation and configuration, the server
must maintain this fact as part of the client's binding. Then, if MUST maintain this fact as part of the client's binding. Then, if
the client eventually releases the IPv6 address (by including an the client eventually releases the IPv6 address (by including an
appropriate IPv6 Address with the DHCP Release message), the server appropriate IPv6 Address with the DHCP Release message), the server
can perform the reverse service by updating DNS again as needed. can perform the reverse service by updating DNS again as needed.
4.2.3. Use with the DHCP Reply message 3.2.3. Use with the DHCP Reply message
In a DHCP Reply message (for each address extension) the server MUST In a DHCP Reply message (for each address extension) the server MUST
indicate indicate
- the preferred lifetime - the preferred lifetime
- the valid lifetime - the valid lifetime
- the status of the request - the status of the request
If the Reply is a response to a DHCP Release, the lifetimes MUST both If the Reply is a response to a DHCP Release, the lifetimes MUST both
be zero. be zero.
In a DHCP Reply message (for each address extension) the server MAY In a DHCP Reply message (for each address extension) the server MAY
indicate indicate
- the DNS name - the DNS name
- whether AAAA has been DNS updated (by setting the 'A' bit) - whether AAAA has been DNS updated (by setting the 'A' bit)
skipping to change at page 9, line 34 skipping to change at page 9, line 19
If the server receives a DHCP Request from one of its clients If the server receives a DHCP Request from one of its clients
whose address it wishes to invalidate, it can cause the client to whose address it wishes to invalidate, it can cause the client to
discontinue use of the old address by including valid and preferred discontinue use of the old address by including valid and preferred
lifetimes with a value of zero. lifetimes with a value of zero.
To perform renumbering, the server will include two IP address To perform renumbering, the server will include two IP address
extensions, one to invalidate the old address, and another to give extensions, one to invalidate the old address, and another to give
the client its new address. the client its new address.
4.2.4. Use with the DHCP Reconfigure message 3.2.4. Use with the DHCP Reconfigure message
In DHCP Reconfigure (for each address extension) the server MAY In DHCP Reconfigure (for each address extension) the server MAY
indicate the DNS name. indicate the DNS name.
4.3. DHCP Relay Considerations 3.2.5. Receiving a DHCP Release with the IPv6 Address Extension
When a DHCP client releases its IPv6 address, by including an
appropriate IPv6 Address Extension with the DHCP Release message, the
server determines whether or not it was originally responsible for
updating the DNS AAAA record or PTR record for the client. If so,
then the server must also perform the reverse service by updating DNS
again to delete the client records.
3.3. DHCP Relay Considerations
The DHCP Relay MUST NOT change any information in any DHCPv6 The DHCP Relay MUST NOT change any information in any DHCPv6
Extension fields. All Extension information flows between DHCPv6 Extension fields. All Extension information flows between DHCPv6
Server and DHCPv6 Client without modification by any Relay. Server and DHCPv6 Client without modification by any Relay.
5. General Extensions 4. General Extensions
The following extensions are important for many DHCPv6 clients, and The following extensions are important for many DHCPv6 clients, and
are not specific to any upper-level protocol. are not specific to any upper-level protocol.
5.1. Time Offset 4.1. Time Offset
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Offset | | Time Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for the time offset extension is 2, and its length is 4 The Type for the time offset extension is 2, and its length is 4
octets. The time offset field specifies the offset of the client's octets. The time offset field specifies the offset of the client's
subnet in seconds from Coordinated Universal Time (UTC). The offset subnet in seconds from Coordinated Universal Time (UTC). The offset
is expressed as a signed 32-bit integer. is expressed as a signed 32-bit integer.
5.2. Domain Name Server Extension 4.2. 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 (STD 13, RFC 1035 [8]) name servers available to the client. System [12] name servers available to the client. Servers SHOULD be
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.
5.3. Domain Name 4.3. Domain Name
This extension specifies the domain name that client should use when This extension specifies the domain name that client should use when
resolving hostnames via the Domain Name System. resolving hostnames via the Domain Name System.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name (variable length) ... | Domain Name (variable length) ...
skipping to change at page 11, line 28 skipping to change at page 11, line 28
The Type for this extension is 10. Its minimum length is 1. The Type for this extension is 10. Its minimum length is 1.
The domain name is a null-terminated ASCII string, length octets in The domain name is a null-terminated ASCII string, length octets in
size, including the terminating zero octet. size, including the terminating zero octet.
If the Domain Name extension is not specified, and the IPv6 Address If the Domain Name extension is not specified, and the IPv6 Address
extension received by a client contains a FQDN, then the client may extension received by a client contains a FQDN, then the client may
take the part of the FQDN after the first '.' octet as the Domain take the part of the FQDN after the first '.' octet as the Domain
Name. Name.
6. Service Location Extensions 5. Service Location Extensions
6.1. Directory Agent Extension Entities using the Service Location Protocol [15] need to find out
the address of Directory Agents in order to transact messages. In
certain other instances they may need to discover the correct scope
to be used in conjunction with the service attributes which are
exchanged using the Service Location Protocol. The scope MAY be
denoted in any standardized character set.
This extension specifies a Directory Agent (DA) [12], along with Note that each extension listed below MAY be included multiple times
zero or more scopes supported by that DA. A scope, in the Service in the same DHCP Request or DHCP Reply. If so, then the extensions
Location Protocol, is a way of restricting the accessibility of SHOULD be included in order of decreasing preference.
service entries (URLs) to User Agents or Service Agents who belong to
a particular class. For instance, in an academic institution, the
math department may decide to allow their Directory Agents to provide
service only for agents with the "math" scope.
The Type for this extension is 16. Each scope MUST be a 6. Directory Agent Extension
null-terminated string of ASCII octets. The lengths of the strings
(measured in octets) are only indicated implicitly by their null This extension requests or specifies a Directory Agent (DA), along
termination and the overall length of the extension. with zero or more scopes supported by that DA.
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 | scope count |D|M| reserved | | Char Encoding | DA length |D|M|F|S| rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | Directory Agent (variable length) ...
| Directory Agent address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scope list ... | (if present) Service Scope (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16 Code 16
Length (variable) The length of the Extension.
Character Encoding Length (variable) The length of the extension.
The characters making up strings within the remainder of
the message may be encoded in any standardized encoding
(see section 2.1).
D If the 'D' bit is set, the Directory Agent address is D If the 'D' bit is set, the Directory Agent field is
present. present.
F If the 'F' bit is set, the Directory Agent is indicated
by including its variable length host name or Fully
Qualified Domain Name (FQDN) instead of its 4 octet IP
address.
M If the 'M' bit is set, the Directory Agent address is M If the 'M' bit is set, the Directory Agent address is
the only one that may be used, and multicast methods for the only one that may be used, and multicast methods for
discovering Directory Agents MUST NOT be used. discovering Directory Agents MUST NOT be used.
scope count S If the 'S' bit is set, the scope is present, encoded in
The number of scopes indicated by strings in the scope the indicated character set.
list following.
scope list rsv reserved; ignored upon reception; MUST be sent as zero
A list of strings denoting scopes.
DA Length The length (in octets) of the Directory Agent field.
Directory Agent
The Fully Qualified Domain Name (FQDN), host name, or IP
address of the Directory Agent.
Char Encoding
The standardized encoding for the characters denoting the
scope.
Service Scope
The characters denoting the scope.
In order to simplify administration of the configuration of Directory
Agents for Service Location Protocol clients, the Directory Agent
can be indicated by presenting its FQDN or host name instead of its
IP address. This allows renumbering to proceed more smoothly [6].
When the FQDN or host name is used, the server sets the 'F' bit. The
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
of the Directory Agent field. When the 'F' bit is not set, the DA
Length MUST be 4.
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
lists of scopes. The client may request a Directory Agent with a scope. The client may request any Directory Agent with a particular
particular scope, by including the Directory Agent extension in a scope, by including the Directory Agent extension in a DHCP Request
DHCP Request message with no Directory Agent address included (the message with no Directory Agent address included (the 'D' bit set
'D' bit set to zero), and the appropriate strings in the scope list. to zero), and the characters denoting the scope. The length of the
scope is only indicated implicitly by the overall length of the
extension.
6.2. Service Scope Extension 7. Service Scope Extension
This extension indicates a scope that should be used by a Service
Agent (SA) [15], when responding to Service Request messages as
specified by the Service Location Protocol.
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 | scope ... | Char Encoding | Service Scope ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 17 Code 17
Length (variable) The length of the Extension.
Character Encoding Length (variable) The length of the extension.
The characters making up strings within the remainder of
the message may be encoded in any standardized encoding
(see section 2.1).
scope Scope is a zero-terminated string in the specified Char Encoding
character encoding, of length 'Length - 2' octets The standardized encoding for the characters denoting the
including the terminating zero octet. scope.
This extension indicates a scope that should be used by a Service Service Scope
Agent (SA) [12], when responding to Service Request messages as the characters denoting the scope.
specified by the Service Location Protocol.
7. IP Layer Parameters per Interface Note that more than one Service Scope extension may be present in a
DHCP message. The length of the scope is only indicated implicitly
by the overall length of the extension.
8. IP Layer Parameters per Interface
This section details the extensions that affect the operation of the This section details the extensions that affect the operation of the
IP layer on a per-interface basis. It is expected that a client can IP layer on a per-interface basis. It is expected that a client can
issue multiple requests, one per interface, in order to configure issue multiple requests, one per interface, in order to configure
interfaces with their specific parameters. interfaces with their specific parameters.
7.1. Static Route Extension 8.1. Static Route 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination address 1 | | Destination address 1 |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router address 1 | | Router address 1 |
skipping to change at page 14, line 14 skipping to change at page 14, line 50
destination are specified, they are listed in the order in which the destination are specified, they are listed in the order in which the
client should make use of them. client should make use of them.
The routes consist of a list of IP address pairs. The first address The routes consist of a list of IP address pairs. The first address
is the destination address, and the second address is the router for is the destination address, and the second address is the router for
the destination. the destination.
Link-local addresses are illegal destinations for a static route. Link-local addresses are illegal destinations for a static route.
The Type for this extension is 24. The minimum length of this The Type for this extension is 24. The minimum length of this
extension is 24, and the length MUST be a multiple of 32. extension is 32, and the length MUST be a multiple of 32.
8. TCP Parameters 9. 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.
8.1. TCP Keepalive Interval Extension 9.1. TCP Keepalive Interval Extension
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keepalive Time Interval | | Keepalive Time Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This extension specifies the interval (in seconds) that the This extension specifies the interval (in seconds) that the
client TCP should wait before sending a keepalive message on a TCP client TCP should wait before sending a keepalive message on a TCP
connection. The time is specified as a 32-bit unsigned integer. connection. The time is specified as a 32-bit unsigned integer.
A value of zero indicates that the client should not generate A value of zero indicates that the client should not generate
keepalive messages on connections unless specifically requested by an keepalive messages on connections unless specifically requested by an
application. application.
The Type for this extension is 32, and its length is 4. The Type for this extension is 32, and its length is 4.
9. Vendor Specific Information 10. Vendor Specific Information
This extension is used by clients and servers to exchange vendor- This extension is used by clients and servers to exchange vendor-
specific information. The information is an opaque object of n specific information. The information is an opaque collection of
octets, presumably interpreted by vendor-specific code on the clients data, presumably interpreted by vendor-specific code on the clients
and servers. The definition of this information is vendor specific. and servers. The definition of this information is vendor specific.
The vendor is indicated in the class-identifier extension. Servers The vendor is indicated in the class-identifier extension. Servers
not equipped to interpret the vendor-specific information sent by a not equipped to interpret the vendor-specific information sent by a
client MUST ignore it (although it may be reported). Clients which client MUST ignore it (although it may be reported). Clients which
do not receive desired vendor-specific information SHOULD make an do not receive desired vendor-specific information SHOULD make an
attempt to operate without it, although they may do so (and announce attempt to operate without it, although they may do so (and announce
they are doing so) in a degraded mode. they are doing so) in a degraded mode.
If a vendor potentially encodes more than one item of information in If a vendor encodes more than one item of information in this
this extension, then the vendor SHOULD encode the extension using extension, then the vendor MUST encode the extension using
"Encapsulated vendor-specific extensions" as described below: "Encapsulated vendor-specific extensions" as described below:
The Encapsulated vendor-specific extensions field SHOULD be encoded The Encapsulated vendor-specific extensions field MUST be encoded
as a sequence of type/length/value fields of identical syntax to the as a sequence of type/length/value fields of identical syntax to
DHCPv6 extensions field with the following exceptions: the fields defined in every other DHCPv6 extension. Extension
65535 (END), if present, signifies the end of the encapsulated
- Types other than 0 or 255 MAY be redefined by the vendor vendor extensions, not the end of the vendor extensions field.
within the encapsulated vendor-specific extensions field, but
SHOULD conform to the type-length-value syntax defined in
section 2.
- Code 255 (END), if present, signifies the end of the If no extension 65535 is present, then the end of the enclosing
encapsulated vendor extensions, not the end of the vendor vendor-specific information field is taken as the end of the
extensions field. If no code 255 is present, then the end of encapsulated vendor-specific extensions field.
the enclosing vendor-specific information field is taken as
the end of the encapsulated vendor-specific extensions field.
The Type for this extension is 40 and its minimum length is 1. The Type for this extension is 40 and its minimum Length is 4.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-specific information ... | Vendor-specific extension information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When encapsulated vendor-specific extensions are used, the When encapsulated vendor-specific extensions are used, each one has
information bytes 1-n have the following format: the same format as just shown. In other words, all vendor-specific
extensions are encoded in Type-Length-Value (TLV) format. More than
Type Len Data item Type Len Data item Type one vendor-specific extension can, therefore, be included in the same
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ DHCP "Vendor Specific Information" extension.
| T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
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.
10. DHCPv6 Extensions 11. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6. This section details the extensions that are specific to DHCPv6.
10.1. Maximum DHCPv6 Message Size Extension 11.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 SHOULD NOT use the extension in DHCP Solicit messages(see [4]),
and MUST NOT use the extension in other DHCP messages. and MUST NOT use the extension in other DHCP messages.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max DHCPv6 Message Length | | Max DHCPv6 Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type for this extension is 64, and its length is 2. The minimum The Type for this extension is 64, and its length is 2. The minimum
legal value is 1500. legal value is 1500.
10.2. Class Identifier 11.2. Class Identifier
This extension is used by a DHCP client to optionally identify the This extension is used by a DHCP client to optionally identify the
type or category of user or applications it represents. type or category of user or applications it represents.
DHCP administrators may define specific user class identifiers to DHCP administrators may define specific class identifiers to convey
convey information about a client's software configuration or about information about a client's software configuration or about its
its user's preferences. For example, an identifier may specify user's preferences. For example, an identifier may specify that
that a particular DHCP client is a member of the class "accounting a particular DHCP client is a member of the class "accounting
auditors", which have special service needs such as a particular auditors", which have special service needs such as a particular
database server. Alternatively, the identifier may encode the database server. Alternatively, the identifier may encode the
client's hardware configuration. client's hardware configuration.
Servers not equipped to interpret the user class specified by a Servers not equipped to interpret the class identifier specified by
client MUST ignore it (although it may be reported). Otherwise, a client MUST ignore it (although it may be reported). Otherwise,
servers SHOULD respond with the set of extensions corresponding to servers SHOULD respond with the set of extensions corresponding to
the user class specified by the client. Further, if the server the class identifier specified by the client. Further, if the server
responds with the set of extensions corresponding to the given user responds with the set of extensions corresponding to the given class
class, it MUST return this extension (with the given user class identifier, it MUST return this extension (with the given class
value) to the client. identifier value) to the client.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | Class Identifier ... | Char Encoding | Class Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The class identifier is a zero-terminated string of characters in the The class identifier is a zero-terminated string of characters in the
character set specified by the Char Encoding field (see section 2.1), character set specified by the Char Encoding field (see section 2.1),
of length 'n' octets including the terminating null octet. The class of length "Length"-2 octets including the terminating null octet.
identifier represents the user class of which the client is a member. The class identifier represents the class identifier of which the
client is a member.
10.3. Reconfigure Multicast Address 11.3. Reconfigure Multicast Address
A DHCPv6 server can instruct its clients to join a multicast group A DHCPv6 server can instruct its clients to join a multicast group
for the purposes of receiving DHCPv6 Reconfigure messages. This will for the purposes of receiving DHCPv6 Reconfigure messages. This will
allow a server to reconfigure all of its clients at once; such a allow a server to reconfigure all of its clients at once; such a
feature will be useful when renumbering becomes necessary. feature will be useful when renumbering becomes necessary.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reconfigure Multicast Address | | Reconfigure Multicast Address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the Reconfigure Multicast Address is 66, and the length The Type of the Reconfigure Multicast Address is 66, and the length
is 16. is 16.
10.4. Renumber DHCPv6 Server Address 11.4. Renumber DHCPv6 Server Address
A DHCPv6 server can instruct its clients to change their internal A DHCPv6 server can instruct its clients to change their internal
records to reflect the server's newly renumbered IPv6 address, by records to reflect the server's newly renumbered IPv6 address, by
using the "Renumber DHCPv6 Server Address" extension. This extension using the "Renumber DHCPv6 Server Address" extension. This extension
may be sent with the DHCP Reconfigure message, and thus can be may be sent with the DHCP Reconfigure message, and thus can be
multicast to all of the server's clients instead of being unicast to multicast to all of the server's clients instead of being unicast to
each one individually. each one 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.
10.5. Client-Server Authentication Extension 11.5. Client-Server Authentication Extension
Exactly one Client-Server Authentication Extension MAY be present Exactly one Client-Server Authentication Extension MAY be present
in any DHCPv6 message transmitted between a client and server (or in any DHCPv6 message transmitted between a client and server (or
vice-versa). If present, it MUST be the last extension, except vice-versa). If present, it MUST be the last extension.
possibly for the Pad extension 3.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | | Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Protection | | Replay Protection |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator (variable length) ... | Authenticator (variable length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 84 Type 84
Length 4 for the SPI, plus 8 for the replay protection, plus the Length 4 for the SPI, plus 8 for the replay protection, plus the
number of bytes in the Authenticator. number of bytes in the Authenticator.
SPI A Security Parameters index [2] identifying a security SPI A Security Parameters index [3] identifying a security
context between a pair of nodes among the contexts context between a pair of nodes among the contexts
available in the security association defined between available in the security association defined between
the DHCPv6 client and server. SPI values 0 through 255 the DHCPv6 client and server. SPI values 0 through 255
are reserved and, if used, MUST conform to the security are reserved and, if used, MUST conform to the security
context defined by that value as defined in the most context defined by that value as defined in the most
recent Assigned Numbers RFC (e.g., [5]). recent Assigned Numbers RFC (e.g., [8]).
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [7](NTP) A 64-bit timestamp (in Network Time Protocol [11](NTP)
format) (see section 11.1). format) (see section 13.1).
Authenticator Authenticator
(variable length) (See Section 11.2.) (variable length) (See Section 13.2.)
This authentication extension remedies the inability of IPsec to This authentication extension remedies the inability of IPsec to
provide for non end-to-end authentication, since authentication is provide for non end-to-end authentication, since authentication is
needed even when the client needs has no valid IPv6 address. The needed even when the client needs has no valid IPv6 address. The
extension can be originated by either the DHCPv6 Client or DHCPv6 extension can be originated by either the DHCPv6 Client or DHCPv6
server to authenticate the rest of the data in the DHCPv6 message. server to authenticate the rest of the data in the DHCPv6 message.
The default authentication algorithm is defined in section 11.2. The default authentication algorithm is defined in section 13.2.
11. Security Considerations 11.6. Client Key Selection Extension
A DHCPv6 server may wish to indicate to a prospective client which
SPI it must use to authenticate subsequent messages, using the
Client-Server Authentication Extension. In such cases, the server
includes the Client Key Selection Extension in its DHCP Advertise
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 85
Length 4
SPI A Security Parameters index [3] identifying a security
context between a pair of nodes among the contexts
available in the security association defined between
the DHCPv6 client and server. SPI values 0 through 255
are reserved and, if used, MUST conform to the security
context defined by that value as defined in the most
recent Assigned Numbers RFC (e.g., [8]).
12. End extension specification
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
octets; there is no Length field for the end extension.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13. 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 10.5. for users of the Client-Server Authentication extension 11.5.
11.1. Replay Protection 13.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [7](NTP) format, is A 64-bit timestamp, in Network Time Protocol [11](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.
11.2. Default Authentication Algorithm 13.2. Default Authentication Algorithm
The default authentication algorithm is HMAC [6], using The default authentication algorithm is HMAC [10], using
keyed-MD5 [10]. Given a secret key K, and "data" the information to keyed-MD5 [13]. Given a secret key K, and "data" the information to
be authenticated, HMAC_result is computed as follows: be authenticated, HMAC_result is computed as follows:
1. opad := 0x36363636363636363636363636363636 (128 bits) 1. opad := 0x36363636363636363636363636363636 (128 bits)
2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
3. zero_extended_key := K extended by zeroes to be 128 bits long 3. zero_extended_key := K extended by zeroes to be 128 bits long
4. opadded_key := zero_extended_key XOR opad 4. opadded_key := zero_extended_key XOR opad
5. ipadded_key := zero_extended_key XOR ipad 5. ipadded_key := zero_extended_key XOR ipad
6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))
The key K is the shared secret defined by the security association The key K is the shared secret defined by the security association
between the client and server and by the SPI value specified in between the client and server and by the SPI value specified in
the Authentication Extension. The "data" is the stream of bytes the Authentication Extension. The "data" is the stream of bytes
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 20, line 16 skipping to change at page 21, line 42
5. ipadded_key := zero_extended_key XOR ipad 5. ipadded_key := zero_extended_key XOR ipad
6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))
The key K is the shared secret defined by the security association The key K is the shared secret defined by the security association
between the client and server and by the SPI value specified in between the client and server and by the SPI value specified in
the Authentication Extension. The "data" is the stream of bytes the Authentication Extension. The "data" is the stream of bytes
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.
12. New Extensions 14. Defining New Extensions
Additional extensions may be registered by contacting: Implementation specific use of undefined extensions (including those
in the range 86-32767) may conflict with other implementations, and
registration is required.
The author of a new DHCP option MUST follow these steps to obtain
acceptance of the option as a part of the DHCP Internet Standard:
1. The author devises the new option.
2. The author requests a number for the new option from IANA by
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
Implementation specific use of undefined extensions (including those 3. The author documents the new option, using the newly obtained
in the range 85-32767) may conflict with other implementations, and option number, as an Internet Draft.
registration is required.
13. Acknowledgements 4. The author submits the Internet Draft for review through the
IETF standards process as defined in "Internet Official Protocol
Standards" [9]. The new option will be submitted for eventual
acceptance as an Internet Standard.
Thanks to Jim Bound for his frequent review, helpful suggestions, 5. The new option progresses through the IETF standards process; the
and design assistance. The original form of this internet draft was new option will be reviewed by the Dynamic Host Configuration
copied directly from RFC1533 [1], written by Steve Alexander and Working Group (if that group still exists), or as an Internet
Ralph Droms, to whom thanks are again due. Draft not submitted by an IETF working group.
6. If the new option fails to gain acceptance as an Internet
Standard, the assigned option number will be returned to IANA for
reassignment.
This procedure for defining new extensions will ensure that:
* allocation of new option numbers is coordinated from a single
authority,
* new options are reviewed for technical correctness and
appropriateness, and
* documentation for new options is complete and published.
15. Acknowledgements
Thanks to Jim Bound for his frequent review, helpful suggestions, and
design assistance. Ralph Droms has also made many, many suggestions
which have been incorporated into this draft. The original form of
this internet draft was copied directly from RFC1533 [1], written
by Steve Alexander and Ralph Droms. Thanks to Erik Guttman for his
helpful suggestions for the Service Location extensions.
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] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 2132, March 1997.
[3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol [3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
for IPv6. draft-ietf-dhc-dhcpv6-09.txt, February 1997. (work
in progress).
[4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
for IPv6. draft-ietf-dhc-dhcpv6-10.txt, May 1997. (work in
progress).
[5] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
[6] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900,
February 1996.
[7] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic [8] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994. Routing Encapsulation (GRE). RFC 1701, October 1994.
[6] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing [9] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1,
February 1997.
[10] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing
for Message Authentication. RFC 2104, February 1997. for Message Authentication. RFC 2104, February 1997.
[7] David L. Mills. Network Time Protocol (Version 3): [11] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[8] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND [12] P. Mockapetris. Domain Names - Concepts and Facilities. STD
SPECIFICATION. RFC 1035, November 1987. 13, November 1987.
[9] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497,
August 1993.
[10] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [13] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[11] S. Thomson and T. Narten. IPv6 stateless address [14] S. Thomson and T. Narten. IPv6 stateless address
autoconfiguration. RFC 1971, August 1996. autoconfiguration. RFC 1971, August 1996.
[12] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. draft-ietf-svrloc-protocol-15.txt, November Location Protocol, April 1997. draft-ietf-svrloc-protocol-17.txt
1996. (work in progress). (work in progress).
[13] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. [16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
Dynamic Updates in the Domain Name System (DNS). in the Domain Name System (DNS). RFC 2136, April 1997.
draft-ietf-dnsind-dynDNS-11.txt, November 1996. (work
in progress).
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
 End of changes. 

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