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

From: Philip Homburg <[email-masked]>
Date: Mon, 01 Jun 2020 18:44:53 +0200

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.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Jun 2020 17:41:20 +0000

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:[email-masked]] On Behalf Of Philip Homburg
> Sent: Monday, June 01, 2020 9:45 AM
> To: [email-masked]
> Subject: Re: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: John Scudder <[email-masked]>
Date: Mon, 1 Jun 2020 17:43:33 +0000

Isn’t that a good application for link-level header compression, as Philip alludes to being used on good ol’ SLIP and PPP?

Regards,

—John

> On Jun 1, 2020, at 1:41 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
>> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UJAdvTzn_Z3n89OKnyACbWXrj22QQm2ZQ2bl3eO4TithKf6Zoo08UEqtwY0FLw$
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UJAdvTzn_Z3n89OKnyACbWXrj22QQm2ZQ2bl3eO4TithKf6Zoo08UEqtwY0FLw$

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 1 Jun 2020 17:47:23 +0000

Good point, John, I may have glossed over it too quickly. Definitely worth considering.
Still, on multi-access links I wonder if there may be challenges but certainly something
we should consider.

Fred

> From: John Scudder [mailto:[email-masked]]
> Sent: Monday, June 01, 2020 10:44 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: Philip Homburg <[email-masked]>; [email-masked]
> >> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-
> gk!UJAdvTzn_Z3n89OKnyACbWXrj22QQm2ZQ2bl3eO4TithKf6Zoo08UEqtwY0FLw$
> > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-
> gk!UJAdvTzn_Z3n89OKnyACbWXrj22QQm2ZQ2bl3eO4TithKf6Zoo08UEqtwY0FLw$

---

From: Philip Homburg <[email-masked]>
Date: Tue, 02 Jun 2020 15:43:40 +0200

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

I think one thing to do would be the creation of a paper design for a
network protocol specific to this application. That can then be use to
evaluate to cost of using IPv6. Or, in the case of compression and
other tricks, how close you can get to 'optimal' performance.

The big question is, what do you gain from using IPv6? Is it host software
(socket interface, TCP, UDP, DNS, etc)? Is it network management?