RE: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Fri, 12 July 2019 02:19 UTC
Return-Path: <pengshuping@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 440DC1200C7 for <ipv6@ietfa.amsl.com>; Thu, 11 Jul 2019 19:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 TPDIu-feyEeD for <ipv6@ietfa.amsl.com>; Thu, 11 Jul 2019 19:19:35 -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 CF535120020 for <ipv6@ietf.org>; Thu, 11 Jul 2019 19:19:34 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5A60E86AE998E341EFF1; Fri, 12 Jul 2019 03:19:32 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Jul 2019 03:19:32 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 12 Jul 2019 03:19:31 +0100
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 12 Jul 2019 03:19:30 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.81]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 10:19:22 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "C. M. Heard" <heard@pobox.com>
CC: Mark Smith <markzzzsmith@gmail.com>, 6man WG <ipv6@ietf.org>, Lizhenbin <lizhenbin@huawei.com>
Subject: RE: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
Thread-Topic: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
Thread-Index: AQHVNtWJ9VJynMEzNkOxlpH2YeiDrabDxMsw//+I2ACAAIl0oP//mTWAgALMYvA=
Date: Fri, 12 Jul 2019 02:19:22 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE14846974@dggeml512-mbx.china.huawei.com>
References: <CACL_3VGP4-kmyJGo1Gxea7HhcKY3P3EGHwgmcYxCGLnjPh-YCg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE148446F8@dggeml512-mbx.china.huawei.com> <CAO42Z2wJR_fssOwLnz_1s=Cz-L3azvXE3tWSB+4YHT9q-QEv8Q@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE148447E9@dggeml512-mbx.china.huawei.com> <CACL_3VF3L89uRuCQY_GO6HJm=r0JVWBvZzma-RNmM3s7rqy3pQ@mail.gmail.com>
In-Reply-To: <CACL_3VF3L89uRuCQY_GO6HJm=r0JVWBvZzma-RNmM3s7rqy3pQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.169.124]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE14846974dggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/7uJtCd5i62rUVr0sNn8XIWy63y8>
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: Fri, 12 Jul 2019 02:19:38 -0000
From: C. M. Heard [mailto:heard@pobox.com] Sent: Wednesday, July 10, 2019 11:14 PM To: Pengshuping (Peng Shuping) <pengshuping@huawei.com> Cc: Mark Smith <markzzzsmith@gmail.com>; 6man WG <ipv6@ietf.org>; Lizhenbin <lizhenbin@huawei.com> Subject: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1 On Wed, Jul 10, 2019 at 6:38 AM Pengshuping (Peng Shuping) wrote: > Take the IOAM as an example, the action needs to be performed hop by > hop along the path. However, when some routers along the path enable > the processing of the HBH but others just ignore it. Then the IOAM > service fails. Therefore, the enforcement of the processing of the > HBH according to the service requirements would be required in the > procedure wise. So what you want is a Hop-by-Hop Options header that all nodes along the path must process. As Mark pointed out, we've been down that road before: both RFC 2460 Section 4.3<https://tools.ietf.org/html/rfc2460#section-4.3> and RFC 1883 Section 4.3<https://tools.ietf.org/html/rfc1883#section-4.3> (its predecessor) contained the following text. The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. In the 2+ decades following the publication of RFC 1883 that idea never caught on, That's why RFC 8200 Section 4 added the note NOTE: While [RFC2460<https://tools.ietf.org/html/rfc2460>] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so. and why RFC 8200 Section 4.3<https://tools.ietf.org/html/rfc8200#section-4.3> now says The Hop-by-Hop Options header is used to carry optional information that may be examined and processed by every node along a packet's delivery path. Based on the decades of experience, it's fair to say that the true hop-by-hop behavior as needed for IOAM to work cannot be expected in the general Internet. Putting the Hop-by-Hop Options header in a new Next Header type will not magically change that. It will, however, cause backward compatibility problems in end systems, because they will see an unknown Next Header type and drop the packet (see RFC 8200 Section 4<https://tools.ietf.org/html/rfc8200#section-4>): If, as a result of processing a header, the destination node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. The best that can be expected is that true hop-by-hop behavior, as required for IOAM to work as desired, can be made to work in a controlled environment (aka limited domain) wherein every router is able to process the Hop-by-Hop Options header at wire speed and has been configured to do so. A new Next Header type is not needed to accomplish that. [Shuping] The configuration you propose here will be effective to all the options contained in the HBH Options header. However, there are multiple different options in the HBH Options header, which usually require different processing procedures, e.g. being assigned to the slow path or processed at wire speed. The way to differentiate the treatments to those options is currently missing. We could do engineering at each option to indicate every router how to treat it. However, that will not be very efficient since each option type needs to be gone through and checked against the preset configuration. Mike Heard
- Comments on draft-li-6man-enhanced-extension-head… C. M. Heard
- 答复: Comments on draft-li-6man-enhanced-extension-… Pengshuping (Peng Shuping)
- Re: Comments on draft-li-6man-enhanced-extension-… Mark Smith
- 答复: Comments on draft-li-6man-enhanced-extension-… Pengshuping (Peng Shuping)
- Re: Comments on draft-li-6man-enhanced-extension-… C. M. Heard
- RE: Comments on draft-li-6man-enhanced-extension-… Tianran Zhou
- RE: Comments on draft-li-6man-enhanced-extension-… Pengshuping (Peng Shuping)
- Re: Comments on draft-li-6man-enhanced-extension-… C. M. Heard
- RE: Comments on draft-li-6man-enhanced-extension-… Pengshuping (Peng Shuping)
- Re: Comments on draft-li-6man-enhanced-extension-… C. M. Heard
- Re: Comments on draft-li-6man-enhanced-extension-… Brian E Carpenter
- Re: Comments on draft-li-6man-enhanced-extension-… C. M. Heard
- Re: Comments on draft-li-6man-enhanced-extension-… Mark Smith