Re: kern/52074: -current npf map directive broken

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

    Date:        Sun, 7 May 2017 17:17:28 -0400
    From:        christos%zoulas.com@localhost (Christos Zoulas)
    Message-ID:  <20170507211728.8AF0A17FDA8%rebar.astron.com@localhost>

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

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.

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.

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.

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

kre