Internet Engineering Task Force C. Perkins INTERNET DRAFT Sun Microsystems 30 July 1997 Extensions for the Dynamic Host Configuration Protocol for IPv6 draft-ietf-dhc-v6exts-07.txt Status of This Memo This document is a submission by 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 (North Europe), ftp.nis.garr.it (South 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 [4] (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 30 January 1998 [Page i] Internet Draft DHCPv6 Extensions 30 July 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. IP Address Extension 3 3.1. Client Considerations for the IP Address extension . . . 6 3.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 6 3.1.2. Use with the DHCP Request message . . . . . . . . 7 3.1.3. Receiving as part of the DHCP Reply message . . . 8 3.1.4. Use with the DHCP Release message . . . . . . . . 9 3.2. Server Considerations for the IP Address extension . . . 9 3.2.1. Use with the DHCP Advertise message . . . . . . . 9 3.2.2. Receiving a DHCP Request with the IP Address Extension . . . . . . . . . . . . . . . . 9 3.2.3. Use with the DHCP Reply message . . . . . . . . . 10 3.2.4. Use with the DHCP Reconfigure message . . . . . . 11 3.2.5. Receiving a DHCP Release with the IP Address Extension . . . . . . . . . . . . . . . . 11 3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 11 4. General Extensions 11 4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. IEEE 1003.1 POSIX Timezone extension . . . . . . . . . . 12 4.2.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 12 4.2.2. An Example . . . . . . . . . . . . . . . . . . . 14 4.2.3. Timezone 0ption Precedence . . . . . . . . . . . 14 4.3. Domain Name Server Extension . . . . . . . . . . . . . . 15 4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 15 5. Application and Service Parameters 15 5.1. Directory Agent Extension . . . . . . . . . . . . . . . . 16 5.2. Service Scope Extension . . . . . . . . . . . . . . . . . 17 5.3. Network Time Protocol Servers Extension . . . . . . . . . 18 5.4. Network Information Service Domain Extension . . . . . . 19 5.5. Network Information Servers Extension . . . . . . . . . . 19 5.6. Network Information Service+ Domain Extension . . . . . . 19 5.7. Network Information Service+ Servers Extension . . . . . 20 Perkins Expires 30 January 1998 [Page ii] Internet Draft DHCPv6 Extensions 30 July 1997 5.8. Vendor Specific Information . . . . . . . . . . . . . . . 20 6. TCP Parameters 21 6.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 21 7. DHCPv6 Extensions 22 7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 22 7.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 22 7.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 23 7.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 23 7.5. Client-Server Authentication Extension . . . . . . . . . 24 7.6. Client Key Selection Extension . . . . . . . . . . . . . 25 8. End extension specification 26 9. Security Considerations 26 9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 26 9.2. Default Authentication Algorithm . . . . . . . . . . . . 26 10. Defining New Extensions 27 11. Acknowledgements 29 Chair's Address 31 Author's Address 31 Perkins Expires 30 January 1998 [Page iii] Internet Draft DHCPv6 Extensions 30 July 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 [4]. In this document, several words are used to signify the requirements of the specification, in accordance with RFC 2119 [5]. These words (MUST, SHOULD, MAY, MUST NOT, etc) are often capitalized. This document defines the format of information in the last field 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 10. 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 [21], 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 30 January 1998 [Page 1] Internet Draft DHCPv6 Extensions 30 July 1997 2. DHCPv6 Extension Field Format DHCPv6 extensions have the same format as the BOOTP "vendor extensions" [2]. Extensions may be fixed length or variable length. All extensions begin with a type field, which is two octets long and uniquely identifies the extension. Fixed length extensions without data consist of only the two octet type field. Only extension 65535 is fixed length. All other extensions are variable length with a two octet unsigned integer Length field following the type octets. The value of the Length field does not include the four octets specifying the type and length. The Length field is followed by "length" octets of data. In the case of some extensions the length field is a constant but MUST still be specified. In each case, unless otherwise specified, the length field specifies the length of the extension in octets. Any extensions defined subsequent to this document should contain a Length field even if the length is fixed or zero. There is no particular requirement for alignment of the data fields within existing DHCPv6 extensions. Unrecognized extensions SHOULD be skipped by ignoring the number of octets specified in the length field, and processing continued for subsequent extensions. Unless and until specified otherwise by use of extension type 64 (see section 7.1), DHCP entities MUST assume that the maximum DHCP message size including extensions is 1500 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. Whenever an extension is received as part of a DHCP message, any reserved fields of the message MUST be ignored, and processing continued as if the reserved fields were zero. 2.1. Character Encoding and String Issues Certain extensions (e.g., type 16 described in section 5.1) have fields which can use various character encodings. 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. Note that in some character sets, each character may require two or more octets of data for its representation. Perkins Expires 30 January 1998 [Page 2] Internet Draft DHCPv6 Extensions 30 July 1997 The encoding will determine the interpretation of all character data in the corresponding fields of particular extensions. There is no way to mix US-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 status code of 24in 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. 3. IP Address Extension The IP 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 IP Address extension 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 IP Address extension can specify how DNS may be updated [22]. To ask for an IP address in a DHCP Request message, a client includes an IP Address Extension. To renew or extend the lifetime of a particular IP address, the client puts that address in the client address field. To request the allocation of a new but unspecified IP address, the client omits the client address field. The IP address returned by the server in the latter case will be compatible with a subnet prefix of the link to which the client is currently attached. Perkins Expires 30 January 1998 [Page 3] Internet Draft DHCPv6 Extensions 30 July 1997 An IP Address Extension can contain at most one IP address. To specify more than one IP 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 | status |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 (unsigned integer, variable) The length of the Extension in octets. pfx-size If the client address is present (the 'C' bit is set), a nonzero pfx-size is the number of leftmost bits of the client's IPv6 address which make up the routing prefix. Otherwise, if the 'C' bit is not set, pfx-size MUST be zero. status If the server is unable to honor the client's request, the reason is indicated in the status. C If the 'C' bit is set, the field containing the IP 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 client requests that that the the server updates DNS with a new AAAA record, as specified by the client's FQDN. Perkins Expires 30 January 1998 [Page 4] Internet Draft DHCPv6 Extensions 30 July 1997 P If the 'P' bit is set, the client requests that that the the server updates DNS with a new PTR record, as specified by the client's FQDN. reserved MUST be zero. client address The IP address to be allocated by the server for use by the client (16 octets long). preferred lifetime The preferred lifetime of the IP address in seconds valid lifetime The valid lifetime of the IP address in seconds DNS name The DNS name (a null-terminated string of ASCII octets) to be used by the client (variable length). The following values for the status field are defined within this document: 0 request granted, no errors 18 Security parameters failed for this client 20 Resource AAAA Record Parameter Problem 21 Resource PTR Record Parameter Problem 22 Unable to honor required extension parameters 23 DNS name string error 33 The name server was unable to interpret the request due to a format error. 34 dynDNS Not Available at this time 35 Some name that ought to exist, does not exist. 36 The name server does not support the specified Opcode. 36 dynDNS Not Implemented 37 The name server refuses to perform the specified operation for policy or security reasons. 38 Some name that ought not to exist, does exist. 39 Some RRset that ought not to exist, does exist. 40 Some RRset that ought to exist, does not exist. 41 The server is not authoritative for the zone named in the Zone Section. 42 A name used in the Prerequisite or Update Section is not within the zone denoted by the Zone Section. 34 Authoritative DNS Server could not be found Status values 34through 21are described more fully within RFC 2136 [22]. Up-to-date values for the values of the status field are Perkins Expires 30 January 1998 [Page 5] Internet Draft DHCPv6 Extensions 30 July 1997 specified in the most recent "Assigned Numbers" [17]. To inform the client of the DYNDNS [22] error return codes (i.e., nonzero return codes) received by the DHCPv6 server the client MUST assume the status codes 32 through 42 are formed as follows: status code = 32 + DYNDNS Error Code 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 octet of the DNS name is not zero, the IP Address Extension MUST be rejected, with status 23. If the 'Q' bit is set, the values or actions requested by the C, L, A, and P bits are required, and MUST be provided, or the extension MUST be rejected with status code 22. If the 'Q' bit is set, and if the 'A' bit is set, the server MUST ensure that the DNS is updated with a new AAAA record, as specified by the client's FQDN, before responding with the corresponding DHCP Reply. Likewise, if the 'Q' bit is set, and if the 'P' bit is set, the server MUST ensure that the DNS is updated with a new PTR record, as specified by the client's FQDN, before responding with the corresponding DHCP Reply. A DHCP client can include an IP address in its IP Address extension and set the 'A' bit and/or 'P' bit to ask the DHCP Server to use that address for updating DNS. This can be done even with IP addresses obtained by Stateless Address Autoconfiguration [20]. 3.1. Client Considerations for the IP Address extension 3.1.1. Address Lifetimes An IP address returned to a client has a preferred and valid lifetime. The valid lifetime represents the lease for addresses provided to the client, from the server. The client SHOULD make a new Request for any 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 SHOULD assume the client does not want that address. The server MAY provide that address to another client requesting an address. Perkins Expires 30 January 1998 [Page 6] Internet Draft DHCPv6 Extensions 30 July 1997 The client MAY request values for the lifetimes, but the client MUST use the lifetimes provided by the server response. When the preferred lifetime of an IP address expires, the client's address becomes a deprecated address. See [8] for required handling of deprecated IP addresses. Before an address for a DHCPv6 client's interface becomes deprecated, the client 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 IP address from the DHCPv6 server, the client MUST keep track of when the request was issued. When the client receives a successful reply from the DHCPv6 server, it MUST decrement the received Lifetimes by the amount of time between the transmission of the DHCP Request and the reception of the 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. 3.1.2. Use with the DHCP Request message In a DHCP Request (for each address extension), a client MUST set the status code to zero. In a DHCP Request (for each address extension), a client MAY: - include an IP address and/or a DNS name (which may be a host name or a FQDN). - set the 'A' bit to request that the server update DNS with a new AAAA record, as specified by the client's FQDN; if the 'Q' bit is also set, this update MUST be completed before responding with the corresponding DHCP Reply. - set the 'P' bit to request that the server update DNS with a new PTR record, as specified by the client's FQDN; if the 'Q' bit is also set, this update MUST be completed before responding with the corresponding DHCP Reply. - indicate the minimum preferred (and/or valid) lifetime, by supplying a value for the field(s). - specify whether address, name and lifetimes (if present) are advisory -or- mandatory, by setting the 'Q' bit. If the Request is advisory, a server may send different parameters than requested in the DHCP Reply. Otherwise, if the Request is Perkins Expires 30 January 1998 [Page 7] Internet Draft DHCPv6 Extensions 30 July 1997 mandatory, the server MUST reject the Request if it cannot be fulfilled. A server can always supply a greater value for the lifetimes than that requested by the client, even if the 'Q' bit is set. If the client wishes to have a smaller lifetime than the server supplies, the client MAY use the DHCP Release mechanism to relinquish it. 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 - Extend the lifetime with the same server, or - Release the address, using DHCP Release. Note that if a client wishes to specify a lifetime for its IP address, it normally only needs to specify a value for the preferred lifetime, not the valid lifetime. 3.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 [4]), it first inspects the status to see whether the requested information has been granted. If the status is nonzero, the client should log the error, display the error condition for action by the user and/or the network administrator. Nonzero status almost always indicates that the client will be need to modify its request before it could be satisfied by the replying DHCP server, or alternatively that the replying DHCP server will need to be given updated configuration information for the client. Upon reception of a new IP address with a lifetime, the client MUST perform Duplicate Address Detection (DAD) [20]; 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 an IP address with zero valid lifetime, the client MUST immediately discontinue using that IP address. Perkins Expires 30 January 1998 [Page 8] Internet Draft DHCPv6 Extensions 30 July 1997 3.1.4. Use with the DHCP Release message In DHCP Release (for each address extension): - the client may include an IP address and/or a DNS name (which may be a host name or a FQDN). - the server MUST update DNS to delete the AAAA record or records that the server originally used when updating DNS when the address was allocated to the client, and likewise for the PTR record (regardless of the setting of the 'A' or 'P' bits in the address extension). - If the client, on the other hand, took charge of the DNS updates, it MUST perform the corresponding deletions before issuing the DHCP Release. If the DNS name is provided ONLY all client AAAA records for that name will be deleted. 3.2. Server Considerations for the IP Address extension 3.2.1. Use with the DHCP Advertise message In DHCP Advertise (for each address extension), the Server can indicate: - the cllient's FQDN or host name - the preferred lifetime - whether DNS will accept new names for the address (via the 'A' bit) If the server sets the 'A' bit, it is willing to perform DNS updates to AAAA records on behalf of the client. Likewise, if the server sets the 'P' bit, it is willing to perform DNS updates to PTR records on behalf of the client. 3.2.2. Receiving a DHCP Request with the IP Address Extension When a server receives a request for an IP address, it consults its allocation tables and determines an IP address appropriate for the requesting client and the subnet to which the client is attached. The subnet can be determined by the Agent address in the DHCP Request message header, or, when there is no relay, by the subnet of the Perkins Expires 30 January 1998 [Page 9] Internet Draft DHCPv6 Extensions 30 July 1997 interface on which the request was received. This is true in the latter case because the client and the server have to be on the same subnet when there is no Agent address included in the message header. If the client has requested that the server perform DNS updates as part of the IP address allocation and configuration, the server MUST maintain this fact as part of the client's binding. Then, if the client eventually releases the IP address (see the DHCP Releas message in [4]), the server MUST perform the reverse service by updating DNS again as needed. 3.2.3. Use with the DHCP Reply message In a DHCP Reply message (for each address extension) the server MUST indicate in the IP address extension - the preferred lifetime - the valid lifetime - the status of the request 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 status 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. Perkins Expires 30 January 1998 [Page 10] Internet Draft DHCPv6 Extensions 30 July 1997 To perform renumbering, the server will include two IP address extensions, one to reduce the zero out the preferred lifetime and reduce the valid lifetime for the old address, and another to give the client its new address. On a practical note, note also that if the DHCP administrator uses site-local addresses for IP address allocation to clients, there will be less need for renumbering whenever the site moves to a new site prefix or set of site prefixes. 3.2.4. Use with the DHCP Reconfigure message In DHCP Reconfigure (for each address extension) the server MAY indicate the DNS name. 3.2.5. Receiving a DHCP Release with the IP Address Extension When a DHCP client releases its IP address, by including an appropriate IP Address Extension with the DHCP Release message, the server determines whether or not it was originally responsible for updating the DNS AAAA record or PTR record for the client. If so, then the server must also perform the reverse service by updating DNS again to delete the client records. 3.3. DHCP Relay Considerations The DHCP Relay MUST NOT change any information in any DHCPv6 Extension fields. All Extension information flows between DHCPv6 Server and DHCPv6 Client without modification by any Relay. 4. General Extensions The following extensions are important for many DHCPv6 clients, and are not specific to any upper-level protocol. Perkins Expires 30 January 1998 [Page 11] Internet Draft DHCPv6 Extensions 30 July 1997 4.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 clock in seconds from Coordinated Universal Time (UTC). The offset is expressed as a signed (two's complement) 32-bit integer. 4.2. IEEE 1003.1 POSIX Timezone extension DHCP includes an extension for the specification of the Universal Coordinated Time Offset (type 2, defined in section 4.1), which is defined as a two's complement 32-bit integer representing the offset in seconds from UTC. Unfortunately, the UTC offset extension does not provide enough information for an Internet client to determine such timezone-related details as the timezone names, daylight savings time start and end times in addition to the timezone UTC offsets. This extension (analogous to that proposed for DHCPv4 [6]) allows delivery of timezone information in the form of a IEEE 1003.1 POSIX Timezone specifier [10]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IEEE 1003.1 POSIX Timezone string (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The extension type is 3. This IEEE 1003.1 POSIX Timezone is detailed next, in section 4.2.1. 4.2.1. IEEE 1003.1 POSIX Timezone specifier . The format of the IEEE 1003.1 POSIX timezone string is specified as StdOffset[Dst[Offset],[Start[/Time],End[/Time]]] Perkins Expires 30 January 1998 [Page 12] Internet Draft DHCPv6 Extensions 30 July 1997 where '[' and ']' enclose optional fields, '|' indicates choice of exactly one of the alternatives, ',' and '/' represent literal characters present in the string, and: Std three or more octets for the standard timezone (Std). Any characters (or case) except a leading colon, digits, comma, minus or plus sign are allowed. Offset Indicates the value one must add to local time to arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset following Std is required. Digits are always interpreted as decimal number. If preceded by a '-', the timezone is east of the Prime Meridian, otherwise it is west ('+' is optional) The permissible values for hh[:mm[:ss]] are as follows: hh 0 <= hh <= 23 mm 0 <= mm <= 60 ss 0 <= ss <= 60 Offset has no default value. Dst three or more octets for the daylight savings timezone. If Dst is missing, then daylight savings time does not apply in this locale. If no Offset follows Dst, then Dst is assumed to be one hour ahead of standard time. Any characters (or case) except a leading colon, digits, comma, minus or plus sign are allowed. Start Indicates the day of the year, in one of the formats indicated below, when to change to daylight savings time. The 'Time' field (which follows immediately after a '/' character, if present) indicates when the change is made, in local time. End Indicate the day of the year, in one of the formats indicated below, when to change back from daylight savings time. The 'Time' field (which follows immediately after a '/' character, if present) indicates when the change is made, in local time. Time Time has the same format as Offset, except that no leading '-' or '+' is permitted. The default is 02:00:00. The day of the year can be given in one of the following formats: Perkins Expires 30 January 1998 [Page 13] Internet Draft DHCPv6 Extensions 30 July 1997 Jn The julian day n, (1 <= n <= 365). Leap days are not counted. n zero-based julian day, (0 <= n <= 365). Leap days are counted so it is possible to refer to Feb 29. Mm.n.d The 'd'th day, (0 <= d <= 6) of week 'n' of month 'm' of the year (1 <= n <= 5, 1 <= m <= 12, where week 5 means last 'd' day in month 'm' which may occur in either the fourth or the fifth week. Week '1' is the first week in which the 'd' day occurs. 4.2.2. An Example For Eastern USA time zone, 1986, the Posix timezone string is as follows: EST5EDT4,116/02:00:00,298/02:00:00 4.2.3. Timezone 0ption Precedence If a DHCP client receives both the Time Offset (type 2) and the POSIX Timezone (type 3) extension in a DHCP reply message, the client MUST discard the value of the Time Offset (type 2) extension and utilize the POSIX Timezone Option. The DHCP client MAY notify the user that it is resolving the conflict by discarding the Time Offset (type 2) extension. If a DHCP client finds that the POSIX Timezone extension value is misformatted, it SHOULD notify the the user of the problem and MUST discard the entire extension value. Perkins Expires 30 January 1998 [Page 14] Internet Draft DHCPv6 Extensions 30 July 1997 4.3. 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 [16] 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. 4.4. Domain Name This extension specifies the default 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 IP 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. 5. Application and Service Parameters This section details some miscellaneous extensions used to configure miscellaneous applications and services. Perkins Expires 30 January 1998 [Page 15] Internet Draft DHCPv6 Extensions 30 July 1997 5.1. Directory Agent Extension Entities using the Service Location Protocol [21] need to find out the address of Directory Agents in order to transact messages. They may need to discover the correct scope to be used in conjunction with the service attributes which are exchanged using the Service Location Protocol. The scope MAY be denoted in any standardized character set. This extension requests or specifies a Directory Agent (DA), along with zero or more scopes supported by that DA. Note that this extension MAY be included multiple times in the same DHCP Request or DHCP Reply. If so, then the extensions SHOULD be included in order of decreasing preference. 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 | DA length |D|M|F|S| rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Directory Agent (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) Service Scope (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 Length (unsigned integer, variable) The length of the Extension in octets. Char Encoding The standardized encoding for the characters denoting the scope. DA Length (unsigned integer, variable) The length of the Directory Agent field in octets. D If the 'D' bit is set, the Directory Agent field 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. F If the 'F' bit is set, the Directory Agent is indicated by including its variable length host name or Fully Perkins Expires 30 January 1998 [Page 16] Internet Draft DHCPv6 Extensions 30 July 1997 Qualified Domain Name (FQDN) instead of its 16 octet IP address. S If the 'S' bit is set, the scope is present, encoded in the indicated character set. rsv reserved; ignored upon reception; MUST be sent as zero Directory Agent The Fully Qualified Domain Name (FQDN), host name, or IP address of the Directory Agent (see following description). Service Scope The characters denoting the scope. The length of the scope is only indicated implicitly by the overall length of the extension. In order to simplify administration of the configuration of Directory Agents for Service Location Protocol clients, the Directory Agent can be indicated by presenting its FQDN or host name instead of its IP address. This allows renumbering to proceed more smoothly [7]. When the FQDN or host name is used, the server sets the 'F' bit. The host name can be distinguished from the FQDN by the presence of a '.' character. In any case, the DA length field is set to be the length of the Directory Agent field. When the 'F' bit is not set, the DA Length MUST be 16. Note that more than one Directory Agent extension may be present in a DHCP message. Each such extension may have the same or different scope. The client may request any 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 characters denoting the scope. 5.2. Service Scope Extension This extension indicates a scope that should be used by a Service Agent (SA) [21], when responding to Service Request messages as Perkins Expires 30 January 1998 [Page 17] Internet Draft DHCPv6 Extensions 30 July 1997 specified by the Service Location Protocol. This extension MAY be included multiple times in the same DHCP Request or DHCP Reply. 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 | Service Scope ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 17 Length (unsigned integer, variable) The length of the Extension in octets. Char Encoding The standardized encoding for the characters denoting the scope. Service Scope the characters denoting the scope. Note that more than one Service Scope extension may be present in a DHCP message. The length of the scope is only indicated implicitly by the overall length of the extension. 5.3. Network Time Protocol Servers Extension This extension specifies a list of IP addresses indicating NTP [14] servers available to the client. Servers SHOULD be listed in order of preference. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type for this extension is 18. Its minimum Length is 16, and the Length MUST be a multiple of 16. Perkins Expires 30 January 1998 [Page 18] Internet Draft DHCPv6 Extensions 30 July 1997 5.4. Network Information Service Domain Extension This extension specifies the name of the client's NIS [13] domain. The domain is formatted as a character string consisting of characters from the US-ASCII character set. The type for this extension is 19. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS Domain Name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.5. Network Information Servers Extension This extension specifies a list of IP addresses indicating NIS [13] servers available to the client. Servers SHOULD be listed in order of preference. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type for this extension is 20. Its minimum Length is 16, and the Length MUST be a multiple of 16. 5.6. Network Information Service+ Domain Extension This extension specifies the name of the client's NIS+ [13] domain. The domain is formatted as a character string consisting of characters from the US-ASCII character set. Perkins Expires 30 January 1998 [Page 19] Internet Draft DHCPv6 Extensions 30 July 1997 The type for this extension is 21. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS+ Client Domain Name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.7. Network Information Service+ Servers Extension This extension specifies a list of IP addresses indicating NIS+ [13] servers available to the client. Servers SHOULD be listed in order of preference. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS+ server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The code for this extension is 22. Its minimum Length is 16, and the Length MUST be a multiple of 16. 5.8. Vendor Specific Information This extension is used by clients and servers to exchange vendor- specific information. The information is an opaque collection of data, 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 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 encodes more than one item of information in this extension, then the vendor MUST encode the extension using "Encapsulated vendor-specific extensions" as described below: Perkins Expires 30 January 1998 [Page 20] Internet Draft DHCPv6 Extensions 30 July 1997 The Encapsulated vendor-specific extensions field MUST be encoded as a sequence of type/length/value fields of identical syntax to the fields defined in every other DHCPv6 extension. Extension 65535 (END), if present, signifies the end of the encapsulated vendor extensions, not the end of the vendor extensions field. If no extension 65535 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 31 and its minimum Length is 4. 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 extension information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When encapsulated vendor-specific extensions are used, each one has the same format as just shown. 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. 6. TCP Parameters This section lists the extensions that affect the operation of the TCP layer on a per-interface basis. 6.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. Perkins Expires 30 January 1998 [Page 21] Internet Draft DHCPv6 Extensions 30 July 1997 The Type for this extension is 32, and its Length is 4. 7. DHCPv6 Extensions This section details the extensions that are specific to DHCPv6. 7.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 [4]), 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 permissible value is 1500. 7.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 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 class identifier specified by a client MUST ignore it (although it may be reported). Otherwise, servers SHOULD respond with the set of extensions corresponding to the class identifier specified by the client. Further, if the server responds with the set of extensions corresponding to the given class Perkins Expires 30 January 1998 [Page 22] Internet Draft DHCPv6 Extensions 30 July 1997 identifier, it MUST return this extension (with the given class identifier 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 string of characters in the character set specified by the Char Encoding field (see section 2.1), of length "Length"-2 octets. The class identifier represents the class identifier of which the client is a member. 7.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. 7.4. Renumber DHCPv6 Server Address A DHCPv6 server can instruct its clients to change their internal records to reflect the server's newly renumbered IP address, by using the "Renumber DHCPv6 Server Address" extension. This extension may be sent with the DHCP Reconfigure message, and thus can be multicast Perkins Expires 30 January 1998 [Page 23] Internet Draft DHCPv6 Extensions 30 July 1997 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. 7.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. 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 (unsigned integer, variable) 4 for the SPI, plus 8 for the replay protection, plus the number of octets in the Authenticator. SPI A Security Parameters index [3] identifying which security context among those available between the DHCPv6 client and server. Replay Protection A 64-bit timestamp (in Network Time Protocol [15](NTP) format) (see section 9.1). Perkins Expires 30 January 1998 [Page 24] Internet Draft DHCPv6 Extensions 30 July 1997 Authenticator (variable length) (See Section 9.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 has no IPv6 address of large enough scope to reach the DHCP server. 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 9.2. Note that SPI values 0 through 255 are reserved and, if used, MUST conform to the security context defined by that value in the most recent Assigned Numbers RFC (e.g., [18]). 7.6. Client Key Selection Extension A DHCPv6 server may wish to indicate to a prospective client which SPI it must use to authenticate subsequent messages, using the Client-Server Authentication Extension. In such cases, the server includes the Client Key Selection Extension in its DHCP Advertise message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 85 Length 4 SPI A Security Parameters index [3] identifying a security context between a pair of nodes among the contexts available in the security association defined between the DHCPv6 client and server. SPI values 0 through 255 are reserved and, if used, MUST conform to the security context defined by that value as defined in the most recent Assigned Numbers RFC (e.g., [9]). Perkins Expires 30 January 1998 [Page 25] Internet Draft DHCPv6 Extensions 30 July 1997 8. End extension specification The end extension marks the end of valid information in the vendor field. The Type for the end extension is 65535, and its Length is 2 octets; there is no Length field for the end extension. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 65535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9. 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 7.5. See also the Security Considerations in the companion specification [4]. 9.1. Replay Protection A 64-bit timestamp, in Network Time Protocol [15](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. 9.2. Default Authentication Algorithm The default authentication algorithm is HMAC [12], using keyed-MD5 [19]. 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 30 January 1998 [Page 26] Internet Draft DHCPv6 Extensions 30 July 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 octets in all previous fields in the DHCPv6 message and extensions. The authenticator is the 128-bit value HMAC_result. 10. Defining New Extensions Implementation specific use of undefined extensions (including those in the range 86-32767) may conflict with other implementations, and registration is required. The author of a new DHCP extension MUST follow these steps to obtain acceptance of the extension as a part of the DHCP Internet Standard: 1. The author devises the new extension. 2. The author requests a number for the new extension from IANA 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 3. The author documents the new extension, using the newly obtained extension number, as an Internet Draft. 4. The author submits the Internet Draft for review through the IETF standards process as defined in "Internet Official Protocol Standards" [11]. The new extension will be submitted for eventual acceptance as an Internet Standard. 5. The new extension progresses through the IETF standards process; the new extension will be reviewed by the Dynamic Host Configuration Working Group (if that group still exists), or as an Internet Draft not submitted by an IETF working group. Perkins Expires 30 January 1998 [Page 27] Internet Draft DHCPv6 Extensions 30 July 1997 6. If the new extension fails to gain acceptance as an Internet Standard, the assigned extension number will be returned to IANA for reassignment. This procedure for defining new extensions will ensure that: * allocation of new extension numbers is coordinated from a single authority, * new extensions are reviewed for technical correctness and appropriateness, and * documentation for new extensions is complete and published. Perkins Expires 30 January 1998 [Page 28] Internet Draft DHCPv6 Extensions 30 July 1997 11. Acknowledgements Thanks to Jim Bound for his frequent review, helpful suggestions, and design assistance. Ralph Droms has also made many, many suggestions which have been incorporated into this draft. The original form of this internet draft was copied directly from RFC1533 [1], written by Steve Alexander and Ralph Droms. Thanks to Erik Guttman for his helpful suggestions for the Service Location extensions. Thanks to Matt Crawford and Erik Nordmark for their careful review as part of the Last Call process. References [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 1533, October 1993. [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 2132, March 1997. [3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [4] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-11.txt, May 1997. (work in progress). [5] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [6] M. W. Carney. DHCP Option for IEEE 1003.1 POSIX Timezone Specifications. draft-ietf-dhc-timezone-01.txt, January 1997. (work in progress). [7] B. Carpenter and Y. Rekhter. Renumbering needs work. RFC 1900, February 1996. [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 1883, December 1995. [9] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [10] IEEE. 1003.1 POSIX Timezone Specification, 1988. [11] Editor J. Postel. INTERNET OFFICIAL PROTOCOL STANDARDS. STD 1, July 1997. Perkins Expires 30 January 1998 [Page 29] Internet Draft DHCPv6 Extensions 30 July 1997 [12] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [13] Sun Microsystems. System and Network Administration, March 1992. [14] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. RFC 2030, October 1996. [15] David L. Mills. Network Time Protocol (Version 3): Specification, Implementation and Analysis. RFC 1305, March 1992. [16] P. Mockapetris. Domain Names - Concepts and Facilities. STD 13, November 1987. [17] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2, October 1994. [18] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, October 1994. [19] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [20] S. Thomson and T. Narten. IPv6 stateless address autoconfiguration. RFC 1971, August 1996. [21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. RFC 2165, July 1997. [22] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System (DNS). RFC 2136, April 1997. Perkins Expires 30 January 1998 [Page 30] Internet Draft DHCPv6 Extensions 30 July 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 E. Perkins Technology Development Group Mail Stop MPK15-214 Room 2682 Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, California 94303 USA Phone: +1-415-786-6464 Fax: +1-415-786-6445 email: charles.perkins@Sun.COM Perkins Expires 30 January 1998 [Page 31]