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

Bill Jouris <> Sat, 21 July 2012 10:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7164421F8672 for <>; Sat, 21 Jul 2012 03:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D3zD5Dy6fo-J for <>; Sat, 21 Jul 2012 03:37:14 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 6A28021F848B for <>; Sat, 21 Jul 2012 03:37:14 -0700 (PDT)
Received: from [] by with NNFMP; 21 Jul 2012 10:38:11 -0000
Received: from [] by with NNFMP; 21 Jul 2012 10:38:11 -0000
Received: from [] by with NNFMP; 21 Jul 2012 10:38:11 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 90554 invoked by uid 60001); 21 Jul 2012 10:38:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1342867090; bh=XinFNPhunM4kUXzZz+0O2B+vwfwWa6VFwslMjNoxePM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=N89tiKAqovuVE34pUKkoQzYlQHzIXXmnrvdygV1SCojKnXdSWsDc2fRSjWO1d8D8uA43sdPI9A/h0GCWBfeokSEKS2vt3E5T4JJytlo8GsJVRzSZ/bPJ2b4+FNi0wufJPvYNJfsEwc5d4u+LPjtjV6yH/qPyvXF1IhHpxfqDV6o=
X-YMail-OSG: P1nvWswVM1k3TSjyT5r9FFHBPBC4DYs6SmEFpteA4O5po6o TOwtvLFB7GF3rMMROEnHO8WCl2vBeBq2x7RKX3Nl2z6i6D6jkEXD4_JIRea4 50D2nPziASS.T6.xriJ0vO.ZSduDvkq15LEawEkLoQ_y7NqaE5HftdTG9gkA 4vw3Li7JeZ.NHuJThLWZdebwxvjQ9bKwZ5IGU1MH2cWHepKLpvjTzN_ZT9NX tBZRBwNdzYjE6NfBNsOnBz2wbwtvbr2THyh1TNl04ErT2OfCENmHhkSVlaah qxEtOpoLXnjPYQnaOskS7HHhF5OZr58NV4NjwU6lAshu2rAvx5kFbpxwelJe 4Upn9DzGXLcfkVxtvEMts0fPNGjQp9c_ox0tSW2wGnL8Bj3maO8.DKjf_6aA kFTFc0hv_mbTUQ3ypkvQtObVuMptCBflxPF0twd_O1JVyLa9WJDyKtoAUpt6 aaS5uSfSHRXwlGPCmoo0AO2s3yLBOM2umnuTTRIZPcMzNVfSCpM3VhHvEpKq C2Oq40EOPbNRuwq3EGJc5bC6lW8GPQjUWk6Nhl5yYez85_GUjRnE0IZ78tTO oowyyqXthh.4-
Received: from [] by via HTTP; Sat, 21 Jul 2012 03:38:10 PDT
X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/
Message-ID: <>
Date: Sat, 21 Jul 2012 03:38:10 -0700 (PDT)
From: Bill Jouris <>
Subject: Re: oversized-header-chains: Receipt of illegal first-fragments
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-759923333-1771573322-1342867090=:80463"
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: Sat, 21 Jul 2012 10:37:15 -0000

--- On Thu, 7/19/12, Fernando Gont <> wrote:

>>On 07/19/2012 07:33 PM, RJ Atkinson wrote:

>> I think the requirement that a packet that violates the

>> proposed oversized-heacer-chain rule be dropped "silently" 

>> is too strong and lacks operational flexibility.


>FWIW, when I said "silently", I didn't meant to stress it. My point was

>about including a requirement to drop such packets, than whether they

>should be silently dropped, a counter incremented, etc.


There are few things more frustrating, when trying to analyze a problem, than a

situation where something happened with no fingerprints left behind.  Not to mention

that having no record makes actually finding and fixing the original problem

much more difficult.  Not only should there be some kind of record about what 

happened, the more information we can provide about why it happened the



>> A device ought to be allowed, but not required, to send 

> >an ICMPv6 Parameter Problem message if/when it drops 

> >such a packet.


> >In some situations, it might be desirable for a device

> >to drop the packet AND also generate an ICMPv6 

> >"Parameter Problem" message for the packet originator. 




As above: the more we information we can provide to the poor guy

trying to find and fix the problem, the better.


>> 1) I'd prefer this draft say that such illegal packets MUST 

>>    be dropped, but then also say that the device dropping the 

>>    packet MAY send an ICMPv6 Parameter Problem control message 

>>    back to the (alleged) sending node.  A brief sentence 

> >   suggesting, but not requiring, that implementations make 

>>    the sending of the ICMPv6 message configurable also would be 

>>    sensible.


>Should we make this latter bit (about this being configurable) a MAY, or

>would you prefer to have non-RFC2119 language?




>> 2) For the situation where an IPv6 packet is dropped for this

>>    specific reason, I'd suggest that the "Reason Code" registry 

> >   for an ICMPv6 "Type 4 - Parameter Problem" message be updated

>>    with a new focused reason code defined.  As a straw man, 

>>    I'd propose adding this new entry to that registry, 

> >   as part of this proposal:



>>      3      IPv6 Initial Fragment missing upper-layer protocol header

> >

>>     Of course, this means an "IANA Considerations" section

>>     update for the I-D would be in order.


>I find your suggestion acceptable. Can others please weigh in?


>Minor note: May be the description for the error code should be along

>the lines of "IPv6 First Fragment missing entire IPv6 header chain"?

>(I'm just thinking of IPv6 packets with no upper layer protocol, which

>would remain legal, but would not have an "upper layer protocol header")




>> 3) I'd also suggest a sentence or two clarifying that the

>>    ICMPv6 "Parameter Problem" with the new Reason Code

>>    is the appropriate message to send -- if the device dropping

>>    the packet with oversized-header-chain sends an ICMPv6

>>   message.  One would hope this would be obvious, but being

>>    very clear is good.




I'm not invested in HOW we provide feedback.  But THAT we provide the

information as clearly as possible.  Something that says explicitly to the 

user: "oversize-header-chain -- illegal first fragment received"  The user needs to 
know exactly what went wrong that got the packet dropped.

Bill Jouris
Inside Products, Inc.
925-855-9512 (direct)