[ovs-dev] [IPv6 IV: A New Hope 6/6] nicira-ext: Support matching IPv6 Neighbor Discovery messages.
blp at nicira.com
Tue Feb 1 20:45:10 UTC 2011
On Tue, Feb 01, 2011 at 12:53:53AM -0800, Justin Pettit wrote:
> IPv6 uses Neighbor Discovery messages in a similar manner to how IPv4
> uses ARP. This commit adds support for matching deeper into the
> payloads of Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
> messages. Currently, the matching fields include:
> - NS and NA Target (nd_target)
> - NS Source Link Layer Address (nd_sll)
> - NA Target Link Layer Address (nd_tll)
> When defining IPv6 Neighbor Discovery rules, the Nicira Extensible Match
> (NXM) extension to OVS must be used.
> Signed-off-by: Justin Pettit <jpettit at nicira.com>
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().
There might be other reasons to distinguish (or to merge) ICMPv4 and
ICMPv6, I haven't thought it through carefully.
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.
If nd_neighbor_solicit and nd_neighbor_advert have the same structure is
there value in defining both structs at all?
I see some spurious use of & for the address of arrays in memcpy and
memset calls. Not a big deal though.
More information about the dev