From: Dan Williams <dcbw@redhat•com>
To: Harout Hedeshian <harouth@codeaurora•org>
Cc: David Miller <davem@davemloft•net>,
netdev@vger•kernel.org, Vadim Kochan <vadim4j@gmail•com>
Subject: Re: [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA
Date: Mon, 26 Jan 2015 09:03:48 -0600 [thread overview]
Message-ID: <1422284628.2393.4.camel@dcbw.local> (raw)
In-Reply-To: <54C519B3.9050905@codeaurora.org>
On Sun, 2015-01-25 at 09:28 -0700, Harout Hedeshian wrote:
> On 01/25/2015 12:21 AM, Vadim Kochan wrote:
> > On Sat, Jan 24, 2015 at 11:14:32PM -0800, David Miller wrote:
> >> From: Harout Hedeshian <harouth@codeaurora•org>
> >> Date: Tue, 20 Jan 2015 10:06:05 -0700
> >>
> >>> The kernel forcefully applies MTU values received in router
> >>> advertisements provided the new MTU is less than the current. This
> >>> behavior is undesirable when the user space is managing the MTU.
> > Instead
> >>> a sysctl flag 'accept_ra_mtu' is introduced such that the user space
> >>> can control whether or not RA provided MTU updates should be applied.
> > The
> >>> default behavior is unchanged; user space must explicitly set this
> > flag
> >>> to 0 for RA MTUs to be ignored.
> >>>
> >>> Signed-off-by: Harout Hedeshian <harouth@codeaurora•org>
> >> Under what circumstances would userland ignore a router advertized
> >> MTU, and are the RFCs ok with this?
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majordomo@vger•kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Hi,
> >
> > I don't know if it make sense but I had the same use case when was
> > working on supporting IPv6 infrastructure for home gateway.
> > One of the provider had requirements to have ability set force IPv6 MTU
> > value via TR parameters and disable update it via RA.
> Hi David,
>
> We are optionally allowing the kernel shift this responsibility to the
> userland. The idea would be that the kernel would ignore it, not so much
> the userland. Just like Vadim, we may not want to use the MTU value
> which comes from the network. Instead, we get an MTU value from the
> cellular modem via configuration message, and that is the MTU we use.
Are you talking about an ethernet interface exposed by the modem, or a
separate network interface connected to a normal LAN? In the modem
case, why would the network-provided RA's MTU be incorrect, but the
modem's MTU be correct? If the normal LAN case, why would the modem's
MTU be correct for a different network that is broadcasting its own RAs?
Just curious...
Dan
> In any case, none of the RFCs state that the kernel must update the MTU
> and that the userland cannot. In fact, there is no mention of
> kernel/user space at all in the RFC for this particular RA message. What
> if someone wants to listen to these RA messages from userland and update
> the MTU? Surely, that won't violate the RFC. In such a case, the kernel
> is unnecessarily forcing policy on the user space.
>
> RFC4861 section 4.6.4 defines the MTU update option (RA option 5) for RA
> messages. I don't see any language where the receiver "MUST" apply this
> option. It merely states that the MTU value in the RA is "The
> recommended MTU for the link." The description goes on to point out why
> this option can be used by the router, but does not specifically enforce
> it. The only receive action specifically enforced by the RFC is that
> "This option MUST be silently ignored for other Neighbor Discovery
> messages."
>
> The risk of not applying the MTU updates is that packet may get dropped
> if path MTU discovery is disabled or broken on the network. HOWEVER,
> anyone explicitly setting accept_ra_mtu to 0 is already taking
> responsibility for enforcing the correct MTU. Since this patch by
> default does not change the kernel behavior, I don't see it breaking for
> users who are unaware of this option.
>
>
> Thanks,
> Harout
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger•kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-01-26 15:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-20 17:06 [PATCH v3 net-next] net: ipv6: Add sysctl entry to disable MTU updates from RA Harout Hedeshian
2015-01-25 7:14 ` David Miller
2015-01-25 7:21 ` Vadim Kochan
2015-01-25 16:28 ` Harout Hedeshian
2015-01-26 15:03 ` Dan Williams [this message]
2015-01-26 16:16 ` Harout Hedeshian
2015-01-26 21:32 ` Dan Williams
2015-01-26 16:19 ` Hannes Frederic Sowa
2015-01-26 17:27 ` Bjørn Mork
2015-01-25 22:55 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1422284628.2393.4.camel@dcbw.local \
--to=dcbw@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=harouth@codeaurora$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=vadim4j@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox