Re: Dealing with ICMPv6 network unreachable.

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

    Date:        Thu, 02 Apr 2015 20:58:01 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <1428004681.19153.11.camel%uberlaptop2.marples.name@localhost>

  | This is displayed with ping -v as well, so it is hitting userland.
  | However, applications are ignoring it.

ICMP messages only "hit userland" for applications using raw sockets,
like ping, the vast majority of applications don't, and I think it way
to much to expect of them just on the off chance an ICMP packet appears
(which they'd have to filter out of all the random other noise that
raw sockets also let through.)

  | On NetBSD, using wget on a IPv6 host, such as roy.marples.name, will try
  | IPv6 first. It then stalls, ignoring the ICMP unreachable message.

That's arguably correct behaviour.  ICMP used (way back in the dark ages)
to kill connections, but that was widely (and correctly) lambasted as totally
broken behaviour - it is perhaps not quite so bad for TCP SYN packets, but
even there leaves the system wide open to DoS attacks (anyone can send an
ICMP packet, they're totally unauthenticated, and unverifiable, if you abandon
the connection on receiving one, you cannot resurrect it later if an answering
SYN+ACK does appear).

It doesn't seem like it would be so bad in the case you're postulating,
where the application has another address it can try, but the kernel doesn't
know that, all it can assume is that if you asked for it to make a
connection to a particular address, that's what it should try and do.

It was (long ago) determined that apart from their use by network engineers
for diagnostics (and hence the output from ping, traceroute, etc) all that
should even be done with a received ICMP unreachable is remember it, to
allow a better error code to be returned to the application if the
connection (or connection attempt) does eventually fail.

If linux is receiving the icmp and using that to abort the connect attempt,
it is, quite simply, broken (and probably even warrants a CERT advisory).

One thing that could be done (but which would mean adapting every application
in existance) would be to invent a "connect to one of addr set" sys call,
where a bunch of addresses (not necessarily all the same AF) could be given,
allowing the kernel to know what the application knows, so it could try
more sophisticated behaviours - including good destination addr selection,
instead of relying on the DNS functions magically returning addresses to
the applications in the "right" order.   That could include either multiple
SYNs (perhaps) or quick fallover in the event of an apparent error (without
actually abandoning the initial attempt).

I kind of agree with Greg Troxel, if there's any problem at all on the
NetBSD system, it would be in attempting to send to the global addr from
a LL addr - but even that isn't as clear cut as it seems, the global
addr might be on the local link, in which case the connection should succeed.

I certainly believe your holiday apartment's router is broken though,
advertising itself as a router when it has no routes at all (beyond LL)
is just perverse.

For NetBSD, aside from the unlikely possibility of a magic new connect
syscall, about all you can do when facing a broken router like this, would be
to disable IPv6 (which admittedly right now is harder than it could be.)

Certainly "fixing" it to act (in any way at all) upon the ICMP is not
the right thing to do.

kre