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

Toerless Eckert <> Fri, 29 May 2020 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B0B63A0E24 for <>; Fri, 29 May 2020 10:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.77
X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PLING_QUERY=0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sYuOQFPHnDn7 for <>; Fri, 29 May 2020 10:12:41 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CC9A3A0E27 for <>; Fri, 29 May 2020 10:12:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AE901548011; Fri, 29 May 2020 19:12:34 +0200 (CEST)
Received: by (Postfix, from userid 10463) id A5470440043; Fri, 29 May 2020 19:12:34 +0200 (CEST)
Date: Fri, 29 May 2020 19:12:34 +0200
From: Toerless Eckert <>
To: Ted Lemon <>
Cc: Stewart Bryant <>, 6MAN <>
Subject: One size fits all !?! (was: Re: So where have all these new 6man WG people come from?)
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 May 2020 17:12:44 -0000

To me the main issue is that all the discussions about possible
improvements of IPv6 steering headers (all the options out there)
do nothing but monopolize precious industry cycles into tactical 
issues instead of also addressing the strategic problems with IPv6
that go way beyond optimizing steering header encoding.

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!

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, ...).
16-bit/32-bit/48-bit address sizes would be highly desirable.
Even the 1980'th CLNP network protocol had variable sized addresses.
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.

We have no "maintenance-only" constraint in IETF multicast,
yet for unicast network layer we only permit maintenance or
else you need to create another WG for just a sub-problem.
How silly of a structure is that ?  And please do not create
an IPv6.00001 working group, but think really about another
instance of IPv6-NG, but this time backward compatible.

And do not let a vendor force the hand of the IETF by developing
and deploying proprietary solutions first. We know how bad that works from
ongoing work in other layers, as well as historic examples.

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.

On Fri, May 29, 2020 at 10:30:01AM -0400, Ted Lemon wrote:
> On May 29, 2020, at 10:17 AM, Stewart Bryant <> wrote:
> > My main point was that a list discussion of this type rarely reaches an acceptable outcome, and that an objective discussion at IETF is normally a better approach. Indeed resolving issues like this is exactly why we meet F2F at IETF.
> My experience with this is more that working group chairs are quite active in moderating discussions during in-person meetings, and really tend not to take responsibility for doing that on the mailing list. This produces the effect you???ve observed, that it???s easier to get consensus in-person than on the list.
> This is unfortunate; if the chairs took a more active role on the list, considering the cost of the time it takes for participants with coding jobs to follow multi-hundred-post repetitive arguments, we would probably do a better job of reaching consensus on-list.
> Of course, this is a lot of work, and it???s sort of understandable that it doesn???t happen; my point is simply that if we want to be an effective _online_ organization, maybe we need to start doing things a bit differently.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------