IETF Logo Mail Archive

Re: [v6ops] Implementation Status of PREF64

Mark Smith <markzzzsmith@gmail.com> Tue, 28 September 2021 22:37 UTC

Return-Path: <markzzzsmith@gmail.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 675E63A0DB5 for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 15:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level:
X-Spam-Status: No, score=-0.597 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 MibwG9CZmgMY for <v6ops@ietfa.amsl.com>; Tue, 28 Sep 2021 15:37:23 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D764F3A0DAB for <v6ops@ietf.org>; Tue, 28 Sep 2021 15:37:23 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id b78so647704iof.2 for <v6ops@ietf.org>; Tue, 28 Sep 2021 15:37:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pDHN8NveUcmnlsnu6m0IWTH4bRiVvlfHVqIvUnHVyAg=; b=WeAYtn37tSKMCHpephSxva8nqyzdVzsNRPA/y/EjUbHz6hu/frMk6GrCv7Eabph/JH 8EJU7WEcZXJ5F8B9Zz9t+tPMbb+DceEk4QaT9PK6VoKwtVZJr8CzJxXV550NQVfGkg4m phHmdM96t1IFppu+BaDd8D8lCpq8qk2jgKL7Res7uVCNL82MPUmsrK/epy+dNxdeGKor mBuAyxHRnlUaOyhTls7RFm10RFXRyqChhcZ7zr0AOVCP1viEKg4XADEwNUaW2OIxf+eE x4sTKCqCVRXpYSHZcOInwn+Kp3qKb5WXqasXKzCbq21CydFYt4B4WNaqKev1PmEzgfB7 dSVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pDHN8NveUcmnlsnu6m0IWTH4bRiVvlfHVqIvUnHVyAg=; b=DDhUuvktDj+3lg7rAiTC/zPbcOFJYwjTpYPttL8ewcbgGyMyAaJ039CvZqqYADKm6+ 97J0y34fyoPtPAqHli90DOAat69Y1zOc0gWYdmH4kq16cAZkj6P8Kx9uqixYGCB/Q+/i KjefzA6+JtmrZ28aLUi9sflhOrUDzPvrE38xP4ZDufnPX6wiSKtK2fNcry8iFRZWfEQt WHvBErhypYsVALn9bz4shrfcu740lLnxf7uFJ7TMaP3y6Dl+TZUPrFUpBIrW0/yaoYal Phr0aPAAu96LxB5HdPjVDfXiiXjlfnlahj7bCstDDj3nFkj/u/h6yuymeYJMnygLtTNk fVOg==
X-Gm-Message-State: AOAM531QB9DahewbRb3ofZWTLEE2/bfjzCMIOTjRihmfi2WKRxZAeUfT eubo2h/AouTfjJCrCv5QULtjH+Wrbhkt7d+M59cJApcq
X-Google-Smtp-Source: ABdhPJyRpuEAEj3w0sDU83SpPfomaGRQRzTIMIF6kOysLAVhMzznDyj+//0WgHfGqCF/y2UE6N2cuJxMOBk90rKH/8M=
X-Received: by 2002:a6b:3c16:: with SMTP id k22mr5750723iob.130.1632868642913; Tue, 28 Sep 2021 15:37:22 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <m1mVK32-0000HpC@stereo.hq.phicoh.net>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 29 Sep 2021 08:37:10 +1000
Message-ID: <CAO42Z2zQys6o41+m1iX1Mm88M7CaUdQa1C+uuYqxz2STfcwt_Q@mail.gmail.com>
To: Philip Homburg <pch-v6ops-10@u-1.phicoh.com>
Cc: v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006d051a05cd15db12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7WFPlG2gebMLbcWi--4wXil4TrI>
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: Tue, 28 Sep 2021 22:37:29 -0000

On Wed, 29 Sep 2021, 06:50 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.
>
> >deploying SoHo networks where ISPs tend to change prefixes every now
> >and then, but managed enterprise networks.  Prefixes change when the
> >admin says so, and they know how to deal with DHCP lease timers,
> >change prefixes at times when nobody is at work, and so on.
>
> Indeed.
>
> >(Now: supporting a DHCPv6 *server* on an Android device running as
> >mobile hotspot with frequently changing uplink connectivity - here I
> >totally agree that DHCPv6 is not the right tool for such a network
> >setup.  But nobody is asking for it, and refusing DHCPv6 client support
> >because DHCPv6 server support on the same device is not a useful
> >thing sounds a bit... "painted myself into a corner" -ish)
>
> 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.
>


It's not. Lorenzo has explained why many times, including in the last week
or so on this mailing list.

Lorenzo has worked out like I have worked out that reducing external
dependencies (such as a dependency on a central server) makes things more
reliable, and also makes deploying new capabilities to hosts easier and
quicker.






> 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.
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email