Live data from Hacker News

So Long Last /8 and Thanks For All the Allocations

labs.ripe.net

141–150 of 201 posts

Re: So Long Last /8 and Thanks For All the Allocations

#141

Earlier quoted context omitted.

Why do they do that? They already have an /8 to themselves -- 10.0.0.0/8. Did they need an additional 16M IP addresses?

There was a time before NAT, where every machine had a publicly routable IP, and things were good. Any machine could talk directly to any port on any other machine (firewall willing). Until one day, IP exhaustion attacked. Thankfully NAT doesn't exist in IPv6, because 2^128 addresses should be enough for everybody.

Technical arguments aside, props for the Avatar: The Last Airbender reference.

Re: So Long Last /8 and Thanks For All the Allocations

#142
post #51
post #34

Earlier quoted context omitted.

Trouble is that NAT solved a huge chunk of the problem. The current setup is not quite painful enough for people to want to fix it. The good is the enemy of the great, as it were.

> not quite painful enough NAT was (and is) destructive and painful that some of us gave up writing network software in the late-90s/early-00s. I personally abandoned several network-focused projects in the early 2000s. The current status quo only seems "not quite painful enough" if you accept that most people cannot use true network software, limited to client-server architecture where party lines [1] communicate wi…

"if you accept..." I mean, isn't that a very reasonable assumption? Do you really disagree with the notion that more than half of global population don't care at all about the ability to "use true network software", wouldn't use it if they could, and, as long as they're not restricted too much, knowingly avoid solutions with more freedom and actually prefer centralized solutions as long as they're even just a bit more convenient? Heck, if we don't listen at what people are claiming and look at their actions, then even in the techie crowd the majority aren't ready to sacrifice minor conveniences to choose decentralized models over a client-server run and entirely controlled by someone else.

Re: So Long Last /8 and Thanks For All the Allocations

#143
post #122

I’d rather these run out even faster so we can just get on with IPv6. Why waste effort on these dying gasps of v4.

Because the 'dying gasps' has a really long tail. My guess that that everyone in this forum will be dead before 25% of the internet is IPv6 only.

There's a huge difference between supporting IPv6 and not supporting IPv4; the latter will take much much longer.

Re: So Long Last /8 and Thanks For All the Allocations

#144
post #38

IPv4 address utilization is incredibly low. For example, consider 44.0.0.0/8 - it's sitting around almost entirely unallocated. UCSD Caida uses it for their network telescope (pretending to use it for amateur radio) and won't give it back. Just look at how dark it is: https://benjojo.co.uk/internet-2018.png (from https://blog.benjojo.co.uk/post/scan-ping-the-internet-hilbe... ) Discussion on r/amateurradio - https://…

They don't have to give it back, of course. If anything, the first organization to have netblocks yanked out from under them should be the US DoD. As I mentioned a few days ago [0]: > There are also large portions of the 13 /8s (218 million IPs!) assigned to the US Department of Defense [5] that you wouldn't need to scan since there are no routes to them at all: the 11.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.…

I bet DoD thinks that they sure were nice to only retain 13 /8s.

Re: So Long Last /8 and Thanks For All the Allocations

#145
post #137
post #38

IPv4 address utilization is incredibly low. For example, consider 44.0.0.0/8 - it's sitting around almost entirely unallocated. UCSD Caida uses it for their network telescope (pretending to use it for amateur radio) and won't give it back. Just look at how dark it is: https://benjojo.co.uk/internet-2018.png (from https://blog.benjojo.co.uk/post/scan-ping-the-internet-hilbe... ) Discussion on r/amateurradio - https://…

As far as I understand the situation, it would be pointless to chase “unused” address ranges and try to claw them back because: 1. It would be technically very difficult, and old equipment is frequently hardcoded. 2. With the rate the allocations are going, you’d get maybe an additional few months or a couple of years out of this enormous effort. After that, all the addresses really would be allocated, and now what d…

Yes this, we were blowing through a /8 every couple months in the past, haven't checked recently but might even be faster now. The parent argument comes up in every one of these threads.

Re: So Long Last /8 and Thanks For All the Allocations

#146
post #138

Earlier quoted context omitted.

There was a time before NAT, where every machine had a publicly routable IP, and things were good. Any machine could talk directly to any port on any other machine (firewall willing). Until one day, IP exhaustion attacked. Thankfully NAT doesn't exist in IPv6, because 2^128 addresses should be enough for everybody.

I don't know if you're being ironic, but NAT64[0] is (sort of unfortunately) an actual existing technology and in use as well. [0] https://en.wikipedia.org/wiki/NAT64

You need NAT whenever you can't change your peers' routing table, for whatever reason.

It's used extensively in IPv4 world for LAN=>WAN connectivity because your only peer (your ISP) won't agree to send all traffic for 192.168.0.0/24 to your home.

Its most popular use case disappearing doesn't make it any less useful for the narrow set of circumstances when it's basically your only option.

Re: So Long Last /8 and Thanks For All the Allocations

#147
post #137

Earlier quoted context omitted.

As far as I understand the situation, it would be pointless to chase “unused” address ranges and try to claw them back because: 1. It would be technically very difficult, and old equipment is frequently hardcoded. 2. With the rate the allocations are going, you’d get maybe an additional few months or a couple of years out of this enormous effort. After that, all the addresses really would be allocated, and now what d…

Yes this, we were blowing through a /8 every couple months in the past, haven't checked recently but might even be faster now. The parent argument comes up in every one of these threads.

This article is about "blowing through" the last available /8, which due to new rules took five and a half years instead of a few months.

Re: So Long Last /8 and Thanks For All the Allocations

#148
post #143
post #122

I’d rather these run out even faster so we can just get on with IPv6. Why waste effort on these dying gasps of v4.

Because the 'dying gasps' has a really long tail. My guess that that everyone in this forum will be dead before 25% of the internet is IPv6 only. There's a huge difference between supporting IPv6 and not supporting IPv4; the latter will take much much longer.

I don’t mean killing IPv4 - I mean all infrastructure and ISPs supporting IPv6 and treating IPv4 as legacy. Like V12 gasoline engines. They exist and are even produced today but the world has pretty much abandoned them.

Re: So Long Last /8 and Thanks For All the Allocations

#149
post #16
post #6

Earlier quoted context omitted.

What are the main issues with IPv6? Edit: I did not mean this as a derogatory question. It's legitimate. I simply posted it under the wrong OP. Calm down people.

IMO retarded greedy ISPs issuing /64 prefixes to customers. Now you aren’t supposed to NAT but you can’t have multiple subnets either.

[deleted]

Re: So Long Last /8 and Thanks For All the Allocations

#150
post #134

Earlier quoted context omitted.

NAT does nothing meaningful securitywise that a firewall cannot achive, and causes a lot of stupid problems.

Particularly notable example of this is that the three ip6tables rules needed to get NAT-like everything out nothing out behavior are exactly the same three rules that you need in v4 iptables for the NAT to have any security effect at all.

Care to share them?

And how is NAT not added security by default? By default it drops everything incoming, no? (I mean, theoretically NAT doesn't, but [almost] every practical implementation situations means that there's no possible automatic internal-external address correspondence, otherwise you wouldn't need the NAT.)

Post reply on HN