I personally find it amusing that companies try to have it both ways. "We are huge, you should use us instead of $LITTLE_GUY because our resources & scale make us better able to handle things. Oh, what, you want IPv6? We're too big to do that quickly...."
But hey, I would try the same thing in their position. -- TTFN, patrick > On Feb 24, 2015, at 13:15 , Ca By <cb.li...@gmail.com> wrote: > > On Tue, Feb 24, 2015 at 10:08 AM, Blair Trosper <blair.tros...@gmail.com> > wrote: > >> I have an unimpeachable source at AWS that assures me they're working hard >> to deploy IPv6. As it was explained to me, since AWS was sort of first to >> the table -- well before IPv6 "popped", they had designed everything on the >> v4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic, which >> they're phasing out. >> >> But I'm assured they're rushing IPv6 deployment of CloudFront and other >> services as fast as they can. I'm assured of this. >> >> > talk is cheap. I suggest people use Cloudflare or Akamai for proper IPv6 > CDN reach to major IPv6 eyeball networks at AT&T, Verizon, Comcast, and > T-Mobile US -- all of which have major ipv6 deployments > > http://www.worldipv6launch.org/measurements/ > > > > >> But you also have to appreciate the hassle of retrofitting a cloud >> platform of that scale, so I do not envy the task that AWS is undertaking. >> >> > work is hard > > >> On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong <o...@delong.com> wrote: >> >>> Amazon is not the only public cloud. >>> >>> There are several public clouds that can support IPv6 directly. >>> >>> I have done some work for and believe these guys do a good job: >>> >>> Host Virtual (vr.org <http://vr.org/>) >>> >>> >>> In no particular order and I have no relationship with or loyalty or >>> benefit associated with any of them. I neither endorse, nor decry any of >>> the following: >>> >>> Linode >>> SoftLayer >>> RackSpace >>> >>> There are others that I am not recalling off the top of my head. >>> >>> Owen >>> >>>> On Feb 23, 2015, at 07:52 , Ca By <cb.li...@gmail.com> wrote: >>>> >>>> On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <ekgerm...@cctec.com> >>> wrote: >>>> >>>>> Currently engaged on a project where they’re building out a VPC >>>>> infrastructure for hosted applications. >>>>> >>>>> Users access apps in the VPC, not the other direction. >>>>> >>>>> The issue I'm trying to get around is the customers who need to connect >>>>> have multiple overlapping RFC1918 space (including overlapping what was >>>>> proposed for the VPC networks). Finding a hole that is big enough and >>> not >>>>> in use by someone else is nearly impossible AND the customers could go >>>>> through mergers which make them renumber even more in to overlapping >>> 1918 >>>>> space. >>>>> >>>>> Initially, I was looking at doing something like (example IP’s): >>>>> >>>>> >>>>> Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC >>> <——> >>>>> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) >>>>> >>>>> Classic overlapping subnets on both ends with allocations out of >>>>> 100.64.0.0/10 to NAT in both directions. Each sees the other end in >>>>> 100.64 space, but the mappings can get tricky and hard to keep track of >>>>> (especially if you’re not a network engineer). >>>>> >>>>> >>>>> In spitballing, the boat hasn’t sailed too far to say “Why not use >>>>> 100.64/10 in the VPC?” >>>>> >>>>> Then, the customer would be allocated a /28 or larger (depending on >>> needs) >>>>> to NAT on their side and NAT it once. After that, no more NAT for the >>> VPC >>>>> and it boils down to firewall rules. Their device needs to NAT >>> outbound >>>>> before it fires it down the tunnel which pfSense and ASA’s appear to be >>>>> able to do. >>>>> >>>>> I prototyped this up over the weekend with multiple VPC’s in multiple >>>>> regions and it “appears” to work fine. >>>>> >>>>> From the operator community, what are the downsides? >>>>> >>>>> Customers are businesses on dedicated business services vs. consumer >>> cable >>>>> modems (although there are a few on business class cable). Others are >>> on >>>>> MPLS and I’m hashing that out. >>>>> >>>>> The only one I can see is if the customer has a service provider with >>>>> their external interface in 100.64 space. However, this approach would >>>>> have a more specific in that space so it should fire it down the >>> tunnel for >>>>> their allocated customer block (/28) vs. their external side. >>>>> >>>>> Thoughts and thanks in advance. >>>>> >>>>> Eric >>>>> >>>> >>>> Wouldn't it be nice if Amazon supported IPv6 in VPC? >>>> >>>> I have disqualified several projects from using the "public cloud" and >>> put >>>> them in the on-premise "private cloud" because Amazon is missing this >>> key >>>> scaling feature -- ipv6. It is odd that Amazon, a company with scale >>>> deeply in its DNA, fails so hard on IPv6. I guess they have a lot of >>>> brittle technical debt they can't upgrade. >>>> >>>> I suggest you go with private cloud if possible. >>>> >>>> Or, you can double NAT non-unique IPv4 space. >>>> >>>> Regarding 100.64.0.0/10, despite what the RFCs may say, this space is >>> just >>>> an augment of RFC1918 and i have already deployed it as such. >>>> >>>> CB >>> >>> >>
