draft-ietf-dhc-v6exts-00.txt   draft-ietf-dhc-v6exts-01.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM INTERNET DRAFT IBM
22 February 1996 12 June 1996
Extensions for DHCPv6 Extensions for DHCPv6
draft-ietf-dhc-v6exts-00.txt draft-ietf-dhc-v6exts-01.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 69 skipping to change at page 1, line 69
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 specification 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.3. Receiving a DHCP Request with the IPv6 Address Extension 6 4.2.2. Receiving a DHCP Request with the IPv6 Address
4.3.1. Use with the DHCP Reply message . . . . . . . . . 6 Extension . . . . . . . . . . . . . . . . 7
4.3.2. Use with the DHCP Reconfigure message . . . . . . 7 4.2.3. Use with the DHCP Reply message . . . . . . . . . 7
4.4. DHCP Relay Considerations . . . . . . . . . . . . . . . . 7 4.2.4. Use with the DHCP Reconfigure message . . . . . . 7
4.5. Alternate Design possibility . . . . . . . . . . . . . . 7 4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 8
5. General Extensions 8 5. General Extensions 8
5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Router Extension . . . . . . . . . . . . . . . . . . . . 8 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 8
5.3. Domain Name Server Extension . . . . . . . . . . . . . . 9 5.3. Directory Agent Extension . . . . . . . . . . . . . . . . 8
5.4. Resource Location Server Extension . . . . . . . . . . . 9 5.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 9
6. IP Layer Parameters per Interface 10 6. IP Layer Parameters per Interface 9
6.1. Static Route Extension . . . . . . . . . . . . . . . . . 10 6.1. Static Route Extension . . . . . . . . . . . . . . . . . 9
7. TCP Parameters 10 7. TCP Parameters 10
7.1. TCP Default TTL Extension . . . . . . . . . . . . . . . . 10 7.1. TCP Default TTL Extension . . . . . . . . . . . . . . . . 10
7.2. TCP Keepalive Interval Extension . . . . . . . . . . . . 11 7.2. TCP Keepalive Interval Extension . . . . . . . . . . . . 10
8. Vendor Specific Information 11 8. Vendor Specific Information 11
9. DHCPv6 Extensions 12 9. DHCPv6 Extensions 12
9.1. Maximum DHCPv6 Message Size . . . . . . . . . . . . . . . 12 9.1. Maximum DHCPv6 Message Size . . . . . . . . . . . . . . . 12
9.2. Class-identifier . . . . . . . . . . . . . . . . . . . . 13 9.2. Class-identifier . . . . . . . . . . . . . . . . . . . . 12
9.3. Mobile Home Address Extension . . . . . . . . . . . . . . 13 9.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 12
9.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 13
10. Neighbor Discovery Extensions 14 9.5. Client-Server Authentication Extension . . . . . . . . . 13
11. Extensions 14 10. Security Considerations 14
10.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 14
10.2. Default Authentication Algorithm . . . . . . . . . . . . 14
12. Acknowledgements 14 11. New Extensions 15
13. Security Considerations 14 12. Acknowledgements 15
Chair's Address 17 Chair's Address 17
Author's Address 17 Author's Address 17
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
skipping to change at page 1, line 126 skipping to change at page 1, line 127
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 [2], 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
number and variety of network services. It is expected that client
needs for creating connections with these future network services
will be satisfied by the Service Location Protocol [9], and not
DHCPv6. DHCP is expected to be used for the kinds of configuration
that enable clients to become fully functional as self-contained
network entities, but not the kinds of configuration that might be
required by applications running above the network or transport layer
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 [7]. 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
skipping to change at page 2, line 8 skipping to change at page 2, line 19
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?
DISCUSSION: Should individual Extensions in Request messages be
rejected individually?
3. Padding and End extension specifications 3. Padding and End extension specifications
3.1. Pad Extension 3.1. Pad Extension
The pad extension can be used to cause subsequent fields to align on The pad extension can be used to cause subsequent fields to align on
word boundaries. word boundaries.
The code for the pad extension is 0, and its length is 1 octet. The code for the pad extension is 0, and its length is 1 octet.
Code Code
skipping to change at page 3, line 11 skipping to change at page 3, line 16
in the same extension, hence the added complexity. Much of this in the same extension, hence the added complexity. Much 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|P|V|N|D|Q|A|P| pfx-size | | ext-type | ext-length |C|L|D|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 The length of the Extension. ext-length
The length of the Extension.
C If the 'C' bit is set, the field containing
the IPv6 address for the client is present in
the extension.
P If the 'P' bit is set, the preferred lifetime
is present in the extension.
V If the 'V' bit is set, the valid lifetime is C If the 'C' bit is set, the field containing the IPv6
present in the extension. address for the client is present in the extension.
N If the 'N' bit is set, the extension contains L If the 'L' bit is set, the preferred and valid lifetimes
the DNS name subfield. are present in the extension.
D If the 'D' bit is set, the client is not D If the 'D' bit is set, Duplicate Address Detection is not
required to perform Duplicate Address required.
Detection.
M If the 'M' bit is set, the fields included by Q If the 'Q' bit is set, the fields included by the client
the client are mandatory, and must be made are required, and must be made available by the server or
available by the server or else the extension else the extension must be rejected.
must be rejected.
A If the 'A' bit is set, the server MUST update A If the 'A' bit is set, the server MUST ensure that the
the DNS specified by the client's FQDN with DNS is updated with a new AAAA record, as specified
a new AAAA record 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 update P If the 'P' bit is set, the server MUST ensure that the
the DNS specified by the client's FQDN with DNS is updated with a new PTR record, as specified by the
a new PTR record before responding with the client's FQDN, before responding with the corresponding
corresponding DHCP Reply. DHCP Reply.
pfx-size If the client address is present (the 'C' rsv MUST be zero.
bit is set), then the pfx-size indicates the
length of the routing prefix, counting the
number of leading 1 bits to be applied to
the client's IPv6 address to get the routing
prefix. Otherwise, if the 'C' bit is not
set, pfx-size MUST be zero.
client address The IPv6 address to be allocated by the pfx-size
server for use by the client (16 octets If the client address is present (the 'C' bit is set),
long). then the pfx-size indicates the length of the routing
prefix, counting the number of leading 1 bits to be
applied to the client's IPv6 address to get the routing
prefix. Otherwise, if the 'C' bit is not set, pfx-size
MUST be zero. NOTE: the pfx-size field is only 7 bits
long.
preferred lifetime The preferred lifetime of the IPv6 address client address
The IPv6 address to be allocated by the server for use by
the client (16 octets long).
valid lifetime The valid lifetime of the IPv6 address preferred lifetime
The preferred lifetime of the IPv6 address
DNS name The DNS name (a zero-terminated character valid lifetime
string) to be used by the client (variable The valid lifetime of the IPv6 address
length).
The DNS name can be either a host name, which does not contain the DNS name
'.' character as a separator between DNS hierarchy components. Any The DNS name (a zero-terminated character string) to be
name containing the '.' is treated as a Fully Qualified Domain Name used by the client (variable length).
(FQDN). The length of the DNS name may be determined by subtracting
the length of those fixed-length fields which are present from the The DNS name can be a host name, which does not contain the '.'
ext-length. character as a separator between DNS hierarchy components. Any name
containing the '.' is treated as a Fully Qualified Domain Name
(FQDN). The length of the DNS name may be determined by subtracting,
from the ext-length, the length of those fixed-length fields which
are present. If the last byte of the DNS name is not zero, the IPv6
Address Extension MUST be rejected.
4.1. Client Considerations for the IPv6 Address extension 4.1. Client Considerations for the IPv6 Address extension
4.1.1. Address Lifetimes 4.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
skipping to change at page 5, line 20 skipping to change at page 5, line 25
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 [4] 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
client MUST keep track of when the request was issued. When the
client receives a successful reply from the DHCPv6 server, it MUST
decrement the received Lifetimes by the amount of time between the
transmission of the DHCP Request and the reception of the DHCP Reply.
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.
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 name and/or FQDN. - include an IPv6 address and/or DNS name and/or FQDN.
- request that server DNS update AAAA and/or PTR record. - request that server send updated AAAA and/or PTR records to the
DNS.
- specify whether address and/or name (if present) is advisory -or- - specify whether address and/or name (if present) is advisory -or-
mandatory; 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 it cannot accept anything other than the address listed in the that it cannot accept anything other than the address listed in the
IP Address extension to the DHCP Request, by specifying the 'M' IP Address extension to the DHCP Request, by specifying the 'Q'
(Mandatory) bit. (Required) bit.
Note that to delete DNS information, a client can use a DHCP Release When a client requests an IPv6 address, it MUST maintain a record for
message. the server which allocates that address, so that the client can (if
necessary) in the future
- Renew the lifetime with the same server, or
- Release the address using DHCP Release.
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 6, line 30 skipping to change at page 6, line 45
4.2.1. Use with the DHCP Advertise message 4.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
- the preferred lifetime - the preferred lifetime
- whether DNS will accept new names for the address - whether DNS will accept new names for the address (via the 'A'
bit)
4.3. Receiving a DHCP Request with the IPv6 Address Extension 4.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.3.1. Use with the DHCP Reply message 4.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
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 - whether AAAA has been DNS updated
skipping to change at page 7, line 16 skipping to change at page 7, line 35
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 - whether AAAA has been DNS updated
- whether PTR has been DNS updated - whether PTR has been DNS updated
If the client requests updates, and sets the 'M' 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.3.2. 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 can
indicate indicate
- the DNS name - the DNS name
4.4. 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.
4.5. Alternate Design possibility
DISCUSSION: Instead of trying to collect together everything
about IPv6 addresses in one single extension, it
would also be possible to break the DNS stuff into
separate Extensions. Since there may be multiple
such IPv6 addresses allocated in a single DHCP
Reply, we would have to adopt the convention that
the subsequent extensons relevant to IPv6 addresses
apply always to the last IPv6 address in the
closest preceding IPv6 address extension.
I find the above sort of context-sensitive
Extension processing is a cure worse than the
disease of a single mildly complicated IPv6 Address
Extension which has all the stuff an IPv6 address
needs.
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
are not specific to any upper-level protocol. are not specific to any upper-level protocol.
5.1. Time Offset 5.1. Time Offset
The time offset field specifies the offset of the client's subnet The time offset field specifies the offset of the client's subnet
in seconds from Coordinated Universal Time (UTC). The offset is in seconds from Coordinated Universal Time (UTC). The offset is
expressed as a signed 32-bit integer. expressed as a signed 32-bit integer.
The code for the time offset extension is 2, and its length is 4 The code for the time offset extension is 2, and its length is 4
octets. octets.
Code Len Time Offset Code Len Time Offset
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| 2 | 4 | n1 | n2 | n3 | n4 | | 2 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
5.2. Router Extension 5.2. Domain Name Server Extension
The router extension specifies a list of IP addresses for routers
on the client's subnet. Routers SHOULD be listed in order of
preference.
The code for the router extension is 3. The minimum length for
the router extension is 16 octets, and the length MUST always be a
multiple of 16.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 3 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
5.3. 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 [5]) name servers available to the client. System (STD 13, RFC 1035 [6]) 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.4. Resource Location Server Extension 5.3. Directory Agent Extension
This extension specifies a list of Resource Location servers [8] This extension specifies a list of Directory Agent [9] available to
available to the client. Servers SHOULD be listed in order of the client. Servers SHOULD be listed in order of preference.
preference.
The code for this extension is 11. The minimum length for this The code for this extension is 11. The minimum length for this
extension is 16 octets, and the length MUST always be a multiple of extension is 16 octets, and the length MUST always be a multiple of
16. 16.
Code Len Address 1 Address 2 Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 11 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... | 11 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
5.5. Domain Name 5.4. 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 | ...
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
If the Domain Name extension is not specified, and the IPv6 Address
extension received by a client contains a FQDN, then the client may
take the part of the FQDN after the first '.' character as the
Domain Name.
6. IP Layer Parameters per Interface 6. 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.
6.1. Static Route Extension 6.1. Static Route Extension
This extension specifies a list of static routes that the client This extension specifies a list of static routes that the client
should install in its routing cache. If multiple routes to the same should install in its routing cache. If multiple routes to the same
destination are specified, they are listed in descending order of destination are specified, they are listed in the order in which the
priority. 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, and the default route (0.0.0.0) is an illegal Link-local addresses are illegal destinations for a static route.
destination for a static route. See section 5.2 for information
about the router extension.
The code for this extension is 33. The minimum length of this The code for this extension is 33. The minimum length of this
extension is 32, and the length MUST be a multiple of 16. extension is 32, and the length MUST be a multiple of 16.
Code Len Destination 1 Router 1 Code Len Destination 1 Router 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 33 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | | 33 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Destination 2 Router 2 Destination 2 Router 2
+-----+-----+-----+-----+-----+-----+-----+-----+--- +-----+-----+-----+-----+-----+-----+-----+-----+---
skipping to change at page 13, line 23 skipping to change at page 12, line 44
not equipped to interpret the class-specific information sent by a not equipped to interpret the class-specific information sent by a
client MUST ignore it (although it may be reported). client MUST ignore it (although it may be reported).
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. Mobile Home Address Extension 9.3. Reconfigure Multicast Address
When this extension is present in a client request message, the A DHCPv6 server can instruct its clients to join a multicast group
DHCPv6 server is asked to send an appropriate home address to the for the purposes of receiving DHCPv6 Reconfigure messages. This will
mobile host. The DHCPv6 server, in its corresponding offering allow a server to reconfigure all of its clients at once; such a
message, will insert the requested address into the usual place for feature will be useful when renumbering becomes necessary.
requested IP addresses. The DHCPv6 server will typically notify the
mobile host of (one of) its home agents' addresses, as configured by
the local administration to be associated with the address given to
the mobile host. That home agent's IP address is inserted in the
data field of the mobile home address extension.
A mobile node with a known mobile home address can dynamically Code Len IPv6 Multicast Address
discover the location of a home agent serving the home address [1]. +-----+-----+-----+-----+-----+-----+
In that case, the DHCPv6 server may be configured to send out mobile | 70 | 16 | a1 | a2 | ... | a16 |
home addresses and expect that the mobile host discover the home +-----+-----+-----+-----+-----+-----+
agent's address by whichever method is approved by the working group.
It is also anticipated that many installations will allow several 9.4. Renumber DHCPv6 Server Address
home agents to serve the same mobile home addresses, for redundancy
or load sharing. For this reason, we have also allowed for the
possibility that the DHCPv6 server may wish to insert multiple home
agent addresses in the mobile home address extension.
The format of the mobile home address extension is as follows: A DHCPv6 server can instruct its clients to change their internal
records to reflect the server's newly renumbered IPv6 address, by
using the "Renumber DHCPv6 Server Address" extension. This extension
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
each one individually.
Code Len Home Address Code Len New IPv6 Server Address
+----+----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
| 68 | n | a1 | a2 | ... | a16 | | 71 | 16 | a1 | a2 | ... | a16 |
+----+----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+
Home Agent Addresses (zero or more)
+----+----+-----+-----+-----+ - --+ - -+ - -+ - -+
| a1 | a2 | ... | a16 | ...
+----+----+-----+-----+-----+ - --+ - -+ - -+ - -+
The code for the mobile home address extension is 68. The length is 9.5. Client-Server Authentication Extension
16, plus 16 octets multiplied by the number of home agents supplied
in the extension, which may be zero or more. It is expected that
the usual length will be 32 octets, containing a single home agent's
address.
10. Neighbor Discovery Extensions Exactly one Client-Server Authentication Extension MAY be present
in any DHCPv6 message transmitted between a client and server
(or vice-versa). If present, it MUST be placed after every other
extension.
This section contains extension definitions for specifying parameters Code Len Security Parameter ndx replay protect
that are useful with IPv6 Neighbor Discovery [6]. +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---
| 71 | 4+x | sp1 | sp2 | sp3 | sp4 | rp1 | ... | rp8 | Auth ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---
11. Extensions Type 71
Length 4 for the SPI, plus the number of bytes in the
Authenticator.
SPI A Security Parameters index [2] 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 MUST NOT be used in any Client-Server
Authentication Extension.
Replay Protection
A 64-bit timestamp (in Network Time Protocol [5](NTP)
format) (see section 10.1).
Authenticator
(variable length) (See Section 10.2.)
This authentication extension remedies the inability of IPsec to
provide for non end-to-end authentication, since authentication is
needed even when the client needs has no valid IPv6 address. The
extension can be originated by either the DHCPv6 Client or DHCPv6
server to authenticate the rest of the data in the DHCPv6 message.
10. Security Considerations
There is an urgent need to define some security protocol for use
with DHCPv6, since otherwise malicious parties could create numerous
denial-of-service style attacks based on depleting available server
resources or providing corrupted or infected data to unsuspecting
clients. The following sections discuss aspects of security relevant
for users of the Client-Server Authentication extension 9.5.
10.1. Replay Protection
A 64-bit timestamp, in Network Time Protocol [5](NTP) format, is
used to protect against replay of previous authenticated messages
by malicious agents. The NTP timestamp value used in the extension
MUST be chosen, and verified, to be larger than values used by the
originator in previous Client-Server Authentication extensions.
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
value (if any) used by the originator.
10.2. Default Authentication Algorithm
The default authentication algorithm uses keyed-MD5 [8] in
"prefix+suffix" mode to compute a 128-bit "message digest" of the
registration message. The default authenticator is a 128-bit value
computed as the MD5 checksum over the the following stream of bytes:
- the shared secret defined by the security association between
the client and server and by the SPI value specified in the
Authentication Extension, followed by
- all previous fields in the DHCPv6 message and extensions,
followed by
- the shared secret again.
11. New Extensions
Additional generic data fields may be registered by contacting: Additional generic data fields may be registered 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 generic types (including Implementation specific use of undefined generic types (including
those in the range 69-127) may conflict with other implementations, those in the range 72-127) may conflict with other implementations,
and registration is required. and registration is required.
DISCUSSION: Need to read Ralph's new draft and incorporate DISCUSSION: Need to read Ralph's new draft and incorporate
those ideas here. those ideas here.
12. Acknowledgements 12. Acknowledgements
Quite a bit of this internet draft is copied directly from Thanks to Jim Bound for his frequent review, helpful suggestions,
RFC1533 [2], written by Steve Alexander and Ralph Droms. and design assistance. The original form of this internet draft was
copied directly from RFC1533 [1], written by Steve Alexander and
13. Security Considerations Ralph Droms, to whom thanks are again due.
Security issues are not discussed in this memo. However, there
is an urgent need to define some security protocol for use with
DHCPv6, since otherwise malicious parties could create numerous
denial-of-service style attacks based on depleting available server
resources or providing corrupted or infected data to unsuspecting
clients.
DISCUSSION: SHOULD there be a DHCP Authentication Extension,
or should security be accomplished end-to-end by
IPSec, but with intermediary relays performing
encapsulation so as not to disturb the IPSec-style
end-to-end authentication.
References References
[1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-15.txt - [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
work in progress, February 1996.
[2] 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.
[3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for [3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for
IPv6. draft-ietf-dhc-dhcpv6-04.txt -- work in progress, February IPv6. draft-ietf-dhc-dhcpv6-04.txt -- work in progress, February
1995. 1996.
[4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[5] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. [5] David L. Mills. Network Time Protocol (Version 3):
RFC 1035, November 1987. Specification, Implementation and Analysis. RFC 1305, March
1992.
[6] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor Discovery. [6] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION.
draft-ietf-ipngwg-discovery-03.txt -- work in progress, November RFC 1035, November 1987.
1995.
[7] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, [7] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497,
August 1993. August 1993.
[8] J. Veizades, S. Kaplan, E. Guttman, and C. Perkins. Service [8] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321,
Location Protocol. draft-ietf-svrloc-protocol-09.txt - work in April 1992.
progress, February 1996.
[9] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service
Location Protocol. draft-ietf-svrloc-protocol-13.txt - work in
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
Lewisburg, PA 17837 Lewisburg, PA 17837
Phone: (717) 524-1145 Phone: (717) 524-1145
EMail: droms@bucknell.edu EMail: droms@bucknell.edu
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Charles Perkins Charles Perkins
Room J1-A25 Room H3-D34
T. J. Watson Research Center T. J. Watson Research Center
IBM Corporation IBM Corporation
30 Saw Mill River Rd. 30 Saw Mill River Rd.
Hawthorne, NY 10532 Hawthorne, NY 10532
Work: +1-914-784-7350 Work: +1-914-784-7350
Fax: +1-914-784-6205 Fax: +1-914-784-6205
E-mail: perk@watson.ibm.com E-mail: perk@watson.ibm.com
 End of changes. 

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