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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 31 Mar 2015 16:05:38 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	klamm@...dex-team.ru
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	hannes@...essinduktion.org
Subject: Re: [PATCH v3] net: sysctl for RA default route MTU

From: Roman Gushchin <klamm@...dex-team.ru>
Date: Mon, 30 Mar 2015 15:30:57 +0300

> This patch introduces new ipv6 sysctl: ra_default_route_mtu.
> If it's set (> 0), it defines per-route MTU for any new default route
> received by RA.
> 
> This sysctl will help in the following configuration: we want to use
> jumbo-frames for internal networks and default ethernet frames for
> default route. Per-route MTU can only lower per-link MTU, so link MTU
> should be set to ~9000 (statically or via RA).
> 
> Due to dynamic nature of RA, setting MTU for default route will require
> userspace agent, that will monitor changes of default route
> and (re)configure it. Not simple. The suggested sysctl solves this
> problem.
> 
> Signed-off-by: Roman Gushchin <klamm@...dex-team.ru>
> Acked-by: Hannes Frederic Sowa <hannes@...essinduktion.org>

I don't like this change at all.  The way I see things you already
have the mechanisms necessary to do this.

You obviously control the entity providing the default routes and
these RA messages, therefore you absolutely can configure it to
provide an appropriate MTU value in those RA messages.

Problem solved, and no kernel changes necessary.

I am warning you ahead of time that I will have a very low tolerance
for replies to this email containing stories explaining why this is
"difficult" to do.  The fact is that the mechanism is there and if you
have designed things at your site in a way such that the mechanism
designed for this has become less useful, that isn't my problem.

I'm not adding facilities that duplicated existing methods that
already exist to accomplish this task.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ