Hacker News Reader

Comment by fidget | Hacker News Reader

8 IPs per instance, max :/

Might be a dumb question, but why would you want or need more than one IP address for an instance? It's not like more addresses will let you download/upload things faster. Maybe if you want to run multiple web servers on port 80 and give each one a different IP address, but how often do people do that, especially more than 8 times over?

Picture running something like Docker on a box, where each container gets its own IPv6 address—with services on their proper ports—instead of mashing a bunch of NATed ports together under the host's IP.

Or, moreover (and this is a bit of a pipe-dream, but it's something I've been hacking on to make possible) picture running something like an Erlang node on a box, where each Erlang process gets its own IPv6 address, fully Internet-routable. This effectively makes Erlang into an SDN vswitch for ephemeral, featherweight virtual machines (which would be oddly similar to AWS's just-announced "Lambda@Edge".)

You'd more likely want them for outbound connections. On modern OSes, the IPv6 stack periodically calculates a new IP (see https://tools.ietf.org/html/rfc4941). Think of it as a kind of one-time-use address, so remote machines can't say "hey, I got a download request from this IP last week. I should try to hack it today!"

When you're running services in containers on the machine and want to have them be directly networkable without another overlay network.

Containers. IP per container.

Quantity changes the quality here. IPv6 address space being so large, we can afford to give everyone a virtually infinite number of addresses. Which in turn enables everything to be globally routable. I never cared about IPv6 much. Once I grasped it I am actually so so excited about it.

This honestly doesn't surprise me. Adding an infinite number of IPs is one way bot writers get around rate limits. I've done it before when I worked for a company that made a facebook/myspace/etc crawler.

Out of curiosity, why does Amazon consider it their responsibility to prevent that? I'm personally glad that they do, but bots use resources, which is good for Amazon (money in their pocket), and as far as I know Amazon doesn't have anything it wants to protect from bots (at least, anything that would be heavily limited by IP).

Well, one explanation might be the reputation of their IP ranges. Already, payment processors and some mail servers will give extra scrutiny to IP ranges belonging to AWS. If AWS is made attractive to that audience and damage is done to the reputation (in various systems) of those IP ranges, their offering becomes less compelling to all customer demographics.

From a rational self-interest standpoint, bots tend to get their IP addresses blocked by whoever they're targeting. Which means the Amazon IP address space gets on threat lists and block lists. The bot owners can just generate new instances with new IP addresses, and then some legitimate customer spins up an instance and gets their address, and wind up on blocked. The bots keep going until various services decide to just block all of Amazon's space, the same way they would for Tor exit nodes or other things associated with shady activity.

As a good netizen, you want to ensure that other providers don't blackhole your IP blocks (which they will if you allow abuse to be emitted from said IP blocks).

In addition to the answers other people have given about not wanting AWS IP space blacklisted, people who are intending to do use services for nefarious purposes have a nasty habit of paying for them using stolen credit cards.

Per IP rate limiting with IPv6 is a futile gesture against any attacker more sophisticated than a kid in his parent's basement. It doesn't take much effort to get a /48 while most ISPs are handing out /64s to their customers. This leaves rate limiters in a catch 22: Are all those requests coming from a given /48 a single attacker, or a bunch of Comcast users? It's impossible to tell without maintaining a table of what the "end user" allocation size is for a particular IP range, which would be a massive, never-ending task.

Infinite IP addresses aren't the same as infinite routable IP addresses. EC2 VPCs use private subnets, and instances created in VPCs don't have routable IP addresses unless you add them. It would be reasonable for AWS to allow infinite VPC subnet addresses to be attached to an instance, but only one or two public addresses.

Reply on news.ycombinator.com