This section is very simple; it’s just learning to use some simple tools to see what we they can tell us and to get ourselves familiarised with the environment. Without this familiarity, we are blind and lame when we need to diagnose problems. We shall limit ourselves to a very small selection of commands.
With IPv6, we generally have a new set of tools, or system specific additions to old tools, such as ifconfig. On Linux, the new, preferred and much more capable tool that manages most of the network stack is simply called ip.
The ip command has extensive help built in, so you generally don’t use the manual page for getting documentation. The help system is modal; it depends on what mode you are using. For example, try these commands on Client1 to see the different help you get.
$ip helpUsage: ip [ OPTIONS ] OBJECT { COMMAND | help } ip [ -force ] [-batch filename where OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable | tunnel | maddr | mroute | monitor | xfrm } OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] | -f[amily] { inet | inet6 | ipx | dnet | link } | -o[neline] | -t[imestamp] }$ip addr helpUsage: ip addr {add|change|replace} IFADDR dev STRING [ LIFETIME ] [ CONFFLAG-LIST] ip addr del IFADDR dev STRING ip addr {show|flush} [ dev STRING ] [ scope SCOPE-ID ] [ to PREFIX ] [ FLAG-LIST ] [ label PATTERN ] IFADDR := PREFIX | ADDR peer PREFIX [ broadcast ADDR ] [ anycast ADDR ] [ label STRING ] [ scope SCOPE-ID ] SCOPE-ID := [ host | link | global | NUMBER ] FLAG-LIST := [ FLAG-LIST ] FLAG FLAG := [ permanent | dynamic | secondary | primary | tentative | deprecated | CONFFLAG-LIST ] CONFFLAG-LIST := [ CONFFLAG-LIST ] CONFFLAG CONFFLAG := [ home | nodad ] LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ] LFT := forever | SECONDS
In order to understand what is being shown, you simply need
to understand that [ … | … ] denotes an optional
choice, { … | … } denotes a mandatory choice,
lowercase are keywords (mandatory) and
UPPERCASE are rules (“grammar productions” to
use a Computer Science term) that expand (:=)
further. You can also see that you just need to add
help to the end of the command you are
trying to complete; it’s pretty simple, though a little
bewildering at first. Most of the things you don’t need to worry
about for simple uses; the ip command can allow
for quite advanced commands which makes the grammar more useful to
have.
Let’s use ip to look at some useful
information. For each example, add help to
the end to see what else you can do. Since we’re only interested
in IPv6 at present, we’ll add the -6 option so it
limits its operation to IPv6. Also, we’re not going to show the
output of the commands; this makes you have to figure out what
they do for yourself.
$ip -6 addr…$ip -6 link…
Okay, so that was pretty basic, we just looked at the Layer 3 network address configuration (for IPv6) and the Layer 2 datalink (Ethernet, in this case) information.
We want to briefly look at the glue the binds the IPv6 layer (network layer) to the Ethernet layer (datalink layer). One of the things that makes IPv6 different from IPv4 is that we no-longer use ARP to determine the Ethernet MAC address that is bound to a particular IPv4 address. Instead, IPv6 has its own protocol for this called Neighbour Solicitation. Likewise, the Neighbour Cache has replaced the ARP cache; that’s a little simplified, but it will do for now.
$ip -6 neigh help…$ip -6 neighfe80:a00:27ff:fe69:9487 dev eth0 lladdr 08:00:27:69:94:87 router STALE
We use the above output to illustrate a few things (your output will look different). The basic pattern is an IPv6 address is associated to a link-layer address (in this case, an Ethernet MAC address) on a particular network device. This IPv6 address apparently belongs to a router (but at the moment we don’t care about that). Each entry has a Neighbour Unreachability Detection (NUD) state; “stale” means the entry is valid but not particularly trustworthy because of its age. Let’s ping Radv and see what changes in our neighbour cache.
Log in as Mal on Radv (the password is the same) and find
out Radv’s eth0 IPv6 link-local address. We suggest you write it
down. Now ping Radv from Client1; don’t include the prefix length
(/64) in the command:
$ping6 -c2…radv-link-local-ipv6-address%eth0
If you get “connect: Invalid Argument”, that indicates that you
forgot to include the %eth0. If instead you got
“unknown host”, then it means you copied the address wrongly such that
it is no longer a valid IPv6 address.
Notice that because we are pinging a link-local address
(fe80::/64), which every interface has and is therefore
generally ambiguous, we need to use a special syntax to identify
the interface we want to use %eth0. A number
can be used for the interface ID on some systems instead, such
as Windows.
What actually went on there? If you had been looking at what was happening on the network, using Wireshark or similar, you should likely see something similar to this, although it can differ depending on what each side already knows. So the packets used look like the following:
Client1 wants to send an IPv6 packet to Radv’s IPv6 link-local address (layer 3), which is a local delivery. But it probably doesn’t yet know Radv’s link-layer address (layer 2), so it needs to look it up by using a ICMPv6 Neighbour solicitation from Client1’s link-local IPv6 address to the Solicited node multicast address for the address that shall be pinged. It also carries with it a notification of Client1’s link-layer (Ethernet) address, preventing Radv from having to look it up later and thus saving network traffic.
This is analogous to an ARP request in IPv4.
Radv responds with a ICMPv6 Neighbour advertisement. It comes from Radv’s link-local IPv6 address to Client1’s link-local IPv6 address. It carries a notification of Radv’s link-layer (Ethernet) address, which Client1 puts into its Neighbour Cache.
This is analogous to an ARP reply and the result being cached in the ARP cache.
Now Client1 knows everything it needs to in order to make the local delivery of this IPv6 packet, so it sends the ICMPv6 Echo request (“ping”), from Client1’s link-local IPv6 address to Radv’s link-local IPv6 address (which is the address we pinged).
Radv has already learned of Client1’s link-layer address, so it doesn’t need to perform the Neighbour Solication process again, as it has it in its neighbour cache. So Radv can now send the ICMPv6 Echo response packet immediately, which is its response to the “ping” (Echo request) packet.
Notice that this is a local, or “on-link” delivery; it does not go through a router. We’ll ignore the issue of routing until much later.
We’ve seen some multicast addresses being used; how do we find out which multicast addresses the host is currently interested in? ip can help here also:
$ip -6 maddr…
That’s it, a few very simple commands to allow us to investigate the local link (layer 2) and IPv6 in a single network.
There is much we haven’t covered in this lab, such as assigning static IPv6 addresses, which is really easy, but we’ll cover that later.