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?
Like any true magician, I must start my magic act with letting you know I have nothing up my sleeves.
The Facts
So let’s review the facts:
- IPv6 unicast routing is globally enabled on both routers
- IPv6 OSPFv3 is enabled via the one global command, “ipv6 router ospf 6”
- Each router has an interface in an out-of-band management network (OOB mgt.) in the subnet 14.14.14.0/24.
- RouterA is 14.14.14.101 and RouterB is 14.14.14.102 in this OOB management network
- The IPv4 addresses for the OOB management interfaces are the only IP addresses in the configurations
- Gig1/0/1 on both routers only has only two IPv6 commands on it, as shown below
- Router A is monitoring the gig1/0/1 interface and sending the traffic to a Spirent TestCenter port for capture
The Magic Trick
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.
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!
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?
A Couple of Clues
What are the other clues I have given you?
- In the diagram above, I show the MAC addresses of both Router A’s interface and Router B’s interface
- I’m highlighting the MAC address in the show interface gig1/0/1 output for RouterA.
Checking in on the Wire
Let’s look at the sniffer trace we caught and focus just on the OSPF.
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:
- FF02::5
- FE80::5A0A:20FF:FEEB:91E4
- FE80::2237:06FF:FECF:67E4
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.
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.
Mystery solved for FF02::5! It is the IPv6 multicast address equivalent to 224.0.0.5: OSPF.
Now Let’s Look at the 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.
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.
Checking in on RFC4291
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.
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?
What were those two IPv6 link-local unicast addresses we saw in the trace again?
- FE80::5A0A:20FF:FEEB:91E4
- FE80::2237:06FF:FECF:67E4
Notice anything? Look at those numbers and look at the picture above. See it? Let me help a little.
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?
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.
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.
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. 🙂
Related IPv6 Blog Series
Understanding IPv6: The 7 Part Series
The Journey Begins (Part 1 of 7)
Link-Local ‘Magic’ (Part 2 of 7)
A Sniffer Full Of 3s (Part 3 of 7)
What Is Solicited-Node Multicast? (Part 4 of 7)
Prepping For Solicited-Node Multicast (Part 5 of 7)
The Ping Before Solicited-Node Multicast (Part 6 of 7)
Solicited-Node Multicast In Action (Part 7 of 7)
Leave a Reply