The following CCNA exam topics are covered in this chapter:

1.0 Network Fundamentals

•  1.8 Configure and verify IPv6 addressing and prefix
•  1.9 Compare IPv6 address types
  • 1.9.a Global unicast
  • 1.9.b Unique local
  • 1.9.c Link local
  • 1.9.d Anycast
  • 1.9.e Multicast
  • 1.9.f Modified EUI 64

3.0 IP Connectivity

•  3.3 Configure and verify IPv4 and IPv6 static routing

 We’ve covered a lot of ground in this book, and though the journey has been tough at times, it’s been well worth it! But our networking expedition isn’t quite over yet because we still have the vastly important frontier of IPv6 to explore. There’s still some expansive territory to cover with this subject, so gear up and get ready to discover all you need to know about IPv6. Understanding IPv6 is vital now, so you’ll be much better equipped and prepared to meet today’s real-world networking challenges as well as to ace the exam. This chapter is packed and brimming with all the IPv6 information you’ll need to complete your Cisco exam trek successfully, so get psyched—we’re in the home stretch!

I probably don’t need to say this, but I will anyway because I really want to go the distance and do everything I can to ensure that you arrive and achieve You absolutely must have a solid hold on IPv4 by now, but if you’re still not confident with it, or feel you could use a refresher, just page back to the chapters on TCP/IP and subnetting. And if you’re not crystal clear on the address problems inherent to IPv4, you really need to review Chapter 11, “Network Address Translation (NAT),” before we decamp for this chapter’s IPv6 summit push!

People refer to IPv6 as “the next-generation Internet protocol,” and it was originally created as the solution to IPv4’s inevitable and impending address-exhaustion crisis. Though you’ve probably heard a thing or two about IPv6 already, it has been improved even further in the quest to bring us the flexibility, efficiency, capability, and optimized functionality that can effectively meet our world’s seemingly insatiable thirst for ever-evolving technologies and increasing access. The capacity of its predecessor, IPv4, pales wan and ghostly in comparison, which is why IPv4 is destined to fade into history completely, making way for IPv6 and the future.

The IPv6 header and address structure has been completely overhauled, and many of the features that were basically just afterthoughts and addenda in IPv4 are now included as full-blown standards in IPv6. It’s power-packed, well equipped with robust and elegant features, poised and prepared to manage the mind-blowing demands of the Internet to come!

After an introduction like that, I understand if you’re a little apprehensive, but I promise—really—to make this chapter and its VIP topic pretty painless for you. In fact, you might even find yourself actually enjoying it—I definitely did! Because IPv6 is so complex, while still being so elegant, innovative, and powerful, it fascinates me like some weird combination of a sleek, new Aston Martin and a riveting futuristic novel. Hopefully you’ll experience this chapter as an awesome ride and enjoy reading it as much as I did writing it!

Why Do We Need IPv6?

Well, the short answer is because we need to communicate, and our current system isn’t really cutting it anymore. It’s kind of like the Pony Express trying to compete with airmail! Consider how much time and effort we’ve been investing for years while we scratch our heads to resourcefully come up with slick new ways to conserve bandwidth and IP addresses. Sure, variable length subnet masks (VLSMs) are wonderful and cool, but they’re really just another invention to help us cope while we desperately struggle to overcome the worsening address drought.

I’m not exaggerating, at all, about how dire things are getting, because it’s simply reality. The number of people and devices that connect to networks increases dramatically each and every day, which is not a bad thing. We’re just finding new and exciting ways to communicate to more people, more often, which is good thing. And it’s not likely to go away or even decrease in the littlest bit, because communicating and making connections are, in fact, basic human needs—they’re in our very nature. But with our numbers increasing along with the rising tide of people joining the communications party increasing as well, the forecast for our current system isn’t exactly clear skies and smooth sailing. IPv4, upon which our ability to do all this connecting and communicating is presently dependent, is quickly running out of addresses for us to use.

IPv4 has only about 4.3 billion addresses available—in theory—and we know that we don’t even get to use most of those! Sure, the use of Classless Inter-Domain Routing (CIDR) and Network Address Translation (NAT) has helped to extend the inevitable dearth of addresses, but we will still run out of them, and it’s going to happen within a few years. China is barely online, and we know there’s a huge population of people and corporations there that surely want to be. There are myriad reports that give us all kinds of numbers, but all you really need to think about to realize that I’m not just being an alarmist is this: there are about 7 billion people in the world today, and it’s estimated that only just under half of the population is currently connected to the Internet—wow!

That statistic is basically screaming at us the ugly truth that based on IPv4’s capacity, every person can’t even have a computer, let alone all the other IP devices we use with them! I have more than one computer, and it’s pretty likely that you do too, and I’m not even including phones, laptops, game consoles, fax machines, routers, switches, and a mother lode of other devices we use every day into the mix! So I think I’ve made it pretty clear that we’ve got to do something before we run out of addresses and lose the ability to connect with each other as we know it. And that “something” just happens to be implementing IPv6.

The Benefits and Uses of IPv6

So what’s so fabulous about IPv6? Is it really the answer to our coming dilemma? Is it really worth it to upgrade from IPv4? All good questions—you may even think of a few more. Of course, there’s going to be that group of people with the time-tested “resistance to change syndrome,” but don’t listen to them. If we had done that years ago, we’d still be waiting weeks, even months for our mail to arrive via horseback. Instead, just know that the answer is a resounding yes, it is really the answer, and it is worth the upgrade! Not only does IPv6 give us lots of addresses (3.4 × 10³⁸ = definitely enough), there are tons of other features built into this version that make it well worth the cost, time, and effort required to migrate to it.

Today’s networks, as well as the Internet, have a ton of unforeseen requirements that simply weren’t even considerations when IPv4 was created. We’ve tried to compensate with a collection of add-ons that can actually make implementing them more difficult than they would be if they were required by a standard. By default, IPv6 has improved upon and included many of those features as standard and mandatory. One of these sweet new standards is IPsec—a feature that provides end-to-end security.

But it’s the efficiency features that are really going to rock the house! For starters, the headers in an IPv6 packet have half the fields, and they are aligned to 64 bits, which gives us some seriously souped-up processing speed. Compared to IPv4, lookups happen at light speed! Most of the information that used to be bound into the IPv4 header was taken out, and now you can choose to put it, or parts of it, back into the header in the form of optional extension headers that follow the basic header fields.

And of course there’s that whole new universe of addresses—the 3.4 × 10³⁸ I just mentioned—but where did we get them? Did some genie just suddenly arrive and make them magically appear? That huge proliferation of addresses had to come from somewhere! Well it just so happens that IPv6 gives us a substantially larger address space, meaning the address itself is a whole lot bigger—four times bigger as a matter of fact! An IPv6 address is actually 128 bits in length, and no worries—I’m going to break down the address piece by piece and show you exactly what it looks like coming up in the section “IPv6 Addressing and Expressions.” For now, let me just say that all that additional room permits more levels of hierarchy inside the address space and a more flexible addressing architecture. It also makes routing much more efficient and scalable because the addresses can be aggregated a lot more effectively. And IPv6 also allows multiple addresses for hosts and networks. This is especially important for enterprises veritably drooling for enhanced access and availability. Plus, the new version of IP now includes an expanded use of multicast communication—one device sending to many hosts or to a select group—that joins in to seriously boost efficiency on networks because communications will be more specific.

IPv4 uses broadcasts quite prolifically, causing a bunch of problems, the worst of which is of course the dreaded broadcast storm. This is that uncontrolled deluge of forwarded broadcast traffic that can bring an entire network to its knees and devour every last bit of bandwidth! Another nasty thing about broadcast traffic is that it interrupts each and every device on the network. When a broadcast is sent out, every machine has to stop what it’s doing and respond to the traffic whether the broadcast is relevant to it or not.

But smile assuredly, everyone. There’s no such thing as a broadcast in IPv6 because it uses multicast traffic instead. And there are two other types of communications as well: unicast, which is the same as it is in IPv4, and a new type called anycast. Anycast communication allows the same address to be placed on more than one device so that when traffic is sent to the device service addressed in this way, it’s routed to the nearest host that shares the same address. And this is just the beginning—we’ll get into the various types of communication later in the section called “Address Types.”

IPv6 Addressing and Expressions

Just as understanding how IP addresses are structured and used is critical with IPv4 addressing, it’s also vital when it comes to IPv6. You’ve already read about the fact that at 128 bits, an IPv6 address is much larger than an IPv4 address. Because of this, as well as the new ways the addresses can be used, you’ve probably guessed that IPv6 will be more complicated to manage. But no worries! As I said, I’ll break down the basics and show you what the address looks like and how you can write it as well as many of its common uses. It’s going to be a little weird at first, but before you know it, you’ll have it nailed!

So let’s take a look at Figure 17.1, which has a sample IPv6 address broken down into sections.

As you can clearly see, the address is definitely much larger. But what else is different? Well, first, notice that it has eight groups of numbers instead of four and also that those groups are separated by colons instead of periods. And hey, wait a second there are letters in that address! Yep, the address is expressed in hexadecimal just like a MAC address is, so you could say this address has eight 16-bit hexadecimal colon-delimited blocks. That’s already quite a mouthful, and you probably haven’t even tried to say the address out loud yet!

2001:db8:3c4d:12:0:0:1234:56ab

2001:db8:3c4d:12::1234:56ab

2001:0000:0000:0012:0000:0000:1234:56ab

2001::12::1234:56ab

2001::12:0:0:1234:56ab

Address Types

We’re all familiar with IPv4’s unicast, broadcast, and multicast addresses that basically define who or at least how many other devices we’re talking to. But as I mentioned, IPv6 modifies that trio and introduces the anycast. Broadcasts, as we know them, have been eliminated in IPv6 because of their cumbersome inefficiency and basic tendency to drive us insane!

So let’s find out what each of these types of IPv6 addressing and communication methods do for us:

Unicast  Packets addressed to a unicast address are delivered to a single interface. For load balancing, multiple interfaces across several devices can use the same address, but we’ll call that an anycast address. There are a few different types of unicast addresses, but we don’t need to get further into that here.

Global unicast addresses (2000::/3)  These are your typical publicly routable addresses and they’re the same as in IPv4. Global addresses start at 2000::/3. Figure 17.2 shows how a unicast address breaks down. The ISP can provide you with a minimum /48 network ID, which in turn provides you 16-bits to create a unique 64-bit router interface address. The last 64-bits are the unique host ID.

Link-local addresses (FE80::/10)  These are like the Automatic Private IP Address (APIPA) addresses that Microsoft uses to automatically provide addresses in IPv4 in that they’re not meant to be routed. In IPv6 they start with FE80::/10, as shown in Figure 17.3. Think of these addresses as handy tools that give you the ability to throw a temporary LAN together for meetings or create a small LAN that’s not going to be routed but still needs to share and access files and services locally.

Unique local addresses (FC00::/7)  These addresses are also intended for nonrouting purposes over the Internet, but they are nearly globally unique, so it’s unlikely you’ll ever have one of them overlap. Unique local addresses were designed to replace site-local addresses, so they basically do almost exactly what IPv4 private addresses do: allow communication throughout a site while being routable to multiple local networks. Site-local addresses were deprecated as of September 2004.

Multicast (FF00::/8)  Again, as in IPv4, packets addressed to a multicast address are delivered to all interfaces tuned into the multicast address. Sometimes people call them “one-to-many” addresses. It’s really easy to spot a multicast address in IPv6 because they always start with FF. We’ll get deeper into multicast operation coming up, in “How IPv6 Works in an Internetwork.”

Anycast  Like multicast addresses, an anycast address identifies multiple interfaces on multiple devices. But there’s a big difference: the anycast packet is delivered to only one device—actually, to the closest one it finds defined in terms of routing distance. And again, this address is special because you can apply a single address to more than one host. These are referred to as “one-to-nearest” addresses. Anycast addresses are typically only configured on routers, never hosts, and a source address could never be an anycast address. Of note is that the IETF did reserve the top 128 addresses for each /64 for use with anycast addresses.

You’re probably wondering if there are any special, reserved addresses in IPv6 because you know they’re there in IPv4. Well there are—plenty of them! Let’s go over those now.

How IPv6 Works in an Internetwork

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.

I’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. I’ll also show you how Internet Control Message Protocol (ICMP) and multicasting works for us in an IPv6 network environment.

Corp(config)#ipv6 unicast-routing

Corp(config-if)#ipv6 address 2001:db8:3c4d:1:0260:d6FF.FE73:1987/64

Corp(config-if)#ipv6 address 2001:db8:3c4d:1::/64 eui-64

Corp(config-if)#ipv6 enable

Stateless Autoconfiguration (eui-64)

Autoconfiguration is an especially useful solution because it allows devices on a network to address themselves with a link-local unicast address as well as with a global 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, which is 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 I have a device with a MAC address that looks like this: 0060:d673:1987. After it’s been padded, it would look like this: 0260:d6FF:FE73:1987. Figure 17.4 illustrates what an EUI-64 address looks like.

So where did that 2 in the beginning of the address come from? Another good question. You see that 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 7th bit in the address.

The reason for modifying the U/L bit is that, when using manually assigned addresses on an interface, it means you can simply assign the address 2001:db8:1:9::1/64 instead of the much longer 2001:db8:1:9:0200::1/64. Also, if you are going to manually assign a link-local address, you can assign the short address fe80::1 instead of the long fe80::0200:0:0:1 or fe80:0:0:0:0200::1. So, even though at first glance it seems the IETF made this harder for you to simply understand IPv6 addressing by flipping the 7th bit, in reality this made addressing much simpler. Also, since most people don’t typically override the burned-in address, the U/L bit is a 0, which means that you’ll see this inverted to a 1 most of the time. But because you’re studying the Cisco exam objectives, you’ll need to look at inverting it both ways.

Here are a few examples:

• MAC address 0090:2716:fd0f
• IPv6 EUI-64 address: 2001:0db8:0:1:0290:27ff:fe16:fd0f

That one was easy! Too easy for the Cisco exam, so let’s do another:

• MAC address aa12:bcbc:1234
• IPv6 EUI-64 address: 2001:0db8:0:1:a812:bcff:febc:1234

10101010 represents the first 8 bits of the MAC address (aa), which when inverting the 7th bit becomes 10101000. The answer becomes A8. I can’t tell you how important this is for you to understand, so bear with me and work through a couple more!

• MAC address 0c0c:dede:1234
• IPv6 EUI-64 address: 2001:0db8:0:1:0e0c:deff:fede:1234

0c is 00001100 in the first 8 bits of the MAC address, which then becomes 00001110 when flipping the 7th bit. The answer is then 0e. Let’s practice one more:

• MAC address 0b34:ba12:1234
• IPv6 EUI-64 address: 2001:0db8:0:1:0934:baff:fe12:1234

0b in binary is 00001011, the first 8 bits of the MAC address, which then becomes 00001001. The answer is 09.

To perform autoconfiguration, a host goes through a basic two-step process:

1. 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 all routers (FF02::2). The actual information being sent is a type of ICMP message, and like everything in networking, this ICMP message has a number that identifies it. The RS message is ICMP type 133.
2. 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 the all-nodes multicast address (FF02::1) 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 Figure 17.5.

By the way, this type of autoconfiguration is also known as stateless autoconfiguration because it doesn’t contact or connect to and receive any further information from the other device. We’ll get to stateful configuration when we talk about DHCPv6 next.

But before we do that, first take a look at Figure 17.6. In this figure, the Branch router needs to be configured, but I just don’t feel like typing in an IPv6 address on the interface connecting to the Corp router. I also don’t feel like typing in any routing commands, but I need more than a link-local address on that interface, so I’m going to have to do something! So basically, I want to have the Branch router work with IPv6 on the internetwork with the least amount of effort from me. Let’s see if I can get away with that.

Ah ha—there is an easy way! I love IPv6 because it allows me to be relatively lazy when dealing with some parts of my network, yet it still works really well. By using the command ipv6 address autoconfig, the interface will listen for RAs and then, via the EUI-64 format, it will assign itself a global address—sweet!

This is all really great, but you’re hopefully wondering what that default is doing there at the end of the command. If so, good catch! It happens to be a wonderful, optional part of the command that smoothly delivers a default route received from the Corp router, which will be automatically injected it into my routing table and set as the default route—so easy!

IPv6 Header

An IPv4 header is 20 bytes long, so since an IPv6 address is four times the size of IPv4 at 128 bits, its header must then be 80 bytes long, right? That makes sense and is totally intuitive, but it’s also completely wrong! When IPv6 designers devised the header, they created fewer, streamlined fields that would also result in a faster routed protocol at the same time.

Let’s take a look at the streamlined IPv6 header using Figure 17.7.

The basic IPv6 header contains eight fields, making it only twice as large as an IP header at 40 bytes. Let’s zoom in on these fields:

Version  This 4-bit field contains the number 6, instead of the number 4 as in IPv4.

Traffic Class   This 8-bit field is like the Type of Service (ToS) field in IPv4.

Flow Label  This new field, which is 24 bits long, is used to mark packets and traffic flows. A flow is a sequence of packets from a single source to a single destination host, an anycast or multicast address. The field enables efficient IPv6 flow classification.

Payload Length  IPv4 had a total length field delimiting the length of the packet. IPv6’s payload length describes the length of the payload only.

Next Header  Since there are optional extension headers with IPv6, this field defines the next header to be read. This is in contrast to IPv4, which demands static headers with each packet.

Hop Limit  This field specifies the maximum number of hops that an IPv6 packet can traverse.

 For objectives remember that the Hop Limit field is equivalent to the TTL field in IPv4’s header, and the Extension header (after the destination address and not shown in the figure) is used instead of the IPv4 Fragmentation field.

Source Address  This field of 16 bytes, or 128 bits, identifies the source of the packet.

Destination Address  This field of 16 bytes, or 128 bits, identifies the destination of the packet.

There are also some optional extension headers following these eight fields, which carry other Network layer information. These header lengths are not a fixed number—they’re of variable size.

So what’s different in the IPv6 header from the IPv4 header? Let’s look at that:

• The Internet Header Length field was removed because it is no longer required. Unlike the variable-length IPv4 header, the IPv6 header is fixed at 40 bytes.
• Fragmentation is processed differently in IPv6 and does not need the Flags field in the basic IPv4 header. In IPv6, routers no longer process fragmentation; the host is responsible for fragmentation.
• The Header Checksum field at the IP layer was removed because most Data Link layer technologies already perform checksum and error control, which forces formerly optional upper-layer checksums (UDP, for example) to become mandatory.

 For the objectives, remember that unlike IPv4 headers, IPv6 headers have a fixed length, use an extension header instead of the IPv4 Fragmentation field, and eliminate the IPv4 checksum field.

It’s time to move on to talk about another IPv4 familiar face and find out how a certain very important, built-in protocol has evolved in IPv6.

ICMPv6

IPv4 used the ICMP workhorse for lots of tasks, including 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 3 protocol. Instead, it’s an integrated part of IPv6 and is carried after the basic IPv6 header information as an extension header. And ICMPv6 gives us another really cool feature—by default, it prevents IPv6 from doing any fragmentation through an ICMPv6 process called path MTU discovery. Figure 17.8 shows how ICMPv6 has evolved to become part of the IPv6 packet itself.

The ICMPv6 packet is identified by the value 58 in the Next Header field, located inside the ICMPv6 packet. The Type field identifies the particular kind of ICMP message that’s being carried, and the Code field further details the specifics of the message. The Data field contains the ICMPv6 payload.

Table 17.2 shows the ICMP Type codes.

ICMPv6 Type	Description
1	Destination Unreachable
128	Echo Request
129	Echo Reply
133	Router Solicitation
134	Router Advertisement
135	Neighbor Solicitation
136	Neighbor Advertisement

And this is how it works: The source node of a connection sends a packet that’s equal to the MTU size of its local link’s MTU. As this packet traverses the path toward 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 the maximum size 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 is used for router solicitation and advertisement, for neighbor solicitation and advertisement (i.e., finding the MAC data addresses for IPv6 neighbors), and for redirecting the host to the best router (default gateway).

Neighbor Discovery (NDP)

ICMPv6 also takes over the task of finding the address of other devices on the local link. The Address Resolution Protocol is used to perform this function for IPv4, but that’s been renamed neighbor discovery (ND) in ICMPv6. This process is now achieved via a multicast address called the solicited-node address because all hosts join this multicast group upon connecting to the network.

Neighbor discovery enables these functions:

• Determining the MAC address of neighbors
• Router solicitation (RS) FF02::2 type code 133
• Router advertisements (RA) FF02::1 type code 134
• Neighbor solicitation (NS) Type code 135
• Neighbor advertisement (NA) Type code 136
• Duplicate address detection (DAD)

The part of the IPv6 address designated by the 24 bits farthest to the right is added to the end of the multicast address FF02:0:0:0:0:1:FF/104 prefix and is referred to as the solicited-node address. 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 in pretty much the same way. When I talked about RA and RS messages earlier and told you that they use multicast traffic to request and send address information, that too is actually 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.

With IPv4, our hosts could have only one default gateway configured, and if that router went down we had to either fix the router, change the default gateway, or run some type of virtual default gateway with other protocols created as a solution for this inadequacy in IPv4. Figure 17.9 shows how IPv6 devices find their default gateways using neighbor discovery.

IPv6 hosts send a router solicitation (RS) onto their data link asking for all routers to respond, and they use the multicast address FF02::2 to achieve this. Routers on the same link respond with a unicast to the requesting host, or with a router advertisement (RA) using FF02::1.

But that’s not all! Hosts also can send solicitations and advertisements between themselves using a neighbor solicitation (NS) and neighbor advertisement (NA), as shown in Figure 17.10. Remember that RA and RS gather or provide information about routers, and NS and NA gather information about hosts. Remember that a “neighbor” is a host on the same data link or VLAN.

Solicited-Node and Multicast Mapping over Ethernet

If an IPv6 address is known, then the associated IPv6 solicited-node multicast address is known, and if an IPv6 multicast address is known, then the associated Ethernet MAC address is known.

For example, the IPv6 address 2001:DB8:2002:F:2C0:10FF:FE18:FC0F will have a known solicited-node address of FF02::1:FF18:FC0F.

Now we’ll form the multicast Ethernet addresses by adding the last 32 bits of the IPv6 multicast address to 33:33.

For example, if the IPv6 solicited-node multicast address is FF02::1:FF18:FC0F, the associated Ethernet MAC address is 33:33:FF:18:FC:0F and is a virtual address.

Duplicate Address Detection (DAD)

So what do you think are the odds that two hosts will assign themselves the same random IPv6 address? Personally, I think you could probably win the lotto every day for a year and still not come close to the odds against two hosts on the same data link duplicating an IPv6 address! Still, to make sure this doesn’t ever happen, duplicate address detection (DAD) was created, which isn’t an actual protocol, but a function of the NS/NA messages.

Figure 17.11 shows how a host sends an NDP NS when it receives or creates an IPv6 address.

When hosts make up or receive an IPv6 address, they send three DADs out via NDP NS asking if anyone has this same address. The odds are unlikely that this will ever happen, but they ask anyway.

 Remember for the objectives that ICMPv6 uses type 134 for router advertisement messages, and the advertised prefix must be 64 bits in length.

IPv6 Routing Protocols

All of the routing protocols we’ve already discussed have been tweaked and upgraded for use in IPv6 networks, so it figures that many of the functions and configurations that you’ve already learned will be used in almost the same way as they are now. Knowing that broadcasts have been eliminated in IPv6, it’s safe to conclude that any protocols relying entirely on broadcast traffic will go the way of the dodo. But unlike with the dodo, it’ll be really nice to say goodbye to these bandwidth-hogging, performance-annihilating little gremlins!

The routing protocols we’ll still use in IPv6 have been renovated and given new names. Even though this chapter’s focus is on the Cisco exam objectives, which cover only static and default routing, I want to discuss a few of the more important ones too.

First on the list is the IPv6 RIPng (next generation). Those of you who’ve been in IT for a while know that RIP has worked pretty well for us on smaller networks. This happens to be the very reason it didn’t get whacked and will still be around in IPv6. And we still have EIGRPv6 because EIGRP already had protocol-dependent modules and all we had to do was add a new one to it to fit in nicely with the IPv6 protocol. Rounding out our group of protocol survivors is OSPFv3—that’s not a typo, it really is v3! OSPF for IPv4 was actually v2, so when it got its upgrade to IPv6, it became OSPFv3. Lastly, for the new objectives, we’ll list MP-BGP4 as a multiprotocol BGP-4 protocol for IPv6. Please understand for the objectives at this point in the book, we only need to understand static and default routing.

Static Routing with IPv6

Okay, now don’t let the heading of this section scare you into looking on Monster.com for some job that has nothing to do with networking! I know that static routing has always run a chill up our collective spines because it’s cumbersome, difficult, and really easy to screw up. And I won’t lie to you—it’s certainly not any easier with IPv6’s longer addresses, but you can do it!

We know that to make static routing work, whether in IP or IPv6, you need these three tools:

• An accurate, up-to-date network map of your entire internetwork
• Next-hop address and exit interface for each neighbor connection
• All the remote subnet IDs

Of course, we don’t need to have any of these for dynamic routing, which is why we mostly use dynamic routing. It’s just so awesome to have the routing protocol do all that work for us by finding all the remote subnets and automatically placing them into the routing table!

Figure 17.12 shows a really good example of how to use static routing with IPv6. It really doesn’t have to be that hard, but just as with IPv4, you absolutely need an accurate network map to make static routing work!

So here’s what I did: First, I created a static route on the Corp router to the remote network 2001:1234:4321:1::/64 using the next hop address. I could’ve just as easily used the Corp router’s exit interface. Next, I just set up a default route for the Branch router with ::/0 and the Branch exit interface of Gi0/0—not so bad!

Configuring IPv6 on Our Internetwork

We’re going to continue working on the same internetwork we’ve been configuring throughout this book, as shown in Figure 17.13. Let’s add IPv6 to the Corp, SF, and LA routers by using a simple subnet scheme of 11, 12, 13, 14, and 15. After that, we’ll add the OSPFv3 routing protocol. Notice in Figure 17.13 how the subnet numbers are the same on each end of the WAN links. Keep in mind that we’ll finish this chapter by running through some verification commands.

As usual, I’ll start with the Corp router:

Corp#config t
Corp(config)#ipv6 unicast-routing
Corp(config)#int f0/0
Corp(config-if)#ipv6 address 2001:db8:3c4d:11::/64 eui-64
Corp(config-if)#int s0/0
Corp(config-if)#ipv6 address 2001:db8:3c4d:12::/64 eui-64
Corp(config-if)#int s0/1
Corp(config-if)#ipv6 address 2001:db8:3c4d:13::/64 eui-64
Corp(config-if)#^Z
Corp#copy run start
Destination filename [startup-config]?[enter]
Building configuration...
[OK]

Pretty simple! In the previous configuration, I only changed the subnet address for each interface slightly. Let’s take a look at the routing table now:

Corp(config-if)#do sho ipv6 route
C 2001:DB8:3C4D:11::/64 [0/0]
via ::, FastEthernet0/0
L 2001:DB8:3C4D:11:20D:BDFF:FE3B:D80/128 [0/0]
via ::, FastEthernet0/0
C 2001:DB8:3C4D:12::/64 [0/0]
via ::, Serial0/0
L 2001:DB8:3C4D:12:20D:BDFF:FE3B:D80/128 [0/0]
via ::, Serial0/0
C 2001:DB8:3C4D:13::/64 [0/0]
via ::, Serial0/1
L 2001:DB8:3C4D:13:20D:BDFF:FE3B:D80/128 [0/0]
via ::, Serial0/1
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
Corp(config-if)#

Alright, but what’s up with those two addresses for each interface? One shows C for connected, one shows L. The connected address indicates the IPv6 address I configured on each interface and the L is the link-local that’s been automatically assigned. Notice in the link-local address that the FF:FE is inserted into the address to create the EUI-64 address.

Let’s configure the SF router now:

SF#config t
SF(config)#ipv6 unicast-routing
SF(config)#int s0/0/0
SF(config-if)#ipv6 address 2001:db8:3c4d:12::/64
% 2001:DB8:3C4D:12::/64 should not be configured on Serial0/0/0, a subnet router anycast
SF(config-if)#ipv6 address 2001:db8:3c4d:12::/64 eui-64
SF(config-if)#int fa0/0
SF(config-if)#ipv6 address 2001:db8:3c4d:14::/64 eui-64
SF(config-if)#^Z
SF#show ipv6 route
C 2001:DB8:3C4D:12::/64 [0/0]
via ::, Serial0/0/0
L 2001:DB8:3C4D:12::/128 [0/0]
via ::, Serial0/0/0
L 2001:DB8:3C4D:12:21A:2FFF:FEE7:4398/128 [0/0]
via ::, Serial0/0/0
C 2001:DB8:3C4D:14::/64 [0/0]
via ::, FastEthernet0/0
L 2001:DB8:3C4D:14:21A:2FFF:FEE7:4398/128 [0/0]
via ::, FastEthernet0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0

Did you notice that I used the exact IPv6 subnet addresses on each side of the serial link? Good… but wait—what’s with that anycast error I received when trying to configure the interfaces on the SF router? I didn’t mean to create that error; it happened because I forgot to add the eui-64 at the end of the address. Still, what’s behind that error? An anycast address is a host address of all 0s, meaning the last 64 bits are all off, but by typing in /64 without the eui-64, I was telling the interface that the unique identifier would be nothing but zeros, and that’s not allowed!

Let’s configure the LA router now:

SF#config t
SF(config)#ipv6 unicast-routing
SF(config)#int s0/0/1
SF(config-if)#ipv6 address 2001:db8:3c4d:13::/64 eui-64
SF(config-if)#int f0/0
SF(config-if)#ipv6 address 2001:db8:3c4d:15::/64 eui-64
SF(config-if)#do show ipv6 route
C 2001:DB8:3C4D:13::/64 [0/0]
via ::, Serial0/0/1
L 2001:DB8:3C4D:13:21A:6CFF:FEA1:1F48/128 [0/0]
via ::, Serial0/0/1
C 2001:DB8:3C4D:15::/64 [0/0]
via ::, FastEthernet0/0
L 2001:DB8:3C4D:15:21A:6CFF:FEA1:1F48/128 [0/0]
via ::, FastEthernet0/0
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0

This looks good, but I want you to notice that I used the exact same IPv6 subnet addresses on each side of the links from the Corp router to the SF router as well as from the Corp to the LA router.

Configuring Routing on Our Internetwork

I’ll start at the Corp router and add simple static routes. Check it out:

Corp(config)#ipv6 route 2001:db8:3c4d:14::/642001:DB8:3C4D:12:21A:2FFF:FEE7:4398 150
Corp(config)#ipv6 route 2001:DB8:3C4D:15::/64 s0/1 150
Corp(config)#do sho ipv6 route static
[output cut]
S 2001:DB8:3C4D:14::/64 [150/0]
via 2001:DB8:3C4D:12:21A:2FFF:FEE7:4398

Okay—I agree that first static route line was pretty long because I used the next-hop address, but notice that I used the exit interface on the second entry. But it still wasn’t really all that hard to create the longer static route entry. I just went to the SF router, used the command show ipv6 int brief, and then copied and pasted the interface address used for the next hop. You’ll get used to IPv6 addresses (you’ll get used to doing a lot of copy/paste moves!).

Now since I put an AD of 150 on the static routes, once I configure a routing protocol such as OSPF, they’ll be replaced with an OSPF injected route since it has a lower AD (remember this is called a floating static route). Let’s go to the SF and LA routers and put a single entry in each router to get to remote subnet 11.

SF(config)#ipv6 route 2001:db8:3c4d:11::/64 s0/0/0 150

That’s it! I’m going to head over to LA and put a default route on that router now:

LA(config)#ipv6 route ::/0 s0/0/1

Let’s take a peek at the Corp router’s routing table and see if our static routes are in there.

Corp#sh ipv6 route static
[output cut]
S 2001:DB8:3C4D:14::/64 [150/0]
via 2001:DB8:3C4D:12:21A:2FFF:FEE7:4398
S 2001:DB8:3C4D:15::/64 [150/0]
via ::, Serial0/1

Voilà! I can see both of my static routes in the routing table, so IPv6 can now route to those networks. But we’re not done because we still need to test our network! First I’m going to go to the SF router and get the IPv6 address of the Fa0/0 interface:

SF#sh ipv6 int brief
FastEthernet0/0 [up/up]
FE80::21A:2FFF:FEE7:4398
2001:DB8:3C4D:14:21A:2FFF:FEE7:4398
FastEthernet0/1 [administratively down/down]
Serial0/0/0 [up/up]
FE80::21A:2FFF:FEE7:4398
2001:DB8:3C4D:12:21A:2FFF:FEE7:4398

Next, I’m going to go back to the Corporate router and ping that remote interface by copying and pasting in the address. No sense doing all that typing when copy/paste works great!

Corp#ping ipv6 2001:DB8:3C4D:14:21A:2FFF:FEE7:4398
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:3C4D:14:21A:2FFF:FEE7:4398, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
Corp#

We can see that static route worked, so next, I’ll go get the IPv6 address of the LA router and ping that remote interface as well:

LA#sh ipv6 int brief
FastEthernet0/0 [up/up]
FE80::21A:6CFF:FEA1:1F48
2001:DB8:3C4D:15:21A:6CFF:FEA1:1F48
Serial0/0/1 [up/up]
FE80::21A:6CFF:FEA1:1F48
2001:DB8:3C4D:13:21A:6CFF:FEA1:1F48

It’s time to head over to Corp and ping LA:

Corp#ping ipv6 2001:DB8:3C4D:15:21A:6CFF:FEA1:1F48
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:3C4D:15:21A:6CFF:FEA1:1F48, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Corp#

Now let’s use one of my favorite commands:

Corp#sh ipv6 int brief
FastEthernet0/0 [up/up]
FE80::20D:BDFF:FE3B:D80
2001:DB8:3C4D:11:20D:BDFF:FE3B:D80
Serial0/0 [up/up]
FE80::20D:BDFF:FE3B:D80
2001:DB8:3C4D:12:20D:BDFF:FE3B:D80
FastEthernet0/1 [administratively down/down]
unassigned
Serial0/1 [up/up]
FE80::20D:BDFF:FE3B:D80
2001:DB8:3C4D:13:20D:BDFF:FE3B:D80
Loopback0 [up/up]
unassigned
Corp#

What a nice output! All our interfaces are up/up, and we can see the link-local and assigned global address.

Static routing really isn’t so bad with IPv6! I’m not saying I’d like to do this in a ginormous network—no way—I wouldn’t want to opt for doing that with IPv4 either! But you can see that it can be done. Also, notice how easy it was to ping an IPv6 address. Copy/paste really is your friend!

Before we finish the chapter, let’s add another router to our network and connect it to the Corp Fa0/0 LAN. For our new router I really don’t feel like doing any work, so I’ll just type this:

Boulder#config t
Boulder(config)#int f0/0
Boulder(config-if)#ipv6 address autoconfig default

Nice and easy! This configures stateless autoconfiguration on the interface, and the default keyword will advertise itself as the default route for the local link!

I hope you found this chapter as rewarding as I did. The best thing you can do to learn IPv6 is to get some routers and just go at it. Don’t give up because it’s seriously worth your time!

Summary

This last chapter introduced you to some very key IPv6 structural elements as well as how to make IPv6 work within a Cisco internetwork. You now know that even when covering and configuring IPv6 basics, there’s still a great deal to understand—and we just scratched the surface! But you’re still well equipped with all you need to meet the Cisco exam objectives.

You learned the vital reasons why we need IPv6 and the benefits associated with it. I covered IPv6 addressing and the importance of using the shortened expressions. As I covered addressing with IPv6, I also showed you the different address types, plus the special addresses reserved in IPv6.

IPv6 will mostly be deployed automatically, meaning hosts will employ autoconfiguration. I demonstrated how IPv6 utilizes autoconfiguration and how it comes into play when configuring a Cisco router. You also learned that in IPv6, we can and still should use a DHCP server to the router to provide options to hosts just as we’ve been doing for years with IPv4—not necessarily IPv6 addresses, but other mission-critical options like providing a DNS server address.

From there, I discussed the evolution of the more integral and familiar protocol like ICMP. They’ve been upgraded to work in the IPv6 environment, but these networking workhorses are still vital and relevant to operations, and I detailed how ICMP works 
with IPv6

I wrapped up this pivotal chapter by demonstrating key methods to use when verifying that all is running correctly in your IPv6 network.

Exam Essentials

Understand why we need IPv6.  Without IPv6, the world would be depleted of IP addresses.

Understand link-local.  Link-local is like an IPv4 APIPA IP address, and it can’t be routed at all, not even in your organization.

Understand unique local.  This, like link-local, is like a private IP address in IPv4 and cannot be routed to the Internet. However, the difference between link-local and unique local is that unique local can be routed within your organization or company.

Remember IPv6 addressing.  IPv6 addressing is not like IPv4 addressing. IPv6 addressing has much more address space, is 128 bits long, and represented in hexadecimal, unlike IPv4, which is only 32 bits long and represented in decimal.

Understand and be able to read a EUI-64 address with the 7th bit inverted.  Hosts can use autoconfiguration to obtain an IPv6 address, and one of the ways it can do that is through what is called EUI-64. This takes the unique MAC address of a host and inserts FF:FE in the middle of the address to change a 48-bit MAC address to a 64-bit interface ID. In addition to inserting the 16 bits into the interface ID, the 7th bit of the 1st byte is inverted, typically from a 0 to a 1.