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

Gert Doering <gert@space.net> Thu, 10 August 2017 05:58 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 0BAB7132557 for <v6ops@ietfa.amsl.com>; Wed, 9 Aug 2017 22:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 vYARimyJPYXb for <v6ops@ietfa.amsl.com>; Wed, 9 Aug 2017 22:58:23 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0A4132556 for <v6ops@ietf.org>; Wed, 9 Aug 2017 22:58:22 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F32454291C for <v6ops@ietf.org>; Thu, 10 Aug 2017 07:58:19 +0200 (CEST)
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 E222D42916; Thu, 10 Aug 2017 07:58:19 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id DE6B9178F9; Thu, 10 Aug 2017 07:58:19 +0200 (CEST)
Date: Thu, 10 Aug 2017 07:58:19 +0200
From: Gert Doering <gert@space.net>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Gert Doering <gert@space.net>, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, v6ops list <v6ops@ietf.org>
Message-ID: <20170810055819.GQ45648@Space.Net>
References: <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> <3A69468C-98E4-4631-A52F-3D8772646EEE@consulintel.es> <20170807110746.GG45648@Space.Net> <CAO42Z2xXXjKUZ8qQY+b1NgDagX2ZJkqL5gieD+_js59ucp0EMw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Dadxls/0Fulk8RKG"
Content-Disposition: inline
In-Reply-To: <CAO42Z2xXXjKUZ8qQY+b1NgDagX2ZJkqL5gieD+_js59ucp0EMw@mail.gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/NZyhoPjIlMKLHmR-_ZEdKVWFU3U>
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: Thu, 10 Aug 2017 05:58:26 -0000

Hi,

On Thu, Aug 10, 2017 at 11:24:48AM +1000, Mark Smith wrote:
> > And yes, I think this is extremely wastive, well over the limits of what
> > is normal "do not care about wasting addresses!" level of IPv6 normal.
> 
> So it's worth considering what the word "waste" means. It means
> getting no value at all from some quantity of a resource. That
> quantity of resource isn't being used for anything of value to the
> resource's user.

Waste can also mean "I have used up something without actually needing
it, and now it's missing somewhere *else*".

[..]
> > Should this topic come up in RIPE policy discussion, I'll chair the
> > discussion and refrain from having an opinion, but will reserve the right
> > for a "told you so" later.
> 
> I assume RIPE give out /32s as the minimum to an ISP, or 4+ billion
> /64s? If an ISP isn't giving out at least /56s to customers, the
> problem isn't with the /64 boundary, it is the ISP carrying IPv4
> address scarcity management practices over to IPv6 where they aren't
> needed.

So how useful is a /56 to a customer if the customer wants to do
/64-per-host?

If it's /64-per-LAN, a /56 is a useful value, but for /64-per-Host it's
all of a sudden becoming tight for slightly larger customer sites.

> We are wasting our time (getting no value from it) trying to
> accommodate unneeded IPv4 practices carried over to IPv6. We end up
> trying to make things accommodate more and more perverse and
> unnecessarily conservative IPv4 carried over practices. If we
> accommodate them, we're also tacitly endorsing them.

I could point out that "a /64 everyhwere" is repeating the "Class A, B, C"
mistakes from IPv4.

Your turn.

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