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

Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 07 August 2017 10:05 UTC

Return-Path: <tim.chown@jisc.ac.uk>
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 0CBEC132195 for <v6ops@ietfa.amsl.com>; Mon, 7 Aug 2017 03:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 tl1pcwRZBY2p for <v6ops@ietfa.amsl.com>; Mon, 7 Aug 2017 03:05:31 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D121E132018 for <v6ops@ietf.org>; Mon, 7 Aug 2017 03:05:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1502100328; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=L2i5UXcgq/TLGFZ8P7YkArxUoQnKKNapz6P6keGuUh0=; b=b9qnWWVL2r/yEnm4kBY5KGXDd2rizlHqgiGyNvzeHb+ymreUwNvCl1JLPptwo+jsHQkWxPcxAdYeIWX2BioYTsl0aDgEhqV9R9A5FBzH5Jj1cIPOAa5g+eCXrW0/KRrf+Z6lTMfKSxCkmbQQFR0oLEEyUs1FHjVtHPbViIuaVWk=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0241.outbound.protection.outlook.com [213.199.154.241]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-77-0lg_15maNTS1cDquOjT5xg-1; Mon, 07 Aug 2017 11:05:25 +0100
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB388.eurprd07.prod.outlook.com (10.242.111.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Mon, 7 Aug 2017 10:05:23 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::b8a2:fb24:484f:ba3%13]) with mapi id 15.01.1320.018; Mon, 7 Aug 2017 10:05:23 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: David Farmer <farmer@umn.edu>
CC: Simon Hobson <linux@thehobsons.co.uk>, v6ops list <v6ops@ietf.org>
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
Thread-Index: AQHTDdGB+HQZzf+4OUiIy6ehixgf+KJ2mRuAgAARjoCAAME1AIAAOwAAgAAmjACAAJ4ugIAAQiEA
Date: Mon, 07 Aug 2017 10:05:23 +0000
Message-ID: <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>
In-Reply-To: <CAN-Dau2jzbQPuE5diEz-XzfRBHY=O1znE8hfy8P-Eee=MVwC_w@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3273)
x-originating-ip: [212.188.254.49]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB388; 20:rl178h/5dAqkGbvznAkf8r2Q+rsgI6YemeECBkrUPVI5WYpTMYlB9XFPDo0rOOW+ZPPBn8FoL1ACEMy0seqZbjlI67sKaKfntspCPE08CVJXfnV0VE1AhqxAAFeoeHUjfY6/Oh2g4zrj/5+foLFbwbhMp8ajC7w3z2FYZyQIPV4=
x-ms-office365-filtering-correlation-id: a0edb353-909a-496d-b7fc-08d4dd7bd180
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB388;
x-ms-traffictypediagnostic: AM3PR07MB388:
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(8104003914727)(136301948869941);
x-microsoft-antispam-prvs: <AM3PR07MB3885D6143CB045633A5A445D6B50@AM3PR07MB388.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB388; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB388;
x-forefront-prvs: 0392679D18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(24454002)(199003)(377454003)(189002)(3280700002)(189998001)(97736004)(2171002)(230783001)(53936002)(14454004)(6246003)(68736007)(6306002)(6512007)(99286003)(8676002)(54906002)(57306001)(8936002)(2900100001)(36756003)(101416001)(4326008)(25786009)(2950100002)(74482002)(6916009)(2906002)(53546010)(110136004)(3660700001)(38730400002)(6436002)(5250100002)(50226002)(82746002)(83716003)(93886004)(86362001)(6486002)(76176999)(6506006)(42882006)(478600001)(106356001)(72206003)(6116002)(229853002)(305945005)(105586002)(102836003)(33656002)(966005)(50986999)(7736002)(81156014)(3846002)(81166006)(66066001)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB388; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <1E3D83115C7FBE408A82062ADB732BDB@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 10:05:23.0578 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB388
X-MC-Unique: 0lg_15maNTS1cDquOjT5xg-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2yPZ81beyuSx4eqRAXyGRaGGnhc>
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 10:05:34 -0000

Hi,

> On 7 Aug 2017, at 07:08, David Farmer <farmer@umn.edu> wrote:
> 
> On Sun, Aug 6, 2017 at 3:42 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:
> Sander Steffann <sander@steffann.nl> wrote:
> 
> > Most (all?) RIRs allow a /48 per site. I haven't seen ISPs give one /48 to a customer and then divide it over the connections ("sites") that that customer has. It far more convenient for everybody to just give each connection/site a separate /48. And business-ISP really shouldn't give any customer any less.
> 
> What about businesses with multiple sites (or even, just multiple buildings on a large site), connected by leased lines or whatever, and one central internet connection ? It's not that uncommon. Some time ago (different job) I managed a network with 45 sites and only one internet connection - 40 of them were retail outlets, using dial on demand ISDN, and the ONLY networking they had was back to head office for PoS systems. OK, not typical, but as I say, not all that rare either.
> These days it would be mostly done with DSL lines and VPNs - but we'd still not be allowing local use of the internet connection at each store.
> 
> As I've been pointing out - there are comments along the lines of "we must not block future innovation". Yet at the same time there are limitation being hardcoded in that do exactly that. Just think about it, even if the entire /48 is used on one network, then that only gives 16 bits for host selection - with 60+ bits "wasted". While at the same time there are those saying that anything less than 64 bits to pick an address from is inadequate.
> 
> This discussion seem to be rapidly spinning out of the IETF's preview, but it is still important. I think the RIR assignment and allocation policies aren't as stingy as some might think.  Organizations with multiple sites should not be limited to only a /48, in fact /48 is really just the staring point, at least in the ARIN region /44s and /40s are not that difficult to justify for most organizations. 

Two UK universities have a /44 due to their internal organisation.

> ARIN's policy explicitly allows the assignment of a /48 for each site of a multi-site end-user, either by an ISP or directly by ARIN (if one of several qualifications is meet by the end-user), further additional /48s per site can be assigned if 16,384 /64 subnets are used in an single x-large site.  However, the policy is really a ceiling for ISPs, and ISPs are free to assign less if they see fit. Also, it could very well be the case that if an end-user has multiple sites behind a single connection to an ISP, the ISP might not realize the end-user has multiple site unless the end-user requests a block larger than /48. It seems quit logical for an ISP to assume a connection is just one site, unless the customer informs them otherwise.
> 
> ARIN's IPv6 end-user policy;
> https://www.arin.net/policy/nrpm.html#six58
> 
> The follow allow ISPs or LIRs to make IPv6 assignment based on the above end-user policy;
> https://www.arin.net/policy/nrpm.html#six54
>  
> 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.

Tim