Re: [v6ops] Flash renumbering

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 16 September 2020 17:32 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 906313A1015; Wed, 16 Sep 2020 10:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 f6IXTLvTLDgg; Wed, 16 Sep 2020 10:32:55 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8D73A0FF7; Wed, 16 Sep 2020 10:32:55 -0700 (PDT)
Received: from lhreml708-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BDD5F6EA1F72CA9EA00E; Wed, 16 Sep 2020 18:32:49 +0100 (IST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Wed, 16 Sep 2020 18:32:49 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 16 Sep 2020 20:32:48 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 16 Sep 2020 20:32:48 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: Flash renumbering
Thread-Index: AdaLlIyewLCjExjqRk+nNQVH29wmCwAZTZ2AAAeQHED//+sRgP//ntdggACj4YD//8DoUA==
Date: Wed, 16 Sep 2020 17:32:48 +0000
Message-ID: <82df400c0e2840e1aef309211c5f1c92@huawei.com>
References: <8f964b8650cd4b619ff47aed5b07bc67@huawei.com> <7ee317a3-05b7-0c78-0abf-47075839223e@si6networks.com> <3c220cce7c834d50a09784923cb40910@huawei.com> <f93a1cc9-d310-4c88-4a33-a749785c72be@si6networks.com> <a03794fb2d514389b33222f0b3e194c2@huawei.com> <17401cd6-e337-4a51-e3b6-6e02978f9c1b@si6networks.com>
In-Reply-To: <17401cd6-e337-4a51-e3b6-6e02978f9c1b@si6networks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.196.47]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ZfIoLhN7n-Glmp6ZpiOYoRciaT4>
Subject: Re: [v6ops] Flash renumbering
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: Wed, 16 Sep 2020 17:32:58 -0000

> All these things expose a stituation that is not robust. You are essentially arguing for brokenness.
Partially agree. Better to fix.

>> 30% is the probability that residential subs have IPv6 (in reality less, 30% is mainly attributed by mobile)
>Where do you get this numbers from?
Many open sources: Google, APNIC (most accurate, Huston behind it), Akamai. Results are very comparable.

>> 5% that he has 2 boxes in the household (reminder: relationships between number of businesses to households is about 2% for majority of countries, number of branches for big Enterprise could be big (+), but many SMBs would be satisfied by typical CPE(-))
> Again where do you get this "5%". Do you just make it up?
Yes, I have increased 2% for business (that is possible to prove) to something bigger. The error here is not principal for our discussion.

>> 50% that he is not capable to create routed network inside (/64 from Carrier - now should be less such cases compare to 2017).
>Same here. WHere do you get these numbers for. Besides, in many cases, you *don't want* to have a subneted local network.
I have shown you statistic below - it was 2017 before strong push from RIPE for /56->/48. It should be more /56 now.

>> I do not know mDNS - may be it needs bridged network. It would be additional extremely small corner case (10^-5).
> huh? Most people access their home devices with technologies such as  mDNS and LLMNR, which operate on a single segment. Because they are plug  and ply without the need to set up a name server, or anything.
Most here means "most geeks" - it is much smaller portion then 0.3%

Ed/
-----Original Message-----
From: Fernando Gont [mailto:fgont@si6networks.com] 
Sent: 16 сентября 2020 г. 19:40
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; 6man@ietf.org; IPv6 Operations <v6ops@ietf.org>
Subject: Re: Flash renumbering

On 16/9/20 12:55, Vasilenko Eduard wrote:
> Hi Fernando,
> I do not believe that other cases are representative except many-box solution.
> Because all other cases are: somebody forgotten to deprecate prefix in his software (including VM - just need to send at least one RA before prefix change).

All these things expose a stituation that is not robust. You are essentially arguing for brokenness.


> It was better to push Industry to properly develop software to deprecate prefixes, then to compromise timers.

What do you mean by "compromise timers"?



> For the multi-box scenario:
> 30% is the probability that residential subs have IPv6 (in reality less, 30% is mainly attributed by mobile)

Where do you get this numbers from?


> 37% that his Carrier do dynamic DHCP-PD
> 5% that he has 2 boxes in the household (reminder: relationships between number of businesses to households is about 2% for majority of countries, number of branches for big Enterprise could be big (+), but many SMBs would be satisfied by typical CPE(-))

Again where do you get this "5%". Do you just make it up?


And, anyway, the possibility is irrelevant. I don't think I need to 
point out that the use of range extenders and the like are not unusual. 
THat kind of thing works pretty well with IPv4, and could be very broken 
with IPv6.



> 50% that he is not capable to create routed network inside (/64 from Carrier - now should be less such cases compare to 2017).

Same here. WHere do you get these numbers for. Besides, in many cases, 
you *don't want* to have a subneted local network.


[...]
> In response to "why IP camera needs bridged network" you have answered "to avoid NAT".
> We are in IPv6 alias. Whatever you would do in IPv6 - you will avoid NAT. Hence, Routed network inside household is not a problem for IP camera. Right?

A subneted network breaks mDNS.



> I do not know mDNS - may be it needs bridged network. It would be additional extremely small corner case (10^-5).

huh? Most people access their home devices with technologies such as 
mDNS and LLMNR, which operate on a single segment. Because they are plug 
and ply without the need to set up a name server, or anything.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492