Re: IPv6 path MTU discovery not working (large number of retransmited TCP data packets)

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

    Date:        Tue, 27 May 2025 00:44:39 +0200
    From:        Christof Meerwald <cmeerw%cmeerw.org@localhost>
    Message-ID:  <20250526224439.B9178%vertex.cmeerw.net@localhost>

  | have something to do with it, i.e. I am following what was discussed
  | here:
  |
  | https://mail-index.netbsd.org/tech-net/2025/01/19/msg008956.html

That's a monstrous pile of utter nonsense.

Configuring anything related to IPv6 routing is (for hosts, not
concerned with inter ISP route filtering and such here) mostly
trivial.

The number 1 rule for IPv6 routing is to *always* use a link local
address for the next hop, for everything.   Never anything else,
whatever seems more convenient, and whatever looks like it might be
working (the code is resilient, lots of things will often mostly
work).

The next hop is necessarily on the same link as the host - that's
what makes it the next hop (that link can be any kind of link,
a LAN (ethernet, WiFi, or other), P2P, or a virtual link (tunnel,
or something similar, incl VPN links).   Whatever it is, it is a
link and has (or should have) link local addresses for every
connected node (even if there are just two) on that link.

The link local address of the router (or even the destination)
to which packets should be sent for some particular destination,
or set of destinations is what should be used as the next hop.

That's all a host ever needs to know, everything else related to
getting packets to their destinations is handled by the routers, all
you need to do is find one (using its link local address, on your link)
and send packets to it.

If you're trying to be one of those, you need to also run some kind
of routing protocol to learn the relevant topology - that might be
complex, or it might be as simple as some instructions written in a
file somewhere that are statically configured, depending upon local
needs, but there has to be something.

In NetBSD, link local addresses are written

	fe80::dead:beef%ifname

(where dead:beef is, of course, whatever is the host part of the link
local addr of the next hop, and "ifname" is the name of our local interface
to that link - something like wm0, tun2, or vioif0, or whatever it is).

Personally, I like to configure routers with nice simple link
local addresses like fe80::1 (with each router having its own
number, and using that same LL addr on all of its interfaces,
they're allowed to be duplicated, they have meaning only when
associated with a particular link).

That makes it easy both to configure, and to see what is configured
and which router is being used.   But unless you're actually configuring
the router as well, you need to live with whatever was configured by
whoever did.

Hosts normally use autoconfigured LL addresses, as aside from their
use in Neighbour Discovery, and DHCPv6, no-one normally ever sees one
of those, or cares what it is, so while they're important, they're also
mostly invisible.

Never use global (or even ULA) addresses in routes (as destinations,
obviously they're OK as the subject of the route) IPv6 just isn't
designed to work properly if you do.   It will work if you use LL
addresses for this purpose.

This is related to why J�asked what he did, though when I replied
to that message, I never imagined that things could have been this
badly configured.

  | so I have 2a03:d9c2:100::1 -connected -ifp vioif0
  | in /etc/mygate6

Don't do that.

  | And that indeed seems to be causing the issue here. If I change the
  | network configuration to use a /48 and just put "2a03:d9c2:100::1"
  | into /etc/mygate6, then it works as expected.

Don't do that either.

I can't suggest what you really should have, as I have no idea what the
actual network topology to which your netbsd vps is connected looks like,
nor what any of the addresses on it really are.

kre