[PATCH v2] dhcp6c: DHCPv6 client

[Denys Vlasenko]

On Fri, Nov 4, 2011 at 8:04 AM, Leonid Lisovskiy <lly.dev at gmail.com> wrote:
> On Fri, Nov 4, 2011 at 4:54 AM, Denys Vlasenko <vda.linux at googlemail.com> wrote:
>>
>> I think that maybe emulating existing dhcp6c tool with its config file
>> and command line is not a good idea. This will make DHCP and DHCPv6
>> clients in busybox to be very different.
>
> Agree, but redesign of applet I was postpone for the future. Seems to
> be, this time is come...
> But I don't see any way to simplify dhcp6c config file like udhcpc
> since we can have several IA/PD.

I prefer to follow the model of udhcpc, where one instance of client
daemon configures one interface.


>> 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?


>> Second, we don't need to implement auth features, at least not at once
>>  - organizations paranoid enough to authenticate DHCPv6 traffic probably
>> should not use dynamic IP addresses at all!
>
> Agreed. I can easy exclude this feature from applet.
>
>> Third, we might choose to support only the setup where there is only
>> one DHCP server, not many - udhcpc currently simply uses the first
>> server response (doesn't try to collect more responses and pick
>> "best one"), and people aren't complaining. This means that the
>> multi-server DHCP setups must be a very rare thing.
>
> Unfortunately, a few ISP's provide multi-server DHCP setups. Most of
> them are buggy, but they are exists  :(
> For example - Beeline ISP, Ekaterinburg, Russia.

If "always select very first received server reply" doesn't work for them,
then their installation is broken IMO.


>> Fourth, it should not set IPv6 addresses (ifaddrconf() func does that
>> in current patch). It should just export data to environment and run
>> a script, just like udhcpc does.
>
> i.e. like all others (ISC dchp client, for example). When I start
> conversion of wide-dhcpv6, I don't think that it is simplifies code
> too much. At this moment, I have to agree with you. Should we take ISC
> dchp reasons list from starting point?
>
>> Do you want to work on it, or you don't find this to be a good idea?
>> I probably can work on it this weekend...

Here is a compilable code I just dropped into git:

http://git.busybox.net/busybox/commit/?id=9ba75048c0099ed90b9a64cb7bb57bf12be93528

It's a moderately scary hack, but it builds and
even sends dhcpv6-looking packets with correct UDP checksum! ;)

d6_dhcpc.c file is basically a hacked copy of dhcpc.c -
I retained the same logic we use in udhcpc.

I deleted all logic which exports $envvars for now. I plan to add it back
after I add code which parses dhcpv6 options returned by server.

After the applet will reach the stage where it actually works
in a simple setup (say, successfully sets IPv6 address + routing + DNS),
then we can take a good look at possibilities to commonalize
some bits in udhcpc and udhcpc6.

Can you take a look at the code?
Is basing future work on it ok with you?

-- 
vda