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.'"
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.