On 11/10/2019 20:40, Hiroki Sato wrote:
I do not have a strong objection on dhcpcd (I am using it on some of
my FreeBSD boxes actually) but let me explain the reason why I chose
wide-dhcp as the candidate. That is because it is a small,
functional DHCPv6-only implementation. I am planning to rewrite it
to add the missing bits and adjust it for a tighter integration with
kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I
feel dhcpcd (or others) is too big for that purpose.
How are you measuring that dhcpcd is too big?
On my FreeBSD box
$ size /usr/sbin/rtsold /sbin/dhclient /usr/local/sbin/dhcp6c /sbin/dhcpcd
text data bss dec hex filename
32327 984 3352 36663 0x8f37 /usr/sbin/rtsold
86752 10144 82696 179592 0x2bd88 /sbin/dhclient
145322 1396 11304 158022 0x26946 /usr/local/sbin/dhcp6c
253258 1532 1184 255974 0x3e7e6 /sbin/dhcpcd
Taken by itself, yes dhcpcd is larger.
But as a whole dhcpcd is quite smaller.
24k of dhcpcd is just a text file with decoding instructions for all
DHCP/DHCP6/ND6 RFC's I can find.
What's more, dhcpcd can be compiled with things turned on or all, such
as DHCP, ARP, etc. It's quite flexable. To demonstrate, the above dhcpcd
size is the full fat dhcpcd.
Here is it with the stock small config and full IPv6 stack support,
which is the equivalent of dhcp6c and rtsold above + the extra goodies
you get with dhcpcd.
$ size dhcpcd
text data bss dec hex filename
176605 1452 1168 179225 0x2bc19 dhcpcd
But wait, there's more.
Lets see how dhcpcd weighs up as just a DHCP client + the extra dhcpcd
goodies?
$ size dhcpcd
text data bss dec hex filename
144163 1420 1136 146719 0x23d1f dhcpcd
I don't consider dhcpcd to be big at all, and would love to know your
rationale for calling it so.
IMHO, the directions of further developments of IPv6 functionality on
FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly
BSD (dhcpcd) have already been diverged. For RFC 7217 I already have
an in-kernel implementation (not committed yet), and I am also
working on SeND (RFC 3971, not directly related to DHCPv6 though).
My goal is to integrate these small implementations into the base
system and make them possible to work together. So for DHCPv6, I
think an implementation of only DHCPv6 is the best.
If people want a more feature-rich implementation or the same one on
other systems, they can still use dhcpcd or ISC's dhclient even after
the import.
Of course this assumes that wide-dhcp works to some degree. If it
does not, importing it to the base system does not make sense. I
have used it in various scenarios for a long time such as RA + O flag
on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others
which are complex enough, and understand what works and what is
missing (poor DUID format support, for example). The popular way to
use DHCPv6 is IA_PD, and wide-dhcp works well with it.
So I have a question. What is missing feature in wide-dhcp which you
are concerned about? I know some, but it has most of the basic
functionality of DHCPv6 and I think it is enough as a minimal
implementation for the base system. My primary reason is that it is
just for DHCPv6 as mentioned earlier and I believe it is maintainable
in the base system. I would like to know other people's opinion if
there is something critical.
This isn't a question about wide-dhcp specifically, but I feel it's a
good question.
Do you plan on supporting a multihomed system with hotpluggable
interfaces all auto configured?
I'm looking at the BUGS section for rtsold and these bugs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138547
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218191
This is one of dhcpcd's killer features and allows me to use my pinebook
on the sofa, but hotplug in ethernet to take over so I can compile my
sources from NFS over distcc much faster.
Roy
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
