IPv4 Exhaustion and IPv6 Readiness - should you care, and if so, why?
Posted 12 May 2011 | 
| 
1 Comments
Judging by recent press articles, Twitter posts and blogs, you'd be excused for thinking that the Interwebs is about to implode, the sky is falling, civilisation as we know it is about to collapse, and that we are about to be cast into a new Dark Age. Why? Because of IPv4 address exhaustion. You will also have read about IPv6 - the New Kid On The Block - and how we must all migrate to it, or risk being cast into a dystopian, post-apocalyptic world of ashen skies, seared earth and no Internet access. So what is this all about? Should you care, and if so, what should you do about it?
First off; yes, the Internet has been running out of addresses. Internet Protocol Version 4 (IPv4) has been serving us well for 30 years, and was built on the earlier implementations of the TCP/IP protocol suite dating back to 1974. At inception, the (roughly) 4.3 billion individual addresses available to the IPv4 schema seemed limitless, and far beyond the wildest ambitions of the - largely - Defense, Research and Academia organisations using it (and for whom it was designed) in terms of scalability. No-one back then could have predicted the exponential growth of the Internet, first through commercial, then domestic usage, nor the plethora of applications - from email, to bulletin boards and USENET Newsgroups, to the birth of the World Wide Web and ubiquitous browsing, B2B, B2C and C2C (eBay, anyone?) e-commerce - that would spring up and absorb this erstwhile 'infinite' addressing resource. Even so, the IPv4 schema had a granular hierarchy of classes to provide different combinations of 'networks' and 'hosts', so that resources within the addressing schema could be allocated on a fair and equitable basis.
Within a few years, the limitation of the 'classful' system was alleviated by introducing the concept of Variable Length Subnet Masking (VLSM) - subnetting - and, in the 90's by Classless Inter-Domain Routing (CIDR). The use of Network Address Translation (NAT) and Port Address Translation (PAT), in conjunction with 'private' addressing bought the IPv4 schema another decade or so of grace.
Despite this, the erosion of the public address space continued, with new, ever-increasing, and unforseen requirements for IP addresses eating into the available pool - out-of-band Management networks, IP telephony (VoIP), CCTV, PDAs, Smartphones, gaming consoles, consumer electronics and household white goods, RFID chips in consumables... and even domestic pet-tracking implants. The central pool of IPv4 addresses held by IANA, the Internet Assigned Numbers Authority, which oversees global IP address and top-level domain allocations via the Regional Internet Registries or RIRs, was depleted in February 2011. Of the RIRs, the Asia-Pacific Network Information Centre (APNIC) ran down to its last its last /8 block of IPv4 addresses in April. The other 4 RIRs are expected to follow suit over the next few years, with RIPE NCC (Réseaux IP Européens), the regional Internet registry for Europe, expected in late 2011 or 2012.
Having established the back story and the issues, what can be done about it? Aware of the limitations of IPv4 and the rapidly-diminishing address space, the Internet Engineering Task Force (IETF) developed a subsequent addressing schema, IPv6, to deal with the issue, as far back as 1998, although you wouldn't have thought so, given the sudden ructions about IPv4 address exhaustion, currently. I think that it's fair to say that some manufacturers, a good few ISPs and most customers have swept the issues under the carpet up until recently, preferring to focus on virtual hosting, more granular VLSM, NAT/PAT and private addressing to get by for as long as possible.
How does IPv6 solve the address exhaustion issue? IPv6 has a 128-bit address field as opposed to IPv4's 32bits, which increases the available number of unique addresses to something in the order of 340 undecillion (that's 2^128, or 3.4 x 10^38). Understandably, that's difficult to express in dotted decimal notation, so the IETF have standardised on a colon-delimited hexadecimal representation, thus, for example: 2001:0db8:85a3:3416:0000:0000:0000:7334. A bit of a mouthful, but IPv6 does have a couple of provisions for address abbreviation, so that same address can be expressed as 2001:db8:85a3:3416::7334. That's still not what I'd call human-readable, and so this has implications on DNS, DHCP and IP Address Management, especially as the two IP address schemas are independent and incompatible - but I'll leave that for another time and a different blog article. Suffice to say that a network administrator with an Excel spreadsheet will no longer be up to the task of managing a dual IPv4/IPv6 address catalog.
The available address space has been variously described in analogies from "as many addresses as there are stars in a galaxy" or "as many as there are grains of sand on the planet", and it certainly is a mind-boggling value. What people don't factor in when calculating these analogies is with 64 bits given over to the network prefix, 16 bits to what the IETF term 'local topology' and other reservations, only an eighth of the total address space is made available for what we would call "normal" IP addresses - 2^16. The RIRs will allocate a minimum of /32 address blocks to the Local Internet Registries (LIRs), who will divide them up to their respective ISPs. End users will get addresses allocations in block values somewhere between /64 and /48. All that still leaves an insane number of addresses, so surely we will never run out again?
Well, I'm going to buck the trend here, thinking "never say never". Nobody thought we'd run out of IPv4 addresses either, back in 1981. We don't know what's around the corner, what "killer app" or technology will be developed which will leverage this addressing schema. I'll use a 'Road Widening' analogy here, where traffic increases to absorb up any new resources as they are made available. What could possibly put a dent in an address space expressed in Undecillions (a value I'd never even heard of until IPv6 came along)? Well, I don't know, but I'd hazard a guess that it might be something to do with nanotechnology, and bio-nanotechnology in particular. How many IP addresses in a 50ml syringe of plasma?
Granted, nanotechnology, which has been around for decades, hasn't cracked the issue of unique addressing at a molecular or cellular level, but they'll get there - after all, there's quite a lot of information in DNA strands, much more than a 128-bit binary string, and when they do get there, they'll look for an existing and ubiquitous addressing schema, rather than create a new one. It wouldn't surprise me if Professor Kevin Warwick, "Captain Cyborg" is involved. And then perhaps, we'll enter into a brave new world of Mendelian, or possibly Mengeleian, eugenics.
I digress. For now at least, the issue of availability of IP addresses is resolved with the availability of IPv6. We still have and use IPv4, and will do for the foreseeable future - with appropriate use of existing alleviating mechanisms already described.
IP Performance exhibit at a couple of the major Universities conferences, UCISA and Networkshop, run by JANET UK, and this year both featured sessions on IPv4 address exhaustion and IPv6 adoption. Universities have a fairly static address base, large IPv4 Class B allocations, and many manage the increasing student body IP addressing requirements (laptops, smartphones, iPads etc) with private (eg. 10.x.x.x) addresses and shortened DHCP leases, so why the sudden pressure to adopt IPv6 now, if sheer numbers are not the issue?
The main drivers are interconnectivity, and to a certain extent, performance. As mentioned earlier, IPv4 and IPv6 are incompatible addressing schemas and mutually exclusive. Therefore, a method is required whereby resources can map between the protocols, tunnel or encapsulate one within the other, or support both on the same interface (referred to as dual-stack). At the end-point level, dual-stack is the preferred method - Windows Vista and Windows 7 systems are natively dual-stack, and will try to connect using IPv6 first, only defaulting to IPv4 if no IPv6 connectivity is available. This can lead to an unsatisfactory user experience in non-IPv6 environments, as client endpoints negotiate their connections. In time, non-IPv6 enabled organisations may find certain internet resources unavailable to their users, or find their Internet-facing web servers cut off from parts of the Internet (this will most likely occur first in Asia and the Far East, as described earlier). As IPv4 address blocks become scarcer, more expensive or unavailable (reserved or exhausted), pockets of the Internet may become IPv6-only. A more likely outcome is that organisations will have to go through complex IPv4 address schema redesigns to reallocate existing IPv4 addresses to any new Internet-facing interfaces that are deployed, as dual-stack implementations. This may account for recent headlines such as Microsoft's bid to purchase nearly 700,000 IPv4 addresses from bankrupt telecomms giant Nortel Networks for $7.5M.
Organisations should be checking the IPv6-readiness of their own Internet-facing web servers and supporting IP infrastructure, their Internet access and their browser-enabled endpoints. This should include (but not necessarily be limited to) PCs, laptops, servers, load balancers, proxies, routers, L3 switches, firewalls, WLAN access points, DHCP and DNS servers. Organisations should also be checking their ISPs' IPv6 readiness or strategy for IPv6 adoption. It is the ISPs and other Service Providers who will have the biggest headaches, having to upgrade hardware and software from a diversity of network vendors in an overlay architecture to support the two protocol families for the forseeable future. How and when they architect this will be down to their particular technical issues and business plans - a full blown two-tier overlay, tunneling and encapsulation to certain IPv6 supernodes, dual protocol stacks on every router interface? It's important to find out how your ISP will fit with your IPv6 plan. A good article on ISPs considerations in planning IPv4 to IPv6 transition can be found here on the searchtelecom.com website.
A good starting point for checking endpoint IPv6 readiness is the test tool at test-ipv6.com. This autorun tool will check your browser's compatibility with IPv4 and IPv6, local DNS resolution for both, as well as your ISP's DNS resolution for both. It will at least inform you whether or not you need to start discussions with them!
A date for your diary: it's less than a month to World IPv6 Day, 8th June 2011!
No, it's not another Y2K Judgment Day, the Internet will not collapse, and Chicken Little need not fear. World IPv6 Day is when Global players such as Google, Facebook, Yahoo!, Akamai and Limelight Networks will join other major organisations in offering their content over IPv6 for a 24-hour “test flight”. The goal of the Test Flight Day is to motivate organisations across the industry – Internet service providers, hardware makers, operating system vendors and web companies – to prepare their services for IPv6 to ensure a successful transition. Don't expect any 'naming and shaming' ISP-wise, but it might indicate some regional anomalies and inconsistencies, and encourage organisations to push on with planning and rolling out their IPv6 adoption programs.
So yes, you should care about IPv4 address space exhaustion and the transition to IPv6, and I hope I have explained why in the preceding paragraphs. Use the test tool, and follow the events of World IPv6 Day, and then start validating and verifying your systems. Use the results to establish your current status, and then develop a transition strategy as appropriate. If you do it now, or at least assess the risks and mitigate accordingly, you will save a lot of stress and anxiety later when you are forced to migrate.
Afterword: Rob Bailey wanted me to expound on Jumbograms. I had one of those on my stag night, many years ago. It's a dim and distant memory, and not one that I care to drag back into the light of day for scrutiny, so sorry Rob, I'll pass...
by Pierre | 12 May 2011
Disclaimer: The opinions expressed in this blog represent those of the blogger or original article writer (if reproduced or linked to), and not those of IP Performance Ltd or IP Performance Ltd's subsidiaries, vendors, distribution channel or other business partners. Furthermore, all content being the responsibility of the individual blogger or original author, it is not intended to malign any religion, ethnic group, club, organisation, company, or individual. All data and information provided on this site is for informational purposes only. IP Performance Ltd makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.
1 Comments
Joshua Scrumm
June 1st, 2011 at 14:44pm
So, what's all this, then?