0

I've noticed strange behavior on one of my machines with Linux 4.8.0 (Debian Sid)

My ISPs router is sending IPv6 RAs as following:

        IP6 (hlim 255, next-header ICMPv6 (58) payload length: 128) fe80::5667:51ff:fee7:7cf > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 128
        hop limit 64, Flags [other stateful], pref high, router lifetime 180s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): <prefix>::/64, Flags [onlink, auto], valid time 1138201s, pref. time 533401s
      route info option (24), length 24 (3):  <prefix>::/64, pref=medium, lifetime=1143629s
      rdnss option (25), length 40 (5):  lifetime 360s, addr: <dns1> addr: <dns2>
      mtu option (5), length 8 (1):  1500
      source link-address option (1), length 8 (1): 54:67:51:e7:07:cf

This results in following routing table:

ip -6 r
<prefix>::/64 via fe80::5667:51ff:fee7:7cf dev eth0 proto ra metric 100  pref medium
fe80::5667:51ff:fee7:7cf dev eth0 proto static metric 100  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
default via fe80::5667:51ff:fee7:7cf dev eth0 proto static metric 100  pref medium

First entry is odd. All local subnet traffic is being forwarded via router which isn't very optimal. Also I have accept_ra_rt_info_max_plen set to 0.

On my other machine in the same subnet with Linux 4.7.0 (Debian Jessie) routing table looks like expected:

<prefix>::/64 dev eth0  proto kernel  metric 256  expires 1136467sec                       
fe80::/64 dev eth0  proto kernel  metric 256               
default via fe80::5667:51ff:fee7:7cf dev eth0  proto ra  metric 1024  expires 120sec hoplimit 64

What can be the reason for this behavior? How can I modify my config so traffic towards local subnet is not send via router?

3
  • Do you use NetworkManager, systemd-networkd, dhcpcd, or just the kernel's built-in RA processing? Does the behavior change if you downgrade the other host to 4.7? Dec 21, 2016 at 20:51
  • Yes, I'm using NetworkManager with standard Debian config. Behavior is the same on 4.7. Dec 23, 2016 at 14:35
  • Then it's most likely a bug in NM. Dec 23, 2016 at 14:57

1 Answer 1

0

These are the relevant bits of the router advertisement:

prefix info option (3), length 32 (4): p/64, Flags [onlink, auto], valid time 1138201s, pref. time 533401s
route info option (24), length 24 (3): p/64, pref=medium, lifetime=1143629s

The prefix information option (PIO) says that prefix p/64 is on-link. The route information option (RIO) says that p/64 can be routed through the router.

By default, Linux ignores RIOs:

$ sysctl -a 2>&1 | grep wlan0.accept_ra_rt_info_max_plen
net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen = 0

Therefore, the Debian Jessie behaviour is expected: the route information option is ignored, the on-link prefix is honoured, and you get an on-link route. On the other machine, some piece of software or another is probably changing the value of the sysconf — try this:

sysctl -a 2>&1 | grep rt_info_max_plen

I cannot find anything in RFC 4191 about whether a RIO should override a PIO or not, so I suppose that the behaviour is RFC-compliant. I agree with you that it is suboptimal.

All local subnet traffic is being forwarded via router which isn't very optimal.

It's not that bad. The first packet to each destination will be sent to the router, which will send a redirect to the sender which will cause it to insert a transient /128 route to the destination, and start sending packets directly to the destination. Yeah, it's a robust protocol.

How can I modify my config so traffic towards local subnet is not send via router?

You should fix your router so that it doesn't send the spurious RIO. Failing that, you should find which piece of software is changing the value of the sysconf mentioned above and disable it. But I wouldn't worry about it too much — the redirect mechanism will take care of the issue just fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .