Transcript ARP

CSC/ECE 573
Internet Protocols
ARP, RARP
Address Resolution Problem
Higher-level applications should work only with IP
addresses


illusion of a single, virtual network
Communication is carried out by physical networks
IP datagrams are encapsulated in MAC frames 
MAC (hardware) addresses are needed
Address resolution problem: mapping high-level (IP)
addresses to physical (MAC) addresses

“Last net” problem
Solutions
1.
Direct mapping: function f maps IP addresses to
hardware addresses


2.
Configuration file provides the mapping


3.
computation of f must be efficient
works well when physical addresses are small and
configurable
not scalable
not easy to update
Dynamic binding: ARP (RFC 826)


for broadcast networks such as Ethernet, Token Ring, etc.
(why not just broadcast all packets?)
ARP vs. RARP
ARP Operation
ARP Packet Format
(Ethernet frame type= 0x0806)
(Reminder: Ethernet Frame Format)
Using ARP: Case 1
Using ARP: Case 2
Using ARP: Case 3
Using ARP: Case 4
ARP Cache
Sending n packets to destination x: n ARP Requests?



Inefficient; one ARP Request per data packet!
Better: cache ARP Replies
Also, upon receipt of an ARP Request, all machines update
their cache entry for the sender of the request
Problems with caching



cache space may be limited
hosts move or change IP addresses
solution: drop (invalidate) cache entries after “a while” (20
minutes)
Gratuitous ARP
Every machine (should) broadcast its
mapping when it boots


use ARP Request with own IP address as the
target IP address
what should happen if an ARP Reply is received?
The arp Command
Used to query or update the ARP cache
Forms
 arp hostname
 arp -a
 arp -d hostname
 arp -f filename
 arp -s hostname ether_address [ temp ] [ pub ] [
trail ] P
Flags
 P = Publish; ARP will respond to ARP requests for this address
 S = Static; not learned from the ARP protocol.
 U= Unresolved; waiting for ARP response.
 (M = Mapping; only used for multicast entries)
ARP Cache Contents Example
Net to Media Table
Device
IP Address
Mask
Flags
Phys Addr
------ -------------------- --------------- ----- -------------le0
le0
le0
le0
le0
le0
le0
le0
le0
eos03ro.eos.ncsu.edu 255.255.255.255
perch.cacc.ncsu.edu 255.255.255.255
shrimp.cacc.ncsu.edu 255.255.255.255
bass.cacc.ncsu.edu
255.255.255.255
multimedia
255.255.255.255
aphrodite
255.255.255.255
artemis
255.255.255.255
athena
255.255.255.255
BASE-ADDRESS.MCAST.NET 240.0.0.0
SM
00:d0:bc:ed:23:64
08:00:20:73:95:ab
08:00:20:90:a3:7f
08:00:20:73:98:c4
08:00:5a:8a:0c:79
08:00:20:87:be:54
08:00:20:87:bc:d4
08:00:20:21:87:4c
01:00:5e:00:00:00
ARP Protocol Design
(Simplified, bare-bones ARP only; no errorchecking, error-handling, packet validation,
etc.)
Three modules:



Output module
Input Module
Cache-control module
State of cache table entries: FREE,
PENDING, RESOLVED
ARP Output Module
(resolving an IP transmit request)
sleep until IP packet with destination IP address D is received
check cache table for entry corresponding to IP address D
if (not found)
create a queue, enqueue packet
create cache entry with state set to PENDING
send ARP Request, ATTEMPTS  1; return
if (found and state=PENDING)
enqueue packet; return
if (found and state=RESOLVED)
extract value of hardware address from entry
send packet; return
ARP Input Module
(responding to ARP messages)
sleep until ARP packet (Request or Reply) arrives
check cache table for entry corresponding to this ARP packet
if (found and state=RESOLVED)
update the entry (why?)
if (found and state=PENDING)
update the entry
while (there are matching packets in the queue)
dequeue and send a matching packet
if (not found)
create an entry for this ARP packet
if (packet is an ARP request and I am the target)
send an ARP reply
return
ARP Cache-Control Module
sleep until periodic timer expires
for each entry in the cache table
if (state=FREE) continue
if (state=PENDING)
ATTEMPTS += 1
if (ATTEMPTS  MAX_ATTEMPTS)
send ARP Request
else
change state to FREE; destroy queue
if (state=RESOLVED)
decrement time-out value by value of elapsed time
if (time-out  0)
change state to FREE; destroy queue
return
Proxy ARP
Proxy ARP
Maps single IP net prefix into two or more physical
addresses
Router answers ARP requests for H3 or H4 from H1 or H2
with its own hardware address
Properties



Assumes trusting relationship
Simple: only requires changes to a single router
Only works for broadcast networks
More details: see
http://www.linuxdoc.org/HOWTO/mini/Proxy-ARP-Subnet/
Diskless workstations (Web PCs):
Small startup program in ROM


startup program cannot contain machine's IP
address
(why not?)
Startup program is used to obtain:



machine's IP address
IP address of file server and of nearest router
initial boot image to execute
Reverse ARP
RARP
One or more RARP servers store IP addresses for
hosts on their network
A diskless client uses physical network addressing to
obtain its IP address from the server(s)


RARP Request is broadcast
RARP uses the same message format as ARP, except


Ethernet frame type= 0x8035
Op field = 3 for RARP request, 4 for RARP reply
Client repeats request if no reply is received


how many times?
how much delay (time-out) between retransmissions?
RARP (cont'd)
Primary RARP server


provides mapping for many hosts (all diskless
machines in the network)
changes message type to RARP Reply, sends
directly to client
Secondary RARP server(s)



do not respond to first RARP Request
respond to second copy of RARP Request
received within a short time
randomly delay the reply to avoid collisions with
other non-primary servers
RARP Design and Implementation
ARP server

simple, part of TCP/IP implementation, in the kernel
RARP server


more complex, implemented as a user process
implementation of RARP server is system-dependent
RARP Requests are transmitted as Ethernet frames
with a specific type field (0x8035)

the server must have a way of sending/receiving Ethernet
frames of this specific type
Drawbacks of RARP
Low-level protocol, difficult for application
programmers to build a server
Supplies only one small piece of information
Cannot be used for dynamic IP address
assignment
Newer protocols: BOOTP, DHCP
Also implemented as user (application)
processes
Operate according to the client-server
paradigm
Use UDP for message transfer (i.e., above
UDP)
BOOTstraP Protocol (RFC 951,
RFC1542)
Single message exchange

but provides many items needed at startup, in addition to IP
address
Application uses the limited broadcast IP address
(255.255.255.255) to broadcast the BOOTP request on the local
net


Multi-homed hosts issue a BOOTP request for each interface
Source IP address = 0.0.0.0 (valid, used only during bootstrapping)
BOOTP server must also use limited broadcast for sending the
reply (why?)
BOOTP “Relay Agents” permit a machine to contact a server on
a non-local net
BOOTP (cont’d)
Server uses well-known UDP port 67, client uses
well-known port 68
“Don’t Fragment” bit in IP header set


To accommodate clients with limited memory which cannot
reassemble datagrams
BOOTP reply is at least 300 bytes long
Client is responsible for ensuring reliable
communication

Timeout and retransmission of request


random timeout and doubling after each retransmission (why?)
random delay before retransmission (why?)
BOOTP Message Format
Some BOOTP Details
Why is server name needed?
Encoding of options

“TLV” = tag (1 byte), length (1 byte), value (n bytes)
Client should set Broadcast flag to 1 if it does not
have a valid IP address already

Otherwise, it should set client_address to it’s IP address
and be prepared to received datagrams at that address
BOOTP Relays
Clients ignore the “relay IP address” field
If a server decides to relay the request, it puts its incoming IP interface
address in the “relay IP address” field and forwards to the BOOTP
server
All BOOTREQUEST messages from a given client MUST be relayed to
the same destination
BOOTP servers send BOOTREPLY messages directly to the relay
agent identified in the ‘relay IP address' field.
All BOOTREPLY messages received by a relay agent are intended for
BOOTP clients on its directly-connected networks
When a relay agent receives a BOOTREPLY message, it should
examine the BOOTP ‘relay IP address', ‘your IP address', and ‘client
hardware address' to deliver the BOOTREPLY message to the client
Dynamic Configuration
RARP, BOOTP designed for a relatively static
environment


manual configuration appropriate
cannot dynamically assign values to individual machines
One problem: mobile clients
Another problem: need to reuse pool of IP addresses


IP address pool may be small, pool of potential clients may
be large (e.g., dialup)
automated mechanism needed
DHCP (RFC 2131)
Extends BOOTP to handle dynamic address assignment


“leases” an address for a limited time (1 sec to 100 years)
Backwards compatible with BOOTP clients, message format is the
same
The DHCP server

Is given a set of addresses to manage




management algorithm is not standardized
leases addresses to clients (for how long?)
informs client of lease period, during which it will not lease same
address to another client
at end of the lease period, the client must either renew or stop
using the address
DHCP Client State Diagram
INPUT
OUTPUT
+ configuration
parameters