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

Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com> Sat, 18 February 2017 12:59 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
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 D34D31294D2 for <ietf@ietfa.amsl.com>; Sat, 18 Feb 2017 04:59:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 5QNIv2tvSnBn for <ietf@ietfa.amsl.com>; Sat, 18 Feb 2017 04:59:44 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C42DB126CD8 for <ietf@ietf.org>; Sat, 18 Feb 2017 04:59:42 -0800 (PST)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1cf4bw-0000FfC; Sat, 18 Feb 2017 13:59:36 +0100
Message-Id: <m1cf4bw-0000FfC@stereo.hq.phicoh.net>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
From: Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
In-reply-to: Your message of "Sat, 18 Feb 2017 08:34:32 +1300 ." <50a79d32-046b-3851-8afe-55fba104e44f@gmail.com>
Date: Sat, 18 Feb 2017 13:59:35 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/GxRJGS1jzWLgm2VXptYGigmer1w>
Cc: IETF discussion list <ietf@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: Sat, 18 Feb 2017 12:59:46 -0000

>> Are you saying:
>> 
>> A correct implementation of RFC2460 MUST NOT insert an EH at any point 
>> along the path other than at the packet source.
>> 
>> Or
>> 
>> A correct implementation of RFC2460 MAY insert an EH at any point along 
>> the path.
>
>Ole doesn't, apparently, want to say either of those things.
>
>I want to say the first *as part of the promotion to Internet Standard*
>because it was the clear and documented intent of the authors and WG
>of RFC 1883, which became RFC 2460. (Documented in the ancient email I dug
>out a while back.) And it has been assumed by subsequent work such
>as PMTUD and IPsec/AH.
>
>If we want to *change* it, that's a separate discussion from promoting
>the current standard. We can do it afterwards.
>
>(And in answer to some other comments, I'll note that RFC 791 does not
>forbid NAT, but I bet the authors would have done so if they'd thought
>of it. When did forbidding something in an RFC ever prevent people from
>implementing it in a limited domain?)

I agree.

Personally, I wish we could allow routers to insert fragmentation headers.
There is some crazy interaction between DNS and fragmentation that doesn't
happen in IPv4.

But in any case, a stronger text doesn't have much impact on parties outside
the IETF. If, as a random example, I came to the conclusion that I can
reduce PMTU problems by having one of my routers fragment IPv6 packets, then
that may violate the spec, but it is possible that the gains are worth it.

So the only purpose of a stronger text against inserting extension headers
would be to prevent IETF working groups from publishing RFCs that use
that technique. 

Then the question becomes, why would we need to pre-emptively constrain
ourselves? 

If we expect that there is some real world use case where insering
extension headers along the way brings a lot of benefit, then it is much
better to prepare for that situation then writing text to disallow it.