It’s time to explore the finer points of IPv6. A great place to start is by showing you how to address a host and what gives it the ability to find other hosts and resources on a network.
We’ll also demonstrate a device’s ability to automatically address itself something called stateless autoconfiguration, plus another type of autoconfiguration known as stateful. Keep in mind that stateful autoconfiguration uses a DHCP server in a very similar way to how it’s used in an IPv4 configuration.
We’ll show you how the internet control message protocol (ICMP) and multicast works for us on an IPv6 network.
Autoconfiguration
Auto-configuration is an incredibly useful solution because it allows devices on a network to address themselves with a link-local unicast address. This process happens through first learning the prefix information from the router and then appending the device’s own interface address as the interface ID. But where does it get that interface ID?
Well, you know every device on an Ethernet network has a physical MAC address, and that’s exactly what’s used for the interface ID. But since the interface ID in an IPv6 address is 64 bits in length and a MAC address is only 48 bits, where do the extra 16 bits come from? The MAC address is padded in the middle with the extra bits it’s padded with FFFE.
For example, let’s say we have a device with a MAC address that looks like this;
0060:d673:1987And after it’s been padded, it would look like this
0260:d6FF:FE73.1987So where did that 2 at the beginning of the address come from? Another good question. You see, part of the process of padding (called modified eui-64 format) changes a bit to specify if the address is locally unique or globally unique. And the bit that gets changed is the seventh bit in the address. A bit value of 1 means globally unique, and a bit value of 0 means locally unique, so looking at this example, would you say that this address is globally or locally unique? If you answered that it’s a globally unique address, you’re right! Trust us, this is going to save you time in addressing your host machines because they communicate with the router to make this happen.
To perform auto configuration, a host goes through a basic two-step process:
- First, the host needs the prefix information (similar to the network portion of an IPv4 address) to configure its interface, so it sends a router solicitation (RS) request for it. This RS is then sent out as a multicast to each router’s multicast address. The actual information being sent is a type of ICMP message, and like everything is networking, this ICMP message has a number that identifies it. The RS message is ICMP type 133.
- The router answers back with the required prefix information via a router advertisement (RA). An RA message also happens to be a multicast packet that’s sent to each node’s multicast address and is ICMP type 134. RA messages are sent on a periodic basis, but the host sends the RS for an immediate response so it doesn’t have to wait until the next scheduled RA to get what it needs.
These two steps are shown in the picture below.
By the way, this type of autoconfiguration is also known as stateless autoconfiguration because it doesn’t contact or connect and receive any further information from the other device. We’ll get to the stateful configuration when we talk about DHCPv6 in a minute.
Now let’s take a look at how to configure Cisco routers with IPv6
- Also Read: How to Configure Cisco Routers?
Configuring Cisco Routers with IPv6
In order to enable IPv6 on a router, you have to use the ipv6 unicast-routing global configuration command:
Corp(config)#ipv6 unicast-routingBy default, IPv6 traffic forwarding is disabled, so using this command enables it. Also, as you’ve probably guessed, IPv6 isn’t enabled by default on any interfaces either, so we have to go to each interface individually and enable it.
There are a few different ways to do this, but a really easy way to just add an address to the interface. You use the interface configuration command ipv6 address <ipv6prefix>/<prefix-length>[eui-64] to get this done.
Here’s an example:
Corp(config-if)#ipv6 address 2001:db8:3c4d:1:0260.d6FF.FE73.1987/64You can specify the entire 128-bit global IPv6 address or you can use the eui-64 option. Remember, the eui-64 format allows the device to use its MAC address and pad it to make the interface ID. Check it out.
Corp(config-if)#ipv6 address 2001:db8:3c4d:1::/64 eui-64As an alternative to typing in an IPv6 address on a router, you can enable the interface instead to permit the application of an automatic link-local address.
To configure a router so that it only uses link-local addresses, use the ipv6 enable interface configuration command:
Corp(config-if)#ipv6 enableOkay, now let’s dive into stateful IPv6 configuring a DHCP server for IPv6 use.
DHCPv6
DHCPv6 works pretty much the same way DHCP does in v4, with the obvious difference that it supports the new addressing scheme for IPv6. And it might come as a surprise, but there are a couple of other options that DHCP still provides for us that auto-configuration doesn’t. we are serious there’s absolutely no mention of DNS servers, domain names, or any of the other options that DHCP has always provided for us via IPv4 with auto-configuration. This is a big reason why it’s likely we’ll still be using DHCP in IPv6 most of the time.
Upon booting up in IPv4, a client sent out a DHCP discover message looking for a server to give it the information it needs. But remember, in IPv6, the RS and RA process happens first.
If there’s a DHCPv6 server on the network, the RA that comes back to the client will tell it if DHCP is available for use. If a router isn’t found, the client will respond by sending out a DHCP Solicit message that actually a multicast message addressed with a source of ff02::1:2, meaning all DHCP agents, both servers and relays.
It’s good to know that there’s some support for DHCPv6 in the Cisco IOS. But it’s limited to a stateless DHCP server, meaning it doesn’t offer any address management of the pool, plus the options available for configuring that address pool are limited to the DNS, domain name, and SIP servers only.
This means that you’re definitely going to need some other server around that can supply and dispense all the additional, required information, as well as manage the address assignment. Anyway, here’s how the configuration looks for the stateless DHCP server in the router IOS it’s really close to what we’d configure with IPv4.
Router1(config)#ipv6 dhcp pool ?
WORD DHCP pool name
Router1(config)#ipv6 dhcp pool test
Router1(config-dhcp)#?
IPv6 DHCP configuration commands:
Default set a command to its defaults
Dns-server DNS servers
Domain-name domain name to complete unqualified host names
Exit exit from DHCPv6 configuration mode
No negate a command or set its defaults
Prefix-delegation IPv6 prefix delegation
Sip SIP servers options
Router1(config-dhcp)#dns server ?
Hostname or X:X:X:X::X server’s name or IPv6 address
Router1(config-dhcp)#domain-name lammle.com
Router1(config-dhcp)#prefix-delegation ?
X:X:X:X::X/<0-128> IPv6 x:x::y/<z>
Aaa Acquire prefix from AAA
Pool IPv6 prefix pool
Router1(config-dhcp)#prefix-delegation pool ?
WORD IPv6 prefix pool
Rotuer1(config-dhcp)#prefix-delegation pool test?
Lifetime configure prefix lifetimes
<cr>
Router1(config-dhcp)#prefix-delegation pool test lifetime ?
<60-4294967295> valid lifetime (seconds)
At expire prefix at a specific time/date
Infinite infinite valid lifetime
Router1(config-dhcp)#prefix-delegation pool test lifetime 3600 ?
<60-4294967295> preferred lifetime (seconds)
Infinite infinite preferred lifetime
Router1(config-dhcp)#prefix-delegation pool test lifetime 3600 3600 ?
<cr>
Router1(config-dhcp)#prefix-delegation pool test lifetime 3600 3600 Notice that just like in DHCP with IPv4, you don’t need to set a lifetime. Okay now that we’ve got the pool configured, we just have to assign it to an interface, a departure from IPv4.
Router1(config)#int fa 0/0
Router1(config-if)#ipv6 dhcp server ?
WORD name of IPv6 DHCP pool
Router1(config-if)#ipv6 dhcp server testSweet we now have a fully configured DHCPv6 server applied to our interface fa0/0!
ICMPv6
IPv4 used ICMP for many things, such as error messages like destination unreachable, and troubleshooting functions like Ping and Traceroute. ICMPv6 still does those things for us, but unlike its predecessor, the v6 flavor isn’t implemented as a separate layer 4 protocol. It’s an integrated part of IPv6 and is carried after the basic IPv6 header information as an extension header. And ICMPv6 adds another cool feature it prevents IPv6 from doing any fragmentation through an ICMPv6 process called path MTU discovery.
This is how it works: The source node of a connection will send a packet that’s equal to the MTU size of its local link’s MTU. As this packet traverse the path towards its destination, any link that has an MTU smaller than the size of the current packet will force the intermediate router to send a “packet too big” message back to the source machine. This message tells the source node what the maximum size is that the restrictive link will allow and asks the source to send a new scaled-down packet that can pass through. This process will continue until the destination is finally reached, with the source node now sporting the new path’s MTU. So now, when the rest of the data packets are transmitted, they’ll be protected from fragmentation. ICMPv6 now takes over the task of finding the address of other devices on the local link. Address Resolution Protocol used to perform this function for IPv4, but that’s been renamed Neighbor discovery in ICMPv6. This process is accomplished by using a multicast address called the solicited-node address, and all hosts join this multicast group when they connect to the network. Part of their IPv6 address (the 24 bits farthest to the right) is added to the end of the multicast address FF02:0:0:0:0:1: FF/104. When this address is queried, the corresponding host will send back its layer 2 address. Devices can find and keep track of other neighbor devices on the network is pretty much the same way. When we talked about RA and RS messages earlier and told you that they use multicast traffic to request and send address information, that too was a function of ICMPv6 specifically, neighbor discovery.
In IPv4, the protocol IGMP was used to allow a host device to tell its local router that it was joining a multicast group and would like to receive the traffic for that group. This IGMP function has been replaced by ICMPv6, and the process has been renamed multicast listener discovery.
IPv6 Routing Protocols
Most of the routing protocols we’ve already seen have been upgraded for use in IPv6 networks. Also, many of the functions and configurations that we’ve already learned will be used in almost the same way as they’re used now. Knowing that broadcasts have been eliminated in IPv6, it follows that any protocols that use entirely broadcast traffic will go the way of the dodo but unlike the dodo, it’ll be good to say goodbye to these bandwidth-hogging, performance-annihilating little gremlins!
The routing protocols that we’ll still use in v6 got a new name and a facelift. Let’s talk about a few of them now.
First on the list is RIPng (next generation). Those of you who have been in IT for a while know that RIP has worked very well for us on smaller networks, which happens to be the very reason it didn’t get whacked and will still be around in IPv6. And we still have EIGRPv6 because it already had protocol-dependent modules and all we had to do was add a new one to it for the IPv6 protocol. Rounding out our group of protocol survivors is OSPFv3 that’s no typo, it really is v3. OSPF for IPv4 was actually v2, so when it got its upgrade to IPv6, it became OSPFv3.
RIPng
To be honest, the primary features of RIPng are the same as they were with RIPv2. It is still a distance-vector protocol, has a max hop count of 15, and uses split horizon, poison reverse, and other loop avoidance mechanisms, but it now uses UDP port 521.
And it still uses multicast to send its updates too, but in IPv6, it uses FF02::9 for the transport address. This is actually kind of cool since, in RIPv2, the multicast address was 224.0.0.9, so the address still has a 9 at the end in the new IPv6 multicast range. In fact, most routing protocols got to keep a little bit of their IPv4 identifies like that.
But of course, there are differences in the new version of it wouldn’t be a new version, would it? We know that routers keep the next-hop addresses of their neighbor routers for every destination network in their routing table. The difference is that with RIPng, the router keeps track of this next-hop address using the link-local address, not a global address.
Probably one of the biggest changes with RIPng (and all of the IPv6 routing protocols for that matter) is the fact that you configure or enable the advertisement of a network from interface configuration mode instead of with a network command in router configuration mode.
So, in RIPng’s case, if you enable it directly on an interface without going into router configuration mode and starting a RIPng process, a new RIPng process will simply be started for you. It will look something like this:
Router1(config-if)#ipv6 rip 1 enableThat 1 you see in this command is a tag that identifies the process of RIPng that’s running, and as we said, this will start a process of RIPng so you don’t have to go into router configuration mode.
But if you need to go to router configuration mode to configure something else like redistribution, you still can. If you do that, it will look like this on your router:
Router1(config)#ipv6 router rip 1
Router1(config-rtr)#So just remember that RIPng will pretty much work the same way as with IPv4, with the biggest difference being that it uses the network itself instead of using the network command you used to use to enable the interface to route the connected network.
EIGRPv6
As with RIPng, EIGRPv6 works much the same as in its IPv4 predecessor does most of the features that EIGRP provided before EIGRPv6 will still be available.
EIGRPv6 is still an advanced distance-vector protocol that has some link-state features. The neighbor discovery process using hellos still happens, and it still provides reliable communication with a reliable transport protocol that gives us a loop-free fast convergence using the Diffusing Update Algorithm (DUAL).
Hello, packets and updates are sent using multicast transmission, and as with RIPng, EIGRPv6’s multicast address stayed almost the same. In IPv4 it was 224.0.0.10; in IPv6, it’s FF02::A(A=10 in hexadecimal notation).
But obviously, there are differences between the two versions. Most notably, and just as with RIPng, the use of the network command is gone, and the network and interface to be advertised must be enabled from interface configuration mode. But you still have to use the router configuration mode to enable the routing protocol in EiGRPv6 because the routing process must be literally turned on like an interface with the no shutdown command interesting!
The configuration for EIGRPv6 is going to look like this:
Router1(config)#ipv6 router eigrp 10The 10, in this case, is still the autonomous system (AS) number. The prompt changes to (configrtr), and from here you must perform a no shutdown:
Router1(config-rtr)#no shutdownOther options also can be configured in this mode, like redistribution.
So now, let’s go to the interface and enable IPv6:
Router1(config-if)#ipv6 eigrp 10The 10 in the interface command again references the AS number that was enabled in the configuration mode.
Last to check out in the out-group is what OSPF looks like in the IPv6 routing protocol.
OSPFv3
The new version of OSPF continues the trend of the routing protocols having many similarities with their IPv4 versions.
The foundation of OSPF remains the same it is still a link-state routing protocol that divides an entire internetwork or autonomous system into areas, making a hierarchy. And just trust us really thankful that multi-area OSPF is out of scope for the CCNA objectives at least.
In OSPF version 2, the router ID (RID) is determined by the highest IP addresses assigned to the router (or you could assign it). In version 3, you assign the RID, area ID, and link-state ID, which are still 32-bit values but are not found using the IP address anymore because an IPv6 address is 128 bits. Changes regarding how these values are assigned, along with the removal of the IP address information from OSPF packet headers, makes the new version of OSPF capable of being routed over almost any Network Layer protocol cool!
Adjacencies and next-hop attributes now use link-local addresses, and OSPFv3 still uses multicast traffic to send its updates and acknowledgments, with the addresses FF02::5 for OSPF routers and FF02::6 for OSPF designated routers. These new addresses are the replacements for 224.0.0.5 and 224.0.0.6, respectively.
Other, less flexible IPv4 protocols don’t give users the ability that OSPFv2 does to assign specific networks and interfaces into the OSPF process, however, this is something that is still configured under the router configuration process. And with OSPFv3, just as with the other IPv6 routing protocols we’ be talked about, the interfaces and therefore the networks attached to them are configured directly on the interface in interface configuration mode.
The configuration of OSPFv3 is going to look like this:
Router1(config)#ipv6 router ospf 10
Router1(config-rtr)#router-id 1.1.1.1You get to perform some configurations form router configuration modes like summarization and redistribution, but we don’t even need to configure OSPFv3 from this prompt if we configure OSPFv3 from the interface.
When the interface configuration is completed, the router configuration process is added automatically and the interface looks like this:
Router1(config-if)#ipv6 ospf 10 area 0.0.0.0So, if we just go to each interface and assign a process ID and area proof, we’re done! With all that behind you, it’s now time to move on and learn about how to migrate to IPv6 from IPv4.