Internet Engineering Task Force J. Bound INTERNET DRAFT Compaq Computer Corp. DHC Working Group M. Carney Obsoletes: draft-ietf-dhc-dhcpv6-14.txt Sun Microsystems, Inc C. Perkins Nokia Research Center 5 May 2000 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-15.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 and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters using extensions to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to ``IPv6 Stateless Address Autoconfiguration'' [15], and can be used separately or concurrently with the latter to obtain configuration parameters. Bound, Carney, Perkins Expires 1 November 2000 [Page i] Internet Draft DHCP for IPv6 5 May 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3 3. DHCP Constants 5 3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5 3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 6 3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Generic Error Values . . . . . . . . . . . . . . 8 3.4.2. Server-specific Error Values . . . . . . . . . . 8 3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8 4. Requirements 9 5. Background 9 6. Design Goals 11 7. Non-Goals 11 8. Overview 12 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 12 8.2. How does a client find out about DHCP agents? . . . . . . 12 8.3. What if the client and server(s) are on different links? 12 8.4. How does a client request configuration parameters from servers? . . . . . . . . . . . . . . . . . . . . . . . 13 8.5. What are releasable resources, and when are they used? . 13 8.6. Can a client release its releasable resources before the lease expires? . . . . . . . . . . . . . . . . . . . . . . . 14 8.7. What if the client determines its releasable resource is already being used by another client? . . . . . . . . 14 8.8. How are clients notified of server configuration changes? 14 9. Message Formats 15 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 15 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 16 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 18 Bound, Carney, Perkins Expires 1 November 2000 [Page ii] Internet Draft DHCP for IPv6 5 May 2000 9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 19 9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 20 9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 22 9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 23 9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24 10. DHCP Server Solicitation and Subnet Prefix Discovery 25 10.1. Solicit Message Validation . . . . . . . . . . . . . . . 25 10.2. Advertise Message Validation . . . . . . . . . . . . . . 25 10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26 10.3.1. Creation and sending of the Solicit message . . . 26 10.3.2. Time out and retransmission of Solicit Messages . 27 10.3.3. Receipt of Advertise messages . . . . . . . . . . 27 10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28 10.4.1. Relaying of Solicit messages . . . . . . . . . . 28 10.4.2. Relaying of Advertise messages . . . . . . . . . 28 10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28 10.5.2. Creation and sending of Advertise messages . . . 29 11. DHCP Client-Initiated Configuration Exchange 29 11.1. Request Message Validation . . . . . . . . . . . . . . . 29 11.2. Reply Message Validation . . . . . . . . . . . . . . . . 30 11.3. Release Message Validation . . . . . . . . . . . . . . . 31 11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 11.4.1. Creation and sending of Request messages . . . . 32 11.4.2. Time out and retransmission of Request Messages . 33 11.4.3. Receipt of Reply message in response to a Request 33 11.4.4. Creation and sending of Release messages . . . . 33 11.4.5. Time out and retransmission of Release Messages . 34 11.4.6. Receipt of Reply message in response to a Release 35 11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 35 11.5.1. Relaying of Request or Release messages . . . . . 35 11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 11.6.1. Receipt of Request messages . . . . . . . . . . . 35 11.6.2. Receipt of Release messages . . . . . . . . . . . 36 11.6.3. Creation and sending of Reply messages . . . . . 36 12. DHCP Server-Initiated Configuration Exchange 37 12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37 12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38 12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 12.4.1. Creation and sending of Reconfigure messages . . 39 12.4.2. Time out and retransmission of Reconfigure messages . . . . . . . . . . . . . . . . . 40 12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40 12.4.4. Creation and sending of Reconfigure-init messages 40 Bound, Carney, Perkins Expires 1 November 2000 [Page iii] Internet Draft DHCP for IPv6 5 May 2000 12.4.5. Time out and retransmission of Reconfigure-init messages . . . . . . . . . . . . . . . . . 41 12.4.6. Receipt of Request messages . . . . . . . . . . . 41 12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41 12.5.1. Receipt of Reconfigure messages . . . . . . . . . 42 12.5.2. Creation and sending of Reconfigure-reply messages 42 12.5.3. Receipt of Reconfigure-init messages . . . . . . 43 12.5.4. Creation and sending of Request messages . . . . 43 12.5.5. Time out and retransmission of Request messages . 43 12.5.6. Receipt of Reply messages . . . . . . . . . . . . 43 13. Using DHCP for network renumbering 43 13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . . 44 13.2. Active Renumbering . . . . . . . . . . . . . . . . . . . 44 14. DHCP Client Implementator Notes 44 14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 14.2. Advertise Message and Configuration Parameter Caching . . 45 14.3. Time out and retransmission variables . . . . . . . . . . 45 14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 45 15. DHCP Server Implementator Notes 46 15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 15.2. Reconfigure Considerations . . . . . . . . . . . . . . . 46 15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 46 15.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 16. DHCP Relay Implementator Notes 47 17. Open Issues for Working Group Discussion 47 17.1. Trade-offs: Optional fields in DHCP messages . . . . . . 47 17.2. Use DHCPv4 authentication or the current DHCPv6 method? . 48 17.3. The Reconfigure Message and Subnet Prefix Extensions . . 48 17.4. ``R'' bit in Request message not needed? . . . . . . . . 48 18. Security Considerations 48 19. Year 2000 considerations 49 20. IANA Considerations 49 21. Acknowledgements 50 A. Comparison between DHCPv4 and DHCPv6 50 B. Full Copyright Statement 52 Chair's Address 55 Bound, Carney, Perkins Expires 1 November 2000 [Page iv] Internet Draft DHCP for IPv6 5 May 2000 Author's Address 55 Bound, Carney, Perkins Expires 1 November 2000 [Page v] Internet Draft DHCP for IPv6 5 May 2000 1. Introduction This document describes DHCP for IPv6 (DHCP), a UDP [14] client / server protocol designed to reduce the cost of management of IPv6 nodes in environments where network managers require more control over the allocation of network resources more varied than that offered by ``IPv6 Stateless Autoconfiguration'' [15]. The DHCP is a stateful counterpart to stateless autoconfiguration. Note that both stateful and stateless autoconfiguration can be used concurrently in the same environment, leveraging the strengths of both mechanisms in order to reduce the cost of ownership and management of network nodes. The DHCP reduces the cost of ownership by centralizing the management of network resources such as IP addresses, routing information, OS installation information, directory service information, and other such information on a few DHCP servers, rather than distributing such information in local configuration files among each network node. The DHCP is designed to be easily extended to carry new configuration parameters through the addition of new DHCP ``extensions'' defined to carry this information. See this document's companion specification, ``Extensions for the Dynamic Host Configuration Protocol for IPv6'' [2] for specifications of existing extensions as well as information on the process by which an interested party might specify new extensions. Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6 provides a superset of features, and benefits from the additional features of IPv6 and freedom from BOOTP [5]-backward compatibility constraints. For more information about the differences between DHCP for IPv6 and DHCP for IPv4, see Appendix A. This document is organized as follows. Section 2 defines terminology used throughout this document. Section 3 defines constant values used by DHCP. Section 4 briefly discusses requirement levels. Section 5 points the reader to helpful background specifications covering related IPv6 protocols. Section 6 discusses the design goals that influenced DHCP. Section 7 identifies some of the non-goals of this specification. Section 8 gives a high level overview of DHCP, its message types, and identifies DHCP functional entities (client, relay, server). Section 9 describes in detail the format of each DHCP message type. Section 10 discusses DHCP server solicitation and subnet prefix discovery. Section 11 discusses DHCP client-initiated configuration information exchange. Section 12 discusses DHCP server-initiated configuration information exchange. Section 13 describes how DHCP can be used to renumber networks. Section 14 presents helpful notes for DHCP client implementators. Section 15 presents helpful notes for DHCP server implementors. Bound, Carney, Perkins Expires 1 November 2000 [Page 1] Internet Draft DHCP for IPv6 5 May 2000 Section 16 presents helpful notes for DHCP relay implementors. Section 18 discusses security considerations for DHCP. 2. Terminology 2.1. IPv6 Terminology IPv6 terminology relevant to this specification from the IPv6 Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless Address Autoconfiguration [15] is included below. address An IP layer identifier for an interface or a set of interfaces. unicast address An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. multicast address An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. host Any node that is not a router. IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 are used only in contexts where it is necessary to avoid ambiguity. interface A node's attachment to a link. link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernet (simple or bridged); Token Ring; PPP links, X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. link-layer identifier a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet or Token Ring network interfaces, and E.164 addresses for ISDN links. link-local address An IP address having link-only scope, indicated by Bound, Carney, Perkins Expires 1 November 2000 [Page 2] Internet Draft DHCP for IPv6 5 May 2000 having the subnet prefix (FE80::0000/64), that can be used to reach neighboring nodes attached to the same link. Every interface has a link-local address. message A unit of data carried in a packet, exchanged between DHCP agents and clients. neighbor A node attached to the same link. node A device that implements IP. packet An IP header plus payload. prefix A bit string that consists of some number of initial bits of an address. router A node that forwards IP packets not explicitly addressed to itself. 2.2. DHCP Terminology Terminology specific to DHCP can be found below. abort status A status value returned to the application that has invoked a DHCP client operation, indicating anything other than success. agent address The address of a neighboring DHCP Agent on the same link as the DHCP client. binding A binding (or, client binding) is a group of server data records indexed by containing the releasable resource data which a DHCP server has assigned to a client. Note that the transaction-ID from the Request message that produced the assignment of the releasable resource is also stored in the server data record including the releasable resource identifier. DHCP Dynamic Host Configuration Protocol for IPv6. The terms DHCPv4 and DHCPv6 are used only in contexts where it is necessary to avoid ambiguity. Bound, Carney, Perkins Expires 1 November 2000 [Page 3] Internet Draft DHCP for IPv6 5 May 2000 configuration parameter An element of the configuration information set on the server and delivered to the client using DHCP. Such parameters may be used to carry information to be used by a node to configure its network subsystem and enable communication on a link or internetwork, for example. DHCP client (or client) A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers. DHCP domain A chunk of network topology managed by DHCP and operated by a single administrative entity. DHCP server (or server) A server is a node that responds to requests from clients, and may or may not be on the same link as the client(s). DHCP relay (or relay) A node that acts as an intermediary to deliver DHCP messages between clients and servers, and is on the same link as a client. DHCP agent (or agent) Either a DHCP server on the same link as a client, or a DHCP relay. Releasable resource Any configuration resource allocated by a server for a finite period of time. As of this writing, the only example of such a resource is the IP address. Releasable resources are carried in extensions allocated out of the 1--8192 range. solicit-ID An unsigned integer generated by the client and inserted into its DHCP Solicit messages, and echoed back to the client by the server in its resultant DHCP Advertise message(s). The client uses the solicit-ID to match received Advertise messages to Solicit messages it has generated. transaction-ID An unsigned integer to match responses with replies initiated either by a client or server. Servers Bound, Carney, Perkins Expires 1 November 2000 [Page 4] Internet Draft DHCP for IPv6 5 May 2000 allocate their transaction-IDs from the range of 0--1023, and clients allocate their transaction-IDs from the range of 1024--65535. Limiting clients and servers to different ranges prevents transaction-ID collisions (e.g. client and server happen to use the same transaction-ID for unrelated transactions (e.g. client Request, server Reconfigure-init). 3. DHCP Constants This section describes various program and networking constants used by DHCP. 3.1. Multicast Addresses The DHCP makes use of the following multicast addresses: All DHCP Agents address: FF02::1:2 This link-local multicast address is used by clients to communicate with the on-link agent(s) when they do not know those agents' link-local address(es). All agents (servers and relays) are members of this multicast group. All DHCP Servers address: FF05::1:3 This site-local multicast address is used by clients or relays to communicate with server(s), either because they want to send messages to all servers or because they do not know the server(s) unicast address(es). Note that in order for a client to use this address, it must have an address of sufficient scope to be reachable by the server(s). All servers within the site are members of this multicast group. 3.2. UDP ports The DHCP uses the following destination UDP [14] port numbers. While source ports MAY be arbitrary, client implementations SHOULD permit their specification through a local configuration parameter to facilitate the use of DHCP through firewalls. 546 Client port. Used by agents to send messages to clients. Also used by servers to send messages to relays. Bound, Carney, Perkins Expires 1 November 2000 [Page 5] Internet Draft DHCP for IPv6 5 May 2000 547 Agent port. Used by clients to send messages to agents. Also used by relays to send messages to servers. 3.3. DHCP message types The DHCP defines the following message types. More detail on these message types can be found in Section 9. Message types 0 and 9--255 are reserved and MUST be silently ignored. 01 DHCP Solicit The DHCP Solicit (or Solicit) message is used by clients to locate servers and (optionally) learn about the subnet prefixes on the client's link for networks that are managed by DHCP. This message is multicast using the All-DHCP-Agents address. Relay(s) forward Solicits as necessary to off-link servers. Section 9.1 contains more details about the Solicit message. 02 DHCP Advertise The DHCP Advertise (or Advertise) message is used by servers responding to Solicits. This message is unicast to the client's link-local address (if the server and client are on the same link) or unicast to the relay through which the Solicit was sent for final delivery to the client. Section 9.2 contains more details about the Advertise message. 03 DHCP Request The DHCP Request (or Request) message is used by clients to request configuration parameters from servers. This message is unicast to the server if the client has an address with sufficient scope to be reachable by the server, otherwise it is unicast to the on-link relay through which the Advertise message was relayed. Section 9.3 contains more details about the Request message. 04 DHCP Reply The DHCP Reply (or Reply) message is used by servers responding to Request and Release messages. In the case of responding to a Request message, the Reply contains configuration parameters destined for the client. This message is unicast to the client if the client has an address of sufficient scope that is Bound, Carney, Perkins Expires 1 November 2000 [Page 6] Internet Draft DHCP for IPv6 5 May 2000 reachable by the server. Otherwise, it is unicast to the relay through which the Request or Release message was sent for final delivery to the client. Section 9.4 contains more details about the Reply message. 05 DHCP Release The DHCP Release (or Release) message is used by clients to return one or more instances of releasable resources (e.g. IP addresses) to servers. This message is unicast to the server if the client will have an address of sufficient scope after the Release operation to receive a Reply message. Otherwise, the Release message is sent through the relay. The server will acknowledge the receipt of the Release message by sending the client a Reply message. Section 9.5 contains more details about the Release message. 06 DHCP Reconfigure The DHCP Reconfigure (or Reconfigure) message is sent by servers to client(s). It contains new or updated configuration parameters for use by the client(s). This message may be unicast or multicast to the client(s). Section 9.6 contains more details about the Reconfigure message. 07 DHCP Reconfigure-reply The DHCP Reconfigure-reply (or Reconfigure-reply) message is unicast by client(s) to the server to acknowledge the receipt of a Reconfigure message. Section 9.7 contains more details about the Reconfigure-reply message. 08 DHCP Reconfigure-init The DHCP Reconfigure-init (or Reconfigure-init) message is set by server(s) to inform client(s) that the server(s) has new or updated configuration parameters, and that the client(s) are to initiate a Request/Reply transaction with the server(s) in order to receive the updated information. Section 9.8 contains more details about the Reconfigure-init message. Bound, Carney, Perkins Expires 1 November 2000 [Page 7] Internet Draft DHCP for IPv6 5 May 2000 3.4. Error Values This section describes error values exchanged between DHCP implementations. 3.4.1. Generic Error Values The following symbolic names are used between client and server implementations to convey error conditions. The following table contains the actual numeric values for each name. Note that the numeric values do not start at 1, nor are they consecutive. The errors are organized in logical groups. _______________________________________________________________ |_Error_Name___|Error_ID_|Description__________________________| |_Success______|00_______|Success______________________________| |_UnspecFail___|16_______|Failure,_reason_unspecified__________| |_AuthFailed___|17_______|Authentication_failed_or_nonexistent_| |_PoorlyFormed_|18_______|Poorly_formed_message________________| |_Unavail______|19_______|Resources_unavailable________________| 3.4.2. Server-specific Error Values The following symbolic names are used by server implementations to convey error conditions to clients. The following table contains the actual numeric values for each name. _______________________________________________________________ |_Error_Name____|Error_ID_|Description_________________________| |_NoBinding_____|20_______|Client_record_(binding)_unavailable_| |_InvalidSource_|21_______|Invalid_Client_IP_address___________| |_NoServer______|23_______|Relay_cannot_find_Server_Address____| |_ICMPError_____|64_______|Server_unreachable_(ICMP_error)_____| 3.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the ``DHCP Retransmission Parameter Extension''carried in a Reply message. This extension is documented in the ``extensions document'' [2]. Bound, Carney, Perkins Expires 1 November 2000 [Page 8] Internet Draft DHCP for IPv6 5 May 2000 ______________________________________________________________ |_Parameter__________|Default_|Description____________________| |_MIN_SOL_DELAY______|1_______|MIN_(secs)_to_delay_1st_mesg___| |_MAX_SOL_DELAY______|5_______|MAX_(secs)_to_delay_1st_mesg___| |_ADV_MSG_TIMEOUT____|500_____|SOL_Retrans_timer_(msecs)______| |_ADV_MSG_MAX________|30______|MAX_timer_value_(secs)_________| |_SOL_MAX_ATTEMPTS___|-1______|MAX_attempts_(-1_=_infinite)___| |_REP_MSG_TIMEOUT____|250_____|REQ_Retrans_timer_(msecs)______| |_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________| |_REL_MSG_ATTEMPTS___|5_______|MAX_Release_attempts___________| |_RECREP_MSG_TIMEOUT_|2000____|Retrans_timer_(msecs)__________| |_REC_MSG_ATTEMPTS___|10______|Reconfigure_attempts___________| |_REC_REP_MIN________|5_______|Minimum_pause_interval_(secs)__| |_REC_REP_MAX________|7200____|Maximum_pause_interval_(secs)__| |_REC_THRESHOLD______|100_____|%_of_required_clients__________| |_SRVR_PREF_WAIT_____|2_______|Advertise_Collect_timer_(secs)_| 4. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3]. This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demostrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. 5. Background Related work in IPv6 that would best serve an implementor to study is the IPv6 Specification [6], the IPv6 Addressing Architecture [8], IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor Discovery Processing [12], and Dynamic Updates to DNS [17]. These specifications enable DHCP to build upon the IPv6 work to provide both robust stateful autoconfiguration and autoregistration of DNS Host Names. The IPv6 Specification provides the base architecture and design of IPv6. A key point for DHCP implementors to understand is that IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater (in IPv4 the requirement is 68 octets). This means that a UDP packet of 536 octets will always pass through an internetwork Bound, Carney, Perkins Expires 1 November 2000 [Page 9] Internet Draft DHCP for IPv6 5 May 2000 (less 40 octets for the IPv6 header), as long as there are no IP options prior to the UDP header in the packet. But, IPv6 does not support fragmentation at routers, so that fragmentation takes place end-to-end between hosts. If a DHCP implementation needs to send a packet greater than 1500 octets it can either fragment the UDP packet into fragments of 1500 octets or less, or use Path MTU Discovery [10] to determine the size of the packet that will traverse a network path. DHCP clients use Path MTU discovery when they have an address of sufficient scope to reach the DHCP server. If a DHCP client does not have such an address, that client MUST fragment its packets if the resultant message size is greater than the minimum 1280 octets. Path MTU Discovery for IPv6 is supported for both UDP and TCP and can cause end-to-end fragmentation when the PMTU changes for a destination. The IPv6 Addressing Architecture specification [8] defines the address scope that can be used in an IPv6 implementation, and the various configuration architecture guidelines for network designers of the IPv6 address space. Two advantages of IPv6 are that support for multicast is required, and nodes can create link-local addresses during initialization. This means that a client can immediately use its link-local address and a well-known multicast address to begin communications to discover neighbors on the link. For instance, a client can send a Solicit message and locate a server or relay. IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies procedures by which a node may autoconfigure addresses based on router advertisements [12], and the use of a valid lifetime to support renumbering of addresses on the Internet. In addition the protocol interaction by which a node begins stateless or stateful autoconfiguration is specified. The DHCP is one vehicle to perform stateful autoconfiguration. Compatibility with addrconf is a design requirement of DHCP (see Section 6). IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6 which replaces and enhances functions of ARP [13]. To understand IPv6 and Addrconf it is strongly recommended that implementors understand IPv6 Neighbor Discovery. Dynamic Updates to DNS [17] is a specification that supports the dynamic update of DNS records for both IPv4 and IPv6. DHCP can use the dynamic updates to DNS to integrate addresses and name space to not only support autoconfiguration, but also autoregistration in IPv6. The security model to be used with DHCPv6 should conform as closely as possible to the authentication model outlined in RFC2402 [9]. Bound, Carney, Perkins Expires 1 November 2000 [Page 10] Internet Draft DHCP for IPv6 5 May 2000 6. Design Goals - DHCP is a mechanism rather than a policy. Network administrators set their administrative policies through the configuration parameters they place upon the DHCP servers in the DHCP domain they're managing. DHCP is simply used to deliver parameters according to that policy to each of the DHCP clients within the domain. - DHCP is compatible with IPv6 stateless autoconf [15]. - DHCP does not require manual configuration of network parameters on DHCP clients, except in cases where such configuration is needed for security reasons. A node configuring itself using DHCP should require no user intervention. - DHCP does not require a server on each link. To allow for scale and economy, DHCP must work across DHCP relays. - DHCP coexists with statically configured, non-participating nodes and with existing network protocol implementations. - DHCP clients can operate on a link without IPv6 routers present. - DHCP will provide the ability to renumber network(s) when required by network administrators [4]. - A DHCP client can make multiple, different requests for configuration parameters when necessary from one or more DHCP servers at any time. DHCP will provide enough information to enable a DHCP server to keep track of a DHCP client's configuration state. - DHCP will contain the appropriate time out and retransmission mechanisms to efficiently operate in environments with high latency and low bandwidth characteristics. 7. Non-Goals This specification explicitly does not cover the following: - Specification of a DHCP server to server protocol. - How a DHCP server stores its DHCP data. - How to manage a DHCP domain or DHCP server. Bound, Carney, Perkins Expires 1 November 2000 [Page 11] Internet Draft DHCP for IPv6 5 May 2000 - How a DHCP relay is configured or what sort of information it may log. 8. Overview This section provides a general overview of the interaction between the functional entities of DHCP. The overview is organized as a series of questions and answers. Details of DHCP such as message formats and retransmissions are left to sections 9, 10, 11, 12, 14, 15, and 16. 8.1. How does a node know to use DHCP? An unconfigured node determines that it is to use DHCP for configuration of an interface by detecting the presence (or absence) of routers on the link. If router(s) are present, the node examines router advertisements to determine if DHCP should be used to configure the interface. If there are no routers present, then the node MUST use DHCP to configure the interface. Detail on this process can be found in neighbor discovery [12] and stateless autoconfiguration [15]. 8.2. How does a client find out about DHCP agents? The client forms a Solicit message, and multicasts it to the FF02::1:2(All DHCP Agents) address. Server(s) receiving the Solicit respond with Advertise message(s). If requested in the client's Solicit message, the Advertise message(s) can include one or more subnet prefix extensions [2], informing the client of subnet prefixes for the networks(s) managed by the server(s) on the client's link. Now that the client knows the IP address(es) of agents(s) on the link, it can request configuration parameters from servers. 8.3. What if the client and server(s) are on different links? Use of DHCP in such environments requires one or more DHCP relays be set up on the client's link, because a client may only have a link-local address. Relays pick up the Solicit and Request messages from the client and forward them to some set of servers within the DHCP domain. A relay will include one of its own addresses (of sufficient scope) of the interface on the same link as the client. The relay also includes the subnet prefix length of that address in the client's messages. Servers receiving the forwarded traffic use this information to aid in selecting configuration parameters appropriate to the client's link. The servers also use the relay's Bound, Carney, Perkins Expires 1 November 2000 [Page 12] Internet Draft DHCP for IPv6 5 May 2000 address as the destination to forward client-destined messages for final delivery by the relay. Relays forward client messages to servers using some combination of the FF05::1:3(All Servers) site-local multicast address, some other (perhaps a combination) of site-local multicast addresses set up within the DHCP domain to include the servers in that domain, or a list of unicast addresses for servers. The network administrator makes relay configuration decisions based upon the topological requirements (scope) of the DHCP domain they are managing. Note that if the DHCP domain spans more than the site-local scope, then the relays MUST be configured with global addresses for the client's link so as to be reachable by servers outside the relays' site-local environment. 8.4. How does a client request configuration parameters from servers? To request configuration parameters, the client forms a Request message, and sends it to the server either directly (client has an address of sufficient scope) or indirectly (through the on-link relay). The client MAY include a Extension Request Extension [2] along with other extensions to request specific information from the server. Note that the client MAY form multiple Request messages and send each of them to different servers to request potentially different information (perhaps based upon what was advertised) in order to satisfy its needs. As a client's needs may change over time (perhaps based upon an application's requirements), the client may form additional Request messages to request additional information as it is needed. The server(s) respond with Reply messages containing the requested configuration parameters, which can include status information regarding the information requested by the client. The Reply MAY also include additional information, such as a reconfiguration event multicast group for the client to join to monitor reconfiguration events, as described in section 8.8. The receipt of a Reply from a server concludes the basic request/reply transaction of the protocol. 8.5. What are releasable resources, and when are they used? A releasable resource is configuration information leased to a client by a server for some finite period of time. When negotiating for a releasable resource, the client and server agree upon a finite period of time the client may use the resource. The client MAY request a renewal of the lease on the resource at any time. The length of time of the lease (and whether it is renewable) are server-based policy tunables. The client MUST stop using the resource when the lease on Bound, Carney, Perkins Expires 1 November 2000 [Page 13] Internet Draft DHCP for IPv6 5 May 2000 the resource expires. The server MUST NOT reallocate an assigned resource before either its lease expires or the client releases the resource. See the ``extensions document'' [2] for more information about releasable resources. 8.6. Can a client release its releasable resources before the lease expires? A client forms a Release message, including extensions carrying the resource(s) to be released. The client sends the Release to the server which leased the resource(s) to the client initially. If that server cannot be reached after a certain number of attempts (see section 3.5), the client can abandon the Release attempt. In this case, the resource(s) will be reclaimed by the server(s) when the client's lease(s) expire. 8.7. What if the client determines its releasable resource is already being used by another client? If the client determines through a releasable resource-specific manner that the resource it was assigned by the server is already in use by another client, the client will form a Release message, including the extension carrying the in-use resource. The extension's status field MUST be set to the extension-specific value reflecting the ``in use'' status of the resource. For example, if the releasable resource is an IP address, the client uses Duplicate Address Detection (DAD) to verify that the IP address is not in use. If the client determines that the IP address is already in use, it forms a Release message including the IP address extension containing the appropriate status value and sends it to the server. See the ``extensions document''for details on the IP address extension. [2]. 8.8. How are clients notified of server configuration changes? There are two possibilities. Either the clients discover the new information when they revisit the server(s) to request additional configuration information / renew the lease on a releasable resource, or through a server-initiated event known as a reconfigure event. The reconfiguration feature of DHCP offers network administrators the opportunity to update configuration information on DHCP clients whenever necessary. If the information to be updated is not Bound, Carney, Perkins Expires 1 November 2000 [Page 14] Internet Draft DHCP for IPv6 5 May 2000 client-specific, the server will form a Reconfigure message and add the new or changed configuration information to it. The Reconfigure may be unicast or multicast (to a preassigned multicast address for this purpose) to one or more client(s) to which the new or updated information needs to be directed. The client(s) will acknowledge the receipt of the Reconfigure message by forming a Reconfigure-reply message and unicasting it to the server. If the configuration information change is different for each client (e.g. a change in subnet prefix, perhaps, which would affect the IP address releasable resource(s)), the server will form a Reconfigure-init message and unicast / multicast as needed to the client(s). A Reconfigure-init is a trigger which will cause the client(s) to initiate a standard Request/Reply exchange with the server in order to acquire the new or updated resources. 9. Message Formats All reserved fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. 9.1. DHCP Solicit Message Format A client multicasts a DHCP Solicit message to the FF02::1:2(All DHCP agents) address over the interface to be configured to locate one or more servers which are configured to provide configuration parameters to nodes on the client's link. Unless otherwise noted, the value of all fields are set by 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 1 |C|P| reserved | prefix-len | solicit-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C If set, the client requests that all servers receiving the message deallocate the releasable resources (e.g. IP addresses) associated with the client's binding. Bound, Carney, Perkins Expires 1 November 2000 [Page 15] Internet Draft DHCP for IPv6 5 May 2000 P If set, the client requests that all servers receiving the message SHOULD return a list of subnet prefix extensions identifying the networks on the client's link that the server(s) are configured to manage. reserved 0 prefix-len An unsigned 7 bit number (0-127) non-zero prefix-len is the number of leftmost bits of the agent's IPv6 address which make up the subnet prefix. The prefix-len field is set by the relay if the relay receives the Solicit message and forwards it to one or more servers. solicit-ID An unsigned 9 bit number (0-511) generated by the client used to identify this Solicit message. client's link-local address The IP link-local address of the client interface through which the client will issue the Solicit message. relay-address Set by the client to be zero. If received by a relay, set by the relay to the site-local IP address of the interface on which the relay received the client's Solicit message. Note that if the DHCP domain crosses site boundaries, the relay MUST place a globally-scoped address in this field. A client MUST send the Solicit message to the All-DHCP-Agents multicast group (see section 3.1), setting the relay-address to zero. 9.2. DHCP Advertise Message Format A server sends an Advertise message in response to a client's Solicit message. The Advertise message notifies the client of the server's IP address. If the server is so configured by the network administrator and the client requests it through the ``P'' bit in its Solicit message, the server SHOULD add a list of subnet prefix extensions to the Advertise message to notify the client of the networks it manages on the client's link. When the client and server are on different links, the server sends the Advertise message back through the relay whence the corresponding Solicit came. The solicit-ID is copied from the client's Solicit Bound, Carney, Perkins Expires 1 November 2000 [Page 16] Internet Draft DHCP for IPv6 5 May 2000 Message. The value of all fields in the Advertise message are filled in by the server and not changed in any way by any intervening relay. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 2 | reserved | solicit-ID | preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved 0 solicit-ID An unsigned 9 bit number (0-511) used to identify this Advertise message. Copied from the client's Solicit message. preference An octet (unsigned) indicating a server's willingness to provide service to the client. client's link-local address The IP link-local address of the client interface from which the client issued the Solicit message. relay-address The IP address of the relay interface on the same link as the client. Copied from the client's Solicit. If the server is on the same link as the client, then this field MUST be zero. server-address The site-local IP address of the server. If the DHCP domain crosses site boundaries, then this address MUST be globally-scoped. extensions See the ``extensions document'' for details [2]. See Sections 14.4 and 15.3 for information about how clients and servers handle the preference field. Bound, Carney, Perkins Expires 1 November 2000 [Page 17] Internet Draft DHCP for IPv6 5 May 2000 9.3. DHCP Request Message Format A client sends a Request message to request configuration parameters from a server. It MAY append appropriate extensions [2]. When a client reboots, it often does not have a valid IP address of sufficient scope for the server to communicate with the client. In such cases, the client MUST NOT unicast the message to the server because the server could not return a response to the client. The client MUST send the message to the server indirectly, by using the on-link relay. The client MUST fill in the relay address field with the on-link relay's IP address. If the Request message is being formed in response to a Reconfigure-init message from the server, then the transaction ID used must be copied from the Reconfigure-init. All fields in the DHCP Request message are entered by 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 3 |C|R| reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C If set, the client requests the server to remove all releasable resources associated with the client binding, except those releasable resources provided as extensions. R If set, the client has rebooted and requests that the server clear any transaction-ID cache entries for the client. reserved 0 Bound, Carney, Perkins Expires 1 November 2000 [Page 18] Internet Draft DHCP for IPv6 5 May 2000 transaction-ID An unsigned integer identifier used to identify this request. client's link-local address The link-local address of the client interface from which the client will issue the Request message. relay-address The IP address of a relay's interface, copied from an Advertise message. If the server is on the same link as the client, then this field MUST BE zero. server-address The IP address of the server to which the the client's Request message is directed, copied from an Advertise message. extensions See the ``extensions document'' [2]. A DHCP client selects the transaction-ID from the range of 1024--65535 used to identify its Request. In contrast, a transaction-ID from the range of 0--1023is selected by a DHCP server to identify a Reconfigure-init. In the latter case, the transaction ID from the Reconfigure-init is copied by the client into its Request message. When the client sets the `C' bit and adds extensions documenting the releasable resources the client wishes to keep, the server is expected to deallocate all other releasable resources not listed. The server SHOULD examine the included extensions to check whether the client is still authorized to use them. 9.4. DHCP Reply Message Format A server sends a Reply message in response to a client's Request message or Release message. If a Request message is received which contains a non-zero relay address field, then the client could not unicast the Request message to the server and thus had to use a on-link relay. In that case, the server unicasts the Reply message to the relay address found in the Request message. If a Release message is received which contains a non-zero relay address field, then the client will not have an IP address of sufficient scope after the Release to receive the Reply message. In Bound, Carney, Perkins Expires 1 November 2000 [Page 19] Internet Draft DHCP for IPv6 5 May 2000 this case, the server unicasts the Reply message to the relay address found in the Release message. All the fields in the DHCP Reply message are set by the DHCP server. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 4 |R| status | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address (if present) | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R If set, the ``relay-address'' field is present. status This 7-bit field contains one of the values in the errors table in section 3.4. transaction-ID Copied from the client's Request or Release. client's link-local address Copied from the client's Request or Release message. relay-address The IP address of a relay's interface, copied from the Request or Release message. If the server is on the same link as the client, then the ``R'' bit is not set and this field is not present. extensions See the ``extensions document'' [2]. 9.5. DHCP Release Message Format A client sends a Release message to a server when it wishes to return one or more releasable resources to the server which allocated them. This can occur either because the client no longer needs the resource(s) or the client has determined through a resource-specific manner that the resource(s) are already in use by different Bound, Carney, Perkins Expires 1 November 2000 [Page 20] Internet Draft DHCP for IPv6 5 May 2000 client(s). The client communicates the reason for the premature release of the resource in the status field of the resource's extension. See ``extensions document'' [2] for more details. When a client sends a Release message, it needs to have a valid IP address with sufficient scope to allow access by the target server. If such an address is not available, a relay is used. Only those releasable resources identified by extensions are released. If no extensions are included in the Release message, then all releasable resources associated with the client's binding are to be released. The values of all fields of the Release message are set by the client. The DHCP server acknowledges the Release message by sending a Reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 5 |R| reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R If set, the ``X-address'' field contains the address of relay. If not set, the ``X-address'' field contains a non-local scope client address. reserved 0 transaction-ID An unsigned integer identifier used to identify this Release message. client's link-local address The client's link-local address for the interface from which the client issued the Release message (and to which the releasable resources are bound at the server). Bound, Carney, Perkins Expires 1 November 2000 [Page 21] Internet Draft DHCP for IPv6 5 May 2000 server-address The IP address of the server which allocated the resource. X-address If the ``R'' bit is set, the ``X-address'' field contains the IP address of the relay interface on the same link as the client. If the ``R'' bit is not set, this field contains a non-link-local IP address of the client interface from which the the client issued the Release message. extensions See the ``extensions document'' [2]. A client selects the transaction-ID from the range of 1024--65535 used to identify the Release message. A client MUST NOT specify an IP address in the client-address field that it is releasing in the extensions field. 9.6. DHCP Reconfigure Message Format A server sends a Reconfigure message when it wishes to inform one or more clients of new or updated values for configuration parameters. The new configuration parameters are carried in the extensions portion of the Reconfigure message. Note that a Reconfigure message MUST NOT carry releasable resource extensions. Reconfigure messages can ONLY be sent to clients which have established an IP address of sufficient scope as to be directly reachable by the server. Clients acknowledge Reconfigure messages with Reconfigure-reply 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 6 | reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved 0 Bound, Carney, Perkins Expires 1 November 2000 [Page 22] Internet Draft DHCP for IPv6 5 May 2000 transaction-ID An unsigned integer identifier in the range of 0--1023 chosen by the server to identify this Reconfigure message. server-address The IP address of the DHCP server issuing the Reconfigure message. MUST be of sufficient scope to be reachable by all clients. extensions See the ``extensions document'' [2]. 9.7. DHCP Reconfigure-reply Message Format A client sends a Reconfigure-reply message to acknowledge receipt of a Reconfigure message from a server. A Reconfigure-reply message can only be sent if the client has an IP address of sufficient scope to contact the server. No interaction with a relay is possible. All fields in the DHCP Reconfigure-reply message are entered by 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 7 |r| status | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r reserved (0) status This 7-bit field contains one of the values from the errors table in section 3.4. transaction-ID An unsigned integer identifier copied from the server's Reconfigure message. Bound, Carney, Perkins Expires 1 November 2000 [Page 23] Internet Draft DHCP for IPv6 5 May 2000 client's link-local address The client's link-local address for the interface from which the client issued the Reconfigure-reply message. server-address Copied from the Reconfigure message. 9.8. DHCP Reconfigure-init Message Format A server sends a Reconfigure-init message when it wishes to notify one or more clients of new or updated values for configuration parameters available on the server. Reconfigure-init messages can ONLY be sent to clients which have established an IP address of sufficient scope as to be directly reachable by the server. A ``Reconfigure-init'' serves as a trigger which will cause the clients to initiate a Request/Reply exchange with the server in order to receive the new information. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 8 | reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved 0 transaction-ID An unsigned integer identifier in the range of 0--1023 chosen by the server to identify this Reconfigure-init message. server-address The IP address of the DHCP server issuing the Reconfigure-init message. MUST be of sufficient scope to be reachable by all clients. extensions SHOULD only include an ERE and/or authentication extensions. No configuration information SHOULD be Bound, Carney, Perkins Expires 1 November 2000 [Page 24] Internet Draft DHCP for IPv6 5 May 2000 included. See the ``extensions document'' [2] for more information about extensions. 10. DHCP Server Solicitation and Subnet Prefix Discovery This section describes how a client locates agents (relays and servers) and how it can learn about the networks on its link that are managed by these servers. The behavior of client, server, and relay implementations is discussed, along with the messages they use. 10.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. Agents MUST discard any received Solicit messages if the ``client's link-local address'' field does not contain a valid link-local address. Servers MUST discard each received Solicit message which meet the following criteria: o The ``relay-address'' field does not contain an address of sufficient scope that is reachable by the server. o The ``relay-address'' field is non-zero, but prefix-len is zero. An error message MAY be logged by the agent. The logging of such messages SHOULD be controlled by an agent implementation configuration flag. 10.2. Advertise Message Validation Servers MUST silently discard any received Advertise messages. Clients MUST discard any Advertise messages that meet any of the following criteria: o The ``Solicit-ID'' field value does not match the value the client used in its Solicit message. o The ``client's link-local address'' field value does not match the link-local address of the interface upon which the client sent the Solicit message. Relays MUST discard any Advertise messages that meet any of the following criteria: Bound, Carney, Perkins Expires 1 November 2000 [Page 25] Internet Draft DHCP for IPv6 5 May 2000 o The ``relay-address'' field does not contain the relay's address on the same link as the client. o The ``client's link-local address'' field does not contain a valid link-local address. 10.3. Client Behavior Clients use the Solicit message primarily to discover DHCP servers configured to serve networks on the link containing the client. Optionally, the client MAY set the ``P'' bit which has the effect of requesting that the server return subnet prefix extensions identifying the networks on the client's link the server is configured to manage. 10.3.1. Creation and sending of the Solicit message When creating a Solicit message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 1, and places the link-local address of the interface it wishes to configure in the link-local address field. If the client is prepared to process multiple Advertise messages in response to its Solicit message, the client will set the Solicit-ID field to 1. Every time the client initiates a new server solicitation attempt (not a retransmission), the client increments the Solicit-ID by one. If the 9-bit field rolls over to 0, then the client sets the Solicit-ID to 1. A client which will only accept the first Advertise message it receives leaves the Solicit-ID field initialized to zero. The ``C'' bit of the Solicit message is set by the client when the client has no cached knowledge of previous DHCP configuration for the interface. Setting this bit requests that the server release any information assigned to the client for the networks on the client's link. If the client desires to learn of the networks managed by DHCP on the link its interface is attached to, it sets the ``P'' bit in the Solicit message. The client transmits the Solicit message to the FF02::1:2 (All DHCP Agents) multicast address, destination port 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. Bound, Carney, Perkins Expires 1 November 2000 [Page 26] Internet Draft DHCP for IPv6 5 May 2000 10.3.2. Time out and retransmission of Solicit Messages The client's first Solicit message on the interface MUST be delayed by a random amount of time between the interval of MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. If no Advertise messages are received, the client retransmits the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process continues until either one or more Advertise messages are received or ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been made, at which time the client stops trying to DHCP configure the interface. An event external to DHCP is required to restart the DHCP configuration process. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5. 10.3.3. Receipt of Advertise messages Upon receipt of one or more validated Advertise messages, the client selects one or more Advertise messages based upon the following criteria. - Those Advertise messages with the highest server preference value (see section 14.4) are preferred over all other Advertise messages. - Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, one server may be advertising the availability of IP addresses on networks which have an address scope of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as relay address and prefix length, server preference value, networks advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. Bound, Carney, Perkins Expires 1 November 2000 [Page 27] Internet Draft DHCP for IPv6 5 May 2000 10.4. Relay Behavior For this discussion, the Relay is assumed to have been configured with some list of server destination addresses, which may be unicast, the FF05::1:3 (All DHCP Servers) multicast address, or some other multicast address selected by the network administrator. 10.4.1. Relaying of Solicit messages When a Relay receives a valid Solicit message, it places the IP address of the interface upon which it received the Solicit message in the ``relay-address'' field of the Solicit. The Relay also places the number of bits of that make up the subnet prefix for this address in the ``prefix-len'' field of the Solicit. The Relay then forwards this Solicit to the list of server destination addresses that it has been configured with. 10.4.2. Relaying of Advertise messages When a Relay receives a valid Advertise message, it unicasts the message to the link-local address found in the ``client's link-local address'' field by way of the appropriate network interface. 10.5. Server Behavior For this discussion, the Server is assumed to have been configured in an implementation specific manner. This configuration is assumed to contain all network topology information for the DHCP domain, as well as any necessary authentication information. 10.5.1. Receipt of Solicit messages Upon the receipt of a valid Solicit message, the server first identifies the client's location within the DHCP domain. If the ``relay-address'' and / or ``prefix-len'' fields of the Solicit are zeroed, then the client is attached to the same link as the server. If these fields are non-zero, then the client exists on the same link as the network identified by these two fields. If administrative policy permits the server to respond to a client on that link, the server will generate and send an Advertise message to the client. Bound, Carney, Perkins Expires 1 November 2000 [Page 28] Internet Draft DHCP for IPv6 5 May 2000 10.5.2. Creation and sending of Advertise messages When creating an Advertise message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 2 and copies the values of the following fields from the client's Solicit to the Advertise message: o solicit-ID o client's link-local address o relay-address The server places one of its IP addresses (determined through administrator setting) in the ``server-address'' field of the Advertise message. The server initializes the ``preference'' field from its configuration information. See section 15.3 for a description of server preference. If the client requests subnet prefix extensions (by setting the ``P'' bit in its Solicit) and the server implements and is configured to provide prefix extensions, the server will generate and insert a subnet prefix extension for each network on the client's link it is configured to manage. If the ``relay-address'' field of the Advertise message is zero, then the server unicasts the Advertise message directly to the client using the ``client's link-local address'' field value as destination address. If the ``relay-address'' field is non-zero, then the server unicasts the Advertise message directly to the relay using the ``relay-address'' field value as the destination address. 11. DHCP Client-Initiated Configuration Exchange A client initiates a configuration exchange with one or more servers it has found through DHCP server solicitation whenever requested to do so by the application layer in order to acquire configuration information of interest. 11.1. Request Message Validation Clients MUST silently discard any received Request messages. Agents MUST discard any Request messages in which the ``client's link-local address'' field does not contain a valid link-local address. Bound, Carney, Perkins Expires 1 November 2000 [Page 29] Internet Draft DHCP for IPv6 5 May 2000 Relays MUST discard any received Request messages in which the ``relay-address'' field value does not match any of the relay's addresses. Servers MUST discard any received Request message which meets any of the following criteria: o The ``server-address'' field value does not match any of the server's addresses. o If the ``relay-address'' field is set, and that field's value does not contain an address of sufficient scope as to be reachable by the server. o The ``extensions'' field contains an authentication extension, and the server cannot successfully authenticate the client. 11.2. Reply Message Validation Servers MUST silently discard any received Reply messages. Clients MUST discard any Reply message that meets any of the following criteria: o The ``transaction-ID'' field value does not match the value the client used in its Request or Release message. o The ``client's link-local address'' field value does not match the link-local address of the interface upon which the client sent in its Request or Release message. o The Reply message contains an authentication extension, and the client's attempt to authenticate the message fails. Relays MUST discard any Reply message that meets any of the following criteria: o The ``R'' bit isn't set. o The ``relay-address'' field value does not contain the relay's address on the same link as the client. o The ``client's link-local address'' field value does not contain a valid link-local address. Bound, Carney, Perkins Expires 1 November 2000 [Page 30] Internet Draft DHCP for IPv6 5 May 2000 11.3. Release Message Validation Clients MUST silently discard any received Release messages. Agents MUST discard any Release message that meets any of the following criteria: o The ``transaction-ID'' field contains a value not in the 1024--65535 range. o The ``client's link-local address'' field does not contain a valid link-local address. Relays MUST discard any received Release message that meets any of the following criteria: o The ``R'' bit is not set. o The ``X-address'' field value does not match any of the relay's addresses. Servers MUST discard any received Release message which meets any of the following criteria: o The ``X-address'' field does not contain an address of sufficient scope as to be reachable by the server. o The ``extensions'' field contains an authentication extension, and the server cannot successfully authenticate the client. 11.4. Client Behavior A client will generate one or more Request messages when prompted by the application layer in order to acquire configuration information. A client may initiate such an exchange automatically in order to acquire the necessary network parameters to communicate with nodes off-link. The client uses the server and relay address information from previous Advertise message(s) for use in delivering Request message(s). Note that a client may request configuration information from one or more servers at any time. A client uses the Release message in the management of releasable resources when: o The client has determined through a resource-specific manner that the resource assigned by the server is already in use by a different client. Bound, Carney, Perkins Expires 1 November 2000 [Page 31] Internet Draft DHCP for IPv6 5 May 2000 o The client has been instructed to release the resource prior to the lease expiration time since it is no longer needed. 11.4.1. Creation and sending of Request messages When creating a Request message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 3, and places the link-local address of the interface it wishes to associate with the configuration information with in the ``client's link-local address'' field. Unless the Request message is created in response to a Reconfigure-init message, the client generates a transaction ID in the range of 1024--65535 and inserts this value in the ``transaction-ID'' field. The client places the address of the destination server in the ``server-address'' field. If the client is not on the same link as the destination server, the client places the appropriate relay's address in the ``relay-address'' field. If the client is acquiring configuration information on the interface for the first time, the client SHOULD set the ``C'' bit in the header. How the client determines if this is the first configuration attempt on the interface is implementation-specific. A client may implement a cache of configuration information on a per-interface basis; if that cache does not exist, that client would set the ``C'' bit. Clients which do not implement caching of per-interface configuration information MUST always set the ``C'', and include any extensions carrying releasable resources received from earlier configuration exchanges in the extensions field of the Request. If the client has determined through an implementation-specific manner that the client implementation itself has restarted, it MUST set the ``R'' bit in the header. After the first successful exchange with the server, the client MUST NOT set the ``R'' bit in subsequent Request messages. Client considerations for extensions are now considered (see the ``extensions document'', [2] for more details). If the client already has an IP address of sufficient scope to directly reach the server, then the client SHOULD unicast the Request to the server. Otherwise, if the server is off-link, the client unicasts the Request message to the appropriate relay. Bound, Carney, Perkins Expires 1 November 2000 [Page 32] Internet Draft DHCP for IPv6 5 May 2000 11.4.2. Time out and retransmission of Request Messages The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply messages. If no Reply messages are received, the client retransmits the Request with the same transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits again. The client continues this process until a Reply is received or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the client MUST abort the configuration attempt. The client SHOULD report the abort status to the application layer. Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS are documented in section 3.5. 11.4.3. Receipt of Reply message in response to a Request Upon the receipt of a valid Reply message, the client extracts the configuration information contained in the Reply. If the ``status'' field contains a non-zero value, the client reports the error status to the application layer. If the extensions field contains one or more ``Reconfigure Multicast Address'' extensions (see ``extensions document'', ``Reconfigure Multicast Address Extension'' section [2]), the client MUST join these multicast groups, and MUST monitor the UDP 546 port for Reconfigure or Reconfigure-init messages on the networks configured by DHCP. If the configuration information returned in the Reply contains releasable resources, then the client MUST take over lease management of the resource. A client MUST NOT request releasable resources unless it is prepared to appropriately manage the resource lease. 11.4.4. Creation and sending of Release messages When creating a Release message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 5, and places the link-local address of the interface the configuration information it wishes to release is associated with in the ``client's link-local address'' field. The client generates a transaction ID in the range of 1024--65535 and inserts this value in the ``transaction-ID'' field. The client includes extensions containing the releasable resources it is releasing in the ``extensions'' field. The appropriate ``status'' Bound, Carney, Perkins Expires 1 November 2000 [Page 33] Internet Draft DHCP for IPv6 5 May 2000 field in the extensions MUST be set to indicate the reason for the release. The client places the IP address of the server who allocated the resource(s) in the ``server-address'' field. If the client will have an appropriately scoped IP address after the release transaction is completed, the client clears the ``R'' bit and places this address in the ``X-address'' field. If the client will not have an appropriately scoped IP address after the release transaction is completed, the client sets the ``R'' bit and places the address of the appropriate relay in the ``X-address'' field. If the client is configured to use authentication, the client generates the appropriate authentication extension, and adds this extension to the ``extensions'' field. Note that the authentication extension MUST be the last extension in the ``extensions'' field. See the ``extension document'' for more details about the authentication extension [2]. If the ``R'' bit is set, then the client MUST unicast the Release to the relay indicated in the ``X-address'' field. Otherwise, the client unicasts the Release message directly to the server indicated in the ``server-address'' field. 11.4.5. Time out and retransmission of Release Messages The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply messages. If no Reply messages are received, the client retransmits the Release, and doubles the REP_MSG_TIMEOUT value, and waits again. The client continues this process until a Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the client SHOULD abort the release attempt. The client SHOULD return the abort status to the application, if an application initiated the release. Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS are documented in section 3.5. Note that if the client fails to release the resource, the resource will be reclaimed by the server when the lease associated with it expires. Bound, Carney, Perkins Expires 1 November 2000 [Page 34] Internet Draft DHCP for IPv6 5 May 2000 11.4.6. Receipt of Reply message in response to a Release Upon receipt of a valid Reply message, the client can consider the Release event successful, and SHOULD return the successful status to the application layer, if an application initiated the release. 11.5. Relay Behavior 11.5.1. Relaying of Request or Release messages When a Relay receives a valid Request or Release message, it forwards it to the IP address found in the ``server-address'' field of the message. 11.6. Server Behavior For this discussion, the Server is assumed to have been configured in an implementation specific manner with configuration of interest to clients. Such configuration information MAY contain releasable resources such as IP addresses. 11.6.1. Receipt of Request messages Upon the receipt of a valid Request message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the extensions field. If the client has set the ``C'' bit, the server MUST release all releasable resources currently associated with the client's binding that do not appear in the ``extensions'' field. If the client has set the ``R'' bit, the server MUST delete any transaction-ID cache entries it is maintaining for this client, if the server implements such a cache. Server considerations for extensions are now evaluated (see the ``extensions document'', [2] for more details). If the configuration information to be returned to the client includes releasable resources, the server checks if a binding already exists for the client. If so, the server examines the data records within the binding to determine if the client's Request is a retransmission of an earlier Request or a new Request. Releasable resource identifiers are stored within the binding with the transaction-ID used by the client to request the resource's assignment. If the transaction-ID's match, this is a retransmission Bound, Carney, Perkins Expires 1 November 2000 [Page 35] Internet Draft DHCP for IPv6 5 May 2000 and the server simply return the contents of the client's binding which satisfy its request. If the transaction-ID's do not match, the server records the additional resources it is assigning in the existing binding with the new Request's transaction-ID. If the client does not have an existing binding, the server creates a binding for the client and records the resources it is assigning in this binding along with the transaction-ID from the client's Request. The server then constructs a Reply message and sends it to the client. 11.6.2. Receipt of Release messages Upon the receipt of a valid Release message, the server performs a lookup to find the client's binding. If the binding is found, the server examines the binding to see if the resource(s) identified by the client in the Release message's extensions field are in fact assigned to the client. If they are, the server deletes these resources from the client's binding, making them available to other clients. The server then generates a Reply message. If a binding was found and the resources presented to the server were deleted from the client's binding, the server sets the ``status'' field to ``Success''. If no binding is found, the server sets the ``status'' field to ``NoBinding''(section 3.4). 11.6.3. Creation and sending of Reply messages When creating a Reply message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 4 and copies the values of the following fields from the client's Request or Release to the Reply message: o transaction-ID o client's link-local address o If the client's message is a Request with a non-zero ``relay-address'' field value, the server sets the ``R'' bit in the Reply and copies the ``relay-address'' field value from the Request to the Reply. If the client's message is a Release with the ``R'' bit set, the server sets the ``R'' bit in the Reply and sets the ``relay-agent'' field to the contents of the Release's X-address field. Bound, Carney, Perkins Expires 1 November 2000 [Page 36] Internet Draft DHCP for IPv6 5 May 2000 The server sets the ``status'' field appropriately (see the table in section 3.4) based upon the results of processing the client's request. If configured to do so, a server will include ``Reconfigure Multicast Address'' extensions (see ``extensions document'', ``Reconfigure Multicast Address Extension'' [2]), in Reply messages sent in response to a Request, informing the client of one or more multicast groups it should join to facilitate the receipt of Reconfigure or Reconfigure-init messages. If the DHCP domain is using authentication, the server will generate an authentication extension with the appropriate settings and add that extension as the last extension in the ``extensions'' field of the Reply message. If the ``relay-address'' field of the Reply message is zero, then the server unicasts the Reply directly to the client using the ``client's link-local address'' field value as destination address. If the ``relay-address'' field is non-zero, then the server unicasts the Reply directly to the relay using the ``relay-address'' field value as the destination address. If the server implements a transaction-ID cache, the server would add an entry for the client to this cache. 12. DHCP Server-Initiated Configuration Exchange A server initiates a configuration exchange on behalf of the administrator of the DHCP domain. An administrator may initiate such an exchange when new networks are added to the domain or existing networks are to be renumbered. Other examples include changes in the location of directory servers, addition of new services such as printing, and availability of new software (system or application). 12.1. Reconfigure Message Validation Agents MUST silently discard any received Reconfigure messages. Clients MUST discard any Reconfigure message that meets any of the following criteria: o The ``transaction-ID'' field value is not within the 0--1023 range. o The Reconfigure message contains an authentication extension, and the client's attempt to authenticate the message fails. Bound, Carney, Perkins Expires 1 November 2000 [Page 37] Internet Draft DHCP for IPv6 5 May 2000 12.2. Reconfigure-reply Message Validation Clients and Relays MUST silently discard any received Reconfigure-reply messages. Servers MUST discard any Reconfigure-reply message that meets any of the following criteria: o The ``transaction-ID'' field value is not that same value the server used in its Reconfigure message. o The ``server-address'' field value does not match the value the server placed in its Reconfigure message. 12.3. Reconfigure-init Message Validation Agents MUST silently discard any received Reconfigure-init messages. Clients MUST discard any Reconfigure-init messages that meets any of the following criteria: o The ``transaction-ID'' field value is not within the 0--1023 range. o The Reconfigure-init message contains an authentication extension, and the client's attempt to authenticate the message fails. 12.4. Server Behavior For this discussion, the server is assumed to have a implementation-specific interface by which an administrator may initiate a reconfiguration event with some set of clients. There are two methods of initiating a reconfiguration event. Each has its advantages: Reconfigure with payload This method uses the Reconfigure message. Items to be changed are included as extensions in the ``extensions'' field. This method MUST NOT be used to reconfigure releasable resources. Examples of information which can be reconfigured using this method are DNS domain and servers, NTP servers, other name service parameters. The server generates and sends the Reconfigure message; clients respond with Reconfigure-reply messages. Bound, Carney, Perkins Expires 1 November 2000 [Page 38] Internet Draft DHCP for IPv6 5 May 2000 Reconfigure Trigger This method uses the Reconfigure-init message. When a client receives a Reconfigure-init message, it initiates a Request/Reply exchange with the server. Any kind of resource can be reconfigured using this method, including releasable resources. An example of an releasable resource is an IP address. A server can send Reconfigure and Reconfigure-init messages only to those clients who have an address of sufficient scope to be reachable by the server. Thus, those clients who have not requested an IP address and are off-link cannot be reconfigured by the server. Before initiating a reconfigure process, the server SHOULD be configured with a REC_THRESHOLD threshold value which represents the percentage of clients successfully reconfigured before the reconfigure process is considered a success. See section 3.5 for the default setting of REC_THRESHOLD. Note that the server MUST be able to determine the set of clients that should receive the reconfigure, in order to determine when the reconfigure process is complete. 12.4.1. Creation and sending of Reconfigure messages When creating a Reconfigure message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 6. The server generates a transaction-ID from the 0--1023 range and inserts it in the ``transaction-ID'' field. The server places its address (of appropriate scope) in the ``server-address'' field. The server then generates extensions for the non-releasable resources to be changed and places them in the ``extensions'' field. If the DHCP domain is using authentication, the server will generate an authentication extension with the appropriate settings and add that extension as the last extension in the ``extensions'' field of the Reconfigure message. The server multicasts the Reconfigure message to one or more Reconfigure Multicast Addresses previously sent as extensions to the clients. Note that a server MAY unicast Reconfigure message(s) to specific clients by walking its list of bindings to determine the unicast address(es) of the clients. Whether or not the Reconfigure is multicast or unicast is an implementation detail. A server waits for Reconfigure-reply messages from clients confirming that they have received the Reconfigure. Bound, Carney, Perkins Expires 1 November 2000 [Page 39] Internet Draft DHCP for IPv6 5 May 2000 12.4.2. Time out and retransmission of Reconfigure messages The server waits RECREP_MSG_TIMEOUT milliseconds, collecting Reconfigure-reply messages. If all the expected Reconfigure-reply messages are received, then the reconfigure process is successful. If some or all of the expected Reconfigure-reply messages are not received, then the server retransmits the Reconfigure, and doubles the RECREP_MSG_TIMEOUT value, and waits again. The server continues this process until all Reconfigure-reply messages are received or REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the server SHOULD abort the reconfigure process. The server SHOULD log the result of the reconfigure process. Default and initial values for RECREP_MSG_TIMEOUT and REC_MSG_ATTEMPTS are documented in section 3.5. 12.4.3. Receipt of Reconfigure-reply messages Upon receipt of a valid Reconfigure-reply message, the server removes that client from the list of clients it is expecting a Reconfigure-reply message from. 12.4.4. Creation and sending of Reconfigure-init messages When creating a Reconfigure-init message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 8. The server generates a transaction-ID from the 0--1023 range and inserts it in the ``transaction-ID'' field. The server places its address (of appropriate scope) in the ``server-address'' field. The server MAY generate an ERE extension to inform the client of what information has been changed or new information that has been added. If the DHCP domain is using authentication, the server will generate an authentication extension with the appropriate settings and add that extension as the last extension in the ``extensions'' field of the Reconfigure-init message. Typically, the server will not provide more than an ERE and / or Authentication extension, since it will provide the new configuration information as part of the Request/Reply transaction triggered by the Reconfigure-init message. The server multicasts the Reconfigure-init message to one or more Reconfigure Multicast Addresses previously sent as extensions to the clients. Note that a server MAY unicast Reconfigure-init Bound, Carney, Perkins Expires 1 November 2000 [Page 40] Internet Draft DHCP for IPv6 5 May 2000 message(s) to specific clients by walking its list of bindings to determine the unicast address(es) of the clients. Whether or not the Reconfigure-init is multicast or unicast is an implementation detail. A server waits for a Request message from each client confirming that they have received the Reconfigure-init and are thus initiating a Request/Reply transaction with the server. The server can determine that a Request message is in response to a Reconfigure-init because the transaction-ID in the Request will be the same value as was used in the Reconfigure-init message. 12.4.5. Time out and retransmission of Reconfigure-init messages The server uses the same algorithm and configuration values for sending Reconfigure-init messages as it does with Reconfigure messages. See Section 12.4.2 for this algorithm. 12.4.6. Receipt of Request messages Upon receipt of a valid Request message with the same transaction-ID as the Reconfigure-init messages it sent, the server removes that client from the list of clients it is expecting to initiate a Request/Reply transaction. The server generates and sends Reply message(s) to the client as described in section 11.6.3, including in the ``extension'' field new values for configuration parameters. If the extensions include releasable resources, the server will include two extensions for each resource - one with the original values with the lease times set to zero, and another with new values and lease times. Note that the server can terminate the client's ability to use a resource simply by including only the first extension value. 12.5. Client Behavior A client MUST always monitor UDP port 546 for Reconfigure and Reconfigure-init messages on interfaces upon which it has acquired DHCP parameters. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface. Bound, Carney, Perkins Expires 1 November 2000 [Page 41] Internet Draft DHCP for IPv6 5 May 2000 12.5.1. Receipt of Reconfigure messages Upon receipt of a valid Reconfigure message, the client extracts the configuration parameters contained in the ``extensions'' field, and notifies the application layer that new values for these parameters are available. The client then generates and sends a Reconfigure-reply message to the server. 12.5.2. Creation and sending of Reconfigure-reply messages When creating a Reconfigure-reply message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 7, and places the link-local address of the interface upon which it received the Reconfigure message in the ``client's link-local address'' field. The client copies the values of the following fields from the Reconfigure message to the Reconfigure-reply message: o transaction-ID o server-address The client sets the ``status'' field appropriately (see the table in section 3.4) based upon the results of processing the server's reconfigure-reply. The client places the address of the destination server in the ``server-address'' field. If the client is configured to use authentication, the client generates the appropriate authentication extension, and adds this extension to the ``extensions'' field. Note that the authentication extension MUST be the last extension in the ``extensions'' field. The client delays the sending of the Reconfigure-reply by some random value selected in the range of REC_REP_MIN and REC_REP_MAX seconds. This delay helps reduce the load on the server generated by processing large numbers of Reconfigure-reply messages. Default and initial values for REC_REP_MIN and REC_REP_MAX are documented in section 3.5. The client unicasts the Reconfigure-reply to the address identified in the ``server-address'' field. Sending the Reconfigure-reply completes the reconfiguration process for the client. Bound, Carney, Perkins Expires 1 November 2000 [Page 42] Internet Draft DHCP for IPv6 5 May 2000 12.5.3. Receipt of Reconfigure-init messages Upon receipt of a valid Reconfigure-init message, the client initiates a Request/Reply transaction with the server. 12.5.4. Creation and sending of Request messages When responding to a Reconfigure-init, the client creates and sends the Request message in exactly the same manner as outlined in section 11.4.1 with the following differences: transaction-ID The client copies the transaction-ID from the Reconfigure-init message into the Request message. Pause before sending Request The client pauses before sending the Request for a random value within the range REC_REP_MIN and REC_REP_MAX seconds, as outlined in section 12.5.2. 12.5.5. Time out and retransmission of Request messages The client uses the same variables and retransmission algorithm as it does with Request messages generated as part of a client-initiated configuration exchange. See section 11.4.2 for details. 12.5.6. Receipt of Reply messages Upon the receipt of a valid Reply message, the client extracts the contents of the ``extension'' field, and sets (or resets) configuration parameters appropriately. If the configuration parameters changed were requested by the application layer, the client notifies the application layer of the changes using an implementation-specific interface. If the resources changed are releasable, the client makes the appropriate adjustments to its management of the leases of these resources. 13. Using DHCP for network renumbering An administrator can use DHCP to renumber links within her DHCP domain through two techniques, passive renumbering and active renumbering. Bound, Carney, Perkins Expires 1 November 2000 [Page 43] Internet Draft DHCP for IPv6 5 May 2000 13.1. Passive Renumbering The administrator can configure her servers to return relatively short preferred and valid lifetimes for the IP addresses she makes available to clients. When she determines that she'd like to renumber a network, she configures her servers through an implementation-specific manner to disallow the extension of the IP address lifetimes on the original network, and adds the new network configuration data to the server's database. The clients on the original network will fail to acquire lifetime extensions on their IP addresses, and will request and acquire IP addresses from the new network when the valid lifetime of the original IP addresses approaches expiration. When the lifetimes for all of the IP addresses on the original network expire, the network can be considered renumbered. 13.2. Active Renumbering The administrator can force the renumbering of networks in her DHCP domain by using the reconfigure feature of DHCP. She instructs her servers of the network renumbering through an implementation-specific interface. The servers in the domain will generate Reconfigure-init messages, which will cause the clients to initiate a Request/Reply transaction with the server. The servers will include two IP address extensions for each IP address being changed. The first will contain the original IP address, with the preferred and valid lifetimes set to zero. The second will contain the new IP address, with non-zero preferred and valid lifetimes. A server implementation MAY permit the administrator to set the original IP address lifetimes to some small value greater than zero, to allow applications running on the client to orderly transfer to the new network over time. 14. DHCP Client Implementator Notes This section provides helpful information for the client implementor regarding their implementations. The text described here is not part of the protocol, but rather a discussion of implementation features we feel the implementor should consider during implementation. Bound, Carney, Perkins Expires 1 November 2000 [Page 44] Internet Draft DHCP for IPv6 5 May 2000 14.1. Primary Interface Since configuration parameters acquired through DHCP can be interface-specific or more general, the client implementor SHOULD provide a mechanism by which the client implementation can be configured to specify which interface is the primary interface. The client SHOULD always query the DHCP data associated with the primary interface for non-interface specific configuration parameters. An implementation MAY implement a list of interfaces which would be scanned in order to satisfy the general request. In either case, the first interface scanned is considered the primary interface. By allowing the specification of a primary interface, the client implementor identifies which interface is authoritative for non-interface specific parameters, which prevents configuration information ambiguity within the client implementation. 14.2. Advertise Message and Configuration Parameter Caching If the hardware the client is running on permits it, the implementor SHOULD provide a cache for Advertise messages and a cache of configuration parameters received through DHCP. Providing these caches prevents unnecessary DHCP traffic and the subsequent load this generates on the servers. The implementor SHOULD provide a configuration knob for setting the amount of time the cache(s) are valid. 14.3. Time out and retransmission variables Note that the client time out and retransmission variables outlined in section 3.5 can be configured on the server and sent to the client through the use of the ``DHCP Retransmission Parameter Extension'', which is documented in the ``extensions document'' [2]. A client implementation SHOULD be able to reset these variables using the values from this extension. 14.4. Server Preference A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages and compare their preferences (see section 15.3), unless it receives an Advertise message with a preference of 255. If the client receives an Advertise message with a preference of 255, then the client MAY act immediately on that Advertise without waiting for any more additional Advertise messages. Bound, Carney, Perkins Expires 1 November 2000 [Page 45] Internet Draft DHCP for IPv6 5 May 2000 15. DHCP Server Implementator Notes This section provides helpful information for the server implementor. 15.1. Client Bindings A server implementation can use the client's link-local address and the subnet prefix specification from which the client sent its Request message(s) as an index for finding configuration parameters assigned to the client. While it isn't critical to keep track of which clients were given information (resources) that isn't releasable, it IS critical for the server to keep track of which client it has assigned releasable resources. The server MUST include the transaction-ID from the client's Request along with the releasable resource identifier(s) within the binding. This is done so that the server can detect whether a client Request is a retransmission of an earlier Request or an entirely new Request. The server should periodically scan its bindings for releasable resources whose leases have expired. When the server finds expired resource assignments, it MUST delete these assignments, thereby making these resources available to other clients. The client bindings MUST be stored in non-volatile storage. The server implementation should provide policy knobs to control whether or not the lease on a releasable resource is renewable, and by how long. 15.2. Reconfigure Considerations A server implementation MUST provide an interface to the administrator for initiating reconfigure events. A server implementation may provide a mechanism for allowing the specification of how many clients comprise a reconfigure multicast group. This enables the administrator to control the hit a server takes when a reconfigure event occurs. 15.3. Server Preference The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference variable is an unsigned single octet value (0--255), with the lowest preference being 0 and the highest 255. Clients will choose higher preference servers over those with lower preference values. If you Bound, Carney, Perkins Expires 1 November 2000 [Page 46] Internet Draft DHCP for IPv6 5 May 2000 don't choose to implement this feature in your server, you MUST set the server preference field to 0 in the Advertise messages generated by your server. 15.4. Request Message Transaction-ID Cache In order to improve performance, a server implementation MAY include an in memory transaction-ID cache. This cache is indexed by client binding and transaction-ID, and enables the server to quickly determine whether a Request is a retransmission or a new Request without the cost of a database lookup. If an implementor chooses to implement this cache, then they SHOULD provide a configuration knob to tune the lifetime of the cache entries. 16. DHCP Relay Implementator Notes A relay implementation SHOULD allow the specification of a list of destination addresses for Solicit messages. This list MAY contain any mixture of unicast addresses and multicast addresses. If a relay receives an ICMP message in response to a DHCP message it has forwarded, it SHOULD log this event. 17. Open Issues for Working Group Discussion This section contains some items for discussion by the working group. 17.1. Trade-offs: Optional fields in DHCP messages You'll notice that the message formats have changed. In particular, some of the optional fields are now required. This will increase the size of DHCP messages in some cases, consuming network bandwidth and memory on the DHCP client (an issue for small devices such as PDAs). The changes were made for the following reasons: o Fields that were used most of the time were made required. o Some fields that were optional were either made required or added to messages which previously didn't have them. This was done for robustness reasons (receivers can validate that the message is for them, and in the case of clients, know which interface the message is intended for). o Simplicity. Bound, Carney, Perkins Expires 1 November 2000 [Page 47] Internet Draft DHCP for IPv6 5 May 2000 Please look at the messages as they are now defined, and let us know your opinion. 17.2. Use DHCPv4 authentication or the current DHCPv6 method? Now that the DHCPv4 authentication draft is in last call, should we use the technique described in that document to provide authentication for DHCPv6, or should we continue with the authentication technique currently documented in the extensions draft? 17.3. The Reconfigure Message and Subnet Prefix Extensions The drafts currently specify that Releasable resources (such as an IP address) can only be reconfigured using the Reconfigure-init trigger message. This was done for simplicity (enables clients to perform DAD on the new address and return the appropriate result to the server) using the same mechanism as a standard Request/Reply/Release exchange. This method also makes no assumptions about the charactistics of the releasable resource. However, for IP addresses with interface IDs, one could send out two IP address extensions, one for the old prefix and one for the new, and cause clients to change the prefix and thus renumber over time. This scheme avoids the added DHCP Request traffic - clients acknowledge with a Reconfigure-reply message. 17.4. ``R'' bit in Request message not needed? Now that the transaction-ID is stored along with the releasable resource identifier in a client's binding, the transaction-ID cache becomes an optional feature of the DHCP server implementation, not a requirement of the protocol. Should we do away with the ``R'' bit? 18. Security Considerations Clients and servers often have to authenticate the messages they exchange. For instance, a server may wish to be certain that a Request originated from the client identified by the fields included within the Request message header. Conversely, it is quite often essential for a client to be certain that the configuration parameters and addresses it has received were sent to it by an authoritative server. Similarly, a server should only accept a Release message which seems to be from one of its clients, if it has some assurance that the client actually Bound, Carney, Perkins Expires 1 November 2000 [Page 48] Internet Draft DHCP for IPv6 5 May 2000 did transmit the Release message. Again, a client might wish to only accept Reconfigure or Reconfigure-init messages that are certain to have originated from a server with authority to issue them. The IPv6 Authentication Header can provide security for DHCPv6 messages when both endpoints have a suitable IP address. However, a client often has only a link-local address, and such an address is not sufficient for a server which is off-link. In those circumstances the relay is involved, so that the DHCP message MUST have the relay's address in the IP destination address field, even though the client aims to deliver the message to the server. The DHCP Client-Server Authentication Extension [2] is intended to be used in these circumstances. Note that, if a client receives a DHCP message which fails authentication, it should continue to wait for another message which might be correctly authenticated just as if the failed message had never arrived; however, receiving such failed messages SHOULD be logged. 19. Year 2000 considerations Since all times are relative to the current time of the transaction, there is no problem within the DHCPv6 protocol related to any hardcoded dates or two-digit representation of the current year. 20. IANA Considerations This document defines message types 1--8 to be received by UDP at port numbers 546 and 547. Additional message types may be defined in the future. Section 3.1 lists several multicast addresses used by DHCP. This document also defines several status codes that are to be returned with the Reply and Reconfigure-reply messages (see sections 9.4 and 9.7). The non-zero values for these status codes which are currently specified are shown in the table in section 3.4. There is a DHCPv6 extension [2] which allows clients and servers to exchange values for some of the timing and retransmission parameters defined in section 3.5. Adding new parameters in the future would require extending the values by which the parameters are indicated in the DHCP extension. Since there needs to be a list kept, the default values for each parameter should also be stored as part of the list. Bound, Carney, Perkins Expires 1 November 2000 [Page 49] Internet Draft DHCP for IPv6 5 May 2000 All of these protocol elements may be specified to assume new values at some point in the future. New values should be approved by the process of IETF Consensus [11]. 21. Acknowledgements Thanks to the DHC Working Group for their time and input into the specification. Ralph Droms and Thomas Narten have had a major role in shaping the continued improvement of the protocol by their careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald Maguire, and Mike Carney for their studied review as part of the Last Call process. Thanks also for the consistent input, ideas, and review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. Thanks to Steve Deering and Bob Hinden, who have consistently taken the time to discuss the more complex parts of the IPv6 specifications. A. Comparison between DHCPv4 and DHCPv6 This appendix is provided for readers who will find it useful to see a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. There are three key reasons for the differences: o IPv6 inherently supports a new model and architecture for communications and autoconfiguration of addresses. o DHCPv6 benefits from the new IPv6 features. o New features were added to support the expected evolution and the existence of more complicated Internet network service requirements. IPv6 Architecture/Model Changes: o The link-local address permits a node to have an address immediately when the node boots, which means all clients have a source IP address at all times to locate an on-link server or relay. o The need for BOOTP compatibility and the broadcast flag have been removed. o Multicast and address scoping in IPv6 permit the design of discovery packets that would inherently define their range by the multicast address for the function required. Bound, Carney, Perkins Expires 1 November 2000 [Page 50] Internet Draft DHCP for IPv6 5 May 2000 o Stateful autoconfiguration has to coexist and integrate with stateless autoconfiguration supporting Duplicate Address Detection and the two IPv6 lifetimes, to facilitate the dynamic renumbering of addresses and the management of those addresses. o Multiple addresses per interface are inherently supported in IPv6. o Some DHCPv4 options are unnecessary now because the configuration parameters are either obtained through IPv6 Neighbor Discovery or the Service Location protocol [16]. DHCPv6 Architecture/Model Changes: o The message type is the first byte in the packet. o IPv6 Address allocations are now handled in a message extension as opposed to the message header. o Client/Server bindings are now mandatory and take advantage of the client's link-local address to always permit communications either directly from an on-link server, or from a off-link server through an on-link relay. o Servers are discovered by a client Solicit, followed by a server Advertise message o The client will know if the server is on-link or off-link. o The on-link relay may locate off-link server addresses from system configuration or by the use of a site-wide multicast packet. o ACKs and NAKs are not used. o The server assumes the client receives its responses unless it receives a retransmission of the same client request. This permits recovery in the case where the network has faulted. o Clients can issue multiple, unrelated Request messages to the same or different servers. o The function of DHCPINFORM is inherent in the new packet design; a client can request configuration parameters other than IPv6 addresses in the optional extension headers. o Clients MUST listen to their UDP port for the new Reconfigure message from servers. Bound, Carney, Perkins Expires 1 November 2000 [Page 51] Internet Draft DHCP for IPv6 5 May 2000 o New extensions have been defined. With the changes just enumerated, we can support new user features, including o Configuration of Dynamic Updates to DNS o Address deprecation, for dynamic renumbering. o Relays can be preconfigured with server addresses, or use of multicast. o Authentication o Clients can ask for multiple IP addresses. o Addresses can be reclaimed using the Reconfigure-init message. o Integration between stateless and stateful address autoconfiguration. o Enabling relays to locate off-link servers. B. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Bound, Carney, Perkins Expires 1 November 2000 [Page 52] Internet Draft DHCP for IPv6 5 May 2000 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. References [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, March 1997. [2] J. Bound, M. Carney, and C. Perkins. Extensions for the Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress). [3] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [4] S. Bradner and A. Mankin. The Recommendation for the IP Next Generation Protocol. Request for Comments (Proposed Standard) 1752, Internet Engineering Task Force, January 1995. [5] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for Comments 951, Internet Engineering Task Force, September 1985. [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [7] R. Droms. Dynamic Host Configuration Protocol. Request for Comments (Draft Standard) 2131, Internet Engineering Task Force, March 1997. [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. Request for Comments (Proposed Standard) 2373, Internet Engineering Task Force, July 1998. [9] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP version 6. Request for Comments (Proposed Standard) 1981, Internet Engineering Task Force, August 1996. [11] T. Narten and H. Alvestrand. Guidelines for Writing an IANA Considerations Section in RFCs. Request for Comments (Best Current Practice) 2434, Internet Engineering Task Force, October 1998. Bound, Carney, Perkins Expires 1 November 2000 [Page 53] Internet Draft DHCP for IPv6 5 May 2000 [12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [13] D. C. Plummer. Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. Request for Comments (Standard) 826, Internet Engineering Task Force, November 1982. [14] J. Postel. User Datagram Protocol. Request for Comments (Standard) 768, Internet Engineering Task Force, August 1980. [15] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [16] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. Request for Comments (Proposed Standard) 2165, Internet Engineering Task Force, June 1997. [17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System (DNS UPDATE). Request for Comments (Proposed Standard) 2136, Internet Engineering Task Force, April 1997. Bound, Carney, Perkins Expires 1 November 2000 [Page 54] Internet Draft DHCP for IPv6 5 May 2000 Chair's Address The working group can be contacted via the current chair: Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (570) 577-1145 E-mail: droms@bucknell.edu Author's Address Questions about this memo can be directed to: Jim Bound Compaq Computer Corporation Mail Stop: ZK03-3/U14 110 Spitbrook Road Nashua, NH 03062 USA Phone: +1-603-884-0400 Email: bound@zk3.dec.com Mike Carney Sun Microsystems, Inc Mail Stop: UMPK17-202 901 San Antonio Road Palo Alto, CA 94303-4900 USA Phone: +1-650-786-4171 Email: mwc@eng.sun.com Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Bound, Carney, Perkins Expires 1 November 2000 [Page 55]