ipv6 address autoconfiguration

This is a limited introduction to the ipv6 protocol's addresses and in particular its address autoconfiguration feature.

Use the VirtualBox client and server machine pair from the "sniffing" exercise.

If you are starting from scratch, i.e., you do not have that exercise already loaded from previous use:

vmconfigure-populate
vmconfigure-contruct-network
vmconfigure-poweron

This avoids the script that bestows IP addresses on the VMs (vmconfigure-guestOS-internal-settings). That's because for this exercise we want them to be address free. Once the machines are up, on both CLIENT and SERVER log in as student, bring up the graphical desktop (startx), open a terminal window (terminal window icon under "Activities" drop-down menu), and become root within the terminal (sudo su -).

If you are not starting from scratch, already having the CLIENT and SERVER machines in VirtualBox and wishing to preserve them, take those same steps as just described above to arrange your desktop. Then, since your machines may already have some addresses, remove them in both:

ifconfig enp0s3 0.0.0.0
ifconfig enp0s3 down

Address autoconfiguration

Now in CLIENT:

ifconfig -a 

Note there is neither an ipv4 nor ipv6 address shown for the enp0s3 interface. Note also the presence and value of the ethernet address. Now activate enp0s3:

ifconfig enp0s3 up

Examine again:

ifconfig -a 

An ipv6 address has popped up on enp0s3. That's unfamiliar; it never happened with ipv4. Indeed, note that nothing popped up here for ipv4, only ipv6. For being activated the interface automatically got an ipv6 address somehow. If you want to isolate this lengthy address for visual clarity:

ifconfig enp0s3 | grep inet6 | gawk '{print $2}'

(Another way to examine ipv6 addresses, in full form, is cat /proc/net/if_inet6.)

The new ipv6 address is the product of ipv6's autoconfiguration feature. ipv4 has no such feature. There are other more traditional ways an interface could get an ipv6 address (manual configuration, ipv6 dhcp) but those acquired this way are called link-local addresses and work only within the local network.

Autoconfiguration constructs an address that embeds the interface's existing built-in MAC address. Because MAC's are globally unique, autoconfiguration reckons that so will be its constructed ipv6 address. But just to make sure it checks with other machines on the network. In order to examine that interaction, let's use a 3rd machine. 

In THIRDMACHINE:

timeout  30  tcpdump  -i  enp0s3   "icmp6 && ip6[40] == 135"  -w  neighborsolicitation.cap

The filter expression (between the quotes) limits capture to icmp6 Neighbor Solicitation Messages. tcpdump will remain up and running for 30 seconds. During that interval visit both CLIENT and SERVER, in that order, and execte on each:

ifconfig  enp0s3  down
ifconfig  enp0s3  up

Pause for a moment then go to THIRDMACHINE and terminate tcpdump (ctrl-C keystroke). It will leave behind a file named neighborsolicitation.cap containing any neighbor solicitation frames that were seen. There will be one from each machine, generated when it activated (ifconfig enp0s3 up) its interface. Note the MAC addresses of the two machines. Then open the capture file in wireshark:

wireshark  neighborsolicitation.cap  &

The first neighbor solicitation is from CLIENT. But note its ethernet source and destination. The source is an ethernet address used for ipv6 multicast. What about the destination? You should  recognize it. Whose is it? Is CLIENT ipsolocutive?? Read the file via tcpdump instead of wireshark.

tcpdump  -tr  neighborsolicitation.cap

and note the wording it uses. Mine looks like:

   IP6 :: > ff02::1:ff5b:548f: ICMP6, neighbor solicitation, who has fe80::a00:27ff:fe5b:548f, length 32

The neighbor solicitation from SERVER also has SERVER's own MAC address as its destination. Read page 781 and 806-807of the Forouzan textbook on autoconfiguration to neighbor solicitation's role in it.

Using your new ipv6

Now that both machines have ipv6 addresses they should be able to interact. Application and transport protocols, above ipv6, should be able to run over it. Here are three familiar examples.. Run these test activites in CLIENT, keying or pasting in SERVER's ipv6 address where indicated:

ping -6 -c5 -I enp0s3 <SERVER's ipv6 address>

ssh -6 student@<SERVER's ipv6 address>%enp0s3

nc <SERVER's ipv6 address>%enp0s3 7     (provided on SERVER you first "undisable" echo protocol in /etc/xinetd.d/echo-stream and restart xinted to activate the echo protocol)

ipv6 should pass the tests. You should receive ping replies. You should be able to get logged in to SERVER, look around if you wish then "exit" to back out. You should be able to type text into nc and get it echoed back to you (terminate nc with ctrl-C keystroke).

ipv6 is ipv4's understudy here. In the network layer it has filled in for ipv4's absence and supported the other layers' regular activity. It illustrates the network model's property of interchangeability of implementations at each layer.

What to turn in

autoconfiguration.zip - a zip file that that contains three other files:

- neighborsolicitation.cap - the file you produced on THIRDMACHINE

- using-ipv6.jpg - a screenshot that looks just like this, showing your performance of the above 3 test activites

- written-answers.txt - a text file with your writtne answers to the following two questions.

1. Autoconfiguration constructs for an interface a "link-local" address which, in a slightly indirect way, embeds its existing MAC address. You can find explanatory examples in Forouzn pp. 780-781, and by observing and comparing a VM interface's MAC versus ipv6 autoconfigured link-local addresses. In Forouzan's exercise 9 on page 784, from the given MAC, construct the link-local address that autoconfiguration will produce. (The exercise asks for the "interface identifier," I am asking for the full ipv6 address). What is the address in standard form?

2. In discussing autoconfiguration above I pointed out an oddity about the destination address in the neighbor solicitation frame CLIENT transmitted. Namely, it was CLIENT's own ipv6 address. I understand why a machine's address would appear in the source address field of a frame it sent, but why in the destination field? Is CLIENT talking to itself? Neighbor solicitation's general purpose is to ensure address uniqueness. That might help explain why the protocol would place the address of the source in the destination field. Why was a source machine's address placed in a destination address field?