DHCPv4 and DHCPv6 NESTED SYSTEMS. Page 1

Transcription

1 DHCPv4 and DHCPv6 NESTED SYSTEMS Page 1

2 Document revision Author Revision Date Comments Patrick Beatini /09/12 Initial revision Page 2

3 Table of Contents 1.Overview and history DHCPv4 client/server States BOOTP/DHCPv4 packet header Messages exchange Options Routing between the client and the server BOOTP relay (DHCPv4-relay) Network design The giaddr field Option 82. Relay-agent information option Server selection Messages exchange in presence of a single relay Messages exchange in presence of multiple relays DHCPv6 client/server States Usual exchanges Packet format DHCP unique identifier (DUID) Identity association Options Information request Reconfiguration DHCPv6 relay Network design Server selection Messages exchange in presence of a single relay Message exchange in presence of multiple relays DHCPv4/v6 differences and commonalities...31 Page 3

4 1. Overview and history This article provides a memo about DHCPv4 and DHCPv6, commonalities as well as the differences between the two protocols. BOOTP (Bootstrap protocol) is an IPv4 protocol used to provide boot information to a host. Historically, BOOTP has been created for disk-less workstations. When booting, these hosts requested network information as well as the location of the boot server. Once the information acquired, the workstations downloaded their executable code from the boot server. Further, the initial BOOTP protocol, having some lack of flexibility, has been enhanced by DHCP (Dynamic Host Configuration Protocol) running on top of BOOTP. Currently, the far end hosts do not download their boot code but they still need network information. DHCPv6, the Dynamic Host Configuration Protocol for IPv6, takes its root from DHCPv4. However some differences exist between the two protocol versions. DHCPv4 in brief: Stateful protocol The source IP address of the client may be unspecified (null address) in the exchanges. Carried through the DHCP options of BOOTP. DHCP message size limited to 576 bytes, unless if the MAX-DHCP-MSG-SIZE option is specified. BOOTP runs on top of UDP UDP ports used: BOOTPS: server port 67 BOOTPC: client port 68 Client-server exchanges done in either unicast mode or broadcast mode. Standards: RFC Bootstrap Protocol RFC BOOTP vendor information extensions RFC DHCP Options and BOOTP Vendor Extensions RFC Dynamic Host Configuration Protocol first issue RFC Clarifications and Extensions for the Bootstrap Protocol RFC Dynamic Host Configuration Protocol second issue RFC DHCP Relay Agent Information Option RFC Dynamic Host Configuration Protocol (DHCP) Domain Search Option DHCPv6 in brief: Stateful protocol The IP address of the client is never the unspecified address. When booting the link-local address should be used as source IP address. Client-server exchanges done in either unicast mode or multicast mode: ALL_DHCP_RELAY_AGENT_AND_SERVER: FF02::1:2. Link-scoped multicast address. All servers and relay agents are members of this multicast group. ALL_DHCP_SERVER: FF05::1:3. Site-scoped multicast address. All servers within a Page 4

5 site are members of this multicast group. DHCPv6 runs on top of UDP No message size limitation. UDP ports used: DHCPv6 client port: 546 DHCPv6 server port: 547 Standards: RFC Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC IPv6 Prefix Options for DHCPv6 RFC DNS Configuration options for DHCPv6 Note Intermediary routers (IPv4/ IPv6) relaying DHCP requests and answers are stateless. In the article, the following terminology is used for both IPv4 and IPv6: DHCP server: Host providing the network information. It is also simply called server. DHCP client: Host requesting the network information. It is also simply called client. DHCP or BOOTP relay: Intermediary router relaying the DHCP requests and replies. IP segment: IP sub-network in which all devices are directly connected at the IP level (no intermediary routers). T1: Time at which the client should start the renew process. T2: Time at which the client should enter the rebind state Page 5

6 2. DHCPv4 client/server This paragraph reminds the DHCPv4 client/server states, exchanges and known values. 2.1 States The exchanges depend on the state of the clients: Booting & selecting: The client looks for servers (discovery stage). The client builds a list of all servers answering the discover message. After a certain amount of time, the client performs a server selection. Requesting: The client sends a request to the selected server. If the server does not reply, the client can select another server from its discovery list. Bound: The server has acknowledged the request from the client. The lease time associated to the IP address starts. Renew & Rebind: The client moves to these states when the IP lease time is close to expire and needs to be refreshed. The first state is Renew, where the client contacts the selected server in unicast mode. After a certain time and if the selected server does not answer, the client moves to the Rebind state and tries to renew its lease with another server. During this stage, the IP address lease is not expired yet. It is clear that the selected server and the other servers answering the rebind message must be synchronized. 2.2 BOOTP/DHCPv4 packet header Packet header (first raw means the size of the field) var op htype hlen hops xid secs flags ciaddr yiaddr siaddr giaddr chaddr sname file option Fields op: operation code (BOOT-REQUEST: 1, BOOT-REPLY: 2). htype: Hardware type (10mb Ethernet: 1). hlen: hardware address length (Ethernet MAC address: 6). xid: Transaction identifier. hops: Number of hops. Optionally used by relay agents. secs: Seconds elapsed since client began the address acquisition. flags: Only the broadcast flag htons(0x8000) is defined. ciaddr: Client IP address (only set if the client is in BOUND, RENEW, REBIND states). yiaddr: Your IP address. Assigned IP address. siaddr: IP address of the next server to use in bootstrap. giaddr: First relay agent IP address. chaddr: Client hardware address (Ethernet MAC address if type = Ethernet). sname: Optional server host name. Can be overloaded by DHCP options. file: Optional boot file name. Can be overloaded by DHCP options options: variable part containing options. Page 6

7 2.3 Messages exchange Renew from the bound state Client Server Discover Offer Discovery stage Discover sent in broadcast. Offer sent in broadcast. Request Ack Request stage Request sent in broadcast. Ack sent in broadcast. Note The exchanges above assume the client starts from the BOOTING state, and sends its packets with the ciaddr field set to 0 and the broadcast flag set to 1. Page 7

8 Renew from the bound state T1 expiry Client Server Request Ack Renew stage Renew sent in unicast. Ack sent in unicast. Renew & rebind from the bound state Client Server 1 Server 2 T1 expiry Renew Renew Renew stage Renew sent in unicast. Renew T2 expiry Rebind Ack Rebind stage Rebind sent in broadcast. Ack sent in unicast Page 8

9 2.4 Options Option Name Code Comment PAD 0 Used to align options. SUBNET-MASK 1 Provides the subnet-mask belonging to the IP address (classless address) TIME-OFFSET 2 Offset of the client's subnet in seconds from Coordinated Universal Time ROUTER 3 Provides the router. Generally this is the default gateway TIME-SERVER 4 Provides the IP address of a timer server NAME-SERVER 5 Provides the IP address of the name server DNS-SERVER 6 IP address list of DNS servers LOG-SERVER 7 IP address list of log servers COOKIE-SERVER 8 IP address list of cookie servers LPR-SERVER 9 IP address list of line printers IMPRESS-SERVER 10 IP address list of imagen Impress servers RES-LOC-SERVER 11 IP address list of resources location servers HOST-NAME 12 Host name of the client BOOT-FSIZE 13 Boot file size option MERIT-DUMP-FILE 14 Path-name of a file to which the client's core image should be dumped in the event the client crashes. DOMAIN-NAME 15 Specifies the domain name that client should use when resolving host names via the Domain Name System. SWAP-SERVER 16 IP address of the client's swap server ROOT-PATH 17 Path-name that contains the client's root disk. EXTENSION-PATH 18 Specifies a file retrievable via TFTP, which contains information IP-FORWARDING 19 Specifies whether the client should configure its IP layer for packet forwarding SOURCE-ROUTING 20 Specifies whether the client should configure its IP layer to allow forwarding of datagrams with non-local source routes POLICY-FILTER 21 Specifies policy filters for non-local source routing. MAX-REASM-SIZE 22 Specifies the maximum size datagram that the client should be prepared to reassemble DEFAULT-IP-TTL 23 Default Time to Live for outgoing packets. PATH-MTU-AGE 24 Timeout (in seconds) to use when aging Path MTU values discovered PATH-MTU-PLAT 25 Path MTU plateau used for path MTU discovery. MTU 26 MTU to use on the interface ALL-SUBNET-LOC 27 Indicates if the MTU can be used for all interfaces. BCAST-ADDRESS 28 IP broadcast address MASK-DISCOVERY 29 Performs mask discovery MASK-SUPPLIER 30 Specifies if the client should respond to ICMP mask requests. Page 9

10 ROUTER-DISCOVERY 31 Specifies if the client should do a router discovery ROUTER-SOLICIT 32 Specifies if the client should do a router solicitation STATIC-ROUTE 33 List of static routes TRAILER-ENCAPS 34 Indicates if the client should negotiate the trailer for ARP. ARP-TIMEOUT 35 Indicates the timeout value to use for the ARP cache ETHERNET-ENCAPS 36 Indicates if the client should use the Ethernet version 2 or IEEE802.3 TCP-TTL 37 Defines the IP TTL to use when sending TCP segments TCP-KEEPALIVE-TIME 38 Defines the interval between TCP keep-alives TCP-KEEPALIVE-GARB 39 Defines if TCP should send one garbage octet with keep-alives NIS-DOMAIN 40 Name of the client's NIS domain. NIS-SERVER 41 Network Information server IP address list. NTP-SERVER 42 List of NTP server IP addresses VENDOR-SPECIFIC 43 Used to carry vendor specific options NETBIOS-NAME-SERV 44 IP address list of NetBIOS over TCP/IP name server NETBIOS-DGRAM 45 NetBIOS over TCP/IP datagram distribution NETBIOS-NODE 46 NetBIOS over TCP/IP node type NETBIOS-SCOPE 47 NetBIOS over TCP/IP scope X-WINDOW-FONT-SERV 48 IP address list of X-window font servers X-WINDOW-SYSTEM 49 IP address list of X-window servers running the X-Window system display manager. REQUESTED-IP-ADDR 50 Requested IP address. IP-ADDR-LEASE 51 IP address lease time OPTION-OVERLOAD 52 Used to indicate that the DHCP 'sname' or 'file' fields are being overloaded by using them to carry DHCP options. DHCP-MESSAGE-TYPE 53 DHCP message type. SERVER-IDENTIFIER 54 DHCP server identifier PARAM-RQST-LIST 55 List of options requested by the client ERROR-MESSAGE 56 DHCP error message (string) MAX-DHCP-MSG-SIZE 57 Maximum DHCP message size RENEWAL-TIME-T1 58 Renewal time of the IP address lease (T1 timer value) REBINDING-TIME-T2 59 Rebinding time of the IP address lease (T2 timer value) VENDOR-CLASS 60 Used by DHCP clients to optionally identify the vendor type and configuration of a DHCP client. CLIENT-IDENTIFIER 61 DHCP clients to specify their unique identifier. TFTP-SERVER-NAME 66 This option is used to identify a TFTP server when the 'sname' field in the BOOTP header has been used for DHCP options. BOOTP-FILE-NAME 67 This option is used to identify a boot-file name when the 'file' field in the BOOTP header has been used for DHCP options. RELAY-AGENT-INFO 82 This option is used by the last relay agent to locate the client interface on which the reply should be forwarded. DOMAIN-SEARCH-LIST 119 Domain search list. Page 10

11 END-OPTION 255 End of options Notes The bold row in the above table indicate usual DHCP options. If the options RENEWAL-TIME-T1 or REBINDING-TIME-T2 are missing then the timers are setup as follow: T1 = IP address lease time / 2 T2 = IP address lease time * 7 / 8 The BOOTP header also contains relevant information: htype, hlen and chaddr: MAC type, length and value ciaddr: Client IP address once assigned. yiaddr: Assigned IP address siaddr: Server IP address giaddr: Gateway IP address, which is in fact the relay IP address if any. The CLIENT-IDENTIFIER option is not required. 2.5 Routing between the client and the server The client and the server must be reachable altogether. Remember that the client renews its IP lease directly to the server. So, IP routes may be required when clients and servers are not in the same IP network. Page 11

12 3. BOOTP relay (DHCPv4-relay) When the DHCP clients and servers are not on the same IP segment, it is required to have a BOOTP relay between them. The relay has two methods to reach the server: 1. Unicast: The relay is configured with the IP addresses of the servers. The relay must be in the IP segment of the client, but not necessarily in the servers IP segments. No extra relays are required in this case. 2. Broadcast: The relay is not configured with the servers IP addresses. The broadcast mode is selected to reach next relays or servers. The relay must be in the IP segment of the client and in the server IP segment or having extra relays between it and the server. 3.1 Network design DHCP client BOOTP relay BOOTP relay BOOTP relay DHCP server DHCP client BOOTP relay DHCP server Legend IP Unicast mode between first relay and servers IP Broadcast mode between relays and servers 3.2 The giaddr field The giaddr field of the BOOT header is used by the first relay (the one on the client IP segment). The relay populates this field with its own IP address. The choice of this IP address is critical since the server replies will be addressed to this address. In other words, this address must be 'routable' from the server. When the option 82 is not used, the giaddr field is generally set to the IP address interface of the first relay facing the client. This technique allows the relay to know the interface on which the server replies should be forwarded. Note The other relays, if crossed, must not modify the giaddr field. Page 12

13 3.3 Option 82. Relay-agent information option The relay-agent information option has been introduced to fine grained the output interface selection of the relay facing the clients. This option is generally used by, but not restricted to, the broadband switched circuits networks. The idea is the addition of a new DHCP option providing interface or circuit information and used by the relay to select the correct interface on which the server replies should be forwarded. This option is generally manipulated by the first relay and copied from requests to replies as an opaque field by the server. The option is inserted by the first relay before forwarding the client requests to the server and removed in the opposite direction. The client should never receive such option. Intermediary relays must not modify the content of the option. The option is divided in two sub-options: Agent circuit ID: Variable length field that could include relevant information identifying the port facing the client (interface number, ATM virtual circuit and so on). The sub-option code is the value 1. Agent remote ID: Variable length field that could include relevant information identifying uniquely the remote client (user name, remote IP address and so on). The sub-option code is the value 2. Both sub-options should be opaque for the server point of view. 3.4 Server selection The server selection is relevant only in the case where the servers IP addresses are known from the relay agent, otherwise the relay just broadcasts the DHCP traffic. The server selection method, not described by RFC, is implementation free. However, some methods are usually used: Round-robin: The server is selected from a list with a round-robin scheduling. This method has the advantage of load-balancing the DHCP traffic. The drawback comes from the fact that the servers must be externally synchronized. Primary/secondary: A server is dedicated as primary server. Upon unreachability of the primary, the relay uses a secondary server. Primary/secondary with monitoring: Same method than the previous one, but the primary server is monitored. Once the connectivity is reestablished, the relay switches back to the primary. Page 13

14 3.5 Messages exchange in presence of a single relay Client Relay Server Discover Offer Discover Offer Discovery stage Request Ack Request Ack Request stage Notes The exchanges above assume the client starts from the BOOTING state, and sends its packets with the ciaddr field set to 0 and the broadcast flag set to 1. During renew stages, the relay is no more used since the exchanges are done in unicast mode between the client and the server. Page 14

15 3.6 Messages exchange in presence of multiple relays In this scheme, the first relay does not know the server IP address. It will use the broadcast method for reaching the server. Client Discover Broadcast Offer broadcast First relay Discover Broadcast giaddr set Relay Discover Broadcast or unicast Offer dstip=giaddr Server Discovery stage Request broadcast Request Broadcast giaddr set Request Broadcast or unicast Request stage ACK Broadcast ACK dstip=giaddr Notes The exchanges above assume the client starts from the BOOTING state, and sends its packets with the ciaddr field set to 0 and the broadcast flag set to 1. The first relay does not known the server IP address. During the renew stages, both relays are no more used since the exchanges are done in unicast mode between the client and the server. Page 15

16 4. DHCPv6 client/server 4.1 States The RFC does not define clear states as for DHCPv4. However, the principle remains the same: Initial-acquisition: The client looks for servers (discovery stage). The client builds a list of all servers answering the solicitation message. After a certain amount of time, the client performs a server selection. Requesting: The client sends a request to the selected server. If the server does not reply, the client can select another server from its discovery list. Bound: The server has acknowledged the request from the client by sending a reply. The lease time associated to the IP address starts. Renew & Rebind: The client moves to these states when the IP lease time is closed to expire and needs to be refreshed. The first state is Renew, where the client contacts the selected server in unicast mode. After a certain time and if the selected server does not answer, the client moves to the Rebind state and tries to renew its lease with another server. During this stage, the IP address lease is still not expired. It is clear that the selected server and the other servers answering the rebind must be synchronized. Page 16

17 4.2 Usual exchanges Examples starting from the Initial acquisition state Client Server Solicitation Advertisement Discovery stage Solicitation sent in multicast. Advertisement sent in unicast. Request Reply Request stage Request sent in multicast or unicast. Reply sent in unicast. DHCPv6 has the capability of requesting the network information with a two messages exchange. In this case, the client inserts the option rapid-commit in the solicitation message. If the server agrees the two messages exchange, it answers with a reply, else it answers with an advertisement. Client Server Solicitation Option: rapid-commit Discovery/request stage Solicitation sent in multicast. Reply sent in unicast. Reply Page 17

18 Renewing Client Server Renew Renew stage Renew sent in unicast Reply sent in unicast. Reply Rebinding Client Server 1 Server 2 T1 Renew Renew Renew stage Renew sent in unicast. Renew T2 Rebind Renew stage Rebind sent in multicast. Reply sent in unicast Reply Page 18

19 4.3 Packet format The standard defines two types of DHCPv6 packet: Client/server message: Used between client and server if no relay required between the client or the server. Used between client/first-relay otherwise. Relay-agent/server message: Used between relay-agent and server only. Client/server message format 1 3 variable msg-type transaction-id options Fields msg-type: Message type transaction-id: transaction identifier options: message options Relay-agent/server message format variable msg-type hop-count link-address peer-address options Fields msg-type: Message type: RELAY-FORW: Sent from relay to server. RELAY-REPL: Sent from server to relay. hop-count: In RELAY-FORW: Number of relay agents that have relayed this message. In REPLAY-REPL: copied from RELAY-FORW link-address: In RELAY-FORW: Global or site scoped address used by the server to identify the link on which the client is located. In REPLAY-REPL: copied from RELAY-FORW peer-address: In RELAY-FORW: Address of the client or relay agent from which the message to be relayed was received. In REPLAY-REPL: copied from RELAY-FORW options: Message option. Must include at least a RELAY message option. Page 19

20 4.4 DHCP unique identifier (DUID) The use of DUID by both the client and the server is required. The Standard defines three methods for generating the DUID: DUID-LLT: Link layer address plus time DUID-EN: Vendor-assigned unique ID based on Enterprise number DUID-LL: Link-layer address only DUID-LLT format variable DUID-LLT hardware type time link-layer address Fields DUID-LLT: value 1 Hardware type: Valid hardware type defined by IANA (eg Ethernet 10mb: value 1) Time: Time in second (UTC) starting at midnight January 1, 2000) Link-layer address: stored in its canonical form (RFC 2464) DUID-EN format 2 4 variable DUID-EN enterprise number identifier Fields DUID-EN: value 2. enterprise number: Vendor registered private Enterprise number. identifier: unique identifier assigned by the vendor. DUID-LL format 2 4 variable DUID-LL hardware type link-layer address Fields DUID-LL: value 3. hardware type: Valid hardware type define by IANA (eg Ethernet 10mb: value 1) link-layer address: stored in its canonical form (RFC 2464) Page 20

21 Canonical link-layer address generation for Ethernet The address is coded on 128 bits and is the well known link-layer address prefix of the form: 0xFE80:0000:0000:00xx:xxxx:xxxx:xxxx:xxxx Where the suite of x means the 64 bits identifier formed as follow: type Length Ethernet address Fields type: 1 for source link-address, 2 for target link layer address length: length in unit of 8 bytes. So value is 1 Ethernet address: Ethernet MAC address (48 bits) Example With a MAC address being 00:11:22:33:44:55 The Canonical Link layer address would be: 0xFE80:0000:0000:0001:0100:11:22:33:44 Or simply: 0xFE80::1:0100:11:22:33:44 Page 21

22 4.5 Identity association DHCPv6 differs from DHCPv4 regarding the IP address acquisition. While IPv4 allows one IP address per interface, IPv6 allows multiple addresses over the same interface. Another main difference between the two protocols is the fact that DHCPv6 allows the configuration of multiple client interfaces via a single one. This way, the client may configure all of these interfaces by requesting addresses in one time. This case could be helpful when some interfaces require address(es) but are not interconnected to the DHCP server. To assign a collection of addresses, DHCPv6 introduces the identity association (IA) construct, which is an identified receptacle containing addresses and related information. The RFC standard requires a one to one relationship between an IA construct (identified by its unique identifier:ia-id) and an interface. This means that should these several interfaces be configured, multiple IA constructs must be used. The IA construct can also carry address prefixes (also known as delegated prefixes) that can be used by the configured device. The standard defines several types of IA construct: IA-NA Non temporary address. IA-TA Temporary address. Currently this address is no more used. IA-PD Prefix delegation Notes 1. Each typed construct is a separate DHCPv6 option. 2. A given IA can transport only one type of information at a time. IA-NA option variable code option-length IA-ID T1 T2 sub-options Fields code - IA-NA code (value 3) IA-ID - Unique identifier of the IA option-length length of the option T1 Renewal time T2 Rebinding time sub-options IA-NA sub-options Page 22

23 IA-NA sub-option: IA-address (IA-ADDR) variable code option-length IPv6 address preferred-lifetime valid-lifetime IAaddr-options Fields code OPTION_IAADDR value 5 option-length length of the option IPv6 address assigned IPv6 address preferred-lifetime Preferred lifetime in second valid-lifetime Valid life time in second IAaddr-options options of the sub option. The only supported option is the status code option. Notes 1. The IA-ADDR option is the only acceptable option for IA-NA. 2. Multiple IA-ADDR options can be enclosed by a single IA-NA. IA-PD option variable code option-length IA-ID T1 T2 sub-options Fields code - IA-PD code (value 25) IA-ID - Unique identifier of the IA option-length length of the option T1 Renewal time T2 Rebinding time sub-options IA-PD sub-options IA-PD sub-option: IA-PREFIX variable code option-length preferred-lifetime valid-lifetime prefix-length IPv6 prefix IAprefix-options Fields code OPTION_IAAPREFIX value 26 option-length length of the option preferred-lifetime Preferred lifetime in second valid-lifetime Valid life time in second Page 23

24 prefix-length prefix length IPv6 prefix assigned IPv6 prefix IAprefix-options options of the sub option. The only supported option is the status code option. Notes 1. The IA-PREFIX option is the only acceptable option for IA-PD. 2. Multiple IA-PREFIX options can be enclosed by a single IA-PD. Example of constructs The example shows a DHCPv6 solicit message extracted from TCPdump requesting both an IA-NA and a IA-PD. 16:54: :06:7b:07:41:87 (oui Unknown) > 33:33:00:01:00:02 (oui Unknown), ethertype IPv6 (0x86dd), length 134: (hlim 64, next header: UDP (17), length: 80) fe80::206:7bff:fe07:4187.dhcpv6 client > ff02::1:2.dhcpv6 server: [udp sum ok] dhcp6 solicit (xid=4a73c5 (client ID hwaddr/time type 1 time f45fc08a) (option request DNS DNS name) (elapsed time 0) (rapid commit) (IA_NA IAID: T1:3600 T2:5400) (IA_PD IAID: T1:3600 T2:5400)) 0x0000: fe x0010: bff fe ff x0020: d7 0x0030: 014a 73c e f6c3 0x0040: 0040 f45f c08a x0050: e c 7b x0060: e c 7b x0070: e The example shows a DHCPv6 advertise message extracted from TCPdump requesting both an IA- NA and a NA-PD. 16:54: :02:b3:a1:3e:4d (oui Unknown) > 00:06:7b:07:41:87 (oui Unknown), ethertype IPv6 (0x86dd), length 202: (hlim 255, next header: UDP (17), length: 148) fe80::202:b3ff:fea1:3e4d.dhcpv6 server > fe80::206:7bff:fe07:4187.dhcpv6 client: [udp sum ok] dhcp6 advertise (xid=4a73c5 (client ID hwaddr/time type 1 time f45fc08a) (server ID hwaddr type b3fffea13e4d) (status code success) (IA_NA IAID: T1:62 T2:109 (IA_ADDR 2002:1:2:3:123:bb:1:2 pltime:125 vltime:250)) (IA_PD IAID: T1:62 T2:109 (IA_PD prefix 2010:1:1:1::/96 pltime:125 vltime:250))) 0x0000: ff fe x0010: 0202 b3ff fea1 3e4d fe x0020: bff fe a5d 0x0030: 024a 73c e f6c3 0x0040: 0040 f45f c08a c x0050: b3ff fea1 3e4d 000d x0060: b e00 0x0070: d x0080: 2300 bb d fa00 0x0090: b e d00 0x00a0: 1a d fa x00b0: Page 24

25 4.6 Options Option Name Code Comment CLIENT-ID 1 Client identifier (DUID) SERVER-ID 2 Server identifier (DUID) IA-NA 3 Identity association for non temporary address IA-TA 4 Identity association for temporary address IA-ADDR 5 IA address. Sub-option of IA-NA or IA-TA. ORO 6 Option request option. List of option requested by the client. PREFERENCE 7 Server preference. Sent by the server and used by the client for server selection ELAPSED-TIME 8 Amount of time since the client began its current transaction. RELAY-MSG 9 Carry the DHCP message between relay agent and servers AUTH 11 Authentication option. UNICAST 12 Sent by the server indicating that the client is allowed to send unicast message STATUS-CODE 13 Carry a status indication. RAPID-COMMIT 14 Request the two messages exchange mode USER-CLASS 15 Used by clients to identify the type of user application it represents VENDOR-CLASS 16 Used by clients to identify the vendor that manufactured the hardware VENDOR-OPTS 17 Vendor specific option. INTERFACE-ID 18 Used by relay agent to identify the interface facing the client RECONF-MSG 19 Carries the message type expected by the server during reconfiguration exchange RECONF-ACCEPT 20 Sent by the client indicating its capability of being reconfigured. DNS-SERVERS 23 List of DNS server IPv6 addresses. DOMAIN-LIST 24 Domain search list used for resolving host names. IA-PD 25 Identity association for delegated prefixes. IA-PREFIX 26 Prefix options. Sub-option of IA-PD Note The bold row in the above table indicate usual DHCP options. Page 25

26 4.7 Information request DHCPv6 has the capability of requesting only information to a DHCP servers. The information can be the DNS servers addresses, the DNS name search list and so on. In this particular case, the clients is already configured regarding its IP address (via stateless autoconfiguration or statically defined). The client/server exchange is based on two messages, as follow: Client Server Info-request Reply Page 26

27 4.8 Reconfiguration Unlike DHCPv4, DHCPv6 has the capability of dynamically reconfiguring the clients. The reconfiguration capability is negotiated between the client and the server during the initial exchange. The client indicates its reconfiguration willingness by including the specific option RECONF-ACCEPT. The server does not acknowledge this option to the client. However, it stores the information for further processing. Once a reconfiguration is required (due to a IPv6 address renumbering, DNS servers changes, etc..), the server sends a RECONFIGURE message to the clients able to be reconfigured. The server indicates the expected message type that the client should send for being reconfigured. The expected message type is carried through the RECONF-MSG option and can be either RENEW or INFO-REQ. It is up to the server to choose what should be the best message type to send to the client. The server may append an ORO option, indicating the type of information that has changed but must include an IA-NA or IA-PD option to indicate which identity association should be reconfigured. Note that the authentication of RECONFIGURATION messages are mandatory to avoid a denial of service attack. All exchanges for reconfiguration are done in unicast (even if multiple clients are concerned by the reconfiguration) and can be pictured as follow: Client Server Reconfiguration Msg-type: RENEW Renew Reply Client Server Reconfiguration Msg-type: INFO-REQ info-req Reply Page 27

28 5. DHCPv6 relay 5.1 Network design The DHCPv6 relaying method is different from the DHCPv4 one in the sens of each relay crossed in the client-to-server direction must also be crossed in the opposite (server-to-client) direction. DHCPv6 client 1 DHCP6 Relay 1 2 DHCP6 Relay DHCP6 Relay 3 DHCPv6 server 1 DHCPv6 client DHCP6 Relay 4 DHCPv6 server 2 Legend IP Unicast mode between relays IP Multicast mode between relays and servers To accomplish this exchange scheme, the DHCPv6 standard requests that the message reaching a relay agent must be encapsulated in an RELAY-MSG option and a new relay header must be inserted at the top of the message before to be forwarded to the server direction. In the opposite direction, the relay removes its own encapsulation before forwarding the message to the client direction. The final message received by the server looks like a stack of relay headers. Header DHCP message Relay Msg option1 F 0 R1c R1s DHCP message Header Relay Msg option 2 F 1 0 R2 F 0 R1c R1s Relay msg option 1 Header Relay Msg option 3 F 2 0 R3 F 1 0 R2 Relay msg option2 Header Column First column: message type. Second column: hop-count Third column: link-address Fourth column: peer-address Header values F means REPLAY-FORW Rx means address of relay x R1c: means relay address on the client side R1s: means relay 1 address on the server side Page 28

29 5.2 Server selection The server selection is relevant only in the case where the servers IP addresses are known from the relay agent, otherwise the relay just multicasts the DHCP traffic. As for DHCPv4, the server selection method, not described by RFC, is implementation free. Refer to the DHCPv4 server selection chapter for methods usually used. 5.3 Messages exchange in presence of a single relay Client Relay Server Solicit Advertise Relay-forward Relay-reply Discovery stage Request Reply Relay-forward Relay-reply Request stage Notes The exchanges above assumes the client starts from the INITIAL-ACQUISITION state, and its IP address is unknown. During renew stages, the relay is no more used since the exchanges are done in unicast mode between the client and the server. Page 29

30 5.4 Message exchange in presence of multiple relays Client First relay Relay Server Solicitation Multicast Adverstise broadcast Relay-fwd Multicast Relay-reply Unicast Relay-fwd Multicast Relay-reply Unicast Discovery stage Request broadcast Relay-fwd Multicast Relay-fwd Multicast Request stage ACK Broadcast Relay-reply Unicast Relay-reply Unicast Notes The exchanges above assumes the client starts from the INITIAL-ACQUISITION state, and its IP address is unknown. The relays ignore the server IP address. During renew stages, both relays are no more used since the exchanges are done in unicast mode between the client and the server. Page 30

31 6. DHCPv4/v6 differences and commonalities This chapter provides the common points and the differences between DHCPv4 and DHCPv6. Commonalities Similar state machine of the DHCP client. Same transport layer: UDP. Able to cross IP subnetworks via relays. Able to discover servers without any static configuration. Provides IP address and other information (such as DNS servers, DNS search list and so on). Client and server are stateful. Relays are stateless. Similar server selection algorithms used by relays. Similar timer T1 and T2 mechanisms for renewing/rebinding. The format of the DHCP options are similar (type length - value). Differences DHCPv4 can use broadcast address, while DHCPv6 uses multicast addresses. The message constructs differ: DHCPv4 is carried by an underlying protocol (BOOTP), while DHCPv6 is a standalone protocol. The message headers are different. The lease IP address is included in the BOOTP header for DHCPv4, while it is set as an option in DHCPv6. Disk-less workstations cannot boot with DHCPv6, while they can with DHCPv4. The use of the DHCP unique identifier is mandatory for DHCPv6, while it is optional for DHCPv4. The UDP ports used are not the same. Each DCHP version has its own known port set. The DHCP options are similar in their constructs but are not shared between the two protocol versions. DHCPv4 can use the unspecified address, while DHCPv6 cannot. DHCPv6 allows fast IP address allocation via the two messages exchange mechanism. Only DHCPv6 allows the configuration of multiple IP addresses per interface. Only DHCPv6 allows the configuration of a client interface other than the one performing dynamic host configuration. Only DHCPv6 allows the dynamic reconfiguration of the client (ease network renumbering, fast update of information). DHPCv6 allows retrieval of information only when IP addresses configuration is not needed. DHCPv6 allows IPv6 prefix delegation. The relay agent hop by hop mechanism for IPv6 is in the two directions, while it is only in one direction for Ipv4. Page 31