INTERNET-DRAFT J. Bound DHC Working Group Digital Equipment Corp Obsoletes: draft-ietf-dhc-dhcpv6-02.txt November 1995 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-03.txt Status of this Memo This document is a submission to the DHC Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the dhcp-v6@bucknell.edu mailing list. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document is an Internet application protocol, for IP version 6 (IPv6), that specifies a client/server model for communications between hosts to dynamically configure parameters for a network, and autoconfigure addresses within a stateful model. This document supports the model for IPv6 Stateless Address Autoconfiguration, where there are clear integration points between stateless and stateful address autoconfiguration for IPv6. Expires May 1996 [Page 1]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Table of Contents: 1. Introduction.................................................3 1.1. Requirements...............................................3 2. Terminology and Definitions..................................4 2.1. IPv6 Terminology...........................................4 2.2. DHCPv6 Terminology.........................................6 3. Protocol Design Model........................................9 3.1. Design Goals...............................................9 3.2. Request/Response Model....................................10 3.3. Leased Address Model......................................11 3.3.1. Address Lifetimes.......................................11 3.3.2. Duplicate Address Detection.............................12 3.3.3. Releasing Infinite Lifetime Addresses...................13 3.4. DNS Host Name Autoregistration Model......................13 4. Request/Response Processing.................................13 4.1. Processing when Server Address is not Known...............14 4.2. Processing when Server Address is Known...................16 4.3. Retransmission and Configuation Variables.................16 5. Datagram and Field Definitions..............................18 5.1. Datagram..................................................18 5.2. Field Definitions.........................................19 6. Client/Server Message Formats...............................21 6.1. Client/Server UDP Ports, Multicast Group, and Addresses...21 6.2. Client DISCOVER and CONF-REQUEST Messages.................21 6.3. Server CONF-RESPONSE Message..............................23 6.4. Client ACCEPT Message.....................................24 6.5. Server SERVER-ACK Message.................................25 6.6. Client RELEASE Message....................................27 7. Relay-Agent Processing......................................28 8. Security Considerations.....................................29 Appendix A - Related Work in IPv6..............................29 Change History.................................................31 Acknowledgements...............................................33 References.....................................................33 Authors' Address...............................................34 Expires May 1996 [Page 2]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 1. Introduction DHCPv6 is an Internet application protocol, for IP version 6 (IPv6), that specifies a client/server model for communications between hosts to dynamically configure parameters for a network, and autoconfigure addresses within a stateful model. DHCPv6 supports the model for IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], where there are clear integration points between stateless and stateful address autoconfiguration for IPv6. DHCPv6 uses a set of request/response messages to support a transaction processing model where a commit to the data can be verified by both the client and server. This affords DHCPv6 the ability in the future to support dynamic updates to data located within a sites network. In addition to the capability of verifying commits to transactions a recovery mechanism is specified, should commits need to be rolled back during the course of a DHCPv6 transaction being processed. DHCPv6 supports optional configuration parameters and processing for hosts through its companion document Options for the Dynamic Host Configuration Protocol for IPv6 [DHCPv6-OPT]. The IPv6 Addressing Architecture [IPv6-ADDR] and IPv6 Stateless Address Autoconfiguration specifications provide new functionality not present in IP version 4 (IPv4). This new IPv6 functionality provides inherent benefits to autoconfigure IPv6 addresses for nodes. In addition the IETF DNS Working Group has defined a method to support Dynamic Updates to DNS [DYN-UPD], which can be used by a node to add, delete, and change node names dynamically. DHCPv6 used several of the architecture principles from DHCPv4 [DHCP-v4], but it is beyond the scope of this document to contrast and compare DHCPv6 with DHCPv4. Section 2 provides definitions for terminology used throughout this document. Section 3 provides a review of the protocol design model parts that are inherent in the specification. Section 4 provides the request/response model and interaction between the set of messages and the semantics for those messages. Section 5 provides the datagram packet format and field definitions for that datagram. Section 6 provides the message formats and field contents for processing the client and server messages. Section 7 provides the specification of how relay-agents and servers interact with clients, when the server is not on the same link as the client. Section 8 provides the security specifications that can be used to support security in DHCPv6. Appendix A provides a summary of related work in IPv6 that will help put DHCPv6 in the context of IPv6 for the reader, and is not part of this specification, but here for information purposes. 1.1. Requirements Throughout this document, the words that are used to define the significance of the particular requirements are capitalized. These words are: Expires May 1996 [Page 3]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. o "MUST NOT" This phrase means the item is an absolute prohibition of this specification. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighted before implementing any behavior described with this label. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example, another vendor may omit the same item. 2. Terminology and Definitions Relevant terminology from the IPv6 Protocol [IPv6-SPEC], IPv6 Addressing Architecture, and IPv6 Stateless Address Autoconfiguration will be provided, and then the DHCPv6 terminology. 2.1. IPv6 Terminology IP - Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 are used only in contexts where necessary to avoid ambiguity. node - A device that implements IPv6. router - A node that forwards IPv6 packets not explicitly addressed to itself. host - Any node that is not a router. upper-layer - A protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being Expires May 1996 [Page 4]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 "tunneled" over (e.g. encapsulated in) IP such as IPX, Appletalk, or IP itself. link - A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6. Examples are Ethernet (simple or bridged); PPP links, X.25, Frame Relay, or ATM networks; and internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. neighbors - Nodes attached to the same link. interface - A node's attachment to the link. address - An IP layer identifier for an interface or a set of interfaces. packet - An IP header plus payload. communication - Any packet exchange between nodes that requires that the address of each node used in the exchange remain the same for the duration of the packet exchange. Examples are a TCP connection or UDP request/response. 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. link-layer identifier - a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links, and E.164 addresses for ISDN links. link-local address - An address having link-only scope that can be used to reach neighboring nodes attached to the same link. All interfaces have a link-local address. preferred address - An address assigned to an interface whose use by upper layer protocols is unrestricted. Preferred addresses may be used as the source or destination address of packets sent from or to the interface. deprecated address - An address assigned to an interface whose use is discouraged, but not forbidden. A deprecated address should no longer be used as a source address in new communications. but packets sent to a Expires May 1996 [Page 5]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 deprecated address are delivered as expected. A deprecated address may continue to be used as a source address for the duration of existing communications. valid address - A preferred or deprecated address. A valid address may appear as the source or destination address of a packet, and the internet routing system is expected to be able to deliver packets sent to a valid address. invalid address - An address that is not assigned to any interface. A valid address becomes invalid when its valid lifetime expires. Invalid addresses should not appear as the source or destination of a packet. preferred lifetime - The length of time that a valid address is preferred. When the preferred lifetime expires, the address becomes deprecated. valid lifetime - The length of time the address remains in the valid state. The valid lifetime MUST be greater than or equal to the preferred lifetime. When the valid lifetime expires, the address becomes invalid. interface token - A link-dependent identifier for an interface that is (at least) unique per link. Stateless Address Autoconfiguration combines an interface token with a prefix to form an address. From an address autoconfiguration perspective, an interface token is a bit string of known length. The exact length of an interface token and the way it is created is defined in a separate link-specific document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). In many cases the token will be the same as the link-layer address. 2.2. DHCPv6 Terminology configuration parameters - Is any parameter that can be used by a node to configure their network environment so the node can communicate on a link or on an internet. client - A client is a host that initiates requests on a link to obtain: addresses, dynamic updates to DNS, or other configuration parameters. server - A server is a node that responds to requests from clients on a link to provide: addresses, dynamic updates to DNS, or other configuration parameters. Expires May 1996 [Page 6]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 relay-agent - A relay-agent is a node that listens on a link for client requests, and then forwards the packet to a server on the network. The server will respond back to the relay-agent, who will forward the response to the client on the relay-agents link. message-type - The message-type defines the DHCPv6 protocol type for this packet. message-flag - The message-flag defines an optional processing notification for DHCPv6. The message-flag can also be used by the Options for DHCPv6 specification. error-code - The error-code specifies errors from a client or server. The error-code can also be used by the Options for DHCPv6 specification. total-addresses - The total-addresses specifies the total number of addresses being provided from a server to a client. For each address there is a preferred and valid lifetime. completed-transaction - A completed-transaction is a communications exchange between a client and server, using the required set of DHCPv6 request/response message-types, where the final response message in the request/response set has been received by the client and by the server. transaction-ID - The transaction-ID is an integer identifier specified by the client and is used by the client and server as a transaction identifier to define the set of request/response messages between the client and server, for a clients interface token. client-link address - The client-link address specifies the clients link-local address. The client-link address is used by a relay-agent to respond to a client on a link, after receiving a server response. server address - The server address specifies the address for the server responding to a client. gateway address - The gateway address specifies the address of the relay-agent for a server, which may be multiple relay-agent hops away from the original relay-agent. client address - The client address specifies an address from a server to be used by a client. binding - A binding in DHCPv6 is an N-tuple that a client and server MUST maintain in DHCPv6 for a Expires May 1996 [Page 7]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 completed-transaction, where N is the number of configuration parameters for a client. An implementation MUST support at least a 5-tuple binding consisting of a clients interface token, client address, preferred lifetime and valid lifetime for each client address, and the transaction-ID. Expires May 1996 [Page 8]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 3. Protocol Design Model This section is provided for implementors to understand the DHCPv6 protocol design model from an architectural perspective. Any conceptual models presented in this specification that provide implementation examples are not a requirement of the DHCPv6 protocol. 3.1. Design Goals The following list gives general design goals for DHCPv6. DHCPv6 should be a mechanism rather than a policy. DHCPv6 must allow local system administrators control over configuration parameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired. Hosts should require no manual configuration. Each host should be able to discover appropriate local configuration parameters without user intervention, and incorporate those parameters into its own configuration. Networks should require no hand configuration for individual hosts. Under normal circumstances, the network manager should not have to enter any per-host configuration parameters. DHCPv6 should not require a server on each link. To allow for scale and economy, DHCPv6 must work across relay agents. A DHCPv6 client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCPv6 servers to enhance reliability and increase performance. DHCPv6 must coexist with statically configured, non-participating hosts and with existing network protocol implementations. DHCPv6 should as much as possible be compatible with IPv6 Stateless Address Autoconfiguration. DHCPv6 must support the requirements of automated renumbering of IPv6 addresses. DHCPv6 servers should be able to support Dynamic Updates to DNS [DYN-UPD]. It is NOT a design goal of DHCPv6 to specify a server to server protocol. It is NOT a design goal of DHCPv6 to specify how a server configuration parameter database is maintained or determined. The following list gives design goals specific to the transmission of the network layer parameters. Guarantee that any specific network address will not be in use by more than one host at a time. Expires May 1996 [Page 9]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Guarantee that client addresses that are not provided by DHCPv6 will not be added to a servers configuration parameter database or the servers binding for a clients interface token. Retain host configuration parameters across client reboots. A client should, whenever possible, be assigned the same configuration parameters in response to a request. Retain host configuration across server reboots, and, whenever possible, a host should be assigned the same configuration parameters despite restarts of the DHCPv6 mechanism, Allow automatic assignment of configuration parameters to new hosts to avoid hand configuration for new hosts. Support fixed or permanent allocation of configuration parameters to specific hosts. 3.2. Request/Response Model DHCPv6 uses a message-type to define whether the packet originated from a DHCPv6 server or client. The set of packets used to complete a DHCPv6 transaction are defined as the request and response set. The message types are as follows: 01 DISCOVER The DISCOVER message is a DHCPv6 multicast packet from a client to locate and request configuration parameters on a network, when the client does not know the servers address. 02 CONF-REQUEST The CONF-REQUEST is an IPv6 unicast packet from a client to a server, when the client knows the IPv6 unicast address of a server, to request configuration parameters on a network. 03 CONF-RESPONSE The CONF-RESPONSE is an IPv6 unicast packet from a server in response to a client DISCOVER or CONF-REQUEST, which provides the requested configuration parameters. 04 ACCEPT The ACCEPT is a client response to a server CONF-RESPONSE. When the client used DISCOVER to locate a server and request configuration parameters on a network, the ACCEPT should be sent using the DHCPv6 multicast address, which also serves to inform other servers that responded to the DISCOVER they were not selected. When the client used CONF-RESPONSE to request configuration parameters from a server whose address was known, the ACCEPT should be sent as an IPv6 unicast packet. The ACCEPT is also an implied acknowledgment to the server selected that the client has received the servers configuration Expires May 1996 [Page 10]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 parameters from the CONF-RESPONSE. 05 SERVER-ACK The SERVER-ACK is an IPv6 unicast packet sent by a server to inform a client that it received an ACCEPT. The SERVER-ACK is used by the server to inform the client it has received an acknowledgment that the client has received the configuration parameters from the server, and denotes a completed-transaction to a server. The server at that point MUST commit its bindings and any updates it may do for the client. The SERVER-ACK for the client denotes a completed-transaction. The client at that point MUST commit its bindings. 06 RELEASE The RELEASE is used by the client for two reasons: 1. To inform the server that the client did not receive the SERVER-ACK required to complete the client transaction, and the server should delete that binding and any updates it may have done on behalf of the client. 2. To inform the server that the client is releasing a particular address or set of addresses, even though the lifetimes for those addresses may not have become invalid. The processing and algorithms for the request/response set of message-types will be discussed in section 4.0. 3.3. Leased Address Model The leased address model specifies a set of lifetimes associated with addresses returned by the server. These lifetimes are meant to support site renumbering, and are completely compatible with the leasing model in IPv6 Stateless Address Autoconfiguration. The DHCPv6 philosophy is that the client has the responsibility to renew a lease for an address that is about to expire, or request a new address or the same address before the lease actually expires. If the client does not request a new lease for an address, the server MUST assume the client does not want a new lease for that address. The server MAY provide that address to another client requesting an address, after all other addresses available to the server have been exhausted. 3.3.1. Address Lifetimes An address returned to a client has a preferred and valid lifetime. The lifetimes represent the lease for addresses provided to the client, from the server. The client MAY request a value for the lifetimes returned by a server, but the client MUST use the lifetimes provided by the server Expires May 1996 [Page 11]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 response. When an address for a client interface becomes deprecated the processing of the lease MUST be as follows: When the preferred lifetime of an address expires, the clients address becomes a deprecated address. A deprecated address can be used as a source address in new communications and existing communications. But a deprecated address means the node will soon have an address whose valid lifetime will expire, when this happens the address cannot be used in any communications. An address is a deprecated until its valid lifetime expires at which point the address becomes an invalid address. An invalid address MUST NOT be used as a source address in outgoing communications, and MUST NOT be recognized as a valid destination address for incoming communications. Once an address is deprecated an implementation SHOULD request a new lease or address for that interface. If the clients preferred lifetime is zero for an address the address is immediately deprecated. Implementors of DHCPv6 would find it beneficial to coordinate the use of the preferred lifetime and valid lifetime for layers below the DHCPv6 application layer with their implementation of Stateless Address Autoconfiguration. It is suggested that implementations use the same modules to configure addresses for stateless and stateful address autoconfiguration. Implementors might want to consider an option to stop all new communications for a deprecated address, to support a very robust renumbering strategy, but this cannot be the default behavior. 3.3.2. Duplicate Address Detection DHCPv6 clients MUST support Duplicate Address Detection as specified in IPv6 Stateless Address Autoconfiguration. This will provide a high guarantee that DHCPv6 client addresses are not duplicated on a link. It is an option for a server to inform the client it does not have to perform Duplicate Address Detection by the server setting a value of 01 in the message-flag in client responses. In this case it is assumed that the server implementation is providing the guarantee that the client addresses returned are unique on the link. It is implementation defined how a server verifies the uniqueness of client addresses on a link. A conceptual model of an implementation for DHCPv6 duplicate address detection is that the client DHCPv6 module, which supports updating the network interfaces for a host, would use the same application configuration interface for DHCPv6 as is used for IPv6 Stateless Address Autoconfiguration on an IPv6 conforming implementation. An implementation can integrate and reuse the same modules in the network operating system kernel to spawn duplicate address detection, address lifetime processing, and the processing of deprecated and invalid addresses for existing and new connections. Expires May 1996 [Page 12]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 3.3.3. Releasing Infinite Lifetime Addresses DHCPv6 specifies no behavior which would require a client to listen for asynchronous messages from servers on a well known UDP port. The reason for this is that minimal implementations may not be able to support such a feature in a client. But DHCPv6 does permit the client to request an infinite lease for addresses. The problem in this case is that though the server has permitted an infinite lease for a client it may later be required that the client give up that lease or the addresses, for some organizational reason. This specification leaves it as implementation defined how this problem is solved in a DHCPv6 network environment. One solution to the problem is to define an SNMP MIB for DHCPv6 clients that when set by a network management agent causes a client to revalidate all of its addresses with the DHCPv6 server or issue a RELEASE to the server. 3.4. DNS Host Name Autoregistration Model It is important that DHCPv6 provide a server implementation set of options for Dynamic Updates to DNS (DYNDNS), to support the autoregistration of addresses to names in IPv6. DYNDNS SHOULD be supported as a set of options in DHCPv6 as specified in the Options for DHCPv6 specification. The minimum requirements to support DYNDNS in DHCPv6 are as follows: 1. Clients SHOULD be able to request or change names for addresses. 2. Servers SHOULD be able to provide names for addresses provided to a client. 3. If servers support DYNDNS then they MUST support the following: a) Create, Update, and Delete of IPv6 AAAA Records [IPv6-DNS] as specified in DYNDNS [DYN-UPD]. b) Create, Update, and Delete of IPv6 IP6.INT Domain PTR records for any IPv6 AAAA addresses defined in a client DYNDNS request, or that the server automatically generated for a client. 4. Request/Response Processing The request/response processing for DHCPv6 is transaction based and uses a best-effort set of messages to guarantee a completed- transaction. The case where the client does not know the servers address is depicted, and then the case where the client does know the servers address is depicted. Then the timeout and retransmission guidelines and configuration variables are discussed. Expires May 1996 [Page 13]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 4.1. Processing when Server Address is not Known The processing for the DHCPv6 request/response model when the client does not know the server address is as follows: Server Client Server (not selected) (selected) v v v | | | | Begin Transaction | | | | | _____________ | _____________ | | DISCOVER | DISCOVER | | (DHCPv6 Multicast) | | | | Determine Client Configuration | Determine Client Configuration | (Unicast) | | ___________ | ____________ | | CONF-RESPONSE | CONF-RESPONSE | | | | | Collects replies | | | | | Selects configuration | | | | | _____________ | _____________ | | ACCEPT | ACCEPT | | (DHCPv6 Multicast) | | | | | | Commits Client Bindings | | (Unicast) | | | | | _____________ | | | SERVER-ACK | | | | | Transaction Complete | | Client commits Bindings | | | | | IF the Client did not | | receive the SERVER-ACK | | delete the Bindings | | (Unicast) | | | | | | _____________ | | | RELEASE | | | | | | Server deletes the Bindings | | and rolls back any updates that | | that may have been done for the | | client. | | | v v v DHCPv6 uses the UDP [RFC-768] protocol to communicate between clients and servers. UDP is not reliable, but DHCPv6 must provide some reliabilty between clients and servers. The network trade-off is time versus the reliability that the completed set of request/response messages were received by both the client and the Expires May 1996 [Page 14]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 server to define a completed-transaction. The request/response set is always started by a client either with a DISCOVER when the client does not know the servers address, or a CONF-REQUEST when the client does know the servers address. The second message is from the server and is the CONF-RESPONSE. The client then acknowledges the servers CONF-RESPONSE with an ACCEPT. At this point in the flow all data has been received and additional messages are defined to insure the transaction is completed, and to provide a method of recovery if either the client or server do not receive the messages to complete the transaction. The server after receiving the ACCEPT sends a SERVER-ACK, which is an acknowledgment to the client the server has received the clients ACCEPT. At that point the time vs reliability trade-off in DHCPv6 is for the server to commit its bindings, and perform any updates as a result of the client messages (e.g. Update DNS). If the client receives the SERVER-ACK, then the client can commit its bindings. But if the client does not receive the SERVER-ACK then it should send the server a RELEASE to inform the server that any bindings should be deleted and any updates for the client should be rolled back. The client RELEASE provides the final recovery check in the DHCPv6 request/response set to complete a transaction. Retransmission of messages is discussed in section 4.3. The ACCEPT in the flow above is a multicast packet which serves an overloaded function, to respond to the selected server, and to inform other servers on the network the client is not selecting them. Expires May 1996 [Page 15]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 4.2. Processing when Server Address is Known The processing for the DHCPv6 request/response model when the client does knows the server address is as follows (all packets are Unicast): Client Server v v v | | | | Begin Transaction | | | | | | _____________ | | | CONF-REQUEST | | | | | | Determine Client Configuration | | | | | ____________ | | | CONF-RESPONSE | | | | | | _____________ | | | ACCEPT | | | | | | Commits Client Bindings | | | | | _____________ | | | SERVER-ACK | | | | | Transaction Complete | | Client commits Bindings | | | | | IF the Client did not | | receive the SERVER-ACK | | | | | | _____________ | | | RELEASE | | | | | | Server deletes the Bindings | | and rolls back any updates that | | that may have been done for the | | client. | | | v v v The processing above is the same as was discussed in 4.1, except the CONF-REQUEST is used by the client to request configuration parameters from the server, and the CONF-REQUEST and ACCEPT are unicast packets. 4.3. Retransmission and Configuation Variables Configuration variables for a DHCPv6 implementation that MUST be configurable by a client or server are as follows: Retranstimer - The time in seconds that a DHCPv6 client or server should wait before retransmitting a message. Expires May 1996 [Page 16]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Default: 3 seconds. Maxretrans - The maximum retransmissions that a DHCPv6 client or server should retransmit, before logging a DHCPv6 System Error to the user. Default: 3 retransmissions. The problem with retransmissions occurs when they are continually received by a client or server (e.g. duplicate bindings or updates). To support informing a client or server that a retransmission is being done a second set of message-types are supported in DHCPv6 as follows: 20 - DISCOVER-Retrans 21 - CONF-REQUEST-Retrans 22 - CONF-RESPONSE-Retrans 23 - ACCEPT-Retrans 24 - SERVER-ACK-Retrans 25 - RELEASE-Retrans When a client or server retransmits a DHCPv6 packet at the application layer over UDP, they MUST change the message-type to the same message-type with the Retrans suffix. A response to a retransmission SHOULD be a duplicate of a previous response to the client or server. It is implementation defined how this is accomplished. One method of retransmitting duplicates in an implementation conceptually is to use the 5-Tuple binding for a client or server to search for a previous response. At a minimum the client interface token and transaction-ID will be present in all messages; hence a binding can be searched (whether committed or in process) to verify if a previous response has been sent. Expires May 1996 [Page 17]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 5. Datagram and Field Definitions 5.1. Datagram DHCPv6 Datagram +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | msg-flag | error-code | total-addrs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interface token | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | gateway address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client-link address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client address | | (16 octets) | | (can be multiple addresses and lifetimes present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | options (variable number and length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires May 1996 [Page 18]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 5.2. Field Definitions All fields in the datagram MUST be initialized to binary zeroes by both the client and server messages unless otherwise noted in Section 6. msg-type - 1 octet integer value (message-type) Value Description 01 DISCOVER 02 CONF-REQUEST 03 CONF-RESPONSE 04 ACCEPT 05 SERVER-ACK 06 RELEASE 07-19 RESERVED 20 DISCOVER-Retrans 21 CONF-REQUEST-Retrans 22 CONF-RESPONSE 23 ACCEPT-Retrans 24 SERVER-ACK-Retrans 25 RELEASE-Retrans 26-255 RESERVED msg-flag - 1 octet integer value (message-flag) Value Description 01 Server - Duplicate Address Detection not Required. 02-255 RESERVED error-code - 1 octet integer value Value Description 01 Server - Addresses are not available at this time. 02 Server - Address not known by the Server 03-255 RESERVED total-addrs - 1 octet integer value (total-addresses) RESERVED - 2 octets Reserved for future use. transaction-ID - 2 octets integer value interface token - 8 octets link-dependent identifier server address - 16 octets address gateway address - 16 octets address client-link address - 16 octets link-local address preferred lifetime - 4 octets integer value in seconds valid lifetime - 4 octets integer value in seconds Expires May 1996 [Page 19]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 client address - 16 octets address options - variable number of octets [DHCPv6-OPT] Expires May 1996 [Page 20]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 6. Client/Server Message Formats 6.1. Client/Server UDP Ports, Multicast Group, and Addresses A client MUST transmit all messages over UDP using UDP Server Port 547. A server or relay-agent MUST transmit all messages over UDP using UDP Client Port 546. A client MUST receive all messages over UDP using UDP Client Port 546. A server or relay-agent MUST receive all messages over UDP using UDP Server Port 547. A server or relay-agent MUST join the DHCPv6 Server/Relay-Agent multicast group well-known multicast address FF02:0:0:0:0:0:1:0. Servers on the same link as the client MUST use the source address in the IPv6 header from the client as the destination address in the servers response packet. Servers that respond to relay-agents and relay-agent processing are discussed in section 7. In the cases where a client or server must retransmit messages the msg-type codes in this section are used as stated in section 4.3 with the values that represent the Retrans suffix for the msg-types. 6.2. Client DISCOVER and CONF-REQUEST Messages msg-type: If the client does not know the server address or wants to locate a new server to receive configuration parameters the client sets the msg-type to DISCOVER. In this case the client MUST use as the destination IP address the DHCPv6 Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. If the client knows the server address the client sets the msg-type to CONF-REQUEST. In this case the client MUST use as the destination IP address the server address. msg-flag: Set to binary zeroes. error-code: Set to binary zeroes. total-addrs: Set to the number of addresses the client is requesting. transaction-ID: Expires May 1996 [Page 21]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Set to an integer value. interface token: Set to a unique link dependent identifier for the clients interface. server address: Set to binary zeroes for DISCOVER. Set to server address for CONF-REQUEST. gateway address: Set to binary zeroes. client-link address: Set to the clients link-local address for the link on which the client transmitted the packet. preferred lifetime: Set to binary zeroes if the client is not requesting a lifetime. Set to the number of seconds the client wants for the lifetime. Set to all 1's (oxffffffff) if the client wants an infinite lifetime. The client must provide a preferred lifetime for each address requested. valid lifetime: Set to binary zeroes if the client is not requesting a lifetime. Set to the number of seconds the client wants for the lifetime. Set to all 1's (oxffffffff) if the client wants an infinite lifetime. The client must provide a valid lifetime for each address requested. The valid lifetime must be greater than or equal to the preferred lifetime. client address: Set to binary zeroes if the client is not requesting a renewal for an existing address it received from a server. Set to an address the client previously received from a server when the client is requesting a new set of lifetimes for the address. A client MUST NOT provide a server with an address that was not given to the client by a server. DHCPv6 does not permit a server to create leases for manual configured addresses, or update leases for addresses created by IPv6 Stateless Address Autoconfiguration. options: See Options for DHCPv6 specification [DHCPv6-OPT]. Expires May 1996 [Page 22]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 6.3. Server CONF-RESPONSE Message msg-type: Set msg-type to CONF-RESPONSE. msg-flag: Set to 01 if the server knows addresses provided are verified to be unique, otherwise set to binary zeroes. error-code: Set to 01 if the server cannot provide any addresses to the client at this time. Set to 02 if the server detects an address from the client it did not provide to the client. total-addrs: Set to the number of addresses the server is returning the client. transaction-ID: Set to the value the client provided in the DISCOVER or CONF-REQUEST msg-type. interface token: Set to a unique link dependent identifier for the clients interface as provided in the clients DISCOVER or CONF-REQUEST msg-type. server address: The address of the server responding. gateway address: Set to the same value that existed when the server received the packet. client-link address: Set to the same value that existed when the server received the packet. preferred lifetime: Set to the value requested by the client or the value required by the server. valid lifetime: Set to the value requested by the client or the value required by the server. The valid lifetime MUST be greater than or equal to the preferred lifetime. client address: Expires May 1996 [Page 23]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Set to an address provided by the server if the client is not attempting to renew existing addresses, meaning the address fields from the client have a value of binary zeroes. If the error-code is set to 02 the server will only return the addresses that the server can verify were provided by the server. If no addresses could be verified the total-addrs field, lifetimes, and client address will be set to binary zeroes. In the case as far as the server is concerned the DHCPv6 transaction is completed and the server will not expect a client ACCEPT message to its CONF-RESPONSE message. options: See Options for DHCPv6 specification [DHCPv6-OPT]. 6.4. Client ACCEPT Message msg-type: Set msg-type to ACCEPT. If the client sent a DISCOVER to request configuration parameters on the link, then the client should use as the IP destination address the DHCPv6 Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. If the client sent a CONF-REQUEST to request configuration parameters on the link, then the client should use as the IP destination address the server address in the CONF-RESPONSE from the server. If the client sees an error-code of 02 and the total-addrs field is zero, the server cannot process any of the addresses requested and the client should not send an ACCEPT to the server. If the client sees an error-code of 02 and total-addrs does not equal zero it means the server dropped addresses that it could not locate requested by the client. msg-flag: Set to binary zeroes. error-code: Set to binary zeroes. total-addrs: Set to 1. transaction-ID: Set to the integer value that the client used on its initial DISCOVER or CONF-REQUEST msg-type to the server. interface token: Set to the unique link dependent identifier for the clients interface that was used for the clients initial DISCOVER or CONF-REQUEST msg-type Expires May 1996 [Page 24]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 to the server. server address: Set to the address provided by the servers CONF-RESPONSE. gateway address: Set to binary zeroes. client-link address: Set to the clients link-local address for the link on which the client transmitted the packet. preferred lifetime: Set to the first or only preferred lifetime returned for an address by the server. valid lifetime: Set to the first or only valid lifetime returned for an address by the server. The valid lifetime MUST be greater than or equal to the preferred lifetime. client address: Set to the first or only address provided by the server. If the client did receive more than one address and lifetime, it MUST store this data in an implementation defined manner, so that it can issue a complete RELEASE for all addresses provided from the server CONF-RESPONSE, if necessary later. But the ACCEPT does not need to carry all those addresses to acknowledge the servers CONF-RESPONSE packet in an ACCEPT. options: No options are present. 6.5. Server SERVER-ACK Message msg-type: Set msg-type to SERVER-ACK. If the client sent the ACCEPT to acknowledge a servers CONF-RESPONSE message on the DHCPv6 Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0, the server MUST look at the server address in the packet to determine if the ACCEPT is for them or not. If the message is not for a particular server then this is an indirect message to that particular server the client is not accepting them as Expires May 1996 [Page 25]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 their server for this transaction, and MUST NOT send a SERVER-ACK to the clients ACCEPT. msg-flag: Set to binary zeroes. error-code: Set to binary zeroes. total-addrs: Set to 1. transaction-ID: Set to the integer value that the client used on its initial DISCOVER or CONF-REQUEST msg-type to the server. interface token: Set to the unique link dependent identifier for the clients interface that was used for the clients initial DISCOVER or CONF-REQUEST msg-type to the server. server address: Set to the servers address. gateway address: Set to the same value that existed when the server received the packet. client-link address: Set to the same value that existed when the server received the packet. preferred lifetime: Set to the value provided by the client. valid lifetime: Set to the value provided by the client. The valid lifetime MUST be greater than or equal to the preferred lifetime. client address: Set to the address provided by the client. At this point the server MUST commit the configuration parameters provided to the client from the servers CONF-RESPONSE. options: Expires May 1996 [Page 26]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 No options are present. 6.6. Client RELEASE Message msg-type: Set msg-type to RELEASE. If the client had sent an ACCEPT to the server and received a SERVER-ACK for that message then the client MUST commit the configuration parameters provided by the servers CONF-RESPONSE and a RELEASE message is not required. But if the client did not receive a SERVER-ACK in response to the clients ACCEPT, then the client MUST issue a RELEASE to the server. If the client no longer needs an address or has been notified to return an address to the server, then the client SHOULD issue a RELEASE to the server. msg-flag: Set to binary zeroes. error-code: Set to binary zeroes. total-addrs: Set to the total number of addresses the client is releasing. In the case of a RELEASE where the client did not receive the SERVER-ACK this value MUST equal the total number of addresses for the servers CONF-RESPONSE. transaction-ID: Set to the integer value that the client used on its initial DISCOVER or CONF-REQUEST msg-type to the server. interface token: Set to the unique link dependent identifier for the clients interface that was used for the clients initial DISCOVER or CONF-REQUEST msg-type to the server. server address: Set to binary zeroes. gateway address: Set to binary zeroes. client-link address: Set to the clients link-local address for the link on which the client Expires May 1996 [Page 27]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 transmitted the packet. preferred lifetime: Set to the valid lifetime returned for an address by the server. valid lifetime: Set to the valid lifetime returned for an address by the server. The valid lifetime MUST be greater than or equal to the preferred lifetime. client address: Set to the address provided by the server. The client will return the number of addresses and associated lifetimes provided in the servers CONF-RESPONSE. options: No options are present. 7. Relay-Agent Processing The relay-agent MUST use UDP DHCPv6 Server Port 547 as the UDP port to accept client responses in an implementation. The relay-agent MUST join the DHCP Server/Relay-Agent multicast group well-known multicast address FF02:0:0:0:0:0:1:0. When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it MUST: If the gateway address is NOT zero then the relay-agent MUST: Put the relay-agents IP address in the gateway address field of the clients request packet. All relay-agents MUST: Put their relay-agent address as the source address for the IP header. Put the next relay-agent or known server address as the destination address in the IP header. Forward the packet to the to the next hop relay-agent or known server. When the remote server receives the client request from the relay-agent it will know its a remote client request (not on the servers link), because there is a gateway address in the request. So servers MUST verify the gateway address is not zero, to determine if the clients request is from a remote link. Expires May 1996 [Page 28]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 The server responds as specified in section 6.0, but uses the gateway address as the destination address in the IP header. When the relay-agent receives the remote servers response, it MUST forward the packet to the client, by using the client-link address as the source address for the IP Header. 8. Security Considerations Security for DHCPv6 can be used as specified in [IPv6-SA], [IPv6-AUTH], and [IPv6-ESP], which are implementation requirements for IPv6. Appendix A - Related Work in IPv6 The related work in IPv6 that would best serve an implementor to study is the IPv6 Specification [IPv6-SPEC], the IPv6 Addressing Architecture [IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], IPv6 Neighbor Discovery Processing [IPv6-ND], and Dynamic Updates to DNS [DYN-UPD]. These specifications afford DHCPv6 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 DHCPv6 implementors to understand is that IPv6 requires that every link in the internet have an MTU of 576 octets or greater (in IPv4 the requirement is 68 octets). This means that a UDP datagram of 536 octets will always pass through an internet (less 40 octets for the IPv6 header), as long as there are no IP options prior to the UDP datagram in the packet. But, IPv6 does not support fragmentation at routers and fragmentation must take place end-to-end between hosts. If a DHCPv6 implementation needs to send a packet greater than 536 octets it can either fragment the UDP datagram in UDP or use Path MTU Discovery [IPv6-SPEC] to determine the size of the packet that will traverse a network path. It is implementation defined how this is accomplished in DHCPv6. The IPv6 Addressing Architecture Specification provides 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 is that multicast addressing is well defined and nodes can create link-local addresses during initialization of the nodes environment. This means that a host immediately can configure an IPv6 address at initialization for an interface, before communicating in any manner on the link. The host can then use a well-known multicast address to begin communications to discover neighbors on the link, or as was discussed in the specification to locate a DHCPv6 server or relay-agent. The IPv6 Stateless Address Autoconfiguration Specification (addrconf) defines how a host can autoconfigure addresses based on neighbor discovery router advertisements, and the use of a validation lifetime to support renumbering of addresses on the Internet. In addition the addrconf specification defines the protocol interaction for a host to begin stateless or stateful autoconfiguration. DHCPv6 is one vehicle to perform stateful autoconfiguration. Compatibility with addrconf is a design goal of DHCPv6 Expires May 1996 [Page 29]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 where possible. IPv6 Neighbor Discovery (ND) is the node discovery protocol in IPv6 (replaces and enhances functions of IPv4 ARP Model). To truly understand IPv6 and addrconf it is strongly recommended that implementors understand IPv6 ND. Dynamic Updates to DNS is a specification that supports the dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use the dynamic updates to DNS to now integrate addresses and name space to not only support autoconfiguration, but also autoregistration in IPv6. Expires May 1996 [Page 30]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Change History Changes from July 95 to November 95 Drafts: Refined request/response codes and processing to support transaction processing model. Permit multiple addresses and lifetimes in a request and response. Moved Dynamic Updates to DNS as an Option to be defined in that specification. Settled on using UDP as it supports DHCP client server model as opposed to TCP which has overhead for this model. Reformatted specification to support analysis, packet formats, and processing in their own sections to make it easier for implementors to read. Removed address count as it is not necessary for synchronization. Added error-code, msg-flag, and total-addrs fields. Made transaction-ID 2 octets. Updated terminology to coordinate with IPv6 Stateless Address Autoconfiguration. Added more implementation notes. Moved IPv6 Related Work to an Appendix. Fixed various bugs in the spec from DHC WG input. Added Security reference pointers. Removed options format, which will be in the options spec. Added retransmission configuration variables, msg-types, and logic. Changes from March 95 to July 95 Drafts: Used integer values instead of bit values for type and code fields. Used message-type and message-code fields and rely on looking at the fields in the datagram instead of multiple over-lapping request/response codes. Added address-count field processing to be specified by the client as opposed to the server, and the processing for when client and server address-counts become disjoint. Added Requirements wording for MUST, SHOULD, MAY, etc. Added Design Goals section. Redefined transaction-ID and interface-token. Expires May 1996 [Page 31]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Added Client/Server Binding definition and processing section to handle those bindings. Added more terminology, definitions, and rationale. Added model to support Dynamic Updates to DNS for Host Names. Reduced the request/response model to 3 packets by not doing a server confirm to a clients confirm to a servers response. Added model to support like lifetime fields for lease management to coordinate with IPv6 Stateless Address Autoconfiguration. Added model and processing definitions for future DHCPv6 Options Specification. Added gateway-address and client-link-address for relay-agent processing. Removed excessive use of the acronym DHCPv6 for section titles and when referencing clients and servers. Added Draft ***Open Issues*** Section for review by the DHC Working Group. Added Change History. Expires May 1996 [Page 32]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Acknowledgements The DHC Working Group for their time and input into the specification. A special thanks for the consistent input, ideas, and review by (in alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack Mccann, Charlie Perkins, Yakov Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. The author would also like to thank Steve Deering and Bob Hinden, who have consistently taken the time to discuss the more complex parts of the IPv6 specifications. The author MUST also thank his employer for the opportunity and funding to work on DHCPv6 and IPv6 in general as an individual in the IETF. References [DHCPv6-OPT] C. Perkins, "Options for the Dynamic Host Configuration Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995 <draft TBD> [IPv6-SPEC] S. Deering and R. Hinden, "Internet Protocol Version 6 [IPv6] Specification" Internet Draft, June 1995 <draft-ietf-ipngwg-ipv6-spec-02.txt> [IPv6-ADDR] R. Hinden, S. Deering, Editors, "IP Version 6 Addressing Architecture" Internet Draft, June 1995 <draft-ietf-ipngwg-ipv6-addr-arch-03.txt> [IPv6-ADDRCONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration" Internet Draft, November 1995 <draft-ietf-addrconf-ipv6-auto-05.txt> [IPv6-ND] T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor Discovery" Internet Draft, September 1995 <draft-ietf-ipngwg-discovery-02.txt> [IPv6-DNS] S. Thompson and C. Huitema, "DNS Extensions to support IP version 6", Internet Draft, March 1995 <draft-ietf-ipngwg-dns-00.txt> [RFC-1034] P. Mockapetris, "Domain Names - implementation and specification" STD-13, 11/01/87 Expires May 1996 [Page 33]
INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 [RFC-1035] P. Mockapetris, "Domain Names - concepts and facilities" STD-13, 11/01/87 [DYN-UPD] S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain Name System (DNS)" Internet Draft, March 1995 <draft-ietf-dnsind-dynDNS-01.txt> [RFC-768] J. Postel, "User Datagram Protocol" STD-6, 08/28/80. [DHCP-v4] R. Droms, "Dynamic Host Configuration Protocol" RFC 1541 Proposed Standard, October 1993 [IPv6-Ether] M. Crawford, "A Method for the Transmission of IPv6 Packets over Ethernet Networks", Internet Draft, October 1995 <draft-ietf-ipngwg-ethernet-ntwrks-01.txt> [IPv6-SA] R. Atkinson, "Security Architecture for the Internet Protocol" RFC 1825, August 1995 [IPv6-AUTH] R. Atkinson, "IP Authentication Header" RFC 1826, August 1995 [IPv6-ESP] R. Atkinson, "IP Encapsulating Security Payload (ESP)" RFC 1827, August 1995 Authors' Address Jim Bound Digital Equipment Corporation 110 Spitbrook Road, ZKO3-3/U14 Nashua, NH 03062 Phone: (603) 881-0400 Email: bound@zk3.dec.com Expires May 1996 [Page 34]
