After years(decades?) of being programmed to work with IPv4, there are telltale signs that you might have fallen victim to a dangerous syndrome called “IPv4 thinking.” Thankfully, not only are there tests to assess if you have this syndrome, but there is a popular antidote on the market to reverse the symptoms. That antidote is shifting to IPv6.
Unlike physical ailments, IPv4 thinking isn’t harmful to your personal health. Unless we compare IPv4 scarcity to a lego block that you’re just about to step on “ouch” in this case it can be a pain. Either way, it is something to be aware of, however, when it comes to IPv6 migration efforts.
In this episode of Packet Pushers IPv6 Buzz 102 Tom Coffeen, Scott Hogg, and Ed Horley talk about the nearly unnoticeable ways IPv4 thinking has become so limiting (and problematic). But first, they address what IPv4 thinking is, how it’s detrimental to IPv6 address planning, how it can impede IPv6 design, and much more.
What Is IPv4 Thinking?
Listening to the hosts individually answer the basic question of “What is IPv4 thinking?” sounds like the equivalent of an IT comedy roast. Each one has a different take on how to define IPv4 thinking, which include:
- “It’s the idea that you have a limited amount of IPv4 space.”
- “It’s a foreboding feeling that you‘re running out, like you’re running faster and faster and hustling, but not getting anywhere.”
- “It’s wondering if a new requirement will rear its ugly head.”
- “Everything is crumbling before you, when your wonderful design is going out the window.”
If you can confirm that you’ve had those same thoughts and experiences in your past work, you might be in an IPv4 thinking recovery period. It’s especially important to be aware of IPv4 thinking because it can have a detrimental impact on IPv6 address planning.
Detrimental Effects of IPv4 Thinking
How so? One way to tell if IPv4 thinking will have a detrimental effect on your IPv6 design is in your initial assessment. If you’re someone whose initial thoughts during the architecture and design phase revolve around host address consumption with IPv6, you’re likely still in the IPv4 mindset. You might think you’re working on an IPv6 project, but you’re stuck in IPv4, and that will negatively impact your design. As a matter of fact, in a previous discussion on Containers and IPv6, Ed Horley explains this well, “to consume a single /64 of address space on a single Docker host that is generating 10 million containers per second it would take more than 58 thousand years to consume all the IPv6 addresses.” So thinking you have limited IPv4 space should be eliminated.
“Instead, you should be thinking about IPv6 prefix consumption.”
Can IPv4 Thinking Impede Design, Architecture, and Operations?
In fact, when too much IPv4 thinking has taken place, the design phase of IPv6 is where network engineers will pay the biggest penalty. With IPv4 limitations driving data center architecture and WAN architecture, for example, layering on the veneer of IPv6 becomes unnatural because it doesn’t fit. It can be like trying on a shoe, thinking that using a shoehorn will help, but the shoe wasn’t actually the right size. You can’t force it, unless you want to deal with the pain of foot problems down the line. In that same way, the physical topology of IPv4 wasn’t meant to be coupled with IPv6.
It is not uncommon for network engineers to be asked to represent characteristics of an IPv4 address space into their IPv6 design. The truth is, there are negative outcomes to tightly coupling IPv4 and IPv6 together when they don’t need to be.
“It’s the mother of all mistakes where IPv4 thinking is concerned.”
In reality, coupling IPv4 and IPv6 leads to constraints in the security design model, thought process about how logical entities should be broken up, underlays, overlays, and all sorts of architecture design issues. You immediately constrain yourself to the IPv4 way of doing things, including the size and bound of a network.
As the episode comes to an end Tom, Scott and Ed share their final thoughts. Recognizing that the goal is to make IPv4 go away, the good news is that IPv4 thinking is completely curable with the correct approach. Separate IPv4 and IPv6 into their respective parts, and don’t drag IPv4 thinking into your next IPv6 design. Constantly test yourself to make sure you’re not limiting your design based on ideas you’ve brought with you from previous programming.
Wipe the slate clean. Imagine you don’t know anything about IPv4 and start with IPv6 cleanly – that’s the best way to cure IPv4 thinking.
Don’t want this discussion to end? Check out IPv6 Buzz to find more episodes surrounding this topic.
