Lecture 9. Direct Datagram Forwarding: Address Resolution Protocol (ARP) G.Bianchi, G.Neglia, V.Mancuso Problem statement ÎRouting decision for packet X has two possible outcomes: ÖYou are arrived to the final network: go to host X ÖYou are not arrived to the final network: go through router interface Y ÎIn both cases we have an IP address on THIS network. How can we send data to the interface? ÎNeed to use physical network facilities! G.Bianchi, G.Neglia, V.Mancuso Reaching a physical host ÎIP addresses only make sense to TCPIP protocol suite Îphysical networks have their own hardware address Öe.g. 48 bits Ethernet address, 16 or 48 bits Token Ring, 16 or 48 bit FDDI, ... Ödatalink layers may provide the basis for several network layers, not only IP! Address Resolution Protocol RFC 826 Here described for Ethernet, but more general: designed for any datalink with broadcast capabilities G.Bianchi, G.Neglia, V.Mancuso 32 bit IP address ARP RARP 48 bit Ethernet Address Manual mapping ÎA possibility, indeed!! ÖNothing contrary, in principle Æactually done in X.25, ISDN (do not support broadcast) ÖSimply keep in every host a mapping between IP address and hardware address for every IP device connected to the considered network Îdrawbacks Ötedious Öerror prone Örequires manual updating Æe.g. when attaching a new PC, must touch all others... G.Bianchi, G.Neglia, V.Mancuso ARP ÎDynamic mapping Önot a concern for application & user Önot a concern for system administrator! ÎAny network layer protocol Önot IP-specific Îsupported protocol in datalink layer Önot a datalink layer protocol !!!! ÎNeed datalink with broadcasting capability Öe.g. ethernet shared bus G.Bianchi, G.Neglia, V.Mancuso ARP idea 131.175.15.8 131.175.15.12 131.175.15.124 ???? Not me! Who has IP address 131.175.15.124 ?? ÎSend broadcast request Îreceive unicast response G.Bianchi, G.Neglia, V.Mancuso It’s me! I have 00:00:a2:32:5a:3 ARP cache ÎAvoids arp request for every IP datagram! ÖEntry lifetime defaults to 20min Ædeleted if not used in this time Æ3 minutes for “incomplete” cache entries (i.e. arp requests to non existent host) Æit may be changed in some implementations » in particularly stable (or dynamic) environments Öarp -a to display all cache entries (arp –d to delete) try a traceroute or ping to check ARP caching! ÆFirst packet generally delays more Æ includes an ARP request/reply! G.Bianchi, G.Neglia, V.Mancuso ARP request/reply Incapsulation in Ethernet Frame 6 bytes Ethernet destination address 6 bytes Ethernet source address 2 bytes frame type 28 bytes (for IP) ARP Request / Reply ÎEthernet Destination Address Öff:ff:ff:ff:ff:ff (broadcast) for ARP request ÎEthernet Source Address Öof ARP requester ÎFrame Type ÖARP request/reply: 0x0806 Protocol demultiplexing ÖRARP request/reply: 0x8035 codes! ÖIP datagram: 0x0800 G.Bianchi, G.Neglia, V.Mancuso 4 bytes CRC ARP request/reply format 0 7 8 15 16 Hardware Type Hardware len Protocol len 31 Protocol Type ARP operation Sender MAC address (bytes 0-3) Sender MAC address (bytes 4-5) Sender IP address (bytes 0-1) Sender IP address (bytes 2-3) Dest MAC address (bytes 0-1) Dest MAC address (bytes 2-5) Dest IP address (bytes 0-3) Hardware type: 1 for ethernet Protocol type: 0x0800 for IP (0000.1000.0000.0000) Ö the same of Ethernet header field carrying IP datagram! Hardware len = length in bytes of hardware addresses (6 bytes for ethernet) Protocol len = length in bytes of logical addresses (4 bytes for IP) ARP operation: 1=request; 2=reply; 3/4=RARP req/reply G.Bianchi, G.Neglia, V.Mancuso 28 bytes Sample ARP request/reply IP: 131.175.15.8 MAC: 0:0:8c:3d:54:1 Ethernet Packet: ARP REQUEST IP: 131.175.15.24 MAC: 0:4f:33:3:ee:67 Ethernet Packet: ARP reply dest MAC FF:FF:FF:FF:FF:FF 00:00:8c:3d:54:01 src MAC 00:00:8c:3d:54:01 00:4f:33:03:ee:67 ARP frame type 0x0806 0x0806 Ethernet / IP 0x0001 0x0800 0x0001 0x0800 MAC=6 / IP=4 / rq=1,rpl=2 0x06 0x04 0x06 0x04 0x0001 0x0002 src MAC 00:00:8c:3d:54:01 00:4f:33:03:ee:67 src IP 131.175.15.8 131.175.15.24 dest MAC 00:00:00:00:00:00 00:00:8c:3d:54:01 dest IP 131.175.15.24 131.175.15.8 Ethernet checksum checksum checksum G.Bianchi, G.Neglia, V.Mancuso ARP cache updating ÎARP requests carry requestor IP/MAC pair ÎARP requests are broadcast Öthus, they MUST be read by everyone ÎTherefore, it comes for free, for every computer, to update its cache with requestor pair ÎCannot do this with ARP reply, as it is unicast! G.Bianchi, G.Neglia, V.Mancuso Proxy ARP ÎDevice that responds to an ARP request on behalf of some other machine Öallows having ONE logical (IP) network composed of more physical networks Öespecially important when different techologies used (e.g. 100 PC ethernet + 2 PC dialup SLIP) ARP request for 131.175.15.24 IP: 131.175.15.24 ARP reply on behalf of 131.175.15.24 returns router MAC address! Then router will forward packets to remote host G.Bianchi, G.Neglia, V.Mancuso Gratuitous ARP ÎARP request issued by an IP address and addressed to the same IP address!! ÖClearly nobody else than ME can answer! ÖWHY asking the network which MAC address do I have??? ÎTwo main reasons: Ödetermine if another host is configured with the same IP address Æin this case respond occurs, and MAC address of duplicated IP address is known. ÖUse gratuitous ARP when just changed hardware address Æall other hosts update their cache entries! ÆA problem is that, despite specified in RFC, not all ARP cache implementations operate as described…. G.Bianchi, G.Neglia, V.Mancuso ARP: not only this mechanism! ÎDescribed mechanism for broadcast networks (e.g. based on shared media) ÎNon applicable for non broadcast networks Öin this case OTHER ARP protocols are used Æe.g. distributed ARP servers Æe.g. algorithms to map IP address in network address G.Bianchi, G.Neglia, V.Mancuso Getting an IP address: Reverse Address Resolution Protocol (RARP) G.Bianchi, G.Neglia, V.Mancuso The problem Î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 G.Bianchi, G.Neglia, V.Mancuso RARP packet format almost identical to ARP. Differences: 6 bytes 6 bytes Dest addr Src addr 0 2B ftyp: 0x 8035 7 8 RARP Request / Reply 15 16 Hardware Type Hardware len 28 bytes (for IP) Protocol len CRC 31 Protocol Type oper: 3 (RARP req) or 4 (RARP reply) Sender MAC address (bytes 0-3) Sender MAC address (bytes 4-5) Sender IP address (bytes 0-1) Sender IP address (bytes 2-3) Dest MAC address (bytes 0-1) Dest MAC address (bytes 2-5) Dest IP address (bytes 0-3) G.Bianchi, G.Neglia, V.Mancuso 4 bytes RARP Request/reply IP = ???? MAC = 0:0:8c:3d:54:1 Your IP is 131.175.21.53 Unicast reply Broadcast request My MAC address is 0:0:8c:3d:54:1. What is my IP address?? G.Bianchi, G.Neglia, V.Mancuso 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... G.Bianchi, G.Neglia, V.Mancuso RARP fundamental limit ÎAllows only to retrieve the IP address information Öand what about all the remaining full set of TCPIP configuration parameters??? ÆNetmask? Æname of servers, proxies, etc? Æother proprietary/vendor/ISP-specific info? ÎThis is the main reason that has driven to engineer and use BOOTP and DHCP G.Bianchi, G.Neglia, V.Mancuso BOOTP/DHCP approach ÎRequests/replies encapsulated in UDP datagrams Ömay cross routers Öno more dependent on physical medium Îrequest addressing: Ödestination IP = 255.255.255.255 Ösource IP = 0.0.0.0 Ödestination port (BOOTP): 67 Ösource port (BOOTP): 68 Îrouter crossing: Örouter configured as BOOTP relay agent Öforwards broadcast UDP requests with destination port 67 G.Bianchi, G.Neglia, V.Mancuso BOOTP parameters exchange ÎMany more parameters Öclient IP address (when static IP is assigned) Öyour IP address (when dynamic server assignment) Ögateway IP address (bootp relay agent - router - IP) Öserver hostname Öboot filename ÎFundamental: vendor-specific information field (64 bytes) Öseems a lot of space: not true! ÖDHCP uses a 312 vendor-specific field! G.Bianchi, G.Neglia, V.Mancuso Vendor specific information format allows general information exchange Tag Len 1 byte 1 byte Parameter exchanged ÎE.g.: subnet mask: Ö tag=1, len=4, parameter=32 bit subnet mask Îe.g.: time offset: Ötag=2, len=4, parameter=time (seconds after midnight, jan 1 1900 UTC) Îe.g. gateway (variable item) Ötag=3, len=N, list of gateway IPaddr (first preferred) Îe.g. DNS server (tag 6) G.Bianchi, G.Neglia, V.Mancuso