Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

otroan@employees.org Thu, 09 February 2017 10:36 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB9812996F; Thu, 9 Feb 2017 02:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 nceBm3P88maP; Thu, 9 Feb 2017 02:36:53 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 587BC129967; Thu, 9 Feb 2017 02:36:53 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 09 Feb 2017 10:36:51 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 08D90D788B; Thu, 9 Feb 2017 02:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=IS07E1Yut2AHUKB9g53++fkVFnA=; b= cTHzCpUvpUx78eJZICsgISlnD9sf2leYcwI1Eqgjxxni8g34D7e5924GER+1nfjG 0XDN3NjiBWqwrQObC/srVeUbbU3YhdovGZUzF7TQ9RJJp+8X2TqI7xfcMKttdk+T 7zH3Kt2oLtMS9e7VjTa83uGFDRa/5McY2ZVQu+hgFXY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=NkucE+KZ0xHHYibHFotg/O+ bC5iIlWuGG4VT6511iHvaJh+EUcYhqXYZ0eZO1jFz6JDj8dmgqe5Wx8ByFqk3jky OENarVZv/iB8qprLHxDjM27Z1Oh+MSOFqjIvphcZhuWgDY9At5jOR4p10bdHaC2m VWuLM/rT7VvvSIaK90og=
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id A60B1D7890; Thu, 9 Feb 2017 02:36:50 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 41D1B88226BF; Thu, 9 Feb 2017 11:36:51 +0100 (CET)
From: otroan@employees.org
Message-Id: <23C46409-337C-468D-BCDC-34027BB56CAD@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_460BAB5C-377D-4C7B-8984-D1E11437AE6E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
Date: Thu, 9 Feb 2017 11:36:50 +0100
In-Reply-To: <2ea64b3c-d69d-6b6c-cb04-fe63727a8bee@si6networks.com>
To: Fernando Gont <fgont@si6networks.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> <2ea64b3c-d69d-6b6c-cb04-fe63727a8bee@si6networks.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/WPDUhRAKc4SxrPuoVZ78ss8e0aQ>
Cc: 6man@ietf.org, IETF Discussion <ietf@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, Stefano Previdi <sprevidi@cisco.com>, draft-ietf-6man-rfc2460bis@tools.ietf.org, 6man-chairs@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2017 10:36:55 -0000

Fernando,

Pete asked me to summarize the objections to option 1 - banning header insertion explicitly.
I responded with the set of objections I've heard for all options, as I couldn't see a straightforward way of only summarising for option 1.

I don't understand your message.
Do you disagree with the summary itself? Are there arguments missing?
Or is your grief that the I have distilled the arguments wrongly or put them in a bad light?

Or are you just rehashing your position on the issue?

cheers,
Ole


> On 8 Feb 2017, at 15:25, Fernando Gont <fgont@si6networks.com> wrote:
> 
> 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
> 
> 
>