Re: [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation

["Bjørn Mork" <bjorn@mork.no>]

Eric Dumazet <eric.dumazet@gmail.com> writes:
> Le samedi 05 novembre 2011 à 01:39 -0700, François-Xavier Le Bail a
> écrit :
>
>> Agreed, but remain the case of ICMPv6 echo request/reply, which I think is in kernel.
>
> Yes, please describe your setup and how to reproduce the problem.

I agree with François-Xavier that the current behaviour is confusing. An
anycast address should really not be treated different from any other
global unicast address by the kernel.


1) The router anycast address does not show up in the list of local
   addresses:

router:~$ ip -6 addr show dev br0.666
15: br0.666@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 
    inet6 2001:db8:9:29a::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::215:17ff:fe1e:5e35/64 scope link 
       valid_lft forever preferred_lft forever



2) pinging the anycast address will produce a reply from another
address: 

frtest1:~# ping6 -n -c1 2001:db8:9:29a::  
PING 2001:db8:9:29a::(2001:db8:9:29a::) 56 data bytes
64 bytes from 2001:db8:9:29a::1: icmp_seq=1 ttl=64 time=0.275 ms

--- 2001:db8:9:29a:: ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.275/0.275/0.275/0.000 ms
frtest1:~# ping6 -n -c1 2001:db8:9:29a::1  
PING 2001:db8:9:29a::1(2001:db8:9:29a::1) 56 data bytes
64 bytes from 2001:db8:9:29a::1: icmp_seq=1 ttl=64 time=0.229 ms

--- 2001:db8:9:29a::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.229/0.229/0.229/0.000 ms



3) the previous issue will become even more obviously buggy if we add a
second address to the router, in the same subnet while pinging the
anycast address.  Here I'm doing 

  router:/tmp# ip addr add 2001:db8:9:29a::5/64 dev br0.666

on the router while I'm pinging the anycast address from a another host:


frtest1:~# ping6 -n  2001:db8:9:29a::  
PING 2001:db8:9:29a::(2001:db8:9:29a::) 56 data bytes
64 bytes from 2001:db8:9:29a::1: icmp_seq=1 ttl=64 time=330 ms
64 bytes from 2001:db8:9:29a::1: icmp_seq=2 ttl=64 time=0.268 ms
64 bytes from 2001:db8:9:29a::1: icmp_seq=3 ttl=64 time=0.234 ms
64 bytes from 2001:db8:9:29a::5: icmp_seq=4 ttl=64 time=0.232 ms
64 bytes from 2001:db8:9:29a::5: icmp_seq=5 ttl=64 time=0.298 ms
64 bytes from 2001:db8:9:29a::5: icmp_seq=6 ttl=64 time=0.279 ms


Now, THAT doesn't look good, does it?


4) just to add to issue 2.  After adding the second address on the
router, we have 3 global unicast addresses in the same subnet. You would
then expect the kernel to either use the destionation address of the
incoming requests as source, or always select the same address as
source.

It does neither.  This is inconsistent, unless you treat the router
anycast address as something special.  Which you should not:


frtest1:~# ping-n -c1 2001:db8:9:29a::  
PING 2001:db8:9:29a::(2001:db8:9:29a::) 56 data bytes
64 bytes from 2001:db8:9:29a::5: icmp_seq=1 ttl=64 time=337 ms

--- 2001:db8:9:29a:: ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 337.251/337.251/337.251/0.000 ms
frtest1:~# ping6 -n -c1 2001:db8:9:29a::1  
PING 2001:db8:9:29a::1(2001:db8:9:29a::1) 56 data bytes
64 bytes from 2001:db8:9:29a::1: icmp_seq=1 ttl=64 time=0.163 ms

--- 2001:db8:9:29a::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.163/0.163/0.163/0.000 ms
frtest1:~# ping6 -n -c1 2001:db8:9:29a::5 
PING 2001:db8:9:29a::5(2001:db8:9:29a::5) 56 data bytes
64 bytes from 2001:db8:9:29a::5: icmp_seq=1 ttl=64 time=3.87 ms

--- 2001:db8:9:29a::5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.873/3.873/3.873/0.000 ms





Bjørn