[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/52074: -current npf map directive broken
On 08/05/2017 00:12, Robert Elz wrote:
Date: Sun, 7 May 2017 17:17:28 -0400
From: christos%zoulas.com@localhost (Christos Zoulas)
| On May 7, 8:50pm, roy%marples.name@localhost (Roy Marples) wrote:
| | The idea is that if we claim to send from an address it has to be valid,
| | but allow the NULL address if forwarded from the filter.
| | Does this make sense?
| | The same path probably needs adjustment in inet6.
| Sure, go for it. Why not put all the logic in ip_ifaddrvalid then?
While you are fixing this, please also fix ...
* Address exists, but is tentative or detached.
* We can't send from it because it's invalid,
Tentative addresses are not invalid, and we *have* to be able to send
from them, without that DAD does't work correctly.
DAD happens at the ARP level, not the IP level.
Different checks are in place there.
Consider a (perhaps unlikely, but possible) case where 2 systems attempt
to allocate the same address at approximately exactly the same time
(broken dhcp server, or common reboot after power fail and they have both
been configured to use the same addr by a broken sys-admin).
In that case they both make the addr tentative, each then starts DAD by
sending a "does anyone own..." query. Each receives the other's DAD
packet. The protocol then requires that, as we have that address, even
as a tentative one, we must reply (from the tentative address) and
claim the addr - both systems should do that, both receive the other's
defence of the addr, DAD fails (on both) and they both abandon the address.
Address defence only happens once DAD has passed.
In the scenario you describe this has not occured for either host.
If both recieves each others initial probe then both will abort DAD and
mark as duplicate.
This is described in RFC5227, 2.1.1:
In addition, if during this period the host receives any ARP Probe
where the packet's 'target IP address' is the address being probed
for, and the packet's 'sender hardware address' is not the hardware
address of any of the host's interfaces, then the host SHOULD
similarly treat this as an address conflict and signal an error to
the configuring agent as above. This can occur if two (or more)
hosts have, for whatever reason, been inadvertently configured with
the same address, and both are simultaneously in the process of
probing that address to see if it can safely be used.
And RFC5227, 2.4:
(b) If a host currently has active TCP connections or other reasons
to prefer to keep the same IPv4 address, and it has not seen any
other conflicting ARP packets within the last DEFEND_INTERVAL
seconds, then it MAY elect to attempt to defend its address by
recording the time that the conflicting ARP packet was received,
and then broadcasting one single ARP Announcement, giving its own
IP and hardware addresses as the sender addresses of the ARP,
with the 'target IP address' set to its own IP address, and the
'target hardware address' set to all zeroes. Having done this,
the host can then continue to use the address normally without
any further special action. However, if this is not the first
conflicting ARP packet the host has seen, and the time recorded
for the previous conflicting ARP packet is recent, within
DEFEND_INTERVAL seconds, then the host MUST immediately cease
using this address and signal an error to the configuring agent
as described above. This is necessary to ensure that two hosts
do not get stuck in an endless loop with both hosts trying to
defend the same address.
But if we are not able to send from the addr, because it is considered
"invalid" then neither defends its addr, neither receives the other's
defence, and both then conclude that the addr is safe, and both (eventually)
reset the tentative flag, and chaos ensues.
This is not what happens.
DAD has not passed, there is no address to defend, it's just marked
DUPLICATED and stays that way until manual intervention.
What we should be doing with tentative addreses is allowing them to be
used (for any purpose), but just not announcing them to the rest of the
system (except to tools like ifconfig and netstat) until DAD has
completed. That means no other process will discover that the addr
exists, and so will not start to use it (nor will TCP accidentally see
the addr as existing, and start to use it) and so the incentive that
led to prohibiting sending from tentative addrs, or considering them
to be invalid, is gone.
On a bad day, DAD on IPv4 can take about 10 seconds to complete.
That's a big window to run ifconfig or getifaddrs in to find and start
using these non announced addresses.
Consider the wireless interface
dhcpcd starts, sees all interfaces are currently down, forks right away
more daemons start up
wifi comes up, dhcpcd is offered an address and adds it
ntpd starts at this point and tries to start using the tentative address.
It also permits applications that really need to start running quickly, and
know how to deal with addresses that appear and disappear, to start using
the tentative addr before it is made permanent, if they like (and if they
can find some mechanism - perhaps using whatever hook ifconfig/netstat use -
to discover that the addr exists.)
If the application really neeeds to start running quickly, it can
disable DAD like so:
Otherwise it can wait for the address to finish DAD and then it can
start using it.
Main Index |
Thread Index |