Summary: | IPv6 address gets detached when using multiple IPv6 routers | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Filipe Mendonça <filipe> | ||||
Component: | kern | Assignee: | freebsd-net (Nobody) <net> | ||||
Status: | In Progress --- | ||||||
Severity: | Affects Only Me | CC: | frank, hrs, luke.hamburg, tatsuki_makino, zlei | ||||
Priority: | --- | ||||||
Version: | 13.0-RELEASE | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Filipe Mendonça
2022-05-15 12:08:01 UTC
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 |