From nobody Thu Sep 30 18:54:05 2021 Return-Path: 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 145BF3A0C6E for ; Thu, 30 Sep 2021 18:54:03 -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=ham 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 i0Ckj8dbIab6 for ; Thu, 30 Sep 2021 18:53:58 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 D1B863A0C6C for ; Thu, 30 Sep 2021 18:53:57 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id v25so2347860wra.2 for ; Thu, 30 Sep 2021 18:53:57 -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=SLDiqUoikqxJybBUQfNshVzVnoJPDejIqbaNqbV+qfo=; b=MCv+3/90GZ2fvVcQxFuqPeY40gMtr3NVwpx+y0F/cAAub6BcTfXJUYSF9SxRtWGJfp 5SpcVSebeRjiVVco8PCwwBrvNc25uTEIUPSKsslx0nMesPzS1ErhJ5Y3IqmdSMw/mkpe 6w960APv1U/luU7vHgAHviZtrdAmeSKZ8yVsBe5hKQqyI+qKUEcBwKtSIOqbv7L6L5re Ba9ZQfYIICvGD6jDVURnhOuugpH8kFEhBrO+wsMQCV1hogmi7FCcgXyMF9877eABUM7R Kc74rZtIjJZisLTi2E/HeXzHjsC/imBolMYxrIAKeJkvh5qlh4i0cFm/JXkp9LJZFni6 djCA== 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=SLDiqUoikqxJybBUQfNshVzVnoJPDejIqbaNqbV+qfo=; b=F27AFgOrjS4nMicnXMbg3lIaRgV5xSwev39gIS2BnTBKuP8mV8ROX/17FEUie9aqOS ZMFrbf+xJU2/aeZQ61ImETGoitvyu2ocGdN+Nnb/u9Bx4ygKch+6tcTPchPdmB1QaWQ/ mR3I1QA9kTJ0JCHmwl4faUzQeD3MbYJifShcWlu7LuoUfx9IFkQqjELX24Q7G+TF251N VXnm0V9S0d2bWmQbNRnQaMqZ6VwamSVzqoKFxKVM6NGGzhl5rTOFLvyuV1ThzhTR5SUg qhBzjqfyekL/R3I3Td14nE3qHJwZzq+UY4nEYmq1OwkFS3IvL2MwY4AHbwW/lxiSDZAX pgtg== X-Gm-Message-State: AOAM530h2yEraeqD2wZ/mlWtOHYb5pOe2psEdTTA2DDDdSlqGgbNB5uZ V2uyPkC4wFY/W9Q33X3nosilWYQZVSk6xU6waAhNbQ== X-Google-Smtp-Source: ABdhPJxcg4MrRu1fN964lAULW/9s0z0on4oqs5LLgTVwmynfuyARGIaAyWA515abwFXy/VI4w283vjNhvqn5DP6Z3vc= X-Received: by 2002:adf:a310:: with SMTP id c16mr9311820wrb.319.1633053235620; Thu, 30 Sep 2021 18:53:55 -0700 (PDT) MIME-Version: 1.0 References: <0B533C71-5DB0-410D-A5A3-7E8FD559F214@delong.com> <5FAD5290-3616-4194-B783-D473DB38A89A@delong.com> <1e9444b30d964a5cb17ff419eca6cc35@huawei.com> <08D2885E-B824-48E8-9703-DCA98771FA37@delong.com> In-Reply-To: <08D2885E-B824-48E8-9703-DCA98771FA37@delong.com> From: Lorenzo Colitti Date: Fri, 1 Oct 2021 10:53:42 +0900 Message-ID: To: Owen DeLong Cc: Owen DeLong , v6ops list Content-Type: multipart/alternative; boundary="00000000000002aeaf05cd40d6ed" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 01:54:03 -0000 --00000000000002aeaf05cd40d6ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 1, 2021 at 9:35 AM Owen DeLong wrote: > That=E2=80=99s not what is being said. A lot of this has little to do wit= h what > they are accustomed to and a lot more to do with a combination of: > + Enterprise policies that they cannot conveniently change > + Government and other regulations that they cannot avoid > + Reporting requirements that they cannot subvert > + Limitations of the tools they have available to comply with the above. > etc. > Ok, but many of these points can be addressed in other ways: - For reporting: many vendor platforms support ND binding logging via syslog, and something like draft-ietf-dhc-addr-registration would likely make it much easier for networks that use DHCPv6 only for tracking/forensics (vs. for access control) to move away from IA_NA. Specifically, it would satisfy the reporting requirements and make it a = lot easier for the tools to adapt because it's still using the DHCPv6 protoc= ol. - Enterprise policies and government regulations are not written in a vacuum, they're written to address business and legal requirements, and = I really don't think you can credibly claim that DHCPv6 is a business or legal requirement. The legal requirements are things like tracking, acce= ss control, etc. > In other words, you keep trying to suggest that there are alternative > technical solutions, but you ignore the fact that this is NOT a technical > problem. > Actually what I'm saying is that we (the IETF) *do* have a technical problem, regardless of the status of implementations, which the IETF doesn't have much of a say in anyway. The problem is: there is no IETF consensus that "IA_NA with one address per device" is a good technical solution. So: why aren't we looking for a way that's better for everyone involved (users, implementers, operators)? Even if you're 100% convinced that utimately all platforms will implement IA_NA with one address per device, isn't it a better outcome if that model is limited to a few networks, and networks with less stringent requirements or less dogmatic operators can use a technically better solution that we come up with in the meantime? Of course, there may still remain network operators that say, "my network, my rules; my one IA_NA way or the highway". But if your main concern is accelerating IPv6 adoption, then if we come up with a solution that's not IA_NA and satifies some (even if not all) enterprise requirements, then that's pretty likely to help adoption of IPv6 in enterprises that have a real business need for IPv6. --00000000000002aeaf05cd40d6ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 1, 2021 at 9:35 AM Owen DeLong <owen=3D40delong.com@dmarc.ietf.org> wrote:=
That=E2=80=99s not what is being said. A lot of = this has little to do with what they are accustomed to and a lot more to do= with a combination of:
+<= span style=3D"white-space:pre-wrap"> Enterprise policies that they c= annot conveniently change
<= /span>+ Government and other re= gulations that they cannot avoid
+ Reporting requir= ements that they cannot subvert
+ Limitations of th= e tools they have available to comply with the above.
etc.
<= /div>

Ok, but many of these points can be a= ddressed in other ways:
  • For reporting: many vendor pl= atforms support ND binding logging via syslog, and something like draft-ietf-dhc-addr-registration would likely make it mu= ch easier for networks that use DHCPv6 only for tracking/forensics (vs. for= access control) to move away from IA_NA. Specifically, it would satisfy th= e reporting requirements and make it a lot easier for the tools to adapt be= cause it's still using the DHCPv6 protocol.
  • Enterprise policies= and government regulations are not written in a vacuum, they're writte= n to address business and legal requirements, and I really don't think = you can credibly claim that DHCPv6 is a business or legal requirement. The = legal requirements are things like tracking, access control, etc.
=
=C2=A0
In other words, you= keep trying to suggest that there are alternative technical solutions, but= you ignore the fact that this is NOT a technical problem.

Actually what I'm saying is that we (the IE= TF) do have a technical problem, regardless of the status of impleme= ntations, which the IETF doesn't have much of a say in anyway. The prob= lem is: there is no IETF consensus that "IA_NA with one address per de= vice" is a good technical solution. So: why aren't we looking for = a way that's better for everyone involved (users, implementers, operato= rs)? Even if you're 100% convinced that utimately all platforms will im= plement IA_NA with one address per device, isn't it a better outcome if= that model is limited to a few networks, and networks with less stringent = requirements or less dogmatic operators can use a technically better soluti= on that we come up with in the meantime?

Of course= , there may still remain network operators that say, "my network, my r= ules; my one IA_NA way or the highway". But if your main concern is ac= celerating IPv6 adoption, then if we come up with a solution that's not= IA_NA and satifies some (even if not all) enterprise requirements, then th= at's pretty likely to help adoption of IPv6 in enterprises that have a = real business need for IPv6.
--00000000000002aeaf05cd40d6ed--