Internet Engineering Task Force C. Perkins INTERNET DRAFT Sun Microsystems 27 February 1997 Extensions for DHCPv6 draft-ietf-dhc-v6exts-05.txt Status of This Memo This document is a submission to the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the dhcp-v6@bucknell.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Dynamic Host Configuration Protocol for IPv6 [3] (DHCPv6) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in typed data items that are stored in the "extensions" field of the DHCPv6 message. The data items themselves are also called "extensions." This document specifies the current set of DHCPv6 extensions. This document will be periodically updated as new extensions are defined. Each superseding document will include the entire current list of valid extensions. Perkins Expires 27 July 1997 [Page i] Internet Draft DHCPv6 Extensions 27 February 1997 Contents Status of This Memo i Abstract i 1. Introduction 1 2. DHCPv6 Extension Field Format 2 2.1. Character Encoding and String Issues . . . . . . . . . . 2 3. Padding and End extension specifications 3 3.1. Pad Extension . . . . . . . . . . . . . . . . . . . . . . 3 3.2. End Extension . . . . . . . . . . . . . . . . . . . . . . 3 4. IPv6 Address Extension 3 4.1. Client Considerations for the IPv6 Address extension . . 6 4.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6 4.1.2. Use with the DHCP Request message . . . . . . . . 6 4.1.3. Receiving as part of the DHCP Reply message . . . 7 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 4.2.3. Use with the DHCP Reply message . . . . . . . . . 8 4.2.4. Use with the DHCP Reconfigure message . . . . . . 9 4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 9 5. General Extensions 9 5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 10 5.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 11 6. Service Location Extensions 11 6.1. Directory Agent Extension . . . . . . . . . . . . . . . . 11 6.2. Service Scope Extension . . . . . . . . . . . . . . . . . 12 7. IP Layer Parameters per Interface 13 7.1. Static Route Extension . . . . . . . . . . . . . . . . . 13 8. TCP Parameters 14 8.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 14 Perkins Expires 27 July 1997 [Page ii] Internet Draft DHCPv6 Extensions 27 February 1997 9. Vendor Specific Information 14 10. DHCPv6 Extensions 16 10.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 16 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 11.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 19 11.2. Default Authentication Algorithm . . . . . . . . . . . . 19 12. New Extensions 20 13. Acknowledgements 20 Chair's Address 22 Author's Address 22 Perkins Expires 27 July 1997 [Page iii] Internet Draft DHCPv6 Extensions 27 February 1997 1. Introduction This document specifies extensions for use with the Dynamic Host Configuration Protocol for IP version 6, DHVPv6. The full description of DHCPv6 message formats may be found in the DHCPv6 specification document [3]. This document defines the format of information in the last field of DHCPv6 messages ('extensions'). The extensions defined within this document specify a generalized use of this area for giving information useful to a wide class of machines, operating systems and configurations. Sites with a single DHCPv6 server that is shared among heterogeneous clients may choose to define other, site- specific formats for the use of the 'extensions' field. Section 2 of this memo describes the formats of DHCPv6 extensions. Information on registering new extensions is contained in section 12. The other sections organize the format descriptions of various extensions according to their general type, as follows: - IP Address extension - Miscellaneous host configuration - Service Location configuration - Miscellaneous network layer - TCP - Vendor Specific - DHCPv6 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 [12], 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. Perkins Expires 27 July 1997 [Page 1] Internet Draft DHCPv6 Extensions 27 February 1997 2. DHCPv6 Extension Field Format DHCPv6 extensions have the same format as the BOOTP "vendor extensions" defined in RFC 1497 [9]. Extensions may be fixed length or variable length. All extensions except for the pad extension begin with a type field which is two octets long, which uniquely identifies the extension. Fixed length extensions without data consist of only the two octet type field. Only extensions 0 and 65535 are fixed length. All other extensions are variable length with a two octet length field following the type octets. The value of the length octets does not include the two octets specifying the type and length. The length octet is followed by "length" octets of data. In the case of some variable length extensions the length field is a constant but must still be specified. Any extensions defined subsequent to this document should contain a 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 specified in the length octets. All multi-octet quantities are in network byte-order. Extension types 32768 to 65534 (decimal) are reserved for site-specific extensions. All of the extensions described in this document will also have their default values specified, if any. 2.1. Character Encoding and String Issues Values for character encoding can be found in the Internet Assigned Numbers Authority's (IANA) database http://www.isi.edu/in-notes/iana/assignments/character-sets and have the values referred by the MIBEnum value. The encoding will determine the interpretation of all character data in the corresponding fields of particular extensions. There is no 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 sent to a DHCP server, which is unable to manipulate or store the character set of the incoming message, the request will fail. The server returns a CHARSET_NOT_UNDERSTOOD error (24) in a DHCP Reply message in this case. Requests using US-ASCII (MIBEnum value == 3) 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 be encoded in US-ASCII. Perkins Expires 27 July 1997 [Page 2] Internet Draft DHCPv6 Extensions 27 February 1997 3. Padding and End extension specifications 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 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 the same DHCP message, all information relevant to a particular IPv6 allocation has to be collected together in the same extension. Some of the fields within the IPv6 Address extension can specify how DNS [13] may be updated. Perkins Expires 27 July 1997 [Page 3] Internet Draft DHCPv6 Extensions 27 February 1997 An IPv6 Address Extension can contain at most one IPv6 address. To specify more than one IPv6 address, multiple extensions are used. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pfx-size | error-code |C|L|Q|A|P| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) | | client address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) preferred lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) valid lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) DNS name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length (variable) The length of the Extension. pfx-size If the client address is present (the 'C' bit is set), a nonzero 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. error-code If the server is unable to honor the client's request, the reason is indicated in the error-code. Current values are as follows: 0 request granted, no errors 16 dynDNS Not Available at this time 17 dynDNS Not Implemented 18 Authentication failed for this client 19 Authoritative DNS Server could not be found 20 Resource AAAA Record Parameter Problem 21 Resource PTR Record Parameter Problem 22 Unable to honor required extension parameters 23 DNS name string error Perkins Expires 27 July 1997 [Page 4] Internet Draft DHCPv6 Extensions 27 February 1997 C If the 'C' bit is set, the field containing the IPv6 address for the client is present in the extension. L If the 'L' bit is set, the preferred and valid lifetimes are present in the extension. Q If the 'Q' bit is set, the fields included by the client are required, and must be made available by the server or else the extension must be rejected. A 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. P 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. reserved MUST be zero. client address The IPv6 address to be allocated by the server for use by the client (16 octets long). preferred lifetime The preferred lifetime of the IPv6 address in seconds valid lifetime The valid lifetime of the IPv6 address in seconds DNS name The DNS name (a zero-terminated string of ASCII octets) to be used by the client (variable length). The DNS name can be a host name, which does not contain the '.' ASCII 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 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, with error code 23. Perkins Expires 27 July 1997 [Page 5] Internet Draft DHCPv6 Extensions 27 February 1997 4.1. Client Considerations for the IPv6 Address extension 4.1.1. Address Lifetimes An IPv6 address returned to a client has a preferred and valid lifetime. The lifetimes represent the lease for addresses provided to the client, from the server. 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 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 MUST assume the client does not want that address. The server MAY provide that address to another client requesting an address. The client MAY request a value for the lifetimes returned by a server, but the client MUST use the lifetimes provided by the server response. When the preferred lifetime of an IPv6 address expires, the client's address becomes a deprecated address. See [4] for required handling of deprecated IPv6 addresses. When an address for a DHCPv6 client's interface becomes deprecated, the processing of the lifetime SHOULD request a new address for that interface, or make a new DHCP Request for the existing address (which can result in the address receiving 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 In a DHCP Request (for each address extension), a client may: - include an IPv6 address and/or DNS name and/or FQDN. - request that server send updated AAAA and/or PTR records to the DNS. - specify whether address and/or name and/or lifetime (if present) is advisory -or- mandatory; Perkins Expires 27 July 1997 [Page 6] Internet Draft DHCPv6 Extensions 27 February 1997 - indicate the minimum preferred lifetime If the Request is advisory, a server may send different parameters than requested in the DHCP Reply. Otherwise, if the Request is mandatory, the server must reject the Request if it cannot be fulfilled. A client may include multiple IP Address extensions in a single DHCP Request. The server that receives the Request is not absolutely required to honor the client's Request. A DHCP client indicates that it cannot accept anything other than the configuration information (e.g., IP address) listed in the IP Address extension to the DHCP Request, by specifying the 'Q' (Required) bit. 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 necessary) in the future - Renew the lifetime with the same server, or - Release the address, using DHCP Release. 4.1.3. Receiving as part of the DHCP Reply message 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 to see whether the requested information has been granted. If the error-code is nonzero, the client should log the error, display the error condition for action by the user and/or the network administrator. Nonzero error-codes almost always indicate that the client will be unable to use DHCP services until the client's request can be modified, or until the DHCP server can be given updated configuration information for the client. Upon reception of a new IP address with a lifetime, the client must perform Duplicate Address Detection (DAD) [11]; 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. If the client receives a new IP address with zero valid lifetime, the client MUST immediately discontinue using that IP address. 4.1.4. Use with the DHCP Release message In DHCP Release (for each address extension): Perkins Expires 27 July 1997 [Page 7] Internet Draft DHCPv6 Extensions 27 February 1997 - Client can include an IPv6 address and/or name and/or FQDN. - Server MUST update DNS to delete the AAAA record if the server originally updated DNS when the address was allocated to the client. Likewise for the PTR record. - If the client, on the other hand, took charge of the DNS updates, it MUST perform the corresponding deletions before issuing the DHCP Release. 4.2. Server Considerations for the IPv6 Address extension 4.2.1. Use with the DHCP Advertise message In DHCP Advertise (for each address extension), the Server can indicate: - the FQDN - the preferred lifetime - whether DNS will accept new names for the address (via the 'A' bit) 4.2.2. Receiving a DHCP Request with the IPv6 Address Extension If the client has requested that the server perform DNS updates as part of the IPv6 address allocation and configuration, the server must maintain this fact as part of the client's binding. Then, if the client eventually releases the IPv6 address (by including an appropriate IPv6 Address with the DHCP Release message), the server can perform the reverse service by updating DNS again as needed. 4.2.3. Use with the DHCP Reply message In a DHCP Reply message (for each address extension) the server MUST indicate - the preferred lifetime - the valid lifetime - the status of the request Perkins Expires 27 July 1997 [Page 8] Internet Draft DHCPv6 Extensions 27 February 1997 If the Reply is a response to a DHCP Release, the lifetimes MUST both be zero. In a DHCP Reply message (for each address extension) the server MAY indicate - the DNS name - whether AAAA has been DNS updated (by setting the 'A' bit) - whether PTR has been DNS updated (by setting the 'P' bit) If the client requests updates, and sets the 'Q' bit, the server MUST NOT issue the DHCP Reply until after receiving positive indication that the DNS update has indeed been performed. If the 'Q' bit has been set, and the server cannot honor the IP address extension, it MUST return a DHCP reply with the error code 22. Otherwise, the client can subsequently update DNS if needed (i.e., the server didn't do it). If the server receives a DHCP Request from one of its clients whose address it wishes to invalidate, it can cause the client to discontinue use of the old address by including valid and preferred lifetimes with a value of zero. To perform renumbering, the server will include two IP address extensions, one to invalidate the old address, and another to give the client its new address. 4.2.4. Use with the DHCP Reconfigure message In DHCP Reconfigure (for each address extension) the server MAY indicate the DNS name. 4.3. DHCP Relay Considerations The DHCP Relay MUST NOT change any information in any DHCPv6 Extension fields. All Extension information flows between DHCPv6 Server and DHCPv6 Client without modification by any Relay. 5. General Extensions The following extensions are important for many DHCPv6 clients, and are not specific to any upper-level protocol. Perkins Expires 27 July 1997 [Page 9] Internet Draft DHCPv6 Extensions 27 February 1997 5.1. Time Offset 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 subnet in seconds from Coordinated Universal Time (UTC). The offset is expressed as a signed 32-bit integer. 5.2. Domain Name Server Extension 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Name System server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The domain name server extension specifies a list of Domain Name System (STD 13, RFC 1035 [8]) name servers available to the client. Servers SHOULD be listed in order of preference. 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 a multiple of 16. Perkins Expires 27 July 1997 [Page 10] Internet Draft DHCPv6 Extensions 27 February 1997 5.3. Domain Name This extension specifies the domain name that client should use when resolving hostnames via the Domain Name System. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type for this extension is 10. Its minimum length is 1. The domain name is a null-terminated ASCII string, length octets in size, including the terminating zero octet. 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 '.' octet as the Domain Name. 6. Service Location Extensions 6.1. Directory Agent Extension This extension specifies a Directory Agent (DA) [12], along with zero or more scopes supported by that DA. A scope, in the Service Location Protocol, is a way of restricting the accessibility of 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 null-terminated string of ASCII octets. The lengths of the strings (measured in octets) are only indicated implicitly by their null termination and the overall length of the extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Char Encoding | scope count |D|M| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Perkins Expires 27 July 1997 [Page 11] Internet Draft DHCPv6 Extensions 27 February 1997 | (if present) | | Directory Agent address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scope list ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 Length (variable) The length of the Extension. Character Encoding 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 present. M If the 'M' bit is set, the Directory Agent address is the only one that may be used, and multicast methods for discovering Directory Agents MUST NOT be used. scope count The number of scopes indicated by strings in the scope list following. 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 scopes. The client may request a Directory Agent with a particular scope, by including the Directory Agent extension in a DHCP Request message with no Directory Agent address included (the 'D' bit set to zero), and the appropriate strings in the scope list. 6.2. Service Scope Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Char Encoding | scope ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 17 Perkins Expires 27 July 1997 [Page 12] Internet Draft DHCPv6 Extensions 27 February 1997 Length (variable) The length of the Extension. Character Encoding 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 character encoding, of length 'Length - 2' octets including the terminating zero octet. 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. 7. IP Layer Parameters per Interface 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 issue multiple requests, one per interface, in order to configure interfaces with their specific parameters. 7.1. Static Route Extension 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination address 1 | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router address 1 | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination address 2 | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router address 2 | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |additional Destination/Router address pairs (32 octets each) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension specifies a list of static routes that the client should install in its routing cache. If multiple routes to the same Perkins Expires 27 July 1997 [Page 13] Internet Draft DHCPv6 Extensions 27 February 1997 destination are specified, they are listed in the order in which the client should make use of them. 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 the destination. Link-local addresses are illegal destinations for a static route. The Type for this extension is 24. The minimum length of this extension is 24, and the length MUST be a multiple of 32. 8. TCP Parameters This section lists the extensions that affect the operation of the TCP layer on a per-interface basis. 8.1. TCP Keepalive Interval Extension 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Keepalive Time Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension specifies the interval (in seconds) that the client TCP should wait before sending a keepalive message on a TCP connection. The time is specified as a 32-bit unsigned integer. A value of zero indicates that the client should not generate keepalive messages on connections unless specifically requested by an application. The Type for this extension is 32, and its length is 4. 9. Vendor Specific Information This extension is used by clients and servers to exchange vendor- specific information. The information is an opaque object of n octets, presumably interpreted by vendor-specific code on the clients and servers. The definition of this information is vendor specific. The vendor is indicated in the class-identifier extension. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which Perkins Expires 27 July 1997 [Page 14] Internet Draft DHCPv6 Extensions 27 February 1997 do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and announce they are doing so) in a degraded mode. If a vendor potentially encodes more than one item of information in this extension, then the vendor SHOULD encode the extension using "Encapsulated vendor-specific extensions" as described below: The Encapsulated vendor-specific extensions field SHOULD be encoded as a sequence of type/length/value fields of identical syntax to the DHCPv6 extensions field with the following exceptions: - Types other than 0 or 255 MAY be redefined by the vendor 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 encapsulated vendor extensions, not the end of the vendor extensions field. If no code 255 is present, then the end of the enclosing vendor-specific information field is taken as the end of the encapsulated vendor-specific extensions field. The Type for this extension is 40 and its minimum length is 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-specific information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When encapsulated vendor-specific extensions are used, the information bytes 1-n have the following format: Type Len Data item Type Len Data item Type +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 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. Perkins Expires 27 July 1997 [Page 15] Internet Draft DHCPv6 Extensions 27 February 1997 10. DHCPv6 Extensions This section details the extensions that are specific to DHCPv6. 10.1. Maximum DHCPv6 Message Size Extension This extension specifies the maximum size in octets of any DHCPv6 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 the maximum DHCPv6 message size extension in DHCP Request messages, but SHOULD NOT use the extension in DHCP Solicit messages(see [3]), and MUST NOT use the extension in other DHCP messages. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max DHCPv6 Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type for this extension is 64, and its length is 2. The minimum legal value is 1500. 10.2. Class Identifier This extension is used by a DHCP client to optionally identify the type or category of user or applications it represents. DHCP administrators may define specific user class identifiers to convey information about a client's software configuration or about its user's preferences. For example, an identifier may specify that a particular DHCP client is a member of the class "accounting auditors", which have special service needs such as a particular database server. Alternatively, the identifier may encode the client's hardware configuration. Servers not equipped to interpret the user class specified by a client MUST ignore it (although it may be reported). Otherwise, servers SHOULD respond with the set of extensions corresponding to the user class specified by the client. Further, if the server responds with the set of extensions corresponding to the given user Perkins Expires 27 July 1997 [Page 16] Internet Draft DHCPv6 Extensions 27 February 1997 class, it MUST return this extension (with the given user class value) to the client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Char Encoding | Class Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The class identifier is a zero-terminated string of characters in the character set specified by the Char Encoding field (see section 2.1), of length 'n' octets including the terminating null octet. The class identifier represents the user class of which the client is a member. 10.3. Reconfigure Multicast Address A DHCPv6 server can instruct its clients to join a multicast group for the purposes of receiving DHCPv6 Reconfigure messages. This will allow a server to reconfigure all of its clients at once; such a feature will be useful when renumbering becomes necessary. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reconfigure Multicast Address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of the Reconfigure Multicast Address is 66, and the length is 16. 10.4. Renumber DHCPv6 Server Address 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 Perkins Expires 27 July 1997 [Page 17] Internet Draft DHCPv6 Extensions 27 February 1997 multicast to all of the server's clients instead of being unicast to each one individually. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New DHCPv6 Server Address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of the Renumber DHCPv6 Server Address is 67, and the length is 16. 10.5. Client-Server Authentication Extension 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 the last extension, except possibly for the Pad extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Protection | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 84 Length 4 for the SPI, plus 8 for the replay protection, 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, if used, MUST conform to the security context defined by that value as defined in the most recent Assigned Numbers RFC (e.g., [5]). Perkins Expires 27 July 1997 [Page 18] Internet Draft DHCPv6 Extensions 27 February 1997 Replay Protection A 64-bit timestamp (in Network Time Protocol [7](NTP) format) (see section 11.1). Authenticator (variable length) (See Section 11.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. The default authentication algorithm is defined in section 11.2. 11. 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 10.5. 11.1. Replay Protection A 64-bit timestamp, in Network Time Protocol [7](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. 11.2. Default Authentication Algorithm The default authentication algorithm is HMAC [6], using keyed-MD5 [10]. Given a secret key K, and "data" the information to be authenticated, HMAC_result is computed as follows: 1. opad := 0x36363636363636363636363636363636 (128 bits) 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 3. zero_extended_key := K extended by zeroes to be 128 bits long Perkins Expires 27 July 1997 [Page 19] Internet Draft DHCPv6 Extensions 27 February 1997 4. opadded_key := zero_extended_key XOR opad 5. ipadded_key := zero_extended_key XOR ipad 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) The key K is the shared secret defined by the security association between the client and server and by the SPI value specified in the Authentication Extension. The "data" is the stream of bytes in all previous fields in the DHCPv6 message and extensions. The authenticator is the 128-bit value HMAC_result. 12. New Extensions Additional extensions may be registered by contacting: Internet Assigned Numbers Authority (IANA) USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-6695 or by email as: iana@isi.edu Implementation specific use of undefined extensions (including those in the range 85-32767) may conflict with other implementations, and registration is required. 13. Acknowledgements Thanks to Jim Bound for his frequent review, helpful suggestions, and design assistance. The original form of this internet draft was copied directly from RFC1533 [1], written by Steve Alexander and Ralph Droms, to whom thanks are again due. Perkins Expires 27 July 1997 [Page 20] Internet Draft DHCPv6 Extensions 27 February 1997 References [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 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 IPv6. draft-ietf-dhc-dhcpv6-09.txt, February 1997. (work in progress). [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 1883, December 1995. [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [6] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [7] David L. Mills. Network Time Protocol (Version 3): Specification, Implementation and Analysis. RFC 1305, March 1992. [8] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC 1035, November 1987. [9] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, August 1993. [10] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [11] S. Thomson and T. Narten. IPv6 stateless address autoconfiguration. RFC 1971, August 1996. [12] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. draft-ietf-svrloc-protocol-15.txt, November 1996. (work in progress). [13] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System (DNS). draft-ietf-dnsind-dynDNS-11.txt, November 1996. (work in progress). Perkins Expires 27 July 1997 [Page 21] Internet Draft DHCPv6 Extensions 27 February 1997 Chair's Addresses The working group can be contacted via the current chair: Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: droms@bucknell.edu Author's Address Questions about this memo can be directed to: Charles Perkins Mail Stop UPAL01-550 Netcentricity Group Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94043 Work: +1-415-336-7153 Fax: +1-415-336-0673 E-mail: cperkins@corp.sun.com Perkins Expires 27 July 1997 [Page 22]