AWS Elastic IP architecture

i love that you are always combative, it makes for great tv.

Yeah, if it were LISP, they could probably handle IPv6.

why can't they do v6 with any other encap?

That’s not my point.

sort of seemed like part of your point.

I swear, it really wasn’t.

sweet! :slight_smile:

the encap really doesn't matter at all to the underlying ip protocol
used, or shouldn't... you decide at the entrance to the 'virtual
network' that 'thingy is in virtual-network-5 and encap the packet...
regardless of ip version of the thing you are encapsulating.

Whatever encapsulation or other system they are using, clearly they can’t do IPv6 for some reason because they outright refuse to even offer so much as a verification that IPv6 is on any sort of roadmap or is at all likely to be considered for deployment any time in the foreseeable future.

it's totally possible that they DO LISP and simply disable ipv6 for
some other unspecified reason too, right? Maybe they are just on a
jihad against larger ip numbers? or their keyboards have no colons?

I suppose, but according to statements made by their engineers, it has to do with the “way that they have structured their backend networks to the virtual hosts”.

I’m pretty sure that I’ve ruled the last two out based on discussions I’ve had with their engineers, but you’re right, I was probably a little more glib about it than was 100% accurate.

Bottom line, however, is it doesn’t matter what the reason, they are utterly incapable of doing IPv6 and utterly and completely unrepentant about it.

it is sort of a bummer, they WILL have to do it eventually though
(you'd think)... and 'sooner rather than later' makes a lot of sense
to work out the bugs and problems and 'we should have thoughta
that!'s...not to mention as they sit and grow it becomes more painful
everyday to make the move :frowning:

Amazon doesn't even offer a v4/v6 LoadBalancer service right? (I had
thought they did, but I guess I'm mis-remembering)

So, my point wasn’t that LISP is the only encapsulation that supports IPv6. Indeed, I didn’t even say that. What I said was that their apparent complete inability to do IPv6 makes it unlikely that they are using an IPv6-capable encapsulation system. Thus, it is unlikely they are using LISP. I only referenced LISP because it was specifically mentioned by the poster to whom I was responding.

Please try to avoid putting words in my mouth in the future.

you have so many words there already it's going to be fun fitting more
in if I did try.

LoL

have a swell weekend!

You too.

so far so good! (hoping for a little rain to cool/clean things)

Perhaps if that energy which was spent on raging, instead was spent on
a Google search, then all those words would've been unnecessary.

As it turns out that IPv6 is already available on ELBs since 2011:
https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-security/

ah! I thought I'd remembered this for ~v6day or something similar.
cool! so at least for some LB services you can get v6 entrance
services.

Official documentation:
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses

Netflix is using it already as per their techblog since 2012:
http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html

neat!

Amazon doesn't even offer a v4/v6 LoadBalancer service right? (I had
thought they did, but I guess I'm mis-remembering)

They sort of do, but it’s utterly incompatible with all of their modern capabilities. You have to use some pretty antiquated VM provisioning and such to use it if I understood people correctly.

Owen

Only EC2 classic has dual stack anything. VPC load balancers (and, indeed,
everything about VPC) is IPv4 only.

And EC2 classic is being phased out, so dualstack is sort of dying on AWS.
However, I do have some solid information that they're scrambling to
retrofit, but seeing
as how we know AWS operates internally (compartmentalizing information to
the point of paranoia), I reckon it will be another year or two before we
even see IPv6
support extend to CloudFront (their CDN) endpoints.

Don't hold your breath on seeing v6 inside VPC/EC2 anytime soon...is what I
was told.

Oh, and the only thing dual stack about EC2 Classic was ELBs (elastic load
balancers). Instances had no means of IPv6 communication except via an
ELB. That
is the FULL extent of IPv6 implementation on AWS at present...and most
people do not have EC2 classic.

Perhaps if that energy which was spent on raging, instead was spent on
a Google search, then all those words would've been unnecessary.

As it turns out that IPv6 is already available on ELBs since 2011:
https://aws.amazon.com/blogs/aws/elastic-load-balancing-ipv6-zone-apex-support-additional-security/

See other posts… ELB is being phased out and works only with EC2 and classic. As I said, it does not work with modern Amazon VPC.

Official documentation:
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html#internet-facing-ip-addresses

All well and good and equally irrelevant.

Netflix is using it already as per their techblog since 2012:
http://techblog.netflix.com/2012/07/enabling-support-for-ipv6.html

Yes… This token checkbox effort which doesn’t work unless you are running on old hosts without access to any current storage technologies and face other limitations is available.

My statements stand, as far as I am concerned.

Owen

Congratulations, you've managed to find exactly the same info as Owen
already covered:

"Load balancers in a VPC support IPv4 addresses only."

and

"Load balancers in EC2-Classic support both IPv4 and IPv6 addresses."

- Matt

Congratulations for missing the point Matt, when I sent my email
(which by the way went for moderation) there wasn't a discussion about
Classic vs VPC yet. The discussion was "no ipv6 in AWS" which is not
true as I mentioned in my previous email. I did not state it works
everywhere, but it does work.

In fact as Owen mentioned the following, I assumed he is talking about
Classic because this statement is only true there. In VPC you can
define your own IP subnets and it can overlap with other customers, so
basically everyone can have their own 10.0.0.0/24 for example.
"They are known to be running multiple copies of RFC-1918 in disparate
localities already. In terms of scale, modulo the nightmare that must
make of their management network and the fragility of what happens
when company A in datacenter A wants to talk to company A in
datacenter B and they both have the same 10-NET addresses"

Andras

Point of clarification: AWS customer IP subnets can overlap, but customer VPCs that encompass overlapping subnets cannot peer with each other. In other words, the standard arguments in favor of address uniqueness still apply.

TV

I wasn’t being specific about VPC vs. Classic.

The support for IPv6 in Classic is extremely limited and basically useless for 99+% of applications.

I would argue that there is, therefore, effectively no meaningful support for IPv6 in AWS, period.

What you describe below seems to me that it would only make the situation I described worse, not better in the VPC world.

Owen

Disagree, and so does AWS. IPv6 has a huge utility: being a universal,
inter-region management network (a network that unites traffic between
regions on public and private netblocks). Plus, at least the CDN and ELBs
should be dual-stack, since more and more ISPs are turning on IPv6.

Sigh…

IPv6 has huge utility.

AWS’ implementation of IPv6 is brain-dead and mostly useless for most applications.

I think if you will review my track record over the last 5+ years, you will plainly see that I am fully aware of the utility and need for IPv6.

http://lmgtfy.com?q=owen+delong+ipv6 <http://lmgtfy.com/?q=owen+delong+ipv6>

My network (AS1734) is fully dual-stacked, unlike AWS.

If AWS is so convinced of the utility of IPv6, why do they continue to refuse to do a real implementation that provides IPv6 capabilities to users of their current architecture.

Currently, on AWS, the only IPv6 is via ELB for classic EC2 hosts. You cannot put a native IPv6 address on an AWS virtual server at all (EC2 or VPC). Unless your application is satisfied by running an IPv4-only web server which has an IPv6 VIP proxy in front of it with some extra headers added by the proxy to help you parse out the actual source address of the connection, then your application cannot use IPv6 on AWS.

As such, I stand by my statement that there is effectively no meaningful support for IPv6 in AWS, period.

AWS may disagree and think that ELB for classic EC2 is somehow meaningful, but their lack of other support for any of their modern architectures and the fact that they are in the process of phasing out classic EC2 makes me think that’s a pretty hard case to make.

Owen

Since your network has IPv6, I fail to see the issue.

Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what?

Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future.

Matthew Kaufman

AWS built their network first...before IPv6 "popped", so you can appreciate
the huge task
they have of retrofitting all their products to support it.

I don't envy the task, but they have said publicly and privately that it's
a priority. But it's
also a massive undertaking, and you can't expect them to snap their fingers
and turn it
out over a weekend, man...

The prize of being first cuts both ways when newer technologies at lower
network levels
start taking off and you don't have support built in to something
proprietary.

Would it be great if they had it faster? Obviously yes.
Are they working on it as a priority? Yes.
Can they go any faster? Probably.
Are there other choices for cloud providers that are full dual stack if
this really is a
live or die issue for you? Yes.

Access to dual-stack isn't a fundamental human right. If you don't like
what AWS is doing,
then use someone else who has dualstack.

I don't get the outrage...and it's so irrational, that you've caused me to
actually *defend* AWS.

bt

Since your network has IPv6, I fail to see the issue.

Nobody is anywhere near being able to go single-stack on IPv6, so AWS is just another network your customers will continue to reach over v4. So what?

Sigh… The point is that all of the services and applications being built on and delivered over AWS are stuck in the IPv4 mud until such time as they can get IPv6 from AWS or move to a different cloud provider.

Heck, if v6 support from a cloud hosting company is so important, I see a great business opportunity in your future.

There are already several cloud hosting companies that provide full dual-stack support. I already mentioned several of them earlier in the thread, so this is a rather silly conclusion to draw from the thread as a whole.

Remember where this all started… Someone asked if the internal Amazon structure was using LISP for encapsulation.

I made the semi-sarcastic comment that if they were using LISP, they probably wouldn’t have so much difficulty supporting IPv6, therefore they probably aren’t using LISP.

My statement was taken all sorts of other ways by various people.

Nonetheless, the bottom line remains the same:

AWS can’t do IPv6 outside of a very tiny limited space which provides a solution only for one particular application (pretending to provide IPv6 web services from an IPv4-only web server through a proxy).

People who are building applications and considering hosting their applications in the cloud should seriously consider whether this limitation in AWS matters to them. IMHO, forward-thinking application developers will eschew AWS in favor of clouds that have dual-stack support and build dual-stack capable applications.

YMMV.

Owen

AWS built their network first...before IPv6 "popped", so you can appreciate the huge task
they have of retrofitting all their products to support it.

Sure, and if they said “We have a plan, and it will take X amount of time”, I would respect that.

If they said “We have a plan and we’re not sure how long it will take”, I would continue to poke
them about sooner is better than later and having a target date helps people to plan.

“We don’t think IPv6 matters and we aren’t announcing any plans to get it implemented or any
date by which it will be available”, on the other hand, being what they have actually repeatedly
said to me until very recently, not so much.

Now, they’re saying (essentially) “We think IPv6 might matter, but we aren’t announcing
any plans to get it implemented or any date by which it will be available” . To me, this
is still a problematic situation for their customers.

Especially when you look at the impact it has on the rest of the internet.

Review Lee Howard’s Denver ION presentation about per-user-per-year costs of delivering IPv4
over the next several years and it rapidly becomes clear that the failure of Amazon to make dual
stack available is actually one of the major factors preventing eyeball carriers from being able to
make plans for IPv6 monastic on any reasonable timeframe and a major factor in their CGN
costs.

I don't envy the task, but they have said publicly and privately that it's a priority. But it's
also a massive undertaking, and you can't expect them to snap their fingers and turn it
out over a weekend, man…

They haven’t, really, exactly said that. They’ve sort of hinted that they might be working on it
in some places. They’ve sort-a-kind-a paid it some lip service. They haven’t announced plans,
dates, or any firm commitment in any form.

The prize of being first cuts both ways when newer technologies at lower network levels
start taking off and you don't have support built in to something proprietary.

I started talking to folks at Amazon about this issue more than 5 years ago. At the time, they
told me flat out that it was not a priority. I gave them half a decade to figure out it was a priority
and do something about it while remaining relatively quite about it publicly. At this point, things
have reached a point where the damage that occurs as a result of applications being deployed
on such a dead-end service and the limitations that service imposes on those applications can
no longer be tolerated.

Would it be great if they had it faster? Obviously yes.

Agreed.

Are they working on it as a priority? Yes.

Do you have any evidence to support this claim?

Can they go any faster? Probably.

Isn’t that answer alone a sign that perhaps it isn’t so much of a priority to them?

Are there other choices for cloud providers that are full dual stack if this really is a
live or die issue for you? Yes.

This represents one of the most common fallacies in people’s thinking about IPv6.

Your failure to implement IPv6 doesn’t just impact you and your customers. Especially when you’re
something like AWS. It impacts the customers of your customers and their service providers, too.
If Amazon and Skype were IPv6 capable, you would actually find a relatively significant fraction of
traffic that is likely to get CGN’d today would be delivered over IPv6 instead. That’s a HUGE win
and a HUGE cost savings to lots of eyeball ISPs out there. None of them are likely AWS customers.
None of them are likely to be perceived by AWS as “demand” for IPv6, yet, they are in fact the
source of the majority of the demand.

Access to dual-stack isn't a fundamental human right. If you don't like what AWS is doing,
then use someone else who has dualstack.

Again, you are ignoring the larger consequences of their failure.

You can rest assured that I am not purchasing service from AWS due to their failed policies toward IPv6.

However, that doesn’t fully mitigate the impact to me from those bad decisions. So, in an effort to both further
mitigate those impacts and to help others avoid them, I have started vocally encouraging people to take a
serious look at AWS’ lack of IPv6 and consider alternatives when selecting a cloud hosting provider.

I don't get the outrage...and it's so irrational, that you've caused me to actually *defend* AWS.

I hope I have explained the reasons for my position a bit better so that you no longer feel the need to do so.

I am not outraged by AWS’ actions. They are free to do what they wish. However, I want to make sure that
application developers are aware of the impact this has on their application, should they choose to deploy
it in AWS and I want to encourage current users of AWS to consider IPv6-capable alternatives for the good
of the internet.

Owen

At the risk of feeding the troll...

This isn't just an AWS problem.

"All Compute Engine networks use the IPv4 protocol. Compute Engine
currently does not support IPv6. However, Google is a major advocate of
IPv6 and it is an important future direction."
https://cloud.google.com/compute/docs/networking

"The foundational work to enable IPv6 in the Azure environment is well
underway. However, we are unable to share a date when IPv6 support will be
generally available at this time."

http://azure.microsoft.com/en-us/pricing/faq/

This is only marginally better, as it acknowledges that it's important,
but still has no actual committed timeline and doesn't even reference any
available ELB hacks.

Anyone else want to either name and shame, or highlight cloud providers
that actually *support* IPv6 as an alternative to these so that one might
be able to vote with one's wallet?

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

People who are building applications and considering hosting their applications in the cloud should seriously consider whether this limitation in AWS matters to them.

It doesn't, because everyone "on the Internet" can reach IPv4-hosted services.

IMHO, forward-thinking application developers will eschew AWS in favor of clouds that have dual-stack support and build dual-stack capable applications.

Forward-thinking developers are using big clouds that have the resources to enable IPv6 long before having IPv6 actually matters.

Matthew Kaufman

As I said before:

Host Virtual (vr.org <http://vr.org/>)
Softlayer (softlayer.com <http://softlayer.com/>)
Linode (Linode.com <http://linode.com/>)

All have full dual-stack support.

I’m sure there are others.

Owen

As I said before:

Host Virtual (vr.org <http://vr.org/>)
Softlayer (softlayer.com <http://softlayer.com/>)
Linode (Linode.com <http://linode.com/>)

All have full dual-stack support.

<snip>

At the risk of feeding the troll...

This isn't just an AWS problem.

So... ok. What does it mean, for a customer of a cloud service, to be
ipv6 enabled?
What really matters for a cloud service user? What information could
be surfaced to the cloud providers in order to get the most important
ipv6 'stuff' done 'now'?

o Is it most important to be able to address ever VM you create with
an ipv6 address?

o Is it most important to be able to talk to backend services (perhaps
at your prem) over ipv6?

o Is it most important that administrative interfaces to the VM
systems (either REST/etc interfaces for managing vms or 'ssh'/etc) be
ipv6 reachable?

o Is it most important to be able to terminate ipv6 connections (or
datagrams) on a VM service for the public to use?

I don't see, especially if the vm networking is unique to each
customer, that 'ipv6 address on vm' is hugely important as a
first/important goal. I DO see that landing publicly available
services on an ipv6 endpoint is super helpful.

Would AWS (or any other cloud provider that's not currently up on the
v6 bandwagon) enabling a loadbalanced ipv6 vip for your public service
(perhaps not just http/s services even?) be enough to relieve some of
the pressure on other parties and move the ball forward meaningfully
enough for the cloud providers and their customers?

-chris