iana.org still shows 7 unallocated blocks in the free pool... anything 5 or under will indeed trigger the final blocks to go to the RIRs, but I totally don't see any source that verifies that this happened yet.
Can someone provide a second source?
Block 39 still shows up as reserved:
NetRange: 39.0.0.0 - 39.255.255.255
CIDR: 39.0.0.0/8
OriginAS:
NetName: RESERVED-39A
NetHandle: NET-39-0-0-0-1
Parent:
NetType: IANA Reserved
RegDate:
Updated: 2002-09-12
Ref: http://whois.arin.net/rest/net/NET-39-0-0-0-1
OrgName: Internet Assigned Numbers Authority
OrgId: IANA
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US
RegDate:
Updated: 2004-02-24
Ref: http://whois.arin.net/rest/org/IANA
The other remaining reserved blocks that are routable should be 102, 103, 104, 106 and 179.
We are close to this event, but to my knowledge it has not yet happened.
Quote ARIN: "When the IANA IPv4 free pool has only five /8 blocks remaining, they will be simultaneously distributed to the five RIRs in accordance with global policy. This means that only two blocks remain to be handed out under the normal distribution method." (From: https://www.arin.net/announcements/2010/20101130.html which is dated a few months, but I believe this policy still stands...)
We just got a new block out of ARIN. The first thing we got in response to our net-isp was this:
"Your template indicates a projected need for additional IPv4 addresses in 12 months. The IANA IPv4 free pool is projected to be depleted sometime by January 2011. As a result, ARIN cannot assure you that additional IPv4 addresses will be available at that time. This will not affect your current IPv4 request, but applications and services that require ongoing availability of IP addresses should be migrated to IPv6."
There's a rumor floating around Twitter that APNIC will be requesting two /8's this week or next, which puts us at 5 left. At that point, the remaining 5 get distributed to the 5 RIRs.
At the present time, most IP implementations consider any IP address
in the range 240.0.0.0 through 255.255.255.255 to be invalid as the
source or destination of a datagram. The check for such "illegal"
addresses may occur in many places, including at datagram receipt,
before IP datagram transmission, when an IP address is assigned to a
network interface, or even by router and firewall configuration
parsers.
IIRC the reason we can't use those is many IP stacks deployed today will refuse to even try using the addresses in 240/4. They were for a future version of IP, not for allocation later.
As a hack, it's quite possible someone will try allocating these and ask everyone to patch their systems over the next half a year to a year as things get more critical and the RIRs begin to run out of /24s. (The RIRs all still have enough /24s to last us for months after the IANA pool gets exhausted.)
We shall see. At the moment, there is no plans to use these. We could also arguably try to steal back the multicast ranges since it's so underused. :\
Thanks for the explanation! I ogled the multicast ranges too but I figured that would be even harder than using a chunk that was previously not allocated at all.
I think we'll be seeing a resurgence of NAT but for companies to relinquish their excessive blocks of routable IPS in return for a nice cash bonus from the new owners, a 'market for addreses' so to speak.
We'll see if that is the way things will go, it would to me seem that that is a logical short term solution that does not require force.
Right. For now everything is fine and will be for months and months. The RIRs will start getting more stingy, some amount of reclaiming will be made possible... but at some point market forces are going to start pushing things around and we will either end up on IPv6 or we will end up in a place where having real IP addresses will be a luxury.
I am hoping for the option where the end to end principle is not murdered. We shall see.
In any case, some of the software I'm developing as part of a research project will work even if the Internet becomes a NAT field. I hope we don't have to resort to that.
As for the multicast block... I think some of them haven't been allocated, so if we're going to patch all the systems to make 240/4 usable, we might as well throw in some of the unallocated multicast space...
I'm cynical enough to think we may not see widespread ipv6 (or any alternative to ipv4) for a long time. Why not?
A) The entrenched power players "have theirs"
B) It will cost a lot of money for the big players to upgrade.
C) Instead of spending money, the big players can make money by charging for something that is a scarce resource.
This will be looked at as pure 'market forces' by many and there will be no major push for a long time.
It also requires a heck of a lot of coordination, or so it seems, between major players. Why do so few (none?) retail stores carry ipv6-capable routers? Maybe because so few ISPs support ipv6? Why don't the ISPs support it? Cause no consumers have the hardware for it? Extreme chicken and egg, and the only real downside for the next few years is some orgs are in control of resources that are becoming potentially more valuable by the day. What real incentive do they have to upgrade to ipv6 ASAP?
Not really; they have enough to support 1-2 years of customer growth. After that, they have to do something.
C) Instead of spending money, the big players can make money by charging for something that is a scarce resource.
If you have N million addresses and N+1 million customers, charging more per address (i.e. raising prices) doesn't really help you; all it does is turn away the cheapest customers. I don't think ISPs are eager to try the Oracle business model of squeezing your existing customers harder instead of getting new customers.
Why do so few (none?) retail stores carry ipv6-capable routers?
> Why do so few (none?) retail stores carry ipv6-capable routers? Maybe because so few ISPs support ipv6? Why don't the ISPs support it? Cause no consumers have the hardware for it?
I have a, um, Netgear WNR3500L, which is supposedly available at places like Office Depot and Walmart. It supports several kinds of IPv6, one of which is "6to4 tunnel" and which test-ipv6.com tells me works just fine on my Comcast connection. According to http://www.comcast6.net/ it looks like Comcast will be providing "real" IPv6 sometime this year.
6rd is an improvisation on the motive of 6to4 and ISATAP: you have IPv4 prefix which you use as a carrier for the tunneled traffic, the synthesized IPv6 addresses have a part within them that allows to know which IPv4 within your domain to forward the tunneled traffic to.
If the IPv6 is outside of your 6rd domain - then the tunneled traffic is sent to the border relay, which decapsulates it and sends to the rest of the IPv6 internet.
Should be implementable with the firmware upgrade - assuming the memory allows for IPv6 code altogether - and, that the supplier decides to do the update (as opposed to shipping a new model).
A whole lot of el-cheapo boxes are supported by openwrt:
The IPV4 depletion site, now IPV6 enabled? Did they seriously set up a website warning about the impending doom of IPV4 address allocations initially on IPV4 only?
If that doesn't paint a picture of the sorry state of the IPV6 transition, I don't know what does.
I think you're underestimating the importance of leading by example - assuming of course that the purpose of the website is to do something about the problem.
First, the world continues to turn on its axis (for instance, it is not the case that I am suddenly unable to procure a cheap Slicehost instance with a routable /32). But now there's one less hypoxic argument about the impending death of the Internet if we don't immediately cut over to IPv6.
Second, plenty of companies are holding on to /16s, or multiple /16s, or (contiguously routable) /15s, or (god help us this is apparently true) /8s. Those addresses will urgently begin to pick up a real market value. Fantastic: IPv4 addresses always should have had a monetary value commensurate with their market value, and now some of those vanity allocations will get liquidated.
there are lots of companies with /8's that can't possibly be using all of the addresses. ibm has 9/8, xerox has 13/8, hp has 15/8 and 16/8, apple has 17/8, mit has 18/8, ford has 19/8, csc.com has 20/8, etc.
Regardless of whether or not they are using all of the addresses, they probably find it easier to continue holding onto them for future needs and convenience than to give any of them up for short term gain.
IT Departments hate having to manage these sorts of changes. Imagine all of the firewall rules that might have to be updated if suddenly part of a /8 range was to be considered "external".
i think arin/iana will have to start doing audits and make these companies justify their continued use of their entire /8s or else have to give parts of them back. ip addresses aren't owned, they're just leased from arin and companies have to pay yearly fees of thousands of dollars to keep using them.
arin has gotten pretty strict on giving out additional space to ISPs asking for further allocations due to the pool shortage. once the pool runs dry, the only thing they'll be able to do is break up previous allocations into smaller ones.
these companies with /8s only have them because they were given out in the mid '80s, not because they've ever shown a need for 16 million host addresses.
ip addresses aren't owned, they're just leased from arin and companies have to pay yearly fees of thousands of dollars to keep using them.
The legacy blocks were never owned by ARIN. It is unclear whether they have any right to claim anything over them. IANA may have rights to claim ownership, ARIN definitely does not. ARIN is merely one of five RIRs that ask for addresses from IANA.
Where do you end up, when can you get there, and will the results be worth it?
With major businesses that have their networks disrupted (Halliburton, HP, GE, IBM, Apple, etc), with the router and firewall and server and client and NAT reconfigurations, and a whole pile of administrative repercussions and squabbles from any revocation certain, where the sections of the blocks won't be available until after the businesses are able to clear the subnets, and how long will those recovered IP addresses delay the inevitable?
Wave a magic wand and recall, say, five US DoD /8 blocks back. (Something which will not happen, but we will assume for the moment that US DoD is on the front edge of IPv6 adoption.) How long will those five /8 blocks delay the exhaustion?
And how much of that consolidation effort will detract from rolling out IPv6 and 6to4 tunnels and NAT64 deployment?
Is the cost of all that effort and disruption worth it?
True, but that doesn't necessarily mean that there are large, unoccupied routeable blocks within their allocated ranges that those organizations could easily hand back. More likely, they've got some sparse set of addresses scattered all over the place, reflecting allocations to their subdivisions.
Hey, it's 1992; why not give that research group a /16 if you've got the bits? There's no immediate need, but they might use some fraction of it eventually. And they parcel out /8s to subgroups, a few at a time, averaging out to maybe a dozen machines (some groups with more, some with less). Upshot: in 2011, there's an internal /16 with a few hundred machines on it --- but reallocating it to a smaller CIDR block which reflects actual usage requires negotiations up and down the hierarchy. And this kind of cruft has been piling up all over the place for decades; sorting it out may be hard enough that some of 'em would rather fight than pull the switch.
Sure, but the simple answer is that nothing will work (unless you've painstakingly set up public v6 already, in which case 0.1% of the internet will work)
Yes you can, and it may not be a total disaster if
1. Have actual IPv6 connectivity. Chances are you don't. Teredo might save you in a transition period, but it depends on IPv4 so wont work with your experiment here.
2. You use a very narrow set of services. Currently I'm able to use IPv6 for usenet, google-services, facebook (although buggy with links back to the IPv4 site all over the place), Ubuntu-updates, Freenode and EFNet irc and -one- news-site.
3. And for google's services' to work you need their IPv6-addresses. Chances are you don't have them, because they don't expose them over DNS in public by default.
If this covers all you use the internet for, you should be golden.
If IP6 doesn't save us, then perhaps a policy of forcing ISP's to use RFC1918 addresses and NAT for their subscribers would help. It's ridiculous how many ISP's use dynamically allocated public blocks for their subscribers and then firewall them anyway.
Good luck trying to play Call of Duty or any other peer to peer video game behind a carrier NAT. ISPs are going to love the customer support calls they'll get from people whose xboxes don't work anymore.
It reassures me that there is commodity hardware out there that won't work behind a NAT.
Ten years ago I would have assumed they'd just jump to NAT; back then, setting up cross-network PC games was still mostly the realm of geeks (besides Battlenet-based games).
Something that I wish the "let's just be happy and NAT everyone" crowd would understand is just how different your run of the mill linksys NAT is from a centralized and managed NAT, which we already have to deal with in some places (like some apartment flats).
Among the marginal annoyances that we run into with centralized NAT are
-there is no UPNP IGD. We don't strictly need UPNP, but it's nice when it's there because it's so much more reliable than STUN.
-tenants share mapped port space so there's no guarantee that protocols that require multiple mapped ports will be able to get some number of them (think BitTorrent or 16 player peer to peer video games).
-UDP mappings might expire after some ridiculously short interval, requiring another STUN set-up.
-many of these devices allow admins to set policies for mappings. You can be sure that someone is going to be playing your 16-player game behind a NAT managed by some eager beaver who decided to limit NAT mappings to 14 per flat.
-STUN just might not work very well at all, in which case you're stuck with a special-case connection through a packet repeater.
-Some will even do evil shit like fiddling around with your packet payload. One lesson I learned was not to ever include a player's RFC1597 LAN ip address or any binary data that happens to be the same as their LAN ip address in network packets. There are actually commercial NAT routers that will peer into your packet payloads and change anything that appears to be your LAN ip address to their own WAN address, probably in a an attempt to fix a NAT-broken protocol.
Commercial NAT devices are truly evil. It wouldn't be a stretch to say that the primary 'value-add' for the majority of network library middleware packages in use in the video game industry today is NAT traversal for weird commercial NATs in apartment buildings.
It's worth noting that the date given is an estimated date of IPv4 address exhaustion (which is probably the reason for Officially being in quotes). I would imagine that the recession might have had an impact on how many IPs have been bought within the last couple of years, and it doesn't seem that any of these models take that into account.
My ISP won't do IPv6 without docsis3 cablemodem which are $40+ even if you had a IPv6 router (DD-WRT can if you have a WRT54G model with 32M)
So many end users are very unprepared, unless major ISPs are going to run tunnels.
BTW, little known fact, Windows XP can actually support IPv6 if your equipment can by running this command
netsh interface ipv6 install
Too bad the government can't do what they did during the DTV switchover and pay for consumer equipment upgrades by the offset of selling the freed-up bandwidth.
Can someone provide a second source?
Block 39 still shows up as reserved:
The other remaining reserved blocks that are routable should be 102, 103, 104, 106 and 179.We are close to this event, but to my knowledge it has not yet happened.
Quote ARIN: "When the IANA IPv4 free pool has only five /8 blocks remaining, they will be simultaneously distributed to the five RIRs in accordance with global policy. This means that only two blocks remain to be handed out under the normal distribution method." (From: https://www.arin.net/announcements/2010/20101130.html which is dated a few months, but I believe this policy still stands...)