No estoy completamente convencido de que mi solución sea correcta, pero al menos puedo arrojar un poco más de luz sobre lo que está sucediendo.
Antecedentes
Linux en realidad tiene múltiples tablas de enrutamiento, y se buscan una a la vez en un orden de prioridad específico hasta que se encuentra una tabla con una ruta coincidente. Opcionalmente, puede buscar algunas de las tablas de enrutamiento en función de la dirección o el protocolo de origen; ver el ip-rule(8) página man.
El problema es la tabla de enrutamiento "local", que tiene prioridad 0, la más alta posible. El núcleo rellena automáticamente la tabla "local" y contiene rutas de transmisión e interfaz "obvias". Para IPv6 bajo Linux, esto aparentemente incluye todo el bloque de multidifusión.
El problema
Voy a utilizar iproute2 herramienta en lugar de la más tradicional route , porque me mostrará todo lo que necesito saber.
En mi caja de Linux:
$ ip -6 route show table local
local ::1 via :: dev lo proto none metric 0
local fe80::213:a9ff:fe91:5bcb via :: dev lo proto none metric 0
local fe80::250:b6ff:fe44:37d1 via :: dev lo proto none metric 0
ff00::/8 dev eth0 metric 256
ff00::/8 dev eth1 metric 256
$ ip -6 route show table main
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 256
ff15::/16 dev eth1 metric 1024
ff00::/8 dev eth1 metric 1024
$ ip -6 rule show
0: from all lookup local
32766: from all lookup main
...Y mis paquetes de multidifusión para ff15::1 (5==site-local,>link-local) terminan en eth0, porque la tabla de enrutamiento "local" coincide primero y anula la tabla "principal", aunque el La tabla "principal" tiene una ruta más específica. Este comportamiento predominante es correcto en el esquema más amplio de enrutamiento de políticas, pero la elección de agregar automáticamente ff00::/8 a la tabla local es cuestionable para mí.
Mi solución
No tengo suficiente experiencia para saber si es una buena idea, pero:
# ip -6 route add ff15::/16 dev eth1 table local
y ahora mis paquetes ff15::1 se enrutan a través de eth1.
Esto concuerda un poco con la semántica de la tabla local, ya que se enruta directamente a través de un dispositivo. No se siente exactamente bien (considerando la administración automática y "no debería tener que mirar esta tabla"), pero es la mejor solución que he encontrado.