That's sort of what I meant to say. I did not articulate it well. The problem *with* AWS is that in VPC (or different regions), the internal network space is unique to each region. So, in theory, I could get 10.1.2.3 in two regions on two instances. In VPC, you can also designate your own subnets, which makes things a little more tough a la interconnecting the disparate regions.
But, as you say, IPv6 would be an elegant solution to that problem...and that's what I meant to articulate. IPv6 as a region unification tool as well as an Internet-facing protocol. On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen <[email protected]> wrote: > Shouldn't it be the other way around? Ipv6 as the unique universal > external network and you can define your own IPv4 within your cloud context > separate from the cloud provider network and from other customers. So if > you have contexts in different region - you can interconnect using layer 3 > or layer 2 - through the cloud provider network...bring your own IPv4. If > you need internet access, you'll get NATted. If you need connections to > your branches/HQs...etc, build your own tunnel or use the cloud provider - > which by the way gives you your own vrf so no need to worry about > overlapping anything. > Noone heard of Dimension Data Cloud? :) > > On Tue, Feb 24, 2015 at 1:10 PM, Blair Trosper <[email protected]> > wrote: > >> ADDENDUM: They're taking into consideration my suggestion of using IPv6 >> as >> a "universal" internal network so that the different regions could be >> interconnected without having to give up the region-independent use of >> 10.0.0.0/8, which I think would be an elegant solution. >> >> On Tue, Feb 24, 2015 at 12:08 PM, Blair Trosper <[email protected]> >> 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. >> > >> > 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. >> > >> > On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong <[email protected]> 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 <[email protected]> wrote: >> >> > >> >> > On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <[email protected]> >> >> 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 >> >> >> >> >> > >> > >
