Internet Engineering Task Force C. Perkins INTERNET DRAFT IBM 22 November 1996 Extensions for DHCPv6 draft-ietf-dhc-v6exts-03.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 22 May 1997 [Page i] Internet Draft DHCPv6 Extensions 22 November 1996 Contents Status of This Memo i Abstract i 1. Introduction 1 2. DHCPv6 Extension Field Format 1 3. Padding and End extension specifications 2 3.1. Pad Extension . . . . . . . . . . . . . . . . . . . . . . 2 3.2. End Extension . . . . . . . . . . . . . . . . . . . . . . 2 4. IPv6 Address Extension 2 4.1. Client Considerations for the IPv6 Address extension . . 4 4.1.1. Address Lifetimes . . . . . . . . . . . . . . . . 4 4.1.2. Use with the DHCP Request message . . . . . . . . 5 4.1.3. Use with the DHCP Release message . . . . . . . . 6 4.2. Server Considerations for the IPv6 Address extension . . 6 4.2.1. Use with the DHCP Advertise message . . . . . . . 6 4.2.2. Receiving a DHCP Request with the IPv6 Address Extension . . . . . . . . . . . . . . . . 6 4.2.3. Use with the DHCP Reply message . . . . . . . . . 7 4.2.4. Use with the DHCP Reconfigure message . . . . . . 7 4.3. DHCP Relay Considerations . . . . . . . . . . . . . . . . 7 5. General Extensions 8 5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 8 5.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 8 6. Service Location Extensions 9 6.1. Directory Agent Extension . . . . . . . . . . . . . . . . 9 6.2. Service Scope Extension . . . . . . . . . . . . . . . . . 10 7. IP Layer Parameters per Interface 10 7.1. Static Route Extension . . . . . . . . . . . . . . . . . 10 8. TCP Parameters 11 8.1. TCP Keepalive Interval Extension . . . . . . . . . . . . 11 9. Vendor Specific Information 11 Perkins Expires 22 May 1997 [Page ii] Internet Draft DHCPv6 Extensions 22 November 1996 10. DHCPv6 Extensions 12 10.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . . 12 10.2. Class Identifier . . . . . . . . . . . . . . . . . . . . 13 10.3. Reconfigure Multicast Address . . . . . . . . . . . . . . 13 10.4. Renumber DHCPv6 Server Address . . . . . . . . . . . . . 14 10.5. Client-Server Authentication Extension . . . . . . . . . 14 11. Security Considerations 15 11.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 15 11.2. Default Authentication Algorithm . . . . . . . . . . . . 15 12. New Extensions 16 13. Acknowledgements 16 Chair's Address 18 Author's Address 18 Perkins Expires 22 May 1997 [Page iii] Internet Draft DHCPv6 Extensions 22 November 1996 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. Although extension numbers in this document correspond closely to the analogous numbers in the options specification for IPv4 [1], there is no requirement to keep numbering future extensions in any consistent manner except purely as a matter of editorial and cross-referencing convenience. Future applications will make extensive use of an ever-increasing number and variety of network services. It is expected that client needs for creating connections with these future network services will be satisfied by the Service Location Protocol [10], and not DHCPv6. DHCP is expected to be used for the kinds of configuration that enable clients to become fully functional as self-contained network entities, but not the kinds of configuration that might be required by applications running above the network or transport layer protocol levels. 2. DHCPv6 Extension Field Format DHCPv6 extensions have the same format as the BOOTP "vendor extensions" defined in RFC 1497 [8]. 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. Perkins Expires 22 May 1997 [Page 1] Internet Draft DHCPv6 Extensions 22 November 1996 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. 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 code 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 is relatively complex and and 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 Perkins Expires 22 May 1997 [Page 2] Internet Draft DHCPv6 Extensions 22 November 1996 in the same extension, hence the added complexity. Some of this added complexity also derives from various possible ways that updating DNS may be specified within the IPv6 Address extension. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ext-type | ext-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|L|Q|A|P| reserved | pfx-size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) | | client address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) preferred lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) valid lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) DNS name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ext-type 1 ext-length The length of the Extension. C If the 'C' bit is set, the field containing the IPv6 address for the client is present in the extension. 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. Perkins Expires 22 May 1997 [Page 3] Internet Draft DHCPv6 Extensions 22 November 1996 rsv MUST be zero. pfx-size If the client address is present (the 'C' bit is set), then the pfx-size indicates the length of the routing prefix, counting the number of leading 1 bits to be applied to the client's IPv6 address to get the routing prefix. Otherwise, if the 'C' bit is not set, pfx-size MUST be zero. NOTE: the pfx-size field is only 7 bits long. 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 ext-length, the length of those fixed-length fields which are present. If the last byte of the DNS name is not zero, the IPv6 Address Extension MUST be rejected. 4.1. Client Considerations for the IPv6 Address extension 4.1.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. Perkins Expires 22 May 1997 [Page 4] Internet Draft DHCPv6 Extensions 22 November 1996 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; - 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. Perkins Expires 22 May 1997 [Page 5] Internet Draft DHCPv6 Extensions 22 November 1996 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. Upon reception of a new IP address, the client must perform Duplicate Address Detection (DAD) [7]; however, if the address has already been allocated to the client and it is merely renewing the lifetime of the address, the client does not have to perform DAD each time. 4.1.3. Use with the DHCP Release message In DHCP Release (for each address extension): - 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 Perkins Expires 22 May 1997 [Page 6] Internet Draft DHCPv6 Extensions 22 November 1996 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 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 - whether PTR has been DNS updated 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. Subsequently, the client can update DNS if needed (i.e., the server didn't do it). 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. Perkins Expires 22 May 1997 [Page 7] Internet Draft DHCPv6 Extensions 22 November 1996 5. General Extensions The following extensions are important for many DHCPv6 clients, and are not specific to any upper-level protocol. 5.1. Time Offset 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. The type for the time offset extension is 2, and its length is 4 octets. Type Length Time Offset +-----+-----+-----+-----+-----+-----+-----+-----+ | 8 | 4 | n1 | n2 | n3 | n4 | +-----+-----+-----+-----+-----+-----+-----+-----+ 5.2. Domain Name Server Extension The domain name server extension specifies a list of Domain Name System (STD 13, RFC 1035 [6]) 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. Type Length Address 1 Address 2 +-----+-----+-----+-----+-----+-----+---+-----+-----+-----+---+-----+--- | 9 | n | a1 | a2 |...| a16 | a1 | a2 |...| a16 |... +-----+-----+-----+-----+-----+-----+---+-----+-----+-----+---+-----+--- 5.3. Domain Name This extension specifies the domain name that client should use when resolving hostnames via the Domain Name System. The type for this extension is 10. Its minimum length is 1. Type Length Domain Name +-----+-----+-----+-----+-----+-----+-----+-----+-- | 10 | n | d1 | d2 | d3 | d4 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- Perkins Expires 22 May 1997 [Page 8] Internet Draft DHCPv6 Extensions 22 November 1996 The domain name is a null-terminated ASCII string, of length 'n' octets including the terminating null 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) [10], along with zero or more scopes supported by that DA. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scope count |D|M| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) | | Directory Agent address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scope list ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 Length variable 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. Perkins Expires 22 May 1997 [Page 9] Internet Draft DHCPv6 Extensions 22 November 1996 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 This extension indicates a scope that should be used by a Service Agent (SA) [10], when responding to Service Request messages as specified by the Service Location Protocol. Type Length +-----+-----+-----+-----+-----+----- | 17 | n | Scope ... +-----+-----+-----+-----+-----+----- Scope is a null-terminated ASCII string, of length 'n' octets including the terminating null octet. 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 This extension specifies a list of static routes that the client should install in its routing cache. If multiple routes to the same 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. Perkins Expires 22 May 1997 [Page 10] Internet Draft DHCPv6 Extensions 22 November 1996 The type for this extension is 24. The minimum length of this extension is 24, and the length MUST be a multiple of 16. Type Length Destination 1 Router 1 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 24 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Destination 2 Router 2 +-----+-----+-----+-----+-----+-----+-----+-----+--- | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ... +-----+-----+-----+-----+-----+-----+-----+-----+--- 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 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. Type Length Time +-----+-----+-----+-----+-----+-----+-----+-----+ | 32 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+-----+-----+ 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 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. Perkins Expires 22 May 1997 [Page 11] Internet Draft DHCPv6 Extensions 22 November 1996 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. Type Length Vendor-specific information +-----+-----+-----+-----+-----+-----+--- | 40 | n | i1 | i2 | ... +-----+-----+-----+-----+-----+-----+--- 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 | ... | ... | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 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. Perkins Expires 22 May 1997 [Page 12] Internet Draft DHCPv6 Extensions 22 November 1996 The type for this extension is 64, and its length is 2. The minimum legal value is 1500. Type Length Size +-----+-----+-----+-----+-----+-----+ | 64 | 2 | l1 | l2 | +-----+-----+-----+-----+-----+-----+ 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. The class identifier is a null-terminated NVT ASCII string, of length 'n' octets including the terminating null octet, that represents the user class of which the client is a member. 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 class, it MUST return this extension (with the given user class value) to the client. The type for this extension is 65, and its minimum length is 1. Type Length Class-Identifier +-----+-----+-----+-----+-----+-----+--- | 65 | n | i1 | i2 | ... +-----+-----+-----+-----+-----+-----+--- 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. Perkins Expires 22 May 1997 [Page 13] Internet Draft DHCPv6 Extensions 22 November 1996 Type Length IPv6 Multicast Address +-----+-----+-----+-----+-----+-----+-----+-----+ | 66 | 16 | a1 | a2 | ... | a16 | +-----+-----+-----+-----+-----+-----+-----+-----+ 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 multicast to all of the server's clients instead of being unicast to each one individually. Type Length New IPv6 Server Address +-----+-----+-----+-----+-----+-----+ | 67 | 16 | a1 | a2 | ... | a16 | +-----+-----+-----+-----+-----+-----+ 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 placed after every other extension. Type Length Security Parameter ndx replay protect +-----+------+-----+-----+-----+-----+-----+-----+-----+---+-----+---+- | 80 | 12+x | sp1 | sp2 | sp3 | sp4 | rp1 |...| rp8 |Auth +-----+------+-----+-----+-----+-----+-----+-----+-----+---+-----+---+- 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 MUST NOT be used in any Client-Server Authentication Extension. Replay Protection A 64-bit timestamp (in Network Time Protocol [5](NTP) format) (see section 11.1). Perkins Expires 22 May 1997 [Page 14] Internet Draft DHCPv6 Extensions 22 November 1996 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. 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 [5](NTP) format, is used to protect against replay of previous authenticated messages by malicious agents. The NTP timestamp value used in the extension MUST be chosen, and verified, to be larger than values used by the originator in previous Client-Server Authentication extensions. On the other hand, the timestamp value MUST also be chosen (and verified) to be no greater than one year more than the last known value (if any) used by the originator. 11.2. Default Authentication Algorithm The default authentication algorithm uses keyed-MD5 [9] in "prefix+suffix" mode to compute a 128-bit "message digest" of the registration message. The default authenticator is a 128-bit value computed as the MD5 checksum over the the following stream of bytes: - the shared secret defined by the security association between the client and server and by the SPI value specified in the Authentication Extension, followed by - all previous fields in the DHCPv6 message and extensions, followed by - the shared secret again. Perkins Expires 22 May 1997 [Page 15] Internet Draft DHCPv6 Extensions 22 November 1996 12. New Extensions Additional generic data fields 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 generic types (including those in the range 72-127) may conflict with other implementations, and registration is required. DISCUSSION: Need to read Ralph's new draft and incorporate those ideas here. 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 22 May 1997 [Page 16] Internet Draft DHCPv6 Extensions 22 November 1996 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-05.txt -- work in progress, June 1996. [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 1883, December 1995. [5] David L. Mills. Network Time Protocol (Version 3): Specification, Implementation and Analysis. RFC 1305, March 1992. [6] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC 1035, November 1987. [7] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). draft-ietf-ipngwg-discovery-06.txt -- work in progress, March 1996. [8] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, August 1993. [9] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [10] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. draft-ietf-svrloc-protocol-14.txt - work in progress, June 1996. Perkins Expires 22 May 1997 [Page 17] Internet Draft DHCPv6 Extensions 22 November 1996 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 Room H3-D34 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-6205 E-mail: perk@watson.ibm.com Perkins Expires 22 May 1997 [Page 18]