Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I find it interesting that this didn't make into the keynote. Is the actual interest really low?


I went to one of the first IPv6 sessions at re:Invent this morning. The room was for maybe, 300-400 people? There were 40 or so people in it. So, yes, the interest is low.

That said, I think it's a great signal to the industry, and I'm excited to try to use IPv6!


> The room was for maybe, 300-400 people? There were 40 or so people in it. So, yes, the interest is low.

I think everyone who needs IPv6 is just not using AWS (anymore).


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


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.

Concerning private networks, IPv4 offers more than enough address space within its private ranges for your private network. 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, so it does not seem that IPv6 would provide a benefit when applied specifically and only to private networks.


It frees you from expensive complexities arising from tunneling and private address space. You don't need the network engineering and service costs to bring your private 10.x overlay network to your various datacenters[1] behind different ISPs, you don't have to fight with addressing conflicts when talking to other people using rfc1918 space or debug situations where 1918 addresses are ambiguous, etc. It's cheaper, safer and simpler to integrate with other organizations because you only have to configure your firewall rule instead of trying to mash together incompatible rfc1918 internal networks and overlay technologies in addition to the fw. Your security posture is better and cheaper to maintain because your simpler network is easier to reason about.

[1] meaning your network locations, not your private datacenter (necessarily)


> Could you explain? How does it help to use IPv6 internally if you're using IPv4 publicly?

See this presentation about IPv6 at Facebook: https://www.facebook.com/groups/2234775539/10152303014725540...

> IPv4 offers more than enough address space within its private ranges for your private network

While theoretically true from a raw numbers standpoint, it breaks down at Facebook's scale when you have many gigantic data centers all over the world and start thinking about how you assign the addresses and manage the network that uses them.

As the presentation says, there was lots of wastage due to racks being /24 and clusters being /n (where n < 24).


Assuming you want to provide IPv4 and IPv6 to the outside:

You can relatively easily map IPv4 addresses into IPv6 range: just pick a /96 prefix and append the 32 bit IPv6 address. This is a relatively easy translation, that does not require the machine doing the translation to keep state !!! (so you can send traffic to a random one and it can do the right thing, no need to have connections stick to one). It is thus quite easy to make an IPv6-only network deal with IPv4 clients. With decreasing IPv4 usage, your network naturally adapts since it only becomes easier.

The reverse is not easily possible for serving IPv6 clients from an IPv4 network: you can't map IPv6 1:1 to IPv4, so your gateways have to be more like traditional NAT and keep state tables around, which makes operation in general and load-balancing/fail-over in particular harder. The more and more IPv6 clients you have, the more resources you need for the translation. And at some point in the future, you are going to want to switch.

You could alternatively run your entire DC on IPv4 and IPv6 double-stack, but that adds a lot of unnecessary complexity. Your routers now have to keep routing tables for both around, behavior could differ for both, your applications (logging, fraud prevention, ...) have to understand both, ...

If you are in a position where you control everything you run (so you can make sure there aren't any stragglers that require IPv4 because their vendor doesn't care or something like that), the IPv6 model can be attractive. Do the switch and be done with it for the future, limit your dealings with two protocols to the very edge.


At my company, we used to use IPv6 internally and IPv4 publicly for future proofing and easier migration to a all IPv6 environment. Instead of changing the entire infrastructure we just had to change the gateway.


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


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


The biggest advantage I see (which is heavily coloured by the use cases I faced at Heroku on the Add-ons team) is being able to peer many VPCs without gymnastics to avoid IP range clashes and routing issues. I haven't looked at AWS' IVv6 announcement in enough detail to know if it addresses this head on, but I always looked forward to IPv6 as an avenue to making that kind of work much more straight forward.


But if the peering limit is still 50 vpcs - I guess it might help if/when inter-region peering ships


Don't plan on inter-region peering ever shipping. Easy to do in network fabric at a region, not so easy to do across regions (constrained by fiber connectivity).


That's my thinking as well. Surely behind the edge is all implementation and should be hidden?

The only appreciable benefit i can see right now is that everything moves back to be a routable internet, no more NAT / nat scaling issues for EC2's sending large quantities of data directly to the public internet?


VPC ELBs and ALBs don't support ipv6 though. Presumably this is the first step to adding that support, although it's still not available even in the new ipv6 VPCs.


They just announced during the ELB session that ALBs will be supporting full IPv6 also.


The opposite direction is more interesting.

It might be finally possible to reach things floating out there on the internet which have an IPv6 address.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: