Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Mon, 11 October 2021 17:09 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 B48FA3A0DEE; Mon, 11 Oct 2021 10:09:43 -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 Tulga-k-K_3h; Mon, 11 Oct 2021 10:09:38 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8883A0DEA; Mon, 11 Oct 2021 10:09:38 -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 19BH9b2C2838149 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 10:09:37 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 19BH9b2C2838149
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1633972177; bh=TnzH/Ej+Fouutoj7AMj878tOUCtwZik5cfpglPaGUpY=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=I+kdYX1SZh8uBFny6y/iNWcPDLt3+Lt4hULqo5GFMWyxwbA0je2WvptJclIiR69BF squoia+hFdTIIVHVpEXOSErUiTMPYNXlCcsQNtaezFCCV57tfEomj5SPT2J/hF4Ka4 f0XbTeBQDrhZtvpJJoHrJ98aovnxLYPSCA6ajs38=
From: Owen DeLong <owen@delong.com>
Message-Id: <403087B1-51A5-4DF4-9884-441D443DACC2@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_98A88E8B-3564-4BED-9A13-791F9C5A6CF9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 11 Oct 2021 10:09:37 -0700
In-Reply-To: <CAN-Dau3JxPucFnbwZB-M5UD3KkSV++7u03AMQ7vOZJKqPHpJ3Q@mail.gmail.com>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>, Owen DeLong <owen=40delong.com@dmarc.ietf.org>
To: David Farmer <farmer=40umn.edu@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> <CAN-Dau3JxPucFnbwZB-M5UD3KkSV++7u03AMQ7vOZJKqPHpJ3Q@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 10:09:37 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uIVfVbOWkK--C8E9qOhSUWdJ2SM>
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 17:09:44 -0000


> On Oct 11, 2021, at 09:37 , David Farmer <farmer=40umn.edu@dmarc.ietf.org> wrote:
> 
> 
> 
> On Mon, Oct 11, 2021 at 1:13 AM Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org <mailto: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 think this is a perfectly reasonable option for the general purpose use case, but I will note there is no clear guidance for the use case of IA_PD on Hosts, and even the guidance for the use of IA_PD with routers is somewhat fuzzy or at least incomplete, in my opinion. Nevertheless, this may or may not be reasonable for special or restricted purpose use cases, especially when compliance regimes are required, like PCI or NIST-800-171. I support IA_PA on hosts, but whether or not that is an acceptable replacement for IA_AN and/or IA_TA for all use cases is very much an open question, and not entirely a technical question for that matter.

At the point where a host solicits and/or accepts IA_PD, it has effectively declared itself to be a router.

Since most android devices have multiple interface and the ability to provide a “hotspot” capability, they are, in fact, routers.

Owen