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 08:25:51 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202505271225.IAA26229%Stone.Rodents-Montreal.ORG@localhost>

OK, there have been several messages asking about this, on and off
the lists, I will reply to Mouse's, just because it was the first,
and just this one, and just this once.

After this you can believe whatever you like.

  | Why?  I've been using globally-routed addresses for everything since
  | 2002 and have never had any trouble I can attribute to the practice.

Yes, as I said, it can seem to work, as the code tries hard to make
things work.

  | What am I at risk of?

It depends....

  | It isn't?  What goes wrong?  Or, more precisely, what parts of the
  | design have that assumption built in?

And this is the other reason for picking this message (I could have replied
to the last on the list, rather than the first) in that that is exactly the
right question to ask.

But first, Andy & Gert, and by implication, Mouse, are all correct, for
just getting a packet to its destination, all that is required is that
the addr which is the default (or any) route resolves (using ND) to the
mac addr of the router (people who manage to make bizarre off-link route
settings work are usually relying upon the local router recognising a
ND request for an off-link addr, and supplying its own mac addr as an
answer to the ND query, which is a questionable practice, but seems to
be rather popular).

If that were all the default route setting was used for, it would really
make no difference.   And no, I'm not considering routers, just hosts,
and so how OSPF works isn't material (and much less, BGP).

But that's not all the config is used for, it is also used so the host
can recognise when a packet it receives originates at the router, when
that is its required source.   And no, that's not for validating RA
packets, any router can send those (all should) it is when we need to
validate a particular router that it matters.   That is, when our local
router sends a response to a packet that we sent to it (as a router,
not as a destination).

One reason for that is ICMP(v6, if you insist, but we're only talking
about v6 here, none of this applies to v4) redirect message.   In the
v4 world, those things (rightfully) have a very bad reputation, and
acting upon them is generally a very poor idea, as they can be sent
from anywhere, there's no validation, and believing a fake will usually
result in a DoS, which can also be one step in other kinds of attacks.

But all this was known when v6 was being designed, and despite their
danger in IPv4 (so no-one uses them) redirects are a valuable tool,
which is why they were invented in the first place.   So the v6
designers avoided the most serious problem with redirects, an IPv6
host believes a redirect only when it originates from the address
(IPv6 addr) to which the packet was forwarded (a redirect from further
away would be useless, that would indicate a routing protocol failure,
but hosts don't do that, they, absent some kind of local routing protocol,
have no idea which of several local routers should be the destination for
a specific off-link destination, and they shouldn't need to.)

By making that be a LL addr, we know the redirect came from on our local
link, and if it is also the addr to which we sent the packet to be
forwarded, then it probably is coming from that router, and is a valid
instruction to send further packets to the addr given in the redirect
(which will be another LL addr on the same link.)

ICMPv6 redirects can still be spoofed by hosts on the local link (on
some kinds of local links anyway) but that's a much simpler problem,
if it happens, the possible sources are generally easy to find, and
there's usually a method to take action which will not be desirable
to the perpetrator, so that one was considered far less serious.
(It might also be possible to use auth headers to authenticate things,
but I have no idea if anyone has actually tried that).

I'm not sure if this is the only use by a receiving host, I haven't been
following the protocol designs in recent years (even decades), but I
was there (as in, in the room, and participating) when v6 was being
designed, and I know that this is one of the fundamental assumptions,
and everyone who really knows v6 understands it, so this same kind of
thing might appear in other protocols I know nothing about.

Of course, if hosts simply used autoconfig the way it was designed,
rather than insisting upon static config, which should never be needed
for an ordinary host using v6 (some servers need a configured global
addr, but no host should need any configured routing), then they'd
learn a suitable default route addr to use from RA packets, and that
should always be a LL addr (RA packets get sent from LL addresses).
Then everything just works...

Gert said "There's benefits and drawbacks to both."   I've yet to see
a real (and sane) benefit to using global addresses.   There are lots
of other benefits to using LL, but not global.   There's the "warm and
friendly" feeling from "this is just like I do it in v4, so it must be
OK", but that's both nonsense, and wrong.   (I'll come to another one
in a minute).   On the other hand, using LL has other (management) type
benefits - LL addresses are the only ones that you can never be forced
to change (unless you use one that some other host already picked, but
that's a one time startup issue).   All other v6 addresses are subject
to needing to be changed - that's just a fact of life, caused by the
size of the network (which is why v6 was needed in the first place).
Routers simply cannot be expected to maintain a table of 2^48 (or more)
destinations ...simply possessing one might be possible, RAM is getting
lots cheaper, but that's still a very big number (and that isn't bytes,
each entry needs a data struct, with dest, timers, ...).   The only
solution that anyone has been able to find (other than perhaps the
PIP protocol, that was, briefly, one of the contenders to become IPv6,
but no-one really knew if it would work, it was dramatically different)
is to use topologically assigned addresses, so your address depends
upon how you're connected - and not just your local ISP, how they're
connected matters too.   You don't even need to change ISPs to need to
have your addresses altered, if some bigger company acquires it, its
place in the network topology will probably alter, resulting in address
changes.   I could go on, there are lots of reasons.

This ends up getting to the other reason that some people like static
configs, and configuring global addresses wherever possible - it is
make work for network managers, setting all that correctly is not
trivial for people who know nothing about networks, so an "expert"
is needed to do the configuration - nice job security.   Simply allowing
hosts to configure themselves, manage themselves, adapt to changing
addresses, all by themselves, and suddenly there's almost nothing for
the local network manager to do, job security down the drain ... so
there's a whole group of people, the apparent experts, who all have
a self-interest in prolonging the old way as long as possible.

This is enough, you either believe me, or you don't, and if you're
one of the people who has a vested interest in keeping the world complex,
rather than making it simple, then v6, as it was designed to work, and
can work if it is allowed to, is truly a frightening thing.

Otherwise, just use LL addresses as destinations for any route (apart from
anything else, doing so avoids the temptation to try and specify an off-link
address as the next hop) and be happy that you're doing things the way it
was all designed to be used.   Even better, just use autoconfig for hosts
(for everything) and your life will become much much simpler.

kre