Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Wed, 13 October 2021 17:56 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 185443A08B6 for <v6ops@ietfa.amsl.com>; Wed, 13 Oct 2021 10:56:17 -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 8FjMa5Wcz_Ta for <v6ops@ietfa.amsl.com>; Wed, 13 Oct 2021 10:56:12 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id AF16F3A0890 for <v6ops@ietf.org>; Wed, 13 Oct 2021 10:56:12 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:14af:8646:5244:2bdd]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 19DHu9fP3978555 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Oct 2021 10:56:09 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 19DHu9fP3978555
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1634147771; bh=gKmPyhZSJDkU7itkQHj+g3EXZntXV5UDsP48Le2+Z8k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=qzpS2NfW8Wtla/AxPM2qplCmfDCsj4AZB01n0jRmRpGEAXWvgR54ROYXFc6j0GkqK LjKqOweCaTq88kZt+JtCkBtfpzZHb8U3h5JcPtZxxqZyogiki3S/D0ZM79vB2v4jkK pdXNenRTG6MeeLXhCrV+hIrmieNmy1IMlu4JRn3g=
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: <YWcZaur+BLe5iNCx@Space.Net>
Date: Wed, 13 Oct 2021 10:56:09 -0700
Cc: Philip Homburg <pch-v6ops-10@u-1.phicoh.com>, v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8D81F4E-13DD-465F-ABB7-CAD730D27B25@delong.com>
References: <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> <YWcZaur+BLe5iNCx@Space.Net>
To: Gert Doering <gert@space.net>
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 10:56:11 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/NxEXWy6rDtSoelJPxaoOSBHRe_Y>
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 17:56:18 -0000


> On Oct 13, 2021, at 10:37 , Gert Doering <gert@space.net> wrote:
> 
> Hi,
> 
> On Wed, Oct 13, 2021 at 10:25:36AM -0700, Owen DeLong wrote:
>>> 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?
> 
> What part of "yeah, it works for me" makes it a *good* idea?
> 
> So did /80s, when they were the latest fashion.

Actually, /80s never worked well for me, YMMV.

> What part of "EUI-64" is a *good* idea, now that everyone is actually
> moving away from EUI-64, because it has more undesirable properties than
> "oh, yeah, it was there and is convenient"?

I guess it depends on your idea of undesirable. EUI-64 is working fine if
you don’t consider it a tracking issue (which there are far more effective
trackers these days).

Further, even if you like privacy addressing (frankly, I’m not a fan, but I don’t
care too much), a 64-bit random number is a reasonable size space to make
searching relatively difficult, so it’s still a good idea.

> Nah.  8+8 was a brilliant idea that did not happen - and nothing else
> in a /64 is more than "we can't find consensus to change that".

If it was so brilliant, why was it rejected?

> On the downside:
> 
> - it creates pressure on the number of subnets in reasonably structured
>   deployments (think of the number of subnets you can have with a /96
>   standard subnet size...)

I’m really not worried about running out of /64s with any rational addressing plan.
See previous messages.

> - ND exhaustion attacks (which arguably would happen in a /96 just as well)

ND exhaustion attacks are a reality the moment you move away from having too
few addresses for the hosts in a decent size subnet to be able to do anything
like meaningful privacy addressing, so I think you lose on that one no matter
what.

The reality is that ND exhaustion attacks will find alternative mitigations, including
rapid garbage collection of unknown ND entries when resources get constrained
and other mechanisms that have larger tradeoffs. Nothing is perfect.

Owen