Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Wed, 29 September 2021 01:55 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 47F1E3A006A for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 18:55:03 -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 nt3pIZUc6kyU for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 18:54:57 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id E3F233A00B0 for <v6ops@ietf.org>; Tue, 28 Sep 2021 18:54:57 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2607:fb90:a63f:7ae4:b4a8:d5b9:e50d:fe12]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 18T1stvX1866486 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Sep 2021 18:54:56 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 18T1stvX1866486
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1632880496; bh=D5WyzT/L0BMa8OS7EER+QHRS/J/mIkE/8RHnwwZ+dmM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=pjHVO0MgX1bPlaprHKs4w1Uz+AkN9kGriA/fSP/Vs6lHaVYaEtpMo9lWIV/TxZBbb Hkhhh7DVKRLL3tGsAJOvklzzkpyxJAdKCK8nlZNo4F1J6yDzVmCtxnFARrurjbNIz1 rJ5ZYFRCpFCACxZUFeB0WE004WE2N0Biw4KZF9bs=
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: <m1mVK32-0000HpC@stereo.hq.phicoh.net>
Date: Tue, 28 Sep 2021 18:54:55 -0700
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C3110D1-7913-4ED4-B9A8-AA6F5FA6F8A2@delong.com>
References: <DDA36020-90CC-471B-83AD-3D98950F1164@delong.com> <CAO42Z2wdoSdJDOB2Zo0=ZK0ecOARRsdg2nbHZGSDOhryPbLfDw@mail.gmail.com> <F2BD0A42-E9AD-45DD-999A-638E73BE1177@delong.com> <CAKD1Yr2K3Gd3JD=NJFOoH6GYgs-8ACxRQB9-sKJ7cbF4_hxsow@mail.gmail.com> <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com> <CAKD1Yr3NoYfNT7+OVJoCCdgdif6AHHw29tNCPttS=-NuRZKv3w@mail.gmail.com> <5FAD5290-3616-4194-B783-D473DB38A89A@delong.com> <m1mVGC6-0000HSC@stereo.hq.phicoh.net> <D6620D7C-8FE8-4294-8014-AB18A230C9C7@delong.com> <m1mVItl-0000GuC@stereo.hq.phicoh.net> <YVN6/cA6Ob3vLJQH@Space.Net> <m1mVK32-0000HpC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-10@u-1.phicoh.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]); Tue, 28 Sep 2021 18:54:56 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IHczdAFCfsQqO8X9TBi08AOjXT0>
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, 29 Sep 2021 01:55:12 -0000


> On Sep 28, 2021, at 1:49 PM, Philip Homburg <pch-v6ops-10@u-1.phicoh.com> wrote:
> 
>>> The net effect is that new flows use the new prefix right away, but the old
>>> prefix can be used for 2 hours longer. So timers are limited to 2 hours.
>> 
>> Indeed, this can be done with SLAAC.
> 
> I responded to Owen, who was arguing that DHCP is better suited to deal
> with flash renumbering than SLAAC.

Not necessarily better, but equally well suited at least.

> The impression I got was that the main reason to refuse to implement
> DHCPv6 IA_NA on Android is to always have a sufficiently large number
> of addresses available. With SLAAC you just pick what you want from a
> /64. Which DHCPv6 you might be limited to one address.
> 
> The argument strikes me as odd, because a router or a switch can limit a 
> device to just a few (or one) IP address. And I have encoutered such
> devices often enough to know that it is not just a theoretical concept.

If that’s the reason, it’s very silly. With DHCP, the android should act
as a DHCP Relay for it’s hotspot clients. With SLAAC, the whole handset
as a bridge that decrements hop count thing strikes me as odd in the
extreme to begin with.

Owen