Address Resolution Protocol

Lecture 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 bytes Ethernet destination address bytes Ethernet source address 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 bytes CRC ARP request/reply format 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: 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 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 + 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 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: bytes bytes Dest addr Src addr 2B ftyp: 0x 8035 RARP Request / Reply 15 16 Hardware Type Hardware len 28 bytes (for IP) Protocol len CRC 31 Protocol Type oper: (RARP req) or (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 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 byte 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 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