IPv6: rtadvd never propagates prefix
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 03 Jul 2021 14:23:04 UTC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, running a small homebrewn FreeBSD 13-STABLE based router/ipfw applance on an APU2C4. WAN interface is tun0 (physically attached to igb0, connected with a modem), opened via ppp (PPPoE). Situation: On IPv6 subnets (ULAs, fc50:baff::, fc50:baff:2::, fc50:baff:66::, fc50:baff:100::), isc-dhcpd serves propper IPv6 addresses to clients attached to the subnet. igb1.1000 ipv6: fc50:baff::1 igb1.2 ipv6: fc50:baff:2::1 . . . igb1.100 ipv6: fc50:baff:100::1 On the router itself, rtadvd is enabled and the appropriate VLAN NICs are passed via /etc/rtadvd.conf (did also via rc.conf's rtadvd_interfaces"", but without any mitigating effect): default: :prefixlen#64: igb1.1000:\ :tc=default:\ :addr="c50:baff::": . . . igb1.100:\ :tc=default:\ :addr="c50:baff:100::": There is no special routing service running on the "router". No static routes configured. The "router" is forwarding between those IPv4 and IPv6 networks as expected. Problem: On clients receiving their IPv6 via DHCPv6 the default gateway never shows up as expected when using rtsold em0 (for instance on a notebook wired to a switch) On each sunbnet (separated by a vlan capable switch) routing via the router works great when applying the proper gateway, for instance on network ipv6 with prefix igb1.1000 ipv6: fc50:baff:2::/64 it is fc50:baff:2::1 (the ipv6 of the NIC/VLAN). What am I missing here? I think this is not a bug, I'm new to IPv6 and routing and probablz my thinking that rtadvd is propagating the IPv6 of the attached gatewaying NIC as the router IPv6 for the specific prefix seems to be bullshit. If someone knows some good entry level literature on that subject (IPv6 routing), please share with me. Thanks for the patience and help in advance, oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCYOBy4wAKCRA4N1ZZPba5 R7CsAQCx++D/gB8uSlQ3ZhrIJUKHVguwVVCd3NKitauzgFMVQAEAhGqKH7E9A5YD wza+v5kSUCIXNM2tf/mB9EjGvUkMigA= =G+MV -----END PGP SIGNATURE-----