Chapter 1 – Static Addresses
There’s a whole new way of assigning addresses to devices with IPv6. Of course, we can still do this manually, and we can still use DHCP. But now we have new options, including EUI64 and SLAAC.
Configuring IPv6 addresses really isn’t that hard. Here we have a network card on a Windows workstation.
See how there’s a TCP/IP stack for IPv4 and IPv6? That’s dual-stack that we’ve spoken about a few times.
The IPv6 settings look familiar, but still a bit different. We can still use DHCP, or one of the fascinating new technologies to get an IP automatically.
Or, we can configure it statically.
But this is a CCNA series, so we’ll spend most of our time on a router.
Many of the commands we’ve familiar with still work. We just use ‘ipv6’ instead of ‘ip’. For example, ‘show ipv6 interface brief’.
We have no IP addresses so far
Now to configure a global unicast address. Under the interface, we just use the ‘ipv6 address’ command.
It’s almost the same as IPv4, except we use CIDR notation for the prefix length, not a dotted-decimal subnet mask.
Looking at our interface list again, we can see two new IP addresses. One is the global unicast address that we just configured. Of course, we can use this to ping other addresses.
There’s also a link-local address. This is created automatically when IPv6 is enabled on an interface.
Notice when we ping, it asks for the output interface? Do you know why? Link-local IPs are fully functional, with the exception of being non-routable.
Because of this, all link-local IPs are in the same subnet. That is, fe80:: /64. So the router needs to know which interface to use for the ping.
One final trick is statically mapping an IP to a hostname. This is done with the ‘ipv6 host’ command, followed by the name and IP. Remember, all these commands are in the study notes.
Normally, this is a DNS server’s job, but we can do it here too.
A quick ping confirms that the name is mapping to the IP correctly.
Chapter 2 – EUI64
Let’s take a step back, and think about the link-local addresses again. We don’t usually configure them, they’re automatically generated.
This uses a system called EUI64. The idea behind EUI64 is that you supply the prefix, and the host portion of the IP is automatically generated.
In the case of link-local addresses, the prefix is always fe80.
The question is, how is the host potion generated, without causing IP conflicts with other devices?
Well, your network card already has a unique address – Its MAC address.
Follow along with me here. Open a command prompt and find your MAC address. Now write the MAC address down.
The MAC address is 48 bits long and is made up of two parts. The first half is the OUI, which is the manufacturer’s ID. The second half is the NIC ID.
The host portion of the link-local address is 64-bits long, so the MAC needs to be extended.
The hex number ‘FF FE’ is added right in the middle of the MAC address.
Next, the weirdest thing happens. The 7th bit is flipped. To do this, find the value of the 7th bit. If it’s a zero, change it to a one. If it’s a one, change it to a zero.
Why is this done? Because this bit has special meaning within MAC addresses
Once we add the prefix to this host ID, we have the full IP address. This is known as a modified EUI64 address.
So that’s the official way to generate a link-local address.
Some operating systems, like Windows, have their own way of generating this address. Why? I don’t know. They just want to be different I guess.
EUI can be used for other addresses too, and the same principles apply.
Under the interface, we give the router a prefix, and give it the eui-64 keyword.
Let’s take a look at the interfaces again…
…and we can see the new IP address here. It’s easy to tell it’s a EUI64 address because of the ‘FFFE’ in the address.
Notice that this doesn’t overwrite the other IP addresses we’ve configured? It adds another one.
The two quiz questions here are… interesting… but they’re also tricky. Let’s call these ones optional.
Chapter 3 – Neighbour Discovery Protocol
There are more ways to have addresses dynamically assigned. But first, we need to know about the Neighbour Discovery Protocol or NDP.
NDP is a collection of tools that are critical to IPv6 operating correctly.
It resolves IP addresses to MAC addresses. In IPv4, this was done by ARP, The Address Resolution Protocol. In IPv6, that’s NDPs job.
It discovers IPv6 routers and other devices in the local network. This is useful if a client is trying to find a default gateway.
It can automatically discover network prefixes. This is clearly useful for assigning IP addresses to clients. We’ll talk about this one soon.
And it includes a tool called Duplicate Address Detection. This checks if there are any IP conflicts when assigning a new IP address.
At the core of NDP is ICMP version 6. ICMP is the protocol that sends messages between devices. This includes ping, and sometimes traceroute.
There are four ICMP messages that NDP uses, as we’ll see soon.
The router has information that the client needs. This could be something like IP address information, prefix length, and things like this.
The client can use NDP to ask the router for this information.
It does this by sending a Neighbour Solicitation message from its link-local address to all IPv6 routers on the link.
There are no broadcasts anymore, so it uses the ‘all routers’ multicast group.
If a router has the requested information, it replies with a router advertisement message. This message contains the information that the client wants.
Before continuing, a brief word on multicast…
All IPv6 multicast groups start with ff. If you see any of these starting with ff02, that’s before they’re link-local multicast groups. These addresses are for the local subnet only.
Here are some of the common multicast groups that you might see.
Of particular interest is the Solicited-Node Multicast Address. This one’s a bit confusing, so let me clear it up here.
Every time we configure a unicast address on an interface, the interface also joins a solicited-node multicast group.
The IP of the group can vary, but it will always follow this format. It selects the last 24-bits of the address based on the unicast address on the interface.
Our router is using this unicast address. Let’s expand that out to make things easier…
The router takes the last 24-bits of the unicast address and uses them as the last 24-bits of the solicited-node multicast address.
Let’s see it on a router. First, let’s configure the unicast address…
We’ll now use ‘show ipv6 interface’ to look at the interface in detail. As you can see, there is a link-local address, and a global-unicast address.
We can also see that this interface has joined a few multicast groups. Notice that there’s a corresponding group for each unicast address?
The big question is, what are these groups used for?
For that, we need to think about how IPv6 devices are discovered on the network. In particular, how IPv6 addresses are mapped to MAC addresses.
In IPv4, this is done using ARP, the Address Resolution Protocol. This doesn’t work in IPv6, as ARP relies on broadcasts.
Instead, the process is like this… A device wants to send a message to another device. It needs to know the MAC address to do this.
The first thing it will do is look in the Neighbour Cache to see if it has previously learned the MAC.
If it’s not there, it needs to learn it. NDP sends an NS message, to ask who owns that IP address.
But this isn’t broadcast. NS messages are sent to the solicited-node multicast address.
The device already knows the IP address, so it can easily take the last 24-bits of the IP address, and use them to work out what the solicited-node multicast address is.
Imagine if there were 200 workstations on this network. IPv4 would broadcast to them all. IPv6 multicasts to one, or a few. Much better!
The device receives the Neighbour Solicitation message and responds with a Neighbour Advertisement message. This time it’s a unicast message.
The NA message includes the device’s MAC address. The original requester can now update their neighbour cache.
Detecting duplicate addresses, that is, IP conflicts is a slight variation of the Neighbour Discovery process.
When an IP is auto-configured, it will send an NS message to the solicited-node multicast address for that IP.
If some device already has this IP, it will see this message and reply. If there’s no reply, then the address is available for use.
Now that we have a good understanding of NDP, we can start thinking about how devices can obtain their IP addresses automatically.
Chapter 4 – SLAAC
We can now get into some true dynamic IP configuration. There are a couple of options available to us.
The first one is called SLAAC, or Stateless Address Auto Configuration.
So what does stateless mean? That’s an easy one to answer! Stateless just means that nothing will keep track of the IP addresses that have been assigned.
This is in contrast to DHCP, which keeps a database of assigned IPs.
SLAAC is stateless, so it doesn’t care which IPs are in use and which aren’t. As you’ll soon see, this isn’t a problem at all.
When a client needs an IP address, it will use NDP to request one. It will send a Router Solicitation message to the ‘all IPv6 routers’ group from its link-local address.
The client is really asking which prefix is in use on the local link
A router will respond with a Router Advertisement message. This is sent from its link-local address to the ‘All IPv6 Nodes’ multicast group.
In this message, it sends the prefix and the length for this link. It does not allocate the host portion of the IP.
The client generates this itself, using EUI-64. This is why SLAAC can be stateless. With each device generating it’s own IP, there’s no need to track anything.
The client then combines the prefix with the host portion to get a full IP. It then confirms it’s uniqueness using Duplicate Address Detection.
Configuring SLAAC on a router is not hard at all. We’re going to configure R1 to hand out prefixes. We’ll then configure R2 to be a SLAAC client.
Step 1 is to enable ipv6 unicast-routing. Certain IPv6 functions won’t work without this being enabled first.
As soon as we configure the router with a global unicast IP, it will start sending Router Advertisement messages.
In the RA messages, it includes the prefix from the interface.
Over on our client router, we just configure the interface to receive an IP address automatically. This is the ‘ipv6 address autoconfig’ command.
Looking at the interfaces, we can see that this one has an automatically configured IP. Notice the second half looks similar to the link-local address? That’s the EUI-64 process.
So, SLAAC is enabled automatically when we have a global IP configured. What if we don’t want that?
We can suppress all RA messages from the router with ‘ipv6 nd ra suppress’. This isn’t just SLAAC though, so use it with caution.
Well that’s nice and easy right? Well, there’s a problem. Can you see what it is? SLAAC doesn’t give the client any extra information.
What about DNS servers? The client will want to know about those.
For this reason, SLAAC hasn’t been widely adopted.
If we want to pass extra information to the router, we need to use another option, such as DHCP.
Chapter 5 – DHCPv6
DHCPv6 can be stateful, where leases are tracked, or stateless. Stateless DHCP is a new concept for IPv6, as it combines traditional DHCP with SLAAC.
The idea behind this is that a client IP is generated with SLAAC, and then the DHCP server assigns the rest of the options. DNS server IPs, domain names, that sort of thing.
NDP is still used with stateful DHCP. The client requests an IP from the router, and the router tells the client about a DHCP server.
It’s probably easier to see it in action…
We’ll now configure R1 as a stateful DHCP server. R2 will be the client
We must enable ipv6 unicast-routing before starting. Then we can create our pool. I’ve named this one TEST-STATEFUL.
Next, the IPv6 prefix that will be handed to clients.
And then any other options. I’m going to add a dns server and domain name.
We need to configure the interface too, starting with an IP.
The ‘ip dhcp server’ command tells the router which pool we want to use with this interface.
We then enable the ‘managed config’ flag in NDP. This tells the client that this will be stateful DHCP, not SLAAC.
Now, let’s configure the client, R2. We need to enable ipv6 routing globally, then we need to enable IPv6 on the interface.
Then it’s just a matter of configuring the interface with DHCP.
Looking at the interfaces, we can confirm this has worked.
Sorry, the command is ‘interface’, not ‘interfaces’
Let’s try that again, but this time with stateless config. In the background, I have already removed the previous config.
As before, we need ipv6 routing enabled, and a DHCP pool. This is only DHCP options this time. We don’t need a prefix, as this is delivered through SLAAC.
Under the interface, we configure an IP address as normal.
Then, we add the pool configuration.
And finally, we enable the ‘Other Config’ flag.
Sorry, let me fix that typo…
This tells the client to get it’s IP through SLAAC, but use DHCP for other options.
We configure R2, our client, the same way as we do for SLAAC.
The last thing to do is to confirm that it has worked… There it is!
To summarize, stateful DHCP is the traditional DHCP server that hands out IPs and other options, and tracks leases.
Stateless DHCP uses SLAAC to assign an IP address, and a DHCP server to assign options.
In today’s lab, we have five routers. R1 is to provide IP addresses to the other four. Your job is to configure this as shown, as well as troubleshoot why R5 is not working.
The configuration is not over! We’ve got one more IPv6 video in the series, and this one’s about routing.
That includes static IP routing, and OSPFv3.
See you there!