1 ADDRESS RESOLUTION PROTOCOL (ARP) & REVERSE ADDRESS RESOLUTION PROTOCOL ( RARP) K. PALANIVEL Systems Analyst, Computer Centre Pondicherry University, Puducherry – LECTURE 5 COMS 525: TCPIP COURSE TOPIC

Discussion Understand the need for ARP Understand the cases in which ARP is used Understand the components and interactions in an ARP package Understand the need for RARP

Communication between Hosts Example From Host A to Host B From Host B to Host A

Address Mapping The delivery of a packet to a host or a router requires two levels of addressing: logical and physical. It needs to be able to map a logical address to its corresponding physical address and vice versa. These can be done using either static or dynamic mapping.

Address Mapping Anytime a host or a router has an IP datagram to send to another host or router, it has the logical (IP) address of the receiver. But the IP datagram must be encapsulated in a frame to be able to pass through the physical network. This means that the sender needs the physical address of the receiver. A mapping corresponds a logical address to a physical address. ARP accepts a logical address from the IP protocol, maps the address to the corresponding physical address and pass it to the data link layer.

Address Mapping

Overview

ARP and RARP – The Internet is based on IP addresses – Data link protocols (Ethernet, FDDI, ATM) may have different (MAC) addresses The ARP and RARP protocols perform the translation between IP addresses and MAC layer addresses ARP for broadcast LANs, particularly Ethernet LANs

Processing of IP packets by network device drivers

Address Translation with ARP ARP Request: Sender broadcasts an ARP request to all stations on the network: What is the hardware address of Router137?

Address Translation with ARP DCHP Server

ARP Operations broadcast

Address Translation with ARP ARP Reply: Router 137 responds with an ARP Reply which contains the hardware address

ARP Packet Format

ARP Encapsulation An ARP request is broadcast; An ARP reply is unicast.

ARP Encapsulation ARP RequestARP Reply ARP Payload ARP ReplyPayload

ARP Encapsulation

ARP request and reply packets. Note that the ARP data field in this case is 28 bytes, and that the individual addresses do not fit in the 4- byte boundary. That is why we do not show the regular 4-byte boundaries for these addresses. Also note that the IP addresses are shown in hexadecimal.

Example ARP Request from Argon: Source hardware address: 00:a0:24:71:e4:44 Source protocol address: Target hardware address: 00:00:00:00:00:00 Target protocol address: ARP Reply from Router137: Source hardware address: 00:e0:f9:23:a8:20 Source protocol address: Target hardware address: 00:a0:24:71:e4:44 Target protocol address:

Four Cases on ARP

Example

A host with IP address and physical address B2:34:55:10:22:10 has a packet to send to another host with IP address and physical address A4:6E:F4:59:83:AB. The two hosts are on the same Ethernet network. Show the ARP request and reply packets encapsulated in Ethernet frames.

Example Solution Figure 8.6 shows the ARP request and reply packets. Note that the ARP data field in this case is 28 bytes, and that the individual addresses do not fit in the 4-byte boundary. That is why we do not show the regular 4-byte boundaries for these addresses. Also note that the IP addresses are shown in hexadecimal.

ARP Cache Since sending an ARP request/reply for each IP datagram is inefficient, hosts maintain a cache (ARP Cache) of current entries. The entries expire after 20 minutes. Contents of the ARP Cache: ( ) at 00:10:4B:C5:D1:15 [ether] on eth0 ( ) at 00:B0:D0:E1:17:D5 [ether] on eth0 ( ) at 00:B0:D0:DE:70:E6 [ether] on eth0 ( ) at 00:05:3C:06:27:35 [ether] on eth1 ( ) at 00:B0:D0:E1:17:DB [ether] on eth0 ( ) at 00:B0:D0:E1:17:DF [ether] on eth0

ARP Caching The ARP output module receives an IP datagram (from the IP layer) with the destination address It checks the cache table and finds that an entry exists for this destination with the RESOLVED state (R in the table). It extracts the hardware address, which is ACAE32, and sends the packet and the address to the data link layer for transmission. The cache table remains the same.

ARP Caching Twenty seconds later, the ARP output module receives an IP datagram (from the IP layer) with the destination address It checks the cache table and does not find this destination in the table. The module adds an entry to the table with the state PENDING and the Attempt value 1. It creates a new queue for this destination and enqueues the packet. It then sends an ARP request to the data link layer for this destination. The new cache table is shown in Table

ARP Caching Fifteen seconds later, the ARP input module receives an ARP packet with target protocol (IP) address The module checks the table and finds this address. It changes the state of the entry to RESOLVED and sets the time-out value to 900. The module then adds the target hardware address (E ACA) to the entry. Now it accesses queue 18 and sends all the packets in this queue, one by one, to the data link layer. The new cache table is shown in Table 8.7.

ARP Caching Twenty-five seconds later, the cache-control module updates every entry. The time-out values for the first three resolved entries are decremented by 60. The time-out value for the last resolved entry is decremented by 25. The state of the next-to-the last entry is changed to FREE because the time-out is zero. For each of the three pending entries, the value of the attempts field is incremented by one. After incrementing, the attempts value for one entry (the one with IP address ) is more than the maximum; the state is changed to FREE, the queue is deleted, and an ICMP message is sent to the original destination (see Chapter 9). See Table 8.8.

ARP Caching

Proxy ARP Proxy ARP: Host or router responds to ARP Request that arrives from one of its connected networks for a host that is on another of its connected networks.

Proxy ARP

Example Solution

Switch Lookup Table

Things to know about ARP What happens if an ARP Request is made for a non-existing host? Several ARP requests are made with increasing time intervals between requests. Eventually, ARP gives up. On some systems (including Linux) a host periodically sends ARP Requests for all addresses listed in the ARP cache. This refreshes the ARP cache content, but also introduces traffic. Gratuitous ARP Requests: A host sends an ARP request for its own IP address: Useful for detecting if an IP address has already been assigned.

Vulnerabilities of ARP 1.Since ARP does not authenticate requests or replies, ARP Requests and Replies can be forged 2.ARP is stateless: ARP Replies can be sent without a corresponding ARP Request 3.According to the ARP protocol specification, a node receiving an ARP packet (Request or Reply) must update its local ARP cache with the information in the source fields, if the receiving node already has an entry for the IP address of the source in its ARP cache. (This applies for ARP Request packets and for ARP Reply packets) Typical exploitation of these vulnerabilities: A forged ARP Request or Reply can be used to update the ARP cache of a remote system with a forged entry (ARP Poisoning) This can be used to redirect IP traffic to other hosts

Components of ARP

RARP RARP finds the logical address for a machine that only knows its physical address. RARP finds the logical address for a machine that only knows its physical address. The RARP request packets are broadcast; the RARP reply packets are unicast.

RARP Bootstrapping a diskless terminal - this was the original problem in the 70s and 80s Reverse ARP [RFC903] - a way to obtain an IP address starting from MAC address Today problem: dynamic IP address assignment - limited pool of addresses assigned only when needed RARP not sufficiently general for modern usage – BOOTP (Bootstrap Protocol - RFC 951): significant changes to RARP (a different approach) – DHCP (Dynamic Host Configuration Protocol - RFC 1541): extends and replaces BOOTP

RARP

RARP Client RARP Server

RARP

RARP Problems Network traffic – for reliability, multiple RARP servers need to be configured on the same Ethernet – to allow bootstrap of terminals even when one server is down – But this implies that ALL servers simultaneously respond to RARP request contention on the Ethernet occurs ÎRARP requests not forwarded by routers – being hardware level broadcasts...

BOOTP/DHCP approach Requests/replies encapsulated in UDP datagrams – may cross routers – no more dependent on physical medium request addressing: – destination IP = – source IP = – destination port (BOOTP): 67 – source port (BOOTP): 68 router crossing: – router configured as BOOTP relay agent – forwards broadcast UDP requests with destination port 67

QUESTIONS ???