Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Toerless Eckert <> Wed, 29 August 2018 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42C38130DD3; Tue, 28 Aug 2018 19:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pVoEcxwjwQ6r; Tue, 28 Aug 2018 19:10:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE9D3129385; Tue, 28 Aug 2018 19:10:19 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 879DF58C51D; Wed, 29 Aug 2018 04:10:15 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 78F80440054; Wed, 29 Aug 2018 04:10:15 +0200 (CEST)
Date: Wed, 29 Aug 2018 04:10:15 +0200
From: Toerless Eckert <>
To: Tom Herbert <>
Cc: Joe Touch <>, Christian Huitema <>, int-area <>,
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Aug 2018 02:10:23 -0000

On Tue, Aug 28, 2018 at 06:02:19PM -0700, Tom Herbert wrote:


> "NOTE: While [RFC2460] required that all nodes must examine and
> process the Hop-by-Hop Options header, it is now expected that nodes
> along a packet's delivery path only examine and process the Hop-by-Hop
> Options header if explicitly configured to do so."

The industry does not fix these type of issues in old running code just
because someone else wants to deploy new code in new boxes somewhere
else along the path. That broken code will kill deployments for
a decade until it expires.  Besides: Anybody who continues to just
evolve code from an old code basis is also unlikely to read, understand
and fix this piece in the evolution to rfc8200 too.

And there is not even a MUST in that text. And it does not talk about
granularity of inspection. Guess what triggered the first wave of bad
implementations killing onpath services: IPv4 router alert that
was punting ANY IPv4 router alert. Instead of at least only per-IPv4
protocol field in the router-alert.

Sorry. Will never fly in real deployment across Internet paths
if its based on this lame text in rfc8200. I stand by my suggestion.

There is also no consideration at all to rethink even expressing
the granularity of deciding whether or not to inspect. 

> That allowance should be sufficient to resolve most of the the
> Hop-by-Hop being dropped problem. All that is being asked of
> middleboxes is that they ignore HBH instead of dropping the packet if
> they don't want to deal with them. That should not be difficult to
> implement. Hopefully, it's just a matter of evangelization and time to
> improve the situation.

Good luck. Where can i buy short sell options for anything
done on the existing hop-by-hop code point ?


> > See above: short of something that extreme, we should focus
> > on doing the right thing for new code but build it in
> > such a way that it is not blocked by bad existing old onpath code.
> >
> Agreed.
> Tom