RE: draft-bourbaki-6man-classless-ipv6-00

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Fri, 02 June 2017 17:15 UTC

Return-Path: <albert.e.manfredi@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C12126557 for <ipv6@ietfa.amsl.com>; Fri, 2 Jun 2017 10:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.322
X-Spam-Level:
X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 9qzfrmZBdYgM for <ipv6@ietfa.amsl.com>; Fri, 2 Jun 2017 10:15:05 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AED1205F0 for <ipv6@ietf.org>; Fri, 2 Jun 2017 10:15:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v52HF3qG043040; Fri, 2 Jun 2017 10:15:04 -0700
Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v52HEuxM042830 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 2 Jun 2017 10:14:56 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 10:14:55 -0700
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1263.000; Fri, 2 Jun 2017 10:14:55 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: RE: draft-bourbaki-6man-classless-ipv6-00
Thread-Topic: draft-bourbaki-6man-classless-ipv6-00
Thread-Index: AQHS26olAbwdN6IbFk+uhX2pi2Ws/qISErGAgAAFyYCAAAZ9gIAAE+sA//+ZrfA=
Date: Fri, 02 Jun 2017 17:14:55 +0000
Message-ID: <f2260ee557014429a1fef32de040547b@XCH15-06-11.nw.nos.boeing.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <20170602141259.GD30896@gir.theapt.org> <CAKD1Yr0DtQYvCYLQexhXe_nhb5rjeyhnB4bCveqyO5Xbuwdg1A@mail.gmail.com> <20170602145655.msfjw35qhoev4sm2@Vurt.local> <CAKD1Yr3gqFgq3dxFaBEV++q5cgx1AHzFLGRJ50DYJjVE69C7iA@mail.gmail.com>
In-Reply-To: <CAKD1Yr3gqFgq3dxFaBEV++q5cgx1AHzFLGRJ50DYJjVE69C7iA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HuzvTLQvt41SbB-bWNJdkMCOgH8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jun 2017 17:15:06 -0000

>> Would be a shame to throw away lessons learned from IPv4.
>
> I think that's exactly the fallacy here. It is not useful to apply something
> you learned about IPv4 addressing to IPv6, because the number of addresses
> is incomparably bigger. Rule of thumb in software engineering is that a
> solution usually scales by one or two orders of magnitude. Here we have
> something like 34 orders of magnitude. Even a single /64 is 9 orders of
> magnitude larger than the IPv4 Internet.

Yeah, this hype needs to end. A /64 hard boundary merely doubles the width of IPv4 addresses, and egregiously wastes the majority of the remaining 64 bits.  And with innovations such as IoT, suddenly all that vast extra space can be swallowed up. Back in 1980, IPv4 address space seemed pretty huge too. The deployment assumptions made are key, when people make assertions about the vastness of the address space.

> Example: I don't want us to have to deal with NAT any more, ever.

I've seen this comment made before, and yet the /64 hard boundary practically guarantees that NAT will get used with IPv6. It's exactly the same solution, for exactly the same problem. Inability to expand at the edges.

Bert