Live data from Hacker News

IPv6 Support for EC2 Instances in Virtual Private Clouds

aws.amazon.com

101–110 of 114 posts

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#101
post #65
post #31

Earlier quoted context omitted.

The opposite pattern is much more convenient: IPv4 on the public endpoint and IPv6-only internally. AWS is now close to supporting this. http://blog.ipspace.net/2014/03/facebook-is-close-to-having-...

Could you explain? How does it help to use IPv6 internally if you're using IPv4 publicly? One of the original motivations for IPv6 was that it would provide enough address space for every device in the world to have its own unique IP address. Then devices could communicate with each other directly, without worrying about intervening NATs. If you're using IPv4 publicly, then you've already lost that advantage. Concern…

  > The 10.0.0.0/8 block provides 16 million addresses
  > and there's also 172.16.0.0/12 and 192.168.0.0/16.
  > There are certainly enough addresses in these ranges
  > that running out is not a concern
With the constraints of subnetting, it is a concern. I know a very large telco that ran out of private IPv4 addresses - and that specific issue was the reason for finally launching a proper IPv6 project.

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#102
post #44

Earlier quoted context omitted.

I don't know enough AWS to understand the announcement, but if your servers and your clients can speak IPv6 and you can skip al the NAT, you don't have to debug NAT problems.

We probably won't ever be rid of NAT. The likes of Cisco, who thrive on making things enterprisey and needlessly complicated will definitely be peddling IPv6 NAT soon, if they aren't already doing it.

IPv6 NAT is generally discouraged and providers can gain huge benefits too from not doing NAT. NAT always implies state which needs to be stored somewhere. The moment you NAT, you very likely won't be able to do the routing in pure hardware any more, so throughput is an issue.

routing v6 directly is completely stateless. It can easily be done completely in hardware possibly not even requiring to store the packet anywhere, nor needing any knowledge of the protocols wrapped inside of the IP packet.

To do NAT, you need to know about TCP and UDP and about the various ports which means you need to look into the IP packet. To route v6, you just look at the IP packet.

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#103

Earlier quoted context omitted.

NAT was created to solve the ip space shortage, which ipv6 doesnt have. There's no point in ipv6 NAT.

Tell that to the people who want NAT for "security".

NAT gives the same amount of security as dropping all SYN packets at the firewall level. The latter just requires much fewer resources to do as it allows for completely stateless operation.

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#104
post #103

Earlier quoted context omitted.

Tell that to the people who want NAT for "security".

NAT gives the same amount of security as dropping all SYN packets at the firewall level. The latter just requires much fewer resources to do as it allows for completely stateless operation.

> NAT gives the same amount of security as dropping all SYN packets at the firewall level

What about UDP packets?

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#105

Earlier quoted context omitted.

The reasons are many. I'll name just a few: * You cannot send UDP packets to your IPv4 customers. * You cannot initiate TCP connections to your IPv4 customers. * You cannot use any application-level protocol that carries information about source or destination IP address. * IPSec more or less goes out the window

But even if my desktop does IPV6.. I am still going to firewall it. Seems like not a "benefit" to throw up my device directly on the internet.

I'm currently in a situation where I've needed to extend access to a wireless network - with two routers (as each has a single radio).

So I have a router that connects to a NATed subnet, which is plugged into another router which provides DHCP to a different private address space for my devices. Granted, in theory all these media hops could've been handled by (more) ethernet level bridging - but if I had simply had native routable ipv6 on my lan, routing through a couple of boxes would've been rather simple - as would exposing ssh or samba on my desktop to the lan or the Internet.

As it is, it's a terrible hack, that sort-of works...

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#106
The state of IPv6 remains sad and depressing. I just switched to centurylink fiber from comcast and I still don't have an IPv6 address. I have the option, but I have to pay for it, which seems totally backwards to me. Sure, I will pay for a static IPv4 address if I need it because I understand that they are few and far between by now. But you can't just give me one v6?

Basically I have a fiber connection in the US, which on it's own is pretty mindblowing, but no IPv6 address...

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#107
post #31

Earlier quoted context omitted.

Most production environments terminate on Cloudfront endpoints (or other CDNs) or ELBs/ALBs; not much need for IPv6 to individual instances (which can use IPv4 internally).

The opposite pattern is much more convenient: IPv4 on the public endpoint and IPv6-only internally. AWS is now close to supporting this. http://blog.ipspace.net/2014/03/facebook-is-close-to-having-...

One reason you would like to go full Ip6 internally may be if your network fit well in a case where you can have only 1 DNS server instead of maintaining 2: 1 for the external IPs plus 1 for the internal IPs. With IP6 you could get rid of the internal DNS server (Which would be simpler for small networks).

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#108
post #58

Earlier quoted context omitted.

Of course you'll keep your firewall. NAT != Firewall Your firewall may start with a simple "deny all incoming SYN packets" rule, but IPv6 gives you the option to open up holes in the firewall to any device or devices on your LAN (port forwarding only works once per port through a NAT). The real benefits probably don't exist yet. There are entire categories of network software that have remained unknown and unexplored…

> Your firewall may start with a simple "deny all incoming SYN packets" rule, but IPv6 gives you the option to open up holes in the firewall to any device or devices on your LAN (port forwarding only works once per port through a NAT). But see.. I can already do that with IPv4 and Nat. Oh I want to run a ftp server on my backend? Open up port 8000 on my firewall and forward to port 21 on my FTP server. I find it weir…

(pilif already covered the main arguments, so I'll keep this short)

> ftp server ... port 8000

Of course there are workarounds. This one requires specifying a non-standard port every time you want to use your server. That may be easy[1] now, but it becomes increasingly problematic the more times you create these workarounds.

The bigger issue is that hosts behind the NAT are not first-class citizens of the internet. They require an imprimatur[2] to publish. If you live in a privileged area that has a static v4 address, this isn't a huge problem. If you live in China behind 3+ layers of NAT, getting a port forwarded to your host isn't going to happen. As NAT becomes more complicated with more layers, even the insane hacks[3] we have to punch holes in NAT (which already require a 3rd party's permission (imprimatur)) start to fail. This will become an increasingly common problem as competition over v4 addresses increases[4].

> Not totally sure what good it will do still though ;)

It will enable the development of new network software that doesn't work over NAT. This type of benefit isn't immediately useful, so think of it as an investment.

It will let more people gain the benefit of being able to publish without needing the permission of a 3rd party. You may not find that important personally, but impartial media access is one of the most important properties of the internet. If we are not vigilant and robust in defense of every peer's right to publish, we will loose it. This isn't a theoretical concern, given how centralized the internet has become in the era of Facebook and Google.

[1] modulo the serious problems that FTP has with NAT that pilif already mentioned

[2] While I don't agree with everything in the essay (some things have changed since 2003), John Walker (co-founder of Autodesk) wrote a very insightful warning about the trend towards requiring an imprimatur to publish: https://www.fourmilab.ch/documents/digital-imprimatur/

[3] http://www.brynosaurus.com/pub/net/p2pnat/

[4] http://www.potaroo.net/tools/ipv4/index.html

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#109
post #95

Earlier quoted context omitted.

We needed IPv6 support five years ago. IPv6 is so vital because without it, we'll see the cost of public IPs skyrocket. I'm surprised it hasn't considering two of the places I worked for in the past few years had trouble purchasing IPs for some of their larger data centre offerings. It's sorta like the network neutrality argument, except you're talking about limits on who can offer services to everyone vs those with…

What product are you building where you can avoid needing public IPv4 addresses considering that the vast majority of the people on the internet still use IPv4? It seems like you'll still need both for many years.

Often you only need one public IPv4 address and thus it doesn't really matter what it costs.

Re: IPv6 Support for EC2 Instances in Virtual Private Clouds

#110
post #96

Earlier quoted context omitted.

Our entire application back end is written in IPv6 only. We don't have an IPv4 version of our product. Until IPv6 was offered, no way for us to host our application on AWS.

Why did you choose to write your backend application using IPv6 APIs only instead of higher abstraction network libraries that support both v4 and v6?

Good question - It's not the APIs that are the issue, it's the actual IPv6 addresses in the packets on the wire that we need. All of our remote devices (typically on the order of 5 million+ for larger customers) have IPv6 addresses. We can use tunnel routers to get the traffic over IPv4 networks to the destination, but the applications themselves are addressing the devices with IPv6 addresses - which means, at least on the network segments that our many applications servers are running on, we need to have IPv6 routing working.

Everything we've done assumes an IPv6 network - trying to squish large device networks into IPv4 is just a losing battle for a huge number of reasons (address mobility, address conflict, large number of downstream devices (20,000+) per network segment, etc...)

Post reply on HN