Re: Import dhcpcd(8) into FreeBSD base
On Tue, Aug 9, 2022 at 8:57 AM Roy Marples wrote: > > On 08/08/2022 23:27, George Michaelson wrote: > > Yes. and I was trying to say, the rc.d system should alllow this to > > say "It wont work, you had rtsold_enabled=YES set" because these have > > to be either/or in my understanding of things. > > > > You can't both do SLAAC and DHCPv6. Its either/or. > > This is not true, you can do one or the other or both. Thanks for the correction Roy. I've been under a misapprehension for over a decade. -G
Re: Import dhcpcd(8) into FreeBSD base
Yes. and I was trying to say, the rc.d system should alllow this to say "It wont work, you had rtsold_enabled=YES set" because these have to be either/or in my understanding of things. You can't both do SLAAC and DHCPv6. Its either/or. On Tue, Aug 9, 2022 at 8:22 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
[Bug 263986] IPv6 address gets detached when using multiple IPv6 routers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263986 Hiroki Sato changed: What|Removed |Added Status|New |In Progress --- Comment #5 from Hiroki Sato --- (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. -- You are receiving this mail because: You are the assignee for the bug.
Re: Import dhcpcd(8) into FreeBSD base
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 dhcpcd (or whatever supports per-interface mode), 2) add a per-interface helper script for it, and 3) set rtsold_enable="YES" effectively by default for all RA-accepting interfaces so that people do not need to manually configure it at least on an IPv6 network with M/O bit enabled. This should be enough for IA_NA. More complicated configurations can be supported incrementally. And I hope this discussion focuses on how to
Re: Import dhcpcd(8) into FreeBSD base
"Bjoern A. Zeeb" wrote in : bz> >> In 1)+2), there is no POLA for users of other DHCPv6 clients such as bz> >> dhcp6c or ISC's dhclient -6. A full-blown dhcpcd configuration, bz> >> which replaces dhclient/rtsold, is still possible. The cons are that bz> >> this is a partial integration of dhcpcd, which prevents some useful bz> >> feature available in the master mode, and some complexity remains in bz> >> the rc.d scripts. I think these are a trade-off. I am interested in bz> >> whether this integration has a big problem when people use the bz> >> imported dhcpcd. bz> >> bz> >> And probably we have to revisit this integration when we want to bz> >> support DHCP 4o6 or something that involves IPv4 and IPv6 at the same bz> >> time. The flexibility of the "toolbox" approach would be helpful in bz> >> minimizing the impact on the existing configurations when more future bz> >> integration change occurs. bz> > bz> > Agreed. I noted my concerns above and would favour a full blown dhcpcd configuration for new installs and leave the current dhclient/rtsold for exising installs. No need to force people to move. bz> bz> I think that is a very sensible approach to do it incrementally. bz> bz> If people can agree on bz> (1) importing it and first closing the gap of the missing DHCPv6 client making bz> sure it does all people have accumultaed over the years, bz> (2) and then solving the "how do I disable dhclient and rtsold and per-IF configs bz> and just run the-one-thing as an alternative in rc" in the 2nd step I agree with (1) before 14 and discussing (2) after that, separately. -- Hiroki pgpAIw3yZbWyo.pgp Description: PGP signature
RE: Import dhcpcd(8) into FreeBSD base
> -Original Message- > From: owner-freebsd-...@freebsd.org On > Behalf Of Bjoern A. Zeeb > Sent: Monday, 8 August 2022 18:43 > To: Roy Marples > Cc: freebsd-net@freebsd.org > Subject: Re: Import dhcpcd(8) into FreeBSD base > > On Mon, 8 Aug 2022, Roy Marples wrote: > > > Also, please consider than dhcpcd supports DNSSL and RDNSS options > > from RA messages whereas FreeBSD rtsold/kernel RA do not (please > > correct me if I'm wrong). > > This allows for a fully working IPv6 only setup without DHCPv6. > > Yeah I think we had that for over a decade... (as it has been pointed out before > in older threads as well) > > commit db82af41db538fba5938d8585b2e2e2c206affb6 > Author: Hiroki Sato > AuthorDate: Mon Jun 6 03:06:43 2011 + > Commit: Hiroki Sato > CommitDate: Mon Jun 6 03:06:43 2011 + > > - Implement RDNSS and DNSSL options (RFC 6106, IPv6 Router > Advertisement >Options for DNS Configuration) into rtadvd(8) and rtsold(8). DNS >information received by rtsold(8) will go to resolv.conf(5) by >resolvconf(8) script. This is based on work by J.R. Oldroyd (kern/156259) >but revised extensively[1]. > > ... > > > > >> 2) Keep the dhclient utility intact and add a knob to choose dhclient > >> or dhcpcd (or something else) for DHCPv4. The current rc.d > >> scripts for DHCPv4 can be adjusted to use another client > >> supporting a per-interface mode. > > > > I would argue that having knobs to control dhcpcd (or any other > > similar network tool for that matter) in rc.conf per interface is a > > bad idea because this discourages running dhcpcd in manager mode. You > > even note this below, but here are some more comments. > > FreeBSD since we last time changed dhclient have had a very liberal way of > allowing users to choose while still providing a default. These things never go > without hiccups. > > I believe what some of us actually have a problem with is (a) the actual way this > is integrated into the rc framework and (b) to some extend that the original > proposal indicates to possibly remove the current defaults (soon). We've lived > with these things for 2 decades and throwing everything out over night and > replacing it doesn't work for (some of) us. > > I see some benefits of it but I also see a lot of drawback in the one-thing-fits-all > approach. It's not the UNIX philosophy. > > *Personally* for a decade++ I've been running IPv6-only systems, I have a > branch somewhere where I started to work through the entire base system to > make things compile if they lack IPv4 header(s) or bits thereof. I *personally* > see very little gain from importing new IPv4 code which replaces something > which worked well for a looong time providing close to no new benefits (and I > emphasize the personally as I do understand and accept that IPv4 is very > important thing to a lot of people and business still and that it needs to be > maintained and supported for those in need). > > At the same time I agree that integration on the IPv6 side of FreeBSD lacks > behind and I do see the advantages of an intertwined RS/RA/DHCPv6 solution > though for a lot of situations the split solution will be "just fine" as the real > challanges come with the integration of other services or other missing bits we > simply haven't done. > > I was hoping this proposal would help solve two problems not just replacing X > and Y for Z. > > > I can tell on another note as it came up in this thread: > (a) wide-dhcpv6 is "maintained" by a lot of people (companies, Linux distros, ..) > and if the right people would have opened a new repo and collected (and > maintained) > bits (a few years ago) we'd likely not have this discussion but the problem > would be long solved for FreeBSD. > (b) I have trees with wide-dhcpv6 imported into base privately and know how > that > works as a default (I also know what doesn't work well but that's not specific > to the DHCPv6 client implementation) > (c) Like many I have patches to aid functionality and fix things (kind-of waiting > for (a) to happen to ridden my tree of them). I have so far resisted to make > FreeBSD that repo though I probably should have years ago. > > > >> The dhcpcd daemon can handle various protocols of IPv4/IPv6 and watch > >> multiple interfaces, so the suggestions above might sound like an > >> underestimation of the capability. I am concerned that changes to > >> replacing dhclient/rtsold will break the existing configurations. > >> Especially for IPv4, dhclient is mature, and many people have used > >> custom dhclient.conf and dhclient-script for years. I believe we > >> will get little gain from such change. > > > > We can leave current dhclient/rtsold configuration intact and suggest > > people move to dhcpcd by themselves. > > People that want DHCPv6 or a better DHCP or RA expierience already > > have some solution in place
Re: Import dhcpcd(8) into FreeBSD base
On Mon, 8 Aug 2022, Roy Marples wrote: Also, please consider than dhcpcd supports DNSSL and RDNSS options from RA messages whereas FreeBSD rtsold/kernel RA do not (please correct me if I'm wrong). This allows for a fully working IPv6 only setup without DHCPv6. Yeah I think we had that for over a decade... (as it has been pointed out before in older threads as well) commit db82af41db538fba5938d8585b2e2e2c206affb6 Author: Hiroki Sato AuthorDate: Mon Jun 6 03:06:43 2011 + Commit: Hiroki Sato CommitDate: Mon Jun 6 03:06:43 2011 + - Implement RDNSS and DNSSL options (RFC 6106, IPv6 Router Advertisement Options for DNS Configuration) into rtadvd(8) and rtsold(8). DNS information received by rtsold(8) will go to resolv.conf(5) by resolvconf(8) script. This is based on work by J.R. Oldroyd (kern/156259) but revised extensively[1]. ... 2) Keep the dhclient utility intact and add a knob to choose dhclient or dhcpcd (or something else) for DHCPv4. The current rc.d scripts for DHCPv4 can be adjusted to use another client supporting a per-interface mode. I would argue that having knobs to control dhcpcd (or any other similar network tool for that matter) in rc.conf per interface is a bad idea because this discourages running dhcpcd in manager mode. You even note this below, but here are some more comments. FreeBSD since we last time changed dhclient have had a very liberal way of allowing users to choose while still providing a default. These things never go without hiccups. I believe what some of us actually have a problem with is (a) the actual way this is integrated into the rc framework and (b) to some extend that the original proposal indicates to possibly remove the current defaults (soon). We've lived with these things for 2 decades and throwing everything out over night and replacing it doesn't work for (some of) us. I see some benefits of it but I also see a lot of drawback in the one-thing-fits-all approach. It's not the UNIX philosophy. *Personally* for a decade++ I've been running IPv6-only systems, I have a branch somewhere where I started to work through the entire base system to make things compile if they lack IPv4 header(s) or bits thereof. I *personally* see very little gain from importing new IPv4 code which replaces something which worked well for a looong time providing close to no new benefits (and I emphasize the personally as I do understand and accept that IPv4 is very important thing to a lot of people and business still and that it needs to be maintained and supported for those in need). At the same time I agree that integration on the IPv6 side of FreeBSD lacks behind and I do see the advantages of an intertwined RS/RA/DHCPv6 solution though for a lot of situations the split solution will be "just fine" as the real challanges come with the integration of other services or other missing bits we simply haven't done. I was hoping this proposal would help solve two problems not just replacing X and Y for Z. I can tell on another note as it came up in this thread: (a) wide-dhcpv6 is "maintained" by a lot of people (companies, Linux distros, ..) and if the right people would have opened a new repo and collected (and maintained) bits (a few years ago) we'd likely not have this discussion but the problem would be long solved for FreeBSD. (b) I have trees with wide-dhcpv6 imported into base privately and know how that works as a default (I also know what doesn't work well but that's not specific to the DHCPv6 client implementation) (c) Like many I have patches to aid functionality and fix things (kind-of waiting for (a) to happen to ridden my tree of them). I have so far resisted to make FreeBSD that repo though I probably should have years ago. The dhcpcd daemon can handle various protocols of IPv4/IPv6 and watch multiple interfaces, so the suggestions above might sound like an underestimation of the capability. I am concerned that changes to replacing dhclient/rtsold will break the existing configurations. Especially for IPv4, dhclient is mature, and many people have used custom dhclient.conf and dhclient-script for years. I believe we will get little gain from such change. We can leave current dhclient/rtsold configuration intact and suggest people move to dhcpcd by themselves. People that want DHCPv6 or a better DHCP or RA expierience already have some solution in place which might even be dhcpcd from ports. I don't see any reason to stamp on their toes. If FreeBSD does import dhcpcd, then I would suggest any talk of removal of dhclient can happen after a version of two. And the same goes for rtsol(d). In 1)+2), there is no POLA for users of other DHCPv6 clients such as dhcp6c or ISC's dhclient -6. A full-blown dhcpcd configuration, which replaces dhclient/rtsold, is still possible. The cons are that this is a partial
Re: Import dhcpcd(8) into FreeBSD base
In message , Franco Fichtner writes: > > > > On 7. Aug 2022, at 4:52 PM, Cy Schubert = > wrote: > >=20 > > My opinion as well. I need to see a solid business case why what we = > have in=20 > > FreeBSD base needs to be changed and how any proposed change will = > benefit=20 > > all FreeBSD users, not just one depending distribution. Right now I = > just=20 > > don't see it. > > I like the irony here. I can see it clearly. > > What FreeBSD desperately needs is another iflib or WireGuard moment. ;) As the saying goes, "you can attract more flies with honey than with vinegar." You are not helping your case with comments like this. ;) -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0
[Bug 263986] IPv6 address gets detached when using multiple IPv6 routers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263986 --- Comment #4 from Frank Behrens --- (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." -- You are receiving this mail because: You are the assignee for the bug.
Re: Import dhcpcd(8) into FreeBSD base
> On 7. Aug 2022, at 4:52 PM, Cy Schubert wrote: > > My opinion as well. I need to see a solid business case why what we have in > FreeBSD base needs to be changed and how any proposed change will benefit > all FreeBSD users, not just one depending distribution. Right now I just > don't see it. I like the irony here. I can see it clearly. What FreeBSD desperately needs is another iflib or WireGuard moment. ;) Cheers, Franco
Re: Import dhcpcd(8) into FreeBSD base
Hi Ben, > On 7. Aug 2022, at 11:27 AM, Ben Woods wrote: > > FreeBSD doesn’t have DHCPv6 support in base today, and therefore should > decide the best way to add it. I appreciate you’ve spent years supporting > dhcp6c and the existing tools, and we are therefore looking at this problem > space differently. While that is true what put me off here was the notion that dhclient could be easily replaced. I don't actually mind so much for solving the IPv6 part (it is highly welcome) and even replacing/obsoleting rtsold is good. > For me, dhcpcd has been reliably working for a decade, with the remaining > sandboxing security added years ago. It’s not a new implementation that is > yet to go through teething issues. From my point of view, a single daemon > that manages dynamic ip addressing makes sense, rather than 3 that have to > combine to manage this separately. I appreciate that this would require > re-work to integrate into the management layer of downstream products that > have found alternative solutions in the mean time. While I understand the dhcpcd motivation the goal here seems to be deferring maintainership in the hope not having to deal with this as much, going through upstream release cycles and potentially unrelated regressions is also a risk that increases the need for local maintenance and native patch inclusion, see below. > What I would ask is that you try dhcpcd for yourself (if you haven’t > already), and provide feedback on your experience. The hooks seem nice. There should be a way to circumvent the hooks in the base system and there must be support for running multiple interfaces through dhcpcd (I couldn't find any reference in the docs so far) for mixed environments. People using FreeBSD as routers often have multiple ISP connections (both IPv4 and IPv6) that need to work in tandem. For dhclient this was never an issue but dhcp6c uses listening facilities that prevent multiple daemons from working. Depending on code ancestry this could be an issue in dhcpcd. > Also, would be keen to hear some of the perks of dhclient and rtsold - is it > existing integration into your downstream management layer? (Not meant > sarcastically). Rtsold is currently the only source of a router address to the client. Even dhcp6c cannot currently provide this. https://github.com/freebsd/freebsd-src/commit/02508a3d4e17 dhclient revently added VLAN 0 reading support: https://github.com/freebsd/freebsd-src/commit/abf5bff71d dhclient VLAN priority support for certain ISPs: https://github.com/freebsd/freebsd-src/commit/1e7fe2fbb9c0 There could be more changes relevant to day-to-day ISP connectivity that eludes most "home lab" use where dhcpcd works well. I know this is tempting but also confirmation bias having worked with a lot of users over the years on their (nasty) ISP connectivity. Cheers, Franco
Re: Import dhcpcd(8) into FreeBSD base
Hi Doug, > On 7. Aug 2022, at 2:15 PM, Doug Rabson wrote: > > Of course but this argument is confusing - we are talking about DHCP client, > not server. You brought up Dynamic DNS and I see now that a discussion with you is not fruitful for a multitude of reasons so I am kindly not going to reply. :) Cheers, Franco
25/100 G performance on freebsd
For some reasons. I can’t use SR-IOV on my freebsd machines (HPE DL160 gen10) with latest 25G HPE branded cards. I opened tickets for that but since then no move happened. So I wonder id there is a good setup to use these cards with the virtualization. Which kind of performance should I expect using if_bridge? What if i am doing L3 routing instead using epair or tap (for bhyve). Would it work better? Any hint is welcome, Benoît
