Re: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
"li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com> Fri, 04 June 2021 09:14 UTC
Return-Path: <li_zhenqiang@hotmail.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 763943A3032 for <ipv6@ietfa.amsl.com>; Fri, 4 Jun 2021 02:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.213
X-Spam-Level:
X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 LuVEvK-P_mNt for <ipv6@ietfa.amsl.com>; Fri, 4 Jun 2021 02:14:26 -0700 (PDT)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01olkn2081f.outbound.protection.outlook.com [IPv6:2a01:111:f403:7004::81f]) (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 553AD3A302D for <ipv6@ietf.org>; Fri, 4 Jun 2021 02:14:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JSKUPzNbv+qIrFamIVDIlYGiW/InNDfuyiAa9seh0mNS+wb2AOxy1epObQwrNqUy5fanDR6WDLvJJK37MjHnNKnRaU2sG9aVZMFd7ojfJISwMgYRE0UGRE/JSxNknb7VJkcasjzcMOIglP68vDlJxXsiuzaEhLjmuWNxbkPehPeANkHWYVVd6aBxK7eddrlSYck+w8YBASfJuiUO5T9z2nKsBa/drGoHjhE8Oh5stxcUucXugiuhKqk1yN/98mDpe8kRJ3eiQE+ItcKjGbjJqAs9A54BGPJ0Q5bqJksl9060ZeAHt71t1dKeicUEOwgnzlOlje1Ic99KFRmRBFRIcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y/OxLTc7o2LnHVkHrmXQu2vqpodmN4qT+3xOUssEs0g=; b=NToRKxCAkixxplN2uW9cJEMMLK+KDFT8096dKII+vwZWRSdqwbvap90PYb1R+Fg2f5yN1bDvvB/DD+Y13d7/PG9k8AHDMCPMmqYjTTHNVpCDdlU7ZIQKNhIwP+ommDVSTFu8v0SLb/OktZYRRNLbsP6IoSE9X9mnff94x6SImHgg+9anC/lkn1Jq2x70DcSl2iDGVs8SvlqcxNbDqE4eAx10OSZ+QBV+X1mEFLD1aXuITa/9PhGjnhyGjQuf1Mw5S/8hWDty5CEJHgk49KPkbFRTKTIYOneFfaYiB5bOvB8mmojCzFmabk1EmvQvPImob5PNg8Mhvj9GEtBohtmEQA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y/OxLTc7o2LnHVkHrmXQu2vqpodmN4qT+3xOUssEs0g=; b=jitlkx4GIBYnrFCX4XJvpulCKXh1iJvvuMSaVrAr1OMc+IN78t8Cu1edXOBT06OLfPHfdxRyH1FSkbssuP6yhS/RL1PrPoVxIN1S7+Mr3oBQPcQL+hSyEW+xdWV9ekA7NTxNGeWaOAG6JdYALtJ3UgCOjTG6x/8WvymKSaCVztZsb1nLDsphvKn+OCxaTkdr9uLA8mFzw5uIchSH/RQz7LtRVs58jiDDxfITeJEwQSw6NKqaLgRH+TQb6g1l5rKKKA3IHHm29BK2QHdEXJ7k+Z2LQbD41ePORfzHxpoBtELBhSVyFwh8noitQIoZ483vSpIppqDMZVy98Hlp4+dQrA==
Received: from MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:157::9) by ME3P282MB2890.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:13b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.22; Fri, 4 Jun 2021 08:59:23 +0000
Received: from MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM ([fe80::1509:afbc:fb4c:27cd]) by MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM ([fe80::1509:afbc:fb4c:27cd%7]) with mapi id 15.20.4195.024; Fri, 4 Jun 2021 08:59:23 +0000
Date: Fri, 04 Jun 2021 17:00:36 +0800
From: "li_zhenqiang@hotmail.com" <li_zhenqiang@hotmail.com>
To: Bob Hinden <bob.hinden@gmail.com>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, Tom Herbert <tom@herbertland.com>
Subject: Re: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
References: <162265842779.4095.2393609365780372735@ietfa.amsl.com>, <E5A31CCD-104D-4B92-9730-4FCFBF191F46@gmail.com>, <CALx6S367PfW5hana4_10C1vGwBcTX7tMsN7D+pA8UPRd5mw1BQ@mail.gmail.com>
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.156[cn]
Message-ID: <MEYP282MB2942C0C24BBBE0A1F801CEF3FC3B9@MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative; boundary="----=_001_NextPart506270313207_=----"
X-TMN: [C7vGn/wLt1LY1xRbe2fYwifFJpQeVEmG2Muuu10yN4Y=]
X-ClientProxiedBy: HKAPR03CA0024.apcprd03.prod.outlook.com (2603:1096:203:c9::11) To MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM (2603:10c6:220:157::9)
X-Microsoft-Original-Message-ID: <2021060417003207768416@hotmail.com>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from cmcc-PC (183.243.251.113) by HKAPR03CA0024.apcprd03.prod.outlook.com (2603:1096:203:c9::11) with Microsoft SMTP Server (version=TLS1_1, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.4219.9 via Frontend Transport; Fri, 4 Jun 2021 08:59:21 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 16f54c6d-5c89-4d00-2901-08d927370b9e
X-MS-TrafficTypeDiagnostic: ME3P282MB2890:
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: rAOjuSr5zFvDSQR1FUluKf7ku211if2lv+JzdfgLXw96wwhJ5SStRtihbc37mpxy5GexWGg/C6BKc2P+xeFpIREk7H42fH8jzLm+EVn3RhmXDmN9ND3k7b4276muNh9JQGafnPzdM+RmYNSXZdUE5ns3KKLadE4CnjGstPgFNwkxKAnXL9hwgBmurvodIsVVLcZ1xYXsJRfFqh6nXOdL99XHmMckaMMdRSUkmUY96fES+f9Lxo6CbpZC0v+1BKbICrD//nJyZ1mYd8dZWD/Pkvf5KqdlKwzTffxhxmyNAhjjbzJeKdXiBaY+ceJ3d1qOdgohfBXmdFK3vm0IT2xgqJZtS83F1GO/rIj0PLJTqEPzxtyQ3UoEnNns/M09Vx3a1ZCmex8BK8Fq4cSp9A0xLkGRIUstcy03D8c18R4rGYZKqXN/7CqvQ9WlxRnzGuX+ZtEqJjsD8bSDTQIEsWSdL4L5Q53+Sjyd6hJZJ8USspk=
X-MS-Exchange-AntiSpam-MessageData: 4NQTXZmq3kfA9ClkPc1n8fWtDPdmynKYtpYM8zS/s37HhDvHZlWpPV13wVq0+CI36q/DXya96MnkNtjpnZm4weRrkvSIXIp/yz/YogFfQa5OAJ7DdP+7+rhHQMaClmAbK4dS+MzpBtZsxrCR5mgoZQ==
X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-8dac2.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 16f54c6d-5c89-4d00-2901-08d927370b9e
X-MS-Exchange-CrossTenant-AuthSource: MEYP282MB2942.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2021 08:59:22.9100 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME3P282MB2890
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BzULAbFbpnY7DqDgJu-0kJYDvtw>
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, 04 Jun 2021 09:14:33 -0000
Hi authors, Could you please explain the relationship between this doc and https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers, in which the processing policy for the packets with HBH EH is DROP or IGNORE? If the processing policy is really needed to be revised, can we update the WG draft https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering accordingly? Best Regards, Zhenqiang Li li_zhenqiang@hotmail.com From: Tom Herbert Date: 2021-06-03 23:17 To: Bob Hinden CC: Gorry Fairhurst; IPv6 List Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt Hello, a few comments on the draft: >From the draft: "Unfortunately, this did not improve the processing of Hop-by-Hop options and did not significantly improve deployment and use in the Internet." Is there data that supports this statement? Since RFC8200 was published, have router implementations been changed to ignore HBH options instead of dropping packets containing them? The primary problem with supporting HBH Options in the Internet isn't that we need all nodes in the path to process them, it's that we need all nodes in the Internet to at least forward packets containing them and not blindly drop the packets. "This document updates [RFC8200] that a node MUST process the first Option in the Hop-by-Hop Header in the Fast Path" It think this should be "This document updates [RFC8200] that a node MUST process the first Option in the Hop-by-Hop Header in the Fast Path if a node is configured to process Hop-by-Hop Options" "The share of traffic containing more than one EH however, is very small. For the design of hardware able to handle the dynamic nature of EHs, we therefore recommend to support at least one EH" I suspect that the share of traffic containing any EH is very small :-). There's an obvious tradeoff here in limiting an extensibility mechanism to elicit feasible implementation versus not restricting the mechanism so much that it inhibits innovation. So we need to define and recommend some number of options N that satisfies both these objectives. Emerging programmable devices, such as those based on P4 or PANDA, are more capable and flexible than ASIC based implementations, so N=1 might not be the best choice looking forward since it is overly restrictive. Note also that section 5.3 of RFC8504 sets N=8 for end host processing of HBH and Dest Options (I suggest RFC8504 should be referenced by the draft). "A node configured not to process HBH options, MUST drop the packet if the top two bits of the Option Type field of the first HBH option is non-zero." This is a change to RFC8200 that would make a lot of implementations retroactively non-conformant. I don't think it's practical. I would suggest updating to RFC8200 with these requirements instead. - If an intermediate node processes an option it does not recognize and the top two bits of the Option Type field of the option are non-zero, then the node MUST stop option processing and SHOULD NOT drop the packet and SHOULD NOT send an ICMP Parameter Problem. - A final destination node MUST process all the Hop-by-Hop Options, or drop the packet if the number of options exceeds the configured limit per RFC8504. This includes processing per the top two bits of Option Type when an option is unrecognized as specified in RFC8200. - New Hop-by-Hop Options SHOULD be defined with 00 as the top two bits of the Option Type (that is new option should be defined to be ignored if they are unrecognized by a node). Tom On Wed, Jun 2, 2021 at 11:32 AM Bob Hinden <bob.hinden@gmail.com> wrote: > > Hi, > > We posted a new version of draft-hinden-6man-hbh-processing. The changes include: > > * Expanded terminology section to include Forwarding Plane and > Control Plane. > * Changed draft that only one HBH Option MUST be processed and > additional HBH Options MAY be processed based on local > configuration. > * Clarified that all HBH options (with one exception) must be > processed on the Fast Path. > * Kept the Router Alert options as the single exception for Slow > Path processing. > * Rewrote and expanded section on New Hop-by-Hop Options. > * Removed requirement for HBH Option size and alignment. > * Removed sections evaluating currently defined HBH Options. > * Added content to the Security Considerations section. > * Added people to the acknowledgements section. > * Numerous editorial changes > > We think this resolves most of the issues raised on the list and at the pervious IETF meeting. > > Please review and comment on the list. > > Bob & Gorry > > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hinden-6man-hbh-processing-01.txt > Date: June 2, 2021 at 11:27:07 AM PDT > To: "Robert M. Hinden" <bob.hinden@gmail.com>, "Godred Fairhurst" <gorry@erg.abdn.ac.uk>, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>, "Robert Hinden" <bob.hinden@gmail.com> > > > A new version of I-D, draft-hinden-6man-hbh-processing-01.txt > has been successfully submitted by Robert M. Hinden and posted to the > IETF repository. > > Name: draft-hinden-6man-hbh-processing > Revision: 01 > Title: IPv6 Hop-by-Hop Options Processing Procedures > Document date: 2021-06-02 > Group: Individual Submission > Pages: 13 > URL: https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.txt > Status: https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/ > Html: https://www.ietf.org/archive/id/draft-hinden-6man-hbh-processing-01.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-hinden-6man-hbh-processing > Diff: https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-hbh-processing-01 > > Abstract: > This document specifies procedures for how IPv6 Hop-by-Hop options > are processed. It modifies the procedures specified in the IPv6 > Protocol Specification (RFC8200) to make processing of IPv6 Hop-by- > Hop options practical with the goal of making IPv6 Hop-by-Hop options > useful to deploy and use in the Internet. When published, this > document updates RFC8200. > > > > > The IETF Secretariat > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- Fwd: New Version Notification for draft-hinden-6m… Bob Hinden
- Re: New Version Notification for draft-hinden-6ma… Eric Vyncke (evyncke)
- Re: Fwd: New Version Notification for draft-hinde… Nick Hilliard
- Re: Fwd: New Version Notification for draft-hinde… Tom Herbert
- Re: New Version Notification for draft-hinden-6ma… Tom Herbert
- Re: Fwd: New Version Notification for draft-hinde… Brian E Carpenter
- Re: Re: New Version Notification for draft-hinden… li_zhenqiang@hotmail.com
- RE: New Version Notification for draft-hinden-6ma… Pengshuping (Peng Shuping)
- Re: Fwd: New Version Notification for draft-hinde… Fernando Gont
- Re: Fwd: New Version Notification for draft-hinde… Fernando Gont
- Re: Fwd: New Version Notification for draft-hinde… Gorry Fairhurst
- Re: Fwd: New Version Notification for draft-hinde… Fernando Gont
- Re: Fwd: New Version Notification for draft-hinde… Gorry Fairhurst
- Re: Fwd: New Version Notification for draft-hinde… Tom Herbert
- Re: Fwd: New Version Notification for draft-hinde… Brian E Carpenter
- Re: Fwd: New Version Notification for draft-hinde… Tom Herbert
- Re: Fwd: New Version Notification for draft-hinde… Brian E Carpenter
- Re: Fwd: New Version Notification for draft-hinde… Fernando Gont
- Re: Fwd: New Version Notification for draft-hinde… Fernando Gont
- Re: Fwd: New Version Notification for draft-hinde… Tom Herbert
- Re: Fwd: New Version Notification for draft-hinde… Fernando Gont
- Re: New Version Notification for draft-hinden-6ma… Pascal Thubert (pthubert)
- Re: New Version Notification for draft-hinden-6ma… Fernando Gont
- Re: New Version Notification for draft-hinden-6ma… Tom Herbert
- Re: New Version Notification for draft-hinden-6ma… Fernando Gont
- RE: New Version Notification for draft-hinden-6ma… Pascal Thubert (pthubert)
- RE: New Version Notification for draft-hinden-6ma… Vasilenko Eduard
- Re: New Version Notification for draft-hinden-6ma… Tom Herbert
- Re: New Version Notification for draft-hinden-6ma… Nick Hilliard
- Re: New Version Notification for draft-hinden-6ma… Tom Herbert
- RE: New Version Notification for draft-hinden-6ma… Vasilenko Eduard
- Re: New Version Notification for draft-hinden-6ma… Tom Herbert
- Re: New Version Notification for draft-hinden-6ma… Fernando Gont
- RE: New Version Notification for draft-hinden-6ma… Vasilenko Eduard
- Re: New Version Notification for draft-hinden-6ma… Fred Baker