Hi Juliusz,
as always, thanks for your comments.
> 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.
The problem is we can't rely on it since it is not widely supported by
clients.
>
> 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.
Added more xrefs where Capability Value is mentioned. This tie-breaker is
intentional to centralize certain services to single routers (e.g. stateful
DHCPv6 and PD).
>
> 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.
I agree, it now always MUST announce itself as router. Dropped the parts about
classless routes.
>
> 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?
That was the intended meaning, it has been a while since I dealt with DHCPv4,
but IIRC there is no lease time besides T1 and T2, anyway clarified.
>
> 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).
Yes, this trade-off was discussed several times already I think.
>
> 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).
Well you can recalculate the elections to know which router is elected, so
there is a way to find out for all local interfaces / Common Links.
You can also calculate it for non-neighboring (transitive) links,
given the topology graph.
> 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).
Well, the reason is that it is relatively useful to collect hostnames,
in absence of any other way of doing this cross-platform.
But yes, the same issues apply in theory. HNCP has a sentence discussing
this for a while. The latest staged one now says:
"Stateful addresses SHOULD be assigned in a
way not hindering fast renumbering even if the DHCPv6 server or
client do not support the DHCPv6 reconfigure mechanism, e.g., by only
handing out leases from locally-generated (ULA) prefixes and prefixes
with a length different from 64, and by using low renew and rebind
times (i.e., not longer than 5 minutes)."
This should help to minimize the issues.
> 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?
RFC 7084 says a router MUST always either provide stateless or stateful DHCPv6.
HNCP mandates when a router MUST and MUST NOT do stateful, so in theory if you
don't do stateful you MUST do stateless on client links, which is fine since
they
do not interfere in general. HNCP also says
"The requirement L-9 is modified, in that the M flag MUST be set
if and only if a router connected to the respective Common Link
is advertising a non-zero H-capability. The O flag SHOULD
always be set."
Cheers,
Steven
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
