Re: kern/51531: Recent networking regression affecting installs

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/51531; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/51531: Recent networking regression affecting installs
Date: Wed, 23 Nov 2016 07:16:23 +0700

 In all of this (and regardless of whatever bugs may be uncovered in
 IPv4 DaD processing, and which clearly should get fixed), I still
 fail to understand this fetish of not sending from a tentative address.
 
 Note, tentative is not invalid - it is an address whose address is not
 invalid but that is not yet known for certain.
 
 I haven't looked at whatever spec now exists for testing v4 addresses
 in this way, but as I recall it, for v6, it is absolutely required to
 send from a tentative address in some circumstances (particularly when
 2 hosts are attempting to configure the same address at the same time,
 and both are performing DaD ... if both stay silent, neither will see
 the conflict, and both will assume they can transition the addr to valid.)
 
 The real fix for this problem (in addition to any others that come to
 attention because of it) would seem to be to remove the restriction on
 sending from tentative addresses (that is, to stop treating them as invalid.)
 
 Almost always, DaD "succeeds" and the tentative address becomes valid.
 This may not have been quite so true in the past, when people commonly
 manually configured IPv4 addresses, and it what let to using ARP to check,
 which eventually led to DaD for IPv6, and then its formalisation for IPv4.
 These days, almost no-one manually configures addresses, and when they do
 it is most commonly of routers/major servers, and they're very rarely
 configured incorrectly, and automatic addr assignment (DHCP, or for v6,
 autoconfig) almost never produces duplicates.
 
 But - for DaD to succeed, we must wait - if we really believe that there's
 more than a negligible chance of duplicates, we really should be sending
 multiple queries, and waiting after each.   That means noticeable delays,
 which almost always are pointless.
 
 On the other hand when DaD does happen to fail (the addr is duplicated)
 it almost always fails very very quickly (usually within a millisecond.)
 That is, the other host to which the addr has been assigned responds to
 the DaD query very very quickly.   That is, usually, by the time we have
 finished configuring the address, and are ready to actually send a packet
 if DaD were ever going to fail, it almost certainly always will have.
 And if we want to reduce our chances of accidentally using addr that might
 become invalid very soon, we can just delay, 10 ms or so should be enough,
 after configuring the address.   If DaD has not failed by then, the chances
 are very small that it ever will - and if we wanted to improve the chances,
 we could send the second query about 5ms after the first rather than waiting
 for the entire timeout - just in case something happened to the first packet
 (corrupted on the wire, or similar) so it had no chance to be received.
 
 Also note that there is 0 chance of never using an address that might
 become invalid in the future (and no way of knowing how far in the future
 that might happen) so we either need to simply tolerate occasional comms
 failures (which is what we mostly just do - just try again if things don't
 work first time - for any reason) or apps need to get a lot smarter to
 learn to recover from such events.   That is, avoiding using a tentative
 address, because it might become invalid is silly, because any address
 might become invalid.   Even avoiding it because it might become duplicated
 is pointless, as the (admittedly rare) case of 2 net segments, reconnecting
 after the same address happened to be assigned (and DaD carried out without
 complaint) on each of the segments before they re-joined shows.
 
 Please, just put the networking code back to the state it used to be, and
 allow tentative addresses to be considered valid for the purposes of
 packet sending/reception.
 
 kre