Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

David Farmer <farmer@umn.edu> Mon, 07 August 2017 16:21 UTC

Return-Path: <farmer@umn.edu>
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 B8BD51321DC for <v6ops@ietfa.amsl.com>; Mon, 7 Aug 2017 09:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level:
X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 RMiIIzltSMDA for <v6ops@ietfa.amsl.com>; Mon, 7 Aug 2017 09:21:42 -0700 (PDT)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 66004132035 for <v6ops@ietf.org>; Mon, 7 Aug 2017 09:21:30 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id B018469E for <v6ops@ietf.org>; Mon, 7 Aug 2017 16:21:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATeSQX3mJbTf for <v6ops@ietf.org>; Mon, 7 Aug 2017 11:21:29 -0500 (CDT)
Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 6C20453F for <v6ops@ietf.org>; Mon, 7 Aug 2017 11:21:29 -0500 (CDT)
Received: by mail-ua0-f197.google.com with SMTP id h2so2916661uaf.5 for <v6ops@ietf.org>; Mon, 07 Aug 2017 09:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dk7+dnv4eMPavzkherClnEKzdIH3qsGQSLUg1jGhRqU=; b=p/G7SWHA9iqzsID+BNraoLXOHyDmLnDTmZpjFl3zOou3FSr+sht8D6sHMYeEYwv/5V OdhVG7JgSHIT0TVoSUSNDsZch37byNOBS3tr/owq9vTKK6p95HUV+wDsIQ6M661XmHV2 gVsCEWGPMrJhXslvVmBNUsrnURxTHZPOrYahr0szGyeqGGuavRc8cv1zZhV89DyH8ajm QkzdRLeMw5Mt/E2sCP/ddBb0vUxZVB0R09Lrs1fMTVDFQR5F9o+0JD2VXKsI9VePsdne sgEqO+lO3jummNjvQCMHqDaOqty+YkmwzJr4KBc4tKv3C4rrZSIbFOQWDaQBMsUroUqy kgtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dk7+dnv4eMPavzkherClnEKzdIH3qsGQSLUg1jGhRqU=; b=GeSHPTre90VonHgJEBVJEnouesc0CgNzU5kuX0YEDuZRmTy+TyXk8eLEMsOxRk61qV DZ2OQKnHVO5IIIesWuHe8emRNJecSiDmCFlEKqqO6IeYFxhHZmWVlHCmACjP+Vctuu+4 YboeH8vIF4MDvQqncXyMWqfy57KH7BpHOzcD0Jy8XrlqSrhLl8iNQFwSmjX5K0Q/SfIw Di+1pviBgcYsSK0EmBlNTxc2Vr+oV2MkKV96vzhX0f9Kwc4/10cEwhJ6c4qwwmDCNZPO fcG4J/m+OLpfldlnJCQm+0ucoHsAgSnJtDelHSv6RZcfXWF0XMeLdxvEs1Mox6MlCl2v 1s5Q==
X-Gm-Message-State: AHYfb5jCi+khsHhQt4DiBnL9XuQCON+XP94Y7v0T7Ed/N4sUv2+qbuo/ +bA6zV+m0utD446S+ZrDzFZ9fuZ3msS7PK+1+cVUru3E0AdyzUYFuCZjZoQQ0vqm/6/7Li61YUm 2Kov972QCtoBCXJOY
X-Received: by 10.31.2.67 with SMTP id 64mr637035vkc.7.1502122888866; Mon, 07 Aug 2017 09:21:28 -0700 (PDT)
X-Received: by 10.31.2.67 with SMTP id 64mr637024vkc.7.1502122888649; Mon, 07 Aug 2017 09:21:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.72.221 with HTTP; Mon, 7 Aug 2017 09:21:27 -0700 (PDT)
In-Reply-To: <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk>
References: <150148445751.17707.15424999122129322815@ietfa.amsl.com> <E6AC9174-3D6E-4FAD-B84B-B7E58FB149BC@gmail.com> <CAO42Z2xEs6RauD6Oo_NbqOh+FRVAu3NuveewSvRx7g1hS2-ToQ@mail.gmail.com> <94BC4E17-D490-4F50-9E99-2AAA081CD43C@gmail.com> <CAO42Z2zR_bWPqOHM7-RNsPX78np45UV=J67YD5gbpoCPUaLkAQ@mail.gmail.com> <FB14455C-F00E-49A4-936F-03BD44C4D42C@gmail.com> <CAO42Z2zLgw3cYapf=1y9pm4cWMZZ32DT2ryfPb6BGUFjCfmrMg@mail.gmail.com> <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.uk> <CAO42Z2wJBCo1yjguWSy-jzSvndeZTPgtN71FfdEhvqrVAUhZUA@mail.gmail.com> <9bd9f886-f53b-109f-d998-1d4c7adaf3b1@gmail.com> <B6A257C9-7E8A-452D-9C0F-0B10A31990CB@thehobsons.co.uk> <796A0ED0-0F58-43FA-9F81-D4D736A35F3B@steffann.nl> <BD3B4153-2EEF-4BFB-832D-D126A75AEC11@thehobsons.co.uk> <CAN-Dau2jzbQPuE5diEz-XzfRBHY=O1znE8hfy8P-Eee=MVwC_w@mail.gmail.com> <7C6C4FCC-26B9-493D-9992-4663DE6EB9CE@jisc.ac.uk>
From: David Farmer <farmer@umn.edu>
Date: Mon, 07 Aug 2017 11:21:27 -0500
Message-ID: <CAN-Dau0st9SreXEDpHhJYGbkNfJJa6TNjeqG-XPeg=47Q6ooXw@mail.gmail.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: Simon Hobson <linux@thehobsons.co.uk>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="001a113dc5f42ffdba05562c3dd9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kwbWVCflp4aSL14UncwYGMyVY-k>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
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, 07 Aug 2017 16:21:45 -0000

On Mon, Aug 7, 2017 at 5:05 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> Hi,
>
> > On 7 Aug 2017, at 07:08, David Farmer <farmer@umn.edu> wrote:
> >
> > On the other hand as I have been listening to this discussion, and I've
> become a little concerned that some may think this new model of a /64 per
> host should replace or obsolete the more traditional subnet model of
> multiple hosts within a subnet for any and all use cases. However, it
> should be noted that the primary use case for this model is public internet
> access, or public WiFi. There are several arguments that the traditional
> subnet model has always been a bad fit for this use case, in that you end
> up mixing totally unrelated users and hosts on the same subnet, there are
> several security and privacy issues with that. This isn't necessarily true
> of other use cases.
> >
> > So, the /64 prefix per host model solves some important problems for
> this, and maybe other use cases too. But, that doesn't mean it should be
> viewed as a universal replacement for the traditional multiple host per
> subnet model for all use cases we have. There are plenty of use cases left
> where traditional multiple host per subnet model still works just fine.
>
> The question though, as and as you say it’s not one really in the IETF’s
> scope, more the RIR communities, is if a site has a /48, and uses it up (or
> 16,384 /64s of it up) implementing draft-ietf-v6ops-unique-ipv6-prefix-per-host,
> will that be deemed appropriate use to allow a further assignment?
>
> A large university may choose to implement this on its wifi/eduroam, for
> example.
>

I don't think dedicating a /48 or even a few /48s for wifi/eduroam at a
large University would be a waste of address space.  I'll use our network
here at UMN Twin Cites as an example, we have almost 65,000 staff,
students, and faculty, with many thousands of visitors on a daily basis,
and many people have multiple devices.

We had almost 80,000 unique devices on WiFi for first day of classes last
year, Fall of 2016, across the the whole day, but only somewhere around
20,000 to 30,0000 devices at any moment. We expect that to be more like
100,000 first day of classes this year, in about a month. So a couple /48s
seems like more than enough, maybe growing to 3 or 4 over the next few
years.  However, reuse of addresses as users come and go creates additional
privacy for individual users, so we don't want too large of a pool either.
Maybe forcing the use of a new prefix overnight for devices that are
continuously on campus.  We currently use a few dozen /64 subnets for WiFi,
and we have some issues with ND scaling in our environment. So we are
eagerly awaiting our WiFi gear and routers supporting this model.

I think we need to be careful, and keep an eye on this over the next few
years, but I think there is still plenty of IPv6 address space available in
2000::/3. This shouldn't be used as excuse to totally eliminate traditional
multiple host per subnet model, but I don't see it as an excuse to
eliminate /64 subnet model either.

Thanks.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================