Subject: [homenet] HNCP nits re DHCPv4

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 16 Aug 2015 13:07:01 +0200

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

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Aug 2015 11:08:26 +0200

Hi Juliusz,

as always, thanks for your comments.

> subprotocol, please drop me a note.
The problem is we can't rely on it since it is not widely supported by
clients.

>    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).

>    unconditionally announced.
I agree, it now always MUST announce itself as router. Dropped the parts about
classless routes.

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

>    cause republishing of node state at each election (since DNCP has no
Yes, this trade-off was discussed several times already I think.

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

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

> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 12:06:08 +0200

> The problem is we can't rely on it since it is not widely supported by

Chicken and egg.  If you put it in hnetd, the clients will come.

> but IIRC there is no lease time besides T1 and T2, anyway clarified.

Yes there is, option 51; it's the time at which you unconditionally
discard a lease even if you didn't manage to rebind it.  I think there
are some tradeoffs between decreasing T2 and decreasing the lease time,
and I'm not sure I fully understand what they are.

>        is advertising a non-zero H-capability.  The O flag SHOULD

If I'm reading this correctly, you're saying that a Homenet router SHOULD
implement stateless DHCPv6.  That seems like a somewhat arbitrary
requirement -- could you please explain the rationale?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Aug 2015 14:12:54 +0200

> Chicken and egg.  If you put it in hnetd, the clients will come.
Well, the thing is. Homenet is not really chartered for host changes and
many believe that IPv4 support is sort of deprecated anyway.

> and I'm not sure I fully understand what they are.

OK, Good to know.

> requirement -- could you please explain the rationale?
I think we discussed this already: https://mailarchive.ietf.org/arch/search/?email_list=homenet&gbt=1&index=4PT0dEjoh_rSVbxoqT8vHZho5_A ;)

Cheers,

Steven

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 14:20:40 +0200

> I think we discussed this already:
> https://mailarchive.ietf.org/arch/search/?email_list=homenet&gbt=1&index=4PT0dEjoh_rSVbxoqT8vHZho5_A ;)

Right, Windows XP support.  Grr.

(It skipped my mind -- sorry, but there's a hell of a lot of requirements
in HNCP, and my head is slowly starting to spin.)

-- Juliusz