Cost of Running an IPv4 Network Will Increase

Operating an IPv4 network will become increasingly costly and make IPv6 more attractive

Many in the industry realize that as we migrate to IPv6 there will be a day when IPv4 is not needed anymore. However, that transition seems daunting and may take decades. In the meantime, organizations will need to maintain both an IPv4 and IPv6 infrastructure adding to the total costs of an IT environment. Over time, the costs of operating an IPv4 network will increase compared to running an IPv6-only network.

In case you missed it, in December of 2010, the U.S. Federal Communications Commission (FCC) released a report titled "Potential Impacts on Communications From IPv4 Exhaustion & IPv6 Transition". This report described the issues related to IPv4 address depletion and the slow pace of IPv6 adoption. This report covers how the scarcity of IPv4 addresses can create challenges for networks. The concern mentioned in the report is that the transition to IPv6 has taken too long and this has strained the use of IPv4. The report also mentions the costs to transition to IPv6. This report covers the effects of NAT as a method of prolonging IPv4's useful lifetime.

During the dual-protocol period of your IPv6 transition we will run both an IPv4 and IPv6 network simultaneously. We should think about the costs of running an IPv4-only network and compare it to what it would be like to run a dual-protocol network or an IPv6-only network.

NAT

We are all familiar with the way that Network Address Translation (NAT) can be used to "hide" private IPv4 addresses behind a NAT/PAT device that uses one or many public IPv4 addresses. NAT has to be used with IPv4 because there are not enough IPv4 addresses available for all IP nodes that organizations possess. NAT is not an optimal solution for Internet communications but many feel safer operating networks using a NAT function. Many companies use firewalls that perform the NAT function and virtually all broadband Internet home routers perform a NAT function.

NAT breaks the end-to-end model of IP networks and causes problems for protocols that use embedded IP addresses. NAT creates problems for applications that contain embedded IP addresses in the upper-layer payload. Growth of NAT has slowed the growth of transparent applications that rely on end-to-end communications between nodes that use unique public IPv4 addresses. NAT preventsIPsec from functioning with Authentication Headers (AH) in addition to Encapsulating Security Payload (ESP). NAT causes many IPsec deployments to rely on NAT-Traversal (NAT-T) and encapsulate IPsec packets within UDP 4500.

Because private IPv4 space is used by so many organizations we must use filters to make sure that these private IPv4 addresses are not used to source IP packets on the Internet. BOGON filtering is still required but now a tight little access-list can be created. Since all the public IPv4 address space has been allocated these BOGON filters will not change in the future.

NAT complicates mergers/acquisitions and double NATing is often needed for devices to communicate with each other during the company integration process. Imagine the meetings that AT&T and T-Mobile will have to reconcile and resolve conflicts in the private IPv4 address space that is used within these companies. The conflicts can be resolved with re-addressing to other private IPv4 address space or with the creative use of NAT. I would hate to be on the network teams asked to perform the tedious work or renumbering IPv4 networks. I wonder if those network engineer's time would be better spent working to further IPv6 deployment.

With IPv6, NAT is not longer needed because virtually all systems can use public (aggregateable global unicast) IPv6 addresses (2000::/3). There are even methods like Unique Local Addresses (ULA) (FC00::/7) IPv6 addresses that have a method to avoid overlaps/collisions for internal networks during a merger or acquisition. Even though ULA space exists for IPv6 the vast majority of internal networks will use public IPv6 addresses.

Service Provider Address Crunch and LSN

The shortage of IPv4 address will make it difficult for Internet Service Providers (ISPs) to connect new customers to the Internet. Because we have waited too late to deploy IPv6, people are coming up with creative ways to conserve IPv4 addresses and operate their IPv4-only networks for many years to come. The IETF Behavioral Engineering for Hindrance Avoidance (behave) working group has been working on CGN/LSN/STUN/TURN/NAT64/DNS64 solutions to allow service providers to have a variety of IPv6 transition options.

NAT444/CGNs/LSNs will cause all your residential Internet traffic be backhauled through a regional NAT444/CGNs/LSNs device. This will add latency to your Internet connections and your performance will degrade as you fight for connections through the CGN with millions of other subscribers. You won't hit up against bandwidth limits but connection limits. Internet performance will soon be measured in terms of connections per second (CPS) instead of Megabits per second (Mbps).

LSN will also cause problems for a variety of Internet applications. Some web applications can open up many parallel connections. Web sites that use Java and AJAX can use many simultaneous connections. Google Maps, iTunes, and many others use many connections. If many of an ISPs subscribers are using these applications and all going through the same LSN system then the service provider will need a LSN system that can support many simultaneous connections per customer. The LSN system will also need a larger pool of public IPv4 addresses to satisfy the large number of connections generated by the subscribers.

NAT64/DNS64 could allow service providers to operate IPv6-only subscriber connections but allow them to access IPv4-only Internet content. This is an option for consumer devices that can operate well in an IPv6-only environment and for applications that don't contain any embedded IP addresses in the upper-layer payload. However, this is still a NAT technique and does not solve the true end-to-end model of communications that we desire.

Security & NAT

As that saying goes: "NAT does not make a good firewall". In fact, a stateful firewall actually makes an even better firewall. The use of NAT has specific implications for network security. Because a NAT system "hides" the sources of the IP connections initiated behind it, many security functions are not possible when NAT is used. NAT makes geolocation and forensics virtually impossible. Internet security investigations are more difficult when NAT is used. Content providers will not be able to track their customers purchases or track fraudulent activity based on IP address. NAT allows for anonymity on the Internet and thus creates an environment for hackers hiding behind NATs. NAT also impacts security techniques like reputation filtering and SPAM blacklists.

IPv6 aggregatable global unicast addresses will allow for simpler tracebacks, ingress/egress filtering, and a restoral of trustworthiness of Internet communications. IPv6 allows for the restoral of the end-to-end model of communications where both the end nodes use unique public addresses.

Troubleshooting with NAT and Multiple Layers of NAT

Troubleshooting many network applications that traverse a NAT or multiple-layers of NAT will become increasingly difficult. Troubleshooting NAT will increase the Mean-Time-To-Repair (MTTR) for every network issue. Every minute of extra troubleshooting time will dramatically affect availability percentages. For example, if it takes an extra 10 minutes to troubleshoot a problem because NAT was involved that just took your organization from 99.999% availability down to around 99.9% availability. 5-nines equals over 5 minutes of downtime per year and about 6 seconds of downtime per week and 3-nines equals 9 hours of downtime per year and about 10 minutes of downtime per week.

Do you think you can quickly troubleshoot a network that has a link to a business partner that uses an IPsec VPN with NAT-T that has overlapping address with your organization and your backup datacenter which also has NAT and overlapping addresses? Do you think this will take you more than 30 minutes just to diagram out the topology and the different source/destination addresses along the traffic path? If you think that the addition of NAT will lengthen your troubleshooting time and increase your MTTR then this situation is a risk for how your network is supporting your business.

Troubleshooting IPv6 without NAT/PAT is much easier. IPv6 will not use NAT and troubleshooting will be much simpler. So long as ICMPv6 message types 1-4 and 128/129 are permitted through your firewalls then applications will work properly and end-to-end ping can be used.

Cost of IPv4 Addresses

Do you have a static IP address at the perimeter of your broadband Internet connection today? How much a month do you pay for that static public IPv4 address? Some people have paid as little as $5/month for a static IP but this is like to increase to $20/month, $40/month and $50/month. I have also heard about service providers that charge an extra $100/month for a static IPv4 address. The monthly rental of a public IP address is likely to increase or even go away as carriers are forced to move to CGN/LSN/NAT444. Furthermore, with the introduction of CGN/LSN, you will not be able to run a server at your location. Because you won't have a static public address your ability to have a single DNS or Dynamic-DNS service is impossible.

If a free-market forms for IPv4 addresses then the cost of public IPv4 addresses will increase. ARIN and other regional registries have documented processes for exchanging (transferring) IPv4 address space between organizations. There is even the possibility for an organization to be an IPv4-address-matchmaker and operate as a Specified Transfer Listing Service (STLS). These companies help organizations in need of addresses find suitable mates that have available addresses and help coordinate the transfer through ARIN following their policies. If you are suffering from insomnia you can read the ARIN Number Resource Policy Manual and the section that describes the policies for address transfers. This section of the ARIN policies that your organization does not actually own your IPv4 addresses, but rather you are just borrowing them.

Recently, Microsoft paid the bankrupt Nortel $7.5 million for 666,624 IPv4 addresses. That comes out to about $11.25 for each IPv4 address. This purchase of IPv4 addresses by Microsoft tells us that Microsoft realizes that IPv4 is going to be around for many years. Even though Microsoft has put a lot of investment into developing IPv6 capabilities in their products Microsoft knows that the transition to IPv6 will not be quick and they need IPv4 addresses to continue to expand.

I have heard of an organization that is selling a Class-B (/16) for one million dollars. That means that those 65536 IPv4 addresses are worth $15.25 each. Bill St. Arnaud has recently estimated that IPv4 addresses could be worth $200 each based on the yearly power consumption of operating a computer with that IPv4 address. This is an interesting concept, but even cloud-based services need IPv4 addresses to function.

IPv6 addresses are essentially free today, however, when the registries run out of IPv4 addresses, then they will have to charge more for IPv6 addresses. I encourage you to get your IPv6 addresses from your regional registry or service provider sooner rather than later.

IPv4 Routing Table Growth

The risk of creating a free-market economy for IPv4 addresses can lead to more fragmentation of the IPv4 Internet routing tables. The Default-Free-Zone (DFZ) will continue to grow as larger blocks are divided up into smaller blocks. IPv4 subnetting causes routing tables to contain smaller and smaller subnets and increase memory and CPU requirements on backbone routers and even enterprise routers (for multi-homed companies). ISPs and multi-homed enterprises will continually need to purchase larger and larger routers to process and hold all the routing information.

IPv6 was originally intended to have fully hierarchical addressing to help limit the size of the Internet routing tables. However, with Provider Independent (PI) addresses and a lack of widely-available multi-homing solutions (SHIM6) the IPv6 routing tables are likely to grow. Currently, the IPv6 Internet routing tables contain about 5000 entries. However, when IPv6 is deployed on a network the size of the current Internet, it would surely have fewer than 360,000 routes.

There are significant hassles of performing IPv4 subnetting to optimize the usage and striving to achieve 80%-90% usage creates churn. IPv4 subnetting can also lead to increased operational overhead. It is complicated for many organizations to keep track of a network that uses diverse prefix lengths. Often it is necessary to use different prefix lengths to maximize utilization of IP addresses. However, when you make a mistake with a subnet mask you can have overlapping subnet mask issues that can be service-affecting.

IPv6 will make things easier because /64 will be the default prefix length for just about every type of link. There will be the occasional other prefix lengths for individual networks, but /64s will the dominant subnet size. There have been extensive discussion of /112, /126, /127, /128 (loopbacks and host routes). The use of /127 prefix lengths were originally considered a bad idea but now we are realizing there may be advantages to using them.

Operating a Dual Protocol Network

As we transition to IPv6, running a dual protocol network will be the dominant transition strategy. You will dual stack where you can and tunnel where you must. However, for many years you will need to maintain both an IPv4 and an IPv6 environment. This will add to the administrative burden of operating a network, systems, applications, and security systems. Everything that has an IPv4 address today will likely have both an IPv4 and an IPv6 address for many years. That means there will be twice as many things to configure. You will need to maintain twice the information in DNS and DHCP/DHCPv6. You will need to maintain twice the configuration information in routers, switches and servers. You will have to maintain two different firewall policies and maintain IPS signatures for each protocol. You will need to convert your IPv4-only applications to address-family independent applications and maintain that dual-stack code for many years. Having a router that holds both the IPv4 and IPv6 routing tables will add CPU and memory overhead for many years. All this will add to the cost of running a dual-protocol network. Therefore, the faster we can move to an IPv6-only environment the sooner we can realize the benefits of IPv6 and the cost savings. However, that day is a long way away.

Conclusion

As the costs of running an IPv4 network increase, organizations will start to see IPv6 as a more attractive solution. However, for the foreseeable future, most organizations will run both IPv6 and IPv4 and the decommissioning of IPv4 networks is a long way off. The real question is if we can even make it to IPv6 while the cost of operating IPv4 networks continue to rise. The effort we will have to put into operating networks with IPv4 will distract us from putting effort into making progress toward IPv6.