Re: [v6ops] Implementation Status of PREF64

Lorenzo Colitti <lorenzo@google.com> Tue, 28 September 2021 05:21 UTC

Return-Path: <lorenzo@google.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 9D5833A1CE9 for <v6ops@ietfa.amsl.com>; Mon, 27 Sep 2021 22:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.097
X-Spam-Level:
X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 u35u5EbhA2PU for <v6ops@ietfa.amsl.com>; Mon, 27 Sep 2021 22:21:35 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 7B2D63A1CE1 for <v6ops@ietf.org>; Mon, 27 Sep 2021 22:21:35 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id q127-20020a1ca785000000b0030cb71ea4d1so1741372wme.1 for <v6ops@ietf.org>; Mon, 27 Sep 2021 22:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BDBbOrkVoo/BH8bZcuMF3NEdyw4VQmCQMnm9Xu8jv8c=; b=RsKhgZXGoqjeVnr59MjFcbX/+lyyow13ljzPk9smEiiZhK05PbJ0IecCkqVsomD5op csPwbydSIC/3zjbYl74Wwdxze5UVuJhVVV5CHWhoPHuXByvHg34zpxxTF/57l80WWrkx aE/6JJiFXsKSYzcU4J6qODNCVNeEP/PGLc4qc6zZvp6kJywKSkv/pNmokj2jgzMMoZ76 yE1muau+JJ1ANr0HKHvvqo/U+HkKCzPIlGk+GZf0wg+++/R1sG3gpRzKEIE+2sA094bv 9AEbX7C5JNp8bbir6IHT16e72foFooskM4pS7rSHfGuPX7DOXP399wRLzCB5/cE2bn4z ic6A==
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=BDBbOrkVoo/BH8bZcuMF3NEdyw4VQmCQMnm9Xu8jv8c=; b=5u0o2fxDiXFuVs2UBWX8nSyqK1szHRtqT5FTIJKX3QWfUl4NI0FgCa4KY6SkOrGUQr PEfpY0gkpZ4+unO9IjOJntUuIpjk9XQ8Mi5SlC6xm5W8LmtVQRN7XCLDHNjmWAgHG76J k7fkhMXWPS13Z1XGsKtPw8HQxtrHqtp5wQL4savfro8WsnyGwOiZc5TxotXng3O5JUFA 4em6VCe25vjx5q9ri33zXknavnLaVziTBolP5JFjV9xVRIPWRkevk8zjijrKqZuDb0su q0YAi5d3nMCRw/nNr9BpGjXCGXiFQcUjkjMY8C9/hdDdmhf+91aHn3/wpbn/Iujkm+FV EhEg==
X-Gm-Message-State: AOAM532EvvC+bRZqM8VG32zPekNkSL2FcvwlS+odG2uucU/5tWwo47Gp oarBv1pSxV8QDIIg15R6bQK6pcctScfWYH3N1Qs75A==
X-Google-Smtp-Source: ABdhPJxMO5GAyQhHdpdbz9FSsrvXPwun2iqn/gFde/keyFU3olyjOZhW0V1MEfx0weEKwJ/mMPzNwXajgv3iN5Dw9HY=
X-Received: by 2002:a05:600c:1d18:: with SMTP id l24mr2803421wms.98.1632806493165; Mon, 27 Sep 2021 22:21:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAN-Dau2in52xSUkqKEXu=2AAiR4O_jLhna7hY-hshYDORfGtcQ@mail.gmail.com> <CAMGpriWFp4JPtqDK5tEj1RkS-SzEfvscfUUnxgK+o6qP2pusRA@mail.gmail.com> <6E95834D-12B3-447B-8326-8EDE9DC6FFB1@delong.com> <CAO42Z2zA-4cK489nxKsWUN8vvU0eAiz-jS0e-_eWPg+OmP8wLw@mail.gmail.com> <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>
In-Reply-To: <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Tue, 28 Sep 2021 14:21:20 +0900
Message-ID: <CAKD1Yr3NoYfNT7+OVJoCCdgdif6AHHw29tNCPttS=-NuRZKv3w@mail.gmail.com>
To: Owen DeLong <owen=40delong.com@dmarc.ietf.org>
Cc: Owen DeLong <owen@delong.com>, David Farmer <farmer@umn.edu>, V6 Ops List <v6ops@ietf.org>, Jen Linkova <furry@google.com>
Content-Type: multipart/alternative; boundary="000000000000040a1b05cd0763bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7AihJ8u7RotHzOnT-gHrkTQY0RM>
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 05:21:41 -0000

On Tue, Sep 28, 2021 at 1:54 PM Owen DeLong <owen=
40delong.com@dmarc.ietf.org> wrote:

> No… That’s not what it amounts to.
>
> It amounts to a machine can only use the network _IF_ it completes 802.1x
> Authentication _AND_ the IP address(es) it is using match the DHCP server’s
> expectation of the address it issued to the MAC address in question.
>

Why would you want to do this? IPv6 addresses are plentiful and ephemeral.
What does it matter to some server on the Internet (or, in general,
off-link) if a given host uses 2001:db8:1:2:3::f00 or 2001:db8:1:2:3::b00
or both? Why take the privacy implications of using a fixed IID (because
DHCPv6 can't seamlessly change IIDs) to talk to all off-link destinations
all the time?

> This is better than the DHCP version above because it allows the client to
> use multiple IP addresses and does not need to be re-done when the IP
> address changes.
>
> Sometimes the network administrator doesn’t want the host using multiple
> IP addresses for a variety of reasons.
>

Ok, but that's also harmful for a variety of reasons, and for general
purpose devices, it's not recommended by the IETF. That's exactly what RFC
7934 is about - explaining why it's harmful.

I repeat… Your anti-DHCP religion is NOT HELPING.
>

Not helping with what? The transition to IPv6? But if so - why bother using
IPv6 if it's just just 128-bit IPv4, with one address per host, no dynamic
address changes (because DHCPv6 can't really support that) and NAT (because
if you can't tell the host that its network configuration has changed, you
need to ensure that the configuration *doesn't* change)? Why use IPv6 to do
that, which requires hosts to implement all the associated complexities
such as NAT traversal, NAT keepalives, etc.? That model works perfectly
well today using IPv4, and I'm pretty sure that OS support for IPv4 isn't
going anywhere any time soon.