SIPP Working Group S. Thomson (Bellcore) INTERNET-DRAFT March 1994 Simple Internet Protocol Plus (SIPP): Automatic Host Address Assignment Status of this Memo 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document specifies the changes that need to be made to the Dynamic Host Configuration Protocol (DHCP) to support SIPP hosts, and describes how a host makes use of this protocol and ICMP (Internet Control Message Protocol) Router Discovery messages to form locally and globally routable address sequences automatically. The changes to DHCP are intended to be minimal and compatible with existing BOOTP and DHCP clients. Modifications include a new message format and updated operation definitions. Communication between a SIPP client and server is made significantly simpler since relay agent functionality is not required. SIPP WG, Expires September 17, 1994 [Page 1] INTERNET-DRAFT Automatic Host Address Assignment March 1994 1. INTRODUCTION Two mechanisms are provided to enable a SIPP host to form and main- tain its own address sequences dynamically: SIPP ICMP Router Discovery[SIPP-DISC] and SIPP DHCP. SIPP DHCP is an extension of the Dynamic Host Configuration Protocol (DHCP)[RFC1531] to support SIPP hosts. SIPP hosts on a subnet discover their global and local-use subnet prefixes by listening for periodic router advertisements. A host forms a locally routable address (also called a local-use address) by concatenating a local-use subnet prefix with a unique interface iden- tifier. A host forms a globally routable address sequence by either (1) querying the SIPP DHCP service for an address sequence with an advertised global subnet prefix, or (2) by concatenating the subnet cluster prefix with a unique interface identifier. The specification assumes that a host can identify each of its interfaces uniquely, at least within the scope of a subnet. A local-use address is sufficient for hosts that do not need to com- municate with destinations outside of their subscriber domain (site), or belong to a site that is disconnected from the global internet. A host may also use a local-use address to form a globally routable address sequence. A host usually acquires a globally routable address sequence from the SIPP DHCP service. The method that allows a host to form its own glo- bal address sequence can only be used in certain circumstances. First, a host must be able to form a globally unique identifying address. Second, a host must be operating in a SIPP domain, since the resulting address sequences do not typically conform to the transi- tion specification[SIPP-IPAE]. Also, the address sequences typically consist of more than one 64-bit address, which may not be desirable for efficiency reasons. This document specifies SIPP DHCP, and defines how a host makes use of SIPP Router Discovery and SIPP DHCP to maintain an up-to-date list of valid address sequences per interface. The document also describes how a SIPP host that is also IPv4-capable can use DHCP instead of SIPP DHCP (if this is not yet implemented) to acquire address sequences that conform to the transition specification. SIPP WG, Expires September 17, 1994 [Page 2] INTERNET-DRAFT Automatic Host Address Assignment March 1994 1.1. Requirements of SIPP Automatic Address Assignment The aim of an automatic address assignment mechanism is to eliminate manual configuration of addresses in hosts. Hosts must be able to boot without pre-configuration ("plug-and-play" operation), and must be able to form new address sequences without being rebooted when necessary, e.g. when a host changes provider or when subnets within a site are renumbered. The requirements of SIPP DHCP are as follows: 1. No manual host administration must be required, when an address needs to be (re)allocated. 2. Addresses must only be in use by one host at a time. 3. Addresses with multiple subnet cluster prefixes should be sup- ported per host interface. 4. SIPP DHCP should retain host address bindings over client and server reboots as far as possible. 5. A SIPP DHCP server need not be on each link or subnet. 6. SIPP DHCP must allow for multiple address servers to enable increased availability. 7. SIPP DHCP should be compatible with BOOTP/DHCP. 1.2. Related Work The Dynamic Host Configuration Protocol (DHCP), an extension of the Bootstrap Protocol (BOOTP), has recently been defined to enable IPv4 hosts to acquire an IPv4 address automatically. The SIPP DHCP service defined in this document provides a similar address assignment ser- vice to DHCP, that is, a server assigns a host a globally routable address for some fixed period of time on request. However, there are several differences. First, SIPP DHCP is an address assignment mechanism only; it does not provide a mechanism for retrieving other configuration parameters. Second, SIPP hosts are expected to use SIPP WG, Expires September 17, 1994 [Page 3] INTERNET-DRAFT Automatic Host Address Assignment March 1994 Router Discovery in conjunction with SIPP DHCP. This means that hosts are explicitly told when the address of their subnet has changed, and hence know when to reallocate their addresses to ensure they are always up-to-date. Moreover, a SIPP host can use information learned in Router Discovery to discover its subnet and form an address rout- able within a subscriber domain. As a result, SIPP DHCP is made sig- nificantly simpler than DHCP to implement and deploy since it does not have to provide a mechanism to enable a SIPP host to communicate with a DHCP server on a different subnet. Two forms of address assignment service are defined for SIPP. Both are backwards-compatible extensions to BOOTP/DHCP. The first exten- sion specifies that BOOTP or DHCP return a new option containing a (statically configured) SIPP address prefix, which can be prepended to the returned IP address to form a SIPP address sequence[SIPP- DHCP]. This solution is suitable in the short- to medium-term when SIPP implementations are minimal and do not provide advanced SIPP features, such as Router Discovery. Only SIPP hosts that are also IPv4-capable can make use of this extension. The SIPP DHCP service defined in this document is suitable for use in the medium-term, when SIPP Router Discovery has been implemented. The SIPP DHCP service is more general than the extension described above because SIPP hosts that are not IPv4-capable are supported and SIPP address sequences are not constrained to include an IPv4 address, Also, the benefits of using Router Discovery accrue. Note that it is possible for a SIPP host that is also IPv4-capable to use SIPP Router Discovery and IPv4 DHCP, to form an address that con- forms to the transition specification. This method provides "plug- and-play" operation and dynamic reassignment of addresses, but, in general, it only supports singly-homed sites, that is sites that are connected to a single provider. 1.3. Terminology The terminology defined in the SIPP specification[SIPP-SPEC], the SIPP Routing and Addressing Specification[SIPP-ROAD] and the DHCP specification[RFC1531] applies here. SIPP WG, Expires September 17, 1994 [Page 4] INTERNET-DRAFT Automatic Host Address Assignment March 1994 2. DISCOVERY OF SUBNET PREFIXES The address assignment mechanism relies on hosts and neighboring routers implementing ICMP Router Advertisements and ICMP Router Soli- citations. Routers advertise address information by multicasting Router Advertisement messages periodically. Each message includes a list of global and local-use subnet prefixes and associated mask lengths supported by the router, and the length of time the informa- tion is considered to be valid. A host may solicit such an advertise- ment by sending a Router Solicitation message to the router. The Router Advertisement and Solicitation Protocol is specified in [SIPP-DISC]. SIPP WG, Expires September 17, 1994 [Page 5] INTERNET-DRAFT Automatic Host Address Assignment March 1994 3. GENERAL HOST PROCEDURE FOR MAINTAINING ADDRESS SEQUENCES A host maintains three lists per interface: 1. a list of subnet prefixes and associated mask lengths, 2. a list of locally routable address sequences, and 3. a list of globally routable address sequences. The lists are updated when a Router Advertisement is received over the interface, and when the lifetime of a subnet prefix expires. The lists are initially empty when a host boots with the following excep- tions. A host may add a local-use address with an unassigned local- use subnet prefix (such an entity has not been defined in [SIPP- ROAD], however) to the list of local-use addresses, and bind this address to the interface. This address can be used for intra-subnet communications when other addresses cannot be formed or renewed because Router Advertisements are not being heard, due to the neigh- boring router being down, for example. A host may remember previ- ously autoconfigured address sequences across reboots. Prerecorded address information may be used after rebooting until its lifetime expires, but every attempt should be made to acquire the latest information as soon as possible after a reboot. Entries may be added manually. 3.1. Allocating and Renewing Address Sequences When a host boots or at any time when a host has no address sequence for an autoconfigurable interface, e.g. when an interface is enabled after being disabled, a host should send a Router Solicitation over the interface so that the interface's address sequences can be formed (or verified) as soon as possible. When a solicited or unsolicited Router Advertisement is received over an interface, the host updates the subnet prefix list, the list of local-use addresses and the list of global address sequences associ- ated with the interface using the procedure outlined in the rest of this section. Note that a Router Advertisement may contain several global and local-use subnet prefixes. For example, if a host is SIPP WG, Expires September 17, 1994 [Page 6] INTERNET-DRAFT Automatic Host Address Assignment March 1994 connected to different providers, several subnet cluster prefixes, one per provider, will be advertised. The choice of which subnet prefixes to use in forming an address sequence should be locally con- figurable. In the following procedure, it is assumed that all pre- fixes are used. For each local-use subnet prefix advertised, the host updates the list of local-use addresses as follows: 1. If the local-use subnet prefix is not in the subnet prefix list, a new local-use address is formed by concatenating the prefix with a unique interface identifier (see Section 4), and an entry is added to the list of local-use addresses. For each subnet cluster prefix advertised, the host updates the list of globally routable address sequences as follows: 1. If the subnet cluster prefix is not in the subnet prefix list, a new address sequence is formed, and an entry is added to the list of globally routable address sequences. A globally routable address sequence can be formed by concatenating the advertised prefix with a local-use address or a host identifier (Section 5), or by querying the SIPP DHCP service for an address in the advertised subnet using the local-use address to identify the client (Sections 7-9). If SIPP DHCP is not supported, IPv4- capable hosts may use IPv4 DHCP to acquire an IPv4 address and concatenate the "C-bit", the upper 31 bits of the subnet cluster prefix and the IPv4 address to form a SIPP address (Section 6). Note that there may be more than one local-use address for the interface, e.g. because a new local-use prefix has just been advertised, and a previously advertised local-use prefix has not yet timed out. In this case, the host should choose one local- use address to form or acquire an address sequence, when appropriate, e.g. the one that has the longest lifetime. The choice should be deterministic. 2. If the subnet cluster prefix has an entry in the subnet prefix list and a new local-use address has been created as a result of this advertisement, a new address sequence is formed using the new local-use address, when appropriate, and an entry is added to the list of globally routable address sequences. For each subnet prefix advertised (whether it is a global or local- SIPP WG, Expires September 17, 1994 [Page 7] INTERNET-DRAFT Automatic Host Address Assignment March 1994 use subnet prefix), a host updates the list of subnet prefixes as follows: 1. If the subnet cluster prefix is not in the subnet prefix list, the subnet prefix and its mask length is added to the subnet prefix list. A timer for the entry is initialised to the life- time of the advertisement. 2. If the subnet prefix has an entry in the subnet prefix list, because it has been advertised previously (rather than having been manually configured by a system administrator), the timer of the entry is reset to the lifetime of the advertisement. 3.2. Deleting Address Sequences A timer is used to time out an entry in the subnet prefix list. The following actions are performed on expiry of a timer: 1. All autoconfigured local-use addresses or globally routable address sequences containing the subnet prefix are unbound from the corresponding interface and deleted from the corresponding address list. All network processing using these addresses must be stopped immediately. Any address sequences acquired from the (SIPP) DHCP Service containing the subnet prefix may also be explicitly released (Section 9). 2. The subnet prefix is deleted from the subnet prefix list. SIPP WG, Expires September 17, 1994 [Page 8] INTERNET-DRAFT Automatic Host Address Assignment March 1994 4. FORMING A LOCAL-USE ADDRESS Local-use addresses may be used by hosts in sites that are not con- nected to the global Internet. They may also be used by hosts to form a globally routable address sequence. At the time of writing, only one type of local-use address has been defined, the IEEE 802 local-use address. This section explains how to form such an address. A host forms a local-use address for an interface by concatenating a local-use subnet prefix advertised by a neighboring router with an interface identifier that is unique at least within the scope of the subnet, as follows: | 16 bits | 48 bits | +----------------+------+-+-+----------------------------------------+ | subnet prefix | interface identifier | +----------------+------+-+-+----------------------------------------+ |6 bits|S|X| 1. The subnet field is set to a local-use subnet prefix advertised by the router over the interface to which this address is to be bound. 2. The identifier used to denote an interface uniquely is either a universally administered IEEE 802 address or a hardware address. The identifier is stored in the 48-bit 'interface identifier' field, right-justified and padded with zeroes, if necessary. The 'S' bit (bit 6) has the value zero if and only if the iden- tifier is a universally administered IEEE 802 address; other- wise, the 'S' bit has the value one. The 'X' bit (bit 7) of the interface identifier must be zero. The local-use address may be locally or globally unique depend- ing on the interface identifier used. The local-use address is globally unique if and only if the interface identifier is a universally administered IEEE 802 address. Otherwise, a local- use address is unique only within a subscriber domain. SIPP WG, Expires September 17, 1994 [Page 9] INTERNET-DRAFT Automatic Host Address Assignment March 1994 5. FORMING A GLOBAL ADDRESS SEQUENCE A host can form a global address sequence on its own only if it can form a globally unique identifying address. This can be done in two ways. First, a host can form an address sequence of at least length two by concatenating a subnet cluster prefix received in a Router Advertisement with a globally unique local-use address. Such address sequences are only useful to hosts that wish to communicate with other SIPP hosts in SIPP domains, since they do not conform to the transition specification[SIPP-IPAE]. A host that needs to communicate with an IPv4 host must use the (SIPP) DHCP Service (Sections 7-10) to acquire an address. Second, a host that has a small enough hardware address can form a 64-bit global hierarchical unicast address by concatenating a subnet cluster prefix with the hardware address. These addresses do conform to the transition specification. 5.1. Forming an Address Sequence using a Local-Use Address A host uses the subnet cluster prefix advertised over the interface as the high-order part of the address sequence, and the interface's globally unique local-use address as the identifying address, to form an address sequence of at least length two as follows (the low-order address is encoded first): SIPP WG, Expires September 17, 1994 [Page 10] INTERNET-DRAFT Automatic Host Address Assignment March 1994 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | local-use address | | | +---------------------------------------------------------------+ | subnet prefix address 0 | | | +---------------------------------------------------------------+ | subnet prefix address 1 | | | +---------------------------------------------------------------+ / ... / / / +---------------------------------------------------------------+ | subnet prefix address n | | | +---------------------------------------------------------------+ 5.2. Forming a 64-bit hierarchical unicast address A host that has a small enough hardware address can form a 64-bit global hierarchical unicast address as follows: | n bits | 64 - n bits | +--------------------------------------------+----------------------+ | subnet cluster prefix | interface identifier | +--------------------------------------------+----------------------+ 1. The 'subnet cluster prefix' field is set to a subnet cluster prefix advertised by the router over the interface to which this address is to be bound. 2. The hardware address of the interface is stored in the 'inter- face identifier' field, right-justified and padded with zeroes, if necessary. SIPP WG, Expires September 17, 1994 [Page 11] INTERNET-DRAFT Automatic Host Address Assignment March 1994 6. USING DHCP TO FORM A GLOBAL ADDRESS If SIPP DHCP is not supported at a site, a SIPP host that is IPv4- capable may use DHCP to acquire an IPv4 address whenever a new subnet cluster prefix is advertised. Together with the C-bit, the upper 31 bits of an advertised subnet cluster prefix can be concatenated with the returned IPv4 address to form a 64-bit hierarchical unicast address that conforms to the transition specification. Note that this method does not support hosts in sites that are attached to multiple providers, one of the reasons being that DHCP is intended to support the allocation of one address per interface. SIPP WG, Expires September 17, 1994 [Page 12] INTERNET-DRAFT Automatic Host Address Assignment March 1994 7. OVERVIEW OF THE SIPP DHCP SERVICE The SIPP DHCP Service assigns a SIPP address sequence to a host within a subscriber network, given the host's subnet, and stores the resulting binding for future retrieval or deletion. Addresses are assigned for fixed periods of time to a host, after which the service may reclaim the address for subsequent use by another host. The duration of an address assignment, known as the lease time, can be extended by the host. Each server maps the tuple (subnet cluster prefix, client identifier) to the tuple (address sequence, lease time). The mapping is one-to- one. The client identifier is defined to be a host's local-use address. The service provides operations to (i) assign a new address, given the client's subnet, (ii) look up an existing address in a particular subnet, (iii) renew the lease time of a particular address sequence and (iv) release or decline an address sequence. As mentioned in Section 1.2, this service is similar to the address assignment function provided by DHCP servers. In DHCP, however, a client is uniquely identified by its subnet and its hardware address (although it is possible to use a client identifier of a different type) and IPv4 addresses are bound to clients. Also, unlike SIPP, a DHCP client need not know its subnet number or have an address to query a server on a different subnet. DHCP enables clients and servers on different subnets to communicate by having a preconfigured BOOTP relay agent on each client subnet, which acts as a proxy for the client in communications with a server. SIPP WG, Expires September 17, 1994 [Page 13] INTERNET-DRAFT Automatic Host Address Assignment March 1994 8. SIPP CLIENT-SERVER PROTOCOL 8.1. Properties Like IPv4 DHCP, SIPP DHCP does allow for multiple servers, which may be responsible for assigning addresses in the same subnet. However, no mechanism is currently provided to maintain consistency between servers. Thus, servers cannot currently administer the same range of addresses within the subnet, and servers cannot ensure that a single binding exists per host per subnet within the service as a whole. Clients must therefore be prepared to cope with different servers offering the use of different address sequences on allocation of an address. Likewise, reallocation of an address may cause two or more subnet address bindings to be allocated within the DHCP service. DHCP allows the identifier of a server to be specified by a client in certain operations, so that a client can identify a single binding within the service, when necessary. In SIPP DHCP, the server must be identified when allocating a new address and when renewing the lease time of a particular binding. IPv4 DHCP mandates that the server be identified when allocating a new address only. 8.2. Transport Protocol The address assignment protocol uses UDP as its transport protocol. A SIPP DHCP server listens to messages on the BOOTP/DHCP server port (67). Note that, unlike BOOTP and DHCP, there is no need for a mes- sage to be returned to a client on a specific port. In all communications between a SIPP client and server, relay agents must be bypassed. A client can use any valid address sequence as a source address in all communications with the SIPP DHCP Service. If no valid global address sequence is known, a client must form a local-use address and use this. A client may use the unicast address sequence of a server as the destination address in a server request, if known. Otherwise, the SIPP DHCP Service multicast address must be used. A server returns a message to a client using the client's source address as the destination. SIPP WG, Expires September 17, 1994 [Page 14] INTERNET-DRAFT Automatic Host Address Assignment March 1994 In DHCP, relay agents can only be bypassed once a client has been assigned an address and is sure it is still valid, e.g. on renewal operations. Otherwise, a client broadcasts DHCP requests on the local subnet using the unassigned address as a source address. The server (or relay agent, if the server is not on the same subnet) unicasts or broadcasts a response to the client depending on whether a client can accept a message with a destination address it does not yet recognise as its own. 8.3. Message Format Extending the BOOTP or DHCP packet format to support the assignment of SIPP address sequences is not straightforward since the message header format is IPv4-specific. The following information needs to be communicated between a SIPP client and the SIPP DHCP Service: FIELD OCTETS DESCRIPTION ----- ------ ----------- client identifier 8 Host identifier, unique within subnet In SIPP, local-use address server identifier 8 Identifier of queried server In SIPP, identifying address of server lease time 4 Length of time (in secs) address is valid subnet mask length 2 Length (in bits) of subnet cluster prefix subnet cluster prefix variable Host's subnet cluster prefix heard from neighboring router Word length is ceil(mask length/64) address sequence variable Host's address sequence Word length is ceil(mask length/64) There are two possible message formats that can be used to support SIPP. If the current BOOTP/DHCP format is to be maintained, SIPP information can be passed as options in the extensible 'options' field of a message. This format renders most of the existing packet header obsolete. Alternatively, a new packet format can be designed to support SIPP clients. This can be done without introducing incom- patibility with existing software since relay agents are not used in SIPP client-server communications and hence do not need to be SIPP WG, Expires September 17, 1994 [Page 15] INTERNET-DRAFT Automatic Host Address Assignment March 1994 modified. The new message format is described below. 8.3.1. New Message format The new message format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | opcode (1) | unused (3) | ----------------------------------------------------------------- | xid (4) | ----------------------------------------------------------------- | subnet mask length (2) | flags (2) | ----------------------------------------------------------------- | lease time (4) | ----------------------------------------------------------------- | client identifier (8) | | | ----------------------------------------------------------------- | server identifier (8) | | | ----------------------------------------------------------------- / client address sequence / / / ----------------------------------------------------------------- The fields in the message have the following sizes (in octets) and meanings: SIPP WG, Expires September 17, 1994 [Page 16] INTERNET-DRAFT Automatic Host Address Assignment March 1994 FIELD OCTETS DESCRIPTION ----- ------ ----------- opcode (op) 1 Message operation code (BOOTREQUEST, BOOTREPLY, DHCPDISCOVER, DHCPASSIGN, DHCPQUERY, DHCPRENEW, DHCPRELEASE, DHCPDECLINE, DHCPACK, DHCPNAK) flags 2 Flags (unspecified, must be zero) xid 4 Transaction identifier lease time 4 Duration (in secs) of host's address binding in server's database (same as DHCP lease time) subnet mask length (mask) 1 Length (in bits) of subnet cluster prefix client identifier 8 Client's unique host identifier (clientid) (A SIPP local-use address) server identifier 8 Server's unique host identifier (serverid) (Server's identifying address) client address sequence Client's address sequence (address) Word length is ceil(mask length/64) Also used to specify client's subnet cluster prefix The 'opcode' field indicates the type of message. The SIPP DHCP Ser- vice uses the opcode to determine what operation is being requested and hence whether the client is a BOOTP/DHCP client (BOOTREQUEST(1) or BOOTREPLY(2)) or a SIPP client (DHCPDISCOVER, DHCPASSIGN, DHCPQUERY, DHCPRENEW, DHCPRELEASE, DHCPDECLINE, DHCPACK, DHCPNAK). The 'xid' field is used by the client to match an outgoing (possibly retransmitted) request with an incoming reply. The 'xid' is a random number specified by the client when transmitting a message and is copied by the server into a response message. The 'lease time' is the duration of a client's lease. It is the length of time (in seconds) that the address sequence may be used by the client. It is expressed in relative, rather than absolute, terms. The 'mask' field indicates the mask length (in bits) of the subnet cluster prefix. It is also used to deduce the length of the subnet prefix and address sequence in the message. SIPP WG, Expires September 17, 1994 [Page 17] INTERNET-DRAFT Automatic Host Address Assignment March 1994 The 'address' field is used by a client to specify either the subnet cluster prefix or a requested address sequence. A server used this field to return the bound address sequence to a client. A client identifies itself uniquely by its local-use address in the 'clientid' field. A server identifies itself uniquely by storing its identifying address in the 'serverid' field. The above fields replace the BOOTP/DHCP IPv4 address fields 'ciaddr', 'yiaddr', and 'giaddr', and the DHCP options, 'requested IP address' and 'IP address lease time'. Other BOOTP/DHCP fields related to relay agents such as 'hops' and 'secs' are not needed. The use of a client identifier to identify a client coupled with the fact that relay agents are bypassed means that specifying a client's hardware address is no longer necessary ('htype', 'hlen' and 'chaddr' fields). We have omitted the 'siaddr', 'sname', 'file' and 'options' fields present in BOOTP/DHCP. For now, it is assumed that other mechanisms will be provided by SIPP to provide further bootstrapping assistance. SIPP WG, Expires September 17, 1994 [Page 18] INTERNET-DRAFT Automatic Host Address Assignment March 1994 9. EXTENDING DHCP TO SUPPORT SIPP 9.1. Server Behavior In IPv4 DHCP, a server supports the following operations: DHCPDIS- COVER, DHCPREQUEST, DHCPDECLINE and DHCPRELEASE. In SIPP DHCP, we have split the functions of DHCPREQUEST into three operations: DHCPASSIGN, DHCPQUERY and DHCPRENEW, for several reasons. First, the parameters used to distinguish these operations in IPv4 DHCP do not all have obvious analogies in SIPP DHCP. Second, one of the functions performed by DHCPREQUEST is not needed and is replaced in SIPP DHCP. Third, the three functions are more clearly understood and specified as different operations. Otherwise, except where mentioned, the semantics of the operations are analogous to that provided by DHCP. The SIPP DHCP service must support IPv4 clients as well as SIPP clients. If the original message format is being used, the server can distinguish between an IPv4 and SIPP client by the specification of the 'address' and 'mask' options. Otherwise, the specification of operation codes other than BOOTREQUEST and BOOTREPLY in the 'op' field of the message header indicates that the server should perform SIPP processing. The SIPP semantics of these operations are discussed in turn in this section. Familiarity with the DHCP specification is assumed. 9.1.1. DHCPDISCOVER message On receiving a DHCPDISCOVER message, a server executes the following procedure: 1. If (a binding exists for the identified host in the subnet specified), a) If the client has specified a desired lease time, choose a lease time according to local policy. SIPP WG, Expires September 17, 1994 [Page 19] INTERNET-DRAFT Automatic Host Address Assignment March 1994 b) Return the bound address sequence, the lease time and the identifying address of this server in a DHCPOFFER message. 2. ELSE if (an address sequence is available in the specified sub- net cluster), a) Choose an available address sequence within the subnet cluster according to local policy. If the client has specified a desired address sequence, the server may take this into account when choosing an address. b) Choose the lease time according to local policy. If the client has specified a desired lease time, the server may take this into account when choosing the lease time value. c) Set the server identifier associated with the binding to be the identifying address of this server. c) Return the uncommitted address sequence, the lease time and the identifying address of this server in a DHCPOFFER mes- sage. The server ignores a DHCPDISCOVER message if the requested address is for a subnet that the server does not administer, or if the server has no available address in the subnet. The choice of address sequence and lease time when allocating a new binding should be made according to the rules laid down in DHCP. 9.1.2. DHCPASSIGN message On receiving a DHCPASSIGN message, a server performs the following procedure: 1. If (this server is identified by 'server identifier') a) If (a binding exists for the identified host in the subnet and the address sequence bound is the address specified by the client and the lease time specified is acceptable according to local policy) i) Set the lease time in the binding that maps (subnet, SIPP WG, Expires September 17, 1994 [Page 20] INTERNET-DRAFT Automatic Host Address Assignment March 1994 client identifier) to (address sequence, lease time), ii) Return a DHCPACK message b) ELSE if (the address sequence and the lease time are acceptable according to local policy) i) Record the binding that maps (subnet, client identif- ier) to (address sequence, lease time), ii) Return a DHCPACK message c) ELSE return a DHCPNAK message. 2. ELSE delete any cached information associated with the identi- fied client. Only the server identified in 'server identifier' responds to this message. Any other servers receiving this message may take this mes- sage as a hint that a host has accepted another server's offer of an address, and delete any information that it may have recorded about this client on receiving a DHCPDISCOVER operation. 9.1.3. DHCPRENEW message On receiving a DHCPRENEW operation, the server extends the lease time of the specified address as follows: If (this server is that specified by 'server identifier'), a) If (a binding exists for the identified host in the specified subnet and the address sequence bound is the address specified by the client and the lease time, if specified, is acceptable according to local policy), i) Reset the lease time of the binding according to local pol- icy ii) Return lease time in a DHCPACK message b). ELSE send a DHCPNAK message. SIPP WG, Expires September 17, 1994 [Page 21] INTERNET-DRAFT Automatic Host Address Assignment March 1994 9.1.3.1. Differences with DHCP Unlike DHCP, a client must specify the identifier of the server that originally allocated the address sequence. This avoids the situation in which a client may receive DHCPNAKs in addition to a DHCPACK in response to a message. This can happen when a client has allocated more than one address in a particular subnet on several servers, e.g. because the client does not choose offers deterministically on each reboot or because a server is down during a reboot. 9.1.4. DHCPQUERY message On receiving a DHCPQUERY message, a server looks for an existing binding as follows: If (a binding exists for the identified host in the specified subnet) a) Return the address sequence and lease time in a DHCPACK message. 9.1.4.1. Differences with DHCP There is no corresponding operation in DHCP. One of the functions of DHCPREQUEST is to verify that a client is on the correct subnet, given its address. This operation is not needed by SIPP clients since the subnet cluster prefix and mask is advertised by neighboring routers. Note that this operation could be omitted if we redefined DHCPDIS- COVER to return a DHCPACK message when a binding already exists, and a DHCPOFFER message when a new address sequence is allocated. 9.2. DHCPRELEASE On receiving a DHCPRELEASE message, a server removes an existing SIPP WG, Expires September 17, 1994 [Page 22] INTERNET-DRAFT Automatic Host Address Assignment March 1994 binding as follows: If (a binding exists for the identified host and the address sequence bound is the address sequence specified by the client) a) Delete the binding and mark the address sequence available for reuse by another client. The server does not send a reply in response to this message. 9.3. DHCPDECLINE On receiving a DHCPRELEASE message, a server removes an existing binding as follows: If (a binding exists for the identified host and the address sequence bound is the address sequence specified by the client) a) Delete the binding and mark the address sequence unavailable for use by any client. b) The server should inform the system administrator of the receipt of such a message. The server does not send a reply in response to this message. SIPP WG, Expires September 17, 1994 [Page 23] INTERNET-DRAFT Automatic Host Address Assignment March 1994 The following table indicates the message field settings by a server for each message type. Field DHCPOFFER DHCPACK DHCPNAK ----- --------- ------- ------- op DHCPOFFER DHCPACK DHCPNAK xid 'xid' from client 'xid' from client 'xid' from client DHCPDISCOVER request request message message message flags 0 0 0 mask 'mask' from client 'mask' from client 'mask' from client DHCPDISCOVER request request message message message lease time MUST MUST 0 clientid 'clientid' from 'clientid' from 'clientid' from DHCPDISCOVER request request message message message serverid MUST MUST MUST address offered address bound address unassigned address 9.4. Client Behavior A client requests the DHCP service for a new address sequence using the DHCPDISCOVER/DHCPASSIGN operations on receiving a Router Adver- tisement advertising a new subnet prefix. On expiry of a subnet pre- fix, a client may release an address sequence containing the prefix using DHCPRELEASE. A client maintains a timer with each address sequence acquired from the DHCP service which indicates when the lease time should be renewed. On expiry of such a timer, a client sends a DHCPRENEW message to the SIPP DHCP service. 9.4.1. Acquiring an Address After receipt of a new subnet prefix in a Router Advertisement, the client should delay transmission of the first DHCPDISCOVER request for a random amount of time between MIN_REQUEST_DELAY and MAX_REQUEST_DELAY. This alleviates overloading of the network and SIPP WG, Expires September 17, 1994 [Page 24] INTERNET-DRAFT Automatic Host Address Assignment March 1994 configuration service after power up, or whenever a new subnet prefix is advertised. The host sends a DHCPDISCOVER request to a DHCP server to acquire a globally routable address sequence. The message may be unicast or multicast to the DHCP service. The host must specify its subnet cluster prefix, mask length, and client identifier. The host may specify a desired SIPP address sequence and a lease time. The client waits an implementation-dependent period of time to receive DHCPOFFER messages from the service. Several address sequences may may be offered in response to a single DHCPDISCOVER request. The host chooses one. The choice is implementation- dependent, but should be deterministic. The DHCPASSIGN message is completed in the same way as the DHCPDIS- COVER message described above, except that three additional fields must be specified. The server identifier must be set to the values returned by the server in the DHCPOFFER message. The client's chosen address sequence and lease time should be set to the values returned by the server in the DHCPOFFER message. Before sending the DHCPASSIGN message, the client records its own local time for later use in computing the expiration time of the address. The DHCPASSIGN may be unicast or multicast. The request should be multicast if more than one DHCPOFFER is received. The client waits an implementation-dependent period of time to receive DHCPACK messages from the service. Once a DHCPACK is received, the host records the address sequence returned by the server and the server's identifier. The client may also record the server's address sequence so that it can be used as the destination address in subsequent DHCPRENEW messages. The host also records the expiration time of the address sequence as the sum of the time at which the DHCPASSIGN request was sent and the lease time as returned in the DHCPACK message, and sets a timer to expire when the lease time of the address should be reset (see Section 9.4.3). The host may also check that the chosen address appears valid and that it is not in use on the subnet, using the SIPP mechanism for address resolu- tion. (If IPv4 ARP is in use, then the SIPP host validates an address as specified in DHCP.) If the host determines that the address is invalid, the client may unicast a DHCPDECLINE message to the server (using its local-use address as the source address) and restart the assignment process. SIPP WG, Expires September 17, 1994 [Page 25] INTERNET-DRAFT Automatic Host Address Assignment March 1994 If the client receives no responses after sending a DHCPDISCOVER or DHCPASSIGN message, it may retry these requests up to some MAX_RETRANSMISSION_INTERVAL. The retransmission interval uses an exponential backoff algorithm which doubles RESPONSE_DELAY each time. If, after MAX_RETRANSMISSION_INTERVAL, no answer is received, and the original request was unicasted, the host may repeat the above pro- cedure by multicasting the request. 9.4.2. Querying for an Existing Address Before attempting to allocate an address using the two-step operation above, a client may first determine whether the SIPP DHCP service already has a binding for the client. This operation is particularly useful to a client on receiving a Router Advertisement immediately after rebooting. Use of this operation has two potential advantages. First, the cost of querying for an already existing address is one operation. Second, it helps avoid allocating several addresses in the case where several servers offer a client an address on receiving a DHCPDISCOVER, and the client does not have a way of determining the choice made last time. The DHCPQUERY message, if sent immediately after receiving a Router Advertisement should delay a random amount of time as specified in the DHCPDISCOVER operation. The DHCPQUERY message may be unicast or multicast to the DHCP service. The host must specify its subnet cluster prefix, subnet mask length, and its client identifier. Before sending the DHCPQUERY message, the client records its own local time for later use in computing expiration of the address. The client waits an implementation-dependent period of time to receive DHCPACK messages from the service. Several messages may be received in response to a single DHCPQUERY request. If a client is verifying recorded information, the client checks that one of the address sequences returned corresponds to that recorded for the iden- tified server. Otherwise, the host chooses one, recording the returned address sequence and the server identifier. The choice is implementation-dependent, but should be deterministic. Whether a client is querying for an unknown address or verifying a known one, the lease time must be recalculated and the timer reset to expire when the address should be renewed. A client may choose to release those address sequences not in use by sending a DHCPRELEASE message SIPP WG, Expires September 17, 1994 [Page 26] INTERNET-DRAFT Automatic Host Address Assignment March 1994 to the corresponding servers(Section 9.4.4). Retransmission of DHCPQUERY messages follows the same algorithm as described above when sending DHCPDISCOVER or DHCPASSIGN messages. 9.4.3. Extending the Lease time of an Address The client maintains a timer with an autoconfigured address, which indicates when to reset the lease time of the address in the confi- guration service using the DHCPRENEW message. The interval between DHCPRENEW operations should be randomised over an interval to reduce the probability that all hosts reset their addresses together. Each time an address is reset, or immediately after the address has been assigned and queried, the timer is reset to a time (called T1 in DHCP) which defaults to some fraction of the lease time (0 [SIPP-SPEC] S.Deering, "Simple Internet Protocol Plus (SIPP) Specification", Internet Draft, February 1994, [SIPP-ROAD] S.Deering, P. Francis and R. Govindan, "Simple Internet Protocol Plus (SIPP): Routing and Addressing", Internet Draft, February 1994, [SIPP-ICMP] R. Govindan and S. Deering, "ICMP and IGMP for SIPP", Internet Draft, March 1994, [SIPP-DISC] W. A. Simpson, "SIPP Neighbor Discovery", Internet Draft, December 1993, [SIPP-DHCP] S. Thomson, "SIPP Extensions to BOOTP/DHCP", Internet Draft, February 1993, SIPP WG, Expires September 17, 1994 [Page 31] INTERNET-DRAFT Automatic Host Address Assignment March 1994 13. APPENDIX 13.1. Configurable Parameters Two per-interface flags are defined which may be toggled to indicate whether local-use addresses or global address sequences or both are to be formed and bound to the interface: PerformAutoGlobal A flag indicating whether advertised global subnet prefixes are to be used to form globally routable address sequences for this interface. Default: TRUE PerformAutoLocal A flag indicating whether advertised local-use subnet prefixes are to be used to form local-use addresses for this interface. Default: TRUE 13.2. Constant Parameters Parameter Default Value --------- ------------- MIN_REQUEST_DELAY 1 sec MAX_REQUEST_DELAY 10 secs MAX_RETRANSMISSION_INTERVAL 64 secs RESPONSE_DELAY 4 secs MIN_RENEW_FRACTION 0.5 MAX_RENEW_FRACTION 0.875 SIPP WG, Expires September 17, 1994 [Page 32]