Today is the day many companies and organizations permanently enable IPv6 for their products and services. This is a big deal.
We’ve had all of our major public servers accessible by both IPv4 and IPv6 for some time, and continuously since World IPv6 Day last year. We’ve also been assigning IPv6 networks by request to customers with routers and network gear capable of supporting it. We’d love to assign more, but although enterprise-grade equipment and every major computer operating system supports IPv6, support in consumer-grade equipment such as DSL routers has been in a chicken-and-egg limbo for years.
So what’s the big deal?
The Internet has run on the IPv4 protocol since September, 1981. An IPv4 address is a 32-bit value, which provides around 4 billion unique IP addresses. Even though changes have been made to the allocation and usage of this space, from replacing the original classed network system with CIDR to routing schemes like NAT, it was never really designed or intended for an rapidly growing public Internet, and it’s clearly at the end of its road.
IPv6, which has actually been around for longer than you might think, is the next generation of Internet addressing. Will it ever fully replace IPv4? That’s unknown but the days of freely allocating more IPv4 addresses are at an end.
IPv6 uses a 128-bit address and provides a vastly larger number of unique IP addresses. Large enough to handle 4 billion unique organizations each with 4 billion unique clients each with their own 64-bit address space, itself 4 billion times larger than the entire IPv4 address space. IPv6 provides the room to create and implement advanced networking features like auto-configuration, efficient routing, and simplified renumbering.
What can you do to help move us further away from IPv4?
Talk to your Internet and/or hosting provider about IPv6 and ask about their deployment plans. Ask them to publicly comment or announce their plans. Talk to your IT department and ask the same questions.
Welcome to the production Internet!
Congratulations to Tegile, whose press release today (picked up on multiple news sites, links below) includes one of the reasons we chose their HA2100EP storage array for our needs: Low latency & high throughput. We also needed iSCSI and F/C for our customers.
Newcomer gets out its box, plans to sell it cheaply to all comers http://ger.ms/LTjuzY
Tegile Selected as a Red Herring Top 100 North America Tech Startup http://ger.ms/KxUJZE
Our vmForge VDC clusters are peaking around 14,000 IOPS and the MASS solution is offloading about 11,500 IOPS via SSD. I wish I could graph this and show it to the public at large but I don’t have a way yet. (those are peaks, average is closer to ~8,000 IOPS with ~6,900 IOPS via SSD)
We’ve been working on building a proper vmForge account creation and management site, so for the last couple of weeks I’ve worked a lot with the vCloud API. It’s a RESTful system, which means everything’s done by getting XML from and posting XML to a web server. It’s perhaps not the worst API I’ve ever worked with, but its tedious to work through. Even more so because their parser is insanely pedantic, to the point of requiring elements in a specific order. So that’s a point in PHP’s favor, that it maintains key order in associated arrays.
There is always confusion about what DNS does and what it doesn’t do. In particular, I see constant reference to DNS functions mixed up with web server functions, and vice-versa. Hopefully this post clarifies things a bit to separate what DNS does and what web servers handle.
While the majority of people know about A, CNAME, and MX records, DNS actually has many dozens of types in common use, and many more dozens of faded historical use that aren’t used at all.