IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 Allocated 467
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.'"
they should start selling IPadresses like phone (Score:3, Interesting)
numbers and car plates.
I'd love to have 1.1.1.1, or 29.09.19.69 (my bday)
Install your own 6to4 tunnel today (Score:5, Interesting)
Run this script to get your own IPv6 address today:
CUR_IP=(`ip -4 addr show ${CUR_DV} | awk '/inet / { print $2 }' | sed -e 's/^\(\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*$/\1/'`)
IPV6_ADDR=$(printf "2002:%02x%02x:%02x%02x:%04x::%04x" $(echo "${CUR_IP} ${SLA_INTF} ${INTF_ID}" | tr '.' ' '))
ip tunnel add tun6to4 mode sit remote any local ${CUR_IP} ::/0 via ::192.88.99.1 dev tun6to4 metric 1
ip link set dev tun6to4 up
ip -6 addr add ${IPV6_ADDR}/64 dev tun6to4
ip -6 route add 2002::/16 dev tun6to4
ip -6 route add
Install radvd if you want to share your new IPv6 subnet with other people on your local network.
This is all it takes. You do not need to wait for your ISP to get a clue.
Only problem is this does not work with NAT.
Re:No (Score:4, Interesting)
And as long as 4.2.2.2 remains ping-able so I can quickly whether just DNS or the net in general is down I'm okay with any reallocation.
It actually might not be for long, Level 3 is closing public access to it and only allowing its use for their own customers.
Wouldn't more widespread SNI support be nice? (Score:1, Interesting)
Where I work perhaps 50% of our IP allocations are due to requests for SSL websites. Now imagine a world without IE6/Windows XP where IIS supported SNI. Unfortunately I suspect Microsoft has once again been far too slow to catch up. That was the obligatory Microsoft bash out the way - seriously though, how long is it going to take to finally lose the ridiculous single address per site requirement for websites in a globally supported manner?
Re:Ill bet this will happen (Score:2, Interesting)
We are a very reactive culture, generally. We don't seem to believe in using foresight to ease predictable and inevitable suffering of any kind.
Because it's usually more expensive and difficult than dealing with problems when they actually become problems.
Re:Install your own 6to4 tunnel today (Score:5, Interesting)
http://www.sixxs.net/main/ [sixxs.net] (www is required, the site isn't perfect but it works)
I currently have two tunnels (one to an out of house server & one to my house), a subnet for my house (I've tested it, I can ssh from an external server directly to my in-house computers without any port forwarding). It adds a little latency (since you have to go through some other router before reaching the ipv6 part of the internet), but not too bad.
Hurricane Electric is also a great option. (Score:4, Interesting)
I run an HE tunnel at home to provide IPv6 connectivity to my personal network, and it's been working great, and has the advantage over SIXXS of more geographically distributed tunnel endpoints (SIXXS' seem to be clustered on the east coast, while, HE has endpoints in California, among other places). Though you do need to rig up a script to update the tunnel should your IP address change.
Throw in a free v6-capable DNS hosting service like freedns.afraid.org and you're laughing.
Unfortunately, applications still behind the curve (Score:5, Interesting)
When I discovered m0n0wall 1.3 hit the pavement, with support for IPv6, I made the move to transition my home network to v6, for no other reason than it seemed like an interesting thing to do (what can I say, I like to tinker). In the process, I looked to moving all my services to v6... obviously I can't completely abandon v4 internally, but I figured, why not move all my internal stuff over? Problem is, among the software I use, the following don't support v6 at all:
Linux NFS client and server
MySQL
MythTV
rtorrent
m0n0wall's VPN implementations (both IPSec (ironically) and PPTP)
And those are just the first four that popped up (though at least I was able to patch rtorrent). God knows what other software out there doesn't support v6. Of course, many of these things can live in private v4 networks for the time being, but until application vendors catch up with the times, it seems v4 and v6 will be living side-by-side for a long time to come.
reclaim dead ip space first (Score:2, Interesting)
ARIN is totally incompetent; Not only does the Prudential have a /8, but back in 1992 when I worked at the Prudential Bank in Atlanta, that totally separate division applied for and got a class-B (158.221) and still holds it to this day. The ridiculous thing is that they will never use it, never did and when I tried to get ARIN to look into getting it back in the late 1990s, that fell on deaf ears. In fact, the Prudential Bank doesn't even exist anymore at the address in the registry entry for 158.221; I don't know if they even exist at all anymore. Go and reclaim dead IP space, and then see what is left.
Re:Ill bet this will happen (Score:5, Interesting)
I actually called my ISP last week and asked if I could get an IPv6 address. They told me Cisco said they won't have to worry about it for at least a couple of years, so they (my ISP) haven't even started thinking about it, yet. I guess they're going to wait until the last IPv4 addresses run out and have a mad rush to assign IPv6 addresses. That'll be fun...
Re:they should start selling IPadresses like phone (Score:3, Interesting)
Only issue with that is how the routing system works. Routers are incapable of keeping track of where every single individual IP is located on the internet. Instead they just get announcements for very large networks, and then as the packet gets closer to its destination it can be tracked with greater and greater granularity.
Dynamic DNS is a much better approach - it separates the implementation of the naming and the routing functions.
I have no idea how the phone system manages to handle number portability. I suspect that either they just rely on the fact that relatively few numbers are ported, or they do a one-time lookup on the phone number to get a different "real" network address for the phone and use that for the routing. That basically just treats the phone number as a DNS address and your local switch as the real IP address.
I don't know (Score:5, Interesting)
There has been an increasing amount of IPv6 support out there. Part of the problem in terms of going IPv6 right away is that many of the high end routers out there accelerate IPv4 but don't accelerate IPv6. Basically when you deal with large amounts of data, it is infeasible to do everything in software. So you have ASICs to help speed everything up. Works great, but said ASICs have limits to what they can do and being hardware, can't simply be reprogrammed. This means you have to buy new hardware to support IPv6, which is of course expensive.
We had that situation on the campus I work on a few years ago. Some people were wanting IPv6 but we didn't support it. Technically, it could be enabled and run on the routers' CPUs but that would only work if a few people used it. If usage got higher, the routers would crash under the load. We needed new routers (or more properly new supervisor modules for them) to support it. However, it was really expensive, a few million for all of campus. That money was not going to be spent just so people could play with IPv6.
However, we've had to upgrade the routers anyhow to support more traffic and such, so now they have IPv6 hardware and IPv6 is routed on campus.
Thus I think you'll see this continue to happen. New hardware supports IPv6, companies will get it, and will then be able to support IPv6 no problem. It just won't be an immediate process. They aren't going to go and buy IPv6 hardware just to get IPv6 support if they don't need it. However, when they need new hardware anyhow, the stuff they get will have IPv6 support.
I think we are more likely to see a gradual change. More and more networks will start supporting IPv6, and people will start using it because it'll be cheap. An ISP will say something like "Well sure, you can buy IPv4 addresses for $10/month each, however your account includes more IPv6 addresses than you can ever use for free anyhow." So people will start using it.
Re:Install your own 6to4 tunnel today (Score:5, Interesting)
I use SIXXS, it's been working great.
Be careful...Jeroen runs SixXS with an iron fist, and actually monitors the content you host. This, to me, is unacceptable. And don't get on Jeroen's bad side: You'll be shut down in a heartbeat if you dare question (publicly or privately) any part of the SixXS infrastructure in a critical way.
My suggestion: Run from SixXS as fast as you can. HE is great to work with, and they have no interest in what you host via their IPv6 service.
Re:How's NAT64 coming along? (Score:3, Interesting)
Our present situation is due in large part to the incompetence of the IPv6 designers and their total and complete failure to plan, or even recognise the need, for a transition.
The IPv4 address space could have been embedded in the IPv6 space. If the existing standard couldn't handle it, then that standard needed to be changed so it could have. IPv6 machines needed native capability to talk to IPv4 devices. Their lack of it is a damning indictment of the design team and puts a serious question mark over their ability to design adequate technologies.
A lesser problem, but still an important one, was the current IPv6 address naming system. The addresses are inherently long, but no serious effort was made to mitigate this. A complex and self contradicting set of "shortcuts" was the extend to which the designers went to try and mollify a problem they knew was coming, but largely ignored anyway. It will fall to third parties to design the neccessary conversion tools and standards that network engineers around the world will need to use IPv6 in daily practice. Again, a clear sign of incompetence.
5 years ago, when IPv6 adoption rates were recognised as a problem, the designers should have taken steps to make the transition smoother. They didn't bother to do that. As a result, IPv6 in its current form can never be used to make the smooth transition that is required. Instead, we will have a painful and troublesome upgrade process which will give headaches and interoperability problems for the next 40 years, if not simply forever.
This problem will never go away. Once IPv4 runs out completely, there will be a mess of an internet with NAT in places and misconfiguration or conflicting IPv4/IPv6 capable clients with two addresses each all desperately trying to send messages to one another over the tangled knots and wires of madness that the internet will have become. Only reliance on the end to end principle will prevent total and utter meltdown.
It's going to be nasty, and we're all going to have to get used to it.
Re:Ill bet this will happen (Score:3, Interesting)
The reason that there will likely be no freak out is that this problem will only affect providers and anyone who wants to get a new routable IP after the IPv4 addresses run out. That is a much smaller group than everyone in IPv4 space and it is a group that is more likely to have an understanding of what needs to be done internally. They aren't going to need to hire COBOL experts to fix their banking code to prevent it from breaking by a certain hard and fast date.
For the people who continue to use IPv4, there will be no problem, they have their IPs and they can keep using them and won't even notice until they need to get new IPv6 addresses. For those people it may well be possible for them to use IPv4 indefinitely if they reorganize their network to use private networks internally. Even if their provider requires them to use IPv6 to connect to them, chances are that the change only needs to be done to the external hosts/routers and the rest can continue to live in IPv4 La La Land.
That's not to say that this is not a big deal for providers, but you would be surprised how many providers have actually started rolling out their IPv6 infrastructure. Even then, the providers don't have to care for at least a little while longer, because they already have blocks and they will just charge a lot more for each new IP that a customer wants. In that way, there may be a short term benefit for providers to allow it to become a hassle for new customers.
Re:How's NAT64 coming along? (Score:3, Interesting)
Squid is v4 and v6 aware, which means if you have an IPv6 host using squid, it can talk to an IPv4 host. If you have an IPv4 host, it can now talk to an IPv6 host as well. The only downside here is that it requires configuration of the proxy in the browser directly, you can't (easily, without DNS spoofing) transparently proxy all requests. Fortunately, this is generally not an issue for any business with a competent network admin staff.
Considering how many networks already deploy squid..
Re:Ill bet this will happen (Score:1, Interesting)
Posting AC to protect the guilty.
From personal anecdotal evidence, there are a lot of wasted IPs out there and it's at least partially ARIN's fault. The easiest way to get an AS number from ARIN is to get a /22 (1024 IPs) from them. You need an AS number to run BGP, and you need to run BGP if you want to be able to do failover between ISPs.
So, if you're serious about providing uptime for your services, the easiest route to be able to do so is to lie to ARIN and tell them you have need of 1024 public IPs. I have clients with multiple /22 networks (multiple datacenters) and they're only *really* using 10 or so to serve up traffic. The rest are allocated to a Linux box which responds to pings in case ARIN ever bothers to check on whether the required 60% is actually being used.
ARIN has this ridiculous notion in their heads that someone who only needs a handful of IPs couldn't possibly need to handle their own routing. Modern load balancers are capable of serving to hundreds if not thousands of real servers on an RFC 1918 backend network via NAT and pushing multiple gigabits of traffic through a single public IP. Most medium sized sites have no need of large IP allocations, but they do need to handle their own routing and failover.
Re:AnoNet (Score:2, Interesting)
Re:Unfortunately, applications still behind the cu (Score:4, Interesting)
POSIX support is easy if you use the new generic getaddrinfo and getnameinfo. Code needs to be ported from the old way which hardcoded IPv4 addresses (AF_INET). A properly written program will support both IPv4 and IPv6 and will use the right one based on network interfaces and DNS.
Re:Ill bet this will happen (Score:4, Interesting)
Is there any physical reason why a router couldn't do the following to transparently enable ipv6-oblivious software to effectively "inverse-NAT the rest of the world"?
1) Connect, and note the /48 assigned to the site by the ISP (for this example, let's say (37a1:de19:7f9b/48).
2) To the inside network, the router looks just like any other ipv4 router. For the sake of argument, let's pretend it's allocating ip addresses 192.168.100.100 to 192.168.100.199 via DHCP
3) A desktop PC on the local network asks the router for an IP address. It gets 192.168.100.101.
4) That desktop PC later sends a request to fetch http://www.slashdot.org./ [www.slashdot.org] The router intercepts the DNS request.
5) The router does the dns lookup, and discovers that Slashdot's IPv6 address is 2005:1234:5678:1::1.
6) The router makes up a fake ipv4 address. To do so, the router declares 10.0.0.0/8 to be off-limits for use on the local network as a local address so they can be hijacked for this purpose, instead. It picks one -- 10.5.17.88 -- then makes a note to itself that it expires in an hour, and answers the DNS query from the local PC: Slashdot's IP address is 10.5.17.88, with TTL=60 minutes.
7. The local PC's browser sends a http request to http://10.5.17.88./ [5.17.88]
8. The router sees the outbound datagram with a 10.0.0.0/8 address. It does a quick lookup from its own local table, and sees that the real ipv6 address is 2005:1234:5678:1::1. It proceeds to send a fake ipv6 request to 2005:1234:5678:1::1 that appears to be from 37a1:de19:7f9b:1:6969:0192:0168:0100:0101. Yeah, the lower 64 bits completely stomp on the intent of every ipv6-related RFC, not to mention inefficiently maps decimal octets to 16-bit values for the sake of human-readability. Deal with it. It works anyway, and makes life a little easier during the transition. ;-)
9) Slashdot's server receives the request from 37a1:de19:7f9b:6969:192:168:100:101, and sends the response.
10) The router gets the datagram. It sees the 6969 (a value dictated by the router that might very well be randomly pulled out of a hat), which confirms to it that the lower 64 bits contain the local ipv4 address encoded in human-readable form. It rewrites the datagram, and passes it along to the local network.
11) The local PC gets its response from 10.5.17.88, and never knows the difference.
The router would need a big chunk of ram to keep track of the kludged dns lookup table, and would have to do more than routers do now to keep up the facade of an ipv4 universe for blissfully-oblivious clients on the inside... but it seems like it would nicely solve the problem of ipv6-unaware software by giving end users another decade or two to sidestep the problem. Their "real" ip address (site network) would be ipv6, but everything that's ipv6-unaware would be able to think it was really sitting behind a public ipv4 address.
For an added level of security (making it harder for random traffic from the outside to directly reach inside hosts), instead of picking a value like '6969' for the fourth 16-bit chunk, it could pick a new random value every hour, use it to XOR the lower 64 bits, and use THAT value for the fourth chunk. When incoming requests came in, it would xor the lower 4 16-bit chunks against its current random value, and compare it to the value presented as the fourth chunk. If it didn't match, it would try again with its previous random value. If it found a match, it would pass it along as per step 10. Otherwise, it might variously refuse the connection, return random junk, silently ignore it, and/or blackhole that IP's source network for some period of time to protect itself.
For hosts intended to have direct accessibility from the outside, the fourth chunk might have a different interpretation. For example, using 0xf as the high 4 bits to flag it, and the lower 12 bits of chunk #4 to indicate the port. So if the local PC whose ip a
IPv6 Unique Local Addressing + IPv4 NAT works (Score:1, Interesting)
1. Most offices can run off a single IPv4 static IP address: the majority of my sites use 192.168.1.0/24 internally.
2. For permanent internal IPv6 access, I route Unique Local Addresses [wikipedia.org] to each site. All the company uses a
3. I use tinc to link together my IPv6 sites over IPv4 Internet: this is the original work I did back in 2007 [tinc-vpn.org]; I've long since figured out how to dynamically route with OSPFv3 instead of static routes.
4.I've been regularly blogging about my IPv6 findings in my tech blog, as well as collaborating with a friend or two via StumbleUpon & Facebook. http://unquietwiki.blogspot.com/search?q=IPv6 [blogspot.com]