Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Tue, 28 September 2021 04:54 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 286733A1BE1 for <v6ops@ietfa.amsl.com>; Mon, 27 Sep 2021 21:54:47 -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=unavailable 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 pHUfqUZ5_rI0 for <v6ops@ietfa.amsl.com>; Mon, 27 Sep 2021 21:54:42 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id C02AD3A1BE2 for <v6ops@ietf.org>; Mon, 27 Sep 2021 21:54:42 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:252a:24d5:4616:456c]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 18S4sYJH1068791 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Sep 2021 21:54:36 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 18S4sYJH1068791
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1632804877; bh=UjoSj3TSrMWMZUdPrlhhxnCZrRDMwHfW6PnxfsoZAO0=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=FpKlSGW8cfLIlBB1H+Qhdp/BEZrSyrKaXcM6LJeMvA72CalScChyhumKmKdBjPZ2F 0G70YEPUOo0Kxy4e2p4CQIBfghRkzD56lwIKJJK71YQWAHUqub9oWhF1/6HAu+ZdFP nIwQo9JPiyR+OUmeP6oASK1L4UucSfvJyi/ikV7w=
From: Owen DeLong <owen@delong.com>
Message-Id: <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_17605B00-D5F1-4780-9BCE-90C51D834B37"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 27 Sep 2021 21:54:34 -0700
In-Reply-To: <CAKD1Yr2K3Gd3JD=NJFOoH6GYgs-8ACxRQB9-sKJ7cbF4_hxsow@mail.gmail.com>
Cc: Owen DeLong <owen=40delong.com@dmarc.ietf.org>, David Farmer <farmer=40umn.edu@dmarc.ietf.org>, V6 Ops List <v6ops@ietf.org>, Jen Linkova <furry@google.com>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
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>
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, 27 Sep 2021 21:54:37 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LsWLNn7jBuNkjKlLzeZOTCrnPN8>
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 04:54:48 -0000


> On Sep 27, 2021, at 18:11 , Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> wrote:
> 
> On Tue, Sep 28, 2021 at 6:04 AM Owen DeLong <owen=40delong.com@dmarc.ietf.org <mailto:40delong.com@dmarc.ietf.org>> wrote:
> 
> In the tightest forms, it goes something like this (oversimplified and generic):
> 
> 0. Port starts out locked down to communicating with DHCPv6 server and NAC authenticator only.
> 1. Use LL address to send DHCPv6 request.
> 2. Get DHCPv6 address and use that for 802.1x authentication. There are a variety of options
> 	here including authentication of not only the machine, but also the individual currently
> 	using the machine and the classification of network privileges based on either or both
> 	of these factors, etc.
> 3. A filter is added to your port permitting your presented DHCPv6 address (which the NAC authenticator
> 	has validated matches to your MAC and LL address) that permits your LL and DHCPv6 addresses
> 	to communicate with the rest of the network. Any additional policies can also be added at this
> 	point if the administrator chooses.
> 
> I don't see how DHCPv6 is required for any of this. What you describe above boils down to, "a machine is allowed to use the network only if its MAC address is acceptable to the network". That can be done with SLAAC just as well. Let me reword for SLAAC:

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.


> 
> 0. Port starts out locked down to communicating with NAC authenticator only.
> 1. Use LL address to send RS.
> 2. Get IPv6 address from SLAAC and use that for 802.1x authentication. There are a variety of options
> 	here including authentication of not only the machine, but also the individual currently
> 	using the machine and the classification of network privileges based on either or both
> 	of these factors, etc.
> 3. A filter is added to your port permitting your presented MAC address to to communicate with the
> 	rest of the network. Any additional policies can also be added at this
> 	point if the administrator chooses.
> 
> 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.

Just because you think it is better in the environments where you operate doesn’t mean it’s better for everyone in every environment.

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

Owen