DHCP - IP Assignment Process (DORA)

▶

Steps

setup

Client broadcasts DHCP Discover

The client starts without an IP and broadcasts a DHCP Discover message to find available DHCP servers.

💡 This initial broadcast is how the client announces it needs an IP address.

Line:

send_dhcp_discover()  # Client broadcasts Discover

💡 DHCP Discover is a broadcast message sent by the client to locate DHCP servers.

traverse

Server receives DHCP Discover

The DHCP server receives the Discover message and begins processing the client's request.

💡 The server must listen for Discover messages to know when a client needs an IP.

Line:

receive_dhcp_discover()  # Server receives Discover

💡 The server is now aware of the client's request and will prepare an IP offer.

insert

Server sends DHCP Offer

The server selects an available IP and sends a DHCP Offer message back to the client as a unicast or broadcast.

💡 The Offer message proposes an IP address lease to the client.

Line:

send_dhcp_offer()  # Server sends Offer

💡 The server offers an IP address to the client, starting the lease negotiation.

traverse

Client receives DHCP Offer

The client receives the DHCP Offer and processes the proposed IP address.

💡 The client must receive and evaluate the Offer before requesting the IP.

Line:

receive_dhcp_offer()  # Client receives Offer

💡 The client now knows which IP the server is offering.

insert

Client sends DHCP Request

The client broadcasts a DHCP Request message to accept the offered IP address.

💡 Broadcasting the Request lets all DHCP servers know which offer the client accepted.

Line:

send_dhcp_request()  # Client broadcasts Request

💡 The Request message confirms the client's acceptance of the IP lease.

traverse

Server receives DHCP Request

The server receives the Request and prepares to finalize the IP lease.

💡 The server must confirm the client's acceptance before assigning the IP.

Line:

receive_dhcp_request()  # Server receives Request

💡 The server now knows the client accepted the offered IP.

insert

Server sends DHCP Acknowledge

The server sends a DHCP Acknowledge message to finalize the IP lease assignment.

💡 This message confirms the client can use the assigned IP address.

Line:

send_dhcp_ack()  # Server sends Acknowledge

💡 DHCP Acknowledge completes the lease process, granting the IP to the client.

traverse

Client receives DHCP Acknowledge

The client receives the Acknowledge message and configures its network interface with the assigned IP.

💡 The client can now use the IP address for network communication.

Line:

receive_dhcp_ack()  # Client receives Acknowledge

💡 The client finalizes its IP configuration after receiving the Acknowledge.

reconstruct

Client configures IP address

The client sets its network interface to the assigned IP address and marks the lease as active.

💡 This step completes the DHCP process by enabling the client to communicate on the network.

Line:

configure_ip_address('192.168.1.100')  # Client sets IP

💡 The client is now ready to use the assigned IP for communication.

reconstruct

DHCP process complete

The DHCP client has successfully obtained and configured its IP address, ready for network communication.

💡 This final step confirms the DHCP lease is active and the client is connected.

Line:

# DHCP process complete

💡 The DORA sequence results in dynamic IP assignment without manual configuration.

def dhcp_process():
    # STEP 1
    send_dhcp_discover()  # Client broadcasts Discover
    # STEP 2
    receive_dhcp_discover()  # Server receives Discover
    # STEP 3
    send_dhcp_offer()  # Server sends Offer
    # STEP 4
    receive_dhcp_offer()  # Client receives Offer
    # STEP 5
    send_dhcp_request()  # Client broadcasts Request
    # STEP 6
    receive_dhcp_request()  # Server receives Request
    # STEP 7
    send_dhcp_ack()  # Server sends Acknowledge
    # STEP 8
    receive_dhcp_ack()  # Client receives Acknowledge
    # STEP 9
    configure_ip_address('192.168.1.100')  # Client sets IP
    # STEP 10
    # DHCP process complete

📊

DHCP - IP Assignment Process (DORA) - Watch the Algorithm Execute, Step by Step

Watching the packet flow step-by-step reveals how DHCP dynamically assigns IP addresses, clarifying the roles of each message and the sequence of communication.

Client sends DHCP Discover broadcast to locate DHCP servers.

Hop: 1

Client

DHCP Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadDHCP Discover

🔌 protocolDHCP

🚩 flagsbroadcast

src→0.0.0.0:—

dst→255.255.255.255:67

data→DHCP Discover

flags→broadcast

DHCP Discover: client→server (broadcast)

Server receives and processes DHCP Discover from client.

Hop: 1

Client

DHCP Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadDHCP Discover

🔌 protocolDHCP

🚩 flagsbroadcast

src→0.0.0.0:—

dst→255.255.255.255:67

data→DHCP Discover

flags→broadcast

DHCP Discover: client→server (broadcast)

Server sends DHCP Offer proposing IP 192.168.1.100 to client.

Hop: 2

Client

DHCP Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadDHCP Offer (IP: 192.168.1.100)

🔌 protocolDHCP

🚩 flagsunicast

src→192.168.1.1:67

dst→255.255.255.255:68

data→DHCP Offer (IP: 192.168.1.100)

flags→unicast

DHCP Discover: client→server (broadcast)

DHCP Offer: server→client (unicast)

Client receives and processes DHCP Offer from server.

Hop: 2

Client

DHCP Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadDHCP Offer (IP: 192.168.1.100)

🔌 protocolDHCP

🚩 flagsunicast

src→192.168.1.1:67

dst→255.255.255.255:68

data→DHCP Offer (IP: 192.168.1.100)

flags→unicast

DHCP Discover: client→server (broadcast)

DHCP Offer: server→client (unicast)

Client broadcasts DHCP Request to accept offered IP.

Hop: 3

Client

DHCP Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadDHCP Request (IP: 192.168.1.100)

🔌 protocolDHCP

🚩 flagsbroadcast

src→0.0.0.0:—

dst→255.255.255.255:67

data→DHCP Request (IP: 192.168.1.100)

flags→broadcast

DHCP Discover: client→server (broadcast)

DHCP Offer: server→client (unicast)

DHCP Request: client→server (broadcast)

Server receives DHCP Request confirming client's acceptance.

Hop: 3

Client

DHCP Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadDHCP Request (IP: 192.168.1.100)

🔌 protocolDHCP

🚩 flagsbroadcast

src→0.0.0.0:—

dst→255.255.255.255:67

data→DHCP Request (IP: 192.168.1.100)

flags→broadcast

DHCP Discover: client→server (broadcast)

DHCP Offer: server→client (unicast)

DHCP Request: client→server (broadcast)

Server sends DHCP Acknowledge to finalize IP lease.

Hop: 4

Client

DHCP Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadDHCP Acknowledge (IP: 192.168.1.100)

🔌 protocolDHCP

🚩 flagsunicast

src→192.168.1.1:67

dst→192.168.1.100:68

data→DHCP Acknowledge (IP: 192.168.1.100)

flags→unicast

DHCP Offer: server→client (unicast)

DHCP Request: client→server (broadcast)

DHCP Acknowledge: server→client (unicast)

Client receives DHCP Acknowledge and configures IP.

Hop: 4

Client

DHCP Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadDHCP Acknowledge (IP: 192.168.1.100)

🔌 protocolDHCP

🚩 flagsunicast

src→192.168.1.1:67

dst→192.168.1.100:68

data→DHCP Acknowledge (IP: 192.168.1.100)

flags→unicast

DHCP Offer: server→client (unicast)

DHCP Request: client→server (broadcast)

DHCP Acknowledge: server→client (unicast)

Client configures assigned IP and completes DHCP process.

Hop: 4

Client (IP: 192.168.1.100)

DHCP Server

DHCP Offer: server→client (unicast)

DHCP Request: client→server (broadcast)

DHCP Acknowledge: server→client (unicast)

DHCP IP assignment process completed successfully.

Hop: 4

Client (IP: 192.168.1.100)

DHCP Server

DHCP Offer: server→client (unicast)

DHCP Request: client→server (broadcast)

DHCP Acknowledge: server→client (unicast)

Key Takeaways

✓ DHCP uses a four-message DORA sequence to dynamically assign IP addresses.

This sequence is hard to grasp from code alone because it involves multiple message types and broadcast vs unicast nuances.

✓ Broadcast messages are used initially to discover servers and request IPs, ensuring all servers hear the client.

Visualizing broadcast vs unicast clarifies why some messages go to all and others directly to one node.

✓ The final DHCP Acknowledge confirms the lease, allowing the client to configure its IP address.

Seeing the Acknowledge message flow and client state change makes the lease finalization concrete.

Practice

1. You want to prevent unauthorized access to your internal network by filtering incoming and outgoing traffic based on IP addresses and ports. Which network component is best suited for this task?

easy

A. Proxy server acting as an intermediary for client requests

B. Firewall filtering traffic based on rules

C. Reverse proxy optimizing server load

D. Content Delivery Network (CDN) caching static content

Solution

1. Step 1: Identify the role of each component

   Firewalls are designed to filter network traffic based on IP addresses, ports, and protocols, enforcing security policies.

2. Step 2: Understand Proxy and Reverse Proxy roles

   Proxies forward client requests but do not primarily filter traffic at the network level; reverse proxies handle server-side requests and optimize load.

3. Step 3: CDN role

   CDNs cache content to improve performance but do not filter traffic for security.

4. Final Answer:

   Option B -> Option B

5. Quick Check:

   Firewall is the component that filters traffic based on rules [OK]

Hint: Firewall filters traffic; proxies forward requests.

Common Mistakes:

• Confusing proxy with firewall as a security filter
• Assuming reverse proxy filters traffic like a firewall

2. In which scenario would you most likely use CIDR notation instead of traditional classful addressing?

easy

A. When you want to efficiently allocate IP addresses to networks of varying sizes without wasting addresses

B. When you want to separate the network and host portions strictly by the first octet

C. When you need to allocate IP addresses in fixed blocks of Class A, B, or C sizes

D. When you want to assign IP addresses only within Class C networks

Solution

1. Step 1: Understand classful addressing limitations

   Classful addressing allocates IP blocks in fixed sizes (Class A, B, C), often wasting many IP addresses.

2. Step 2: Recognize CIDR's flexibility

   CIDR allows variable-length subnet masks, enabling allocation of IP blocks tailored to network size, reducing waste.

3. Step 3: Evaluate options

   When you need to allocate IP addresses in fixed blocks of Class A, B, or C sizes describes classful allocation, not CIDR. When you want to separate the network and host portions strictly by the first octet is about classful fixed boundaries. When you want to assign IP addresses only within Class C networks restricts to Class C, which CIDR overcomes.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   CIDR is used for efficient IP allocation across variable network sizes [OK]

Hint: CIDR = flexible IP blocks, classful = fixed blocks

Common Mistakes:

• Believing CIDR only applies to Class C networks
• Thinking CIDR is just a different notation without functional difference
• Assuming classful addressing is still standard for IP allocation

3. Why is it generally not advisable to set a fixed Retransmission Timeout (RTO) value in TCP instead of using an adaptive algorithm?

medium

A. Because fixed RTO values prevent the sender from using sequence numbers effectively

B. Because fixed RTO values increase the TCP header size, reducing throughput

C. Because fixed RTO values cause the receiver to drop out-of-order packets more frequently

D. Because a fixed RTO cannot adjust to varying network delays, leading to either premature retransmissions or long delays

Solution

1. Step 1: Understand RTO purpose

   RTO determines when the sender retransmits unacknowledged segments, ideally matching network delay.

2. Step 2: Analyze fixed vs adaptive RTO

   Fixed RTO cannot adapt to changing RTTs, causing retransmissions either too early (wasting bandwidth) or too late (increasing latency).

3. Step 3: Evaluate options

   Because fixed RTO values prevent the sender from using sequence numbers effectively is incorrect; sequence number usage is unaffected by RTO. Because fixed RTO values increase the TCP header size, reducing throughput is false; RTO does not affect header size. Because fixed RTO values cause the receiver to drop out-of-order packets more frequently is unrelated to RTO. Because a fixed RTO cannot adjust to varying network delays, leading to either premature retransmissions or long delays correctly identifies the main drawback.

4. Final Answer:

   Option D -> Option D

5. Quick Check:

   Adaptive RTO improves efficiency by matching network conditions.

Hint: Adaptive RTO matches RTT; fixed RTO causes inefficiency.

Common Mistakes:

• Believing fixed RTO affects TCP header size
• Confusing RTO with receiver packet handling
• Assuming RTO impacts sequence number usage

4. If a company wants to improve both security and performance for a public-facing web application, which combined deployment of firewall, proxy, and reverse proxy is most effective?

hard

A. Deploy a proxy server between backend servers and clients without a firewall

B. Use only a reverse proxy to handle all security filtering and caching

C. Rely solely on a firewall to filter traffic and improve performance

D. Deploy a firewall at the network edge, a forward proxy for client requests, and a reverse proxy in front of backend servers

Solution

1. Step 1: Firewall role

   Firewall at network edge filters unauthorized traffic, providing security.

2. Step 2: Forward proxy role

   Forward proxy manages client requests, can enforce policies and cache content.

3. Step 3: Reverse proxy role

   Reverse proxy protects backend servers, performs load balancing, SSL termination, and caching.

4. Step 4: Evaluate other options

   Only reverse proxy (B) or only firewall (C) miss layered defense and performance optimization; no firewall (A) reduces security.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   Combined deployment leverages strengths of all components [OK]

Hint: Layered defense: firewall + proxies for security and performance.

Common Mistakes:

• Assuming one component can handle all roles
• Ignoring the need for firewall in security

5. If a new network protocol requires encryption and compression before data transmission, which TCP/IP model layer would be the best place to implement these features to maintain compatibility and efficiency?

hard

A. Network Interface Layer, since it deals with physical transmission

B. Transport Layer, because it manages data segmentation and reliability

C. Internet Layer, as it routes packets across networks

D. Application Layer, since it handles end-user protocols and data formatting

Solution

1. Step 1: Identify layer responsibilities relevant to encryption and compression

   Encryption and compression are data transformations related to how data is presented and formatted for applications, which fits the Application Layer's role in TCP/IP (combining OSI's Application, Presentation, and Session layers).

2. Step 2: Why not other layers?

   Transport Layer manages segmentation and reliability, not data formatting. Internet Layer handles routing, not data content. Network Interface Layer deals with physical transmission, not data processing.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   Application Layer is the correct place for encryption/compression to maintain compatibility [OK]

Hint: Encryption/compression belong at Application Layer in TCP/IP

Common Mistakes:

• Placing encryption at Transport Layer (confusing with TLS)
• Thinking Internet Layer handles data content
• Assuming Network Interface Layer manages data transformations