Created attachment 148500 [details] Allow userland to submit IPv6 prefix routes Userland cannot add IPv6 prefix routes because the kernel assumes it will always be the one handling prefix routes from Router Advertisements. Both NetBSD and OpenBSD have added checks to allow for neighbors on routes marked RTF_CLONING, but FreeBSD dropped this routing flag a while ago. As such, the only similar check that can be made is against the absence of RTF_STATIC. Attached is a patch that implements this and allows dhcpcd-6.5.1 to work entirely on FreeBSD.
Are there any issues with the proposed change that prevent it from being added for inclusion in FreeBSD??
It might be desirable to add a new flag to mark neighbour routes, maybe RTF_CONNECTED. It could even have the same value as the old RTF_CLONING one. I think that's the only point for discussion really, but someone from FreeBSD needs to lead it.
Note, this is only an issue if the kernel has received a default router from a RA. So the use case where this fails is the kernel receives a RA from upstream router and a DHCPv6 client receives a Prefix Delegation from upstream router. In this case no node on the downstream prefixes will be treated as a valid neighbour. The workaround is to disable RA handling in the kernel and let a userland application (such as dhcpcd) handle it.
I created phabricator D15404 and D15405 as my attempt to port the changes to 12.0-CURRENT while using RTF_CONNECTED. I needed to use RTF_CONNECTED instead of RTF_STATIC for dhcpcd 7.0.3 (it doesn't add the RTF_STATIC flag.)
I tried review D15404 and review D15405 then later saw that review D15406 was also referenced. Now with rc.conf containing: ifconfig_re0="DHCP" ifconfig_re0_ipv6="inet6" dhclient_program="/usr/local/sbin/dhcpcd" and dhcpcd-7.1.1 installed - changed Makefile version and ran: make makesum && make install I used pfsense DHCPv6 and the router mode set to "managed" I was able to get static IPv6 address assigned I am using kernel: FreeBSD 13.0-CURRENT #2 r346220M Notes: 1. with only first two patches a kernel panic occurs adding the review D15406 patch appears to have fixed things. 2. the patch in this bug report does not apply and I think it is superceded by the patches from reviews
Assignee timeout (11 months), reset assignee If the reviews don't still apply to head, we may need a single cumulative/complete patch (from each of the three reviews, if/where applicable), rebased against latest head. @Christopher Can you clarify which one or more of the three reviews was used (applied) that resulted in a successful outcome?
All three reviews were applied to make it work and were applied in order.
Just the three reviews were used - the patch in this bug report was NOT used, I thinke the combination of the three reviews is sufficient
The comment I made almost 5 years ago about how to handle the now missing RTF_CLONING still applies. NetBSD used RTF_CONNECTED in it's place, so is more descriptive and probably the better option.
(In reply to roy from comment #9) Ignore me, it's added in the firsrt review patch, which I should have ... uh.... reviewed!
I have just did a fresh install of 12.0-RELEASE, used freebsd-update to get to 12.0-RELEASE-p3 and compiled a kernel with the 3 review patches as referenced in comment #5 (Patches applied without error and no error on buildkernel) # uname -r 12.0-RELEASE-p3 # pkg info |grep dhcpcd dhcpcd-7.1.1 DHCP/IPv4LL/IPv6RS/DHCPv6 client The system is running and it acquire both IPv4 and IPv6 addresses; alsoI was able to set static values for both on pfsense DHCP/DHCPv6 sucessfully.
Raised https://reviews.freebsd.org/D23695 as an alternative approach not involving RTF_CONNECTED flag.
Committed to current: https://reviews.freebsd.org/rGf998535a66b986f51dd65b5153d1a580d50ddfbe And STABLE13: https://reviews.freebsd.org/rG95b5ff22a93c50911f167ad11ffc25d6a9413fc9 Do we still want to MFC to STABLE12 @Melifaro? If not we can close this PR.
I think it is fine to merge to stable/12 if folks are so inclined, but as there are no more releases it also will have a limited impact.
Routing part of stable/13 and stable/12 has drifted apart too much. I don't think the patch can apply directly to stable/12.
Given the above statement and considering that 12-STABLE is only supported until end of 2023, lets close this and not backport to 12-STABLE.