Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Wed, 13 October 2021 22:20 UTC

Return-Path: <owen@delong.com>
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 856B13A1234; Wed, 13 Oct 2021 15:20:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 Do3QsI6LSqNc; Wed, 13 Oct 2021 15:20:01 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47E3A122E; Wed, 13 Oct 2021 15:20:00 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:ed73:98e2:9599:2427]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 19DMJtGF4080139 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Oct 2021 15:19:58 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 19DMJtGF4080139
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1634163598; bh=0dtBb8ylR0C0wRkRLzvA/tKLSM0SyoWCFvXVFa59QkQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IaL04wtB1GfpG+/XXOxDxvCyC5pGy1+3uSVybxSiW1d1d98EaeUtRBsSx4v2MhyQ9 cdNYjiBiihLYrGMLI99GEr9qbyi557R6Ls6xlB7bwlOpmGv1HP2wzbnqnO0v+EpwiA sPeyolkNVtBgudCtD70YajPbDI2isgpriz639LME=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <802A4F47-5DB0-4986-894D-2B20BA09FF24@cisco.com>
Date: Wed, 13 Oct 2021 15:19:49 -0700
Cc: Owen DeLong <owen=40delong.com@dmarc.ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <36CB5B2A-2469-4E51-9536-D16B66BE3B6E@delong.com>
References: <CAKD1Yr10OKMJ1y8bs5xpt6jS8ZWsqs66oFCXmp-QLySS5Yn4hg@mail.gmail.com> <5DF8D1AE-4B54-429F-962A-488F2AA1F895@delong.com> <CAPt1N1ma45GKqXcvjHUGCYFKVbEGp3OuT013pZhrnOkFFLMiQA@mail.gmail.com> <CAKD1Yr2Pe+=tNkA7Ou9KeMkgFhcdSb8WxgVn1w9MauusMEhRcw@mail.gmail.com> <CO1PR11MB4881076DFF8A145C8CD818B8D8B69@CO1PR11MB4881.namprd11.prod.outlook.com> <A188D974-3CEB-497F-93EA-B66C77D2CA90@delong.com> <YWW1ghmjueHmfCEb@Space.Net> <m1maKp6-0000I3C@stereo.hq.phicoh.net> <YWW8FPkRuxCBFp3o@Space.Net> <D0510DEB-04FF-4864-9363-6FC40C686C22@delong.com> <YWcQKwK3lAKpl7y1@Space.Net> <DFD526B0-7CA3-4445-910F-425142C0AEDA@delong.com> <802A4F47-5DB0-4986-894D-2B20BA09FF24@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 13 Oct 2021 15:19:58 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vxiDYXyV9_cf_ft2hZLwdKkORww>
Subject: Re: [v6ops] Implementation Status of PREF64
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Oct 2021 22:20:07 -0000


> On Oct 13, 2021, at 13:08 , Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hello Owen 
> 
> The thing of the past is probably still perfect in some unmanaged networks but I understand that your focus is not those.
> 
> /64 came with neatly with EUI 64 as you point out, and we are deprecating that for privacy. 

Yes, but we’re choosing a new form of 64-bit random number to take its place, so from my perspective, it’s still basically
a form of EUI-64 addressing even though not based on the actual MAC address.

> Switching better than routing in the domain we call a subnet is also becoming obsolete since even when we think we switch we probably route at L2 or in an underlay.

I guess that depends on how you define “L2 routing”. My definition is of routing involves deprecating the hop count (TTL in v4) and replacing the L2 headers. Forwarding
at L2 is (mostly) one of repeating or bridging (which usually called switching due to differences in hardware between modern switches and traditional bridges). Repeating
is what happened in old UTP hubs and even older DELNI boxes.

> Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to every host just to be able to route inside the subnet at L2. 

Need is an interesting thing, but I don’t think it’s particularly relevant. I think the true question is what is useful to do and doesn’t pose an undue threat to addressing in the process. I think /64 meets that test.

Depending on your definition of “need”, we could claim that each device only needs one address behind which it can nat everything else on the device or behind the device and use ULA there. That’s not the model of IPv6 I want to see deployed, but if you push the bare-bones need argument far enough, that’s where you end up.

I’d much rather see us do reasonable addressing, issuing reasonable subnets (/64 seems perfectly fine to me) and one on.

> We can easily route to /112 or even to /128. I’m used to the latter because we build subnets of thousands of nodes in IoT and we know the nodes from a registrar, typically DHCPv6. But I see benefits of giving a prefix to the phone or the PC and let it distribute the addresses to stuff like VMs and tethered nodes.

Meh. If that works for you in your environment, more power to you.

> Why insist on /64 per host? Seems to me that the properties that we want do not depend much on where we cut.

I’m not insisting on any particular size in any given network’s implementation. I am insisting that we don’t put silly limits on what people can do because someone has a misguided fear of running out of prefixes.

> What’s really interesting is to decouple the domain we decide is a subnet from a L2 broadcast domain and from what we see as an IP link. For that you need L3 routing inside the subnet. The /(>100) per host gives you all that.

Why would we want it?

Owen

> 
> 
> Regards,
> 
> Pascal
> 
>> Le 13 oct. 2021 à 19:26, Owen DeLong <owen=40delong.com@dmarc.ietf.org> a écrit :
>> 
>> 
>> 
>>> On Oct 13, 2021, at 09:58 , Gert Doering <gert@space.net> wrote:
>>> 
>>> Hi,
>>> 
>>> On Tue, Oct 12, 2021 at 12:39:43PM -0700, Owen DeLong wrote:
>>>>> (ceterum censeo, /64 was not a very smart decision)
>>>> We can agree to disagree. So far, I???ve seen no data to support that.
>>> 
>>> Indeed.
>>> 
>>> So far I have not seen any data that supports "/64 was a good idea" :-)
>> 
>> It’s working quite well in a number of networks I’ve deployed.
>> 
>> It’s convenient for EUI-64 addressing.
>> 
>> Reviewing the record, it seems we were destined for something like 64-bit
>> addressing overall before IETF decided to consider EUI-64 addressing and
>> added 64-bits to the plan, so one can argue that without the idea of
>> universal /64 addressing we’d have a whole lot fewer network numbers
>> available.
>> 
>> So now you have seen data to suggest that /64 was a good idea.
>> 
>> Do you have any data support your claim that /64 was not?
>> 
>> Owen
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops