Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

Simon Hobson <linux@thehobsons.co.uk> Mon, 25 September 2017 19:34 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFC713457C for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 12:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzHu4iwYpyGa for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 12:34:15 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425A8132125 for <v6ops@ietf.org>; Mon, 25 Sep 2017 12:34:15 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 2BF0E1BC37 for <v6ops@ietf.org>; Mon, 25 Sep 2017 19:34:11 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com>
Date: Mon, 25 Sep 2017 20:34:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <79925FFC-05F5-473E-8167-EB719E5ACAF8@thehobsons.co.uk>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <b0b09e49-ad0a-4693-d4d0-1e398f244b5d@gmail.com> <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com>
To: "v6ops@ietf.org list" <v6ops@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/x3O1RYKduR_Dys_2uw7gRE1e3YI>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2017 19:34:17 -0000

Fred Baker <fredbaker.ietf@gmail.com> wrote:

> Several companies, notably Microsoft and Comcast in the v6ops context, and said that they were running out not only of public space but, within their networks, private space. In the CGN context, this (in part, there were other considerations) resulted in us requesting an additional RFC 1918-like prefix for the space between a presumed NAT'd private address space and a CGN.

While I'd never considered that before now, it makes sense. 10/8 only has 16 million addresses (or, say, 65k /24s), plus another million for 172/12 and another 65k for 192.168/16. Given that (for example) Azure uses a lot of RFC1918 addressing internally, it's not hard to see how they could be running into problems.