Hi, Allow me to add my point of view on this matter ; I used to think of writing such a DHCPv6 client some times ago…
Le mardi 08 novembre 2011 à 09:59 +0100, Denys Vlasenko a écrit : > On Tue, Nov 8, 2011 at 8:03 AM, Vladislav Grishenko <[email protected]> wrote: > >> From: Denys Vlasenko [mailto:[email protected]] > >> On Fri, Nov 4, 2011 at 8:04 AM, Leonid Lisovskiy <[email protected]> > > wrote: > >> > On Fri, Nov 4, 2011 at 4:54 AM, Denys Vlasenko > >> >> Maybe we need a udhcpc6 applet which is similar to udhcpc. > >> >> > >> >> For one, it should handle one interface. This simplifies many things. > >> > > >> > One upstream(listen) interface - yes. But simplification to single > >> > downstream (IA, PD) interface seems to be bad idea. > >> > >> Can you elaborate why is it a bad idea? > > > > This is bad idea, because it should be only one and same dhcpv6 client (id) > > which is responsible for: > > 1) receiving/assigning address to interface it running on > > 2) receiving/assigning prefix(es) to sub-interface(s) as per rfs3633 > > udhcpc handles all configurational tasks by running a script. This is > a VERY generic mechanism. The script certainly can "assign prefix(es) > to sub-interface(s) as per rfs3633". It can do much more than that. > For example, on my machines the script (re)starts ntpd if needed. > Imagine the awkwardness of hard-coding *that* into C code. I completely agree with Denys. I didn't read the client code, but I always thought of handling PD with some scripts. This is not the role of a DHCP client to do anything about PD himself: there could be so many ways of handling it… Better launch a script. The common case I see, the result would be to generate some configuration file for radvd. Not something to hardcode in the client… For me, there should be one client bound to one interface in almost every cases. No need for something more complicated. Or maybe I misread something. Regards, benjamin _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
