ch1.pdf

JTO Phase-II IT DHCP 1 DYNAMIC HOST CONFIGURATION PROTOCOL (DHCP) 1.1 INTRODUCTION DHCP (Dynamic Host Configuration Protocol) is a network management protocol used to dynamically assign an...

JTO Phase-II IT DHCP 1 DYNAMIC HOST CONFIGURATION PROTOCOL (DHCP) 1.1 INTRODUCTION DHCP (Dynamic Host Configuration Protocol) is a network management protocol used to dynamically assign an Internet Protocol (IP) address to any device, or node, on a network so they can communicate using IP. DHCP automates and centrally manages these configurations rather than requiring network administrators to manually assign IP addresses to all network devices. DHCP can be implemented on small local networks as well as large enterprise networks. 1.2 HOW DHCP WORKS? Figure 1: 1.3 SCHEMA OF A TYPICAL DHCP SESSION DHCP uses the same two IANA assigned ports as BOOTP: 67/udp for the server side, and 68/udp for the client side. DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement. After the client obtained an IP address, the client may start an address resolution query to prevent IP conflicts caused by address poll overlapping of DHCP servers. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 2 of 167 For Restricted Circulation JTO Phase-II IT DHCP DHCP discovery The client broadcasts on the local physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a UDP packet with the broadcast destination of 255.255.255.255 or subnet broadcast address. A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation dependent time out for the client to give up on the request and ask for a new IP. DHCP offers When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer. The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field. DHCP requests When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card. DHCP acknowledgement When the DHCP server receives the DHCPREQUEST message from the client, it initiates the final phase of the configuration process. This acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the TCP/IP configuration process is complete. The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 3 of 167 For Restricted Circulation JTO Phase-II IT DHCP 1.4 DHCP GOALS Compatibility The DHCP protocol must be compatible with existing interface and protocols; For example it should be compatible with all the types of clients, each one can have a different configuration of communication parameters. As mentioned in "Protocol introduction", the DHCP protocol should have compatibility with the BOOTP protocol which was used before. Local control Although the DHCP protocol is an external mechanism for allocating a web address and communication parameters, the administrator of the client must have the capability to control these parameters. Communication parameters preserving: The DHCP server has to give a specific client the same communication parameters in as many sequential requests as possible, so if a client was disconnected from the web and requests its address/communication parameters again, it would receive the same communication parameters as before. (if nothing has changed since the disconnection). The same is for the DHCP server, which should have the capability to give the same client the same communication parameters even if it was disconnected from the web. Unique clients A main goal of the DHCP protocol is to give each client its unique address. A situation in which two or more clients are allocated with the same web address must not occur in any circumstances, to prevent a situation of client send a message to the wrong client. Automatic Configuration Usually, a single client should have to be configured automatically by the DHCP server and not manually by the administrator of that client. A situation in which the configuration of the communication parameters is done manually by the client's administrator should occur seldom. But when it happens, the DHCP server must be compatible with the manual configuration as mentioned before. Saving hardware There should not be a DHCP server for each and every link interface. There should be a wide use of relay-agents to transmit a DHCP messages. If less DHCP servers are used, it's more financialy agreeable because we'll use the relay-agents which are simpler. The hardware saving will lead to more economically worthwhile network and will save money as mentioned in "protocol introduction". JTO Phase –II DNIT Version 1.0 Sep 2021 Page 4 of 167 For Restricted Circulation JTO Phase-II IT DHCP 1.5 HISTORICAL BACKGROUND At first, most TCP/IP networks were relatively small and static. Manual IP address management techniques were sufficient for them. Each station kept its own IP address somewhere in its secondary storage. Once the address had to be changed, it required manual administrator action, usually at the machine console, and in most cases involved a reboot. Soon afterwards, as more complex networks were established, as more and more underlying network hardware was used for TCP/IP communication networks and as cheap client workstations without secondary storage came in use, a need for central administration of the hardware to P addresses bindings became obvious. A special protocol (RARP) for such bindings was designed. It allowed a machine on a network segment to learn its own IP address and then to begin normal TCP/IP operation. Another protocol, BOOTP, was also developed to allow diskless stations retrieve all the TCP/IP configuration parameters and other operating system data, needed to start functioning normally after a startup. It allowed configuration over broader networks as it was not limited to a single segment. For that purpose BOOTP defined the concept of a BOOTP relay agent which specified how BOOTP traffic is forwarded between multiple segments. BOOTP was designed to be easily extended by the BOOTP extension mechanism. This mechanism uses the last field in the frame for more (vendor) specific data and message options. The next attempt to extend BOOTP provided the Dynamic Host Configuration Protocol, DHCP. DHCP was designed to be backward compatible with BOOTP in order to support BOOTP clients and BOOTP relay agents, yet there are two primary differences between DHCP and BOOTP: 1. DHCP defines a mechanism through which a client can be assigned a network address for a finite lease, allowing for a serial reuse the same network address by different clients. 2. DHCP provides a mechanism for a client to request and acquire all the IP configuration parameters that it needs in order to operate, and only them. DHCP comes with a predefined set of DHCP options, which it inherits from the BOOTP vendor extensions mechanism, and it is open for further extension, inheriting the openness from BOOTP. 1.6 MAIN DIFFERENCES BETWEEN BOOTP AND DHCP: The DHCP is an extension of the previous BOOTP protocol, thus it must be compatible with BOOTP messages, but there are some differences between BOOTP and DHCP. One difference is that DHCP is designed to allocate a web address to a client temporarily so the client can disconnect allowing another client to get this web address, or renew the lease of the web address, a capability which the BOOTP protocol does not have. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 5 of 167 For Restricted Circulation JTO Phase-II IT DHCP Another difference is that the DHCP can configure a client with all the IP parameters that the client needs in order to establish communication. One BOOTP transfer only some of these parameters. Moreover, the BOOTP protocol had a field named 'vendor extentions', to specify the requested parameters and other options, which were replaced with the field 'options' in the DHCP protocol. In addition, the BOOTP protocol had a field named "chaddr" in order to specify the address of the client which has requested the communication parameters. In DHCP protocol, there is the field "client identifier". This field can have the physical address of the client as in "chaddr" of the BOOTP protocol, or it can have another identifier like DNS name, or another types. New types of identifier can be registered in IANA. DHCP is currently the most advanced host configuration mechanism for TCP/IP, although it still has its problems, giving researchers things to work on, for an even better configuration protocol in the future. 1.7 PROTOCOL INTRODUCTION General The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts in a client-server model. DHCP server hosts allocate network addresses and deliver configuration parameters to other (client) hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a server to a host and a mechanism for allocation of network addresses to hosts. IP Address Allocation DHCP supports three mechanisms for IP address allocation. 1. Automatic allocation -- in which a permanent IP address is assigned to the client. 2. Dynamic allocation -- in which the address is assigned for a limited period of time (a "lease"). 3. Manual allocation -- in which the address is assigned manually by the network administrator. 1.8 CONFIGURATION PARAMETERS DELIVERY The client sends a message to request configuration parameters and the server responds with a message carrying the desired parameters back to the client. BOOTP Compatibility The format of DHCP messages is based on the format of BOOTP messages due to the following reasons: JTO Phase –II DNIT Version 1.0 Sep 2021 Page 6 of 167 For Restricted Circulation JTO Phase-II IT DHCP 1. From the client's point of view, is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software. 2. DHCP supports the BOOTP relay agent behavior. Use of Relay Agents DHCP does not require a server on each subnet. To allow for scale and economy, DHCP can work across routers or through the intervention of BOOTP relay agents. A relay agent listens to DHCP messages and forwards them on (and onto other network segments). This eliminates the necessity of having a DHCP server on each physical network. Allocation of network addresses DHCP supports three mechanisms for IP address allocation. The DHCP server can use any one or more of the of these mechanisms: 1. Automatic allocation: The DHCP server assigns a permanent IP address to a client without any manual interference. Automatic allocation is best suited for in cases where hosts are permanently connected to a network and the network does not suffer from an address shortage. 2. Manual allocation: The client's IP address is assigned manually by the network administrator. The DHCP server simply retrieves it from its storage and delivers it to the client. Manual allocation is best suited for giving IP addresses to servers of any kind. As servers are the ones to be addressed, rather than to initiate a conversation, their location should be permanent and known in the network. Manual allocation would guarantee that (although a clever use of Automatic allocation can accomplish that too). 3. Dynamic allocation: The DHCP server assigns a temporary IP address to a client without any manual interference. Dynamic allocation is the most interesting method of the three, because it involves not only the assigning of a network address but also reclaiming and reusing of the same address by another client. Therefore, using Dynamic allocation allows for an efficient managing of a pool of network addresses and is particularly useful in cases where: 1. There is a limited amount of network addresses on the net. 2. The network has computers which temporarily connect and disconnect to it (e.g. portable computers) and so the network is changing frequently. The basic mechanism for the dynamic allocation of network addresses is simple: the client requests the use of an address for a limited period of time (which is called a lease). The DHCP server allocates an address for the client, marks it as 'used' and notifies the client about the address and the lease time approved. The client, in his turn, can: 1. Extend its lease with subsequent requests. 2. Ask for a permanent assignment by asking for an infinite lease. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 7 of 167 For Restricted Circulation JTO Phase-II IT DHCP 3. Release the address back to the server before the lease expires, in case it doesn't need it. Renewing and acquiring addresses The client holds two times in its memory ? time1, and time2. The first time is the time in which the client starts to ask its server for renewing the lease of its address ? RENEWING state in the states diagram of the protocol. The second time is the time in which the client starts to ask other servers for address ? REBINDING state in the states diagram of the DHCP protocol. When the first time arrives, the client sends the DHCPREQUEST message to the server with unique ID to this request. If the renew is approved, the server will send an answer in DHCPACK message with this ID. Then the client returns to normal functioning. The new time1 will be the sum of the time in the server's answer and the time which has passed from the start of the request to the answer. If no answer has arrived until time2 has passed, the client will enter the REBINDING state in the states diagram of the DHCP protocol, and will send a multicast message to all the servers available to acquire new address. These times can be changed by servers in the 'option' field, and have default values. The default of time1 is half of the lease time of the current address, and the default of time2 is 0.875x(lease time). In both cases ? time1 and time2, if the client has not got an answer from the DHCP servers, it should wait half of the time which is left before sending DHCPREQUEST again. The shortest waiting time is one minute. If the client has got its previous address, it continues to work normally. If the client didn't get its previous address but got a new one, he should continue working, but not with the current web parameters, and must inform the users about this. If the client didn't manage to get an address at all, it should stop its work and go back to INIT state in the states diagram of the DHCP protocol. 1.9 CONFIGURATION PARAMETERS DELIVERY The DHCP server is designed to supply DHCP clients with the configuration parameters defined in the Host Requirements RFCs (1122 and 1123). Most of those parameters are related to the TCP/IP protocol stack but DHCP allows the configuration of non-related parameters too. The server provides a permanent storage of network parameters for network clients. The DHCP storage model is a set of key-value pairs for each client, where the key is some unique identifier and the value contains the configuration parameters for the client. In other words, the storage model is a per-host list of entries of the form: key = value JTO Phase –II DNIT Version 1.0 Sep 2021 Page 8 of 167 For Restricted Circulation JTO Phase-II IT DHCP The client addresses the server with a request message to retrieve its configuration parameters. The server answer with a response message carrying the configuration parameters in the (later discussed) options field. Not all clients require initialization of all possible parameters. Two techniques are used to reduce the number of parameters delivered from the server to the client: 1. Most of the parameters have defaults defined in the Host Requirements RFCs (1122 and 1123). If the client receives no parameters from the server that override the defaults, a client uses those default values. 2. A client and server may negotiate for the delivery of only those parameters required by the client. In a case like that the client includes the parameter request list option in the requested message and fills it with the list of parameters it needs. 1.10 MESSAGE FORMAT As mentioned earlier, the format of the DHCP messages is based on the format of BOOTP messages in order to keep compatible with BOOTP relay agents and BOOTP clients. Here is the DHCP message format. The numbers in parentheses indicate the size of each Field in Bytes. Figure 2: Description of Fields in a DHCP message Field Bytes Description Message op code / message type. op 1 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 Hardware address type (e.g., '1' = 10Mb Ethernet) JTO Phase –II DNIT Version 1.0 Sep 2021 Page 9 of 167 For Restricted Circulation JTO Phase-II IT DHCP hlen 1 Hardware address length (e.g. '6' for 10Mb Ethernet) Client sets to zero, optionally used by relay agents when booting via a hops 1 relay agent. Transaction ID. xid 4 A random number chosen by the client, used by the client and server to associate the request message with its response. Seconds passed since client began the request process. secs 2 Filled in by client. flags 2 Flags Client IP address. ciaddr 4 Filled in by client if it knows its IP address (from previous requests or from manual configurations) and can respond to ARP requests. yiaddr 4 'your' (client) IP address. Server's response to client. Server IP address. Address of sending server or of the next server to siaddr 4 use in the next bootstrap process step. giaddr 4 Relay agent IP address, used in booting via a relay agent. chaddr 16 Client hardware address. sname 64 Optional server host name. Null terminated string. Boot file name. file 128 Null terminated string; "generic" name or null in request, fully qualified directory-path name in reply. Field to hold the optional parameters. options variable (See next section). Table 1. The 'options' Field in a DHCP message Apart from the small amount of the Fields imported from the BOOTP frame format there came a need for a lot more Fields, some of them changing from one message to another, others from one subnet to another etc. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 10 of 167 For Restricted Circulation JTO Phase-II IT DHCP That need came first after defining the BOOTP protocol which led to the BOOTP extension mechanism, where the last Field in the frame format, the 'vendor extensions' filed was of variable length and could contain the extra information. DHCP improved this mechanism, changing the Field name to 'options' and adding more options. One way to categorize those options would be to split them into two groups: 1. Configuration parameters. 2. Message control information. All options begin with a tag octet, which uniquely identifies the option. The next octet is the option length specifier, its value does not include the two Bytes specifying the tag and length. The length octet is followed by length Bytes of data. All these options/vendor extensions are defined in RFC 2132, where they are split to the following groups: 1. RFC 1497 Vendor Extensions. 2. IP Layer Parameters per Host. 3. IP Layer Parameters per Interface. 4. Link Layer Parameters per Interface. 5. TCP Parameters. 6. Application and Service Parameters. 7. DHCP Extensions. 1.11 SOME IMPORTANT DHCP OPTIONS: Message Type (a DHCP control): Specifies the type of the DHCP message in order to be more specific than the originally BOOTP Field 'op'. Different message types are used at different stages of the client/server interaction. Appears in every DHCP message (therefore the 'options' Field is never empty): Renewal Time Value (a DHCP control): Specifies the time interval from address assignment until the client attempts to contact the server that originally issued the client's network address before the lease expire. Parameter Request List (a DHCP control): A list of valid DHCP option codes. Used by a DHCP client to request values for specified configuration parameters. Subnet Mask (a Configuration parameter): Specifies the client's subnet mask. DNS Option (a Configuration parameter): JTO Phase –II DNIT Version 1.0 Sep 2021 Page 11 of 167 For Restricted Circulation JTO Phase-II IT DHCP Specifies a list of DNS name servers available to the client. Message Format in IPv6 Every message in DHCP protocol of IPv6 has a constant length header and variable length data. This data is located in the "options" Field, and composed from Bytes, in network byte format (least significant byte first. This is the format of a message which sent from client directly to the server: Figure 3: Field Bytes Description This is the type of the message chosen from the 11 types of direct msg-type 1 messages from client to server (an exact list in "Message Types Summary"). transaction- 3 The ID for this message transport. id options variable The options for this message. This is the format of a message from relay-agent to another relay-agent or a server: JTO Phase –II DNIT Version 1.0 Sep 2021 Page 12 of 167 For Restricted Circulation JTO Phase-II IT DHCP JTO Phase –II DNIT Version 1.0 Sep 2021 Page 13 of 167 For Restricted Circulation JTO Phase-II IT DHCP Figure 4: Field Bytes Description msg-type 1 The code of the message, RELAY-FORW or RELAY-REPL. hop-count 1 Counts the relay-agents which the message has passed until now. link- Used by the server to identify the link of the client in RELAY- 12 address FORW message or in RELAY-REPL message. peer- The address of the relay-agent or the client from which the message 12 address was received ? the current hop. Options for the message. Here the message has to have "Relay options variable Message option" among the other options. Table 2. The options are in this format: JTO Phase –II DNIT Version 1.0 Sep 2021 Page 14 of 167 For Restricted Circulation JTO Phase-II IT DHCP Figure 5: Field Bytes Description option- The number of option according to "types of 2 code options". option-len 2 The length of the option-data in bytes. option- the value in "option-len" in The data of the options. data bytes Table 3. 1.12 CLIENT/SERVER MODEL The client and the server negotiate in a series of messages in order for the client to get the parameters it needs. The following diagram shows the messages exchanged between the DHCP client and servers when allocating a new network address. Next is a detailed explanation of all the various messages and a description of the communication steps. This process can involve more than one server but only one server is selected by the client. In the figure, the selected server is marked 'selected' and the other, 'not selected' server stands for all the possible not selected servers. 1.13 STEPS OF COMMUNICATION : 1. The client broadcasts a DHCPDISCOVER. 2. Each server may responds with a DHCPOFFER message. 3. The client receives one or more DHCPOFFER messages from one or more servers and chooses one server from which to request configuration parameters. 4. The client broadcasts a DHCPREQUEST message. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 15 of 167 For Restricted Circulation JTO Phase-II IT DHCP 5. Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server's offer. 6. The server selected in the DHCPREQUEST message commits the responds with a DHCPACK message containing the configuration parameters for the requesting client. 7. The client receives the DHCPACK message with configuration parameters. At this point, the client is configured. 8. If the client receives a DHCPNAK message, the client restarts the configuration process. 9. The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server (e.g. on shutdown). 10. The server receives the DHCPRELEASE message and marks the lease as free. Variations on the timeline diagram. There are two main variations on the presented client/server interaction scenario: 1. Reuse of a previously allocated network address: If a client remembers (in its cache) and wishes to reuse a previously allocated network address, a client may choose to omit some of the steps taken in case of a new allocation. In the first DHCPREQUEST the client includes its network address in the 'requested IP address' option. The server that has the knowledge of the client's configuration respond with a DHCPACK message and from then on the diagram continues from step (5). 2. Obtaining parameters with externally configured network address: If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without allocating a new address. 1.14 MESSAGE TYPES Message Use DHCPDISCOVER Client broadcast to locate available servers. DHCPOFFER Server to client in response to DHCPDISCOVER with offer of configuration parameters. DHCPREQUEST Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others, (b) confirming correctness of previously allocated address after, e.g., system reboot, or (c) extending JTO Phase –II DNIT Version 1.0 Sep 2021 Page 16 of 167 For Restricted Circulation JTO Phase-II IT DHCP the lease on a particular network address. DHCPACK Server to client with configuration parameters, including committed network address. DHCPNAK Server to client indicating client's notion of network address is incorrect (e.g., client has moved to new subnet) or client's lease as expired DHCPDECLINE Client to server indicating network address is already in use. DHCPRELEASE Client to server relinquishing network address and canceling remaining lease. DHCPINFORM Client to server, asking only for local configuration parameters; client already has externally configured network address. 1.15 MESSAGE TYPES IN IPV6 Message Use SOLICIT This message is sent by a node to discover new DHCP servers ADVERTISE This message is sent by the DHCP server in response to a "SOLICIT" message. It means that this DHCP server is available to serve the client. REQUEST A request of an address and communication parameters after a node has found a DHCP server. CONFIRM A multicast message to all DHCP servers which are available, to confirm, that its address is still appropriate to its link. RENEW A request to renew address lifetime or updating communication parameters. The message is sent to a specific DHCP server which has sent its address/communication parameters beforehand. REBIND A multi Broadcast message to all the servers available with the request to renew addraddreess or updating its communication parameter. This message is sent sentafter a "RENEW" request didn't get any response from the node‟s DHDHCPPrver. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 17 of 167 For Restricted Circulation JTO Phase-II IT DHCP REPLY A message that is sent to a node by a DHCP server. Address/communication parameters are sent in response to a "SOLICIT", "REQUEST", "RENEW" or "REBIND" messages from a node. Additionally it is used to confirm or reject an address in response to a "CONFIRM" message, or it simply used as an ack message in response to a "RELEASE" or "DECLINE" message from a node. RELEASE A message from a node to the DHCP server which granted it an address. It is sent when the node no longer needs that adress. This message is mean to let the DHCP server know that this address is free to use by other nodes. DECLINE A message to the DHCP server which means that a node declines the address which is already taken, and the node requests another address. It can happen when a node discovers that an address which the DHCP server has gaven it is used by another node in the link. RECONFIGURE A message sent by the DHCP server when it wants to update a node's communication parameters. The node response should be a "RENEW" message back to the DHCP server. INFORMATION- This message is sent to a DHCP server when a node wants to get REQUEST communication parameters without an address. RELAY-FORW A message which is sent from relay-agent to a DHCP server or another relay-agent, and encapsulates the innitial message from a node to the DHCP server. RELAY-REPL A message which is sent from DHCP server or another relay-agent to a certain relay-agent, and encapsulates the innitial message from a DHCP server to the node. 1.16 SECURITY IN DHCP Security is a significant subject in when considering DHCP, this is because the main goal is to get communication parameters/IP address from an external source. This can give an opportunity do damage the host from outside of the system. There numerous threats to a host which using DHCP. For example: Deploying fake DHCP servers that will always deny service. Another way is by sending incorrect communication parameters and wrong DHCP server information either because of flawed server, or deliberately. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 18 of 167 For Restricted Circulation  JTO Phase-II IT DHCP These threats require authentication of the DHCP server or/and the communication parameters to ensure that we are dealing with real DHCP server which sends valid parameters. In order to achieve higher safety, the following two rules must be obeyed: 1. The protocol cannot be changed. (i.e. its structure, msg types etc. must remain intact.) 2. Interact with the DHCP server as little as possible ? minimize the number of stages of the communication with the DHCP server. Main way to authenticate a DHCP message is to include an authentication field in the "option" field of the DHCP message. Figure 6: This is the format of DHCP client/server message with "authentication option?: Description of Fields in a DHCP message Code Bytes Description op 1 The code of an authentication message is 90. Length 1 The length of the information data. The name of the protocol used for authentication (there are Protocol 1 number of techniques). The name of the algorithm used by the protocol in the "protocol" Algorithm 1 field. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 19 of 167 For Restricted Circulation JTO Phase-II IT DHCP RDM stands for "Replay Detection Method" ? the method used for RDM 4 replay detection. Replay This is a sequence of authentication. If the RDM field is 0x00, the 8 Detection sequence must be a monotonic increasing counter. 1.17 SUMMARY In addition to the method of adding "options", like in IPv4, there is also use of the IPsec mechanisms for communication between relay-agents or relay-agent - server in IPv6. IPSec is mechanism of security on the IP level. It provides services such as reply detection, access control etc. The servers and relay-agents are configured manually. Each relay-agent or server has to hold a list of pairs of servers and relay-agents to know which one will get the message. Servers and relay agents can accept messages only from DHCP sources which are on the list in their configuration. In addition to this tool, one can use also the general security tools of IPv6 for DHCP security. There are many sources to these tools in the web, and a partial list can be found in this Link. JTO Phase –II DNIT Version 1.0 Sep 2021 Page 20 of 167 For Restricted Circulation