Re: AWS Elastic IP architecture

[Owen DeLong <owen () delong com>]

> On May 28, 2015, at 10:03 AM, Christopher Morrow <morrowc.lists () gmail com> wrote:
>
> On Thu, May 28, 2015 at 11:59 AM, Michael Helmeste <elf () ubertel net> wrote:
> > > -----Original Message-----
> > > From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of Christopher
> > > Morrow
> > > Subject: Re: AWS Elastic IP architecture
> > > [...]
> > > i sort of doesn't matter right? it is PROBABLY some form of encapsulation
> > > (like gre, ip-in-ip, lisp, mpls, vpls, etc) ...
> > > [...]
> >
> > I don't know how the public blocks get to the datacenter (e.g. whether they are using MPLS) but after that I think 
> > it is pretty straightforward. All of the VMs have only one IPv4 address assigned out of 10/8. This doesn't change 
> > when you attach an Elastic IP to them.
>
> right, so they encap somwhere after between 'tubez' and 'vm'. and
> likely have a simple 'swap the ip header' function somewhere before
> the vm as well.

It doesn’t sound like they have to encap/decap anything.

Sounds like the packet comes in, gets NAT’d and then gets routed to the 10/8 address by normal means.

Why do you assume some encap/decap process somewhere in this process?

> > All that is happening is that they have some NAT device somewhere (maybe even just a redundant pair of VMs?) that 
> > has a block of public IPs assigned to it and they
>
> i'd question scalability of that sort of thing... but sure, sounds
> like a reasonable model to think about.

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, the variety of things that are 
inherently broken by NAT or multi-layer NAT, and a few other relatively well-known problems, the biggest scalability 
problem I see in such a solution is the lack of available public IPv4 addresses to give to elastic IP utilization.

However, this is a scale problem shared by the entire IPv4 internet.

The solution is to add IPv6 capabilities to your hosts/software/etc.

Unfortunately, if you build your stuff on AWS, said solution is not possible and Amazon, despite repeated public 
prodding, has not announced any plans, intention, or date for making IPv6 available in a meaningful way to things 
hosted on their infrastructure.

Suggestion:

If you care about scale or about your application being able to function in the future (say more than the next couple 
of years), don’t build it on AWS… Build it somewhere that has IPv6 capabilities such as (in no particular order): 
Linode, Host Virtual[1], SoftLayer, etc.

Owen


[1] Full disclosure: I have no affiliation with any of the companies listed except Host Virtual (vr.org 
<http://vr.org/>). I have done some IPv4 and IPv6 consulting for them. I have no skin in the game promoting any of the 
above organizations, including Host Virtual. To the best of my knowledge, all of the organizations have ethical 
business practices and offer excellent customer service.