IPv6 Essentials

9.2. DHCP

DHCP is widely used to configure hosts with their IPv4 addresses and additional information. If you have an IPv6 network, you do not need DHCP to configure your hosts with address information. The Stateless autoconfiguration mechanism will configure your hosts for their IPv6 addresses without the need to set up a DHCP server. All you need to do is configure your IPv6-enabled routers with the prefix information for the links to which they are attached. But you might still choose to have DHCP servers in some cases. Host configuration that includes the assignment of IPv6 addresses using DHCP is called Stateful autoconfiguration or Stateful DHCPv6. Maybe you have a specific IPv6 addressing scheme; or you need dynamic assignment of DNS servers; or you choose not to have the MAC address as a part of the IPv6 address; or you wish to implement dynamic updates to DNS (RFC 2136). In these cases, you can use DHCP for address configuration. You can also combine Stateless and Stateful autoconfiguration by using Stateless autoconfiguration for the IPv6 address configuration and DHCP servers to provide additional configuration information including but not limited to DNS server IP addresses or DNS domains.

RFC 3736 offers an additional configuration option. It defines a Stateless DHCP service for IPv6. A Stateless DHCP server can configure hosts that already have an IP address with additional information such as DNS or SIP servers. It cannot do address assignment, though. Stateless DHCP is explained later in this chapter, after the section on stateful DHCPv6.

DHCPv6 and DHCPv4 are independent. If you want to configure hosts with DHCP in a dual-stack network, currently you will need two separate DHCP services running, one for each protocol. In this case, you will also have to watch out for configuration conflicts. In the DHCPv4 world, the client is configured to know whether to use DHCP. In the DHCPv6 world, the Router Advertisement has options to inform the client whether to use DHCP. There may be differing configuration information arriving at the client from different sources, or a node may have multiple interfaces, e.g., one being IPv4-only and one being dual-stacked. DHCPv6 uses a unique identifier (DUID), which does not exist for DHCPv4. In the realm of DHCPv4, MAC address and client ID resemble the DUID in DHCPv6 but are not synonymous. There is work going on to make the DUID available for DHCPv4 also.

The DHCP working group is further assessing requirements and evaluating solutions, which will allow dual-stack hosts to be configured for both protocols by one or more DHCP server. Draft-ietf-dhc-dual-stack-04.txt goes into more detail and describes issues identified with dual IP version DHCP interactions. The most important aspect is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers.

DHCPv6 is specified in RFC 3315. All references in this chapter relate to DHCPv6.

For the development of DHCPv6, the following guidelines were originally defined:

• It must be possible to combine DHCP and Stateless autoconfiguration.

• The configuration of DHCP and the interaction with other mechanisms (e.g., Stateless autoconfiguration) are the responsibility of the administrator.

• The clients do not need to be configured manually.

• DHCP must be able to configure multiple addresses per interface.

• A DHCP server is not needed in every subnet. Relay agents must be able to forward DHCP packets.

• A client must be able to deal with multiple DHCP replies coming back from different DHCP servers.

• It must be possible to have subnets where only some of the clients are configured by DHCP.

• DHCP does not depend on the presence of a router. Routers are needed only if Stateless autoconfiguration is used.

• DHCP must be able to do dynamic DNS updates to register allocated addresses in DNS. The administrator can decide to update DNS manually.

• DHCP must support and simplify the renumbering of a network.

9.2.1. DHCP Terms

Let us define some common terms used for DHCPv6:

DHCP Client

A DHCP client sends requests to a DHCP server to get configuration information.

DHCP Server

A DHCP server is preconfigured to reply to client requests. It knows the configuration for each client. When it receives a client request, it sends the information back to the client. A DHCP server may or may not be on the same link as the client.

DHCP Relay Agent

If there is no DHCP server on the client link, a relay agent must be configured on the client link. The relay agent receives the client request and forwards it to one or more DHCP server(s) on another subnet. When the relay agent receives the answer from the DHCP server, it forwards it to the client. A relay agent is called an IP helper in the Cisco world. I use the term relay agent in this chapter.

DHCP Unique Identifier (DUID)

Each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified.

Identity Association (IA)

A collection of addresses assigned to a client. Each IA has an associated Identity Association Identifier (IAID), which is assigned by the client. A client can have multiple IAsfor example, one for each interface.

Identity Association Identifier (IAID)

An identifier for an IA chosen by the client. Each IA has an IAID, which is chosen to be unique among all IAIDs for IAs belonging to that client.

Transaction ID

A value used to match requests and replies.

DHCP uses the following multicast addresses:

All_DHCP_Relay_Agents_and_Servers (FF02::1:2)

All DHCP agents (servers and relays) are members of this multicast group. DHCP clients use this link-scoped multicast address to reach DHCP agents on their link. So clients do not need to know the agent's link-local address.

All_DHCP_Servers address (FF05::1:3)

All DHCP servers within a site are members of this multicast group. This site-scoped address is used by DHCP relays to reach all DHCP servers within a site. They either do not know the server's unicast address, or they want to reach all DHCP servers within the site.

The following UDP ports are used with DHCPv6:

UDP port 546Client port

Clients listen on port 546 for DHCP messages. DHCP servers and relays use it as the destination port to reach DHCP clients.

UDP port 547Server/Agent port

DHCP servers and relays listen on port 547 for DHCP messages. DHCP clients use this port as the destination port to reach DHCP servers and relay agents. DHCP relays use this port as the destination port to reach DHCP servers.

The messages types shown in Table 9-1 have been specified in RFC 3315.

The DHCP server-initiated configuration exchange is a great new feature. It can be used, for example, when links in the DHCP domain have to be renumbered or when new services or applications have been added and need to be configured on the clients. When services or applications need to be configured on the client, the DHCP server sends out a Reconfigure message (type 10). A client receiving this message must initiate a Renew or Information Request message exchange to get the updated information. Haven't we been waiting for this?

This could also be done with DHCPv4, but it has rarely been implemented. The IPv4 way of doing this is defined in RFC 3203. A DHCPv4 server sends a DHCPforcerenew message, which triggers the client to the Renew state in which it tries to renew its lease.

9.2.2. DHCPv6 Header Format

The general DHCPv6 header format is much simpler than the one used with DHCPv4. I describe it next.

9.2.2.1. Client-Server messages

All DHCP messages exchanged between server and client have a fixed header with a variable part for options.

Figure 9-2 shows the header format.

The Message Type field defines the type of message. You saw the list of message types in Table 9-1. For each request, the client generates a new transaction ID and writes it into the Transaction ID field. It is used in all messages relating to this specific request. When troubleshooting DHCP, it is important to check the transaction ID and make sure to associate the corresponding requests and replies.

Options are used to provide configuration information and parameters. The options fields have an identical base format, which is shown in Figure 9-3.

The Option Code field defines the type of the option. Find an overview of the available option types in Table 9-2. The Option Length field indicates the length of the option in bytes. The Option Data field finally contains the information configured for the option. Its format and length varies depending on the option type.

The options defined in RFC 3315 are a base set of options. In the future, additional options will be defined and specified in separate RFCs. Table 9-2 shows an overview.

Some specifications with additional options have already been published:

RFC 3319, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"

The Session Initiation Protocol (SIP) is defined in RFC 3261. It is a control protocol for the establishment, modification, and termination of multimedia sessions or calls. The components are a SIP server and a SIP client. RFC 3319 defines two DHCPv6 options for the configuration of a SIP client for a local SIP server. The client will use this server for all outgoing SIP requests. The first option (option code 21) contains a list of domain names, and the second option (option code 22) is a list of 128-bit IP addresses. The servers have to be listed in the order of their preference. The client has to choose the first server in the list; if it does not answer, the client chooses the second server in the list. The client can request both options. It then has to use the domain list first and use the IP address list only if that is unsuccessful.

RFC 3633, "IPv6 Prefix Options"

This RFC defines options that can be used to send prefix information from a delegating router or a DHCPv6 server to a requesting router that has DHCPv6 client functionality. It is useful in environments where the delegating router has no information about the topology of a network connected to the requesting router. A delegating router or a DHCPv6 server in an ISP network uses this option to configure a router in a customer network for its prefix. The delegating router can, for example, assign a /48 prefix to the border router in the customer network. The border router can subdivide the /48 prefix to /64 subnets and advertise these prefixes with Router Advertisements. DHCP prefix delegation (DHCP-PD) is independent from DHCP address assignment, but the two can be combined.

RFC 3646, "DNS Configuration Options"

RFC 3646 defines two DHCPv6 options for the client configuration of DNS name servers (option code 23) and domain search lists (option code 24).

RFC 3898, "Network Information Service (NIS) Configuration Options"

This RFC defines four options for Network Information Service (NIS) related configuration information: NIS Servers (option type 27), NIS+ Servers (option type 28), NIS Client Domain Name (option type 29), and NIS+ Client Domain name (option type 30). They can be used only for the configuration of NIS services that can be reached over IPv6. The two options for NIS and NIS+ servers provide a list of IPv6 addresses for the respective servers. The lists are ordered according to their preference.

RFC 4014, "DHCPv6 Relay agent RADIUS Attributes Option"

This option enables the network access system (NAS), which also serves as a DHCPv6 relay agent, to pass along attributes for the user of a device (received during RADIUS authentication) to a DHCP server. The NAS, using RADIUS as an authentication authority, will receive attributes from a RADIUS server that may be used by the DHCP server in the selection of configuration parameters to be delivered to the device requesting access.

RFC 4075, "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6"

The Simple Network Time Protocol servers option provides a list of one or more IPv6 addresses of SNTP servers available to the client for synchronization. The clients use these SNTP servers to synchronize their system time to that of the standard time servers.

This is the status at the time of writing, but active development is underway. If you want to get up to speed with the latest status at the time of your reading, refer to the DHCP working group at http://www.ietf.org/html.charters/dhc-charter.html. There you will also find all the drafts that are underway.

9.2.3. Relay AgentServer Message Format

Relay Agents forward client and server messages if the two are not on the same link. A DHCP message can be forwarded by more than one Relay Agent to one or more server(s). The reply by the server has to follow the same path back through which the original request came in, and it has to be forwarded by the same Relay Agents. Figure 9-4 shows the header fields in the Relay Agent and server messages.

Relay Forward and Relay Reply messages have the same format and are identified by the value in the Message Type field. Type 12 is a Relay Forward message, type 13 a Relay Reply message.

The Hop Count field in a Relay Forward message shows how many Relays have already forwarded this message. Each forwarding Relay increases the value by one. The Relay can be preconfigured with a Hop Count Limit to limit the number of Relays that forward the message. When a Relay receives a message in which the Hop Count has reached the value configured in the Hop Count Limit, it discards the message. The default value for the Hop Count Limit is 32. In a Relay Reply message, the Hop Count field value is taken from the Hop Count field in the corresponding Relay Forward message.

The Link Address field contains a global IPv6 address. Based on this field in a Relay Forward message, the server can identify the link where the requesting client sits. The RFC also mentions the site-local address as a possible value for this field because the DHCPv6 RFC was published before the site-local address was deprecated. In a Relay Reply message, the value in this field is taken from the corresponding Relay Forward message.

The Peer Address field contains the address of the client or the Relay from which the message was received. This field is copied from the Relay Forward message into the corresponding field in the Relay Reply message.

The variable size Options field contains a Relay Message Option (option type 9). In a Relay Forward message, it contains the client request; in a Relay Reply message, it contains the server reply. This field can contain additional information that can be preconfigured on Relay Agents and that they insert when forwarding the message.

9.2.4. DHCP Unique Identifier

Each DHCP client and server has a DHCP Unique Identifier (DUID) that is used to identify each other. A server uses the client DUID to choose the corresponding client configuration to be sent. The DUID has to be unique across all servers and clients and should not be changed after initial assignment. RFC 3315 specifies three different types of DUIDs. Additional types may be specified in the future. A DUID contains a 2-byte type code followed by a variable number of bytes containing the identifier. The three types specified currently are as follows:

• Link-layer address plus time (DUID-LLT)

• Vendor-specific unique ID based on enterprise number (DUID-EN)

• Link-layer address (DUID-LL)

9.2.5. Identity Association

An Identity Association (IA) is an object used by the server and the client to identify and manage a group of addresses. Each IA is identified by a corresponding IAID and contains individual configuration information. A client has at least one IA per interface, which is to be configured by a DHCP server. The client uses the IA to get the right configuration for the interface from the server. Each IA has to be associated to only one interface. It is the client that chooses the IAID, and it must be unique. The configuration information of an IA contains one or more IPv6 addresses plus the T1/T2 timers (Renewal and Rebinding timers, explained in "Renew/Rebind," later in this chapter).

A DHCP server chooses the configuration information for the IA according to the address allocation policies defined by the administrator. It chooses the configuration based on the following criteria:

• The link to which the client is connected

• The DUID of the client

• Other information provided by the options from the client

• Other information taken from the options, which have been added by Relay Agents

9.2.6. DHCP Communication

There are different processes in the DHCP communication. There is the client-server interaction and the forwarding of messages over Relay Agents. The following sections describe these processes in more detail. Many processes are similar to DHCPv4, differing only in IPv6-related adaptation. Other processes are newfor instance, the way messages are forwarded over Relay Agents.

9.2.6.1. Client and server communication

A client uses multicast Solicit messages to find a DHCP server. If a client wishes to contact a specific DHCP server, it uses the server DUID in a Server Identifier Option (option type 2). All DHCP servers will receive this message, but only the server specified by the DUID will reply. In some cases, a client can use a unicast address to reach a specific server. This is possible only if the server is configured to send a Server Unicast Option (option type 12) indicating that unicast communication is possible and stating the IP address to be used. In this case, it has to be considered that these unicast messages will not be forwarded over Relay Agents, so any configuration done on the Relay Agent will not be inserted into the unicast DHCP messages.

The client receives one or more Advertise messages in answer to its Solicit message. If it receives more than one, it applies the following criteria to choose a DHCP server:

• The message with the highest Server Preference value is preferred.

• If there are several messages with an equal Server Preference value, it chooses the one with the preferred configuration.

• The client may also choose a message with a lower Server Preference value if it contains more appropriate configuration parameters.

The list of servers and their corresponding Preference values are stored at the client. Should it not receive replies from its preferred DHCP server, it will choose the next one in the list. If a client does not receive an answer from a DHCP server within a certain amount of time, it either initiates a new Discovery process by sending out another Solicit message or ends the configuration and creates an error message.

In reply to the Advertise message, the client sends a Request message to one of the DHCP servers including its IA Option, its client DUID, and an Option Request option, which contains the desired DHCP options. The server replies with a Reply message containing the requested options. If the server received the Request forwarded by a Relay Agent in a Relay Forward message, it will reply with a Relay Reply message forwarded over the same Relay Agents like the incoming Request message. The server flags the addresses given out in the Reply message as allocated. If the client receives multiple Replies, it chooses the most appropriate one and uses these addresses. The addresses allocated by other servers through their Advertise messages remain allocated but are not used. They will be reused by the DHCP server when their lifetimes have expired.

The client has to perform Duplicate Address Detection (DAD) for each address allocated by the DHCP server. For an explanation of DAD, refer to "Neighbor Discovery (ND)" in Chapter 4. A typical DHCP communication performed by a client that does Stateful address autoconfiguration looks as follows:

1. Client sends Solicit message.

2. Server(s) reply with Advertise message.

3. Client sends Request message to one server.

4. Server replies with Reply message.

This communication can be shortened to only two messages with the Rapid Commit option. In this case, the client sends a Solicit message with the Rapid Commit option included. The server replies with a Reply message that also contains the Rapid Commit option. If the client sent out a Solicit message with a Rapid Commit option, it will ignore any Replies that do not contain a Rapid Commit option. If the client does not receive any Reply including a Rapid Commit option, it may accept an incoming Advertise message and continue the regular configuration process. If a server receives a Solicit message with a Rapid commit option and is not configured to use it, it replies with a regular Advertise message. While it is true that Rapid Commit offers a more efficient approach to address assignment by using only two messages, it has to be chosen carefully. Depending on the configuration and the number of DHCP servers, it could result in wasted address space or a situation where multiple DHCPv6 servers believe that they each assigned addresses to requesting clients. Once a DHCP server has allocated an address in a Reply message with a Rapid Commit option, it has to commit the IP address to the client.

A client uses Request, Renew, Rebind, Release, and Decline messages as necessary for the lifetime of its server-assigned addresses. If the client switches link or subnet (for instance, in a wireless network or after waking up from sleep mode), it has to initiate a Confirm/Reply exchange. It does this by sending its IAs and the corresponding addresses and options. If the client does not receive an answer to its Confirm message, it should continue to use the previously allocated addresses.

To release one or more of its addresses, a client sends a Release message, which contains the IA and the corresponding addresses and options. The server answers with a Reply. If the client does not receive a Reply, it sends another Release message. This is not possible in all casesfor instance, if the client is shutting down. If a DHCP server did not receive a Release message, it will reuse the addresses when their lifetimes have expired.

If a client notices that an allocated address is already in use (for instance, through DAD), it sends a Decline message to the server. This message contains a Transaction ID, the client identifier, the server identifier, and the address(es).

If a DHCP server receives a unicast message from a client to which it has not sent the Unicast option, it replies with a Reply message containing the Status Code "use multicast" (option 13, code 5).

9.2.6.2. Renew/Rebind

If a client wants to refresh the lifetime of its valid and preferred addresses, it sends a Renew (type 5) message containing the IA Address option and the addresses corresponding to this IA. The server identifies the corresponding lifetimes and sends a Reply message to the client. Doing this it may also add new addresses or remove old addresses by setting their lifetime to 0.

If a server receives a Renew message for an IA for which it has no entry, it replies with a Reply message setting the Status code to "no binding" (option 13, code 3). If the client wants to renew an address that is not valid for its link, the server sends a Reply message setting the lifetimes for the addresses to 0.

The server controls the intervals in which a client has to renew its addresses through the Timers T1 and T2 preconfigured and associated to each IA. When the client reaches the time indicated by T1, it has to start the Renew process. When a client reaches the time indicated by T2, this indicates that its Renew messages have not been answered. In this case, it sends a Rebind message to all DHCP servers. The Rebind message contains an IA option with the currently allocated addresses and an Option Request option with all desired DHCP options.

When a server receives a Rebind message and finds the corresponding IA, it answers with a Reply message. If the addresses are not valid for the link anymore, it sets the lifetimes to 0. If the client does not receive an answer to a Rebind message, it cannot make further use of the address(es). In this case, it has two options:

• Restart the address configuration by sending out a Solicit message to find a DHCP server.

• If the client has other valid IAs, it can ignore the expired IA and use other addresses.

9.2.6.3. Information Request

If the client already has IP addresses but wants to get other DHCP information, it sends an Information Request message. This message contains an Option Request option to indicate the desired DHCP options. If, for instance, the client is configured by Stateless address autoconfiguration and the router is configured to set the O-flag (other Stateful configuration) in the Router Advertisement, this causes the client to send an Information Request message to get additional information such as DNS, NTP, or SIP server configuration. The Information Request message is also sent by the client in answer to a Reconfigure message from the server.

9.2.6.4. Reconfigure process

The server sends a Reconfigure message to trigger the client to send a Renew or an Information Request message. This is useful when the server has been updated with new or modified information, to make sure the new information is propagated as quickly as possible. In the Reconfigure message, the Transaction ID is set to 0 and contains a Server Identifier option including the server DUID and a Client Identifier option containing the client DUID. Additionally, an Option Request option can be sent along to indicate to the client which options have changed or been added. The Option Request option contains an IA Address option (type 5) if the client needs to reconfigure its IP address. With the Reconfigure message option (type 19), the server indicates whether the client has to send a Renew or an Information Request message.

Because of the danger of DoS attacks, the use of security mechanisms is mandatory in Reconfigure messages, which means that the server has to use DHCP authentication. The server sends a Reconfigure message to a unicast IPv6 address of each client. If it doesn't know the unicast address of the client, it sends the message as a Relay Reply message to a Relay agent. While a client is in a Reconfigure process, it does not accept further Reconfigure messages. A new process can be started only once the initial process has been completed.

9.2.6.5. Relay Agent communication

The way a Relay Agent forwards DHCP messages with DHCPv6 is quite different from the way it is done with DHCPv4. The following section describes the Relay Agent communication in detail. A Relay Agent is often called an IP helper in the Cisco world.

A Relay Agent uses the All_DHCP_Severs multicast address (FF05::1:3) to forward messages to DHCP servers. It can be configured to use a unicast address. The Relay Agent takes the message coming from the client and builds a Relay Forward message. Figure 9-4 shows the header of this message. In the Link Address field, it sets its global IPv6 address with the prefix for the link on which the client resides. From this address, the DHCP server determines for which prefix it has to allocate addresses. The Hop Count is set to 1. The Source address from the original address (i.e., the client IP address) is copied into the Peer Address field of the Relay Forward message. The original DHCP message is copied into the Relay Message Option field. The Relay Agent can now add other information that has been preconfigured by the administrator.

When a Relay Agent receives a Relay Forward message from another Relay Agent and the value of the Hop Count field reaches the preconfigured value for the Hop Count Limit, it ignores the message. With the Hop Count Limit, the number of Relay Agents that forward a DHCP message can be limited. If the Hop Count is smaller than the Hop Count Limit, the message is forwarded. It encapsulates the packet into another Relay Forward header, increases the Hop Count by one, and copies the Source address of the previous Relay Agent into the Peer Address field. The Link Address field is set to 0. The message received is copied into the Relay Message Option.

As already mentioned, the Relay Reply message has to be forwarded over the same Relay Agents as the Relay Forward message. With the process just described, each Relay Agent encapsulates the received message into a new Relay Forward header, which makes it possible for the DHCP server to track the way back. In the last Relay Message Option, the server finds the original request from the client. It replies to it and copies the answer into the Relay Message Option of a Relay Reply message. It encapsulates this reply into as many Relay Reply headers as the Relay Forward message has received. So the Relay Reply travels the same way back through the same Relay Agents. Each Relay Agent on the path decapsulates the exterior header and forwards the message to the next Relay Agent. The last Relay Agent on the path receives a Relay Reply message, which contains the server reply in the Relay Message Option field. It removes the Relay Reply header and forwards the server reply to the client.

Table 9-3 shows the entries in the header fields for a packet that has been forwarded over two Relays, Relay A and Relay B.

The communication looks as follows:

1. Client C sends a DHCP Request (Packet 1, not shown in Table 9-3).

2. Relay Agent A forwards the client request in a Relay Forward message (type 12) to Relay Agent B (packet 2). It copies its address into the Link Address field. The client request is copied into the Relay Message Option.

3. Relay Agent B forwards the message to the DHCP server (packet 3). It sets the Link Address field to 0 and copies the address of Relay Agent A into the Peer Address field. Packet 2 received from Relay Agent A is copied into the Relay Message Option.

4. The DHCP server sends a Relay Reply (type 13) to Relay Agent B (packet 4). The Hop Count, Link Address, and Peer Address fields are copied from the Relay Forward message. The Relay Message Option contains the packet, which has to be sent from Relay Agent B to Relay Agent A (packet 5).

5. Relay Agent B decapsulates packet 5 and forwards it to Relay Agent A.

6. Relay Agent A takes the server reply from the Relay Message Option and forwards it to Client C.

9.2.7. Security Considerations

Attacks based on DHCP functionality are possible in the IPv4 world as well as in the IPv6 world. The points of attack to be watched are the same:

• External, unknown DHCP servers allocating false addresses to DHCP clients

• Faulty or malicious DHCP servers in the intranet that assign false addresses or other false configuration information to DHCP clients

• Unknown, external clients that attach to the corporate network and receive internal addresses

• Intentional exhaustion of IP addresses by malicious clients, resulting in valid clients being unable to obtain a valid IP address and/or configuration options

• Malicious client(s) transmitting such high volumes of requests that a DHCP server is unable to respond to valid requests

To protect your network from external DHCP servers from outside the corporate network, a firewall closing the ports for DHCP is a good protection. It is important to protect your network from internal DHCP servers. It doesn't even need to be a malicious attack. Very often the problems come from improperly configured test servers. A client can be attacked by a malicious DHCP server configuring it with false information. For instance, a bad DNS or NTP server can be configured, or it can be configured in a way that it cannot communicate in the local network anymore. To protect from such attacks, Authentication should be used.

With DHCPv4, the ways to protect from such attacks are limited. Firewalls only protect from outside attacks. The possibility to use Authentication for DHCP communication exists only in the form of vendor solutions in addition to DHCPv4.

The specification for DHCPv6 includes an Authentication mechanism, which is based on Authentication for DHCPv4 (RFC 3118). New hosts must be authorized and authenticated before they receive configuration information from a DHCP server, the sender of a message must be authenticated, and the content of the message must be protected.

The following section gives an overview of the Authentication mechanisms specified in RFC 3315. If you are not familiar with security concepts and terms, please refer to Chapter 5 first.

9.2.7.1. Security for messages between Relay Agents and DHCP servers

For a secure exchange of messages between Relay Agents and DHCP servers, IPsec (in transport mode with ESP) is used. Between each Relay Agent and its communication peers, an independent two-way trust relationship has to be established. If the content of the message is not considered confidential, encryption is not required (null encryption). As the Relay Agents and the DHCP servers are within the corporate network, private keys can be used.

In addition to this, DHCP servers and Relay Agents are configured with the addresses of trusted communication peers. It is therefore not possible for an unknown DHCP server or Relay Agent to intrude into the communication.

9.2.7.2. DHCP Authentication

The authentication of DHCP messages can be accomplished through the use of the Authentication option (option 11). The authentication information carried in the Authentication option can be used to reliably identify the source of a DHCP message and to confirm that the contents of the DHCP message have not been changed. Multiple authentication protocols can be used with the Authentication option. Two such protocols are specified in RFC 3315: the Delayed Authentication Protocol and the Reconfigure Key Authentication Protocol (section 21 in RFC 3315). Additional protocols may be specified in the future with separate RFCs.

9.2.8. Dynamic Updates to DNS

With the widespread use of DHCP and autoconfiguration for dynamic IP address configuration, the need for a dynamic update of DNS for addition and deletion of records arose. RFC 2136 introduced the mechanism called Dynamic DNS (DDNS). It is supported by BIND Versions 8 and 9 and many popular DNS implementations. The update functionality is usually used by applications such as DHCP, but it can be implemented on hosts as well. With IPv6, dynamic addresses are often assigned using Stateless autoconfiguration, which means there may not be a DHCP server in the network. A DNS update mechanism is necessary on each host to update its DNS records. There are important security aspects to consider when DDNS updates are made. It is important that you can control which nodes are authorized to make changes to your DNS records. Update policies must be implemented and Transaction Signatures (TSIG; see RFC 2845) or Domain Name System Security Extensions (DNSSEC; see RFCs 3007, 4033, 4034, and 4035) mechanisms should be used. RFC 4339, "IPv6 Host Configuration of DNS Server Information Approaches," discusses some of these general DNS aspects for IPv6 hosts.

9.2.9. Stateless DHCP

In environments where Stateless autoconfiguration is used for IP address information, there was no way to configure additional information on the client, such as DNS information or other options. Several solutions were discussed, one being to add such options to the Router Advertisement. Finally, RFC 3736 specified a new service called Stateless DHCP Service for IPv6. A Stateless DHCP server has an implementation of only a subset of the DHCPv6 specification. Its use requires that hosts are already configured for an IPv6 address. A Stateless DHCP server replies to Information Request messages (message type 11) that contain an Option Request option (option type 6) with a Reply message (message type 7). The Stateless DHCP server can also act as a relay agent. This allows configuration of a part of the clients on a link using Stateless address autoconfiguration while getting additional information from the Stateless DHCP server. Meanwhile, other clients use Stateful address autoconfiguration, and their DHCP messages are forwarded by the Stateless DHCP server acting as a relay agent.