Comment by djcapelis | Hacker News Reader

Comment by djcapelis | Hacker News Reader

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

Yeah, most people expect this to happen within the next dozen days or so. The next IANA allocation is expected to be the last.

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.

http://news.ycombinator.com/item?id=2119927 http://twitter.com/#!/steve_evil/status/27646139280924672

How about 240/4, that's 2^28 addresses that are reserved for 'future use', that's still 256M addresses.

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?

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

Note that any "IPv6 ready" router you buy probably does not support DS-Lite or DNS64 and thus will probably stop working in 2012.

Firmware upgrade?

Good luck.

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.

More details are in http://tools.ietf.org/html/rfc5969 if you are interested.

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:

http://wiki.openwrt.org/toh/start

And there exists a 6rd-enabled image:

https://forum.openwrt.org/viewtopic.php?pid=123059

So it is not all that catastrophic, IMO.

A) The entrenched power players "have theirs"

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?

Partly because they outsource the firmware to the lowest bidder and partly because the standard hasn't even been finalized: http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-...

>all it does is turn away the cheapest customers.

which helps you....

http://tools.ietf.org/html/draft-fuller-240space-02

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.

Reply on news.ycombinator.com