IPv4? That Will Cost You

ipvdollar

After my recent articles on Network Computing, I got an email from Fred Baker.  To say I was caught off guard was an understatement.  We proceeded to have a bit of back and forth about IPv6 deployment by enterprises.  Well, it was mostly me listening to Fred tell me what he sees in the real world.  I wrote about some of it over on Network Computing.

One thing that Fred mentioned in a paragraph got me thinking.  When I heard John Curran of ARIN speak at the Texas IPv6 Task Force meeting last December, he mentioned that the original plan for IPv6 (then IPng) deployment involved rolling it out in parallel with IPv4 slowly to ensure that we had all the kinks worked out before we ran out of IPv4 prefixes.  This was around the time the World Wide Web was starting to take off but before RFC 1918 and NAT extended the lifetime of IPv4.  Network engineers took a long hard look at the plans for IPv6 and rightfully concluded that it was more expensive to run IPv6 in conjunction with IPv4 and instead it was more time and cost effective to just keep running IPv4 until the day came that IPv6 transition was necessary.

You’ve probably heard me quote my old Intro to Database professor, Dr. Traci Carte.  One of my favorite lessons from her was “The only way to motivate people is by fear or by greed.”  Fred mentioned that an engineer at an ISP mentioned to him that he wanted to find a way to charge IPv4 costs back to the vendors.  This engineer wants to move to a pure IPv6 offering unless there is a protocol or service that requires IPv4.  In that case, he will be more than willing to enable it – for a cost.  That’s where the greed motivator comes into play.  Today, IPv6 is quickly becoming equivalent in cost to IPv4.  The increased complexity is balanced out by the lack of IPv4 prefixes.

What if we could unbalance the scales by increasing the cost of IPv4?  It doesn’t have to cost $1,000,000 per prefix.  But it does have to be a cost big enough to make people seriously question their use of IPv4.  Some protocols are never going to be ported to have IPv6 versions.  By making the cost of using them higher, ISPs and providers can force enterprises and small-to-medium enterprises (SMEs) to take a long hard look at why they are using a particular protocol and whether or not a new v6-enabled version would be a better use of resources.  In the end, cheaper complexity will win out over expensive ease.  The people in charge of the decisions don’t typically look at man-hours or support time.  They merely check the bottom line.  If that bottom line looks better with IPv6, then we all win in the end.

I know that some of you will say that this is a hair-brained idea.  I would counter with things like Carrier-Grade NAT (CGN).  CGN is an expensive, complicated solution that is guaranteed to break things, at least according to Verizon.  Why would you knowingly implement a hotfix to IPv4 knowing what will break simply to keep the status quo around for another year or two?  I would much rather invest the time and effort in a scaling solution that will be with us for another 10 years or more.  Yes, things my break by moving to IPv6.  But we can work those out through troubleshooting.  We know how things are supposed to work when everything is operating correctly.  Even in the best case CGN scenario we know a lot of things are going to break.  And end-to-end communications between nodes becomes one step further removed from the ideal.  If IPv4 continuance solutions are going to drain my time and effort they become as costly (or moreso) that implementing IPv6.  Again, those aren’t costs that are typically tracked by bean counters unless they are attached to a billable rate or to an opportunity cost of having good engineering talent unavailable for key projects.


Tom’s Take

Dr. Carte’s saying also included a final line about motivating people via a “well reasoned argument”.  As much as I love those, I think the time for reason is just about done.  We’ve cajoled and threatened all we can to convince people that the IPv4 sky has fallen.  I think maybe it’s time to start aiming for the pocketbook to get IPv6 moving.  While the numbers for IPv6 adoption are increasing, I’m afraid that if we rest on our laurels that there will be a plateau and eventually the momentum will be lost.  I would much rather spend my time scheming and planning to eradicate IPv4 through increased costs than I would trying to figure out how to make IPv4 coexist with IPv6 any longer.

Advertisements

The Five Stages of IPv6 and NAT

I think it’s time to put up a new post on IPv6 and NAT.  Mainly because I’m still getting comments on my old NAT66 post from last year.  I figured it would be nice to create a new place for people to start telling me how necessary NAT is for the Internet of the future.

In the interim, though, I finally had a chance to attend the Texas IPv6 Task Force Winter 2012 meeting.  I got to hear wonderful presentations from luminaries such as John Curran of ARIN, Owen DeLong of Hurricane Electric, and even Jeff Doyle of Routing TCP/IP book fame.  There was a lot of great discussion about IPv6 and the direction that we need to be steering adoption of the new address paradigm.  I also got some very interesting background about the formation of IPv6.  When RFC 1550 was written to start soliciting ideas about a new version of IP, the Internet was a much different place.  Tim Berners-Lee was just beginning to experiment with HTTP.  The majority of computers connected to the Internet used FTP and Telnet.  Protocols that we take for granted today didn’t exist.  I knew IPSec was a creation of the IPv6 working group.  But I didn’t know that DHCP wasn’t created yet (RFC 2131).  Guess what?  NAT wasn’t created yet either (RFC 1631).  Granted, the IPng (IPv6) informational RFC 1669 was published after NAT was created, but NAT as we know and use it today wasn’t really formalized until RFC 2663.  That’s right, folks.

The reason NAT66 doesn’t exist is because IPv6 was built at a time when NAT didn’t exist.

It’s like someone turned on a lightbulb.  That’s why NAT66 has always felt so wrong to me. Because the people that created IPv6 had no need for something that didn’t exist.  IPv6 was about creating a new protocol with advanced features like automatic address configuration and automatic network detection and assignment.  I mean, take a look at the two IPv6 numbering methods.  Stateless Automatic Autoconfiguration (SLAAC) can assign all manner of network information to a host.  I can provide prefixes and gateways and even default routes.  However, the one thing that I can’t provide in basic SLAAC is a DNS server entry.  In fact, I can’t provide any of the commonly assigned DHCP options, such as NTP server or other vendor-specific fields.  SLAAC is focused solely on helping hosts assign addresses to themselves and get basic IP connectivity to the global Internet.  Now, take DHCPv6.  This stateful protocol can keep track of options like DNS server or NTP server.  It can also provide a database of assignments so I know which machine has which IP.  But you know what critical piece of information it can’t provide?  A default router.  That’s right, DHCPv6 has no method of assigning a default router or gateway to an end node.  I’m sure that’s due to the designers of DHCPv6 knowing that SLAAC and router advertisements (RA) handle the network portion of things.  The two protocols need to work together to get hosts onto the internet.  In 1995, that was some pretty advanced stuff.  Today, we think auto addressing and network prefix assignment is pretty passé.

Instead of concentrating on solving the dilemma of increasing the adoption rate of IPv6 past the 1% mark where it currently resides, we’ve instead turned to the Anger and Bargaining phases of the Küber-Ross model, otherwise known as the Five Stages of Grief. The need for IPv6 can no longer be denied.  The reality of running out of IPv4 addresses is upon us.  Instead, we lash out against that which we don’t understand or threatens us.  IPv6 isn’t ready for real networking.  There are security risks.  End-to-end communications aren’t important.  IPv6 is too expensive to maintain.  People aren’t smart enough to implement it.  Any of those sound familiar?  Maybe not those exact words, but I’ve heard arguments very similar to that leveled at IPv6 in just the two short years that I’ve been writing.  Think about how John Curran of ARIN must feel twenty years after he started working on the protocol.

Anger is something I can handle.  Getting yelled at or called expletives is all part of networking.  It’s the Bargaining phase that scares me.  Now, armed with a quiver of use cases that perhaps 5% of the population will ever take advantage of, we now must delay adoption or move to something entirely different to support those use cases.  It’s the equivalent of being afraid to jump off a diving board because there is a possibility that the water will drain out of the pool on the way down.  The most diabolical is Carrier Grade NAT.  Let’s NAT our NATed networks to keep IPv4 around just a little longer.  It won’t cause that many problems, really.  After all, we’ve only got 65,536 ports that we can assign for any given PAT setup.  So if we take that limit and extend it yet another level, we have 65,536 PATed PAT translations that we can assign per CGN gateway.  That has real potential to break applications, and not just from an end-to-end connectivity point of view. To prove my point, fire up any connection manager and go to http://maps.google.com.  See how many separate connection requests are spawned when those map tiles start loading.  Now, imagine what would happen if you could only load ten or fifteen of them.  There’s going to be a lot of blank spots on the that map.

Now, for the fun part.  I’ve been accused of hating NAT.  Yes, it’s true.  I dislike any protocol that breaks basic connectivity and causes headaches for troubleshooting and end-to-end communications.  I have to live with it in IPv4.  I’d rather not see it carried forward.  That’s the feeling of many IPv6 evangelists.  If you think I dislike NAT, ask Owen DeLong his feelings on the subject.  However, to say that I dislike NAT for no good reason is silly.  People are angry at me for saying the emperor has no clothes.  Every time I discuss the lack of need for NAT66, the same argument gets thrown in my face.  Ivan Pepelnjak wrote an article about about using network prefix translation (NPT) in a very specific case.  If you are multihoming your network to two different providers and not using BGP then a case for NPT can be made.  It’s not the best solution, but it’s the easiest.  Much like Godwin’s Law, as the length of any NAT66 argument increases, the probability of someone bringing up Ivan’s article approaches approaches one.

So, I’ve found a solution to the problem.  I’m going to fix this one scenario.  I’m going to dedicate my time to solving the multihoming without BGP issue.  When I do that, I expect choirs of angels to sing and a chariot pulled by unicorns to arrive at my home to escort me to my new position of Savior of IPv6 Adoption.  More realistically, I expect someone else to find a corner case rationale for why IPv6 isn’t the answer.  Of course, that’s just another attempt at bargaining.  By that point, I’ll have enough free time to solve the next issue.  Until then, I suggest the following course of action: