sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c
connect: Invalid argument
Hierzu ist die offizielle Meinung, es kann mehr Interfaces geben, die das Link-Lokal-Netz fe80 anliegen haben. Man muss das Interface/Zone beim Pingen definieren.
Weg1
sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c%br0
PING fe80::cacb:b8ff:fece:6e8c%br0(fe80::cacb:b8ff:fece:6e8c) 56 data bytes
64 bytes from fe80::cacb:b8ff:fece:6e8c: icmp_seq=1 ttl=64 time=0.701 ms
Weg2:
PING fe80::cacb:b8ff:fece:6e8c(fe80::cacb:b8ff:fece:6e8c) from fe80::221a:6ff:fe5d:6989 br0: 56 data bytes
64 bytes from fe80::cacb:b8ff:fece:6e8c: icmp_seq=1 ttl=64 time=0.468 ms
Weg3:
sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c%4
PING fe80::cacb:b8ff:fece:6e8c%4(fe80::cacb:b8ff:fece:6e8c) 56 data bytes
64 bytes from fe80::cacb:b8ff:fece:6e8c: icmp_seq=1 ttl=64 time=0.476 ms
Leider sehe ich keinen Grund für die Definition des Source-Interfaces. Bei ipv4 entscheidet der Routing-Prozess das zu verwendende Interface:
sb@s1:~$ ip ro get 8.8.8.8
8.8.8.8 via 192.168.0.1 dev br0 src 192.168.0.101
Bei v6 sieht die Ausgabe auch korrekt aus – es interessiert den Prozess jedoch nicht:
sb@s1:~$ ip ro get fe80::cacb:b8ff:fece:6e8c
fe80::cacb:b8ff:fece:6e8c from :: dev br0 src fe80::221a:6ff:fe5d:6989 metric 0
sb@s1:~$ ping6 fe80::cacb:b8ff:fece:6e8c
connect: Invalid argument
Warum ist das so?