ARP - Address Resolution Protocol, ARP Cache & Spoofing

▶

Steps

setup

Initialize ARP Cache and Network Nodes

The host initializes its ARP cache as empty and sets up the network nodes: Client (Host A), Router, and Server (Host B). No packets are in transit yet.

💡 Initialization is crucial to understand the starting point where no MAC address mappings exist, so ARP resolution is necessary.

Line:

arp_cache = {}
client = Node('client')
router = Node('router')
server = Node('server')

💡 The ARP cache starts empty, so the host must send an ARP request to resolve the MAC address.

compare

Host A Checks ARP Cache for Host B's MAC

Host A looks up Host B's IP address in its ARP cache but finds no entry. It decides to send an ARP request broadcast.

💡 This cache lookup step is key to avoid unnecessary ARP requests if the MAC is already known.

Line:

if target_ip not in arp_cache:
    send_arp_request()

💡 The absence of a cache entry triggers the ARP request broadcast to discover the MAC address.

insert

Host A Broadcasts ARP Request

Host A creates and broadcasts an ARP request packet asking 'Who has IP 192.168.1.3? Tell 192.168.1.2'. The packet is sent from Host A to all nodes on the local network.

💡 Broadcasting the ARP request is how a host discovers the MAC address of a target IP on the local network.

Line:

arp_request = create_arp_request(src_ip, target_ip)
broadcast_packet(arp_request)

💡 The ARP request is a broadcast packet that all nodes receive, but only the owner of the target IP replies.

compare

Host B Receives ARP Request and Recognizes Its IP

Host B receives the ARP request and checks if the requested IP matches its own. It finds a match and prepares to send an ARP reply.

💡 This step shows how only the host owning the requested IP responds to the ARP request.

Line:

if arp_request.target_ip == host_ip:
    send_arp_reply()

💡 The ARP reply is unicast back to the requester with the MAC address of Host B.

insert

Host B Sends ARP Reply to Host A

Host B sends a unicast ARP reply packet to Host A containing its MAC address, answering the request.

💡 The ARP reply provides the MAC address needed for Host A to send packets directly to Host B.

Line:

arp_reply = create_arp_reply(host_b_mac, host_b_ip, host_a_ip)
send_packet(arp_reply, dest=host_a_mac)

💡 The ARP reply is unicast directly to the requester, not broadcast.

insert

Host A Receives ARP Reply and Updates Cache

Host A receives the ARP reply and updates its ARP cache with the IP-to-MAC mapping for Host B.

💡 Updating the ARP cache avoids future broadcasts for the same IP, improving efficiency.

Line:

arp_cache[target_ip] = mac_address_from_reply

💡 The ARP cache now contains the resolved MAC address, enabling direct communication.

insert

Host A Sends Data Packet to Host B Using Resolved MAC

With the MAC address resolved, Host A sends the actual data packet directly to Host B's MAC address.

💡 This step shows the purpose of ARP: enabling direct Layer 2 communication after MAC resolution.

Line:

send_packet(data_packet, dest=arp_cache[target_ip])

💡 The data packet is sent unicast using the resolved MAC, avoiding broadcast.

traverse

Host B Receives Data Packet

Host B receives the data packet sent by Host A and processes it accordingly.

💡 This final step confirms successful communication after ARP resolution.

Line:

process_packet(received_packet)

💡 The data packet reaches the intended host using the MAC address resolved by ARP.

reconstruct

Host A ARP Cache After Resolution

Host A's ARP cache now contains the mapping from Host B's IP to its MAC address, ready for future packets.

💡 This cache state prevents repeated ARP requests for the same IP, improving network efficiency.

Line:

print(arp_cache)

💡 The ARP cache stores IP-to-MAC mappings learned from ARP replies.

reconstruct

Summary: ARP Resolution Complete

The ARP resolution process is complete. Host A can now communicate directly with Host B using the resolved MAC address stored in its ARP cache.

💡 This final step consolidates the entire ARP mechanism from request to cache update and data transmission.

Line:

# ARP resolution cycle complete

💡 Understanding this cycle is fundamental to grasping how IP and MAC addresses interact in local networks.

arp_cache = {}  # STEP 1: Initialize ARP cache

client_ip = '192.168.1.2'
target_ip = '192.168.1.3'

# STEP 2: Check ARP cache
if target_ip not in arp_cache:
    # STEP 3: Send ARP request broadcast
    arp_request = f"Who has {target_ip}? Tell {client_ip}"
    print('Broadcast ARP request:', arp_request)
    # STEP 4: Host B receives request and checks IP
    host_b_ip = '192.168.1.3'
    if target_ip == host_b_ip:
        # STEP 5: Host B sends ARP reply
        host_b_mac = '00:11:22:33:44:55'
        arp_reply = f"{target_ip} is at {host_b_mac}"
        print('Send ARP reply:', arp_reply)
        # STEP 6: Host A receives reply and updates cache
        arp_cache[target_ip] = host_b_mac
        print('ARP cache updated:', arp_cache)
        # STEP 7: Host A sends data packet
        print(f'Send data packet to {host_b_mac}')
        # STEP 8: Host B receives data packet
        print('Host B received data packet')

# STEP 9: Print final ARP cache
print('Final ARP cache:', arp_cache)

# STEP 10: ARP resolution complete
print('ARP resolution process complete')

📊

ARP - Address Resolution Protocol, ARP Cache & Spoofing - Watch the Algorithm Execute, Step by Step

Watching this step-by-step packet flow is the fastest way to understand ARP because it reveals the exact message exchanges and cache state changes that are otherwise abstract in code or theory.

ARP cache initialized empty; network nodes ready.

Hop: 0

Host A

Router

Host B

Cache miss detected; preparing ARP request broadcast.

Hop: 0

Host A

Router

Host B

src→192.168.1.2:—

dst→192.168.1.3:—

ARP cache lookup: Host B IP not found

ARP request broadcast packet created and sent.

Hop: 1

Host A

Router

Host B

📦Packet

↗ fromclient

↘ tobroadcast

📄 payloadARP Request: Who has 192.168.1.3? Tell 192.168.1.2

🔌 protocolARP

🚩 flagsbroadcast

src→192.168.1.2:—

dst→255.255.255.255:—

data→Who has 192.168.1.3? Tell 192.168.1.2

flags→broadcast

ARP cache lookup: Host B IP not found

ARP request broadcast sent by Host A

Host B recognizes its IP in ARP request and prepares reply.

Hop: 2

Host A

Router

Host B

📦Packet

↗ fromrouter

↘ toserver

📄 payloadARP Request: Who has 192.168.1.3? Tell 192.168.1.2

🔌 protocolARP

🚩 flagsbroadcast

src→192.168.1.2:—

dst→255.255.255.255:—

data→Who has 192.168.1.3? Tell 192.168.1.2

flags→broadcast

ARP cache lookup: Host B IP not found

ARP request broadcast sent by Host A

ARP request received by Host B

ARP reply packet created and sent unicast to Host A.

Hop: 3

Host A

Router

Host B

📦Packet

↗ fromserver

↘ toclient

📄 payloadARP Reply: 192.168.1.3 is at MAC 00:11:22:33:44:55

🔌 protocolARP

🚩 flags

src→192.168.1.3:—

dst→192.168.1.2:—

data→MAC 00:11:22:33:44:55

ARP request broadcast sent by Host A

ARP request received by Host B

ARP reply sent by Host B to Host A

Host A ARP cache updated with Host B's MAC address.

Hop: 4

Host A

Router

Host B

src→192.168.1.3:—

dst→192.168.1.2:—

data→MAC 00:11:22:33:44:55

ARP request received by Host B

ARP reply sent by Host B to Host A

ARP reply received by Host A; cache updated

Data packet sent using MAC address resolved by ARP.

Hop: 5

Host A

Router

Host B

📦Packet

↗ fromclient

↘ toserver

📄 payloadData Packet

🔌 protocolIP

🚩 flags

src→192.168.1.2:12345

dst→192.168.1.3:80

data→HTTP GET /

ARP reply sent by Host B to Host A

ARP reply received by Host A; cache updated

Data packet sent from Host A to Host B using resolved MAC

Host B received and is processing the data packet.

Hop: 6

Host A

Router

Host B

src→192.168.1.2:12345

dst→192.168.1.3:80

data→HTTP GET /

ARP reply received by Host A; cache updated

Data packet sent from Host A to Host B using resolved MAC

Data packet received by Host B

ARP cache at Host A updated with Host B's MAC address.

Hop: 7

Host A

Router

Host B

Data packet sent from Host A to Host B using resolved MAC

Data packet received by Host B

ARP cache at Host A: 192.168.1.3 → 00:11:22:33:44:55

ARP resolution cycle finished; Host A ready for direct communication.

Hop: 7

Host A

Router

Host B

Data packet received by Host B

ARP cache at Host A: 192.168.1.3 → 00:11:22:33:44:55

ARP resolution process complete

Key Takeaways

✓ ARP resolves IP addresses to MAC addresses by broadcasting requests and receiving targeted replies.

This insight is hard to see from code alone because the broadcast and unicast nature of ARP packets is implicit, but the visualization shows it explicitly.

✓ The ARP cache stores resolved mappings to avoid repeated broadcasts, improving network efficiency.

Seeing the cache update and lookup visually clarifies why ARP cache is critical for performance.

✓ Only the host owning the requested IP responds to ARP requests, ensuring correct MAC resolution.

The decision to reply or ignore is a key branching point that the visualization highlights clearly.

Practice

1. In which scenario is the TCP sequence number most critical for ensuring reliable data transfer?

easy

A. When the receiver needs to reorder out-of-sequence packets before delivering data to the application

B. When the sender wants to detect duplicate acknowledgments to trigger fast retransmission

C. When the receiver uses it to calculate the retransmission timeout (RTO)

D. When the sender uses it to encrypt the data payload for security

Solution

1. Step 1: Understand the role of TCP sequence numbers in packet ordering

   TCP sequence numbers uniquely identify bytes in the data stream, allowing the receiver to reorder packets that arrive out of order.

2. Step 2: Analyze each option

   When the receiver needs to reorder out-of-sequence packets before delivering data to the application is correct because reordering depends on sequence numbers. When the sender wants to detect duplicate acknowledgments to trigger fast retransmission relates to ACKs, not sequence numbers directly. When the receiver uses it to calculate the retransmission timeout (RTO) is incorrect because RTO calculation uses RTT estimates, not sequence numbers. When the sender uses it to encrypt the data payload for security is unrelated to sequence numbers.

3. Final Answer:

   Option A -> Option A

4. Quick Check:

   Sequence numbers enable ordering, not encryption or RTO calculation.

Hint: Sequence numbers order bytes; ACKs confirm receipt.

Common Mistakes:

• Confusing sequence numbers with ACK numbers
• Thinking sequence numbers affect RTO calculation
• Assuming sequence numbers relate to encryption

2. In which scenario is the TCP three-way handshake essential before data transmission begins?

easy

A. When broadcasting a message to multiple hosts on a local network

B. When establishing a reliable connection-oriented session between two hosts

C. When sending a single UDP datagram to a remote host

D. When encrypting data packets for secure transmission

Solution

1. Step 1: Identify the purpose of the handshake

   The TCP three-way handshake is designed to establish a reliable, connection-oriented session between two hosts before data transfer.

2. Step 2: Analyze each option

   Sending a single UDP datagram to a remote host is incorrect because UDP is connectionless and does not use a handshake. Broadcasting a message to multiple hosts on a local network is incorrect because broadcasting does not require connection establishment. Encrypting data packets for secure transmission is unrelated to connection setup; encryption is a separate process.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   Only TCP connections require this handshake to ensure reliability and synchronization.

Hint: TCP handshake = reliable connection setup, not for UDP or broadcast

Common Mistakes:

• Confusing TCP handshake with UDP communication
• Assuming handshake is needed for broadcast or encryption

3. Trace the sequence of packets exchanged during the TCP three-way handshake when a client initiates a connection to a server.

easy

A. Client sends ACK, Server replies with SYN, Client sends SYN-ACK

B. Client sends SYN-ACK, Server replies with ACK, Client sends SYN

C. Client sends SYN, Server replies with SYN-ACK, Client sends ACK

D. Client sends SYN, Server replies with ACK, Client sends SYN-ACK

Solution

1. Step 1: Understand the handshake steps

   The client initiates by sending a SYN packet to request connection. The server responds with SYN-ACK to acknowledge and synchronize. The client completes with ACK.

2. Step 2: Evaluate each option

   Client sends SYN, Server replies with SYN-ACK, Client sends ACK correctly follows the SYN -> SYN-ACK -> ACK sequence. Options A, C, and D have the order or packet types mixed up, which breaks the handshake protocol.

3. Final Answer:

   Option C -> Option C

4. Quick Check:

   Remember the handshake as "SYN, SYN-ACK, ACK" in that order.

Hint: Handshake order: SYN -> SYN-ACK -> ACK

Common Mistakes:

• Mixing up who sends SYN-ACK or ACK first
• Assuming ACK comes before SYN-ACK

4. You are designing a live video streaming app where minimal delay is critical, and occasional frame loss is acceptable. Which transport protocol is most suitable?

easy

A. TCP, because it uses congestion control to avoid packet loss

B. TCP, because it guarantees delivery and order of packets

C. UDP, because it provides faster transmission without waiting for acknowledgments

D. UDP, because it establishes a connection before sending data

Solution

1. Step 1: Identify the key requirement -- minimal delay with acceptable occasional loss

   Live video streaming prioritizes speed over perfect reliability.

2. Step 2: Analyze TCP characteristics

   TCP guarantees delivery and order but introduces delay due to acknowledgments and retransmissions.

3. Step 3: Analyze UDP characteristics

   UDP is connectionless and does not wait for acknowledgments, enabling faster transmission at the cost of possible packet loss.

4. Step 4: Evaluate options

   UDP, because it provides faster transmission without waiting for acknowledgments correctly matches the scenario needs. TCP options prioritize reliability over speed. UDP does not establish a connection before sending data, so that option is incorrect.

5. Final Answer:

   Option C -> Option C

6. Quick Check:

   UDP is preferred for real-time applications where speed matters more than reliability.

Hint: Use UDP for speed when some loss is okay; TCP for reliability when loss is not acceptable.

Common Mistakes:

• Assuming TCP is always better because it guarantees delivery
• Believing UDP establishes a connection like TCP
• Confusing congestion control with speed priority

5. If a domain's authoritative DNS server is down, which of the following best describes how DNS resolution behaves assuming the recursive resolver has a cached entry with a TTL of 300 seconds that expired 10 seconds ago?

hard

A. The recursive resolver will attempt to query the authoritative server despite the expired TTL and return an error if unreachable.

B. The recursive resolver will return the expired cached record to the client to avoid resolution failure.

C. The recursive resolver will immediately return a SERVFAIL error to the client since the authoritative server is unreachable.

D. The recursive resolver will query the root server again to find an alternative authoritative server.

Solution

1. Step 1: Understand TTL expiration

   Once TTL expires, cached records are considered stale and should not be served without validation.

2. Step 2: Behavior on authoritative server failure

   The recursive resolver tries to refresh the record by querying the authoritative server.

3. Step 3: Outcome if authoritative server is down

   If unreachable, the resolver returns an error (e.g., SERVFAIL) to the client.

4. Step 4: Why other options are incorrect

   The recursive resolver will immediately return a SERVFAIL error to the client since the authoritative server is unreachable ignores retry attempt; The recursive resolver will return the expired cached record to the client to avoid resolution failure violates TTL rules by serving expired data; The recursive resolver will query the root server again to find an alternative authoritative server is incorrect because root servers do not provide alternative authoritative servers.

5. Final Answer:

   Option A -> Option A

6. Quick Check:

   Expired TTL triggers retry; failure returns error -> correct

Hint: Expired TTL means resolver must retry; failure leads to error, not stale data.

Common Mistakes:

• Assuming expired cache is always served
• Thinking root servers provide alternative authoritative servers
• Believing resolver returns error immediately without retry