dhcpcd-discuss

On Friday 17 June 2016 13:43:23 Neal P. Murphy wrote:
> > > Is this good approach?
> > > If so, how can I do step 3? ie detect events such as timeout, reject or
> > > offer received?
> > > If not, is there a better way to do this? e.g is -T worth considering?
> > 
> > I don't think that's a good approach because you're signallng dhcpcd
> > from outside about what is good and what is bad.
> > 
> > Right now, dhcpcd internally has a state machine per protocol that is
> > desinged to handle only one offer. These should be refactored to handle
> > N offers, with a mechanisn to handle preference.
> > 
> > Another interesting question is this: do we want to only have one
> > primary lease or take the IPv6 autoconf approach and merge active offers?
> 
> Thinking out loud, this could open some intriguing possibilities. For one,
> assuming you trust all of the advertisers, you could accept *all* of them
> (at least accept those that are unique) as separate leases. The admin would
> have to track which gateway she wants to use as the default. The others
> would likely be of lower priority in separate routing tables. What use is
> it? How about connecting your DSL and cable modems and your firewall to one
> switch. Et viola: easy multihome. But I suspect various protocols and
> conventions wouldn't allow this to work.

What use is it?

Well, the same use we have already when dhcpcd accepts a DHCP  and DHCPv6 
lease *per* interface in one daemon.
So multi-home is already there.

All I am suggesting is a similar approach to IPv6 RA where dhcpcd stores all 
RA's and merges them. The difference being that it's merged into one dhcpcd 
hook call where we would have one per DHCP{,6} state.

So it's not anything radical in dhcpcd terms.
For the time being, I think we just have one active lease (dhcpcd decides 
which one) instead of merging like RA. IF the lease expires, or for example, 
the default router becomes "unreachable" then dhcpcd can move to another lease 
which works transparently.

Roy