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

[Vadim Goncharov <vadimnuclight%gmail.com@localhost>]

On Wed, 28 May 2025 06:28:06 +0700
Robert Elz <kre%munnari.OZ.AU@localhost> wrote:

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

You've said about PIP - may be you have materials on it's routing which are
missing from IETF archives? I've contacted author, but he didn't have it and
do not anything in his brain memory either... (see forwarded message below)

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

Totally not agree. While IPv6 tried to make some things simpler, overall it is
making world more complex, and have too many problems of it's own. That's why
there were proposals to design new IP in last years, most notable Huawei's
NewIP, and IPv6 problems were recognized at IETF level at least in
draft-bryant-arch-fwd-layer-ps-05 but I've began to design my PIP-influenced
alternative IPnh even before discovering that, notes/ideas can be seen at
https://github.com/nuclight/musctp/blob/main/ipnh.txt

Or better it may be described in letter to that draft's authors and PIP author:

== Beginning of forwarded message:

Date: Tue, 19 Nov 2024 05:01:35 +0300
From: Vadim Goncharov <vadimnuclight%gmail.com@localhost>
To: Paul Francis <francis%mpi-sws.org@localhost>
Subject: Re: IPnh & draft-bryant-arch-fwd-layer-ps-05 & Pip


Hi,

Well, the problem is, it's not much to dive into - some materials are
not available from neither the IETF site nor FTP links from 90-ies (and
web.archive.org didn't archive them, too). In particular, absent is the
most interesting part, Multi-Level Path Vector (MLPV) routing protocol
(https://datatracker.ietf.org/doc/draft-ietf-pip-vector/ has no text).

May be you have that part in your archives?

About dozen of Pip drafts texts are available from
https://datatracker.ietf.org/person/francis%works.ingrid.org@localhost but not
all.

On Tue, 19 Nov 2024 01:16:32 +0100
Paul Francis <francis%mpi-sws.org@localhost> wrote:

> Hi Vadim,
> 
> To be honest, I haven't paid any attention to this stuff for nearly 20
> years now, so it would be rather difficult to dive back in and
> produce any useful thoughts.
> 
> Nevertheless, enjoy!
> 
> PF
> 
> On Mon, Nov 18, 2024 at 7:37 PM Vadim Goncharov
> <vadimnuclight%gmail.com@localhost> wrote:
>   
> > Hello,
> >
> > For several years I was working (as a hobby, in spare time) on new
> > L4/L5 transport protocol (muSCTP), intended for future instant
> > messenger network (resistable to censorship, as you can guess from
> > country), but generic enough to be also suitable for higher-end IoT
> > devices and generic "big Internet" instead of TCP. In relevant part
> > to this discussion, it is "T" for "tunneled" over everything -
> > don't tied to IP, but go over ICMP, HTTP, raw Ethernet, UDP being
> > just most primitive example, embedded in other protocols to
> > circumvent government DPI blockages... it has some things better
> > than in QUIC.
> >
> > And 1.5 years ago (after news on Huawei's NewIP) it became
> > interesting to me if some of it's features (e.g. address/port
> > independence) better be on Layer 3, so I, as familiar with
> > 802.15.4/6LoWPAN problems and knowing that IPv6 is very bad, began
> > to design new IP protocol. I've read historic IPng materials and
> > based it on IPv7 [RFC 1475] and Pip [RFC 1621][RFC 1622], but also
> > from TCP/IP v3 [IEN-21] - most notably hierarchical variable-length
> > addresses and presence of Next Hop Forwarding Identifier of some
> > sort at first fields of packet for routers to be able to not parse
> > rest of packet (the main objection to variable-length addresses at
> > all times was performance).
> >
> > https://github.com/nuclight/musctp/blob/main/ipnh.txt here's early
> > notes
> >
> > Some month ago I've discovered draft-bryant-arch-fwd-layer-ps-05 and
> > was amazed how many solutions foreseen before SIPP/IPv6 settlement,
> > match current problems of the Internet, or for some things, like
> > profiles (called HCver in draft) I've "catching from the air" (if
> > not "reinvented the wheel"). So I've expanded some packet header
> > fields according to stated problems, e.g. MPLS-like Forwarding
> > Instructions for up to 48 bytes, a up to 60 bytes space for
> > in-transit-changed Balancer part (flow label, congestion info,
> > per-fragment copy of L4 start bytes, solving almost most of [RFC
> > 8900] fragmentation problems, etc.) and so on.
> >
> > But my experience is mostly from application side. I've implemented
> > experimental TCP-like protocol for IoT, with congestion control per
> > SCTP spec, but know almost nothing about BGP or MPLS. Just must say,
> > however, that, according to "at times problems are better seen from
> > outside", that many things in current Internet design are broken,
> > e.g. in BGP it looks very ugly and non-scalable for many routers to
> > have information about full network, or triangular-at-best host
> > mobility, so Pip's aggregation where host just knows all provider
> > prefixes and uses Host IDs for L4 and roaming instead of addresses,
> > looks much more beautiful (and secure, and I've added to it
> > anti-DDoS spoof prevention).
> >
> > So please see draft (very early in thinking process, though) and
> > give some review/advices about what things are not suitable or what
> > I didn't take into account. Please note that I don't care about
> > "IETF doesn't want to change from IPv6" - as it is intended first
> > for overlay I2P-like network, experiment can show something. And
> > then I predict that in next decades IPv6 *will* start to get
> > replaced by something - given political situation, in worst case
> > we'll get several technically incompatible Internets, for which
> > we'll then need a something trying to consolidate it again (here,
> > hierarchical addressing might be helpful); in best case this would
> > be just better protocol. But in any case, trend of "everything is
> > speeding up to datacenters" is breaking right now - Internet will
> > became decentralized is some way or another.
> >
> > --
> > WBR, @nuclight
> >    


-- 
WBR, @nuclight