> On May 28, 2015, at 10:03 AM, Christopher Morrow <morrowc.li...@gmail.com> > wrote: > > On Thu, May 28, 2015 at 11:59 AM, Michael Helmeste <e...@ubertel.net> wrote: >>> -----Original Message----- >>> From: NANOG [mailto:nanog-boun...@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.
