Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

Simon Hobson <linux@thehobsons.co.uk> Sat, 10 June 2017 10:15 UTC

Return-Path: <linux@thehobsons.co.uk>
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 D62A91205F1 for <ipv6@ietfa.amsl.com>; Sat, 10 Jun 2017 03:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 XywQ1qU51z6q for <ipv6@ietfa.amsl.com>; Sat, 10 Jun 2017 03:15:23 -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 27BE21201FA for <ipv6@ietf.org>; Sat, 10 Jun 2017 03:15:22 -0700 (PDT)
X-Quarantine-ID: <zaobOFJCyG9I>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <CA[...]
Received: from [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6] (unknown [IPv6:2001:470:1f09:baa:d69a:20ff:fec4:bbf6]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 288191A071 for <ipv6@ietf.org>; Sat, 10 Jun 2017 10:15:11 +0000 (UTC)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <20170609221029.F3F247B70921@rock.dv.isc.org>
Date: Sat, 10 Jun 2017 11:15:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3828155-E165-4AAE-A218-2AA7DBF7700F@thehobsons.co.uk>
References: <CAO42Z2wp72j-yOsR8C=iqS+dX14wLwthAtOTvD5ugj_NQ=NQag@mail.gmail.com> <8be34ef8-557f-652e-0d2f-f1a1e008bffd@gmail.com> <alpine.DEB.2.02.1706050827290.17963@uplift.swm.pp.se> <E2B77C58-B235-49D6-8130-0B41BE55899C@google.com> <CAAedzxrkbywKMmUaZ6-OCunXe1sw=q3+TNz278xZDmdsQm3xaw@mail.gmail.com> <93C6138E-A2EE-4005-8C16-05E2A2DEA661@google.com> <CAKD1Yr3+pHFhCwoL4vbQLDQ3PNGpijci8c7eZM=Gb0oTy9C0XA@mail.gmail.com> <8678F73D-2CCD-4781-9947-8C07182DFAF4@google.com> <EF9AC09C-5262-4DFB-AA4D-AE95EF81293C@gmail.com> <CB328974-E401-4B62-A408-1814183E0010@google.com> <8C792BA9-3FBA-46F3-9CBE-E82E4B93BEFC@google.com> <CAD6AjGSvaAGydOjZ-LYA8=DR2pOjmUrYAGN0kVdC2aKb3jvx_A@mail.gmail.com> <A3E25B71-9EC6-4E1B-91BC-FE36388676CB@google.com> <73A42828-9F55-4B01-9C00-608221B66EA3@gmail.com> <9B812DC3-E06A-4FB6-B071-BF66F96C8E19@thehobsons.co.uk> <20170609011106.22E967B64301@rock.dv.isc.org> <BB84AB04-ABAC-4DEB-B69B-92EA5A904967@thehobsons.co.uk> <20170609125852.29C107B6EB8F@rock.dv.isc.org> <6d1 acd5d-9d45-9e2a-4ac9-5e0cb9787b13@si6networks.com> <E2460C65-6237-424B-BDBC-29378C27F3A0@thehobsons.co.uk> <20170609221029.F3F247B70921@rock.dv.isc.org>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ttsZvikQD__PRErr_KTbX7_m3bQ>
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: Sat, 10 Jun 2017 10:15:26 -0000

Carsten Bormann <cabo@tzi.org> wrote:

> Apple has had these in their “Airport” product line for about a decade.
> (Of course, “average users” aren’t taught about VLAN tags; it “just works™” :-)

Really ?
If you connect an airport to ${random_switch} and ${random_router} then all the VLANs will work without any intervention ? It might work if every piece of kit is from the same manufacturer (ie what Apple would have you do), but in the general case there's a long way to go !


Mark Andrews <marka@isc.org> wrote:

>> Besides, for this to work properly it's going to require VLANs and
>> multiple wireless SSIDs unless you limit the network to the ports on the
>> router. Good luck getting that to work with the average user.
> 
> People can handle multiple SSIDs quite easily.  We have had routers
> shipping with 2 SSIDs for many years now. Usually the second one in
> labeled "Something Guest".

Most chipsets only support 4 SSIDs, a few handle 16. I've never come across one, but I could believe that some enterprise manufacturer might handle more - at a price. That's a loooooong way from exceeding the 256 segments possible with a /56 from your ISP.

And there's the other issue - people will really really hate you if all these SSIDs do materialise. I've already read comments in another list where users in densely populated places (think these high-density apartment blocks with gigabit connectivity we hear about in parts of Asia) where they already struggle to select a WiFi network because the list takes so long to display and scroll down that it refreshes (and resets the scroll) before they can select their network. Now you propose to multiply that by a few hundred ?

>> I can see uses for about 3 or 4 segments - note, segments rather than
>> subnets! You are not clear whether you are talking about multiple
>> segments or a single network with multiple subnets. If it's the latter
>> then it adds almost zero security, if the former than it's beyond the
>> average user to deal with.
> 
> The home user is quite capable of doing multiple segments.  It
> really isn't hard.

I don't think you've dealt with the average home user, you wouldn't say that otherwise. As I;ve said before, there's a reason ISPs use colour coded sockets and cables for their routers - it's so they can say things like "connect the yellow cable to ..." The average home user really is incapable of doing this.

> Have a couple of cars that each do PD requests for a couple of /64s
> each when they arrive home as they connect over WiFi rather than
> using LTE possibly using a distinct WiFi SSID in the garage (another
> /64). The LTE border router in the car becomes a interior router
> when it connects to the WiFi.

And there's no security in that method.
If I have ${random_IoTat_hub}, I don't want (and wouldn't allow) it to connect to anything but it's own isolated segment and then control what traffic it is allowed to send where. If it connects to the users general WiFi then the IoT thing has full access to the rest of what's on that segment and I don't have control of what it can and cannot do on it. So as I read it, you are proposing to build a network system that gives the false appearance of security - and thus is worse that no security at all.
Whether it requests it's own /64 is another matter - it's really not the same as it having an isolated network segment.

> What other equipement will request /64s as it comes into range or
> just request /64s when it connects?  I don't know yet but I do know
> it will happen.  256 subnets is going to look very small when that
> happens.
> 
>>> (you || me || we) != users
>>> 
>>> network_knowledge(users) == NULL
>> 
>> Thanks - you've expressed it better than I would have.
> 
> Actually we are all users.

OK, change that to (you || me || we) != average users. I've dealt with them, really, no-one on this list is anything whatsoever like an average user - and I strongly suspect that some on this list just don't understand what a real average user is like !