Internet Engineering Task Force C. Perkins INTERNET DRAFT IBM 22 February 1996 Extensions for DHCPv6 draft-ietf-dhc-v6exts-00.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 tagged 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 August 1996 [Page i] Internet Draft DHCPv6 Extensions 22 February 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 specification 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.3. Receiving a DHCP Request with the IPv6 Address Extension 6 4.3.1. Use with the DHCP Reply message . . . . . . . . . 6 4.3.2. Use with the DHCP Reconfigure message . . . . . . 7 4.4. DHCP Relay Considerations . . . . . . . . . . . . . . . . 7 4.5. Alternate Design possibility . . . . . . . . . . . . . . 7 5. General Extensions 8 5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Router Extension . . . . . . . . . . . . . . . . . . . . 8 5.3. Domain Name Server Extension . . . . . . . . . . . . . . 9 5.4. Resource Location Server Extension . . . . . . . . . . . 9 5.5. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 9 6. IP Layer Parameters per Interface 10 6.1. Static Route Extension . . . . . . . . . . . . . . . . . 10 7. TCP Parameters 10 7.1. TCP Default TTL Extension . . . . . . . . . . . . . . . . 10 7.2. TCP Keepalive Interval Extension . . . . . . . . . . . . 11 8. Vendor Specific Information 11 9. DHCPv6 Extensions 12 Perkins Expires 22 August 1996 [Page ii] Internet Draft DHCPv6 Extensions 22 February 1996 9.1. Maximum DHCPv6 Message Size . . . . . . . . . . . . . . . 12 9.2. Class-identifier . . . . . . . . . . . . . . . . . . . . 13 9.3. Mobile Home Address Extension . . . . . . . . . . . . . . 13 10. Neighbor Discovery Extensions 14 11. Extensions 14 12. Acknowledgements 14 13. Security Considerations 14 Chair's Address 17 Author's Address 17 Perkins Expires 22 August 1996 [Page iii] Internet Draft DHCPv6 Extensions 22 February 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 11. Although extension numbers in this document correspond closely to the analogous numbers in the options specification for IPv4 [2], there is no requirement to keep numbering future extensions in any consistent manner except purely as a matter of editorial and cross-referencing convenience. 2. DHCPv6 Extension Field Format DHCPv6 extensions have the same format as the BOOTP "vendor extensions" defined in RFC 1497 [7]. Extensions may be fixed length or variable length. All extensions begin with a tag octet, which uniquely identifies the extension. Fixed-length extensions without data consist of only a tag octet. Only extensions 0 and 255 are fixed length. All other extensions are variable-length with a length octet following the tag octet. The value of the length octet does not include the two octets specifying the tag and length. The length octet is followed by "length" octets of data. In the case of some variable-length extensions the length field is a constant but must still be specified. Any extensions defined subsequent to this document should contain a length octet even if the length is fixed or zero. All multi-octet quantities are in network byte-order. Extension codes 128 to 254 (decimal) are reserved for site-specific extensions. All of the extensions described in this document will also have their default values specified, if any. Perkins Expires 22 August 1996 [Page 1] Internet Draft DHCPv6 Extensions 22 February 1996 DISCUSSION: Should the DHCPv6 Extensions be put into a format similar to IPv6 options? DISCUSSION: Should individual Extensions in Request messages be rejected individually? 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 code for the pad extension is 0, and its length is 1 octet. Code +-----+ | 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 code for the end extension is 255, and its length is 1 octet. Code +-----+ | 255 | +-----+ 4. IPv6 Address extension specification 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 in the same extension, hence the added complexity. Much of this added complexity also derives from various possible ways that updating DNS may be specified within the IPv6 Address extension. Perkins Expires 22 August 1996 [Page 2] Internet Draft DHCPv6 Extensions 22 February 1996 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|P|V|N|D|Q|A|P| 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. P If the 'P' bit is set, the preferred lifetime is present in the extension. V If the 'V' bit is set, the valid lifetime is present in the extension. N If the 'N' bit is set, the extension contains the DNS name subfield. D If the 'D' bit is set, the client is not required to perform Duplicate Address Detection. M If the 'M' bit is set, the fields included by the client are mandatory, 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 update the DNS specified by the client's FQDN with Perkins Expires 22 August 1996 [Page 3] Internet Draft DHCPv6 Extensions 22 February 1996 a new AAAA record before responding with the corresponding DHCP Reply. P If the 'P' bit is set, the server MUST update the DNS specified by the client's FQDN with a new PTR record before responding with the corresponding DHCP Reply. 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. 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 valid lifetime The valid lifetime of the IPv6 address DNS name The DNS name (a zero-terminated character string) to be used by the client (variable length). The DNS name can be either a host name, which does not contain the '.' 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 the length of those fixed-length fields which are present from the ext-length. 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 Perkins Expires 22 August 1996 [Page 4] Internet Draft DHCPv6 Extensions 22 February 1996 MUST assume the client does not want that address. The server MAY provide that address to another client requesting an address, after all other addresses available to the server have been exhausted. 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). 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 name and/or FQDN. - request that server DNS update AAAA and/or PTR record. - specify whether address and/or name (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 address listed in the IP Address extension to the DHCP Request, by specifying the 'M' (Mandatory) bit. Note that to delete DNS information, a client can use a DHCP Release message. Perkins Expires 22 August 1996 [Page 5] Internet Draft DHCPv6 Extensions 22 February 1996 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 4.3. Receiving a DHCP Request with the IPv6 Address Extension If the client has requested that the server perform DNS updates as part of the IPv6 address allocation and configuration, the server must maintain this fact as part of the client's binding. Then, if the client eventually releases the IPv6 address (by including an appropriate IPv6 Address with the DHCP Release message), the server can perform the reverse service by updating DNS again as needed. 4.3.1. 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 Perkins Expires 22 August 1996 [Page 6] Internet Draft DHCPv6 Extensions 22 February 1996 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 'M' 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.3.2. Use with the DHCP Reconfigure message In DHCP Reconfigure (for each address extension) the server can indicate - the DNS name 4.4. 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.5. Alternate Design possibility DISCUSSION: Instead of trying to collect together everything about IPv6 addresses in one single extension, it would also be possible to break the DNS stuff into separate Extensions. Since there may be multiple such IPv6 addresses allocated in a single DHCP Reply, we would have to adopt the convention that the subsequent extensons relevant to IPv6 addresses apply always to the last IPv6 address in the closest preceding IPv6 address extension. Perkins Expires 22 August 1996 [Page 7] Internet Draft DHCPv6 Extensions 22 February 1996 I find the above sort of context-sensitive Extension processing is a cure worse than the disease of a single mildly complicated IPv6 Address Extension which has all the stuff an IPv6 address needs. 5. General Extensions 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 code for the time offset extension is 2, and its length is 4 octets. Code Len Time Offset +-----+-----+-----+-----+-----+-----+ | 2 | 4 | n1 | n2 | n3 | n4 | +-----+-----+-----+-----+-----+-----+ 5.2. Router Extension The router extension specifies a list of IP addresses for routers on the client's subnet. Routers SHOULD be listed in order of preference. The code for the router extension is 3. The minimum length for the router extension is 16 octets, and the length MUST always be a multiple of 16. Code Len Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- | 3 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- Perkins Expires 22 August 1996 [Page 8] Internet Draft DHCPv6 Extensions 22 February 1996 5.3. Domain Name Server Extension The domain name server extension specifies a list of Domain Name System (STD 13, RFC 1035 [5]) name servers available to the client. Servers SHOULD be listed in order of preference. The code for the domain name server extension is 6. The minimum length for this extension is 16 octets, and the length MUST always be a multiple of 16. Code Len Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- | 6 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 5.4. Resource Location Server Extension This extension specifies a list of Resource Location servers [8] available to the client. Servers SHOULD be listed in order of preference. The code for this extension is 11. The minimum length for this extension is 16 octets, and the length MUST always be a multiple of 16. Code Len Address 1 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- | 11 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 5.5. Domain Name This extension specifies the domain name that client should use when resolving hostnames via the Domain Name System. The code for this extension is 15. Its minimum length is 1. Code Len Domain Name +-----+-----+-----+-----+-----+-----+-- | 15 | n | d1 | d2 | d3 | d4 | ... +-----+-----+-----+-----+-----+-----+-- Perkins Expires 22 August 1996 [Page 9] Internet Draft DHCPv6 Extensions 22 February 1996 6. 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. 6.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 descending order of priority. 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, and the default route (0.0.0.0) is an illegal destination for a static route. See section 5.2 for information about the router extension. The code for this extension is 33. The minimum length of this extension is 32, and the length MUST be a multiple of 16. Code Len Destination 1 Router 1 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 33 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ Destination 2 Router 2 +-----+-----+-----+-----+-----+-----+-----+-----+--- | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ... +-----+-----+-----+-----+-----+-----+-----+-----+--- 7. TCP Parameters This section lists the extensions that affect the operation of the TCP layer on a per-interface basis. 7.1. TCP Default TTL Extension This extension specifies the default TTL that the client should use when sending TCP segments. The value is represented as an 8-bit unsigned integer. The minimum value is 1. Perkins Expires 22 August 1996 [Page 10] Internet Draft DHCPv6 Extensions 22 February 1996 The code for this extension is 37, and its length is 1. Code Len TTL +-----+-----+-----+ | 37 | 1 | n | +-----+-----+-----+ 7.2. TCP Keepalive Interval Extension This extension specifies the interval (in seconds) that the 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 code for this extension is 38, and its length is 4. Code Len Time +-----+-----+-----+-----+-----+-----+ | 38 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+ 8. 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. 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: - Codes other than 0 or 255 MAY be redefined by the vendor within the encapsulated vendor-specific extensions field, Perkins Expires 22 August 1996 [Page 11] Internet Draft DHCPv6 Extensions 22 February 1996 but SHOULD conform to the tag-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 code for this extension is 43 and its minimum length is 1. Code Len Vendor-specific information +-----+-----+-----+-----+--- | 43 | n | i1 | i2 | ... +-----+-----+-----+-----+--- When encapsulated vendor-specific extensions are used, the information bytes 1-n have the following format: Code Len Data item Code Len Data item Code +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 9. DHCPv6 Extensions This section details the extensions that are specific to DHCPv6. 9.1. Maximum DHCPv6 Message Size This extension specifies the maximum length DHCPv6 message that it is willing to accept. The length 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. The code for this extension is 57, and its length is 2. The minimum legal value is 1500 octets. Code Len Length +-----+-----+-----+-----+ | 57 | 2 | l1 | l2 | +-----+-----+-----+-----+ Perkins Expires 22 August 1996 [Page 12] Internet Draft DHCPv6 Extensions 22 February 1996 9.2. Class-identifier This extension may be used by DHCPv6 clients to identify the type and configuration of a DHCPv6 client. The information is a string of n octets, interpreted by servers. Vendors and sites may choose to define specific class identifiers to convey particular configuration or other identification information about a client. For example, the identifier may encode the client's hardware configuration. Servers not equipped to interpret the class-specific information sent by a client MUST ignore it (although it may be reported). The code for this extension is 60, and its minimum length is 1. Code Len Class-Identifier +-----+-----+-----+-----+--- | 60 | n | i1 | i2 | ... +-----+-----+-----+-----+--- 9.3. Mobile Home Address Extension When this extension is present in a client request message, the DHCPv6 server is asked to send an appropriate home address to the mobile host. The DHCPv6 server, in its corresponding offering message, will insert the requested address into the usual place for requested IP addresses. The DHCPv6 server will typically notify the mobile host of (one of) its home agents' addresses, as configured by the local administration to be associated with the address given to the mobile host. That home agent's IP address is inserted in the data field of the mobile home address extension. A mobile node with a known mobile home address can dynamically discover the location of a home agent serving the home address [1]. In that case, the DHCPv6 server may be configured to send out mobile home addresses and expect that the mobile host discover the home agent's address by whichever method is approved by the working group. It is also anticipated that many installations will allow several home agents to serve the same mobile home addresses, for redundancy or load sharing. For this reason, we have also allowed for the possibility that the DHCPv6 server may wish to insert multiple home agent addresses in the mobile home address extension. The format of the mobile home address extension is as follows: Code Len Home Address +----+----+-----+-----+-----+-----+ | 68 | n | a1 | a2 | ... | a16 | Perkins Expires 22 August 1996 [Page 13] Internet Draft DHCPv6 Extensions 22 February 1996 +----+----+-----+-----+-----+-----+ Home Agent Addresses (zero or more) +----+----+-----+-----+-----+ - --+ - -+ - -+ - -+ | a1 | a2 | ... | a16 | ... +----+----+-----+-----+-----+ - --+ - -+ - -+ - -+ The code for the mobile home address extension is 68. The length is 16, plus 16 octets multiplied by the number of home agents supplied in the extension, which may be zero or more. It is expected that the usual length will be 32 octets, containing a single home agent's address. 10. Neighbor Discovery Extensions This section contains extension definitions for specifying parameters that are useful with IPv6 Neighbor Discovery [6]. 11. 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 69-127) may conflict with other implementations, and registration is required. DISCUSSION: Need to read Ralph's new draft and incorporate those ideas here. 12. Acknowledgements Quite a bit of this internet draft is copied directly from RFC1533 [2], written by Steve Alexander and Ralph Droms. 13. Security Considerations Security issues are not discussed in this memo. However, there is an urgent need to define some security protocol for use with Perkins Expires 22 August 1996 [Page 14] Internet Draft DHCPv6 Extensions 22 February 1996 DHCPv6, since otherwise malicious parties could create numerous denial-of-service style attacks based on depleting available server resources or providing corrupted or infected data to unsuspecting clients. DISCUSSION: SHOULD there be a DHCP Authentication Extension, or should security be accomplished end-to-end by IPSec, but with intermediary relays performing encapsulation so as not to disturb the IPSec-style end-to-end authentication. Perkins Expires 22 August 1996 [Page 15] Internet Draft DHCPv6 Extensions 22 February 1996 References [1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-15.txt - work in progress, February 1996. [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 1533, October 1993. [3] J. Bound and C. Perkins. Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6-04.txt -- work in progress, February 1995. [4] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 1883, December 1995. [5] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC 1035, November 1987. [6] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in progress, November 1995. [7] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, August 1993. [8] J. Veizades, S. Kaplan, E. Guttman, and C. Perkins. Service Location Protocol. draft-ietf-svrloc-protocol-09.txt - work in progress, February 1996. Perkins Expires 22 August 1996 [Page 16] Internet Draft DHCPv6 Extensions 22 February 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 J1-A25 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 August 1996 [Page 17]