Re: [v6ops] WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 - multiple prefixes per device

Philip Homburg <pch-v6ops-6@u-1.phicoh.com> Fri, 17 March 2017 10:45 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
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 D1C6012741D for <v6ops@ietfa.amsl.com>; Fri, 17 Mar 2017 03:45:04 -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 p6BBY8leWaVw for <v6ops@ietfa.amsl.com>; Fri, 17 Mar 2017 03:45:02 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF4C1241FC for <v6ops@ietf.org>; Fri, 17 Mar 2017 03:45:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1copNR-0000GrC; Fri, 17 Mar 2017 11:44:57 +0100
Message-Id: <m1copNR-0000GrC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-6@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
References: <BLUPR0501MB2051704E825BCA03EEB09D79AE240@BLUPR0501MB2051.namprd05.prod.outlook.com> <c8c0f5be-28bb-ba31-16da-7fc7e3fccec0@gmail.com> <20170316082639.GF2367@Space.Net> <29F9E911-E637-456D-A930-3316FFD93C41@jisc.ac.uk> <27AE6A05-C742-44BF-98E8-BFCEC72316F2@employees.org> <EF0F4950-F238-4001-BA74-D9440524BEFA@gmail.com> <634a6a12-4d82-da33-6d1d-baae2e5b2891@gmail.com> <13DA8077-91C1-4B3F-9D67-3727F546D202@employees.org> <13194a4f-aeda-63b0-0293-6bc738b068f2@gmail.com> <4D60B43B-24F9-4701-800E-13CF32CD4769@employees.org> <8fc7f3e7-7155-f184-c028-a9f6da7e97db@gmail.com> <D32A31B3-8DB3-444D-B320-B68830A8C4AB@employees.org>
In-reply-to: Your message of "Thu, 16 Mar 2017 18:38:32 +0100 ." <D32A31B3-8DB3-444D-B320-B68830A8C4AB@employees.org>
Date: Fri, 17 Mar 2017 11:44:52 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/CPfheX1dgzkU_3UMUY4J6Fm5UHU>
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-unique-ipv6-prefix-per-host-02 - multiple prefixes per device
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: Fri, 17 Mar 2017 10:45:05 -0000

>Indeed. I just don't think that's realistic to expect.
>The implementation has to accommodate the smallest common denominator. =
>At at the local coffee shop or at your favourite Enterprise you would be =
>very lucky if you got more than a /64 assigned to the host. Enterprises =
>often don't like you to extend their network, nor do the coffee shop =
>want to run multiple provisioning protocols.

Assuming that homenet takes of, then we can assume the local coffee shop
to be a homenet.

Small companies probably just a get consumer internet connection, set up 
a consumer CPE and that's it.

So if we make sure that what we want works in a homenet environment, then it is
likely going to work in losts of other contexts as well.

For the enterprise, some organisations seems to be set on making sure that
nobody can do any useful work. Obviously, it will be hard to make standard
for that type of environment.

Assuming the enterprise wants to support a 'desk area network' then
one way forward is to recognize each desk network as a separate homenet.
That's relatively easy to spec.

On other hand, I can see a desire to have the enterprise network
infrastructure be in control, with end user devices providing local
connectivity. In that case probably all devices with routing functionality
would have to be DHCP relay agents (or something similar) to allow central
infrastructure to see what is going on.