1 / 36

CSC/ECE 573 Internet Protocols

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

argus
Download Presentation

CSC/ECE 573 Internet Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related