I'm in the process of setting up bridging, so I add the following lines to /etc/rc.conf:
ifconfig_bridge0="addm bge0 SYNCDHCP up"
This works just fine. However, when I remove the files from /etc/rc.conf and instead add them to /etc/rc.conf.d/netif things break. The netif file does get processed, but /etc/rc.d/dhclient incorrectly throws the following warning:
'bridge0' is not a dhcp-enabled interface
In my view, it shouldn't make a difference whether I put my configuration in /etc/rc.conf or in /etc/rc.donf.d/netif but apparently it does.
I'm fairly attached to having separate files /etc/rc.conf.d because it makes managing the setup through Puppet just so much easier.
I just found this report while in the process of figuring out the same issue. I figure I should just as well provide some details and findings.
The reason why that configuration doesn't work when placed in /etc/rc.conf.d/netif is that the service that handles dhcp is dhclient, which goes and look for its configuration in /etc/rc.conf.d/dhclient.
Now, both netif and dhclient will also load /etc/rc.conf.d/network. (`load_rc_config network' in both of those services file). However, there is a comment against this loading line in /etc/rc.d/netif stating that this is loaded for compatibility, which I interpret as meaning that it might not work forever.
It seems like there is a more general issue with the /etc/rc.conf.d/ mechanism not being well-suited for handling variables used in network.subr. Any rc script including network.subr could start making use of a functionality that depends on one of those variables in the future and result in breakage for people having one of those set in /etc/rc.conf.d, but for another script. It would be good to get some clarity here in order to avoid such unexpected configuration issues.
In the meanwhile, I think it is prudent to use /etc/rc.conf for any variable that ends up being "shared" between rc scripts in this fashion.