Re: [v6ops] Implementation Status of PREF64

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 30 September 2021 10:04 UTC

Return-Path: <vasilenko.eduard@huawei.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 BF9573A0A85 for <v6ops@ietfa.amsl.com>; Thu, 30 Sep 2021 03:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 051ht95xK4TW for <v6ops@ietfa.amsl.com>; Thu, 30 Sep 2021 03:03:53 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A1F3A0A6D for <v6ops@ietf.org>; Thu, 30 Sep 2021 03:03:52 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HKpfG6Mx0z67wqH; Thu, 30 Sep 2021 18:00:54 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 30 Sep 2021 12:03:48 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 30 Sep 2021 13:03:47 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.008; Thu, 30 Sep 2021 13:03:47 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: David Farmer <farmer=40umn.edu@dmarc.ietf.org>, Mark Smith <markzzzsmith@gmail.com>, v6ops list <v6ops@ietf.org>
Thread-Topic: [v6ops] Implementation Status of PREF64
Thread-Index: AQHXsWiabe9xT98knEyNpn/SXFCzFauzkUkAgABK7ICAAEb8gIAACf0AgAH4SoCAAgvogIAAROwAgAA+dACAAPFksIAAN4ew///cF4CAADh0D///620AgAE/qoCAAEymgIAAQtEAgACFcMD//87gAAALvGDw
Date: Thu, 30 Sep 2021 10:03:47 +0000
Message-ID: <f6f4e6e31b2148ff86319133ef60196f@huawei.com>
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>
In-Reply-To: <CAKD1Yr0T-7t-UHbsJBMLpTjKhPAV5uUQkux6oby89TVUue7PyA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.238]
Content-Type: multipart/related; boundary="_004_f6f4e6e31b2148ff86319133ef60196fhuaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_Ug2sG2NzwlgnCrQTzuG2nylYmI>
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 10:04:06 -0000

Hi Lorenzo,
Sorry, but this URL has no reference to the product or OpenSource that is capable to collect ND logs from the wide range of routers (multi-vendor!), correlate them, and present them for forensic, billing, or troubleshooting purposes.
No one vendor or developer of OpenSource spends resources behind your idea.
What you propose is just not possible to implement in production now.
Why these people do not believe you?
[cid:image002.jpg@01D7B5FB.E353D5E0]
You would not go anywhere with your idea if you would not persuade them (especially Infoblox as the leader).
The first question that they would have to you may be: show me the YANG model to provision boxes and show me the data model for statistics that they would generate?
Ups, it is proprietary for all vendors…

IMHO: no chance that your idea would fly if it would not have any DDI product that supports it.
Eduard
From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Thursday, September 30, 2021 10:17 AM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: David Farmer <farmer=40umn.edu@dmarc.ietf.org>; Mark Smith <markzzzsmith@gmail.com>; v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] Implementation Status of PREF64

There are already vendor solutions.

https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/

On Thu, Sep 30, 2021 at 4:12 PM Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
+1.
“Show me another solution” is a good message. Just idea or theory is not enough.
David has mentioned OpenSource. I would say that vendor product is needed too.
Ed/
From: v6ops [mailto:v6ops-bounces@ietf.org<mailto:v6ops-bounces@ietf.org>] On Behalf Of David Farmer
Sent: Thursday, September 30, 2021 5:15 AM
To: Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>>; Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: v6ops list <v6ops@ietf.org<mailto:v6ops@ietf.org>>
Subject: Re: [v6ops] Implementation Status of PREF64


On Wed, Sep 29, 2021 at 5:16 PM Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>> wrote:

On Thu, 30 Sep 2021, 03:41 Nick Hilliard, <nick@foobar.org<mailto:nick@foobar.org>> wrote:

Even if you had, that would be fine and you're welcome to your opinions.
  Other people disagree because it doesn't make sense on their deployments.

If they want to hobble IPv6, such that it is nothing more than a copy of IPv4 with bigger addresses, what is the point of going to the expense and effort of deploying IPv6 when most enterprises have plenty of IPv4 address space via RFC1918 and 100.64/10 if they were willing to abuse it a bit?

A hobbled deployment of IPv6, hobbled such that it doesn't provide any useful benefit over IPv4, is just pure business expense. Increased profit is an exceptionally strong disincentive to incurring those.

So, instead of just telling people they are doing IPv6 wrong (building a hobbled network) and that DHCP doesn't provide them what they think it does; How about making sure there are good open-source tools to build what you think is a non-hobbled network that meets their needs? In other words, how about providing some good open-source ARP and ND router scraping tools?

Now you could point the finger back at me too, but then I'm not saying that building networks with DHCPv6 is building a hobbled network, nor am I refusing to provide a DHCPv6 client for a very popular mobile and IoT platform. So, at least in my opinion, that puts more onus on you than me.

So, I agree that DHCP logging (both IPv4 and IPv6) by itself isn't enough, and yes you also need to scrape ARP and ND out of the routers. However, ARP and ND scrapping by themselves aren't enough either, DHCP logging provides much better granularity than is practical from ARP and ND scrapping, at least using SNMP. Also, by having both you can make some assumptions about suspicious access clients that are statically configuring addresses instead of doing DHCP on the access network as they should be.

I agree that limiting DHCPv6 clients to only IA-NA  and not providing IA-TA is a bad implementation of DHCPv6. Further, I recommend SLAAC, and we provide SLAAC, for general-purpose (AKA public) access networks with IPv6. But, we also have many networks where that is not appropriate, where I have regulatory and contractual compliance requirements, to protect non-public information, things like FERPA, HIPPA, PCI, and CMMC(1-4). Long-term we want these networks doing IPv6 too.

Android smartphones, probably belong on a general-purpose access network with SLAAC for IPv6 in most cases. However, Android is also on many IoT devices, things like point-of-sale terminals, credit card terminals, environmental monitoring sensors, etc... Many of those things I don't want on general-purpose access networks and some of those will have compliance requirements we have to meet. We think DHCPv6 is perfectly appropriate for these networks, and probably for server networks too.

In conclusion, while I agree with most of your arguments that DHCPv6 isn't necessarily the right way to do IPv6, especially for general-purpose (public) access networks, that doesn’t mean I think DHCPv6 doesn’t have a place in many other networks, and it would be very helpful if Android provided a DHCPv6 client, even as a non-default option.

Thanks


--
===============================================
David Farmer               Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================