[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/51531: Recent networking regression affecting installs
The following reply was made to PR kern/51531; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
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
Main Index |
Thread Index |