Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
"C. M. Heard" <heard@pobox.com> Wed, 10 July 2019 15:13 UTC
Return-Path: <heard@pobox.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 27C27120118 for <ipv6@ietfa.amsl.com>; Wed, 10 Jul 2019 08:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
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 DmmxnTdIS-S1 for <ipv6@ietfa.amsl.com>; Wed, 10 Jul 2019 08:13:49 -0700 (PDT)
Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69EBD1203AB for <ipv6@ietf.org>; Wed, 10 Jul 2019 08:13:49 -0700 (PDT)
Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id DF40F167F83 for <ipv6@ietf.org>; Wed, 10 Jul 2019 11:13:46 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=Hg+SjJRMvwYi1Y7PYJs5SN+R9Dc=; b=pK5zY3 OdL0lCE+5CCFZkcJMJpVLebojsXKKWqbwlsRhpoGbPy5cKUP1WtIvK5vAiP9LDpD TYxtgSqZfVerOLb2DWCbDjrZsis+vQ9i/MpA8tTm4tpay1wsgt/8bE2/Dwm9i1wf CsEBD4LvxuhteWXUwxQrJMfkv4PjKtaxgZYdw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=rY7ghsEYIFJ/vFaHUMwhuwFh2xt93r2e EXPboOLxCOlEQ5W3etl8I9CAtKUtIl9btf56Wojg4ep7J3KdAbieESGBIWe/apgs pZK9toTNyahhWNlAJRb8LJdmbLq64NgO3ebPBwWdl/CvfaPYhKKl9qVAm1HSCj+d +Jk/lA0qa8c=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id D7E07167F81 for <ipv6@ietf.org>; Wed, 10 Jul 2019 11:13:46 -0400 (EDT)
Received: from mail-io1-f51.google.com (unknown [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 25015167F7C for <ipv6@ietf.org>; Wed, 10 Jul 2019 11:13:46 -0400 (EDT)
Received: by mail-io1-f51.google.com with SMTP id k8so5548819iot.1 for <ipv6@ietf.org>; Wed, 10 Jul 2019 08:13:46 -0700 (PDT)
X-Gm-Message-State: APjAAAUIajMx3lBL2MyN+CqlHeMHjZwmqWJOBtsl3H/KYBJUO64wltre yW2dbqct9o5DWa06n/I8EHvG/hAGCGW3BOs97qw=
X-Google-Smtp-Source: APXvYqxDHHp7PtPWpq42NEeLhbYb577AQblfcDP7p9M5jjygrY5dUAhkzT8UmuIdeFete4aUCIvR0WEt141dt4gJ66A=
X-Received: by 2002:a5d:8905:: with SMTP id b5mr33402293ion.291.1562771625583; Wed, 10 Jul 2019 08:13:45 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <4278D47A901B3041A737953BAA078ADE148447E9@dggeml512-mbx.china.huawei.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Wed, 10 Jul 2019 08:13:33 -0700
X-Gmail-Original-Message-ID: <CACL_3VF3L89uRuCQY_GO6HJm=r0JVWBvZzma-RNmM3s7rqy3pQ@mail.gmail.com>
Message-ID: <CACL_3VF3L89uRuCQY_GO6HJm=r0JVWBvZzma-RNmM3s7rqy3pQ@mail.gmail.com>
Subject: Re: Comments on draft-li-6man-enhanced-extension-header Sec 2.1
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, 6man WG <ipv6@ietf.org>, Lizhenbin <lizhenbin@huawei.com>
Content-Type: multipart/alternative; boundary="0000000000009babf5058d551fc3"
X-Pobox-Relay-ID: 4FEE5C66-A325-11E9-B464-46F8B7964D18-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/TNQrwdGzqZruDa92mX3qu8cQdcM>
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: Wed, 10 Jul 2019 15:13:58 -0000
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. 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