I think that I've finished implementing most of the DHCPv4 bits in shncpd,
and it was hard work. Requested changes to the draft are at the end. In
the following, I write RA for Router Advertisement and RP for Routing
Protocol. (I'd write Babel, but then somebody would get annoyed, and
I don't like annoying people. Really.)
Did I mention that I rather like HNCP? The HNCP+RA+RP subset of the
Homenet stack is pleasantly robust:
- HNCP state is replicated, and every HNCP instance can restart without
the clients noticing (see "adoption" in the PA draft);
- there is no hard state in the RA and routing protocols that cannot be
recovered from HNCP, so both the RA and RP can be restarted without
the clients noticing;
- every router can run RA and RP, with no need for election or signalling
(participation in RA or RP is signalled over the protocol itself,
a textbook example of fate sharing).
Unfortunately, DHCPv4 doesn't have these properties. DHCPv4 maintains
hard state (the lease database), and multiple DHCPv4 servers must either
synchronise their lease database or split the address space between them.
HNCP works around this issue by electing a single DHCPv4 server for each
link. This sucks, but it sucks less than the alternatives.
I might experiment with working around some of these issues by using RFC
3203 and RFC 6704 (forcerenew with nonce authentication, which is
reportedly implemented by dhcpcd). If you have experience with this
subprotocol, please drop me a note.
I have the following nits:
1. The election process is described in Section 7.3, and uses an ordering
that is sort-of defined in Section 4 (the bit that maps capabilities to
a single integer). This confused me, I suggest either making an
explicit reference to Section 4 in Section 7.3, or simplifying the
election procedure so that the first tie-breaker is not used.
2. Section 7.3 says that DHCPv4 should only announce a default route if
the RP is announcing one. This means that if the RP's default route is
flapping, clients will randomly get or not get the default route. Since
DHCPv4 has much larger latencies than the RP, I think this should be
changed to always announcing a DHCPv4 default route, and trusting ICMP
to do the right thing with respect to unreachable networks.
3. Related to the above, 7.3 requests that a static route be announced to
each delegated prefix. Again, DHCPv4 latencies are too large to make
this useful, and in any case this is redundant if a default route is
unconditionally announced.
4. Section 7.3 says "DHCPv4 lease times SHOULD be short (i.e., not longer
than 5 minutes) in order to provide reasonable response times to
changes." I'm not sure that's necessary -- wouldn't a longer lease
time but with a low rebind timer (T2 in RFC 2131) be more robust?
5. The election is not stateful: should the elected router be unstable,
the election process will be repeated every time it goes up or down.
Since there is no mechanism for passing around the lease database, this
will cause duplicate address allocations (hopefully worked around by
clients performing duplicate detection, but still). A stateful, sticky
(OSPF-style) election process would be preferable to the stateless,
unstable (IS-IS-style) election process currently mandated, but would
cause republishing of node state at each election (since DNCP has no
link-local signalling).
6. The election state is not signalled -- there is no way to find out
whether a router currently considers itself elected by just looking at
its published node state. This makes debugging tricky, but is perhaps
the right thing to do in order to avoid republishing node state at each
election (since DNCP has no link-local signalling).
I'm not familiar with DHCPv6 (SLAAC ftw!), but I think that many of the
above nits apply to stateful DHCPv6 as well. I believe that the spec
should say that stateful DHCPv6 MUST NOT be provided for prefixes of
length 64 (I know that Steven disagrees, see odhcpd issue #55).
On a related note, I'm not sure the draft is sufficiently clear about when
it is allowed to provide stateless ("O") DHCPv6 -- should a router that
has lost the DHCPv6 election provide stateless DHCPv6 service? How will
clients behave if they get RAs with conflicting "M" values?
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
