Home › Routing › IPv6 › Understanding IPv6: The Journey Begins (Part 1 of 7)

Understanding IPv6: The Journey Begins (Part 1 of 7)

By Denise "Fish" Fishburne on February 19, 2018 • ( 15 )

IPv6 and I met back in the early 2000s. After the initial getting used to the 128 bits and the odd /64 mask I thought I “knew” IPv6. I really didn’t see why people found it so difficult. Looking back now I refer to that time period as my “Checklist IPv6” phase.

“Checklist” IPv6

“Checklist IPv6” was actually a great place for me to start. I had to remember only a few things while I was configuring the routers. Then I could kick back and let the magic of routing protocols work. Voila, IPv6 addresses would show up in the routing table of some other router in the lab. Ping to confirm, and I was done.

Back to Square 1

“The more you know, the more you realize how much you don’t know. The less you know, the more you think you know,”

David T. Freeman.

I discovered the truth of this as I began digging deeper. The trigger to this phase was when I realized that IPv6 was clearly not IPv4 with 128 bits. When did that happen? When I read that there was no broadcast in IPv6.

That started an avalanche of questions, including:

Why the heck did they get rid of broadcast?
If there is no broadcast, how does one resolve MAC addresses?
What is this weird link-local address thing?
What do you mean you can just randomly generate your own link-local address? And why not?
Solicited-node multicast? Really?
This SLAAC thing has two different flavors?

I was honestly struggling with the impossibility of memorizing all these varying attributes. It all culminated in one question that eventually formed in my mind. The question went something like “Seriously? Why couldn’t we have just stayed with IPv4 and increased it to 128 bits?”

Time to Reverse Engineer

We all have strengths and weaknesses. One of my weaknesses is the ability to memorize a list of facts. I’m much better if I can see a flow, an equation, or a reason in my mind. So I had to spend some time trying to reverse-engineer the “why” of IPv6.

It was the year 1993. BOOTP required much manual intervention, and there was concern that IPv4 addresses would run out. In October of that year, RFC 1531was published, defining DHCP as an extension to BOOTP. A couple of months later, RFC 1550 solicited for white papers on “IP Next Generation” (IPng). RFC 1550 helped take me back in time to the issues that were at the forefront of people’s minds and what the IPng protocol would need to address. I specifically liked one quote in section 5:

“Any or all of these issues may be addressed, as well as any other topic that the author feels is germane.”

That one sentence essentially gave me permission to imagine all the things people might have thought were “germane” to the next generation of IP. I came up with the following potential discussions that could have happened between 1993 and 1996, when RFC 1970 was produced, defining IPv6’s Neighbor Discovery protocol.

Broadcast: Why broadcast to every device on the segment? Why bother every device on the segment to process a broadcast? Can’t we do MAC resolution a different way?
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.
BOOTP manual intervention: Isn’t there a better way for devices to get IPng addresses? Or to get the options and information they need? Or to find out who their default gateway should be?

Did all these questions actually come up? I have no clue. But thinking about them has helped me reverse engineer some potential “whys” of much that has confused me about IPv6.

Sharing my journey

As I mentioned earlier, I don’t really learn well by just memorization. I have to see a flow, a reason, or an equation and then play with it. At first, in the darkness, there is really just darkness. Then there’s an occasional “hmmmm.” Then there’s a flicker of a potential light of understanding that might — just might — be around the next bend. You’re rewarded with an “a-ha” moment that lasts for only a moment, until that “a-ha” brings up still more questions.

But for right now, I’d like to share my fun in the lab and what I have learned with you in this series. Next time, we’ll talk about and look at sniffer traces and debugs. 🙂