In this section, I want you to practice using a network analyser called Wireshark to take a close look at what happens when an interface is configured using StateLess Address AutoConfiguration (SLAAC) and to observe other fundamental IPv6 mechanisms.
By now Radv should have finished importing. Go into its Network settings and ensure that its Adaptor 1 is connected to the Internal Network “TELE301 Internal Network 1”. Then Start it.
The purpose of this machine is send out IPv6 “router advertisements”, so host on the network can learn about their local router(s) and determine a suitable set of addresses to use. Radv will not be used as a router for this lab, we only need it to offer us router advertisements, so we can study what they contain and how it influences Client1. You will not need to configure anything inside this machine.
When you have imported and started the new machine, which is called “Radv”, it will boot to a console-login window (“radv login:”). You can minimise the machine, you won’t need to interact with it.
On Client1, run ifconfig and ip addr show in a terminal window on Client1. Take a screenshot of what you see; you should see that you now have another address in addition to the link-local address (fe80::/64) you will typically always have. This address, which starts with fd6b:, is a “Unique-Local Unicast Address”. Write down this address in its uncompressed form. You will need these for the assessment.
Wireshark needs to run with sufficient privileges to capture traffic, which generally—though not necessarily—implies root privilege. However, Wireshark is such a complicated program (due to all the various protocols it tries to understand) that experience has shown it to be something of a security risk, so ideally you would run it as a non-root user that has the appropriate permissions to capture traffic; but currently Wireshark doesn’t support separation of privileges when you are capturing and analysing (displaying) the packets at the same time. So just run wireshark using a privilege elevator such as sudo.
In the video, we show an alternative, more secure way of doing the capture and analysis, using tcpdump for the capture, and wireshark for the analysis.
Wireshark will detect that it is running as root and pop up an alert box, which you will need to dismiss before you can continue running the application. Note that the alert box may be hidden behind the Wireshark window.
Start capturing on the first ethernet interface (it should be “eth0”). You should soon see ICMPv6 Routing Advertisements. The radvd software running on the machine Radv has been configured to send out routing advertisements rather more frequently than needed, to reduce your waiting time. Stop the capture when you have at least 10 or so. Using the menu, un-check the to give yourself more screen real-estate. Alternatively, you can just make the VirtualBox window larger and (due to the fact that the VirtualBox Guest Additions are installed inside the guest) it should change the screen resolution of the guest.
Click on any one of the ICMPv6 Router advertisement packets. In the Packet Details area of the Wireshark window, click on the disclose (screenshot showing the entire contents, you will want to refer to it later.) button recursively to open up the packet so you see that all of the fields and subfields for the “Internet Protocol Version 6” and “Internet Control Message Protocol v6”. Take a
Figure 9, “Detail of IPv6 Router Advertisement in Wireshark” shows the screenshot simililar to what you should see, showing the details of a single router advertisement. Right now we’re going to discuss what is significant in this packet.
Here is a brief explanation of the most important parts of the router advertisement, from top to bottom in the packet details view.
In the packet shown, this is the “link-local unicast”
address of Radv. We can confirm this by logging into Radv
mal and running ifconfig.
(note that your Radv will have a different MAC address from ours)
and seeing that the IPv6 address has a MAC address embedded
inside of it.
ff02::1 is a well-known address commonly called the “all-hosts link-local multicast address”. Every host on the local network (the “local link”, which is everything up to the first router) will be listening for traffic sent to this address.
ICMPv6 is a management protocol that is very important to the running of IPv6. As such, there are many different types of messages it could transmit. To identify the type of message being transmitted, the Type field is used. Here, type 134 identifies this message as being a Router advertisement.
The “Managed” address config flag specifies whether “Stateful configuration” is to be used. Stateful configuration would typically be understood to mean DHCPv6 (we learn about DHCP in a later lab, but we’ll ignore DHCPv6 in this paper). On most networks, this flag would not be set, meaning that the host should use “StateLess Address AutoConfiguration” (SLAAC).
The “Other” stateful config flag means that nodes on this link (local network) should use Stateful configuration (DHCPv6) for things other than address assignment. Thus, if you don’t use Stateful configuration for address assignment, you can still use it to advertise other information (such as information about DNS services, but we learn about DNS later in this course).
For example, in the capture we saw on our own network, we saw M=0 and O=0, meaning “Not managed” and “Not other”. So we don’t use stateful configuration (such as DHCPv6) to try and get an address (instead we just use SLAAC), and neither do we use stateful configuration to find out other, non-address information about the network (eg. DNS settings, which host to send log messages to, and a wide range of other possibilities, some of which we mention further in the lab on DHCP).
These “M” and “O” bits (Managed and Other) are important for understanding how IPv6 address assignment works. The remaining flags are not important for what we are aiming to understand today.
There can be a number of optional components to a router advertisement. The most common would be an option advertising what “prefix(es)” are used on this link. A prefix is very much like a network address: in SLAAC, a set of addresses is formed by taking each prefix and adding the interface’s EUI-64 host ID (typically formed by the MAC address).
Note that there can be multiple “Prefix information” options included in a router advertisement. An interface can use multiple prefixes to generate multiple IPv6 addresses.
Somewhat self-explanatory, it tells us that this particular prefix is a /64 (remember that IPv6 addresses are 128-bit). With SLAAC, all advertised prefixes are /64, which makes this particular entry rather less interesting. We’ll come back to it when we see the Prefix.
The only flag we wish to draw to your attention here is the Autonomous Configuration flag (shown as “auto” in the screenshot). Recall that there can be multiple prefixes included in a router advertisement: only the ones marked with this “auto” flag get SLAAC addresses. This is on by default.
This is the key piece of data in this announcement. Coupled with the prefix length we saw earlier, we see that this the prefix being advertised is fd6b:4104:35ce::/64. Viewed uncompressed, so you can see exactly how long the prefix is in relation to the whole address:
fd6b:4104:35ce:0000:0000:0000:0000:0000 network bits ↤ ↦ host bits
This option simply communicates the router’s MAC address to the hosts on the link, so they can pre-cache it in their “neighbour cache” (this is like ARP, although IPv6 doesn’t use ARP but something similar which we don’t want to get into right now). Having it included here means we don’t have to have an extra round-trip on the network to figure out the link-layer (MAC) address of the router, which reduces delay.
So that’s a router advertisement, seen during steady-state whereby nothing particularly interesting is happening such as a new host appearing on the link. Let’s now repeat the capture and this time we shall see everything that happens when an interface comes up.
Resize the Wireshark display so that the packet list area takes up most of the room. Start a new live capture in Wireshark; you may discard your previous capture. When it has started capturing, from a terminal window, run as root the command ifconfig eth0 down, which will “down” the interface “eth0”, basically disabling it and removing any information that relates to it, such as routing table entries. Now remember what the last packet was that is currently shown in Wireshark’s packet list area. When you bring the interface back up with ifconfig eth0 up, you should see several packets arrive in the window. Stop the capture and save it, you will need it later in the assessment. Take a screenshot of the packet list showing the new packets. Figure 10, “What Wireshark sees when an Interface “Comes Up”” is what we see on our own capture, which may likely be a bit different from yours; in particular, the ordering of some packets can vary.
Rather than having you read about what each packet is doing, we’re going to show you with a video, which will walk you through what is happening in this sequence of packets; or rather, a similar sequence of packets. In this video, which lasts about half an hour, you will encounter various parts of IPv6 that form part of its basic mechanisms. We require that you have some understanding of what is going on, to an extent whereby you could look at such a listing, and with a bit of work, explain basically what is happening. In the assessment, you will be asked to summarise some of what you have seen.
The video can be found in the “Resources” share on Gallardo, and is called IPv6 SLAAC Explanation. However, you should watch the video later.
This is because you won’t need to be in the lab to complete the video-watching task, but you will want to be in the lab for Section 4, “Diagnostic and Query Tools”. Doing this will help you use your time more effectively.