Address Resolution Protocol ARP and Domain Name Service DNS
This lecture is divided into hyperlinked sections
Introduction
IP and LAN addresses
Mapping
IP addresses to MAC addresses
Sending
on the same Ethernet Segment
Address Resolution
Protocol
More Efficiency to
ARP
Sending
to a distant Ethernet Network
Sending Over a WAN
Translation
of Domain Names to IP addresses
Domain Name System
How does DNS operate?
Example of DNS usage
Connection
between IP address and Domain Name
Conclusion
References
So far we have talked about Ethernet addresses and IP addresses but no mention has been made of how a computer can discover an IP address from either a Domain name or a MAC address. This lecture will try to answer those questions.
Although every machine on the Internet has one or more IP addresses, within the confines of a LAN, IP addresses be used for sending frames because the Data Link layer hardware does not understand Internet addresses. The hosts (PCs) are attached to the LAN by an interface card that only understands LAN (MAC) addresses. For example, every Ethernet board ever manufactured comes equipped with a 48-bit Ethernet address. Manufacturers of Ethernet boards request a block of addresses from a central authority to ensure that no two boards have the same address (to avoid conflicts should the two boards ever appear on the same LAN). The boards send and receive frames based on 48-bit Ethernet addresses. They know nothing at all about 32-bit IP addresses.
Mapping IP addresses to MAC addresses
If Ethernet nodes cannot use IP addresses to construct Ethernet frames, how do IP addresses get mapped onto Data Link layer addresses, such as Ethernet?
To explain how this works, refer to Fig. 8.1, in which a university with two class C networks is shown. Here we have two Ethernet networks, one in the Computer Science department, with IP address 193.61.65.0 and one in Electrical Engineering, with IP address 193.31.63.0. These are connected by a campus FDDI ring with IP address 193.61.60.0. Each machine on an Ethernet segment has a unique Ethernet MAC address (e.g. 07-A4-13-24-0C-D2), labelled E1 to E8, and each machine on the FDDI ring has a FDDI address, labelled F1 to F3.
Fig 8.1 Three interconnected
class C networks: 2 Ethernet and FDDI ring
Sending on the same Ethernet Segment
Let us start out by seeing how a user on host labelled E1 sends a packet to a user on host E3. Let us assume the sender knows the name of the intended receiver, possibly something like fred@gre.ac.uk.
The first step is to find the IP address for host E3, known as sneezy.gre.ac.uk. This lookup is performed by the Domain Name System. For the moment, we will just assume that DNS returns the IP address for host E3 (193.61.65.5).
The upper layer software on host E1 now builds a packet with 193.61.65.5 in the IP header Destination Address field and gives it to the IP software to transmit (Network Layer). The IP software can look at the address and see that the destination is on its own network, but it needs a way to find the destination's Ethernet address.
One solution is to have a configuration file somewhere in the system that maps IP addresses onto Ethernet addresses. This solution is certainly possible, but for organisations with thousands of machines, keeping these files up to date is an error-prone, time consuming job.
A better solution is for host E1 to output a broadcast packet onto the Ethernet asking:
"Who owns IP address 193.61.65.5?"
The broadcast will arrive at every machine on Ethernet 193.61.65.0, and each one will check its IP address. Host E3 alone will respond with its Ethernet address 00-50-04-3D-45-3D. In this way host E1 learns that IP address 193.61.65.5 is on the host with Ethernet address 00-50-04-3D-45-3D. The protocol for asking this question and getting the reply is called ARP (Address Resolution Protocol). Almost every machine on the Internet runs it. It is defined in RFC 826.
The advantage of using ARP over configuration files is the simplicity. The system manager does not have to do much except assign each machine an IP address and decide about subnet masks. ARP does the rest.
At this point, the IP software on host E1 builds an Ethernet frame addressed to 00-50-04-3D-45-3D, puts the IP packet (addressed to 193.61.65.5) in the payload field, and dumps it onto the Ethernet. The Ethernet card of host E3 detects this frame, recognises it as a frame for itself, scoops it up, and causes an interrupt.
The Ethernet driver extracts the IP packet from the payload and passes it to the IP software, which sees that it is correctly addressed, and processes it.
Various optimisations are possible to make ARP more efficient. To start with, once a machine has run ARP, it caches the result in case it needs to contact the same machine shortly. Next time it will find the mapping in its own cache, thus eliminating the need for a second broadcast. In many cases host E3 will need to send back a reply, also forcing it to run ARP to determine the sender's Ethernet address.
This ARP broadcast can be avoided by having host E1 include its IP address to Ethernet mapping in the ARP packet. When ARP broadcast arrives at host E3, the pair (193.61.65.7, 05-50-04-3D-45-3E) is entered into host E3's ARP cache for future use. In fact all machines on the Ethernet can enter this mapping into their ARP caches.
Yet another optimisation is to have every machine broadcast its mapping when it boots. This broadcast is generally done in the form of an ARP looking for its own IP address. There should not be a response, but a side effect of the broadcast is to make an entry in everyone's ARP cache. If a response does arrive, two machines have been assigned the same IP address. The new one should inform the system manager and not boot.
To allow mappings to change, for example, when an Ethernet board breaks and is replaced with a new one (and thus a new Ethernet address), entries in the ARP cache should time out after a few minutes.
Sending to a distant Ethernet Network
Now let us look at figure 8.1 again, only this time host E1 wants to send a packet to host E6 (193.61.63.8). Using ARP will fail because host E6 will not see the broadcast because routers do not forward Ethernet-level broadcasts.
There are two solutions. First, the Computer Science router could be configured to respond to ARP requests for network 193.61.63.0 (and possibly other local networks). In this case, host E1 will make an ARP cache entry of (193.61.63.8, E4) and happily send all traffic for host E6 to the local router E4. This solution is called proxy ARP.
The second solution to have host E1 immediately see that the destination is on a remote network and just send all such traffic to a default Ethernet address that handles all remote traffic, again E4. This solution does not require having the Computer Science router know which remote networks it is serving.
Either way, what happens is that host E1 packs the IP packet into the payload field of an Ethernet frame addressed to E4. When the Computer Science router gets the Ethernet frame, it removes the IP packet from the payload field and looks up the IP address in its routing tables. It discovers that packets for network 193.61.63.0 are supposed to go to router 193.61.60.7.
If it does not already know the FDDI address of 193.61.60.7, it broadcasts an ARP packet onto the ring and learns that its ring address is F3. It then inserts the packet into the payload field of an FDDI frame addressed to F3 and puts it on the ring.
At the Electrical Engineering router, the FDDI driver removes the packet from the payload field and gives it to the IP software, which sees that it needs to send the packet to 193.61.63.8. If this IP address is not in its ARP cache, it broadcasts an ARP request on the Electrical Engineering Ethernet and learns the MAC address of E6 so it builds an Ethernet frame addressed to E6, puts the packet in the payload field, and sends it over the Ethernet. When the Ethernet frame arrives at host E6, the packet is extracted from the frame and passed to the IP software for processing.
Going from host E1 to a distant network over a WAN works essentially the same way, except that this time the Computer Science router's tables tell it to use the WAN router whose FDDI address is F2.
Translation of Domain Names to IP addresses
The names that are given to computers on the Internet are known as Domain Names. This means that for your home or a remote computer to find www.gre.ac.uk it must first discover the IP address that is assigned to that domain name.
The system that performs this function is known as the Domain Name System (DNS). So when you type a domain name into a browser, the application uses the domain name system to translate the domain name into an IP number. Once the computer has received the IP number of the remote computer it may begin contacting it using datagrams, else it must find the MAC address of a communication server.
The domain name system uses a client/ server approach to the problem.
Your computer sends a request to a domain name server:
What is the IP address for www.gre.ac.uk ?
The server looks up the corresponding IP number and replies:
193.60.49.94
The method of operation of DNS is similar to directory enquiries (192) in the UK. If you need the telephone number of a person, you dial the service and an operative asks for the name and address of the person that you are contacting. He or she then looks up the corresponding number and this is relayed to you.
If the number that you are searching for lies in another country, perhaps France, the operative will give you the telephone number of the French directory enquiries service. Then you will be able to contact the overseas office of directory enquiries.
The DNS works in a similar fashion. Any particular DNS server does not have a table containing all of the domain names on the Internet. It will only keep a listing of the local domain names, perhaps in an organisation or area.
When you are working at a computer within the university and need a service from a computer in Japan, you type the URL into your application. The application then contacts its local DNS on the Medway site which then forwards the request to a DNS server on the Woolwich site (UoG) which will then forward its request to a DNS in Japan.
If you are working in an organisation that has just one DNS server and want to contact a web server in USA for a web page, the application (browser) you are using will automatically call its local DNS server which will then forward the request to the appropriate DNS in USA. This may require more than one hop, depending upon whether the DNS server in USA that is first contacted has a copy of the relevant domain name/ IP pair. The American DNS server will reply to your local DNS server which will then supply your application (browser) with the IP number you wanted.
The American DNS server may be identified by the organisation specified in the domain name.
Your application may now contact the American web server directly using the IP number in its datagrams. Below is a simplified diagram of the whole process.
Figure 8.2 Requesting an
IP address from an American DNS server
Referring to fig 8.2, steps 1, 2, 3 and 4 involve resolving the domain name into an IP address. Step 5 happens once the IP address has been returned; this is where the application program sends a request for a web page. Step 6 is where the web page is returned to the application to be displayed on the monitor.
Connection between IP address and Domain Name
There is only a logical connection between a domain name and an IP address; it is not possible to split an IP address in half and map it to half of a domain name.
The assignment of an IP address to a domain name occurs when you have registered the domain name and then approach an ISP or web server company to host your website. They will assign your IP address from their collection of IP addresses that they have allocated to them.
To send frames over an Ethernet network it is necessary to have the MAC address of either the destination or a router that can act as stage 1 in the delivery process.
To discover the MAC address of a computer from the IP address, Address Resolution Protocol is used. ARP servers are local to the LAN that the message is to be sent from.
To discover the IP address from a domain name, Domain Name Service is used. The DNS is distributed across the world.
Tannenbaum, Prentice Hall, 3rd Edition pp 420 et seq
http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/arp.html
http://www.hill.com/library/publications/tcpip.shtml
Back to top of page
© MM Clements 2001