IPv4 – Basics – Part 1: DHCP (Dynamic Host Configuration Protocol)

Today I will start a small series, which will cover some basic behaviour of the IPv4 protocol suite and is meant for reimagine and a little bit baselining.

I will start the series with the Dynamic Host Confirguration Protocol (DHCP).

History:

In the Classless Inter Domain Routing (CIDR) environment of IPv4 the following parameters should be defined on every IPv4 host:

• IP-Address
• Subnetmask
• Default GW

And of course some additional infos like ntp-servers or DNS-Servers should be defined, too. If you want to adminstrate this in a network with more then 1 host, you normally would need a good pair of running shoes.

So for this kind of reason it would be nice to have a workflow which allows us to configure our hosts centralized and dynamically.

In 1985 this worklfow is defined in the RFC 951  with the invention of the Bootstrap–Protocol (BOOTP).

The idea behind BOOTP has been a client which boots without a non volatile storage gets his configuration during the boot process over the network.
but there is mainly one reason why an update for the BOOTP is needed.

• A dynamical assignment of IP-Addresses is needed without knowing the MAC Address -> For exanmple think about guest clients

DHCP

The Update is called Dynamic Host Configuration Protocol (DHCP) and was firstly defined in 1983 in the  RFC 1531. The RFC 1531 has been Updated by the RFC 1541 in the same month and this is obsoleted by the actual RFC 2131 in 1997.

Address Assignment:

The address assignment happen in 4 steps

1. Step: DHCP DISCOVER
   The client sends a Limited Broadcasts (255.255.255.255) with a DHCP DISCOVER message, and shows so that he needs an IPv4 configuration.
2. Step: DHCP OFFER
   The DHCP Server responds with an Unicast message wich contains a proposal for the new IPv4 address and the DHCP OFFER also may provide additional information like subnetmask, Default Gateway, DNS server and NTP server. The additional information depends on how the DHCP server is configured.
3. Step: DHCP REQUEST
   The client answers the proposal with a DHCP REQUEST again as a Limited Broadcast. With this DHCP REQUEST he also shows other DHCP servers which DHCP server the client has selected.
4. Step: DHCP ACK
   The server acknowledges the DHCP REQUEST with an Unicast DHCP ACK message.

Address Renewing:

Inside the Address DHCP OFFER and the DHCP ACK message a so called renewal time is defined. After this time the client needs to renewal his address by the DHCP address renewal.
This is done in 2 Steps.

1. Step: DHCP REQUEST
   The client sends the proposal (his actual IPv4-Address) with a DHCP REQUEST as an Unicast.
2. Step: DHCP ACK
   The server acknowledges the DHCP REQUEST with an Unicast DHCP ACK message.

Points of interest:

• The interested reader may have obeserved that the DHCP OFFER message is send as an Unicast. But the client doesn´t own an IP-Address at that moment. Because the new address is inside the DHCP OFFER. Which the client hasn´t read so far.
  A explanation can be found in RFC 2131 Page 10:

In the case of a client using DHCP for initial configuration (before
the client's TCP/IP software has been completely configured),
DHCP requires creative use of the client's TCP/IP software
and liberalinterpretation of RFC 1122.
The TCP/IP software SHOULD accept and forward to the IP layer any IP packets
delivered to the client's hardware address before the IP address is configured;
DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages toclients
that cannot accept hardware unicast datagrams before the
TCP/IP software is configured.

To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the 'flags' field [21].  The leftmost bit is
defined as the BROADCAST (B) flag.  The semantics of this flag are
discussed in section 4.1 of this document.  The remaining bits of the
flags field are reserved for future use.  They MUST be set to zero by
clients and ignored by servers and relay agents.  Figure 2 gives the
format of the 'flags' field.

1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|             MBZ             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B:  BROADCAST flag

MBZ:  MUST BE ZERO (reserved for future use)

Figure 2:  Format of the 'flags' field

• So we can see that this is a very special design case, that TCP/IP SHOULD accept every IP packet, if no IP address is configured so far and the HW-address of a packet is correct.
• Due to his origin from the Bootstrap protocol the display filter for DHCP in Wireshark is still bootp

Glossary:

BOOTP                 Bootstrap protocol

Broadcast             A transmission for every host in the subnet

Frame                 PDU of the Link Layer

IP Datagram           Unfragmented PDU of the Network Layer
                      (before fragementation or after reassembly)

IP                    IPv4 - Internet Protocol Version 4

IPv4                  IPv4 - Internet Protocol Version 4

IPv6                  Internet Protocol Version 6

DHCP                  Dynamic Host Configuration Protocol

MTU                   Maximum Transmission Unit

Packet                PDU of the Network Layer;
                      IP datagram or a fragment of an IP datagramm
PDU                   Protocol Data Unit

Segment               PDU of the Transport Layer if TCP is in use

Service Data Unit     The PDU of the actual layer 
                      is the SDU of the layer below the actual layer 
                      PDU (n) = SDU ();   n = Actual Layer

Transmission Unit     The Data of the Link Layer

UDP Datagram          PDU of the Transport Layer if UDP is in use