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

Mark Andrews <marka@isc.org> Sun, 19 February 2017 22:36 UTC

Return-Path: <marka@isc.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 D7FF312941A for <ietf@ietfa.amsl.com>; Sun, 19 Feb 2017 14:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ScrtnbCeYInD for <ietf@ietfa.amsl.com>; Sun, 19 Feb 2017 14:36:25 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 9BBAD1293E0 for <ietf@ietf.org>; Sun, 19 Feb 2017 14:36:25 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AC7F334930F; Sun, 19 Feb 2017 22:36:21 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 96B0016003F; Sun, 19 Feb 2017 22:36:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 73A46160047; Sun, 19 Feb 2017 22:36:21 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 61eXAYhF9lMc; Sun, 19 Feb 2017 22:36:21 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DA98E16003F; Sun, 19 Feb 2017 22:36:20 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8E4E46427E17; Mon, 20 Feb 2017 09:36:27 +1100 (EST)
To: Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com>
From: Mark Andrews <marka@isc.org>
References: <m1cf4bw-0000FfC@stereo.hq.phicoh.net>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
In-reply-to: Your message of "Sat, 18 Feb 2017 13:59:35 +0100." <m1cf4bw-0000FfC@stereo.hq.phicoh.net>
Date: Mon, 20 Feb 2017 09:36:27 +1100
Message-Id: <20170219223627.8E4E46427E17@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/xxLoqK70LjIo13f54TXO31xRCwE>
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: Sun, 19 Feb 2017 22:36:27 -0000

In message <m1cf4bw-0000FfC@stereo.hq.phicoh.net>et>, Philip Homburg writes:
> >> 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.

With IPv4 DF is 0 unless you are running a out of RFC compliance
stack (Yes I'm talking about Linux) so fragmentation is done when
required. Add to that very few paths that actually require PMTUD
even with DF=1 you don't see issues.  As IPv4 as a service becomes
more common you will start to see more issues.

For IPv6 you have to play games with DNS.  We tried just fragmenting
at 1280 but the idiots with firewalls that drop all fragments made
that not viable.  At the moment named is forcing fragmentation at
1280 on DNS/UDP message sizes > 1432 (IPv6 in IPv4 + UDP header).
This removes most of the PMTUD issues without getting DNS/UDP
messages between 1252 and 1432 bytes dropped just because they were
fragmented.

> 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.
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org