netdev - Re: [RFC PATCH net-next 00/11] Nested VLANs

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: <CAKOOJTzzV8Aiz3yn=a2o8mBW3xzxOPCWHFyu9KJJ9TBC4UAnYg@mail.gmail.com>
Date:   Wed, 27 May 2020 17:39:59 -0700
From:   Edwin Peer <edwin.peer@...adcom.com>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next 00/11] Nested VLANs - decimate flags and add another

On Wed, May 27, 2020 at 5:15 PM Michał Mirosław <mirq-linux@...e.qmqm.pl> wrote:

> Have you considered adding a 'vlan_headroom' field (or another name)
> for a netdev instead of a flag? This would submit easily to device
> aggregation (just take min from the slaves) and would also handle
> nested VLANs gracefully (subtracting for every layer).

Great idea, I think that would be much nicer.

> In patch 3 you seem to assume that if lower device reduces MTU below
> its max, then its ok to push it up with VLAN headers. I don't think
> this is apropriate when reducing MTU because of eg. PMTU limit for
> a tunnel.

Indeed. For non-tunnel devices I think this behavior is still correct,
because past the 1st hop (where device MTU should be appropriate), all
of L2, including any VLANs, has been replaced by something else. But
yes, tunnels probably do need to unconditionally reduce MTU, because
PMTU is something more dynamic. I guess I kind of half thought about
this for gre6, where this is what I did because PMTU is so much more
in your face for IPv6.

Regards,
Edwin Peer