Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Mon, 11 October 2021 16:00 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 EAF1C3A0AFA; Mon, 11 Oct 2021 09:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 ptL74QQYyiE3; Mon, 11 Oct 2021 09:00:35 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A66633A0B1D; Mon, 11 Oct 2021 09:00:34 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:3d47:4290:6816:2e2f]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 19BG0YAv2817182 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 09:00:34 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 19BG0YAv2817182
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1633968034; bh=fB7zDRDQCOFxUFyMAViuLjztkdngVrl5KFxxatC5olw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=hQazxVfgJF4gRWtw3dkT2wWqihuUThYkaURn6nI2w8MzqH6kg9paQ3/zejSavfFXA ZZ1Bm1RTSvQdxBgSLmFpzCVUrBP5TgvMh74Hwl2wgMPxbxESc/YRC9TdzsqZ14bj4U KDrvIcmZx+Fn+0y1HXlswgc6MZ2PCI5W42/xHC2o=
From: Owen DeLong <owen@delong.com>
Message-Id: <5DF8D1AE-4B54-429F-962A-488F2AA1F895@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CE6CD1E-A00E-45C3-902A-C1AE4085E10C"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 11 Oct 2021 09:00:21 -0700
In-Reply-To: <CAKD1Yr10OKMJ1y8bs5xpt6jS8ZWsqs66oFCXmp-QLySS5Yn4hg@mail.gmail.com>
Cc: Owen DeLong <owen=40delong.com@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
References: <DDA36020-90CC-471B-83AD-3D98950F1164@delong.com> <CAKD1Yr0T-7t-UHbsJBMLpTjKhPAV5uUQkux6oby89TVUue7PyA@mail.gmail.com> <CO1PR11MB4881D400EA4681F1505040D2D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <CAKD1Yr3TmqFxjKuZ57wS7VuPOf6rJvOwnvnQdFrRLQ=DkZ+CCw@mail.gmail.com> <CO1PR11MB4881F411A4D5BEA7A8479726D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com> <D8AEA194-293B-43E4-BCAE-33CD81FB7D8C@delong.com> <CAKD1Yr2Tug-PFV7wAh0s6-gw8W3LcLG7wC1fD7Lu_hMZQYKdtw@mail.gmail.com> <08D2885E-B824-48E8-9703-DCA98771FA37@delong.com> <CAKD1Yr2EVsY3tYUf56R0Q1+KVrowtqh-HgwXj5vxzy4wd-vkTg@mail.gmail.com> <1A6ED87B-666E-439C-852F-2E5C904C0515@delong.com> <CAKD1Yr23fY2DJDvB-9eVFRsxnBnZQ0kZuZfYUfRUHYW=_D=enA@mail.gmail.com> <CAN-Dau1z0q0R61x7iY+Wg_cFRU0jmqr+fR0y=bSXxj+K-n722w@mail.gmail.com> <CAKD1Yr1T_mXfxJGHOrBfqZfexm6GTrUqnFi57710pTroKQK6uQ@mail.gmail.com> <702CB018-1A02-4B32-B9AA-7C7B31521F12@delong.com> <CAKD1Yr0jZR8Efzr_Y6FeiBvHYS8ATmDupx2ABTXXy-rSA_QjmA@mail.gmail.com> <1adb70a8-db0a-4ea6-f721-c1035343cda3@foobar.org> <DM6PR02MB69249D4F0A8003E77EC9F153C3B19@DM6PR02MB6924.namprd02.prod.outlook.com> <E1FED93B-674C-46DD-8C39-F6C30475C48A@delong.com> <CAKD1Yr34jv_N0jGKdg=sG76oGU7PdRjYFC_-w9Uvzs=7oGm38w@mail.gmail.com> <E6316781-AC7D-438F-B216-75B1DF9217DC@delong.com> <CAKD1Yr10OKMJ1y8bs5xpt6jS8ZWsqs66oFCXmp-QLySS5Yn4hg@mail.gmail.com>
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]); Mon, 11 Oct 2021 09:00:34 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/nOmnBVQF_BgRyheNYDrwnNNriq0>
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: Mon, 11 Oct 2021 16:00:47 -0000


> On Oct 10, 2021, at 23:12 , Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
> 
> On Mon, Oct 11, 2021 at 1:36 PM Owen DeLong <owen=40delong.com@dmarc.ietf.org <mailto:40delong.com@dmarc.ietf.org>> wrote:
> Suppose an OS developer ships a DHCPv6 implementation that requires N addresses and does not enable the IPv6 stack unless it receives all of them. How does that do anything to address statements such as, "my network, my rules" that have been made on this thread? Any operator that wants to assign only one address per device still cannot use such hosts on their network, and can still criticise the implementation for not doing what they want.
> 
> At least it provides a possible way forward for networks that don’t want to assign addresses outside of IA_NA or IA_PD to provide addressing to android devices.
> 
> Surely a single IA_NA + a routed IA_PD would meet your requirements, right?
> 
> IA_PD, even by itself without IA_NA, has none of the concerns in this thread. RFC 7934 explicitly recommends it, actually. Not sure if enterprise network operators can or would want to deploy IA_PD though. Is that something that we can nudge the industry towards?

I see no reason that enterprise operators would need to oppose IA_PD as the prefix is entirely accountable to the authenticated device.

However, they’re not going to want IA_PD addresses on the directly attached interface. They’re going to want IA_NA there and to route the IA_PD prefix to the host via ND resolution of the MAC of it’s IA_NA address.

>> What I think David was suggesting is: if we reach consensus on some reasonable value of N, then the IETF could write a BCP to that effect. That would help to some extent, because if an operator complains that the implementation does not work on a network that has N=1, the OS developer could point to the BCP as justification for why.
> 
> I don’t think that’s really necessary. I think there are already adequate documents about single-address is less than ideal in the existing RFCs/BCPs.
> 
> The existing BCPs also say that running an IA_NA-only network is not recommended, but that doesn't prevent folks from saying it's necessary. I think we'd want to make a stronger statement than that.

I don’t think a stronger statement is needed.

Owen