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

[Bill Jouris <[e-mail]>]

--- On Thu, 7/19/12, Fernando Gont <[e-mail]> 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

better.


>


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


>


>Agreed.


>

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:


>> 


>>    CODE     NAME/DESCRIPTION


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


>


>Ok.


>


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.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)