--- On Thu, 7/19/12, Fernando Gont <fg...@si6networks.com> 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)
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
