Re: IPv6 "bloat"

[Owen DeLong via NANOG <nanog () nanog org>]

> On Mar 20, 2022, at 22:41, Masataka Ohta <mohta () necom830 hpcl titech ac jp> wrote:
>
> Michael Thomas wrote:
>
> > So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system 
> > syndrome, etc.
>
> IPv6 optional header chain, even after it was widely recognized
> that IPv4 options are useless/harmful and were deprecated is an
> example of IPv6 bloat.
>
> Extensive use of link multicast for nothing is another example
> of IPv6 bloat. Note that IPv4 works without any multicast.

Yes, but IPv6 works without any broadcast. At the time IPv6 was being developed, broadcasts were rather inconvenient 
and it was believed that ethernet switches (which were just beginning to be a thing then) would facilitate more 
efficient capabilities by making extensive use of link multicast instead of broadcast.

Guess what, we are again bad at predicting the future. You have no choice when developing something but to make the 
best guess about what will happen from the information available at the time. Turns out multicast was arguably a wrong 
guess, but all indications available at the time were that it was a good bet.

There is still a valid argument to be made that in a switched ethernet world, multicast could offer efficiencies if 
networks were better tuned to accommodate it vs. broadcast. That’d be IPv4 unfriendly, but in a world where IPv4 is 
eventually deprecated and broadcasts are no longer necessary, the potential is there.

> > So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories.
>
> See above. That is an improper way to evaluate IPv6 bloat.
>
> An example of second system syndrome of over-engineering
> without bloat is various timing parameters specified
> for ND, even though timing requirements are different
> depending on link types, which means there can be no
> standard timing parameters applicable to all the link
> types.
>
> Another example of over-engineering is SLAAC to
> *statefully* maintain address configuration state
> in fully distributed way only to promote
> inconsistencies requiring DAD.

SLAAC doesn’t “statefully” maintain address state in the network or in remote systems. Obviously some level of 
statefulness is required on each local host or it would need to repeat the address acquisition process for each 
unconnected frame (whether initiating a connected session or a connectionless frame). DAD is there to avoid 
inconsistencies and more gracefully handle situations where addresses get duplicated. IPv4 is particularly bad at this 
and the “over engineering” you speak of here was seen as a solution to that problem in IPv4.

> An example of under-engineering is lack of the
> following consideration of rfc791:
>
>    The number 576 is selected to allow a reasonable sized data block to
>    be transmitted in addition to the required header information.  For
>    example, this size allows a data block of 512 octets plus 64 header
>    octets to fit in a datagram.  The maximal internet header is 60
>    octets, and a typical internet header is 20 octets, allowing a
>    margin for headers of higher level protocols.
>
> as IPv6 optional headers can be arbitrary lengthy, it is not
> guaranteed that 512B DNS message can be sent over UDP over
> IPv6.

It is guaranteed that a 512 octet DNS message can be sent over UDP if it does not contain extension headers. You can 
argue that extension headers should have been more carefully considered in RFC791, but two factors come into play there:

        1.      I’m not sure the idea of extension headers had been fleshed out by the time RFC791 was written. It is 
one
                of the earliest IPv6 RFCs.

        2.      Even with full consideration of IPv6 extension headers, I think 576 is still a reasonable MINIMUM MTU,
                since a minimum MTU that can account for all extension headers would exceed the common 1500 octet
                MTU prevalent at the time (and still relatively prevalent today). It’s clear from the text of RFC791 
that
                this number is by definition a compromise between competing factors, wherein there is on one side
                the desire to keep the minimum MTU as small as possible and on the other side, the need for the
                minimum MTU to accommodate a reasonable size payload under the majority of circumstances.
                For better or worse, I think that 576 is probably as good a compromise as can be reached.

So I disagree with your characterization of this as under-engineered.

Owen