On Tue, 9 Aug 2022, at 6:21 AM, Roy Marples wrote:
> On 08/08/2022 21:40, Hiroki Sato wrote:
>> Roy Marples wrote
>>in <4516f415-939e-6374-45ce-df19a2ac6...@marples.name>:
>>
>> ro> On 07/08/2022 15:23, Hiroki Sato wrote:
>> ro> > 1) Import dhcpcd and make it invoked via Other Configuration flag
>> ro> > in RA for DHCPv6. This means that the rtsold daemon remains a
>> ro> > consumer of RA messages, and the default value of the -O option is
>> ro> > set to run dhcpcd.
>> ro>
>> ro> I don't think this is a viable option as there is no easy way to
>> ro> transition from Other to Managed (or the other way around) from the
>> ro> dhcpcd commandline or signals.
>>
>> The rtsold daemon just invokes a corresponding helper script when
>> receiving RAs with these flags. A transition from O to M or vice
>> versa is supposed to be handled by them. I think it is possible to
>> stop the running dhcpcd and/or restart it with another configuration
>> via the scripts. Is there a critical problem with it? I do not
>> insist that it is the best way since it is not a graceful transition,
>> but I still believe it should work for most DHCPv6-enabled networks.
>>
>> ro> Also, please consider than dhcpcd supports DNSSL and RDNSS options
>> ro> from RA messages whereas FreeBSD rtsold/kernel RA do not (please
>> ro> correct me if I'm wrong).
>>
>> The FreeBSD rtsold has supported them for >10 years. Resolvconf, one
>> of your projects, was imported at the same time to solve the problem
>> of multiple information source for /etc/resolv.conf.
>>
>> ro> Sure it works fine for the one interface wired system - which
>> ro> admitedly is the most popular setup. But when more than one interface
>> ro> comes into play or you have plugable interfaces it then becomes more
>> ro> complicated and will consume more resources having many more daemon
>> ro> runing to allow capsicum and makes dhcpcd just as predictable as
>> ro> dhclient on a multi-homed system (ie it's not predictable).
>> ro>
>> ro> I modified wpa_supplicant upstream to support the -M directive (I
>> ro> don't know if FreeBSD compiles wpa_supplicant with CONFIG_MATCH_IFACE
>> ro> defined) to allow plugable interfaces just for this reason.
>>
>> I agree that running processes for each interface independently is
>> sub-optimal. However, I think it is a separate topic from whether
>> importing a DHCPv6 client into the base system or not. More
>> specifically, the following three are orthogonal:
>>
>> 1. Use dhcpcd or not as a replacement of dhclient and rtsold.
>>
>> This leads to a never-ending discussion. Some people like the
>> existing ones because they have worked well and do not want to
>> change.
>>
>> 2. Adopt a single process managing the multiple interfaces on the
>> system or use per-interface processes.
>>
>> Changing this requires a lot of work and breaks the existing
>> configurations. A side node of the design and behavior of the
>> current rc.d/netif is as follows:
>>
>> - The current rc.d/netif (and other network-related rc.d scripts
>> such as rc.d/wpa_supplicant) are based on the per-interface
>> model. The rc.d/netif script is invoked asynchronously while it
>> also runs at boot time sequentially. This asynchronous
>> invocation is specific to FreeBSD, and not seen in other BSDs
>> (correct me if I am wrong).
>>
>> - The devd(8) daemon is the main process receiving events of the
>> interfaces such as arrival/departure/link-state changes, and
>> invokes a process upon an event if necessary.
>>
>> - The rtsold(8) daemon is the main process receiving RAs in
>> userland and invokes a process upon an event if necessary.
>> Currently, it handles O/M flags and RDNSS/DNSSL options.
>>
>> 3. Add an implementation of the DHCPv6 client-side functionality or
>> not.
>>
>> I believe no one objects for adding one because we have no
>> implementation in the base system. Some people like another one,
>> such as ISC dhclient or WIDE dhcp6.
>>
>> My opinion is: 1) "no need", 2) "keep the current model for a while",
>> and 3) "go for it". I tend to prefer WIDE dhcp6 because I have used
>> it for >15 years with accumulated local patchset, but I do not stick
>> to it as long as there is a good working implementation supporting
>> IA_NA and IA_PD, and someone actively maintains it. WIDE dhcp6 works
>> well, but it has a lot of rough edges (and fixed locally by many
>> people, as bz@ pointed out).
>>
>> As mentioned in my previous email, avoiding POLA violations is the top
>> priority. Regardless of which implementation we import, I still
>> believe keeping the current per-interface model is the least
>> intrusive for the existing configurations.
>>
>> So we need a consensus about how to get started with the integration.
>> An idea in my mind is: 1) import dhcp
