Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Fri, 08 October 2021 20:36 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 E04B53A0863; Fri, 8 Oct 2021 13:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.238
X-Spam-Level: *
X-Spam-Status: No, score=1.238 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, LOTS_OF_MONEY=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 q-hW1b7jh0b7; Fri, 8 Oct 2021 13:36:39 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id D77243A0860; Fri, 8 Oct 2021 13:36:38 -0700 (PDT)
Received: from smtpclient.apple ([12.33.220.202]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 198KaUHJ980763 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Oct 2021 13:36:32 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 198KaUHJ980763
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1633725394; bh=NGTVCIPUtl9KwQuOSRpuXZsAcdFaKjSklw9NqKc+cQ4=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=LsW3XP1ZLUvdJnM1qfWS0A1RCu8nNEoPzD53ip1PBuVGuPUjKKdDXZtxlRKZT84/T 8LOGb10F9Eh6r3iJ0a4xCIP/Lj+KHKwuqJiCoo+ok6jb6GQ/N5sWHDdaIvI5wflamu ArrEtFvvy1HHd1Dobdaf/paSYvhuua135xq8Fej8=
From: Owen DeLong <owen@delong.com>
Message-Id: <CEF113D2-1F80-422F-BBD1-1E1951367A2F@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31ABDF72-2556-4313-8163-4A81E5B3CAC9"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 08 Oct 2021 13:36:29 -0700
In-Reply-To: <CAN-Dau0q7p-9NWv=9vouX51Z1Yqe_h06WwpnkMjkyj6=A7EcQw@mail.gmail.com>
Cc: "STARK, BARBARA H" <bs7652@att.com>, v6ops list <v6ops@ietf.org>, Lorenzo Colitti <lorenzo=40google.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> <CAN-Dau0q7p-9NWv=9vouX51Z1Yqe_h06WwpnkMjkyj6=A7EcQw@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 [192.159.10.2]); Fri, 08 Oct 2021 13:36:34 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6jcThTGhw2Ffx-IQUd2THPo0NHU>
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: Fri, 08 Oct 2021 20:36:46 -0000


> On Oct 8, 2021, at 9:28 AM, David Farmer <farmer=40umn.edu@dmarc.ietf.org> wrote:
> 
> 
> 
> On Thu, Oct 7, 2021 at 8:21 AM STARK, BARBARA H <bs7652@att.com <mailto:bs7652@att.com>> wrote:
> > > but hosts should not
> > > be able to set policies on how many IPv6 addresses they accept.
> > 
> > Sure they can.  There's nothing stopping a dhcpv6 client from refusing
> > to enable ipv6 on an interface if it gets less than N addresses.
> 
> Host policy should be dictated by the people in control of the host and not IETF.
> IETF has no business restricting the rights of device owners and private networks operators to dictate what devices are allowed to do on their network. This sort of prohibition on device owners and private network admins setting host policy would be 100% harmful.
> 
> Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you think it is inappropriate for host implementations to enforce some number of IPv6 addresses be available? Or, are you saying that is completely up to network operators?

If I operate a network, I don’t think that a host should be able to demand N addresses from my network (for any value of N).

It can ask. I can give it as many or as few as I’m willing. It can decide to use what I offer or not.

> I will note a few things;
> 
> 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, said that N<1.

I doubt that. N<1 would be utterly useless… Perhaps N>1?

> 2. In effect Android already enforces, N<1, by only supporting the self-assigned addressing model of SLAAC.

Yes, because Android has a large market share, they are, in effect, through their refusal to adopt IA_NA, bullying (or at least attempting to bully) network operators that choose to implement IPv6.

This divides the community into three groups…

	+	Those that are not implementing IPv6 at least in part because of this issue
		(probably the vast majority of enterprises at this point)
	+	Those that are being subverted by this bullying
	+	Those that are implementing IPv6 in a “sorry, android, you can’t play until you fix it” mode.
		(by far the least populous group for now)

> 3. However, by not supporting a DHCPv6 client, Android doesn't support the managed-assignment addressing model of DHCPv6.
> 
> In an effort to find a compromise that allows Android to support DHCPv6 and therefore the managed-assignment addressing model, I'm suggesting it is reasonable for DHCPv6 clients to require the availability of more than one IPv6 address before it enables it's IPv6 stack, and it sounds like Lorenzo is at least open to discuss such a comprise.

The client is free to implement whatever minimums to implement its v6 stack it wants. IETF doesn’t need to weigh in on this, no standardization is required.

Android will simply become known as oddly dysfunctional in IPv6 which is an apt description for such behavior.

> However, it seems that some people are insisting that network operators should be able to assign one and only one IPv6 address per client. Personally, I think this argument is utterly futile, is creating a deadlock, and it is holding back the deployment of IPv6. However, this deadlock is not caused only by Android not supporting DHCPv6, but it is also caused by those that insist that assigning one and only one address is a valid IPv6 deployment strategy, and that network operators should have ultimate and unilateral control in this matter.

Network operators by and large own the networks they are operating and they should have unilateral control over the numbering decisions on those networks. To claim that some hardware vendor should be entitled to override the operators wishes just because they don’t like the implications is silly.

Do I think that network operators _SHOULD_ allocate more than one address per client? Absolutely.
Do I think that it is IETF or Google’s or Lorenzo’s place to say that they MUST? Absolutely not.
Heck, I’d like to see ISPs required to hand out /48s per site regardless of customer type or size.

Nonetheless, the operator pays for and builds the infrastructure, the operator deals with registering the address and takes responsibility (at least in the enterprise case) for the goings on on the operator’s network. As such, yes, the operator gets to absolutely decide what resources any given host is allowed on their network.

> I'm willing to concede that network operators need to allocate more than one IPv6 address per client.. Furthermore, I think it is very important that all major operating systems allow for both IPv6 address assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).

I’m willing to concede that they should. I’m also willing to accept android shutting down its IPv6 stack if it wants to throw a temper tantrum over the resource constraints of the network it’s trying to attach to. I’m not willing to take that next step and say that operators should be dictated to by IETF, Google, Lorenzo, et. al.

> I'm having visions of IETF becoming not unlike the Texas legislature in its desire to dictate "morality".

Yeah, let’s let every android user sue for $10,000 if they can’t get their preferred number of addresses… Yay.

Owen