In the Internet when you send packets to destinations, it's not enough to say what the destination is. You can't say, "Hey, I want to send packets to dub dub dub. Microsoft.com". That's not enough. With the Internet, you need to specify these intermediate addresses. You need to say the network endpoint, the IP address, and the MAC address of the next LAN Hop Tracert destination. You need to do these things. You got to sit back and think, we've been talking about DHCP a lot. Can we use DHCP to solve this challenge? Because DHCP gives you information about the network. Wouldn't it be great if it could give you information about the next LAN Hop, and all these other intermediate addresses you need. The answer is no, not really. Because DHCP is about configuration, it's not about caching. Because there's a difference between information that's configured and cached. You configure information that's static and fixed. If you have a host, you get an IP address. It doesn't really change. You get an IP address, and it stays there. As opposed to these intermediate addresses, which you may resolve for a large number of destinations. They may change dynamically. Dynamic information, you don't configure, you cache it. Is DHCP enough? Let's go through an example of why it might not be enough. Suppose you have a network here, you've a bunch of hosts, and each of them has an IP address and a MAC address, and you have some intermediate switches. So they're all on the same LAN. You could think about a host. This host wants to send a packet to 4.4.4.4. So when a host generates a packet, it's generated by an application. The application is going to trigger your DNS stub resolver to do a DNS requests lookup IP address. That's fine. But you can't send a packet to an IP address because an IP address is not the next LAN Hop. So this host is sitting here and says, "Okay. I want to send a packet to 4444. How do I do that?" To send it out over the Ethernet, it needs a construction Ethernet frame, independent Ethernet header to the start of the packet. What's the destination MAC address it puts in there? You can look at this and you can say, clearly I put CCCCCCCCCC in there because that's the MAC address associated with IP address 4444. But you can see that because I'm showing you the whole topology. The real situation is, if you have a host on a network, it doesn't have every destination on the network memorize. That's not very scalable, because they'd have to maintain that state over time. We don't do that in Ethernet. In Ethernet, each host just knows about itself, by default. So if it gets a packet destined to 4444, it needs to do something to figure out the MAC address of the destination, so it can send it over the current LAN Hop. So to do that, there is a protocol, which is called the Address Resolution Protocol. Its purpose is to resolve IP addresses to MAC addresses. If you know the IP address of the destination, it'll figure out the MAC address for you. Which is great. You don't have to figure that out on your own or write code to do that. It does that for you. It works like this. It leverages the broadcast capabilities of Ethernet to discover the destination. If I'm a host 2222 and I want to send a packet to 4444, what I'll do is I'll do a broadcast. I'll send a broadcast message out, which is a broadcast ARP request. My message will say basically, who owns IP address 4444? This message will be broadcast throughout the entire LAN, all host will hear it. All hosts will do a local check. They'll check to see, do I own that IP address? Was I given that IP address by DHCP or with a statically configured. When the destination receives this message, it will reply back with an ARP reply message. It'll say, I own 4444, and my MAC address is CCCCCCCCCC. So that message will be broadcast again throughout the network. Then, the original host can then cache that information. It can use that information to generate an Ethernet frame to send the packet. Since we have a lot of stationarity in networks, if you talk to a destination, you'll probably send in a lot of packets to it after that too. It's smart to cache this information. So hosts have what are called ARP caches. Where they maintain cache bindings of IP addresses to MAC addresses in these tables. So this process works, and it works for any IP address on that subnet. If you're sending to a destination on your local subnet in your local LAN, you will discover it. Because you'll broadcast and you'll ask who has the address, and they'll respond back. So this is the correct protocol. Now one issue is, what if the destination is not your subnet. This is a very common case, right? You send packets to destinations all the time that are not on your local subnet. They may be at some distant ISP off in the Internet somewhere. So what do we do in that case? Well, there we have a problem because you can't this broadcast and then expect to get a response, because you're broadcast only go out as far as the boundaries of the local area network, because that is your broadcast domain. To deal with that, we have the notion of what's called a default gateway. So if I have a LAN, I've got at least one point where I can get off that LAN onto the public Internet. I have an upstream connection. I may even have multiple of them. These points of connection are called default gateways. Through your default gateway to get out into the public Internet. It's what each host does, is that it first checks to see if the destination is on its local subnet first. If it is, then it uses this process I described. It uses ARP, does a broadcast. If it's not, then what it does is it does an ARP request for its default gateway, and then uses that to get out. So it would assign the MAC address of the default gateway. It's in the packet out. But it would use the IP address of the final destination off in the Internet. The way it does this check, is each host is configured through DHCP or some manual mechanism with the IP address of the default gateway, and it also knows its local subnet. In other words, it also knows all the IP addresses on its local subnet. It knows deterministically whether a host is on it's local subnet or if it's on some remote subnet off in the Internet. You might think what? It's hard to keep a list of all the IP addresses on your subnet, what if you have thousands of them? The reason why that's not hard, is because IP addresses are a topologically dependent. We send them based on topology. So each subnet is configured with just a single prefix. So it's just a very simple check, each host maintains a prefix corresponding to its local subnet. It does a check to see whether the destinations on that local subnet or not. If it is, it does this regular broadcast. If it's not, it does an ARP request for as default gateway, and it sends the packet to that.
