Re: oversized-header-chains: Receipt of illegal first-fragments

Fernando Gont <> Wed, 18 July 2012 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB5D011E81AD for <>; Wed, 18 Jul 2012 14:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cUKZxQw0o6HI for <>; Wed, 18 Jul 2012 14:48:44 -0700 (PDT)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id 14BDD11E8132 for <>; Wed, 18 Jul 2012 14:48:44 -0700 (PDT)
Received: from [2001:5c0:1400:a::531] by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <>) id 1Src7g-0000xQ-7h; Wed, 18 Jul 2012 23:49:32 +0200
Message-ID: <>
Date: Wed, 18 Jul 2012 22:48:22 +0100
From: Fernando Gont <>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Fred Baker (fred)" <>
Subject: Re: oversized-header-chains: Receipt of illegal first-fragments
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jul 2012 21:48:44 -0000

Hi, Fred,

Thanks so much for your prompt response. Please find my comments in-line...

On 07/18/2012 10:03 PM, Fred Baker (fred) wrote:
>> "A host that receives a first-fragment that fails to include the
>> entire IPv6 header chain MUST silently drop the aforementioned
>> fragment".
>> Clearly, since such packets are illegal, they shouldn't exist in
>> the first place... so dropping them makes sense.
>> Thoughts?
> I would say "SHOULD", but I'm OK with the fundamental statement. The
> Robustness Principle has some built-in tension: "be liberal in what
> you accept and conservative in what you send" often works out to mean
> "accept a technically-illegal message if you can work out an
> unambiguous intent"; what you are saying is to "be strict in what you
> accept", which in this case is (as you suggest) probably the right
> thing to do.


> The distinction between "SHOULD" and "MUST" is a little of a chinese
> wall. The rule I use, which is neither specified nor universal, is
> that I say something "MUST" be obeyed if failing to obey results in
> an identifiable failure

I've always used the same rule, but ended up reconsidering it upon
suggestion of S. Braden when he noted that, as per RFC2119, a "SHOULD"
implies that

   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

So I guess that, from that perspective, to make it a "SHOULD" (rather
than a "MUST") one should be able to come up with a good reason to
accept such packets...

(I should say that I've authored documents that include SHOULDs/MUSTs
with your rationale, rather than the one I've just quoted)

> (fragmenting a DNF packet, for example, fails
> in that if a recipient of DNF fragments will refuse to reassemble
> them, this prevents communication that was intended to be supported,
> so a packet marked DNF "MUST" not be fragmented), 

(Side discussion, but just for the fun of it): Actually, I'd argue that
the motivation for "MUST NOT" fragment would probably be that the
Identification field is most-likely 0, and the node fragmenting the DNF
packet is in no good position of selecting a good Fragment ID.


Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492