Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Fernando Gont <fgont@si6networks.com> Wed, 08 February 2017 14:25 UTC
Return-Path: <fgont@si6networks.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 124C8129B1A; Wed, 8 Feb 2017 06:25:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 iN_rAq3TRMwv; Wed, 8 Feb 2017 06:25:46 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FCC129B20; Wed, 8 Feb 2017 06:25:45 -0800 (PST)
Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4726A809C0; Wed, 8 Feb 2017 15:25:40 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: otroan@employees.org, Pete Resnick <presnick@qti.qualcomm.com>
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> <30725d25-9829-bf50-23c6-9e1b757e5cba@si6networks.com> <7ee506c2-4213-9396-186a-2b742c32f93b@gmail.com> <EA7E5B60-F136-47C6-949C-D123FB8DA70E@cisco.com> <00af01d27e11$fe539500$4001a8c0@gateway.2wire.net> <60F01869-8B32-46D3-80B1-A140DF1DDA8A@employees.org> <8D401C5B-C3C3-4378-9DFA-BF4ACC8E9DAF@qti.qualcomm.com> <D2D907D5-84B4-43BB-9103-F87DA9F122EB@employees.org> <33DC7B74-D240-4FF2-A8FF-C9C5A66809EE@qti.qualcomm.com> <1179DE45-3971-44A1-9630-28F76D2D652D@employees.org>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <2ea64b3c-d69d-6b6c-cb04-fe63727a8bee@si6networks.com>
Date: Wed, 08 Feb 2017 11:25:25 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <1179DE45-3971-44A1-9630-28F76D2D652D@employees.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/clMjWG_eBbCzbJ5LOtoPJBUlj60>
Cc: draft-ietf-6man-rfc2460bis@tools.ietf.org, 6man@ietf.org, IETF Discussion <ietf@ietf.org>, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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, 08 Feb 2017 14:25:53 -0000
On 02/08/2017 10:51 AM, otroan@employees.org wrote: >> >> There were three main positions argued in the working group. >> >> 1) Ban header insertion outright. 2) Describe the problems with >> header insertion. 3) No changes to RFC2460 text. >> >> What did you see as the objections to going with (1) (which I >> presume to be the equivalent of Brian's proposed text)? Why was it >> that people thought the protocol could not be clarified to say >> that? And was your assessment that those arguments were correct, or >> that they simply were not addressed by the WG? I've seen several >> people argue on this list that (1) was always the intent of the >> protocol, and that damage occurs if you don't follow that >> directive. I haven't seen anyone here argue otherwise. Could you >> summarize? > > I can try. It has been difficult to distill the essence out of all > the mailing list discussions. This is _my_ take of the discussion and > arguments as I understood them. Please chime in with corrections. > > The arguments of what would break are correct. The counter-arguments > given would be that this is done within a controlled domain and the > potential for damage could be controlled. There need not be "counter arguments". It was clear to everyone that IPv6 never allowed EH insertion. If you want to change that, you have to update RFC2460 (and if you do it before rfc2460bis is published, good luck with moving it to Standard). OTOH, if the argument is that you want to break a protocol in your own environment, in which you can "control the damage"... why do you need an RFC for that? why should we rubberstamp it? > The discussion went something like (paraphrasing): > > - Inserting headers will break Path MTU discovery, AH and may result You miss the most important point: EH insertion was never allowed in IPv6. Quite a lot of us find the argument that "we're doing EH insertion because RFC2460 doesn't explicitly prohibit *insertion*" quite funny. I'm not against EH-insertion per se. I'm against what looks like a procedural hack. If people want EH insertion, fine: write a proposal that updates RFC2460, and let's have the discussion. But please do not pretend that RFC2460 allows EH insertion. > in unsuspecting hosts receiving ICMP error messages. - We will do > this in a controlled domain only. - Even if you can guarantee it will > not leak, it is not appropriate to specify that in the core IPv6 > specification - We don't need that, we just need 2460 not to ban it. > IPv6 is used in many networks not only the capital I Internet. > > There was also quite a bit of discussion on the intent of the > original authors. I don't know how much value it is correct to give > that argument. "This is what I intended, but not what I wrote...". > Given that this is in any case the output of the IETF and not two > individual authors. > > 1) Ban header insertion outright. > [...] > > b) RFC2460 is already clear and no clarification is needed. No > interoperability issue has been shown caused by this perceived > ambiguity. RFC2460 already bans EH insertion. Only when SR wa published people started to argue otherwise. Given that for some guys there was room for EH insertion, we clearly need to make the point clear. > There was hard to find consensus on either of the alternatives. As > the poll shows there was a clear preference (if people couldn't get > their first choice) to describe the problem, over banning it, or over > saying nothing. Based on the mailing-list discussion, it was quite clear that most of the folks arguing in favor of "ambiguity" were from the same company pushing a proposal with EH insertion. That's not a minor datapoint. Besides, moving a document to Standard with "ambiguity" on an item that led to 600+ messages discussion at the same group that specifies the protocol would be really bad. We're moving RFC2460 to standard. I think it should be able to answer the very basic question "Is it possible to insert EHs in the middle of the network?" -- or, framed in a different way: "is IPv6 and end-to-end protocol?" Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (I… The IESG
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Manfredi, Albert E
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Stefano Previdi (sprevidi)
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… C. M. Heard
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… 神明達哉
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Suresh Krishnan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Pete Resnick
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Enno Rey
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Philip Homburg
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… 神明達哉
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Randy Bush
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Ted Lemon
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Randy Bush
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Scott Bradner
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Suresh Krishnan
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Eric Vyncke (evyncke)
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Leddy, John
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Mark Smith
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Tal Mizrahi
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Mark Smith
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… t.petch
- RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… Tal Mizrahi
- RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… David Mozes
- Re: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… Brian E Carpenter
- Re: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460… Mark Smith
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Sander Steffann
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Sander Steffann
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Fernando Gont
- Address types [was: Last Call: <draft-ietf-6man-r… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt… Erik Kline