Hacker News Reader

Comment by throwaway2048 | Hacker News Reader

throwaway2048

Seems a little absurd that one company just got 1/4th of all remaining ARIN ipv4 adresses when there is such an insane crunch looming, no matter how big and important they are.

View on HN

Exactly! They should not hand out anything bigger than a /16 or so. It's really unfair for the others.

That's just an effect of how the roadmap works. The registries defined about number of points at which the allocation rules became/become stricter. They could have defined more points, ie. smaller and more frequent rule changes, but what would the benefit be, really?

Btw, your math is off. ⅕, not ¼.

I can't wait till subnets are a thing of the past with ipv6.

Most people at this stage are probably happy to push along ipv6 more so.

Don't hold your breath. I think ipv4 will be around for a long time. With NAT, there's really no shortage of numbers for many sites.

Haha, I'm laughing at that statement. You do realize that NATs merely extend the address space by mapping connections to computers with non-public IPs onto a uniquely identifiable port number? So depending on the average number of concurrent connections operated per peer, NATs won't be able to extend the IP4 address space by more than, say 12 bits.

Hahas are on you.

NAT does tuple mapping - src/dst addr/port and protocol. That is - two TCP mappings can use the same local external port even if they go to the same remote address, for as long as they connect to a different remote port.

Shortly after submitting my reply I had a similar thought but after some googling I cannot find any source that this kind of "port sharing" NAT is actually used. Looking at RFC 3022 "Traditional IP Network Address Translator" it looks like usually unique port numbers are allocated per connection. Maybe there are protocol subtitles or security implications that keep implementors from going with "port sharing" NAT?

My argument still stands in case all peers behind a common NAT router try to access the same IPv4 server (which may just happen with centralized services like youtube/facebook/google). It also stands in case UDP based services are used (stuff depending on a Cone NAT and using STUN like VoIP or online gaming).

This is true, but consider that while there are 16 bits of ports on both source and destination, in reality, nearly all traffic flows to a very short list of ports. Most connections, and connections are what matters here, not total traffic, are going to have a port 80 or 443 on one side of the connection or the other. So while I think 12 bits is too low, in practical use, you aren't getting the 32 bits you think you are getting. Considering source port restrictions, I think saying single-level nat extends IPv4 with another 16 bits is not too far off. Of course, that is still a lot of IPs.

Of course, nat has a bunch of other pain in the ass problems, especially in that if I want to be able to track abuse, I've got to log every new connection (flow, whatever) that you make. When I get a complaint, I've got to match that up to my logs, which can be goddamn difficult if the complainer's clock isn't just right.

With static IPs it's way easier to track abuse, and I don't have to actively log what you are doing, just who has what IP when, and because IPs stick around a lot longer than connections, I'm way less vulnerable to clock drift.

You should know that subnets are not a past with IPv6. Unless you meant to say "I can't wait to have one big net for all of my $CORP".

Even then, I wouldn't rule out partitioning your big net - there is enough stupid software and OSes around which happily blabber (ie. broadcast) to the attached subnet. Becomes quite a nuisance when you've got hundreds of Nodes.

Reply on news.ycombinator.com