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.
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?
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.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
