operating system, must be downloaded from the network. clients, diskless workstations, and small embedded systems.

Transcription

1 Boot Protocol Nowadays it s commonplace for computers to be added to a network, or moved from one network to another. Commonplace activities should be easy, and this is the motivation for protocols such as BOOTP (Boot Protocol) and DHCP (Dynamic Host Configuration Protocol). To understand the design of BOOTP and DHCP, we can start by asking this question: Given some information to communicate to another host, what does a host need to know in order to send the information using IP? In order to construct an IP packet, the host must know its own IP address, and the IP address of the destination. To reach a destination host on the same link, the source host must either know the destination s MAC address or be able to participate in an ARP exchange in order to learn the destination s MAC address. The source host must also know its own MAC address. The source and destination MAC addresses together allow the host to construct a frame to encapsulate the IP packet. The destination may not be on the same link as the source. The source host needs to know the network id and prefix length for the connected network in order to decide whether the destination is on the connected link. If the destination is not on the local link, the source host needs to know the identity of a gateway (router) that will forward the IP packet on to the destination. The host probably needs some way to learn the IP address of the destination. For this, it will most likely rely on a DNS server. Of all the items mentioned in this list, only the source MAC address is likely to be known to a host at power-up. BOOTP and DHCP provide a way for a host to learn the rest. We skipped right over a protocol called RARP (reverse ARP). RARP provides a very limited capability: it allows a host to determine its IP address given that it knows its MAC address. We skipped RARP on the grounds it is obsolete: It supplies only the IP address, and that s just not sufificient in today s networked computing environment. There s another dimension to the boot process that s also addressed by BOOTP and DHCP. It may be that the host has very little local non-volatile storage, so that the operating system, perhaps even the boot loader for the 1 June, 2014

2 operating system, must be downloaded from the network. clients, diskless workstations, and small embedded systems. Think of thin Let s step back for a moment and consider the larger picture. several aspects to consider. There are As mentioned above, a commonplace activity should be easy. In a general context, that implies that the activity should not require expert knowledge on the part of the user. In the computer world, that can be read as should be automated. The configuration of a computer system is comprised of a collection of hardware and software components. One of the key strategies for managing large networks is minimising the number of distinct configurations which must be maintained. In the network context, certain details must differ from one system to another the IP address, for example. A generic configuration must therefore be customised at installation by supplying the necessary custom data. The custom data required by individual devices on the network should be centralised for ease of management. It should not be necessary to scan all systems on the network in order to get an overall picture of an installation. To summarise: we want our set of generic system configurations (hardware and software) to be as small as possible. When a system is connected to a network, the proper generic configuration and all the information that makes the system unique should be automatically downloaded from servers somewhere on the network. All the above motivate the basic design of protocols like BOOTP and DHCP. Given some sort of key to identify a system, they are designed to supply the correct generic software configuration and the necessary custom information, and to allow the entire process to be automated. For each of BOOTP and DHCP, there is a database to hold the information required for each system. The key is the MAC (Ethernet) address of an interface on the system. BOOTP was designed for an environment where movement of devices was relatively infrequent and where the number of available IP addresses matched the number of devices. DHCP extends BOOTP to an environment where devices join and leave a network on an hourly or daily basis. The major enhancement is the 2 June, 2014

3 ability to reallocate IP addresses as devices join and leave. This makes it possible to share a small pool of IP addresses among a much larger number of devices in an environment where only a few of the devices are connected at any one time. DHCP is a direct descendent of BOOTP, and compatibility with BOOTP was an explicit design goal. As a result, they share a lot of functionality. We can start by talking about BOOTP, then discuss the additional capabilities added in DHCP. BOOTP provides a way to locate and download the necessary configuration information and software to boot a device. It can provide an IP address and much more the name of a file containing a full boot image, a subnet mask, a default gateway address, addresses of other types of servers, and more. The original BOOTP protocol is defined in RFC 951, with significant clarifications and extensions in RFC RFC 2132 is the most recent version of DHCP Options and BOOTP Vendor Extensions. BOOTP PDUs are carried as payload in UDP datagrams. There s a chicken and egg problem here how can we use IP to download data, if the device doesn t yet have an IP address? Let s quickly deal with the question of how a BOOTP client can exchange messages with a BOOTP server without knowing the server s IP address or its own IP address. The short answer is broadcast. It s clear that broadcast (or equivalent) will be needed in order for the client to find a server. The limited (linklocal) broadcast address is used to get the boot request to the server 1. When it comes time to return information from the server to the client, there are more possibilities. Limited broadcast can be used, but plain old unicast can be made to work with some creative interpretation of the IP standard. The server knows the client s hardware address at this point (it comes in the BOOTP request), and it also knows the IP address (which it is about to return to the client). If the o/s provides an interface which allows a program to make an entry in the ARP cache, the BOOTP server can do this and then send a unicast packet to the new IP address just like any other unicast IP packet. The client doesn t need to answer an ARP request because the server has forced the entry into its ARP cache. 1 If the server is not on the same link as the client, a relay agent acts for the server. The use of a relay agent is covered later in these notes. 3 June, 2014

4 Some care is needed at the client end. RFC 1122 (the current host requirements RFC) is quite clear that an IP implementation should silently discard a unicast packet if the destination address doesn t match one of the host s IP addresses. But it doesn t explicitly say what should happen if the host doesn t yet know its address. RFC 1542 (clarifications and extensions to BOOTP) is quite clear that an IP implementation should accept unicast packets under these conditions, and mentions that... old host implementations [of IP] SHOULD be modified so that they may receive unicast BOOTREPLY messages. RFC 2131 (DHCP) is even more explicit, noting... DHCP requires creative use of the client s TCP/IP software and liberal interpretation of RFC The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client s hardware address before the IP address is configured;... Sending a frame with the client s unicast hardware (MAC) address and the broadcast IP address is technically possible, but awkward because it requires a violation of the protocol layers the BOOTP server must force the IP and MAC layers to construct a packet with a broadcast IP address and a unicast hardware address. This approach is not recommended in the standards. If unicast cannot be used, the recommended solution is to send the reply as a broadcast using the limited broadcast address. It s good to avoid this if possible, on the grounds that it s just generally good to minimise broadcasts. On small networks, this may seem trivial. On large networks with hundreds or thousands of workstations, it s much more annoying. As a final detail, the server listens for requests at port 67, and the client listens for replies at port 68. Now that we know how we ll be able to exchange BOOTP messages, we can look at the higher level message exchange. Here s the protocol: The boot process is seen as a two stage operation. In the first stage, the client and server communicate using BOOTP, to provide the client with an IP address, subnet information, default gateway, etc.. If a second stage is necessary, the BOOTP server also provides the IP address of a boot server and the name of a boot file. (The boot server can be the BOOTP server itself, or it may be some other host.) In the second step, the client downloads the specified boot file from the boot server, using tftp or another file transfer protocol. To begin the first stage, the client broadcasts a bootrequest message to find a server which can tell it its IP address, etc., and (if necessary) 4 June, 2014

5 where to obtain a boot file (this might be anything from a bootstrap loader to a complete o/s image). At minimum, the bootrequest message will contain the client s MAC address. A BOOTP server, on receiving the request, fills in the necessary information and returns a bootreply. UDP is used to exchange the messages in first stage, so delivery is not guaranteed. It s the client s responsibility to keep a timer and retransmit the bootrequest as necessary. The recommended strategy is binary exponential backoff capped at 60 secs., with some randomisation strategy. BOOTP really is simple, and that s a design feature. To fit its intended use, a BOOTP client implementation should fit in ROM along with self-test and related firmware. Small is a relative term, and now-a-days it s common to have 10 s of MBs of ROM in a system. Firmware (BIOS, self-test, BOOTP, tftp, etc.) has expanded to fill the available space. Let s look at the messages in a little more detail. The format of a BOOTP packet is as follows: 5 June, 2014

6 op htype hlen hops xid (transaction id) secs flags ciaddr (client IP address) yiaddr (your IP address) siaddr (server IP address) giaddr (gateway IP address) chaddr (client hardware address) sname (server name) file (boot file name) vend (vendor specific information) The op field specifies either a bootrequest (1) or bootreply (2). The htype and hlen fields, together with the chaddr field, specify the client s hardware address. Htype specifies the hardware type (using the same type codes as ARP, from the Assigned Numbers RFC). Hlen specifies the number of octets in the address, and chaddr is the address itself. xid is a transaction id which the client can use to match a reply with the original request. secs is the time since the client sent its first bootrequest. The intent was that servers could use this as part of a policy to decide how much importance to attach to a bootrequest. (If the client has been trying for a while, give it more attention.) In practice, it hasn t been all that useful. Flags has only one defined flag, which should be set by the client if it wants the server to reply using broadcast rather than unicast. The preferred interpretation of the ciaddr (client IP address) and yiaddr ( your IP address) is as follows 2. 6 June, 2014

7 If the client is willing to accept any IP address supplied by the server, it should place in the ciaddr field. If the client wants to assert that it already has an IP address that it would really like to use, it should place it in the ciaddr field. The yiaddr field is filled in by the server with the IP address assigned to the client. This can differ from the address requested by the client in ciaddr. Why include this in the message format, instead of recovering the assigned IP address from the network layer? Aside from the usual argument that we want to avoid protocol layer violations, it s possible that the bootreply will be broadcast back to the client, in which case no IP address can be recovered. Siaddr is the IP address of the second stage boot file server. It is supplied by the server if not specified by the client and will be used by the client for the second part of the boot downloading the boot file using tftp or a similar file transfer protocol. (RFC 951 (BOOTP) can be read to allow this, but it s not clearly stated until RFC 2131 (DHCP).) Sname is the name of the server specified by siaddr. Hops and giaddr (gateway IP address) provide a way for a client to boot from a server on some other network, using the assistance of a BOOTP relay agent. We ll come back to this. File can be used by the client to request a particular type of boot file, either a specific file or a generic type of boot configuration. The server will fill this field with a valid path name for the boot file. The vendor specific area is used for a slew of options; now-a-days, most are generic, rather than vendor specific. We ll mention some of the more common ones in a bit. As mentioned at the start, when trying to understand why a BOOTP message contains the information that it does, it helps to keep in mind that the designers had two scenarios in mind. In the first, the client knows absolutely nothing, and the BOOTP server will supply a generic system configuration and all custom parameters required for that client. 2 The details are more complicated. The usage of ciaddr and yiaddr is specified in more detail for DHCP in RFC The client should use the ciaddr and yiaddr fields as described only when it s already been issued a lease on an IP address and can respond to an ARP for that IP address. Otherwise, it should communicate its preferred IP address in an option. 7 June, 2014

8 In the second, the client knows some subset of the information already, and is simply contacting the BOOTP server for the remainder. One version of this would be a diskless client in a relatively static network environment. The client already knows some or all of its network information from a configuration PROM, perhaps and is contacting the BOOTP server to determine the remaining network information and the proper boot loader or operating system to fetch in the second part of the boot process. In another version the client might come from the factory with the operating system preloaded, and needs only the networking information to complete the configuration. This is the most common case today. Calling the final options field in a BOOTP message vendor-specific information is a misnomer today. Most of the options now defined are generic, and some are pretty much essential. A selection of the more common types: The subnet mask (essential for sub- and supernetting in the CIDR world), static routing information, and other IP parameters (forwarding, routing, timeouts, etc.). The client s host name, and DNS and NIS domain names. The address of DNS and NIS servers, as well as other generic servers. Actual vendor-specific information. An escape option, which allows the BOOTP server to specify a file which contains the list of options (in case there s more than 64 bytes of options). All options are encoded using a (tag, length, data) triplet. What if a site has many physical networks? Local broadcast is not normally forwarded off of the network where it originates. On the other hand, a site may not want to maintain BOOTP servers on each network. To deal with this situation, the BOOTP protocol defines a BOOTP relay agent. A BOOTP relay agent runs in a network element which can act as a gateway (a multi-homed host, or a router) and listens for BOOTP bootrequest broadcasts. It increments the hop count and forwards the bootrequest to adjacent networks. The spread of the bootrequest can be limited by discarding the packet if the hop count exceeds a limit. When a client constructs a bootrequest, it places in the giaddr field. The first relay agent will replace this with its own IP address before forwarding the bootrequest to adjacent networks. 8 June, 2014

9 When the bootrequest finally reaches a server, the server will return the bootreply to the first relay agent using unicast to the address in giaddr. The relay agent takes care of getting the bootreply back to the client, either by unicast or local broadcast. A BOOTP server keeps a static database which associates a hardware address with the other configuration information host name, IP address, boot file, etc. In many environments this is no longer adequate. Computers have become mobile. A common scenario is an ISP or a bring your own laptop computer lab. Facility limitations (number of ports, basically) limit the number of computers that can be connected at any one time, and the ISP will have sufificient IP addresses to allow all ports to be in use. But, the population of computers which might connect over time is huge. There has to be some way to reassign IP addresses as computers connect and disconnect from the network. The Dynamic Host Configuration Protocol (DHCP) is designed to address this need, along with a large number of other goals. Some of the more important ones: The protocol supports hands-off configuration and boot. No manual intervention (to adjust the client s hardware/software configuration) is required to boot a computer once it s physically connected to the network. While allowing dynamic configuration, there was also a desire for stability. Whenever possible, a DHCP server should give a client the same configuration as was used for previous connections. DHCP had to be compatible with BOOTP, so that a BOOTP client could obtain BOOTP service from a DHCP server. DHCP supports static configuration, just as BOOTP. It maintains a database that associates a set of configuration parameters with a hardware address. Specifically, the unique id is a subnet identifier and hardware address, to eliminate any possibility of confusion where the link layer does not guarantee globally unique hardware addresses. DHCP also supports dynamic configuration. There s a similar database of configuration information, but IP addresses are not permanently bound to a client. 9 June, 2014

10 An IP address is drawn from a pool and leased to a client for a specified amount of time. (Which can be infinity, so that the client is automatically allocated a permanent address the first time it connects to the network.) For interoperability with BOOTP, the format of a DHCP message is nearly identical to a BOOTP message. A server or client can identify a DHCP message by looking for option type 53, which specifies the DHCP message type. New DHCP functions are handled using additional options. The vendorspecific field is renamed to options and its length is extended to 312 bytes (the maximum possible within the IP datagram limit of 576 bytes, the minimum datagram size that any IP implementation must be able to handle). The protocol becomes considerably more complex, but the responsibility of keeping track of state and dealing with failures still lies almost entirely with the client. 10 June, 2014

11 Init issue dhcp_discover issue dhcp_release Bound Select collect offer y dhcp_offer? choose? select offer; issue dhcp_request n n shut down? 50% lease? issue dhcp_request Renew y Request y dhcp_ack? discard y dhcp_offer? dhcp_nak? y issue dhcp_decline y n dhcp_nak? dhcp_ack? accept? n y 87.5% lease? issue dhcp_request Rebind n dhcp_nak or lease expire? y n dhcp_ack? A client which needs an IP address starts in state Init, and broadcasts a dhcp_discover message to locate a DHCP server. This message is treated just as a BOOTP boot_request, including relaying if necessary. If a client already knows its IP address, it can skip the discovery phase. It starts in a separate state (called Init-Reboot), sends a dhcp_request, and moves to a Rebooting state to wait for the reply. If it receives a dhcp_ack, it moves directly to the Bound state. If it receives a dhcp_nak, it moves to Init and starts from scratch. Servers hearing the dhcp_discover construct a dhcp_offer. The dhcp_offer 11 June, 2014

12 will include an IP address in the yiaddr field. Any other configuration parameters are passed as options. This message is the equivalent of a boot_reply, and is returned to the client in the same manner, including relaying if necessary. RFC 2131 strongly recommends that the server probe the offered address before sending a dhcp_offer. The suggested probe is an ICMP echo, which will be able to reach all networks served by the server. (As opposed to an ARP request, which is limited to the server s link.) In BOOTP, the boot_reply was the end the client had no choices to make, and the binding was permanent. In DHCP, we re just getting started. The client can potentially receive several offers. How long it waits, collecting offers, and how it chooses between them is implementation dependent. In the simplest case, the first dhcp_offer to arrive is the one chosen, with no further waiting. Having selected an offer, the client needs to make its choice known to the servers which have made offers. It broadcasts a dhcp_request message which includes a server identifier option that specifies the server whose offer has been accepted. Again, this message is relayed if necessary. If none of the offers are acceptable, the client can start again with dhcp_discover messages. For a better chance of success, the client should specify desired parameter values (a longer lease time, for example) in the options portion of the message. When the servers receive the dhcp_request, the chosen server marks the IP address as committed, places the binding (address and configuration information) into its database of active bindings, and replies with a dhcp_ack message. Other servers, on receipt of the dhcp_request, note that their offer has been declined and update their internal state appropriately (e.g., marking the address as in-use.) On receipt of dhcp_ack from the server, the client should perform one last check before committing to the address. RFC 2131 strongly recommends that the client use an ARP request to confirm the offered address is not in use on the local subnet. To avoid polluting existing ARP cache entries if the address is already in use, the ARP request should use as the sender protocol address. There are various exceptional situations that can occur: 12 June, 2014

13 It s possible that the server whose offer has been accepted wants to renege on the offer. In this case, it will reply with dhcp_nak and the client will return to the Init state and start over. It s also possible that the client will decide it doesn t want to accept the offer. In this case, it can reply to the dhcp_ack with a dhcp_decline. This might come about because the final ARP check showed that the address was in use, or because some parameter (lease length, for example) in the dhcp_ack was unacceptable. (The second case would be very rare, as the server should not change parameter values between the dhcp_offer and dhcp_ack.) Assuming that the server replies with dhcp_ack and the client decides to accept, it simply moves to the Bound state (no explicit reply to the server is required). The client stays in the Bound state, happily networking, until one of two events occurs: the client finishes, and decides to disconnect and shut down, or 50% of the lease time passes. If the client has decided to shut down, it will notify the server by sending a unicast dhcp_release. If the lease has reached the 50% mark, the client will enter a set of states where it attempts to extend the lease. The Renew state is the first attempt at renewal. A unicast dhcp_request is sent to the DHCP server that granted the original lease, asking for an extension. The server will make a decision on renewal and return a dhcp_ack or dhcp_nak as appropriate. If the answer is dhcp_ack, the client notes the lease extension and returns to the Bound state to continue working. If the answer is dhcp_nak, the client is required to disconnect from the network. This is the earliest point at which a server can rescind a lease. In the Rebind state, the client makes a second attempt at renewal if there s been no response in the Renew state. This is a broadcast dhcp_request, asking any server to renew the current IP address and configuration. As with the Renew state, if dhcp_ack is received, the client can return to working. A dhcp_nak, or lease expiry, means that the client must disconnect from the network and return to the Init state to request a new binding. If the client does manage to reacquire the previous binding, it can simply return to the Bound state and continue working. But if it s given 13 June, 2014

14 a new IP address, it cannot make any further use of the old IP address, which means all previous network connections must be terminated. This will likely require notification of the user, who can try and repair the damage. There s a lot of fussy attention to particular values of fields in order to make sure servers, which are essentially stateless, can be sure of the meaning of the message they re receiving. For example, the server decides whether a dhcp_request is an acknowledgement of a dhcp_offer or a request for renewal of a lease by looking for the presence or absence, respectively, of the server identifier option. To make this a little bit easier, there are some new options specifically for DHCP. The DHCP message type is conveyed as an option. The DHCP server id is passed as an option, leaving the siaddr field unambiguously clear to specify the server for the boot file. There are options to allow the client to request a particular IP address, and to allow the client to request a lease duration and the server to specify the offered lease duration. Another DHCP option allows the server to specify that the server name and boot file fields in the message body have been used for parameters. DHCP defines two more options to handle the server name and boot file name. (The theory being that the space gained in the message body (192 bytes) will outweigh the space taken by the extra options.) Looking ahead, automated assignment of IP addresses requires interaction with the Domain Name Service (DNS). In today s network environment, this is more than just a question of human convenience. A common check for authenticity of a host involves a pair of DNS accesses, one using the name of the host and one using the IP address. The results of the two must agree to pass the test. An extension to DNS, Dynamic DNS (DDNS), provides the ability to update the database of a DNS server by defining an update message which provides for atomic updates. There is, however, no standard protocol for the interactions between a BOOTP or DHCP server and a DNS server; the details will differ from one BOOTP or DHCP server implementation to the next. We ll postpone further discussion until we ve talked about DNS. 14 June, 2014

15 DHCPv6 In an Ubuntu system, an interface is configured to use DHCP by specifying the dhcp method for the interface in the interface configuration file /etc/network/interfaces. When the ifup command sees the dhcp method, it will start a DHCP client program to find and negotiate with a DHCP server. A DHCP lease must be renewed at regular intervals, so the client will continue to run (as a dæmon) as long as the interface is up. DHCPv6 The DHCPv6 protocol, defined in RFC 3315, is the IPv6 analogue of the DHCP protocol for IPv4 3 covered in the previous section. As with DHCPv4, DHCPv6 provides stateful address assignment, in the sense that it maintains a record of clients and the address(es) assigned to them. IPv6 hosts can make use of router advertisements and stateless address autoconfiguration to obtain gateway information and to construct globally valid addresses. For this reason, it s useful for a DHCPv6 server to provide a stateless service mode, supplying configuration information (e.g., the addresses of local servers or other local resources) without assigning addresses. RFC 3736 specifies the subset of DHCPv6 operations that must be implemented in a stateless DHCPv6 server. For IPv4, a host initiates communication with a BOOTP or DHCPv4 server by broadcasting a message. In order for the host to receive a unicast reply, it was necessary to exploit a loophole in the IPv4 specification. Hosts are required to accept, and deliver to the network layer, any unicast IP packets that arrive before an IP address has been assigned to the host. For IPv6, this is not a problem. A host initiates communication with a DHCPv6 server using the All_DHCP_Relay_Agents_and_Servers multicast address 4 (ff02::1:2, link scope). Because every IPv6 host automatically generates a link-local address, the DHCPv6 server can use this address to reply to the client. As with DHCPv4, the client is responsible for maintaining timers and retransmitting messages if it does not receive a reply from a server within a reasonable amount of time. 3 For clarity, the remainder of these notes will use DHCPv4 and DHCPv6 to distinguish the two protocols. 4 Abbreviated to All_DHCPv6 in the notes that follow. 15 June, 2014

16 DHCPv6 The most common exchange of messages between a DHCPv6 server and a client resembles the most common DHCPv4 exchange. A client solicits offers of addresses from DHCPv6 servers using a Solicit message sent to the All_DHCPv6 multicast address. DHCPv6 servers reply with Advertise messages, offering addresses to the client. The client chooses an offer by sending a Request message to the All_DHCPv6 multicast address. The Request specifies the server whose offer has been accepted. Other servers will also see the Request and can update their state information appropriately. The chosen server responds with a Reply message to confirm the lease of the addresses to the client. The client begins to use the IPv6 addresses. At the appropriate point in the lease interval for an address, the client will send a Renew message to the server asking for an extension of the lease. The server will respond with a Reply message that extends or cancels the lease. If the client cannot elicit a Reply from the original server in response to its Renew message, it can send a Rebind message asking any server to extend the lease on an address. If some server offers to extend the lease with a Reply message, the client can continue to use the address. Otherwise, it must stop using the address. The client uses a Release message to indicate to the server that it will no longer be using an address. In DHCPv4 it is common to use the Ethernet address of the client as a unique identifer. The client identifier in DHCPv6 is called a DHCP Unique Identifier (DUID). DHCPv6 defines three types of DUID, two based on the Ethernet address of the client and a third based on an enterprise ID assigned by the IANA. RFC 3315 is clear that a DUID should not change. Even for DUIDs based on the Ethernet address, once generated it should be stored and should not change even if the interface hardware is changed. DHCPv6 messages are carried as data in UDP datagrams. The server listens for requests at port 547 and the client listens for replies at port 546. The format of a DHCPv6 message is quite simple, consisting of a message type code, a transaction id, and a list of options. 16 June, 2014

17 DHCPv6 msg-type transaction-id options (variable) DHCPv6 groups a set of addresses assigned to a client into a unit called an Identity Association (IA). Each IA specifies one or more IPv6 addresses, each with its own preferred and valid lifetimes. Here s the format of an Identity Association option for non-temporary 5 addresses (IA_NA). OPTION_IA_NA option-len IAID T1 (renew time) T2 (rebind time) IA_NA-options The assigned addresses are given by Identity Association Address options in the IA_NA-options list. OPTION_IAADR option-len IPv6 address preferred-lifetime valid-lifetime IAaddr-options 5 As mentioned in the notes for IPv6 addresses, there is concern that using a globally unique identifier like an Ethernet address in the interface ID portion of an address makes it easy to track an individual device. Temporary addresses (RFC 4941) address this issue. We will not discuss them further. 17 June, 2014

18 DHCPv6 A client may be assigned one or more IAs. There must be at least one distinct IA per interface on the client. An IA is identified by a client-generated id (the IAID) which must be unique over all IAIDs used by the client. It is the client s responsibility to ensure that IAIDs do not change, even when the client is rebooted, hence they must be statically configured or generated by a stable algorithm 6. DHCPv6 provides substantial functionality beyond basic address assignment. The IANA registry for DHCP option codes contains over 80 defined options, including options related to DNS servers, mobile IP support, the location of boot files (for hosts that need to load an operating system), geographic information, and much more. A Solicit message from a client contains an Option Request Option with a list of option codes specifying the information that the client wants to receive from the server. As with DHCPv4, communication between a booting client and a DHCPv6 server is restricted to common link connecting the client and the server. DHCPv6 defines a relay agent capability for cases where it s inconvenient to have a server on every link. The relay agent passes the client s messages to the server and returns the server s replies to the client. This basic explanation does not do full justice to the capabilities and complexity of DHCPv6. Consult RFC 3315 for the full details of the basic protocol. A list of options and their associated RFCs can be found in the IANA registry at scroll down the page to the entry titled Dynamic Host Configuration Protocol for IPv6 (DHCPv6). 6 RFC is clear that generation of an IAID may be dependent on the client hardware configuration and may change if the hardware changes. 18 June, 2014