RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
"Ackermann, Michael" <MAckermann@bcbsm.com> Fri, 31 March 2017 15:04 UTC
Return-Path: <mackermann@bcbsm.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 4FC7A1294ED for <ipv6@ietfa.amsl.com>; Fri, 31 Mar 2017 08:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.09
X-Spam-Level:
X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.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 Xz4eMd7LdEDC for <ipv6@ietfa.amsl.com>; Fri, 31 Mar 2017 08:04:09 -0700 (PDT)
Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 AAED5129511 for <ipv6@ietf.org>; Fri, 31 Mar 2017 08:04:09 -0700 (PDT)
Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 2220DC15C7 for <ipv6@ietf.org>; Fri, 31 Mar 2017 10:04:09 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [12.107.172.81]) by mx.z120.zixworks.com (Proprietary) with SMTP id 70FE2C15A8; Fri, 31 Mar 2017 10:04:08 -0500 (CDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F18F4FE066; Fri, 31 Mar 2017 11:04:19 -0400 (EDT)
Received: from imsva2.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C8199FE064; Fri, 31 Mar 2017 11:04:19 -0400 (EDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (unknown [216.32.180.175]) by imsva2.bcbsm.com (Postfix) with ESMTPS; Fri, 31 Mar 2017 11:04:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=an/rHYnEPEQ2iUIKEo2E3JGctcNXZdfr4tP4kR5Hj7k=; b=IVkwrNXPYoJte4WPLTDwIN8t7qx1QQv1w9pnRmsuR01JbsaypGWHF498xyNAKKOG9mIw4EtariaciCOW8RMS5QF4CkbOEGwofsv6+jYWWu1q6+xEQqqyyODIHyewoh4cE2c8YDCNmO4LBbGY1U+NAz6kibsgHH5yGI8fqk4kZro=
Received: from BN6PR14MB1361.namprd14.prod.outlook.com (10.172.149.135) by BN6PR14MB1362.namprd14.prod.outlook.com (10.172.149.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.10; Fri, 31 Mar 2017 15:04:05 +0000
Received: from BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) by BN6PR14MB1361.namprd14.prod.outlook.com ([10.172.149.135]) with mapi id 15.01.1005.014; Fri, 31 Mar 2017 15:04:05 +0000
From: "Ackermann, Michael" <MAckermann@bcbsm.com>
To: Tim Chown <Tim.Chown@jisc.ac.uk>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSnTZv71giYAPcbUKK9ywM4gSjvqGuC10AgAAPeACAAQO2gIAABphg
Date: Fri, 31 Mar 2017 15:04:05 +0000
Message-ID: <BN6PR14MB136174D6D442396781347270D7370@BN6PR14MB1361.namprd14.prod.outlook.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <CAFU7BAS4zZ44ZRgmNSHBYvV9iWwRvn1X2Z-_-ncD-=E4mzhp9g@mail.gmail.com> <eb09748b-9d56-1306-e636-a482825f8e1d@gmail.com> <F2FACDFC-E7A8-47D8-8552-8E11D7E98345@jisc.ac.uk>
In-Reply-To: <F2FACDFC-E7A8-47D8-8552-8E11D7E98345@jisc.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com;
x-originating-ip: [31.133.134.235]
x-microsoft-exchange-diagnostics: 1; BN6PR14MB1362; 7:RXxDVH0BzeJN3Sl5+G7/EZaU+Caeuzn5CIfONUhKse5MQApWJGoVTsXQVnTxUgTtt6N+wU5eKOUma6xojKa/t7dnfn9FNL+g2sjYV5/SN2q7lSpFIIkTUr/YX1y8P7e6lLDMdh965J1iavqmCYNv0jWbynE1SPhfk5rTcPHCoQlezdA3Jx10j0o6E9bw81BnuC7Ue9HAicYqCD9oeKMNu5iNh+ApCr72sWAd2nFAVUtHb7H1/HOPuZ7Zt09RCPKsAAUJmO8HEUs1adcWWEIyQssMReRxJrRcdw1JBHJ5aLHeWwcylBw/NFXhP2jV0c4+HrvEu/cIjzfJdnfTX8V+lw==; 20:BaJdVfkRVo/AlDmn/p2gdjgvwpR4gvVcwjWLKdNNPI/XfPAv5dE1+CixEj+ik60Z3pGddf0uk70AphWytbfRS7+2skHlk7SbJf31yPAU//gN49p1MC0gTkxbUGhClUwYsYOn3zWKeA5pMZ9F4NYkvn0IUIAtL34+Qypq5UQaPMc=
x-ms-office365-filtering-correlation-id: 613b319a-9941-4f3e-f361-08d478472cfb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN6PR14MB1362;
x-microsoft-antispam-prvs: <BN6PR14MB13622793511208DB7FD385A7D7370@BN6PR14MB1362.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN6PR14MB1362; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1362;
x-forefront-prvs: 02638D901B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(39410400002)(39400400002)(39450400003)(54164003)(24454002)(377454003)(2900100001)(19609705001)(230783001)(7696004)(229853002)(2950100002)(7736002)(7906003)(74316002)(106356001)(122556002)(66066001)(86362001)(5660300001)(6506006)(4326008)(77096006)(6436002)(53546009)(8676002)(790700001)(606005)(6246003)(25786009)(80792005)(38730400002)(3846002)(6116002)(102836003)(54356999)(189998001)(2906002)(236005)(3660700001)(39060400002)(3280700002)(8936002)(6306002)(76176999)(50986999)(55016002)(9686003)(99286003)(54896002)(53936002)(33656002)(81166006)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1362; H:BN6PR14MB1361.namprd14.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR14MB136174D6D442396781347270D7370BN6PR14MB1361namp_"
MIME-Version: 1.0
X-OriginatorOrg: bcbsm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 15:04:05.6771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1362
X-TM-AS-GCONF: 00
X-VPM-HOST: vmvpm02.z120.zixworks.com
X-VPM-GROUP-ID: dd9a81cc-a64f-4472-9678-26d9ff511c00
X-VPM-MSG-ID: cd027ab1-d474-4c30-98f7-786b31890f2a
X-VPM-ENC-REGIME: Plaintext
X-VPM-IS-HYBRID: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DdeHmTkML7srILru2FFb1CEpaPU>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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, 31 Mar 2017 15:04:13 -0000
QUESTION: Does the word PROCESSED, mean change, implying write capability? If yes, can that be stated? From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tim Chown Sent: Friday, March 31, 2017 10:39 AM To: Brian E Carpenter <brian.e.carpenter@gmail.com> Cc: ipv6@ietf.org Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08 On 31 Mar 2017, at 00:09, Brian E Carpenter <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote: On 31/03/2017 11:13, Jen Linkova wrote: On Wed, Mar 15, 2017 at 3:47 AM, Suresh Krishnan <suresh.krishnan@ericsson.com<mailto:suresh.krishnan@ericsson.com>> wrote: Thanks to everyone who commented during the IETF Last Call of draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for this draft was mainly focused around the text in Section 4 that discusses the handling of extension headers. The biggest concern raised was that the current text is ambiguous on whether header insertion is allowed on intermediate nodes or not. There were some people arguing that an explicit prohibition is not necessary as the text is already clear, while others believed that explicitly listing the prohibitions will minimize any misunderstandings in the future. There was also a small number of people who wanted to explicitly allow header insertion and describe how to do it, but this was clearly out of scope for this draft (but may be in scope for future work in 6man). Overall, no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet. The only argument m a de against adding clarifying text was that the text was already clear. Given this, I believe there is consensus to add explicit text about header insertion into the draft before it progresses further. I have discussed this with the editor and the document shepherd and would like to propose the following text change. OLD (from -08): The insertion of Extension Headers by any node other than the source of the packet causes serious problems. Two examples include breaking the integrity checks provided by the Authentication Header Integrity [RFC4302], and breaking Path MTU Discovery which can result in ICMP error messages being sent to the source of the packet that did not insert the header, rather than the node that inserted the header. One approach to avoid these problems is to encapsulate the packet using another IPv6 header and including the additional extension header after the first IPv6 header, for example, as defined in [RFC2473] With one exception, extension headers are not processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header... NEW: With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header... I have some concerns with how that sentence AND the following note comes together: " With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Note: If an intermediate forwarding node examines an extension header for any reason, it must do so in accordance with the provisions of [RFC7045]. " I'm afraid that the lack of the normative language strikes back.. Exactly the opposite, IMHO. I think it's much better like this than it would be under RFC2119 (although in fact that doesn't change the English meaning of 'must'). The "Note:" describes a situation where middleboxes are actually breaking the rule. We had that fight before RFC7045. Indeed. The RFC7045 exception applies specifically to *examining* headers, with the common use case being firewalling. Changing the RFC7045 exception text to clarify this in 2460bis was proposed, but it wasn’t taken forward. Tim Brian If 'are not examined" is to be interpreted as RFC2119 'MUST NOT', then the following note conflicts with that statement. 'A node MUST NOT examine EHs but if it does it must do it as per RFC7045' - it is extremely controversial. If ''are not examined" is to be read as RFC2119 'SHOULD NOT' then I have a very good news for those who would still like to insert/delete EHs: they can do it as long as they have "valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.". But from today's presentation I've got an impression that the intention of this text was actually to prohibit EH insertion (the sildes say 'no one argued against the fact that the intent of the text in RFC2460 was to forbid insertion of extension headers on any other node but the source of the packet.). So to summarize: the proposed text either explicitly prohibits the examination (and then it contradicts the next sentence and we need to do smth with the note and RFC7045) OR it allows EH insertion - it depends how the text is interpreted. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
- IETF Last Call conclusion for draft-ietf-6man-rfc… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Stefano Previdi (sprevidi)
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… 神明達哉
- Re: IETF Last Call conclusion for draft-ietf-6man… Voyer, Daniel
- Re: IETF Last Call conclusion for draft-ietf-6man… Joe Touch
- Re: IETF Last Call conclusion for draft-ietf-6man… Joe Touch
- Re: IETF Last Call conclusion for draft-ietf-6man… Fernando Gont
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Joe Touch
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Smith
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Xing Li
- Re: IETF Last Call conclusion for draft-ietf-6man… otroan
- Re: IETF Last Call conclusion for draft-ietf-6man… Stewart Bryant
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Manual PMTUD [was ...rfc2460bis-08] Brian E Carpenter
- Re: Manual PMTUD [was ...rfc2460bis-08] Robert Raszuk
- Re: Manual PMTUD [was ...rfc2460bis-08] Brian E Carpenter
- Re: Manual PMTUD [was ...rfc2460bis-08] Mark Smith
- Re: Manual PMTUD [was ...rfc2460bis-08] Robert Raszuk
- Re: Manual PMTUD [was ...rfc2460bis-08] Brian E Carpenter
- Re: Manual PMTUD [was ...rfc2460bis-08] Timothy Winters
- Re: Manual PMTUD [was ...rfc2460bis-08] Michael Richardson
- Re: Manual PMTUD [was ...rfc2460bis-08] Brian E Carpenter
- Re: Manual PMTUD [was ...rfc2460bis-08] Joel M. Halpern
- Re: Manual PMTUD [was ...rfc2460bis-08] Michael Richardson
- Re: Failure of AH (was: Manual PMTUD [was ...rfc2… Christian Huitema
- Re: Failure of AH (was: Manual PMTUD [was ...rfc2… Michael Richardson
- Re: Failure of AH Brian E Carpenter
- Re: Failure of AH Michael Richardson
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Townsley
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Townsley
- Re: IETF Last Call conclusion for draft-ietf-6man… Leddy, John
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Jeff Tantsura
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- RE: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- RE: IETF Last Call conclusion for draft-ietf-6man… Ackermann, Michael
- Re: IETF Last Call conclusion for draft-ietf-6man… 神明達哉
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Mark Smith
- RE: IETF Last Call conclusion for draft-ietf-6man… Ackermann, Michael
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… otroan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… otroan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- Re: IETF Last Call conclusion for draft-ietf-6man… Jen Linkova
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Jen Linkova
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Tim Chown
- RE: IETF Last Call conclusion for draft-ietf-6man… Ackermann, Michael
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Martin Rex
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Fernando Gont
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Suresh Krishnan
- Re: IETF Last Call conclusion for draft-ietf-6man… Robert Raszuk
- Re: IETF Last Call conclusion for draft-ietf-6man… Brian E Carpenter
- Re: IETF Last Call conclusion for draft-ietf-6man… Bob Hinden