I have the same issue:

#
# radvd configuration generated by radvdump 1.9.9
# based on Router Advertisement from fe80::c283:aff:fecd:7331
# received by interface wlp1s0
#

interface wlp1s0
{
	AdvSendAdvert on;
	# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
	AdvManagedFlag off;
	AdvOtherConfigFlag off;
	AdvReachableTime 1805000;
	AdvRetransTimer 0;
	AdvCurHopLimit 64;
	AdvDefaultLifetime 1800;
	AdvHomeAgentFlag off;
	AdvDefaultPreference medium;
	AdvLinkMTU 1472;
	AdvSourceLLAddress on;

	prefix 2602:30a:2c3f:5990::/64
	{
		AdvValidLifetime 2592000;
		AdvPreferredLifetime 604800;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;
	}; # End of prefix definition

}; # End of interface definition

[van@iafonichev-nb ~]$ cat /proc/sys/net/ipv6/conf/wlp1s0/mtu
1500

[van@iafonichev-nb ~]$ rpm -q NetworkManager
NetworkManager-0.9.9.0-44.git20131003.fc20.x86_64

Just as a workaround to ease your pain for now,... 

It should be easily possible to set the MTU later in the dispatcher scripts. See DISPATCHER SCRIPTS in `man NetworkManager`

Just as an additional data point, the NM included in Ubuntu Trusty does the right thing:

tore@hallgeir-System-Product-Name:~$ sudo rdisc6 eth0 | grep MTU
 MTU                      :         1480 bytes (valid)
tore@hallgeir-System-Product-Name:~$ cat /proc/sys/net/ipv6/conf/eth0/mtu
1480
tore@hallgeir-System-Product-Name:~$ dpkg -l network-manager | cat
Ønsket=Ukjent/Installer/Fjern/Rens ut/Hold tilbake
| Status=Ikke/Inst/Oppsettsfiler/Ikke pakket ut/HalvT-satt-opp/Halvt-inst/Ut-ventende
|/ Feil?=(ingen)/Må inst. på nytt (Status,Feil: versalar=dumt)
||/ Navn                                                  Versjon                                             Architecture Beskrivelse
+++-=====================================================-===================================================-============-====================================================================================
ii  network-manager                                       0.9.8.8-0ubuntu7                                    i386         network management framework (daemon and userspace tools)

Tore

Will work on this. Thanks for the report.

Created attachment 288104 [details]
Suggested fix

(In reply to comment #5)
> Created an attachment (id=288104) [details]
> Suggested fix

The MTU can already be set via NMSettingWired:mtu and DHCP.

I think this needs some coordination when different sources try to set the MTU.

For example, I think if having the mtu set via configuration, the DHCP/RA values should be ignored. When having both DHCP & RA, the smaller one should win, etc. (1)


Right now we track the MTU as part of NMIP4Config object. I think that is not technically correct (because MTU is also relevant without IP configuration and for IPv6).

Anyway, wherever we track it, I think it needs to be extended to be able to remember different values and it's origin...

nm_ip4_config_set_mtu (ip4_config, mtu, SOURCE_DHCP);
nm_ip4_config_set_mtu (ip4_config, rdist->mtu, SOURCE_RDISC);
nm_ip4_config_set_mtu (ip4_config, nm_connection_wired_get_mtu(...), SOURCE_CONFIG);

then nm_ip4_config_get_mtu() can merge the three values into a "best" one -- according to (1).

Created attachment 288153 [details]
[PATCH 1/2] core: Track origin of MTU

(In reply to comment #6)
> (In reply to comment #5)
> > Created an attachment (id=288104) [details] [details]
> > Suggested fix
> 
> The MTU can already be set via NMSettingWired:mtu and DHCP.
> 
> I think this needs some coordination when different sources try to set the MTU.
> 
> For example, I think if having the mtu set via configuration, the DHCP/RA
> values should be ignored. When having both DHCP & RA, the smaller one should
> win, etc. (1)
> 
> 
> Right now we track the MTU as part of NMIP4Config object. I think that is not
> technically correct (because MTU is also relevant without IP configuration and
> for IPv6).
> 
> Anyway, wherever we track it, I think it needs to be extended to be able to
> remember different values and it's origin...
> 
> nm_ip4_config_set_mtu (ip4_config, mtu, SOURCE_DHCP);
> nm_ip4_config_set_mtu (ip4_config, rdist->mtu, SOURCE_RDISC);
> nm_ip4_config_set_mtu (ip4_config, nm_connection_wired_get_mtu(...),
> SOURCE_CONFIG);
> 
> then nm_ip4_config_get_mtu() can merge the three values into a "best" one --
> according to (1).

Makes sense, adding second version of the patchset.

I've added source tracking & priorities, but kept it in ip4-config (does not seem trivial to move it away; at least I don't make things worse).

Created attachment 288154 [details]
[PATCH 2/2] rdisc,device: Set MTU if an appropriate option is present in a RA

(It's two patches now. https://github.com/lkundrak/NetworkManager/commits/lr-rdisc-mtu if you prefer.)

Does nm_platform_link_set_mtu only affect the IPv6 in /proc/sys/net/ipv6/conf/<device>/mtu ?  Because the IPv4 MTU should not be changed to the value in the IPv6 RA.

On Fedora 19 with NM 0.9.8 where the kernel is handling the IPv6 RA, "ip link show" and ifconfig still show 1500 for the device MTU, even though the IPv6 MTU in effect is different:

>cat /proc/sys/net/ipv6/conf/p4p1/mtu 
1480

>ip -4 link show p4p1
2: p4p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:10:18:5a:37:3b brd ff:ff:ff:ff:ff:ff

>ip -6 link show p4p1
2: p4p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:10:18:5a:37:3b brd ff:ff:ff:ff:ff:ff

>ifconfig p4p1
p4p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.26  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2001:470:8df7:1:210:18ff:fe5a:373b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::210:18ff:fe5a:373b  prefixlen 64  scopeid 0x20<link>
        ether 00:10:18:5a:37:3b  txqueuelen 1000  (Ethernet)
        RX packets 4545585  bytes 2293354760 (2.1 GiB)
        RX errors 8  dropped 0  overruns 0  frame 8
        TX packets 3463231  bytes 805605936 (768.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  


Thanks.

Created attachment 288189 [details]
[PATCH 2/2] rdisc,device: Set MTU if an appropriate option is present in a RA

(In reply to comment #9)
> Does nm_platform_link_set_mtu only affect the IPv6 in
> /proc/sys/net/ipv6/conf/<device>/mtu ?  Because the IPv4 MTU should not be
> changed to the value in the IPv6 RA.

Thanks for the correction. Attaching updated patch.

Branch works for me...

Though I guess maybe we should just add MTU to IP6Config, since theoretically DHCPv6 can return the MTU as well?  That could be a future thing though, the patches certainly fix the immediate issue.

(In reply to comment #11)
> Branch works for me...
> 
> Though I guess maybe we should just add MTU to IP6Config, since theoretically
> DHCPv6 can return the MTU as well?

In theory yes, but I think it's quite unlikely. At least I got an impression that redundant means of configuring the same information with NDP and DHCPv6 (as had been done with DNS) are frowned upon these days and currently the DHCPv6 option to configure a MTU does not exist:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

>> core: Track origin of MTU


 #include "nm-setting-ip4-config.h"
+#include "nm-platform.h"

I think we should move the declaration of NMPlatformSource to nm-types.h .



>> rdisc,device: Set MTU if an appropriate option is present in a RA

+               * from the link, even the link-local, and we wouldn't be able to
+               * listen for further RAs that could fix the MTU. */
+              error ("(%s): MTU too small for IPv6 ignored: %d", rdisc->ifname, mtu);

I think, this is only worth a warning(). error() is already the highest severity we have...


LGTM

merged as:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=60aee59f18a57b7ad5dbd32adb7f9fb11d67617b