> On Mar 20, 2022, at 22:41, Masataka Ohta <mo...@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
