“You must unlearn what you have learned.” -Yoda

As network rock stars, we’ve all spent the majority of our careers learning how to do things.  We learn how to address interfaces and configure routing protocols.  For many of those out there, technology has changed often enough that we often find ourselves need to retrain.  Whether it be a new version of an old protocol or an entirely new way of thinking about things, there will always come a time when it’s necessary to pick up new knowledge.  However, in the case of updated knowledge it’s often difficult to process.  That’s because the old way of doing things interposes itself in our brains while we’re learning to do it the new way.  How many times have you been practicing something only to hear a little voice in the back of your head saying, “That’s not right.  You should be doing it this way.”  In many ways, it’s like trying to reprogram the pathway in your brain that leads to the correct solution to your problem.

This is very apparent to me when it comes to learning how to configure and setup IPv6 on a network.  Those just starting out in the big wide world of IPv6 need to have some kind of reference point to start configuring things, so they tend to lean back on their IPv4 training in order to get started.  This can work for some applications.  For others, though, it can be quite detrimental to getting IPv6 running the way it should.  Instead of carrying forward the old way of doing things because “that’s just the way they should be done,” you need to start unlearning IPv4.  The little green guy in Empire Strikes Back hit the nail on the head.  The whiney farm boy had spent so much of his life convinced that something was impossible that he couldn’t conceive that someone could lift his starship out of a swamp with the Force.  He had to unlearn that lifting things with his mind was impossible.  Once you take that little step, nothing can stop you from accomplishing anything.

With that in mind, here are a few things that need to be unlearned from our days working with IPv4.  Note that this won’t be easy.  But nothing worth doing is ever easy.

Address Conservation – This one is the biggest stumbling block today.  Look at all the discussion we’ve got around point-to-point links and whether to address them with a /64 or a /127 bit mask.  People claim that addressing this link with a /64 wastes addresses.  To  quote the old guy in the desert from Star Wars, “It’s true, depending on your point of view.”  In a given /64, there are approximately 18 quadrillion addresses available (I’m rounding to make the math easy).  If you address a point-to-point link with a /64, you’re only going to be using 0.0000000000000000001% of those addresses (thats 1 * 10^-19).  To many, that’s a pretty big waste.  But with numbers that big, your frame of reference gets screwed up.  By example, take a subnet with 4,094 hosts, which today would need /20 in IPv4.  That’s about the biggest single subnet I can imagine creating.  If you address that 4,094 host subnet with a /64 in IPv6, you’d end up using 0.0000000000000002% (2 * 10^-16) of the address space.  Waste is all a matter of perspective.  On the other hand, by addressing a link with a bit mask beyond a /64, we break neighbor discovery and secure neighbor discovery and PIM sparse mode with embedded RP among other things.  We need to unlearn the address conservation mentality and instead concentrate on making our networks easier to configure and manage.

Memorizing IP addresses – I’m guilty of this.  I spend a lot of time working at the command line with IPv4, whether it be via telnet or SSH or even just plugging numbers into a GUI.  My CUCM systems are setup to use IP only.  I memorize the addresses of my servers, or in many cases try to make this as similar mnemonically to other systems to jog my memory about where to find them in IP space.  In IPv6, memorizing addresses is going to be impossible.  It’s hard enough for me to remember non-RFC1918 address space as it is with 4 octets of decimal numbers.  Now quadruple that and add in hex addressing.  And when it comes to workstations with SLAAC or DHCPv6 assigned addresses?  Forget about it.  Rather than memorizing address space, we’re going to need to start using DNS for communications between endpoints.  Yes, that means setting up DNS for all your routers and CUCM servers too.  It’s going to be a lot of extra work up front.  It’ll pay off in the long run, though.  I’m sure you’d much rather refer to CUCM1.local rather than trying to remember fe80::ba8d:12ff:fe0b:8aff every time you want to get to the phone server.

Subnet Masks – Never again will you need to see 255 in an IPv6 address unless it’s part of the address.  Subnet masking is dead and buried.  Instead, bit masks and slash notation rule the day.  This is going to be one of the most welcome changes in IPv6, but I think it’s going to take a long time to unlearn.  Not really as much for network engineers, but mainly for the people that have ancillary involvement with networking, such as the server people.  Think about the number of server admins that you’ve talked to that have memorized that the subnet mask of their network card is 255.255.255.0.  Now, ask them what that means. Odds are good they can’t tell you.  Worse, some of them might say that it’s a Class C subnet mask.  It’s a little piece of anecdotal information that they heard once when the network folks were talking that they just picked up.  Granted, most of the time the servers are going to be addresses with a /64 bit mask on the IPv6 address.  That’s still going to take a while to explain to the non-networking people.  No, you don’t need any more 255s in your address.  Yes, the /64 is the same as that, sort of.  No, there’s math involved.  Yes, I’ll take care of all the math.

Ships in the Night – As I said on my recent appearance on the Class C block podcast, I think it’s high time that networking vendors stop treating IPv4 and IPv6 like they are separate entities.  I know that I’ve spent the better part of this blog post talking about how IPv4 and IPv6 require a difference in application and not carrying across old habits and conventions.  The two protocols are more alike that they are different.  That means that we need to stop thinking of IPv6 as an afterthought.  Take a look at the CCIE.  There’s still a separate section for IPv6.  It feels like it was just a piece that was added on to the end of the exam instead of being integrated into the core lab.  Look at Kurt Bales’ review of the JNCIE lab that he took.  Specifically, the last bullet point.  You could be asked to configure something on either IPv4 or IPv6, or even both!  Juniper understands that the people taking the JNCIE today aren’t going to have the luxury of concentrating on just IPv4.  The world is going to require us to use IPv6, so I think it’s only fair that our certification programs start doing the same.  IPv6 should be integrated into every level of certification from CCNA/JNCIA all the way up to CCIE/JNCIE.

Tom’s Take

Working with IPv6 is a big change from the way we’ve done things in the past.  With SLAAC and integrated IPSec, the designers have done a great job of making our lives easier with things that we’ve needed for a long time.  However, we’re doing our best to preclude our transition to IPv6 by carrying over a lot of baggage from IPv4.  I know that our brains look for patterns and like to settle on familiarity as a way to help train for new challenges.  If we aren’t careful, we’re going to carry over too much of the old familiar networking and make IPv6 difficult to work with.  Unlearning what we think we know about networking is a good first step.  A person may learn something quickly with familiarity, but they can learn even faster when they approach it with a blank slate and a keen interest to learn.  With that approach, even the impossible won’t keep you from succeeding.