OPINION/BELIEF:

I concur with Fred Baker's analysis of "SHOULD" versus "MUST".

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.

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.  


ACTIONABLE SUGGESTIONS:

So....

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.

and

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.

and

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.

and

4) Security Considerations ought to note the importance of
   deploying Source Address Forgery Prevention filters, in
   order to reduce the threat of an adversary forging an
   illegal packet with contains a victim/target's IP address
   in the Source IPv6 Address field of the illegal packet.
   [RFC-2827, RFC-3704]

Yours,

Ran

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to