nanog mailing list archives
Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
From: Gino O'Donnell <g () 1337 io>
Date: Tue, 24 Feb 2015 14:02:23 -0800
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html On 2/24/15 10:59 AM, Blair Trosper wrote:
In VPC, you can also designate your own subnets, which makes things a little more tough a la interconnecting the disparate regions. On Tue, Feb 24, 2015 at 12:27 PM, Luan Nguyen <lnguyen () opsource net> 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 <blair.trosper () gmail com> 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 <blair.trosper () gmail com> wrote:I have an unimpeachable source at AWS that assures me they're workinghardto deploy IPv6. As it was explained to me, since AWS was sort of firsttothe table -- well before IPv6 "popped", they had designed everything onthev4 only. Granted, you can get an IPv6 ELB, but only in EC2 classic,whichthey'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 isundertaking.On Tue, Feb 24, 2015 at 11:35 AM, Owen DeLong <owen () 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 anyofthe following: Linode SoftLayer RackSpace There are others that I am not recalling off the top of my head. OwenOn Feb 23, 2015, at 07:52 , Ca By <cb.list6 () gmail com> wrote: On Mon, Feb 23, 2015 at 7:02 AM, Eric Germann <ekgermann () 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 toconnecthave multiple overlapping RFC1918 space (including overlapping whatwasproposed for the VPC networks). Finding a hole that is big enoughandnotin use by someone else is nearly impossible AND the customers couldgothrough mergers which make them renumber even more in to overlapping1918space. 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 toDC<——>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 endin100.64 space, but the mappings can get tricky and hard to keeptrack 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 onneeds)to NAT on their side and NAT it once. After that, no more NAT fortheVPCand it boils down to firewall rules. Their device needs to NAToutboundbefore it fires it down the tunnel which pfSense and ASA’s appearto beable to do. I prototyped this up over the weekend with multiple VPC’s inmultipleregions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumercablemodems (although there are a few on business class cable). OthersareonMPLS and I’m hashing that out. The only one I can see is if the customer has a service providerwiththeir external interface in 100.64 space. However, this approachwouldhave a more specific in that space so it should fire it down thetunnel fortheir allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. EricWouldn't it be nice if Amazon supported IPv6 in VPC? I have disqualified several projects from using the "public cloud"andputthem in the on-premise "private cloud" because Amazon is missingthiskeyscaling feature -- ipv6. It is odd that Amazon, a company withscaledeeply 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 spaceisjustan augment of RFC1918 and i have already deployed it as such. CB
-- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Current thread:
- Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Eric Germann (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Ca By (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Luan Nguyen (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Owen DeLong (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Blair Trosper (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Blair Trosper (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Luan Nguyen (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Blair Trosper (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Gino O'Donnell (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Ca By (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Ca By (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Patrick W. Gilmore (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Benson Schliesser (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Owen DeLong (Feb 24)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Blair Trosper (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Eric Germann (Feb 23)
- Re: Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment Randy Bush (Feb 23)