draft-ietf-dhc-v6exts-01.txt   draft-ietf-dhc-v6exts-02.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM INTERNET DRAFT IBM
12 June 1996 27 August 1996
Extensions for DHCPv6 Extensions for DHCPv6
draft-ietf-dhc-v6exts-01.txt draft-ietf-dhc-v6exts-02.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
skipping to change at page 1, line 36 skipping to change at page 1, line 35
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 the
``1id-abstracts.txt'' listing contained in the Internet- Drafts ``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 (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). 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 tagged data items that are stored in the information are carried in tagged 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 62 skipping to change at page 1, line 61
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. DHCPv6 Extension Field Format 1 2. DHCPv6 Extension Field Format 1
3. Padding and End extension specifications 2 3. Padding and End extension specifications 2
3.1. Pad Extension . . . . . . . . . . . . . . . . . . . . . . 2 3.1. Pad Extension . . . . . . . . . . . . . . . . . . . . . . 2
3.2. End Extension . . . . . . . . . . . . . . . . . . . . . . 2 3.2. End Extension . . . . . . . . . . . . . . . . . . . . . . 2
4. IPv6 Address extension specification 2 4. IPv6 Address Extension 2
4.1. Client Considerations for the IPv6 Address extension . . 4 4.1. Client Considerations for the IPv6 Address extension . . 4
4.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 4 4.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 4
4.1.2. Use with the DHCP Request message . . . . . . . . 5 4.1.2. Use with the DHCP Request message . . . . . . . . 5
4.1.3. Use with the DHCP Release message . . . . . . . . 6 4.1.3. Use with the DHCP Release message . . . . . . . . 6
4.2. Server Considerations for the IPv6 Address extension . . 6 4.2. Server Considerations for the IPv6 Address extension . . 6
4.2.1. Use with the DHCP Advertise message . . . . . . . 6 4.2.1. Use with the DHCP Advertise message . . . . . . . 6
4.2.2. Receiving a DHCP Request with the IPv6 Address 4.2.2. Receiving a DHCP Request with the IPv6 Address
Extension . . . . . . . . . . . . . . . . 7 Extension . . . . . . . . . . . . . . . . 6
4.2.3. Use with the DHCP Reply message . . . . . . . . . 7 4.2.3. Use with the DHCP Reply message . . . . . . . . . 7
4.2.4. Use with the DHCP Reconfigure message . . . . . . 7 4.2.4. Use with the DHCP Reconfigure message . . . . . . 7
4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 8 4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 7
5. General Extensions 8 5. General Extensions 8
5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Domain Name Server Extension . . . . . . . . . . . . . . 8 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 8
5.3. Directory Agent Extension . . . . . . . . . . . . . . . . 8 5.3. Directory Agent Extension . . . . . . . . . . . . . . . . 8
5.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Service Scope Extension . . . . . . . . . . . . . . . . . 10
5.5. Naming Authority Extension . . . . . . . . . . . . . . . 10
5.6. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 10
6. IP Layer Parameters per Interface 9 6. IP Layer Parameters per Interface 11
6.1. Static Route Extension . . . . . . . . . . . . . . . . . 9 6.1. Static Route Extension . . . . . . . . . . . . . . . . . 11
7. TCP Parameters 10 7. TCP Parameters 11
7.1. TCP Default TTL Extension . . . . . . . . . . . . . . . . 10 7.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 11
7.2. TCP Keepalive Interval Extension . . . . . . . . . . . . 10
8. Vendor Specific Information 11 8. Vendor Specific Information 12
9. DHCPv6 Extensions 12 9. DHCPv6 Extensions 13
9.1. Maximum DHCPv6 Message Size . . . . . . . . . . . . . . . 12 9.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 13
9.2. Class-identifier . . . . . . . . . . . . . . . . . . . . 12 9.2. Class-identifier . . . . . . . . . . . . . . . . . . . . 13
9.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 12 9.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 14
9.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 13 9.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 14
9.5. Client-Server Authentication Extension . . . . . . . . . 13 9.5. Client-Server Authentication Extension . . . . . . . . . 14
10. Security Considerations 14 10. Security Considerations 15
10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 14 10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 15
10.2. Default Authentication Algorithm . . . . . . . . . . . . 14 10.2. Default Authentication Algorithm . . . . . . . . . . . . 15
11. New Extensions 15 11. New Extensions 16
12. Acknowledgements 15 12. Acknowledgements 16
Chair's Address 17 Chair's Address 18
Author's Address 17 Author's Address 18
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].
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 11. Information on registering new extensions is contained in section 11.
Although extension numbers in this document correspond closely to the Although extension numbers in this document correspond closely to the
analogous numbers in the options specification for IPv4 [1], there is analogous numbers in the options specification for IPv4 [1], there is
no requirement to keep numbering future extensions in any consistent no requirement to keep numbering future extensions in any consistent
manner except purely as a matter of editorial and cross-referencing manner except purely as a matter of editorial and cross-referencing
convenience. convenience.
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 [9], and not will be satisfied by the Service Location Protocol [12], 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 [7]. Extensions may be fixed length extensions" defined in RFC 1497 [10]. Extensions may be fixed length
or variable length. All extensions begin with a tag octet, which or variable length. All extensions begin with a tag octet, which
uniquely identifies the extension. Fixed-length extensions without uniquely identifies the extension. Fixed-length extensions without
data consist of only a tag octet. Only extensions 0 and 255 are data consist of only a tag octet. Only extensions 0 and 255 are
fixed length. All other extensions are variable-length with a length fixed length. All other extensions are variable-length with a length
octet following the tag octet. The value of the length octet does octet following the tag octet. The value of the length octet does
not include the two octets specifying the tag and length. The length not include the two octets specifying the tag and length. The length
octet is followed by "length" octets of data. In the case of some octet is followed by "length" octets of data. In the case of some
variable-length extensions the length field is a constant but must variable-length extensions the length field is a constant but must
still be specified. still be specified.
Any extensions defined subsequent to this document should contain a Any extensions defined subsequent to this document should contain a
length octet even if the length is fixed or zero. length octet even if the length is fixed or zero. Unknown options
MAY be skipped by ignoring the number of bytes specified in the
All multi-octet quantities are in network byte-order. length octet. All multi-octet quantities are in network byte-order.
Extension codes 128 to 254 (decimal) are reserved for site-specific Extension codes 128 to 254 (decimal) are reserved for site-specific
extensions. 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.
DISCUSSION: Should the DHCPv6 Extensions be put into a format DISCUSSION: Should the DHCPv6 Extensions be put into a format
similar to IPv6 options? similar to IPv6 options?
skipping to change at page 2, line 45 skipping to change at page 2, line 45
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. Subsequent octets should be filled with pad extensions. field. Subsequent octets should be filled with pad extensions.
The code for the end extension is 255, and its length is 1 octet. The code for the end extension is 255, and its length is 1 octet.
Code Code
+-----+ +-----+
| 255 | | 255 |
+-----+ +-----+
4. IPv6 Address extension specification 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 is relatively complex and and can be used by both extensions. It is relatively complex and and can be used by both
client and server in various ways. Since the IPv6 Address option client and server in various ways. Since the IPv6 Address option
can be used more than once in the same DHCP message, all information can be used more than once in the same DHCP message, all information
relevant to a particular IPv6 allocation has to be collected together relevant to a particular IPv6 allocation has to be collected together
in the same extension, hence the added complexity. Much of this in the same extension, hence the added complexity. Some of this
added complexity also derives from various possible ways that added complexity also derives from various possible ways that
updating DNS may be specified within the IPv6 Address extension. updating DNS may be specified within the IPv6 Address extension.
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ext-type | ext-length |C|L|D|Q|A|P| rsv | pfx-size | | ext-type | ext-length |C|L|Q|A|P| rsv | pfx-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| client address (16 octets) | | client address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) preferred lifetime (4 octets) | | (if present) preferred lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) valid lifetime (4 octets) | | (if present) valid lifetime (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) DNS name (variable length) ...
| DNS name (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ext-type 1 ext-type 1
ext-length ext-length
The length of the Extension. The length of the Extension.
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.
D If the 'D' bit is set, Duplicate Address Detection is not
required.
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 server MUST ensure that the
DNS is updated with a new AAAA record, as specified DNS is updated with a new AAAA record, as specified
by the client's FQDN, before responding with the by the client's FQDN, before responding with the
corresponding DHCP Reply. corresponding DHCP Reply.
P If the 'P' bit is set, the server MUST ensure that the P If the 'P' bit is set, the server MUST ensure that the
skipping to change at page 4, line 26 skipping to change at page 4, line 21
applied to the client's IPv6 address to get the routing applied to the client's IPv6 address to get the routing
prefix. Otherwise, if the 'C' bit is not set, pfx-size prefix. Otherwise, if the 'C' bit is not set, pfx-size
MUST be zero. NOTE: the pfx-size field is only 7 bits MUST be zero. NOTE: the pfx-size field is only 7 bits
long. long.
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 The preferred lifetime of the IPv6 address in seconds
valid lifetime valid lifetime
The valid lifetime of the IPv6 address The valid lifetime of the IPv6 address in seconds
DNS name DNS name
The DNS name (a zero-terminated character string) to be The DNS name (a zero-terminated character string) to be
used by the client (variable length). 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 '.'
character as a separator between DNS hierarchy components. Any name character as a separator between DNS hierarchy components. Any name
containing the '.' is treated as a Fully Qualified Domain 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 ext-length, the length of those fixed-length fields which from the ext-length, the length of those fixed-length fields which
skipping to change at page 5, line 10 skipping to change at page 4, line 51
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, after provide that address to another client requesting an address.
all other addresses available to the server have been exhausted.
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 [5] 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 processing of the lifetime SHOULD
request a new address for that interface, or make a new DHCP Request request a new address for that interface, or make a new DHCP Request
for the existing address (which can result in the address receiving for the existing address (which can result in the address receiving
an updated preferred lifetime). an updated 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
skipping to change at page 5, line 42 skipping to change at page 5, line 34
4.1.2. Use with the DHCP Request message 4.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 DNS name and/or FQDN.
- request that server send updated AAAA and/or PTR records to the - request that server send updated AAAA and/or PTR records to the
DNS. DNS.
- specify whether address and/or name (if present) is advisory -or- - specify whether address and/or name and/or lifetime (if present)
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 required to honor the client's Request. A DHCP client indicates that
that it cannot accept anything other than the address listed in the it cannot accept anything other than the configuration information
IP Address extension to the DHCP Request, by specifying the 'Q' (e.g., IP address) listed in the IP Address extension to the DHCP
(Required) bit. Request, by specifying the 'Q' (Required) bit.
When a client requests an IPv6 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 - Renew the lifetime with the same server, or
- Release the address using DHCP Release. - Release the address, using DHCP Release.
Upon reception of a new IP address, the client must perform Duplicate
Address Detection (DAD) [9]; however, if the address has already been
allocated to the client and it is merely renewing the lifetime of the
address, the client does not have to perform DAD each time.
4.1.3. Use with the DHCP Release message 4.1.3. 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. - Client can include an IPv6 address and/or name and/or FQDN.
- Server MUST update DNS to delete the AAAA record if the server - Server MUST update DNS to delete the AAAA record if the server
originally updated DNS when the address was allocated to the originally updated DNS when the address was allocated to the
client. Likewise for the PTR record. client. Likewise for the PTR record.
skipping to change at page 7, line 44 skipping to change at page 7, line 39
If the client requests updates, and sets the 'Q' bit, the server MUST If the client requests updates, and sets the 'Q' bit, the server MUST
NOT issue the DHCP Reply until after receiving positive indication NOT issue the DHCP Reply until after receiving positive indication
that the DNS update has indeed been performed. that the DNS update has indeed been performed.
Subsequently, the client can update DNS if needed (i.e., the server Subsequently, the client can update DNS if needed (i.e., the server
didn't do it). didn't do it).
4.2.4. Use with the DHCP Reconfigure message 4.2.4. Use with the DHCP Reconfigure message
In DHCP Reconfigure (for each address extension) the server can In DHCP Reconfigure (for each address extension) the server MAY
indicate indicate the DNS name.
- the DNS name
4.3. DHCP Relay Considerations 4.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 5. General Extensions
The following extensions are important for many DHCPv6 clients, and The following extensions are important for many DHCPv6 clients, and
skipping to change at page 8, line 33 skipping to change at page 8, line 27
octets. octets.
Code Len Time Offset Code Len Time Offset
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| 2 | 4 | n1 | n2 | n3 | n4 | | 2 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
5.2. Domain Name Server Extension 5.2. Domain Name Server Extension
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 [6]) name servers available to the client. System (STD 13, RFC 1035 [8]) name servers available to the client.
Servers SHOULD be listed in order of preference. Servers SHOULD be listed in order of preference.
The code for the domain name server extension is 6. The minimum The code 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.
Code Len Address 1 Address 2 Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 6 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... | 6 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
5.3. Directory Agent Extension 5.3. Directory Agent Extension
This extension specifies a list of Directory Agent [9] available to This extension specifies a Directory Agent (DA) [12], along with zero
the client. Servers SHOULD be listed in order of preference. or more Naming Authorities [6] known to that DA and zero or more
scopes supported by that DA.
The code for this extension is 11. The minimum length for this The code for this extension is 11. Each Naming Authority and each
extension is 16 octets, and the length MUST always be a multiple of scope MUST be a null-terminated string of ASCII characters. The
16. lengths of the strings are only indicated implicitly by their null
termination and the overall length of the extension.
Code Len Address 1 Address 2 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
| 11 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- | Code | Length |D| NA count | scope count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| Directory Agent address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NA list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scope list ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4. Domain Name Code 11
Length variable
D If the 'D' bit is set, the Directory Agent address is
present.
NA count
The number of Naming Authorities indicated by strings in
the NA list following.
scope count
The number of scopes indicated by strings in the NA list
following.
NA list
A list of strings denoting Naming Authorities.
scope list
A list of strings denoting scopes.
Note that more than one Directory Agent extension may be present in
a DHCP message. Each such extension may have the same or different
lists of Naming Authorities and scopes. The client may request a
Directory Agent with a particular scope, and/or knowledgeable about
schemes defined by a particular Naming Authority, by including the
Directory Agent extension in a DHCP Request message with no Directory
Agent address included (the 'D' bit set to zero), and the appropriate
strings in the NA list and/or scope list.
5.4. Service Scope Extension
This extension indicates a scope that should be used by a Service
Agent (SA) [12], when responding to Service Request messages as
specified by the Service Location Protocol.
Code Len
+-----+-----+-----+-----
| 12 | n | Scope ...
+-----+-----+-----+-----
Scope is a null-terminated ASCII string, of length 'n' including the
terminating null character.
5.5. Naming Authority Extension
This extension indicates a naming authority (which specifies the
syntax for schemes that may be used in URLs [3]) for use by entities
with the Service Location Protocol.
Code Len
+-----+-----+-----+-----+-----+-----
| 13 | n | Naming Authority ...
+-----+-----+-----+-----+-----+-----
Naming Authority is a null-terminated ASCII string, of length 'n'
including the terminating null character.
5.6. 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.
The code for this extension is 15. Its minimum length is 1. The code for this extension is 15. Its minimum length is 1.
Code Len Domain Name Code Len Domain Name
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
| 15 | n | d1 | d2 | d3 | d4 | ... | 15 | n | d1 | d2 | d3 | d4 | ...
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
skipping to change at page 10, line 22 skipping to change at page 11, line 42
Destination 2 Router 2 Destination 2 Router 2
+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+-----+---
| d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ... | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+-----+---
7. TCP Parameters 7. 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.
7.1. TCP Default TTL Extension 7.1. TCP Keepalive Interval Extension
This extension specifies the default TTL that the client should use
when sending TCP segments. The value is represented as an 8-bit
unsigned integer. The minimum value is 1.
The code for this extension is 37, and its length is 1.
Code Len TTL
+-----+-----+-----+
| 37 | 1 | n |
+-----+-----+-----+
7.2. TCP Keepalive Interval Extension
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 code for this extension is 38, and its length is 4. The code for this extension is 38, and its length is 4.
skipping to change at page 12, line 9 skipping to change at page 13, line 16
Code Len Data item Code Len Data item Code Code Len Data item Code Len Data item Code
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
9. DHCPv6 Extensions 9. DHCPv6 Extensions
This section details the extensions that are specific to DHCPv6. This section details the extensions that are specific to DHCPv6.
9.1. Maximum DHCPv6 Message Size 9.1. Maximum DHCPv6 Message Size Extension
This extension specifies the maximum length DHCPv6 message that it This extension specifies the maximum length in octets of any DHCPv6
is willing to accept. The length is specified as an unsigned 16-bit message that the sender of the extension is willing to accept. The
integer. A client may use the maximum DHCPv6 message size extension length is specified as an unsigned 16-bit integer. A client may use
in DHCP Request messages, but SHOULD NOT use the extension in DHCP the maximum DHCPv6 message size extension in DHCP Request messages,
Solicit messages(see [3]), and MUST NOT use the extension in other but SHOULD NOT use the extension in DHCP Solicit messages(see [4]),
DHCP messages. and MUST NOT use the extension in other DHCP messages.
The code for this extension is 57, and its length is 2. The minimum The code for this extension is 57, and its length is 2. The minimum
legal value is 1500 octets. legal value is 1500.
Code Len Length Code Len Length
+-----+-----+-----+-----+ +-----+-----+-----+-----+
| 57 | 2 | l1 | l2 | | 57 | 2 | l1 | l2 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
9.2. Class-identifier 9.2. Class-identifier
This extension may be used by DHCPv6 clients to identify the type and This extension may be used by DHCPv6 clients to identify their
configuration of a DHCPv6 client. The information is a string of type and configuration. The information is a string of n octets,
n octets, interpreted by servers. Vendors and sites may choose to interpreted by servers. Vendors and sites may choose to define
define specific class identifiers to convey particular configuration specific class identifiers to convey particular configuration or
or other identification information about a client. For example, the other identification information about a client. For example, the
identifier may encode the client's hardware configuration. Servers identifier may encode the client's hardware configuration. Servers
not equipped to interpret the class-specific information sent by a not equipped to interpret the class-specific information sent by
client MUST ignore it (although it may be reported). a client MUST ignore it (although it may be reported for system
management purposes).
The code for this extension is 60, and its minimum length is 1. The code for this extension is 60, and its minimum length is 1.
Code Len Class-Identifier Code Len Class-Identifier
+-----+-----+-----+-----+--- +-----+-----+-----+-----+---
| 60 | n | i1 | i2 | ... | 60 | n | i1 | i2 | ...
+-----+-----+-----+-----+--- +-----+-----+-----+-----+---
9.3. Reconfigure Multicast Address 9.3. Reconfigure Multicast Address
skipping to change at page 13, line 32 skipping to change at page 14, line 41
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
9.5. Client-Server Authentication Extension 9.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 in any DHCPv6 message transmitted between a client and server
(or vice-versa). If present, it MUST be placed after every other (or vice-versa). If present, it MUST be placed after every other
extension. extension.
Code Len Security Parameter ndx replay protect Code Len Security Parameter ndx replay protect
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+------+-----+-----+-----+-----+-----+-----+-----+-----+---
| 71 | 4+x | sp1 | sp2 | sp3 | sp4 | rp1 | ... | rp8 | Auth ... | 84 | 12+x | sp1 | sp2 | sp3 | sp4 | rp1 | ... | rp8 | Auth ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+------+-----+-----+-----+-----+-----+-----+-----+-----+---
Type 71 Type 84
Length 4 for the SPI, plus the number of bytes in the Length 4 for the SPI, plus 8 for the replay protection, plus the
Authenticator. number of bytes in the Authenticator.
SPI A Security Parameters index [2] identifying a security SPI A Security Parameters index [2] identifying a security
context between a pair of nodes among the contexts context between a pair of nodes among the contexts
available in the security association defined between available in the security association defined between
the DHCPv6 client and server. SPI values 0 through 255 the DHCPv6 client and server. SPI values 0 through 255
are reserved and MUST NOT be used in any Client-Server are reserved and MUST NOT be used in any Client-Server
Authentication Extension. Authentication Extension.
Replay Protection Replay Protection
A 64-bit timestamp (in Network Time Protocol [5](NTP) A 64-bit timestamp (in Network Time Protocol [7](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 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.
skipping to change at page 14, line 25 skipping to change at page 15, line 36
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 9.5. for users of the Client-Server Authentication extension 9.5.
10.1. Replay Protection 10.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [5](NTP) format, is A 64-bit timestamp, in Network Time Protocol [7](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 uses keyed-MD5 [8] in The default authentication algorithm uses keyed-MD5 [11] in
"prefix+suffix" mode to compute a 128-bit "message digest" of the "prefix+suffix" mode to compute a 128-bit "message digest" of the
registration message. The default authenticator is a 128-bit value registration message. The default authenticator is a 128-bit value
computed as the MD5 checksum over the the following stream of bytes: computed as the MD5 checksum over the the following stream of bytes:
- the shared secret defined by the security association between - the shared secret defined by the security association between
the client and server and by the SPI value specified in the the client and server and by the SPI value specified in the
Authentication Extension, followed by Authentication Extension, followed by
- all previous fields in the DHCPv6 message and extensions, - all previous fields in the DHCPv6 message and extensions,
followed by followed by
skipping to change at page 16, line 12 skipping to change at page 17, line 12
copied directly from RFC1533 [1], written by Steve Alexander and copied directly from RFC1533 [1], written by Steve Alexander and
Ralph Droms, to whom thanks are again due. Ralph Droms, to whom thanks are again due.
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993. Extensions. RFC 1533, October 1993.
[2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [2] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for [3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource
IPv6. draft-ietf-dhc-dhcpv6-04.txt -- work in progress, February Locators (URL). RFC 1738, December 1994.
1996.
[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-05.txt -- work in progress,
June 1996.
[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[5] David L. Mills. Network Time Protocol (Version 3): [6] Paul E. Hoffman and Ron Daniel, Jr. Generic URN Syntax.
draft-ietf-uri-urn-syntax-00.txt -- work in progress, April
1995.
[7] David L. Mills. Network Time Protocol (Version 3):
Specification, Implementation and Analysis. RFC 1305, March Specification, Implementation and Analysis. RFC 1305, March
1992. 1992.
[6] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. [8] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND
RFC 1035, November 1987. SPECIFICATION. RFC 1035, November 1987.
[7] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, [9] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). draft-ietf-ipngwg-discovery-06.txt -- work
in progress, March 1996.
[10] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497,
August 1993. August 1993.
[8] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, [11] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
April 1992. April 1992.
[9] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service [12] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. draft-ietf-svrloc-protocol-13.txt - work in Location Protocol. draft-ietf-svrloc-protocol-14.txt - work in
progress, June 1996. progress, June 1996.
Chair's Addresses Chair's Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Ralph Droms Ralph Droms
Computer Science Department Computer Science Department
323 Dana Engineering 323 Dana Engineering
Bucknell University Bucknell University
 End of changes. 

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