Default ULA lifetimes are way too short

[toreanderson]

By default, hnetd will generate ("self-delegate") an ULA prefix with a valid/preferred lifetime of 600/300 seconds. These will reset every 270 seconds (i.e., when the remaining preferred lifetime has reached 30 seconds). These defaults are codified in hncp_pa.c.

These defaults are simply way too short.

draft-ietf-homenet-hncp-10 states:

HNCP TLVs specified within this document, in steady state, stay constant, with one exception: as Delegated Prefix TLVs (Section 10.2.1) do contain lifetimes, they force re-publishing of that data every time the valid or preferred lifetimes of prefixes are updated (significantly). Therefore, it is desirable for ISPs to provide large enough valid and preferred lifetimes to avoid unnecessary HNCP state churn in homes, but even given non-cooperating ISPs, the state churn is proportional only to the number of externally received delegated prefixes and not the home network size, and should therefore be relatively low.

If I understand correctly, hnetd is essentially acting as a «non-cooperating ISP» by self-delegating ULA prefixes which these short lifetimes.

Another disadvantage of these short lifetimes is that it significantly increases how often RAs need to be sent. odhcpd will by default transmit unsolicited RAs approx. every 30 seconds (cf. issue #55), however it is important to note that the PIO lifetimes in these RAs are the actual remaining lifetimes. That is, if 100 seconds have passed since hnetd has renewed the ULA self-delegation, then the PIO valid/preferred lifetimes in the RA will be advertised as 500/200 seconds.

This in turn means that it is essential that the nodes in the homenet receives an unsolicited RA in the 30 seconds immediately after the self-delegation has been renewed, otherwise the preferred lifetime on the nodes will reach 0 and the associated addresses will become deprecated.

Thus in order to keep the addresses in a permanent usable state, unsolicted RAs need to be sent at least every 5 minutes, or 12 times per hour. As far as I can observe, odhcpd will transmit an unsolicted RA pretty much immediately after the self-delegation has been renewed, so the actual figure is every 270 seconds (13.3 unsolicited RAs per hour). This is already in violation of the recommendations in RFC7772, which sets an upper limit of approx. 7 unsolicted RAs per hour.

Furthermore, the above paragraph completely ignores the fact that multicast RAs are rather unreliable. Thus it is necessary to retransmit them a few times within that 30-second window following the renewal, and odhcpd appears to does so twice, with a seemingly random 1-10 second delay before each retransmission. So the actual situation is that every 270 seconds, a 20 second window starts in which 3 unsolicited RAs get sent. That means these short ULA lifetimes cause the transmission of 40 unsolicited RAs per hour.

Finally, even if the essential unsolicited RAs do get retransmitted, the window is still too narrow for the situation to be stable. If the node, e.g., enters an area with poor wireless coverage right before the self-delegation gets renewed, and stays there for 20 seconds, the addresses will likely end up becoming deprecated anyway. This is trivially reproducable by running something like ip6tables -I INPUT 1 -p icmpv6 --icmpv6-type router-advertisement -j DROP; sleep 20; ip6tables -D INPUT 1 on node in the homenet preciesly when the preferred lifetime of its ULA address reaches 30 seconds.

The way I see it, a ULA prefix is supposed to be a _stable_ alternative to (possibly quite ephemeral) ISP-delegated prefixes, but these short default lifetimes prevents it from succesfullly filling that role. IMHO the default lifetimes should really be counted in units of months or at the very least weeks, rather than seconds and minutes. (Heck, why not infinity?) Regardless of which exact values are chosen, it also seems essential to me that the lifetimes get renewed with _way_ more preferred lifetime remaining than just 30 seconds.