netdev - Re: [RFC PATCH v2] ethtool: add IPv6 to the NFC API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1453692870.3734.195.camel@decadent.org.uk>
Date:	Mon, 25 Jan 2016 03:34:30 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Alexander Duyck <alexander.duyck@...il.com>,
	Edward Cree <ecree@...arflare.com>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH v2] ethtool: add IPv6 to the NFC API

On Fri, 2016-01-22 at 10:54 -0800, Alexander Duyck wrote:
> On Fri, Jan 22, 2016 at 10:04 AM, Edward Cree <ecree@...arflare.com> wrote:
[...]
> > +/**
> > + * struct ethtool_usrip6_spec - general flow specification for IPv6
> > + * @ip6src: Source host
> > + * @ip6dst: Destination host
> > + * @l4_4_bytes: First 4 bytes of transport (layer 4) header
> > + * @tos: Type-of-service
> > + * @proto: Transport protocol number (nexthdr after any Extension Headers)
> > + */
> > +struct ethtool_usrip6_spec {
> > +       __be32  ip6src[4];
> > +       __be32  ip6dst[4];
> > +       __be32  l4_4_bytes;
> > +       __u8    tos;
> > +       __u8    proto;
> > +};
> > +
> 
> It might be better to refer to this as l4_proto so that it is clear
> that this is specifying the protocol of the l4 header that the
> l4_4_bytes will be pulled from.

The comment seems to make it fairly clear.

> It still might even be useful to add a nexthdr field since it is
> possible that there may be NICs out there that don't support parsing
> the extension headers.  In such a case they could block setting
> protocol and use nexthdr instead.  It provides an indirect way of
> communicating if the NIC supports parsing extension headers or not as
> the NIC can block adding a filter on one mask being set or the other.

I don't think a NIC can do any useful flow steering for IPv6 without
being able to parse and skip over the extension headers.  It would be
like trying to match flows by looking at IPv4 header options.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
                                    A fail-safe circuit will destroy others.
Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)