Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

"Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com> Tue, 02 March 2021 14:22 UTC

Return-Path: <liguangpeng@huawei.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6883A18D5; Tue, 2 Mar 2021 06:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 JBFeTXVCe3pf; Tue, 2 Mar 2021 06:22:12 -0800 (PST)
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 0B3203A18D3; Tue, 2 Mar 2021 06:22:12 -0800 (PST)
Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DqfNj3F98z67tyD; Tue, 2 Mar 2021 22:17:57 +0800 (CST)
Received: from fraeml738-chm.china.huawei.com (10.206.15.219) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 2 Mar 2021 15:22:09 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Tue, 2 Mar 2021 15:22:09 +0100
Received: from DGGEMM513-MBS.china.huawei.com ([169.254.4.30]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0509.000; Tue, 2 Mar 2021 22:21:57 +0800
From: "Liguangpeng (Roc, Network Technology Laboratory)" <liguangpeng@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, Toerless Eckert <tte@cs.fau.de>
CC: Jiayihao <jiayihao@huawei.com>, "draft-jia-scenarios-flexible-address-structure@ietf.org" <draft-jia-scenarios-flexible-address-structure@ietf.org>, int-area <int-area@ietf.org>, "draft-jia-flex-ip-address-structure@ietf.org" <draft-jia-flex-ip-address-structure@ietf.org>
Thread-Topic: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
Thread-Index: AQHW/f5QAnbTPo1JcUmifgJ+1NT5hapNixgAgCFTIQCAAXZzAIAAiWDg
Date: Tue, 02 Mar 2021 14:21:56 +0000
Message-ID: <6F4E6B0C717D4641A2B79BC1740D8CF4A902DD90@dggemm513-mbs.china.huawei.com>
References: <CDB32FF0-5CE0-4C0F-B1D1-B6BFEA42E817@gmail.com> <3dd5a712bd2b4fdbb882d860ab2ece82@huawei.com> <7A6DB0D7-A2A3-4995-A6D9-ABDFF4F7879B@gmail.com> <20210301153259.GB11539@faui48f.informatik.uni-erlangen.de> <554E7FC1-0146-4AEF-B84C-805B51013180@gmail.com>
In-Reply-To: <554E7FC1-0146-4AEF-B84C-805B51013180@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.19.55]
Content-Type: multipart/alternative; boundary="_000_6F4E6B0C717D4641A2B79BC1740D8CF4A902DD90dggemm513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/iI_U_dRdb3jzVDDcOh_SfzZAuOc>
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 14:22:14 -0000

Hi Stewart,

Backwards compatible should be always good thing for investment protection. Except “could put your new packet into a IPv6 parser”, another possible approach is the last new forwarder translate new packet to IPv6 packet (may encapsulate new fields in extension header), and passthrough in IPv6 domain. Then the first new forwarder adjacent to IPv6 forwarder must recognize IPv6 encapsulation and traversing all extension headers to form new packets if next hop is new forwarder.

Guangpeng Li

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Tuesday, March 2, 2021 9:53 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; Jiayihao <jiayihao@huawei.com>; draft-jia-scenarios-flexible-address-structure@ietf.org; int-area <int-area@ietf.org>; draft-jia-flex-ip-address-structure@ietf.org
Subject: Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses




On 1 Mar 2021, at 15:33, Toerless Eckert <tte@cs.fau.de<mailto:tte@cs.fau.de>> wrote:

I really don't understand why the IPv6 world has not understood how the most easy way
to allow for the applicability of IPv6 to grow (especially beyond "just more addresses thn IPv4")
would be to come up with a backward compatible encap on the wire that would support additional
address lengths.

Toerless

I don’t think there is a simple backwards compatible approach, but we can probably do more than we do today.

Backwards compatible means that you could put your new packet into a IPv6 parser and it would correctly forward the packet as if nothing had changed.

You could I suppose put a well known IPv6 address in the IPv6 header and put the real address in an extension header, perhaps including the pointer to the address in the suffix of the IPv6 address to make finding the EH much faster, but I am not sure that is backwards compatible.

I suppose it might be able to do a bit better if the address in the IPv6 DA was the DA of the egress router and old routers did best effort to the egress and newer routers knew to take a look at the extension header for more detail.

I think that it is worth thinking about how we could do better than we do today, but I think we need to be careful with the term backwards compatible.

- Stewart