Hello, and welcome back to CS615 System Administration! This is week 6, segment 3, and we're beginning a series of bite-sized videos covering some of the more common protocols you'll regularly encounter as a System Administrator across the standard TCP/IP stack. While some of this may be familiar to you from other classes, I hope that you will find at least something useful in each segment. In this video, we'll discuss the Address Resolution Protocol or ARP and it's IPv6 equivalent, the Neighbor Discovery Protocol or NDP. We already saw ARP in our last video, but especially the comparison to the IPv6 NDP should help illustrate a few important concepts. --- Let's first look at the ARP cache of a few systems. On our typical EC2 instance, it'll look something like this. But since our instance resides on a dedicated VPC and we don't have any other systems spun up there, there is not going to be a whole lot of local traffic on this network. So let's see what things look like on our Stevens linux-lab systems. Ok, this is perhaps a bit more interesting, as we can see numerous systems on our network, but to illustrate the use of the ARP protocol, we'll need to be able to flush the cache and capture packets, for which we need superuser privileges, so let me show you some real-world traffic from my personal virtual private server. Alright, not particularly exciting, only a few entries here, but at least now we can start our analysis. We run a tcpdump capturing all ARP traffic, then flush the ARP cache. Next, we generate some IPv4 network traffic -- ICMP echo request / echo reply also known as "ping" in this case -- and then display the ARP cache. We can now stop the tcpdump again, and take a look at what traffic we captured. Oh, wow, look at that. That's a _lot_ of packets we saw here! If you ran that through 'wc', you'd see we have almost 6000 packets here! Now obviously not all of those were from our system, so let's take a look. We see a whole bunch of "who-has" requests, showing that those requests made by other systems are _broadcast_ to all devices in the broadcast domain. Down here, we see 166.84.5.240 asking for our IP address 166.84.7.99, and the "is at" reply is what we're then sending unicast to that address. We see a whole lot of other "who-has" requests, with the only "is-at" replies being our answers to other hosts asking where we are, although every now and then, we also oversee other "is-at" messages _without_ a "who-has" request -- this is known as a "gratuitous ARP", a reply that nobody asked for. This commonly happens when a new interface comes up, to let the switch know where this device is. --- Ok, so to recap and visualize once more: We saw requests from other systems asking "who has this IP address, please let me know". Such requests are sent by the sending system with a destination MAC address of all ones (or FF:FF:FF:FF:FF:FF) - which the switch then broadcasts to all systems in the broadcast domain, which is why we, sitting on our system up here in the top left at 166.84.7.99 were able to see the request. In other words, - "who-has" is a broadcast request. --- The reply to that request, which we did _not_ see - was delivered via unicast only to the system that made the specific request. But --- if a system wants to announce to everybody in the broadcast domain its location, then it can send a so-called "gratuitous ARP", which again has a destination address of all ones - and thus is also broadcast to all systems. Finally, it's worth noting that it's possible for you to observe - addresses outside of your _subnet_, but that are still within your _broadcast domain_: this might be the case if the switch in question has multiple subnets in the same VLAN, which thus combines those subnets into the same _broadcast domain_. Alright, so that's ARP, and as we've seen, this is IPv4 only. What happens in the IPv6 world here? --- In IPv6, there is no ARP, but instead the job of discovering your neighbors is handled by the, well, Neighbor Discovery Protocol, which utilizes ICMP. - So let's try another tcpdump, this time collecting ICMPv6 traffic. We flush our neighbor discovery table and send out a few IPv6 packets to trigger the neighbor discovery from our end. After this, we can look at our NDP table and find this entry over here. Ok, so let's take a look at the network packets we captured. Ooof, like before that's a lot - almost a thousand packets. Let's look again at our IP addresses. What's our default IPv6 route? There, this link-local address, and our global scope address is this one here. Let's see if that shows up in our tcpdump. There. So we see an ICMPv6 neighbor solicitation from our global address to this ff02::1 address here, asking "who has the address of our default route?" Note that the low-order 24 bits of the address we're looking for is combined with the ff02::1:ff prefix, and that the default route replies to our global address. To do that, we then see the default route ask "hey, who has this global address that I'm supposed to reply to", to which we reply from our _link-local address_ down here. Now let's look again at our NDP cache here -- two entries. If we now send an ICMP echo request to this special address here -- ff02::1, then look at that, we get a lot of replies back! And our NDP cache now has a _lot_ more entries. This is because this address, ff02::1, is the "all-nodes" multicast address, and we thus requested a reply from all IPs in multicast address. Let's compare and visualize like we did before: --- Here's our set up, just like before with the various IPv6 addresses. Note that each system has both a link-local address as well as a global address. If we want to find out what the MAC address is of a given IPv6 address, then we issue a "neighbor solicitation" to the so-called "solicited-node multicast address". This address is determined by combining the ff02::1:ff prefix with the low-order 24 bits of the desired destination address. Any system with an IPv6 address matching those low-order bits joins that specific multicast address, and our request is then - multicast to only those address, unlike in the case of ARP, where these requests were broadcast to _all_ systems in the broadcast domain. --- The reply, the "neighbor advertisement" then is returned as a unicast "tgt is" message. --- But of course we _can_ send messages to all systems via the "all-nodes multicast address", which is link-local in scope, and --- which then gets delivered to all systems in that link-local broadcast domain, similar to the ARP requests we saw for IPv4. --- Alright, time to recap: - We saw the Address Resolution Protocol, or ARP, defined in RFC826 and used for IPv4. - We saw the "who-has" requests going out as broadcast packets, and the - "is-at" replies being unicast, unless broadcast as gratuitous announcements. - For IPv6, we saw the Neighbor Discovery Protocol, where we saw different address scopes in play. - The neighbor solicitation -- "who has" -- went to the special solicited-node multicast address, while the - neighbor advertisement -- "tgt is" -- went to the global unicast address that made the request. - But like gratuitous ARP announcements, we can also generate similar "unsolicited" neighbor advertisements, which we simulated via a ping packet sent to the all-nodes multicast address. Now it's worth noting that in IPv6, the Neighbor Discovery Protocol happens inside of the network layer, using ICMPv6. We'll - take a closer look at what else happens with ICMP in our next video. Make sure to play around with tcpdump and capture packets on your own systems. We'll be using tcpdump more and more in the next few videos. Until then, thanks for watching. Cheers!