Re: Dealing with ICMPv6 network unreachable.

[Roy Marples <roy%marples.name@localhost>]

On Sat, 2015-04-04 at 03:16 +0700, Robert Elz wrote:
> 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).

I don't know what Linux is doing here, I just know that wget (and other
applications) are failing IPv6 early and falling back to IPv4. It could
be some other mechanism other than ICMP for all I know.

> 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 agree on all points.

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

My knee jerk reaction was the same.
But after contemplating the issue while soaking the sun it's not really
that broken. It's perfectly possible that the router is configured to
request a Prefix Delegation from a upstream DHCP server which has gone
silent. The normal operation of rtadvd(8) is to advertise itself as a
router and any prefixes on the advertising interface - of which there
will be none if Prefix Delegation has failed.

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

Well, as discussed above, fixing it by not adding a default route if no
global addresses are available isn't a good solution either (and one I
have also considered).

Roy