Understanding IPv6: The Journey Begins

Why is IPv6 so difficult to understand? Denise Fishburne explains how she began unraveling this complex topic.

Denise Fishburne

July 7, 2014

4 Min Read
NetworkComputing logo in a gray background | NetworkComputing

IPv6 and I met back in the early 2000s. I really didn't see the big deal or know what all the RFCs were about. This stuff was easy. Of course, at the time, my thoughts were barely even scratching at the surface, and I still believed IPv6 was just IPv4 with 128 bits. I was in what I now refer to as the "Checklist IPv6" phase.

"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.

IPv6 "I know nothing" phase
The quote "The more you know, the more you realize how much you don't know. The less you know, the more you think you know," is attributed to 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?"

The reverse-engineering phase
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 1531 was 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.

About the Author

Denise Fishburne

Customer Proof of Concept EngineerDenise "Fish" Fishburne, (CCIE #2639, CCDE #2009:0014, Cisco Champion) is a team lead with Cisco's Customer Proof of Concept Lab in Research Triangle Park, N.C. Fish loves playing in the lab, troubleshooting, learning, and passing it on. She has been regular speaker at Networkers/Cisco Live since 2006 and a session group manager for Cisco Live US since 2009.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights