Re: [v6ops] Implementation Status of PREF64

Owen DeLong <owen@delong.com> Thu, 30 September 2021 15:59 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 1E9283A0D7B; Thu, 30 Sep 2021 08:59:33 -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=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 L2lq_n78CPNr; Thu, 30 Sep 2021 08:59:27 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id B59CF3A0D7C; Thu, 30 Sep 2021 08:59:08 -0700 (PDT)
Received: from smtpclient.apple ([IPv6:2620:0:930:0:d12c:2b24:7049:d8a]) (authenticated bits=0) by owen.delong.com (8.16.1/8.15.2) with ESMTPSA id 18UFx79A3461384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Sep 2021 08:59:07 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 18UFx79A3461384
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1633017547; bh=1hG/rfc6L9eTR0L1P6VpM3oCUDFbASrXR9bLpCDV9Ec=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=oEY6+sRgkBYruaDblcMXJtf8iWljLDScg93MGjDX9ukrdIe4s+PYUp3eBQ3qfe7ID qHvog35kw7ZFiCjqCrLE7iIjmc4S49is+0no/uxCZCKxFAxunuq8PQDuyx9MKJfsSc Q1QCE8/0isuDMUoZp3QUQ7CzgOvY/gVGEqMQNYwA=
From: Owen DeLong <owen@delong.com>
Message-Id: <D8AEA194-293B-43E4-BCAE-33CD81FB7D8C@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_374925CD-2744-40D7-B9F1-4671A8EB8009"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 30 Sep 2021 08:59:07 -0700
In-Reply-To: <CO1PR11MB4881F411A4D5BEA7A8479726D8AA9@CO1PR11MB4881.namprd11.prod.outlook.com>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, v6ops list <v6ops@ietf.org>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
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> <CAO42Z2zQys6o41+m1iX1Mm88M7CaUdQa1C+uuYqxz2STfcwt_Q@mail.gmail.com> <d2887464-19d7-da09-d6f6-51ddc0e9ca45@foobar.org> <CAO42Z2w=BVoy-EmkM+x=8bVJc8WAcwRyLrdpsOAxu-as3ed6ZQ@mail.gmail.com> <CAN-Dau0v5dS9esEfQk9w0deG-QLpQ6EH9JJBY4JVcUfstFENkQ@mail.gmail.com> <1e9444b30d964a5cb17ff419eca6cc35@huawei.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>
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]); Thu, 30 Sep 2021 08:59:07 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9rZOMa3o6854dLl1dI8QBMi5Nz4>
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: Thu, 30 Sep 2021 15:59:33 -0000


> On Sep 30, 2021, at 03:14 , Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
> 
> I have the same perception of that thread and the IPv6 woes one on NANOG as you do. For one thing we cannot extract DHCPv6 brutally as a rotten tooth.
> We need to understand what it’s used for and provide a better replacement that will slowly take over. SLAAC cannot be that. The problem of SLAAC is not the AAC piece, it’s the SL. SL lacks observability, and that’s what prevent it from being a replacement to the database that the operators and network managers need, e.g., for forensics.

It’s both, actually. The AAC side interferes with certain aspects of policy enforcement that are important in some environments.
 
> I think there’s a golden path where DHCP is pushed deeper in the infra so that at first it is no more visible to the end device but still available to the operations that require it, and then we move on to the point where it becomes fully redundant and ceases to exist, by the user’s own decision, on his own agenda.

This is the problem, right here… There are networks where the administrators do NOT WANT this to be up to the user. They want control over certain policy aspects on their network. You are free to call them whatever names you want, but their networks are part of the target audience for IPv6 and they aren’t going to deploy it unless they have at least equivalent policy enforcement tools to what they have in IPv4 and they’re going to have to be implemented in a way that provides at least some familiarity or clear roadmap of the transition.

Today, that’s IA_NA combined with other enforcement mechanisms such as NAC providing dynamic switch port ACLs. Yes, 802.1x is an L2 protocol, but contrary to earlier statements, the NAC server can pull data from multiple sources and push an ACL onto the switch port that will limit the client(s) attached to that port to the addresses and capabilities permitted by the NAC policy configured (including limiting the L3 addresses that can be forwarded to the one(s) assigned by the DHCPv6 server, if desired).

If you’ve got a better idea for enterprise-level policy enforcement than IA_NA and IA_PD (where permitted), by all means, present it.

If not, then yeah, support for IA_NA is essential to forward progress in the enterprise.

Owen