Hacker News Reader

Comment by Mythanar | Hacker News Reader

Most of it can't, actually. Rather, using the words in the question in their strict meaning, most of the hardware out there is not on the "public internet", it is behind NAT.

You can argue that behind NAT there is still IPv4 connectivity with public internet, but it is actually closer to proxying (i.e. having some device talk to internet on your behalf) than to routing (i.e. have some device pass your packets on).

Long story short, there is (for a long time already), no IPv4 public internet. There is IPv4 public interconnect between millions of isolated IPv4 islands. And a lot of hacks and shady engineering to make packets traverse from interconnect to islands and back.

View on HN

But if that exists, why should I as someone running on EC2 care if I can use IPv6 natively or have to make use of such proxying/routing?

You individually? There really isn't a reason to. *

However, as a whole, the lack of native IPv6 support in EC2 certainly held back the global deployment cycle. It's the chicken and the egg problem: Without support for servers that use IPv6, there is no reason for last mile providers to implement it in households. With this update, a huge swath of sites will get support, hopefully leading to quicker adoption for end users.

* for most applications. This is certainly trivializing a subset of applications where this could be useful.

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.

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 because it didn't work behind a NAT. There were several projects I wanted to write ~15 years ago that I never even started because it required a real internet connection, not a NAT "party line".

> 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 weird I am making this argument, as I am normally progressive. I push Python3 over Python2, because it is the way of the future. Even though it causes me pain sometime. For some reason, I just do not see the (for me personally) reason to care about ipv6.

Clearly the more backbones that support it, the better. It at least gives us the OPTION to use it later. Not totally sure what good it will do still though ;)

> 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

funny you mention FTP where that is distinctly not true as the application level protocol encodes IP addresses and ports to either (depending on PASV mode) peer to open for the data transfer.

If your server is behind a NAT and the user is using passive mode, it'll tell the client to connect to some internal ip address, so unless the NAT router does deep packet inspection and alters your packet on the go, that won't fly.

Conversely, if you disable passive mode, a NATed client would have the same issue because in that case it would tell the server to connect to some internal IP on the client's side which too won't fly.

Same issue for all other protocols that have IP addresses in their payload. There are very few of them these days for precisely this reason, many early media streaming and VoIP protocols were doing this too.

Also somewhat related: Port forwarding from one public address only gives you the ability to forward to one specific server. What if you want to run two different HTTP servers on your backend? What if you want to run different SMTP servers on your backend.

Now you're again down to needing packet-contents inspection or you need multiple public IPs in the first place plus a more complicated NAT table. With v6, all you need is to open a few ports.

And these were the technical issues.

There's also a political issue: As v4 addresses get more and more scarce, so increases the control entities with addresses get to have over what services they do and to not allow on the network.

Do we want to live in a place where no new service gets to participate in the internet? Where the next Netflix can't launch because none of the providers want to have yet another service competing against their own content business?

In order for the internet to continue to grow, we need an abundance of addresses and the only way to get that is to have wide-spread v6 support. And in order to get there, every single bit counts: Every service that can offer v6 should. Every provider that can offer v6 should. Only this way we can avoid one big cause for a very much locked down internet in the hands of the providers and the old guard.

v6 plays a very important role for both technical and political reasons to the point where we really need to fight the "v4 works fine for me" attitude. Having a v4 address to run a service on is a privilege. Don't argue from a privileged position based on lazyness.

(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

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

In the vast majority of cases, you cannot use proxying/routing to reach an IPv6 address. If you don't have IPv6 yourself, then any attempt to communicate with another IPv6 address simply fails.

It's sort of like asking "Why should I connect to the Internet, if everyone I know already has a telephone?"

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.

You're probably right, but many telecoms have already deployed ipv6 without a bunch of layers of networking hell, and I'm hopeful that they'll just junk all the crazy ipv4 stuff without replicating it in ipv6. It'll be cheaper for them and nobody will notice the difference.

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.

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

What about UDP packets?

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.

Reply on news.ycombinator.com