IETF Logo Mail Archive

RE: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Mon, 25 May 2020 09:08 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2403A07D0 for <ipv6@ietfa.amsl.com>; Mon, 25 May 2020 02:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 dS683KvwzVJo for <ipv6@ietfa.amsl.com>; Mon, 25 May 2020 02:08:37 -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 10F743A07CE for <6man@ietf.org>; Mon, 25 May 2020 02:08:37 -0700 (PDT)
Received: from lhreml706-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C4B5B176918AA99074A9; Mon, 25 May 2020 10:08:35 +0100 (IST)
Received: from nkgeml708-chm.china.huawei.com (10.98.57.160) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 25 May 2020 10:08:35 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml708-chm.china.huawei.com (10.98.57.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 25 May 2020 17:08:32 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Mon, 25 May 2020 17:08:32 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6MAN <6man@ietf.org>
Subject: RE: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
Thread-Topic: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03
Thread-Index: AQHWI0N8oI/8MsBlk0uecDFDr3XEgai3UJYAgAEJwPD//5AWAIAAtJmA
Date: Mon, 25 May 2020 09:08:32 +0000
Message-ID: <efb80a5d51074ed2a509e75ece596282@huawei.com>
References: <CAJE_bqcR8gg6c4c=4sU8zfs5B0gaT4AFtKrbq9o2CFw_Yo4qvA@mail.gmail.com> <fd375263-2b3a-f20d-cf51-d5f39a62c5bf@gmail.com> <69f92d989fca4a7bb3117d6afa84eade@huawei.com> <c14bb0d4-e1a8-2d67-3c36-8657f94ca553@gont.com.ar>
In-Reply-To: <c14bb0d4-e1a8-2d67-3c36-8657f94ca553@gont.com.ar>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
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/ipv6/kKQMHH3HxtuMUNlz7F0s_CDfeuc>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2020 09:08:40 -0000

Hi Fernando,

It is not surprise to me that, the multicast address could be used as "non-final/non-ultimate destination" in IPv6-EH mechanism.

We could go back to the day when "multicast address" was first invented/introduced by Dr. Steve Deering (also a co-author of 1883/2460), firstly in RFC966, then 988, then 1112:
https://mailarchive.ietf.org/arch/msg/ipv6/gnp6W6QSuo_jMelU6jJys7wxcrU/

and Let's imagine:
(1) in IPv4, a packet using Multicast address as destination address, and there is some "Option" in IP header.
(2) in IPv6, a packet using Multicast address as destination address, and there is some "Option" in IP header.

Thanks
Jingrong

-----Original Message-----
From: Fernando Gont [mailto:fernando@gont.com.ar] 
Sent: Monday, May 25, 2020 2:13 PM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; 6MAN <6man@ietf.org>
Subject: Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03

On 25/5/20 01:56, Xiejingrong (Jingrong) wrote:
> Hi Brian,
> 
> Maybe the more you assume "Destination node" as "final/ultimate destination node", the more you will be confusing.
> To me, "Destination node" is very simple to mean "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field".

Ironically, it would be quite interesting to have a multicast address as a "Destination Node", unless "Destination Node" implies final destination.

(note: rfc2460 banned both cases for RHT0)

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

v2.23.0 | Report a Bug | By Email