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

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Wed, 14 June 2017 18:53 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 54FAE129464 for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 11:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CaLHePf5FuOQ for <ipv6@ietfa.amsl.com>; Wed, 14 Jun 2017 11:53:52 -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 9D9E612783A for <ipv6@ietf.org>; Wed, 14 Jun 2017 11:53:52 -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 v5EIrpAh038692; Wed, 14 Jun 2017 11:53:51 -0700
Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v5EIrjx0038670 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 14 Jun 2017 11:53:45 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 11:53:44 -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; Wed, 14 Jun 2017 11:53:44 -0700
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>
Subject: RE: draft-bourbaki-6man-classless-ipv6-00
Thread-Topic: draft-bourbaki-6man-classless-ipv6-00
Thread-Index: AQHS5O3iBqlt++AmEkC1QOEah1pM8KIkiz6AgAADVoCAAAFzAIAAA1KAgAAEk2CAAIZuAP//kAoQ
Date: Wed, 14 Jun 2017 18:53:44 +0000
Message-ID: <1c0deb36b1534ca58ad275b80706c1c1@XCH15-06-11.nw.nos.boeing.com>
References: <E02C4C99-155A-4358-A845-F00F8BB071C1@employees.org> <b3ca5271-21b1-ab33-2dff-82735ebe9128@gmail.com> <235143da452c4ff4aec39a26ba918e7e@XCH15-06-11.nw.nos.boeing.com> <1489a50a-2616-f9ac-4109-16c595e15f90@gmail.com> <FA3032F9-F44B-45B4-9AFF-01EBC84F1448@employees.org> <b1c5c13d-ef69-ef30-546c-9178a2655caf@si6networks.com> <391c730c-fa75-7596-bb6b-383ea6583131@gmail.com> <0b57c999-b5df-8a44-e3fd-55cee628f3f3@si6networks.com> <20170614092327.GB30896@gir.theapt.org> <E61AFFF1-0354-41EE-8E11-50433B26BAF7@employees.org> <20170614094034.GC30896@gir.theapt.org> <A7502902-245B-499B-916B-28630CD5A824@employees.org> <6c4157da7039438981db0f4ba46df916@XCH15-06-11.nw.nos.boeing.com> <EB6160E5-0FB3-427E-BBE0-486A58FD0D82@google.com>
In-Reply-To: <EB6160E5-0FB3-427E-BBE0-486A58FD0D82@google.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/OLm7-lX5Vj-72qPnLmfRvoeny4M>
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: Wed, 14 Jun 2017 18:53:54 -0000

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of james woodyatt

> This category of problem is about connecting *routers* (not hosts)
> to the Internet via RFC 7278.

Or hosts which operate like routers?

> If all you’re connecting at the hotspot are hosts, then why would you
> need more than one subnet?

My smartphone is assigned a single /64. It becomes a WiFi hotspot. So, de minimis, it creates a /65, for its WiFi interface, which any number of local WiFi users can use. Why not allow SLAAC for these WiFi users? And, why should we not allow, trivially, more flexibility? We now have these "whole home WiFi" systems. Why should that smartphone's /64 not be capable of supporting two or three local WiFi hotspots?

Point being, all of this can be done with absolutely no consequences to the service provider, other than potentially some extra traffic volume on that one /64 facing the operator. But only if that 64-bit boundary is not fixed.

> And if you need more than one subnet— for some premium mobile hotspot
> thingie I guess— why not use more than one UE?

Of course you can use multiple phones with /64s, if that's what you're asking?  But not without going hat in hand to the operator.

With IoT, example in cars, or in homes, no one can tell how many different subnets will make sense. If a home router is assigned a /64, it should be able to use that one /64 effectively, without constantly having to ask for more? And SLAAC should be available, for inside the home. Why not? Either that, or for sure, you will see NAT used with IPv6.

Summary: I keep seeing people saying that they don’t want to see NAT used with IPv6. In the next sentence, they say they want a fixed boundary at /64. The only way the two ideas can be compatible is if we have a prefix police that mandates some arbitrary max prefix length to be handed out, by operators, like /48. But operators keep saying no way, and they hand out /64s. Rock, hard place. (And, not to be ignored, then there's the hype of this limitless address space offered by 128-bit addresses, as if it's actually usable.)

Bert