RE: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)

Philip, good message but I do see an element of truth in what the original poster
was trying to communicate. In aviation, we often deal with wireless links with
bandwidth less than 1Mbps - sometimes even *much* less. Asking those links
to carry at least two IPv6 addresses per packet is a considerable commitment
of resources, but that is our current plan. Should we be open to considering
alternatives?

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Philip Homburg
> Sent: Monday, June 01, 2020 9:45 AM
> To: ipv6@ietf.org
> Subject: Re: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
> 
> In your letter dated Fri, 29 May 2020 19:12:34 +0200 you wrote:
> >IMHO, it is a misguided dogma to think that RFC8200 128 bit
> >addresses IPv6 is a one-size-fits-all solution not only for
> >what it was built for, the Internet, but also all arbitrary controlled
> >networks - for the infinite future!
> 
> For IPv4, one-size-fits-all was a good thing. Anybody who remembers
> the nightmare of many different network protocols, all slightly different
> knows how great it was to have just one protocol.
> 
> Even in the early days, one-size-fits-all was a bit of a problem. I remember
> SLIP and PPP header compression trying do deal with big headers on slow links.
> 
> Right now we have IPv6, which can address all devices in the world. Which is
> great for software, no need to worry where something is, just generate an
> IPv6 packet and it will get there somehow.
> 
> If we look at the overhead of IPv6 then certainly at speed of 100 Mbps and
> higher, the effect of bigger addresses is left in the noise.
> 
> Obviously, IPv6 on slow links in a limited domain is not a great fit. Does
> that mean that IPv6 has to change? What is the benefit for all those devices
> that are on fast links and have no problem?
> 
> >IoT with IPv6 is an extreme pain (header compression, MTU).
> >Most controlled networks do not even want global addresses (security,
> >segment based app-gateway architectures, ...).
> 
> My first question would be, why not use IPv4 if address size and MTU are
> a problem? IPv4 is certainly a mature technology.
> 
> >16-bit/32-bit/48-bit address sizes would be highly desirable.
> >Even the 1980'th CLNP network protocol had variable sized addresses.
> 
> Nobody who does low level software wants veriable size anything.
> 
> If I compare processing an IPv4 header (which is variable size) with an IPv6
> header, then dealing with an IPv6 header is so much easier. With variable
> length addresses that would only get worse.
> 
> >IPv6 has not solved core problems to be even equal to L2 switching:
> >plug routers together, get automatic connectivity, no bother about addresses.
> >CLNP was a lot closer to that goal too.
> 
> Both DHCPv6 PD and homenet deal with this problem.
> 
> >but think really about another
> >instance of IPv6-NG, but this time backward compatible.
> 
> I doubt that the world is waiting for a third protocol that brings a
> completely new set of issues.
> 
> And I have no clue what a backward compatible internet protocol is supposed
> to look like. People have complained for years that IPv6 is not backward
> compatible with IPv4, but in all that time I have never seen a sensible
> protocol that is actually backward compatible with IPv4.
> 
> >If we continue to proliferate this "one-size-fits-all" myth,
> >then we are just continuing to extend our own version of
> >a winchester mystery house and kill our industry.
> 
> I doubt that the IETF has any power to stop a new local networking protocol.
> 
> If, for example, IoT needs a light weight local networking protocol, then
> anybody can just design it. It may help adoption if there is an easy way
> to convert to and from IPv6, but such a protocol can easily exist outside
> the internet world.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------