Re: [v6ops] Implementation Status of PREF64

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 14 October 2021 08:48 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 BBB343A1001 for <v6ops@ietfa.amsl.com>; Thu, 14 Oct 2021 01:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 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, T_KAM_HTML_FONT_INVALID=0.01, 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 FFLAxmSKUgZn for <v6ops@ietfa.amsl.com>; Thu, 14 Oct 2021 01:48:23 -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 ADC023A1019 for <v6ops@ietf.org>; Thu, 14 Oct 2021 01:48:22 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HVNJb1ZB0z686pl for <v6ops@ietf.org>; Thu, 14 Oct 2021 16:45:19 +0800 (CST)
Received: from mscpeml100002.china.huawei.com (7.188.26.75) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 14 Oct 2021 10:48:14 +0200
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100002.china.huawei.com (7.188.26.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 14 Oct 2021 11:48:14 +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, 14 Oct 2021 11:48:14 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>, "Owen DeLong" <owen=40delong.com@dmarc.ietf.org>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Implementation Status of PREF64
Thread-Index: AQHXsWiabe9xT98knEyNpn/SXFCzFauzkUkAgABK7ICAAEb8gIAACf0AgAH4SoCAAgvogIAAROwAgAA+dACAAPFksIAAN4ew///cF4CAADh0D///620AgAE/qoCAAEymgIAAQtEAgACFcMD//87gAAADB2KAAAEo1YAAAgTGgAAMC1mAABEnE4AAAOBpgAACvIEAAAREQQAAAJLtAAACLxgAAAE9/QABFvNJgAAZYOiAAAkzk4AAA/ImAACtxS+AAAbwXgAAAidYAAADWgIAABSGmYAAAHeBgAAaBUUAAAd1uwAAD0J9AAABvnEAAAcNDAL//89sAIAAMC+AgAFlPICAAAegAIAALYYA//76mbA=
Date: Thu, 14 Oct 2021 08:48:14 +0000
Message-ID: <6fa669448c5543379a70bddd2b684dc0@huawei.com>
References: <CAKD1Yr10OKMJ1y8bs5xpt6jS8ZWsqs66oFCXmp-QLySS5Yn4hg@mail.gmail.com> <5DF8D1AE-4B54-429F-962A-488F2AA1F895@delong.com> <CAPt1N1ma45GKqXcvjHUGCYFKVbEGp3OuT013pZhrnOkFFLMiQA@mail.gmail.com> <CAKD1Yr2Pe+=tNkA7Ou9KeMkgFhcdSb8WxgVn1w9MauusMEhRcw@mail.gmail.com> <CO1PR11MB4881076DFF8A145C8CD818B8D8B69@CO1PR11MB4881.namprd11.prod.outlook.com> <A188D974-3CEB-497F-93EA-B66C77D2CA90@delong.com> <YWW1ghmjueHmfCEb@Space.Net> <m1maKp6-0000I3C@stereo.hq.phicoh.net> <YWW8FPkRuxCBFp3o@Space.Net> <D0510DEB-04FF-4864-9363-6FC40C686C22@delong.com> <YWcQKwK3lAKpl7y1@Space.Net> <DFD526B0-7CA3-4445-910F-425142C0AEDA@delong.com> <802A4F47-5DB0-4986-894D-2B20BA09FF24@cisco.com>
In-Reply-To: <802A4F47-5DB0-4986-894D-2B20BA09FF24@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.203.183]
Content-Type: multipart/alternative; boundary="_000_6fa669448c5543379a70bddd2b684dc0huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kzEnBLY9x4Vd3t8bRVaP5C-o3-4>
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, 14 Oct 2021 08:48:27 -0000

Ø  Why insist on /64 per host?

Well, it depends on what is the host? If it has 300 containers inside then maybe it is less wastage of address space than to give /64 to a household.

Ø  Seems to me that the properties that we want do not depend much on where we cut.

Yes, /64 boundary for any subnet look artificial.

Ed/

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, October 13, 2021 11:09 PM
To: Owen DeLong <owen=40delong.com@dmarc.ietf.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Implementation Status of PREF64



Hello Owen



The thing of the past is probably still perfect in some unmanaged networks but I understand that your focus is not those.



/64 came with neatly with EUI 64 as you point out, and we are deprecating that for privacy.



Switching better than routing in the domain we call a subnet is also becoming obsolete since even when we think we switch we probably route at L2 or in an underlay.



Bottom line is that /64 is still an interesting boundary for backward compatibility and old habits to form a group we call a subnet. But I agree with Gert that we do not need to give that much to every host just to be able to route inside the subnet at L2.



We can easily route to /112 or even to /128. I’m used to the latter because we build subnets of thousands of nodes in IoT and we know the nodes from a registrar, typically DHCPv6. But I see benefits of giving a prefix to the phone or the PC and let it distribute the addresses to stuff like VMs and tethered nodes.



Why insist on /64 per host? Seems to me that the properties that we want do not depend much on where we cut.



What’s really interesting is to decouple the domain we decide is a subnet from a L2 broadcast domain and from what we see as an IP link. For that you need L3 routing inside the subnet. The /(>100) per host gives you all that.





Regards,



Pascal



> Le 13 oct. 2021 à 19:26, Owen DeLong <owen=40delong.com@dmarc.ietf.org<mailto:owen=40delong.com@dmarc.ietf.org>> a écrit :

>

> 

>

>> On Oct 13, 2021, at 09:58 , Gert Doering <gert@space.net<mailto:gert@space.net>> wrote:

>>

>> Hi,

>>

>> On Tue, Oct 12, 2021 at 12:39:43PM -0700, Owen DeLong wrote:

>>>> (ceterum censeo, /64 was not a very smart decision)

>>> We can agree to disagree. So far, I???ve seen no data to support that.

>>

>> Indeed.

>>

>> So far I have not seen any data that supports "/64 was a good idea"

>> :-)

>

> It’s working quite well in a number of networks I’ve deployed.

>

> It’s convenient for EUI-64 addressing.

>

> Reviewing the record, it seems we were destined for something like

> 64-bit addressing overall before IETF decided to consider EUI-64

> addressing and added 64-bits to the plan, so one can argue that

> without the idea of universal /64 addressing we’d have a whole lot

> fewer network numbers available.

>

> So now you have seen data to suggest that /64 was a good idea.

>

> Do you have any data support your claim that /64 was not?

>

> Owen

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org<mailto:v6ops@ietf.org>

> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________

v6ops mailing list

v6ops@ietf.org<mailto:v6ops@ietf.org>

https://www.ietf.org/mailman/listinfo/v6ops