SolidBLOG

AfriNIC, Africa’s new Internet Numbers Registry, is now experiencing a wave of growth as mobile companies are starting to shift their attention to buying IPv6 addresses in order to keep up with the expansion of mobile data services.

With the entry and the rising popularity of 3G mobile data services, IPv4 allocations have increased dramatically. In three years time, AfriNIC predicts that the number of addresses that will be allocated will double to approximately 32 million, and by around 2012, IPv4 addresses will run out. This then puts more pressure into shifting to IPv6 — the next-generation Internet protocol that is the best alternative to IPv4.

An article by Russell Southwood notes that:

In 2005 there were only four allocations of IPv6 addresses but now there are nearly 60 allocations so the transition point may well get closer as mobile companies transition first to IPv4 addresses (exhausting the existing allocation more quickly than the 2012 prediction) and switch to IPv6. As Adiel Akplogan notes: ”This runs to billions of addresses.” AfriNIC is looking to make sure that IPv6 addresses are deployed in each African country.

Aside from the obvious difference in address space, with 128 bits for IPv6 and only 32 bits for IPv4, IPv6 also has other features that organizations such as AfriNIC find attractive. Some of these features that Adiel Akplogan, AfriNIC’s CEO, specified were cited by Southwood:

And those features? Akplogan said:”Security is embedded in IPv6 and it’s possible to encrypt communications and there will be the development of apps around that as it will be possible to safely encypt on the fly.

But the key draw in terms of how Africa’s Internet markets are developing is IPv6 also has mobility embedded in it:”We’ll reach a point where IP addresses will become our identity. You can reach someone on any device on the same IP addresses.

A number of organisations have recognized that these advantages are relevant to Africa and have imposed a rule that all new equipment is IPv6-ready.

With the birth and rising popularity of mobile Internet showing good signs of IPv6 migration in Africa, more countries will hopefully see the importance of IPv6 and follow suit.

A new biennial report which covers various IPv6 topics has recently been released by Research and Markets.

The 2008 Technology - Internet - Volume 4 - IPv6 (1st Edition) report covers topics ranging from the IPv6 addressing system to the IPv6’s extensive support for automated assignment of IP addresses.

The report also discusses the differences between IPv6 and IPv4, as well as their similarities, competition in IPv6 address allocation and connectivity issues. The product overview from Research and Markets also added that the handbook contains discussions on:

• Future problems with the routing system unless new architectural elements are added to enable multihoming and portability without relying on BGP or host-based systems such as SHIM6.
• Suitability of SHIM6 for multihoming.
• Transition arrangements for IPv6 connectivity via IPv4 tunnels.
• Competition in IPv6 address allocation.

Since this is a biennial report and the publication date of the next issue will still be on May 2010, it might be a smart move to check this handbook out.

Last month, Heise Online reported on efforts to push for adoption of IPv6 in Europe in the article. “EU Commission promotes IPv6“. The opening paragraph reads:

Twenty-five per cent of all European users should have the opportunity to use IPv6 by the end of 2010, and should be able to access most of their normal services and content with it. The EU Commission will set this goal in a statement, to be published at the end of May, on the new internet protocol and progress in the net. Detlef Eckert of the General Directorate for Information Society and Media presented the key points of the statement and a related action plan at the RIPE meeting in Berlin. The Commission is joining organisations like the Réseaux IP Européens Network Coordination Centre (RIPE) in calling for rapid action in the face of dwindling reserves of IP addresses.

The continent also celebrated European IPv6 Day in Brussels, Beligium, last May 30. The European Commission, in its website for the event, stated:

The Information Society and Media Directorate General of the European Commission is pleased to invite you to the “European IPv6 Day” that will take place in Brussels, Belgium, on the 30th of May of 2008 at the Robert Schuman room inside the Berlaymont building. The event will see the launch of the Communication “Advancing the Internet action plan for the deployment of Internet Protocol version 6 (IPv6) in Europe”.

The main goal of the Communication is to promote IPv6 adoption through a wide range of actions encouraging public administration, users and industrial stakeholders to take decisive steps to accelerate the implementation of IPv6, so as to ensure Europe’s readiness to face the expected depletion of the IPv4 addresses. Moreover, the prompt and efficient adoption of IPv6 offers Europe significant opportunities to boost innovation and develop a leading role in advancing the Internet.

It’s good to see that Europeans are taking IPv6 migration seriously. Governments and regulatory bodies would do well to put in place measures that encourage IPv6 adoption through real, palpable incentives. How does an IPv6 tax break sound?

Improvements to the Border Gateway Protocol (BGP) were supposed to address the unprecedented growth of routing tables (and the attendant processing overhead they required) experienced in the 1990s. The scalability problem however, is still with us, this time perhaps due to multihoming, traffic enginnering, and plain poor housekeeping. Real, long-lasting solutions must be implemented.

In the article “Internet routing shows growing pains—again“, Iljitsch an Beijnum discusses the issue. Here’s a sample from the article:

However, both the IETF and its research-focused sibling the Internet Research Task Force have studied the problem as a whole or certain aspects of it over the past decade. When IPv6 was developed, this was seen by many as an opportunity to fix the routing scalability problem as well. However, the argument that you can only make so many changes at once won out—along with the fact that back then there was no easy way to solve the routing issue, either. A few years later, Mike O’Dell wrote up the famous “8+8″ or GSE proposal. The idea behind it is to allow routers to rewrite the upper 8 bytes of the 16-byte IPv6 address and hosts only look at the lower 8 bytes. This addresses multihoming, traffic engineering, and provider independent addressing. However, the proposal was never developed any further and suffers from a number of issues.

Will IPv6 be up to the challenge? That’s an interesting question, but can we even ask that question about IPv4? That’s like taking a step backwards.

We found this little gadget by Intec Netcore while surfing the Web. The IPv4 Exhaustion Counter gives you an idea of the state of IPv4 address exhaustion at a glance. The tool can also be found on this blog’s sidebar (but you can see that, right?).

The website for this tool is at: http://entne.jp/tool/toollist/000101.php

Here’s the javascript code for your blog:

<script src="http://entne.jp/labs/blogparts/wolf3/en-us/wolf_c.js" type="text/javascript"></script>

The authors have licensed this blogpart under a Creative Commons License [Attribution-NonCommercial-NoDerivs 2.1 Japan].

Have at it!!!

A white paper designed to assist wireless service providers move to IPv6 was released last month. “Transitioning to IPv6″ was recently published by 3G Americas, a wireless industry trade organization made up of of telecommunications service providers and manufacturers.

In its annoucnement “3G Americas Provides IPv6 Transition Recommendations for the Americas“, the group noted that:

As UMTS/HSPA and IMS networks are deployed and usage of the mobile Internet continues to rise, the wireless industry will continue to experience explosive growth. New always-on services will likewise require devices to be always available; thus, wireless service providers will require a substantial number of IP addresses to support such services. Current IPv4 addresses are being depleted at a very rapid rate, and are expected, by some analyst predictions, to exhaust as soon as 2012.

The white paper by 3G Americas addresses the problems that will occur when new IPv4 address blocks are no longer available. Service providers will face increasing capital expenses and numerous challenges when attempting to operate their networks efficiently on a limited number of IPv4 addresses. Not only does transitioning to IPv6 solve the address exhaustion problem, it will likely enable new services perhaps impossible in an IPv4-only world. The 3G Americas’ white paper strongly recommends that rather than wait for the inevitable difficulties to arise, service providers should begin planning their transition to IPv6 as soon as possible.

The white paper can be downloaded at: http://3gamericas.com/pdfs/2008_Ipv6_transition_3GA_Mar2008.pdf

The time to plan your move to IPv6 is now. Waiting for the inevitable address crunch looks like a really bad idea.

Despite the fact that IPv6 has been around for over 10 years, it seems that its implementation for DNS has quite a way to go. Sure, some of ICANN’s root servers can handle the new protocol, but not all the downstream components are ready. This was made evident in a post by Patrick Vande Walle in “Are Domain Name Registrars Ready for IPv6?“:

Now that ICANN has added IPv6 name servers for the root zone, and that many registries have enabled IPv6 on their DNS servers, I thought it would have been easy to update the DNS records pointing to my domain to mention a IPv6-only DNS server. This way, we could have native name resolution end-to-end in IPv6. We are not there yet, it seems.

The web interface my registrar (Gandi) uses does not allow IPv6 addresses. Their support desk informed me that they do not yet handle IPv6 addresses in their web forms.

It’s not enough that your network and operating systems support IPv6. Applications — and their user interfaces — must be ready to accept IPv6 addresses and their associated characteristics. Most routers in service probably already know how to handle IPv6 traffic, but there’s still a lot of work to be done. DNS servers and their interfaces have to be upgraded to make a smooth transition possible. If your network’s host machines use DHCP, then your DNS/DHCP servers need to have DHCPv6 running. And, as illustrated above, Internet Registries and Registrars must be able to process IPv6-related requests.

Many DNS servers are “home-built” affairs, cobbled together using no-name clones and open source software. There’s no problem at all with this setup, as long as the person creatign the server knows what he is doing and meticulously configues all the necessary parameters. That, too, is relatively easy if you’re doing it once or twice. But large ISPs, enterprises, and Interrnet Registries/Registrars managing thousands of domains and servers at disparate locations may want to turn to professionally built and maintained turnkey solutions, such as DNS appliances.

So the question remains: Is your DNS ready for IPv6?

You’ve got to forgive us for missing this one when it came out a couple of weeks ago. Better late than never though, so we’re happy to note that Red Hat Enterprise Linux (RHEL) now has even better IPv6 support. This was reported in the article “Red Hat Enterprise Linux 5.2 Beta released“:

The new RHEL will also be able to boast of superior IPv6 support. This will include a DHCPv6 (Dynamic Host Control Protocol) client and server. With this in place, it will be much easier to deploy IPv6 network addressing across an entire LAN or WAN.

DHCPv6 allows network administrators to easily automate and manage the assignment of IPv6 addresses and to pass on other information to network hosts (such as the DNS server).

RHEL is a popular Linux distribution (with a free, community-compiled binary distribution known as Community Enterprise Operating System — CEntOS), so better support for IPv6 will be a welcome addition for those RHEL users who wish to move their Linux networks over to the new architecture.

Resources

• The Red Hat Enterprise Linux 5.2 Beta Announcement
• DHCPv6 on Wikipedia

Is Google playing with IPv6? Check out this link and find out: http://ipv6.google.com.

The little morsel above was posted at the IPv6 Portal, in the short article “Is Google Live With IPv6?”

Google doesn’t seem to have made their IPv6 page official yet, but it’s out there. You can try to ping it. Here’s what I got:

[maddog@localhost ~]$ ping6 -c 5 ipv6.google.com
PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes
64 bytes from 2001:4860:0:2001::68: icmp_seq=0 ttl=55 time=287 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=1 ttl=55 time=347 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=2 ttl=55 time=291 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=3 ttl=55 time=288 ms
64 bytes from 2001:4860:0:2001::68: icmp_seq=4 ttl=55 time=287 ms

— ipv6.google.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 287.906/300.712/347.333/23.359 ms, pipe 2
[maddog@localhost ~]$

Smart move, Google!

Is a million-dollar corporate DNS breach a disaster just waiting to happen — soon? That’s the impression one gets when reading the latest news on emerging threats to the system that allows users to connect to various internet hosts using names instead of IP addresses.

Paul Mockapetris, the man who invented the Domain Name Service (DNS), said that new ways of hacking DNS may put users at risk. This was reported last month in “DNS Inventor Warns of Next Big Threat“:

Mockapetris — who is also chief scientist and chairman of the board for network naming and address vendor Nominum — says the recent research on corrupted DNS resolution servers by researchers at Georgia Tech and Google demonstrates yet another way the bad guys are attacking DNS to infect users. (See Hacking a New DNS Attack .)

Researchers David Dagon, Chris Lee, and Wenke Lee of Georgia Tech, and Google’s Niels Provos, dubbed the new threat “DNS resolution path corruption,” where malicious DNS servers provide false information in order to send users to malicious sites. The researchers officially presented their findings today at the Network and Distributed System Security Symposium (NDSS) in San Diego.

Quite often, DNS servers can be hacked because of seemingly minor misconfigurations. SecuriTeam, for example, in the January 20, 2008, report entitled “Common DNS Misconfiguration can Lead to “same Site” Scripting“, noted how a simple typographical error in DNS records could leave a server open to attack (note: the information for the SecuriTeam report was provided by Tavis Ormandy):

It’s a common and sensible practice to install records of the form “localhost. IN A 127.0.0.1″ into nameserver configurations, bizarrely however, administrators often mistakenly drop the trailing dot, introducing an interesting variation of Cross-Site Scripting (XSS). Tavis calls it Same-Site Scripting. The missing dot indicates that the record is not fully qualified, and thus queries of the form “localhost.example.com” are resolved. While superficially this may appear to be harmless, it does in fact allow an attacker to cheat the RFC2109 (HTTP State Management Mechanism) same origin restrictions, and therefore hijack state management data.

The result of this minor misconfiguration is that it is impossible to access sites in affected domains securely from multi-user systems. The attack is trivial, for example, from a shared UNIX system, an attacker listens on an unprivileged port[0] and then uses a typical XSS attack vector (e.g. <img src=…> in an html email) to lure a victim into requesting http://localhost.example.com:1024/example.gif, logging the request. The request will include the RFC2109 Cookie header, which could then be used to steal credentials or interact with the affected service as if they were the victim.

Another attack vector exists where a victim connects to a site from (or via) a machine that hosts another website, any XSS-like flaw or reflective web service on the hosted website can therefore be exploited in the context of the mis-configured domain. This would also affect users who connect via a shared caching http proxy machine, that also hosts an HTTP daemon.

Experts have been warning of the dangers faced by DNS for years, but how many administrators are up to date? And how many are effectively doing something about it?