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:
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
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
# 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.