Re: nd6_free assumes all routers are processed by kernel RA

[Gert Doering <gert%greenie.muc.de@localhost>]

Hi,

On Sat, Aug 24, 2019 at 05:28:55PM +0700, Robert Elz wrote:
>     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.

Apologies for not writing down precisely what I was thinking.  Yes, indeed,
that paragraph should have read "... do not have any source address
but link-local (fe80::), sending packets via a router..."

ULAs are fully routable, though by convention not routed across the
public Internet.  So with ULAs, you might end up hitting a NAT66 box
on the way to the Internet, and it would magically work (which I expect 
to see in enterprise deployments where renumbering on ISP change is 
more expensive than a NAT box...)

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

"Only LL addresses and have v6 enabled" would be "any recent operating
system in an IPv4 only environment", of which there are many.

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

To make that work, the neighbour discovery code could would need to
communicate the timeout back to the TCP SYN sender (or more generic,
"the entity that sent the original IPv6 packet") somehow - "we tried
to send your packet but had to give up".  Sort of "TTL exceeded"...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert%greenie.muc.de@localhost