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 the DHCP.
But now we have new options including EUI-64
and SLAAC
Working with 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.
The IPv6 settings look familiar, but it's 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 the router
Many of the commands we're 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 is 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 IP's 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.
A quick ping confirms the name is mapping to the IP
correctly
Let's take a step back and think about link local addresses again.
We don't usually configure them.
They're automatically generated This uses a system called EUI-64.
The idea behind EUI-64 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 portion 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 that 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 manufacturers 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 seventh bit is flipped.
To do this, find the value of the seventh bit.
If it's zero, change it to a one to one Change it to a zero.
Why is this done?
Because this bit has a 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 EUI-64.
address.
So that's the official way to generate a link local address.
Some operating systems like Windows have their own way of generating addresses.
Why? I don't know.
They just want to be different, I guess.
EUI can be used for other addresses as well.
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 addresses here.
It's easy to tell
it's in an EUI-64 address because of the FF FE in the address.
Notice that this doesn't override the other IP addresses we have configured.
It just adds a new one
The two quiz questions here are,
well, interesting, but they're also quite tricky.
Let's call these ones optional.
There are more ways to have addresses dynamically assigned.
But first, we need to know about the Neighbor 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 a 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, and we'll talk about that soon.
And it includes a tool called duplicate address detection.
This checks if there are any IP conflicts when assigning a new address.
At the core of NDP is ICMP version six,
ICMP is the protocol that sends messages between devices.
This includes ping and often traceroute.
There are four ICMP messages that NDP uses as we'll soon see.
The router has information that the client needs.
This could be something like
IP address information prefix length and things like these.
The client can use NDP to ask the router for this information.
It does this by sending a neighbor 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 because they 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 take a moment to clear it up.
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 this out to make things easier.
A router takes the last 24 bits of the Unicast address
and use them as a last 24 bits of the solicited node multicast address
Let's see that on the 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's 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 with up 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.
So the first thing it will do is it will look in its neighbor
cache to see if it has previously learned the Mac
If it's not there, it needs to learn it. NDP sends
a neighbor solicitation message to ask who owns that IP address.
But this isn't a broadcast. NS messages
are sent to the solicited node multicast address.
The sending 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 the network.
IPv4 would broadcast to all of them,
IPv6 multicasts to one or a few.
Much better.
The device receives the neighbor solicitation message
and responds with a neighbor advertisement message.
This time it's a Unicast message.
The NA message includes the devices MAC address
The original requester can now update the neighbour cache.
Detecting duplicate addresses, that is IP conflicts is a slight variation
of this neighbor discovery process. When an IP is auto configured.
It will send a neighbor solicitation message to the solicited
node multicast address for that IP.
If some device is already using that IP, it will see this message
and it will reply.
If there is no reply, then the address is still 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.
We can now get into
some truly 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 IP are in use and which aren't.
It might sound weird, but 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 the 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 its own IP.
There's no need to track anything.
The client then combines the prefix with the host portion to get a full IP.
He then confirmed its 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
will then configure R2 to be a SLAAC client.
Step one is to
enable IPv6 Unicast routing
certain IPv6 functions won't work without this being enabled
first
As soon as we configure out 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 auto config
command
Looking at the interfaces,
we can see that this one has an automatically configured IP.
Notice that the second half looks similar to a 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, it'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 the DNS servers, for example?
The client needs to know about those as well.
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
dhcp v6 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, and that sort of thing.
NDP is still used to be 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 easy 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 a pool
I've named this one test stateful.
Next the IPv6
prefix that will be handed out to the clients
and then any other options.
I'm just going to add a DNS server and a 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 on 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.
And 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 interface not interfaces
let's try that again.
But this time we'll use stateless config.
In the background of this video, I have already removed the previous
config from these routers
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, just let me fix that typo.
This tells the client to get its
IP through SLAAC, but to use DHCP for other options
we configure
R2, our client, the same way we do for SLAAC.
The last thing to do
is confirm that it has worked
and there it is.
To summarize, Stateful
DHCP is the traditional type of DHCP that hands out
IPs and other options and tracks leases,
stateless DHCP uses SLAAC to assign an IP address
and the 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 is about routing.
That includes static IP routing and Ospf version three.
I hope to see you there.