On Son, 2008-12-14 at 09:35 +0100, Juliusz Chroboczek wrote:
> >>   - it needs to work across multiple hops;
> 
> > DHCP also works through multiple hops - one uses DHCP-Relayers for that.
> 
> You're right.
> 
> > Of course one has to configure all that - but you have to configure DHCP
> > in any case.
> 
> There are actually two ways to get multi-hop DHCP: relays and prefix
> delegation.  As you note, DHCP will not automatically set-up relays, you

ACK.

> need to set up one relay per link manually.

One relay per router IMHO.
And AFAIK with usual DHCP-relayers (the one from ISC-dhcpd, ones on the
few CMTS I encountered), you can forward to exactly one DHCP-server
(which is in large DHCP-managed networks like cable nets a problem. The
usual solution is IMHO to have the usual HA-setup to have one IP
address).

> Additionally, I don't think DHCP will not forward over the same interface,
> which is needed in mesh networks.  However, I'd love to be proved wrong --
> if you manage to set up DHCP in a mesh network, please let us know.

The trivial answer is: if the node's IP setup (read: relation of  MAC
address to IP address) is static (and never dynamic), I just use the
very same DHCP config everywhere. The remaining problem is the
occasional disconnection - but the problem of duplicated IP addresses
(because of unsynchronized updates) is not handled by DHCP..

And it depends on what you want to achieve with it. Of course DHCP
requires (IMO) central management/organization (and not the necessary
distributed one as it is required for mesh networks). And IMHO the only
way to use DHCP in a mesh environment is to automagically separate the
IP address ranges which are handed out by the various DHCP servers.

Yes there is code in ISCs dhcpd for the DHCP failover protocol - but
that is designed/implemented to be deployed on 2 hosts next to each
other (especially network-wise).

And yes, that isn't implemented AFAIK anywhere.

> >>   - a part of the network needs to be able to survive for at least a few
> >>     hours when it becomes isolated from the rest of the network;
> >
> > That gets IMHO really interesting if the parts join again and detect
> > IP-address clashes because two new nodes in different networks got the
> > same one.
> 
> The idea is that we are sufficiently careful when handling out leases that
> clashes don't happen.

With IPv4?
I have to read it up sometime.

> > DHCP doesn't need sync'd clocks at all (simply because at the time of
> > the design/development of DHCP, clock synchronization was far from
> > "normal" IMHO).
> 
> I'm afraid I don't understand -- as far as I know, a DHCP server must have
> a reasonable clock.  Consider a DHCP server that gives out a lease and then
> reboots -- unless the lease was committed to stable storage with
> a reasonable timestamp, you'll get address conflicts.

Ah I understand/meant synchronized clocks between servers and clients.
As within reboots of the server: Of course you need that a clock -
especially the one of a server - is synchronized to itself (and that
included reboots of the host).
Well, if one drops that requirement, I fear it gets quite ugly in the
field.

> In other words, while you are right that time skew between the client and
> the server doesn't matter, the server needs to preserve time across reboots.

ACK.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services