Re: nd6_free assumes all routers are processed by kernel RA

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

    Date:        Sat, 24 Aug 2019 10:26:27 +0200
    From:        Gert Doering <gert%greenie.muc.de@localhost>
    Message-ID:  <20190824082627.GX1349%greenie.muc.de@localhost>

  | If we do not have a global source address, sending packets via a router
  | is pretty much guaranteed to violate a number of RFCs.

That's what I expect too, though ULAs, which are not global - that is
the FC00::/7 prefix, can be routed.  It is just LLs that cannot.

  | So hoping that a router will tell us by means of ICMPv6 what we already 
  | know

If we do send, there should be less "hope" and more "expectation" there.
The router should (perhaps rate limited, as usual) send an ICMPv6 about
packets it is discarding.

And does in my case.

  | (and hoping that it is even able to do so, which implies special 
  | handling over there to get the ICMPv6 to a LLA out the correct interface) 
  | does not sound like a good plan forward.

The router knows over which interface it received the packet - it needs
to retain that info in order to know when it might be appropriate to
send a redirect in the cases where it is forwarding the packet, so sending
the ICMPv6 back to the right place is not going to be a problem.

Certainly it would be useful to do something intelligent with such an
ICMP when received, though knowing what that is isn't quite as easy as
it sounds.  Blindly treating it as a "cannot get there, don't try again"
opens the host up to simple DoS attacks.  Causing the host to try a
different address if one is available, before retrying the one that
reported the ICMP would be good (no DoS, just different routing) but
we don't really have the API model to allow that - the dest addr
choice is in the application, whereas retries to non-responsive SYN
packets is in TCP in the kernel.   Getting that to behave in a sane
fashion utilising ICMP mesages as hints, but not necessarily fatal
blocks would be an "interesting" code set to write (and then fit into
every network application that exists).   If the API were "connect to one
of these addresses please" things would be easier.

Gert Doering <gert%greenie.muc.de@localhost> (in a different reply) also said:

  | This is not actually a reasonable thing to do - in your scenario,
  | this would mean "send a NS for every single v6 address out there
  | that you want to talk to,

Yes.   Of course only hosts that have only LL addresses, and which have
v6 enabled, act that way, which means not very many of them.

  | and since no NA ever comes back, the application would run into the
  | same timeout behaviour as before".

Not really, the timeout waiting for a non-replied NS can be much much
shorter (since we know the responder, if it exists, must be on our link)
and we also don't need to retransmit as often (one retransmit is probably
enough, as the only common cause of a missing reply should be recipient
overload, or non-existence.  If it is so overloaded that it fails to respond
to 2 successive NS requests it is probably also so overloaded that it isn't
worth attempting to communicate with, so simply treating that case the same
as non-existence seems reasonable.)   A delay of 0.5 of a second or so would
be tolerable (barely noticeable), and nothing at all like the 75 second
delay I am seeing (and which is much worse when the destination host has
multiple v6 addresses, that get tried in turn, before a fallback to v4
happens.)

This issue is orthogonal to my actual problem though - this is something
else that perhaps should be fixed (and could also be configurable, so hosts
that don't ever actually want to communicate with a global neighbour addr
when they have no global addr of their own, could avoid doing this).  I
believe it is (or was at least) part of the original v6 design however.

  | Even if you have something that does proxy-NDP, it would still be a bad
  | idea to fill the local neighbour table with an entry for every single
  | communication partner out there (people did - and do - this in v4, point
  | a default route "to ethernet" and rely on proxy ARP for packets to go
  | to the router, and all good it does is "hide configuration errors").

I agree this is not a good way to configure a net - proxy NDP (if anyone
has implemented that anywhere) does not really sound like a reasonable and
certainly not necessary model ... but I would be hesitant to prohibit it
either.

I am certainly not concerned with the size of the neighbour cache, if we
were communicating with all that many hosts, the TCP state tables would
be much larger, and no-one complains about those (further, unlike TCP state,
NDP caches are caches - if one gets too big, we can always just discard the
oldest (counting usage, not creation) and if it turns out to be have still
been needed, simply NS for it again.

Once there are no more packets being sent/received (ie: TCP has shut down)
the neighbour cache will quickly age out and be deleted.   TCP is what
matters here, as that is what is used to communicate with all those random
communication partners in practice (web, e-mail, and similar).  UCP (and ICMP)
are used typically for a much more restricted set, and/or for very limited
transactions (one DNS query/reply) that would allow the NDP cache to be
cleared quite quickly.   In practice, this would not be a problem worth
worrying about.    A system with very limited memory resources wouldn't be
making many "random" connections to hosts in the first place -- and recall,
all of this is material only for hosts with only LL addresses - if a host
has an addr of sufficient scope, it simply uses that to communicate, and
that one gets sent via a router, if not to a local destination, and none
of this is relevant.

kre