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

Gert Doering <gert@space.net> Fri, 17 March 2017 10:13 UTC

Return-Path: <gert@space.net>
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 444C2129A76 for <v6ops@ietfa.amsl.com>; Fri, 17 Mar 2017 03:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 wZKoDGZNsxIa for <v6ops@ietfa.amsl.com>; Fri, 17 Mar 2017 03:13:10 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (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 447EA129A83 for <v6ops@ietf.org>; Fri, 17 Mar 2017 03:13:08 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id C72AB618BA for <v6ops@ietf.org>; Fri, 17 Mar 2017 11:13:06 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 882486034B; Fri, 17 Mar 2017 11:13:06 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 772F033A18; Fri, 17 Mar 2017 11:13:06 +0100 (CET)
Date: Fri, 17 Mar 2017 11:13:06 +0100
From: Gert Doering <gert@space.net>
To: Mark Andrews <marka@isc.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gert Doering <gert@space.net>, v6ops@ietf.org
Message-ID: <20170317101306.GT2367@Space.Net>
References: <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> <20170316201413.GQ2367@Space.Net> <212f8258-a025-325e-badc-e7bdcc2bf5f7@gmail.com> <20170316232633.77ADD66F1D4A@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Ub0MCZ5J9UXWVvV5"
Content-Disposition: inline
In-Reply-To: <20170316232633.77ADD66F1D4A@rock.dv.isc.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lZrPPDRjWiUfdIzlYk2aVMh7fAs>
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:13:12 -0000

Hi,

On Fri, Mar 17, 2017 at 10:26:33AM +1100, Mark Andrews wrote:
> > 
> > Yes, one always needs cautious allocation policies. But still... /64
> > is not enough in the general case, with today's link-layer media
> > and today's IPv6 stacks. (We can have the argument about tomorrow
> > some other time. :-)
> 
> And PD allows for a node to do multiple PD requests.  Each router
> doesn't need a pool of prefixes to answer PD requests from.  It can
> do a upstream request to full fill the downstream request on demand.

Technically, it could.  Administratively, I'm going to believe that
when I see it - like, in a big enterprise network, individual /64s
being routed randomly across the place because a wifi hotspot needed
another prefix to hand out.

> A coffee shop is a site or part of a site.  That site should have
> a /48 with 65536 /64 subnets to further allocate.  Hosts draw from
> that pool.  Yes, that does mean that there are lots of intra site
> routing entries for /64's rather than for shorter prefix lengths.
> That however shouldn't matter because it is not a excessive number
> for even the most inexpensive router to handle and they are summaried
> as a /48 in the global routing table.  Even with a few of /48 pools
> from different ISPs it still isn't excessive.

A coffee shop has a /48 today (or a /56, given that the RIR policies
where changed based on extrapolations that a /48 for each SoHo customer
connection might not be sustainable).

If we suggest that hosts should "get a /48", and there a a number of 
customers in that coffee shop, then a /48-per-site is not going to
be enough.

But seriously: how many visitors of said coffee shop would need
more than a /64?  Yes, I've heard about the laptop with the VMs running,
in multiple hierarchical virtual networks, and such.  How many of those
laptops exist?  100, 1000?  This is totally niche.  

Normal users want their browsing, e-mail and corporate VPN to work.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279