On my LAN, I have 2 routers sending ICMPv6 RA. One is the default gateway advertising the IPv6 global prefix. The other one advertises the IPv6 ULA prefix. On a FreeBSD host, using the following interface configuration on /etc/rc.conf, the ULA address is marked as detached and its on-link route deleted from the routing table. ifconfig_em0="DHCP" ifconfig_em0_ipv6="inet6 accept_rtadv" # ifconfig em0 em0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=481009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER,NOMAP> ether 08:00:27:6b:a5:36 inet6 fe80::a00:27ff:fe6b:a536%em0 prefixlen 64 scopeid 0x1 inet6 fd09:xxxx:xxxx:xxxx:a00:27ff:fe6b:a536 prefixlen 64 detached autoconf inet6 2001:xxxx:xxxx:xxxx:a00:27ff:fe6b:a536 prefixlen 64 autoconf inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> This network setup works fine with other OS. The RA message details are the following: # rdisc6 em0 Soliciting ff02::2 (ff02::2) on em0... Hop limit : 64 ( 0x40) Stateful address conf. : No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 0 (0x00000000) seconds Reachable time : unspecified (0x00000000) Retransmit time : unspecified (0x00000000) Prefix : fd09:xxxx:xxxx:xxxx::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 180000 (0x0002bf20) seconds Pref. time : 90000 (0x00015f90) seconds Route : fd09:xxxx:xxxx::/60 Route preference : medium Route lifetime : 1800 (0x00000708) seconds Source link-layer address: XX:XX:XX:B0:FA:F4 from fe80::x:x:feb0:faf4 Hop limit : 64 ( 0x40) Stateful address conf. : No Stateful other conf. : Yes Mobile home agent : No Router preference : low Neighbor discovery proxy : No Router lifetime : 1800 (0x00000708) seconds Reachable time : unspecified (0x00000000) Retransmit time : unspecified (0x00000000) Prefix : 2001:xxxx:xxxx:xxxx::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 90000 (0x00015f90) seconds Pref. time : 90000 (0x00015f90) seconds Route : 2001:xxxx:xxxx:xxxx::/64 Route preference : high Route lifetime : 90000 (0x00015f90) seconds Source link-layer address: 00:XX:XX:9E:1D:2F from fe80::x:x:fe9e:1d2f
memorandum: RFC 4861 6.3.4.
Created attachment 235692 [details] workaround/wild hack when using ULA I confirm the bug, I detected the same. When the validity of prefix/address/router is checked, the own router advertisements and static address assignments are not considered. The attached patch does not fix the problem, but works for me as a workaround, because I use a unique local address for the FreeBSD router. That should also work for the original bug reporter. The patch does not prevent the change of address state to "detached", but keeps the route working and allows a static address with same prefix.
(In reply to Filipe Mendonça from comment #0) The router for the prefix fd09:xxxx:xxxx:xxxx::/64 has zero router lifetime. This excludes the router from the default router list, and the advertised prefix is marked as detached. This should be fixed if you have non-zero lifetime RAs from the router. Do you intentionally configure the router so that it emits zero-lifetime RAs?
(In reply to Hiroki Sato from comment #3) In my case I have also a router lifetime of 0. The reason is that the FreeBSD router is only responsible for the ULA prefix and is the gateway for this and one other prefix. It is not the default router in the segment. From RFC4861: "A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options."
(In reply to Frank Behrens from comment #4) Do you have a result of the "ndp -p" command when observing the detached address? I would like to know how the prefix was recognized to narrow down the cause. I guess it has D flag and is treated as unreachable for some reason.
(In reply to Hiroki Sato from comment #5) Your are right, (without my patch) the state switches from initial fdxx:xxxx:xxx:xxxx::/64 if=net3 flags=LO vltime=infinity, pltime=infinity, expire=Never, ref=1 No advertising router to fdxx:xxxx:xxx:xxxx::/64 if=net3 flags=LAD vltime=360000, pltime=36000, expire=%s, ref=2 No advertising router
(In reply to Hiroki Sato from comment #3) Like Frank's cenario, my ULA prefix router has a zero Router Lifetime due not being a default router for the segment. It is only responsible for the ULA prefix.
(In reply to Hiroki Sato from comment #5) Here's my output of "ndp -p" command: # ndp -p 2001:xxxx:xxxx:xxxx::/64 if=em0 flags=LAO vltime=90000, pltime=90000, expire=1d0h58m24s, ref=1 advertised by fe80::x:x:fe9e:1d2f%em0 (reachable) fd09:xxxx:xxxx:xxxx::/64 if=em0 flags=LAD vltime=180000, pltime=90000, expire=2d1h57m38s, ref=1 No advertising router fe80::%em0/64 if=em0 flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=1 No advertising router fe80::%lo0/64 if=lo0 flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=1 No advertising router
I have a similar issue, but slightly different. I have multiple interfaces: igc4/vlan1001. igc4 receives a default route/on-link prefix that is using a GUA and has a valid router lifetime of greater than 0. vlan1001 however is used only for storage traffic. It is a pure IPv6 only VLAN and configuration is done with ULA addressing, that is advertised with a router lifetime of 0. Unfortunately that means that when vlan1001 accepted the router advertisement it never installs the on-link route for the prefix it received, even though we expressly want to force that /64 onto vlan1001 (10 GbE) instead of out through igc4 (1 GbE). Even adding a manual IP address in the same /64 will not install the on-link route: igc4: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG> ether 20:7c:14:f4:83:f4 inet 172.16.109.131 netmask 0xffffff00 broadcast 172.16.109.255 inet6 fe80::227c:14ff:fef4:83f4%igc4 prefixlen 64 scopeid 0x5 inet6 2601:283:4c01:29a0:227c:14ff:fef4:83f4 prefixlen 64 autoconf pltime 604800 vltime 2592000 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> vlan1001: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000 options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,MEXTPG> ether 20:7c:14:f4:83:f5 inet6 fe80::227c:14ff:fef4:83f5%vlan1001 prefixlen 64 scopeid 0xb inet6 fd9b:d0c4:d2c8:736e::4 prefixlen 64 inet6 fd9b:d0c4:d2c8:736e:227c:14ff:fef4:83f5 prefixlen 64 detached autoconf pltime 604800 vltime 2592000 groups: vlan vlan: 1001 vlanproto: 802.1q vlanpcp: 0 parent interface: ix0 media: Ethernet autoselect (10Gbase-Twinax <full-duplex,rxpause,txpause>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> # ndp -p 2601:283:4c01:29a0::/64 if=igc4 flags=LAO vltime=2592000, pltime=604800, expire=29d23h59m32s, ref=1 advertised by fe80::4262:31ff:fe08:9276%igc4 (reachable) # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 172.16.109.1 UGS igc4 127.0.0.1 link#10 UH lo0 172.16.109.0/24 link#5 U igc4 172.16.109.131 link#10 UHS lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 link#10 URS lo0 default fe80::4262:31ff:fe08:9276%igc4 UG igc4 ::1 link#10 UHS lo0 ::ffff:0.0.0.0/96 link#10 URS lo0 2601:283:4c01:29a0::/64 link#5 U igc4 2601:283:4c01:29a0:227c:14ff:fef4:83f4 link#10 UHS lo0 fd9b:d0c4:d2c8:736e::4 link#10 UHS lo0 fd9b:d0c4:d2c8:736e:227c:14ff:fef4:83f5 link#10 UHS lo0 fe80::%lo0/10 link#10 URS lo0 fe80::%igc4/64 link#5 U igc4 fe80::227c:14ff:fef4:83f4%lo0 link#10 UHS lo0 fe80::%ix0/64 link#6 U ix0 fe80::227c:14ff:fef4:83f5%lo0 link#10 UHS lo0 fe80::%lo0/64 link#10 U lo0 fe80::1%lo0 link#10 UHS lo0 fe80::%vlan1001/64 link#11 U vlan1001 fe80::227c:14ff:fef4:83f5%lo0 link#10 UHS lo0 ff02::/16 link#10 URS lo0 # rdisc6 igc4 Soliciting ff02::2 (ff02::2) on igc4... Hop limit : 64 ( 0x40) Stateful address conf. : No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 1800 (0x00000708) seconds Reachable time : unspecified (0x00000000) Retransmit time : unspecified (0x00000000) Source link-layer address: 40:62:31:08:92:76 Prefix : 2601:283:4c01:29a0::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 2592000 (0x00278d00) seconds Pref. time : 604800 (0x00093a80) seconds Recursive DNS server : fd9b:d0c4:d2c8:6c6f::1 DNS server lifetime : 900 (0x00000384) seconds DNS search list : home.arpa DNS search list lifetime: 900 (0x00000384) seconds from fe80::4262:31ff:fe08:9276 # rdisc6 vlan1001 Soliciting ff02::2 (ff02::2) on vlan1001... Hop limit : 64 ( 0x40) Stateful address conf. : No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 0 (0x00000000) seconds Reachable time : unspecified (0x00000000) Retransmit time : unspecified (0x00000000) Source link-layer address: 40:62:31:08:92:76 Prefix : fd9b:d0c4:d2c8:736e::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 2592000 (0x00278d00) seconds Pref. time : 604800 (0x00093a80) seconds from fe80::4262:31ff:fe08:9276 Both FreeBSD and Linux will create an ip address, but Linux will happily install the on-link prefix, whereas FreeBSD will not. Note that I would expect that no matter what as long as a prefix does not clash with an existing prefix on the system, I would expect it to be installed on-link correctly, even if the router lifetime is 0 and there is no ::/0 route provided on that network segment. Whether that address is ULA (as is the case from Filipe or myself) or GUA, since the same issue exists when I use a GUA prefix on the same network. While searching for bugs I did find this other bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=104851 that seems to be somewhat related, and probably in the same part of the codebase.
(In reply to Delta Regeer from comment #9) Apologies for the additional email noise, I wanted to make sure to add that I am on FreeBSD 14.2-RELEASE.
^Triage: this PR does not really appear to be "In Progress".