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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 25 September 2017 19:50 UTC

Return-Path: <prvs=1441fc161e=jordi.palet@consulintel.es>
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 3D40A134575 for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 12:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 wLZDp9dxpgPZ for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 12:50:53 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FA7134582 for <v6ops@ietf.org>; Mon, 25 Sep 2017 12:50:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506369051; x=1506973851; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=/ekDvldaDv5QmJ+K9fHsz18OV ndUfCQf1xB48rAKcrg=; b=LPIuQ5bW27kZpAD3M9Rq8Ac6O8OTQcYphgHfbx8Mo zS+X5CzdsWmHSbqug/K1QZ6t8ZRFE40mzfQgaPqOTeN3gxOpS4sgJFaDO8HkyKcT azeemiw92NbbfaTky6vRD3OU5BUz78oolvVmRpUbsfGVGg/sMrC6bVf620R+2sej FI=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=irsX+qy36z29njuJH/tBsM+fblQSlfqbUomSSoTNXfL2sI4l7kFW1Gi9SFAc Vp9Im9IAzfNqq0O8t8noiIX7CfTeqFAGWwkwI8q69+diq6InCa01/b882 M5vku7V64A3SdmL2B0gd5//UItPlhFanzH+Ry2Y5kF5HF+VF1CFJo0=;
X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:50:51 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:50:51 +0200
Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005567578.msg for <v6ops@ietf.org>; Mon, 25 Sep 2017 21:50:50 +0200
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170925:md50005567578::oMQQ2m9/OI4Q2PE6:00003Fgj
X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.26.0.170902
Date: Mon, 25 Sep 2017 21:50:48 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ietf.org list" <v6ops@ietf.org>
Message-ID: <4D460AEB-2B9F-4A99-B64C-10DE5EE5BEF8@consulintel.es>
Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <b0b09e49-ad0a-4693-d4d0-1e398f244b5d@gmail.com> <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> <79925FFC-05F5-473E-8167-EB719E5ACAF8@thehobsons.co.uk>
In-Reply-To: <79925FFC-05F5-473E-8167-EB719E5ACAF8@thehobsons.co.uk>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ChmxOZvIxXba4pe1Ch-JKSPZnkk>
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:50:55 -0000

If I’m correct, this was the reason big cable operators such as Comcast, pushed CableLabs to accept IPv6 for the management network at least in DOCSIS 3.0, as they had already run out of RFC1918 space, so they need to duplicate it across his own network, a big trouble … I think SoftBank run into the same problem, probably just a few really big operators, but a big mess for them.

Regards,
Jordi
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Simon Hobson <linux@thehobsons.co.uk>
Responder a: <linux@thehobsons.co.uk>
Fecha: lunes, 25 de septiembre de 2017, 21:34
Para: "v6ops@ietf.org list" <v6ops@ietf.org>
Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

    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.
    
    
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.