DHCP in a Gist

Coming to the history of host auto configuration protocols, there were many protocols before DHCP that were meant to configure clients with minimal user intervention such as Reverse-ARP, BOOTP, etc…
DHCP is actually a extension of BOOTP mechanism which allows backward compatibility with BOOTP devices.

There are some differences between DHCP and BOOTP such as DHCP has mechanism to assign leases for a finite amount of time, thus, saving IP addresses.
Also, there is some terminology differences b/w them such as the dhcp options were called as vendor-extensions in DHCP.
Another major improvement in DHCP compared to BOOTP was that BOOTP uses 2-phase mechanism and requires additional servers for providing other details like it requires another TFTP server for performing file transfer of boot images, whereas DHCP uses 1-phase boot config and the client negotiates with a DHCP server to determine its IP address and obtain any other initial configuration details it needs for network operation.

DHCP MESSAGES

\1. message-type
\2. hops (client sets as zero, relays increment it)
\3. transaction-id
\4. flags —> contains a bit called broadcast bit which helps clients that cannot unicast before getting a IP address get a DHCP exchange successfully
\5. client-ip addr---> used only after client has already got an IP address during Renew/Rebind message exchange
\6. si-addr—> server-id, filled by server
\7. gi-addr —> relay agent IP address is put here if relay is used. If server is in same subnet as client, it will be 0x0 .ie. no relay has sent this message
\8. cl-id: client mac is put here usually, but, not necessarily since it is considered as opaque field by server….This field is used by server to assign leases and thus, the client also should use the same identifier so that server can recognize it
\9. file: TFTP server location
\10. options
Others are also there like server-hostname, your-Ip address (used by server in advertising Offers) etc…

Client sends a broadcast DHCP Discover message with S-IP: 0 and D-Ip: 255.255.255.255. S-mac: client-mac and D-Mac: ffff:ffff:ffff
Now, servers present in same broadcast domain will send offers and put the IP address in your-ip-address field of DHCP. This message will be sent as unicast message to client with D-IP as the one which it plans on offering and the D-Mac as the client’s Mac. This behavior depends on the server actually and both unicast and broadcast dest-IP address will work.
Then, client chooses one of the servers and sends request. This is always sent as a broadcast message so that other servers which were not chosen knows that those Offers were implicitly declined
Then, the DHCP server first pings for the IP which it plans on assigning so as to confirm that that Ip was not manually assigned to any host. If it passes, it sends a ACK to the client with the configuration parameters as UNICAST. If ping fails, it sends a NAK to client as broadcast

DHCP Decline: After server sends a ACK, the client does a G-ARP for the IP. If it fails, client sends a DHCP Decline to server
DHCP Release: Graceful shutdown- Informing the server of cancelling the lease by the client
DHCPInform: used by client to only request parameters and not IP addresses.

There is no explicit DHCP Renew message in v4 and same Request messages are used even for Renew with the fields being set with IP addresses and this will be unicast directly to server-ip
Now, if the B bit is set in the DHCP DISCOVER of the client, all the above exchange will be using the destination-Ip as broadcast always
Another thing to note is that DHCP covers variety of scenarios such as different servers offering IPs in different subnets as well as two servers offering IP in same subnet. In the above exchange, the transaction-id set by the client will be the same and even if two messages are received by client from different servers, it will just ignore the later one (ACK- in case of same pools, NAK in case of different pools)

Since for DHCP servers to work, we need them in same subnet as the client but this approach is scalable and costly
So, usually DHCP/BOOTP relays are used to unicast the client’s DHCP messages to the server
In case relays are used, the giaddr field in the DHCP message will contain the relay agent’s interface on which the client is connected to.
All replies from server will be sent to this address

Permanent allotment: Server assigns a lease to client permanently. Done by putting the seconds field as ffff-ffff
Fixed time allotment: Here client is given a lease time with minimum of 300 sec and the client must periodically renew the lease
Manual assignment using DHCP- used for getting finer control wherein we configure a IP for each client’s Mac on the server

Several DHCP options can be there
In case the client needs particular parameters from the server, it uses the Parameter Request Option. The client uses this to request for subnet mask, gateway router, renewal time and rebinding time. (The server gives all these info in separate respective options )

Now, there is another very important Option in DHCP which is the DHCP Option82. Also known as Relay agent Information Option

This option82 enables a DHCP relay agent to insert information about a client's identity into a DHCP client request being sent to a DHCP server. This option can be used to assist DHCP servers to implement dynamic address policy.
It is used only between the relay and the server and is deleted before forwarding to the client

DHCP snooping is a security feature to prevent dhcp-based violations by identifying trusted and untrusted ports and marking only the known server’s port as trusted port and all clients will be untrusted. If any dhcp message that is supposed to be sent only by server comes on untrusted port, those packets are not forwarded. In order for DHCP snooping to work, we need the relay agent to use Option82 and this is done automatically.
Option82 can contain several sub options. In case of DHCP snooping, the sub options used to identify the client are:

Circuit-id ——> identifies the link on the relay
remote-id ——> identifies the relay-agent. We use the relay agent’s mac address as remote-id