[ovs-dev] [IPv6 IV: A New Hope 6/6] nicira-ext: Support matching IPv6 Neighbor Discovery messages.

Justin Pettit jpettit at nicira.com
Wed Feb 2 07:17:02 UTC 2011


On Feb 1, 2011, at 12:45 PM, Ben Pfaff wrote:

> One issue that comes to mind is ICMPv4 versus ICMPv6.  The datapath
> considers these the same under this set of patches, but in fact aren't
> they different enough to warrant different key values?  I don't think
> that ICMPv4 would ever have neighbor discovery messages, but
> flow_from_nlattrs() doesn't distinguish between them.  We could
> distinguish by using different attributes (e.g. ODP_KEY_ATTR_ICMPV4 and
> ODP_KEY_ATTR_ICMPV6) or by checking the dl_type in flow_from_nlattrs().

You've convinced me.  I went ahead and changed this in the previous patch, since that's where these are defined.

> Same comment for format_odp_key_attr() as in the previous patch: I don't
> think any of the fields are optional so I don't see why we would omit
> them from the output.

Actually, the source and target link layer (sll and tll) fields are part of the options section of neighbor solicitation messages and are truly optional (unlike ARP).  I've continued to omit them if they're all zeroes, but I can print them if you'd still prefer that.

> If nd_neighbor_solicit and nd_neighbor_advert have the same structure is
> there value in defining both structs at all?

I don't actually define them at all.  I'm assuming they're located in "/usr/include/netinet/icmp6.h".  I have the build assertion just to make sure that their definitions continue to be identical in the include file.

> I see some spurious use of & for the address of arrays in memcpy and
> memset calls.  Not a big deal though.


Whoops.  I cleaned up the ones that I spotted.

--Justin






More information about the dev mailing list