CSC/ECE 573 Internet Protocols

1. CSC/ECE 573Internet Protocols ARP, RARP

2. 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

3. Solutions • Direct mapping: function f maps IP addresses to hardware addresses • computation of f must be efficient • works well when physical addresses are small and configurable • Configuration file provides the mapping • 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?)

4. ARP vs. RARP

5. ARP Operation

6. ARP Packet Format (Ethernet frame type= 0x0806)

7. (Reminder: Ethernet Frame Format)

8. Using ARP: Case 1

9. Using ARP: Case 2

10. Using ARP: Case 3

11. Using ARP: Case 4

12. 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)

13. 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?

14. 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)

15. ARP Cache Contents Example Net to Media Table Device IP Address Mask Flags Phys Addr ------ -------------------- --------------- ----- -------------- le0 eos03ro.eos.ncsu.edu 255.255.255.255 00:d0:bc:ed:23:64 le0 perch.cacc.ncsu.edu 255.255.255.255 08:00:20:73:95:ab le0 shrimp.cacc.ncsu.edu 255.255.255.255 08:00:20:90:a3:7f le0 bass.cacc.ncsu.edu 255.255.255.255 08:00:20:73:98:c4 le0 multimedia 255.255.255.255 08:00:5a:8a:0c:79 le0 aphrodite 255.255.255.255 08:00:20:87:be:54 le0 artemis 255.255.255.255 08:00:20:87:bc:d4 le0 athena 255.255.255.255 08:00:20:21:87:4c le0 BASE-ADDRESS.MCAST.NET 240.0.0.0 SM 01:00:5e:00:00:00

16. ARP Protocol Design • (Simplified, bare-bones ARP only; no error-checking, error-handling, packet validation, etc.) • Three modules: • Output module • Input Module • Cache-control module • State of cache table entries: FREE, PENDING, RESOLVED

17. 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

18. 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

19. 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

20. Proxy ARP

21. 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/

22. 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

23. Reverse ARP

24. 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?

25. 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

26. 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

27. 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

28. 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)

29. 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

30. 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?)

31. BOOTP Message Format

32. 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

33. 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

34. 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

35. 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

36. DHCP Client State Diagram INPUT OUTPUT + configuration parameters