Slashdot Mirror
IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 Allocated
mysidia writes "A total of 16,777,216 IP address numbers were just allocated to the Asian Pacific Network Information Centre IP address registry for assignment to users. Some venerable IP addresses such as 1.1.1.1 and 1.2.3.4 have been officially assigned to the registry itself temporarily, for testing as part of the DEBOGON project. The major address blocks 1.0.0.0/8 and 27.0.0.0/8, are chosen accordance with a decision by ICANN to assign the least-desirable remaining IP address ranges to the largest regional registries first, reserving most more desirable blocks of addresses for the African and Latin American internet users, instead of North America, Europe, or Asia. In other words: of the 256 major networks in IPv4, only 24 network blocks remain unallocated in the global free pool, and many of the remaining networks have been tainted or made less desirable by unofficial users who attempted an end-run around the registration process, and treated 'RESERVED' IP addresses as 'freely available' for their own internal use. This allocation is right on target with projected IPv4 consumption and was predicted by the IPv4 report, which has continuously and reliably estimated global pool IP address exhaustion for late 2011 and regional registry exhaustion by late 2012. So, does your enterprise intranet use any unofficial address ranges for private networks?" Reader dude_nl sends in a summary of the issues with allocating from 1.0.0.0/8 from the BGPmon.net blog. "As Alain Durand mentioned on Nanog: 'Who said the water at the bottom of the barrel of IPv4 addresses will be very pure? We ARE running out and the global pain is increasing.'"
Please mod-bomb this to the stone age, where it belongs.
After all, I am strangely colored.
The timelines have been sheerest nonsense. The use of NAT, and of load-balancers, has heavily reduced the need for IPv4 address space. In fact, it's often helpful in security terms to NAT a local network away from other networks and reduce the potential for unmanaged traffic: it's even extremely helpful in blocking a lot of idiot home users from running classic SMTP, HTTP, and IRC servers without paying server-based fees.
IPv6, on the other hand, has repeatedly proven itself fragile in production use, incompatible with critical older servers, and a genuine security issue with its tendency to advertise its hosts very broadly and act in a much more "mobile" fashion. This mobility is, in and of itself, a profound security issue. Many of these issues can be addressed with thoughtful configuration, but so far, I'm not seeing it in practice.
Google search it. Seriously, there are plenty of good papers on this, including modest papers such as http://www.infosecwriters.com/text_resources/pdf/IPv6_SSotillo.pdf.
The big problem is one of change: many people _do not_ properly integrate services into their networks, but instead leave themselves wide open to external and internal scanning of various sorts. The "mobile" aspects of IPv6 encourage "mobile" nodes which may be very poorly secured, and from personal experience have been.
The fragility of IPv6 in production is usually associated, from personal experience, with older operating systems and hardware. Some instances of it that I've seen are, unfortunately, under NDA. But others include the integration of ancient, older, even virtualized core software into a contemporary IPv4/IPv6 capable environment, and it's repeatedly broken software that I've had to backport.