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

Simon Hobson <linux@thehobsons.co.uk> Sat, 05 August 2017 09:58 UTC

Return-Path: <linux@thehobsons.co.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 1184812741D for <v6ops@ietfa.amsl.com>; Sat, 5 Aug 2017 02:58:52 -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 sEMAhSzr1OwM for <v6ops@ietfa.amsl.com>; Sat, 5 Aug 2017 02:58:50 -0700 (PDT)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA42F127B73 for <v6ops@ietf.org>; Sat, 5 Aug 2017 02:58:49 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from [192.168.137.117] (unknown [192.168.137.117]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id AEF3C1BC37 for <v6ops@ietf.org>; Sat, 5 Aug 2017 09:58:37 +0000 (UTC)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <CAO42Z2zLgw3cYapf=1y9pm4cWMZZ32DT2ryfPb6BGUFjCfmrMg@mail.gmail.com>
Date: Sat, 05 Aug 2017 10:58:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4939D55E-D37D-4551-9EB0-916FBACBC2BD@thehobsons.co.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>
To: v6ops list <v6ops@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/p-GuOQxW7EkOG_7W2aFdW-o63YI>
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: Sat, 05 Aug 2017 09:58:52 -0000

Mark Smith <markzzzsmith@gmail.com> wrote:

>> Is this prohibited by this document? Or is ‘/64’ mentioned in the document only an example?
> 
> No. /64s as the subnet size as been the common edge subnet/IID
> boundary for almost 20 years since RFC2373.

> Analysis of the 64-bit Boundary in IPv6 Addressing
> https://tools.ietf.org/rfc/rfc7421.txt

I'll make an observation that one of the primary reasons given is the now deprecated EUI64 addressing model for SLAAC.
Also there is mention of "but there sooooo many addresses, we can't possibly run out". I don't have a crystal ball, in much the same way that all those decades ago, those designing IPv4 didn't have a crystal ball.

So it appears to me that the basis of a fixed /64 comes down to :

1) A now deprecated addressing method requires it
2) Based on what we know now we can't see things ever running out
3) If any but /64 is used, then some things (implementations) may break.

So isn't the logical route to say that all implementations must support arbitrary prefix lengths - that avoids breakage when (and I suspect in the real world it will be when, rather than if) they meet something other than /64 ?
Something that handles arbitrary prefix lengths can handle 64+64, the reverse isn't true if it expects 64+64 and is thrown something else.

That and removing references to fixed 64 bit boundaries where they aren't necessary. Noting that allowing plenty of space for randomisation for security by obscurity isn't a technical limitation as such - it's merely a best practice.

And finally. There has been mention in here in the past about not preventing flexibility in the future with things no-one has yet thought of. Yes the numbers are huge, but as I said, I don't have a crystal ball.

And the argument about not having to work out prefixes/masks/etc is only partly true - and assumes that no-one would ever have to work with anything but /64. It could well lead to people who CANNOT work with anything else, in the same way that many people cannot work with anything but /24 in the IPv4 world.