Don’t drown in the IPv6 address sea
Our Chief Operating Officer, Joe Gersch, recently authored this blog post on managing large numbers of reverse DNS records at our partner, 6connect’s, blog site:
Our Chief Operating Officer, Joe Gersch, recently authored this blog post on managing large numbers of reverse DNS records at our partner, 6connect’s, blog site:
IP address assignments around the world are handled by the Regional Internet Registries (RIR). In the beginning of May, I had the pleasure to attend and be a speaker at the LACNIC (the Latin American RIR) conference in Cancun, Mexico. My talk about IPv6 and DNS was very well received and I think the audience really understood how running the DNS supporting dual stack or IPv6-only clients differs from running in a pure IPv4 environment. There were several other talks, most of them discussing IPv6 and how to handle the depletion of IPv4 addresses.
In terms of the depletion of IPv4 addresses, all RIRs have implemented a phased approach to handing out their remaining IPv4 addresses. In this phased approach it will be harder and harder to get IPv4 addresses allocated from the RIRs as they move from phase to phase. Most RIRs have decided that the first of these phases, the depletion phase, will be reached when about 16 million addresses (A network of size /8) are still available in their pool. However, LACNIC took a somewhat different approach. Instead they decided to go into a limited depletion phase when they reached 8 million (/9) free addresses and a more restrictive phase once they reached 4 million (/10) free addresses.
At the time of the event, LACNIC had around 14-15 million addresses left in their free pool. Demand for the last blocks has been very high and on May 20th, LACNIC announced that they are down to one /9. This means that LACNIC entered the more restrictive depletion phase and also triggered the RIR’s parent organization (IANA) to send some recovered addresses to each RIR (about 2 million addresses to each RIR).
The next phase for LACNIC was triggered on June 10th when they reached a /10 (about 4 million addresses). Once this phase is reached the policy restricts allocation to only 1000 addresses every 6 months per member. 1000 is not a lot of addresses – they can perhaps be used for translators when implementing IPv6 so that backwards compatibility with IPv4 still can be achieved using NAT64/DNS64 but not to any dual stack deployment.
The final phase will occur when a /11 (about 2 million addresses) are left. At that point a limited number of IPv4 addresses will only be available for new members.
We are, in other words, very close to going IPv6-only in Latin America. During the last year this region has used up a lot of IPv4 address space and is currently the region with the fewest IPv4 addresses remaining. Latin American service providers should make sure their DNS servers can receive traffic over IPv6 so that their customers can still reach them.
IETF recently announced the publication of RFC 7050 – “Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis”. This is an interesting RFC that will help service providers transition their customers to an IPv6 only network. I’m happy to have been contributing with minor suggestions to the authors around how the DNS pieces of the RFC should work.
RFC 7050 is really an extension to the initial DNS64 RFC (RFC 6147). If you are unfamiliar with the original RFC and DNS64 here is a quick recap:
We are running out of IPv4 addresses in the world. Service providers, especially in the wireless industry, are looking at ways of providing users with IPv6 only networks so that they still can grow their customer base. However, they still need these new customers to be able to IPv4 sites.
RFC 6147 describes a way of doing this by adding intelligence into the DNS to trick the endpoint into believing that everything is accessible via IPv6. To work properly, this trick relies on a DNS64 prefix that is configured into the DNS by the service provider.
DNS64 works very well with most applications and web sites but some applications and websites utilize hardcoded IPv4 addresses that bypass the DNS, and therefore bypass the DNS64 trick. These sites, therefore, cannot be reached from an IPv6 only network. One would hope that the owners of such applications and website would rewrite them to use domain names rather than hardcoded IP addresses, but this is not happening quickly enough. This is where the new RFC 7050 comes in.
Instead of just dropping those IPv4 only requests the idea behind RFC 7050 is that the endpoint should do its own translation. To do so the endpoint will need the magic DNS64 prefix. RFC 7050 describes a way of obtaining this prefix by doing some intelligent DNS probes. IANA has added a special record ‘ipv4only.arpa’ into the global DNS. The endpoint can do a lookup of this record, and by doing so, the endpoint can determine the DNS64 prefix and start translating IPv4 hardcoded addresses itself.
RFC 7050 is mostly for wireless services providers and it will require cooperation from handset manufacturers to be effective. I hope the handset manufactures will implement support for RFC 7050 in their software so that we all can migrate into IPv6 as soon as possible.
Even though more than two years have passed since federal government agencies were required to support DNS Security Extensions (DNSSEC) on their web sites, only 57 percent of agencies have met these requirements. In other words, about 40 percent of federal agencies have not secured their domains to protect users from domain name hijacking and cache poisoning attacks.
As this Network World article explains, Read more
We have learned some lessons in the field about DNS over IPv6. The other day, one of our clients called us asking for help with their configurations. They were doing some lab testing while working on their annual upgrade of our software. To give you some background, our customers normally certify each upgrade they intend to use and they do extensive lab testing before they roll it out to their production DNS servers. Read more
It may surprise you, but IPv6 has been has been around for the past two decades, according to a post on IT Business Edge, “Ten Myths about IPv6”
Here is a summary of those “10” most talked about IPv6 myths:
On June 6th, many major Web sites and Internet providers will begin supporting Internet Protocol version 6 (IPv6) full time. While the average internet user might not even notice, if you’re running a growing business you should prepare for this change.
As an IPv6 article, by Stephen J. Vaughan-Nichols, explains, IPv4’s 32-bit 4.3 billion addresses are not enough for today’s internet and all of our mobile devices. Read more
In December of this year the World Conference on International Telecommunications (WCIT-12) will be held. 193 nations will be coming together in Dubai to review the International Telecommunications Regulations as part of an ongoing United Nations treaty. Among other telecommunications issues these regulations are used for the Internet.
For the first time, the agenda may include such polarizing subjects as who will control the Internet; at the heart of the issues, too, is a lingering question about who will oversee the Domain Name Systems (DNS) residing on our root servers. Read more
The need to move the Internet from IPv4 to IPv6 is inevitable. Almost all of the addresses allowed by the 32 bit based addressing scheme used in IPv4 have been assigned. The 128 bit addressing scheme within IPv6 solves that issue. While the number of available addresses is a significant driver in the need for IPv6, this isn’t the only benefit to be derived. Other benefits include added security, mobility extensions, communication and addressing to the end device, etc.
The North America IPv6 Summit, one of the premier IPv6 shows in the world, was held on April 9-11 in Denver, Colorado. It focused on educating people on IPv6, providing insight on how to make the transition from IPv4, showed products and technology capable of supporting IPv6. The attendees ranged in background from people just learning about IPv6 to people who are intimately involved with implementing IPv6 with all levels of experience in between.
The event has grown every year and has added breadth of knowledge and increased participation. It is not unusual to meet people from the all over the U.S. along with people from other countries such as Brazil, France, etc… even Texas;)
The list of sponsors included a wide range of savvy companies and organization that have the foresight see the need to continue to improve the Internet.
This event was organized by the Rocky Mountain IPv6 Task Force (rmv6tf). My hat is off to the members of the rmv6tf. This is a group of volunteers who see the inevitable need for the Internet to move to IPv6. The group was formed in 2007 by a handful of dedicated technologists. They have organized this event every year since 2008 with consistency and quality to create the summit.
This event is one that was worthwhile to attend if you have any interest in the future of the Internet. Here is the site for information from the event: http://www.rmv6tf.org/IPv6Summit.htm
We may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.
Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.
These cookies are strictly necessary to provide you with services available through our website and to use some of its features.
Because these cookies are strictly necessary to deliver the website, you cannot refuse them without impacting how our site functions. You can block or delete them by changing your browser settings and force blocking all cookies on this website.
We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.
Google Webfont Settings:
Google Map Settings:
Vimeo and Youtube video embeds:
You can read about our cookies and privacy settings in detail on our Privacy Policy Page.
https://secure64.com/company/privacy-policy/