[ovs-dev] [IPv6 Redux 6/6] nicira-ext: Support matching IPv6 Neighbor Discovery messages.

Justin Pettit jpettit at nicira.com
Mon Jan 24 02:01:24 UTC 2011


On Jan 23, 2011, at 11:46 AM, Jesse Gross wrote:

>>>> +invalid:
>>>> +       key->tp_src = htons(0);
>>>> +       key->tp_dst = htons(0);
>>> 
>>> Should we really zero out the type and code if we don't have a valid ND packet?
>> 
>> My concern was that if someone did something we disliked (e.g., setting two SLL options in a Neighbor Solictation message), then a rule writer would have a hard time distinguishing that from a (valid) NS message with no options.  I suppose they could drop based on "nd_target" being 0, but that seems really confusing.  I believe we were already going to suggest to people wishing to enforce ND policies that they drop all ICMPv6 traffic with "icmp_code=0".
> 
> I'm not sure I understand why you think that dropping based on
> nd_target is confusing.  If you think of ND as being essentially
> another protocol layer, then it is consistent with how we handle other
> protocols.  It's also consistent with how you implemented it: before
> this patch an invalid ND message would have a type and code but after
> the patch those are zeroed out.  Therefore, this (and any future
> parsing that we implement along these lines) changes preexisting
> behavior even if you aren't using them.

It now zeros out nd_target on this error.

> Do you mean drop traffic with icmp_type that is zero?  It seems like
> these messages all use code of zero.

Sorry, I meant to say "icmp_type" and not "icmp_code".

> Also, should we be checking the code when parsing?


Agh!  You're right.  Fixed.

--Justin






More information about the dev mailing list