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

Fernando Gont <fgont@si6networks.com> Wed, 18 July 2012 21:48 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5D011E81AD for <ipv6@ietfa.amsl.com>; Wed, 18 Jul 2012 14:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUKZxQw0o6HI for <ipv6@ietfa.amsl.com>; Wed, 18 Jul 2012 14:48:44 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 14BDD11E8132 for <ipv6@ietf.org>; Wed, 18 Jul 2012 14:48:44 -0700 (PDT)
Received: from [2001:5c0:1400:a::531] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <fgont@si6networks.com>) id 1Src7g-0000xQ-7h; Wed, 18 Jul 2012 23:49:32 +0200
Message-ID: <50072F26.9030002@si6networks.com>
Date: Wed, 18 Jul 2012 22:48:22 +0100
From: Fernando Gont <fgont@si6networks.com>
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)" <fred@cisco.com>
Subject: Re: oversized-header-chains: Receipt of illegal first-fragments
References: <50071E54.30708@si6networks.com> <64FE914F-4607-4B3E-A06E-D8F193A6FEF9@cisco.com>
In-Reply-To: <64FE914F-4607-4B3E-A06E-D8F193A6FEF9@cisco.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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.

Agreed.



> 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

  "there
   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.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492