Understanding IPv6: Link-Local 'Magic'

For those of you new to IPv6, what I am about to show you is going to look a lot like a magic trick. I’m going to bring up an IPv6 IGP neighbor relationship (OSPFv3) between two routers. This doesn’t sound like a magic trick, I know. But what if I told you I am going to do this without putting any IPv6 addresses into the configurations of either routers?

Figure 1:

Like any true magician, I must start my magic act with letting you know I have nothing up my sleeves. So let’s review the facts:

Figure 2:

The interfaces are currently, as I mentioned, administratively shut down. So why look at the output to show int gig1/0/1 on Router A? Hint, hint: The MAC address of Router A is highlighted.

Figure 3:

Let’s “no shut” both Router A’s interface and Router B’s interface. Wave the magic wand and say a few magic words and….

VOILA! OSPFv3 neighbor!

Figure 4:

Can you guess?

How did I do that? Let’s take a step backward for a second and think about all the clues I’ve given you thus far.

In my previous blog, I raised a question that might have been posed during the development of IPv6 (IPng at the time):

“IPng addressing on local links: Why use up precious IPng addresses supporting routing protocols on a local segment just for the purpose of routers talking to each other? They are just communicating on that local segment.”

It's a good question and one I definitely imagine was asked. With the concern about the exhaustion of IPv4 addresses, I can imagine address conservation techniques might have been forefront in people's minds. Why, then, burn up an IPng address on the link between RouterA and RouterB just to have OSPF neighbors come up?

What are the other clues I have given you?

Sniffer trace
Let's look at the sniffer trace we caught and focus just on the OSPF.

Figure 5:

Lots of FE80:: and FF02::5 stuff, eh? These are all part of the magic trick.

It may look messy and intimidating to read, but it is really just three numbers repeating again and again in our trace, all of which are actually IPv6 addresses critical to making the magic trick work:

Examining FF02::5
First, let's take a closer look at the one that stands out a little easier and is a little less intimidating – FF02::5.

Figure 14:

Does that "::5" at the end of "FF02::5" remind you of anything? How about the clue that FF02::5 is only a destination IP address and never a source? Anything? Would it remind you of anything if I mentioned the IPv4 address 224.0.0.5?

Let's go to this IANA page, plus this other IANA page and merge together some information from the two.

Figure 6:

Mystery solved for FF02::5! It is the IPv6 multicast address equivalent to 224.0.0.5: OSPF.

NEXT Page: A closer look at FE80::

So what are all those FE80:: IPv6 addresses and where did they come from? Clearly, they somehow came from RouterA and RouterB because this is a sniffer trace of the packets on the point-to-point link between Router A and Router B.

Figure 7:

So the question is, how did the routers get IPv6 addresses if I didn't configure any. Allow me to introduce you to the IPv6 link-local unicast address type.

RFC4291 section 2.4 introduces the varying address types. FF00::/8 we met above with FF02::5. Our two FE80:: IPv6 addresses clearly fall under the "link-local unicast" family.

Figure 8:

RFC4291 section 2.8 states, "A host is required to recognize the following addresses as identifying itself"and it goes on to have the first bulleted item as "its required Link-Local address for each interface."

So we have just learned that IPv6 hosts must have a link-local unicast IPv6 address for each interface. We also know that this IPv6 link-local unicast address must start with FE80:: as per RFC4291 section 2.4.

But where DO the rest of the numbers after FE80:: come from?

Figure 9:

What were those two IPv6 link-local unicast addresses we saw in the trace again?

Notice anything? Look at those numbers and look at the picture above. See it? Let me help a little.

Figure 10:

The routers and code version I am using for Router A and Router B are defaulting to creating the required IPv6 link-local unicast address via the described method of creating an IEEE EUI-64 identifier from an IEEE 48-bit MAC identifier. I will not go into detail describing this here as there are many helpful links out on the web to explain the magic, including RFC4291 Appendix A.

The point I'm trying to make here is not the specifics of how the MAC to IPv6 link-local magic happens. The "takeaway" I want you to sear into your brain is that, by default, the IPv6 link-local address for Router A and Router B that is used to bring up the OSPF will be based on the MAC address for that specific interface.

Can this get complicated? You tell me. Can you easily read the sniffer trace below and know who is who?

Figure 11:

Statically defined IPv6 link-local
Like most defaults, we can override them. For example, below I am assigning FE80::1 as the IPv6 link-local address for Router A and FE80::2 as the IPv6 link-local address for Router B.

Figure 12:

Let's shut/no shut the interface and grab a new sniffer trace. As you can see, this makes the sniffer trace much easier to read. This will become even more important, in my opinion, when we talk about RAs (router advertisements) in the future.

Figure 13:

Voila!
There is no magic of course. The "rabbit" was "in the hat" all along, so to speak.

The IPv6 IGP neighbor relationship (in this case, OSPF) comes up and doesn't have to use one global unicast IPv6 address.

You might find yourself now wondering: "If we had assigned IPv6 global unicast addresses to those interfaces, would the IGP (OSPFv3) have used the global unicast addresses as the source and destination IPv6 addresses for the IGP neighboring instead of the link-local?"

Good question. Catch you on that one in a future blog.