Re: New Approach For Discussing IPv10.

Joseph Touch <touch@strayalpha.com> Mon, 19 April 2021 14:37 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328013A33C0 for <ietf@ietfa.amsl.com>; Mon, 19 Apr 2021 07:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.939
X-Spam-Level: **
X-Spam-Status: No, score=2.939 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HAS_X_OUTGOING_SPAM_STAT=2.484, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cKHq4YnibQQ for <ietf@ietfa.amsl.com>; Mon, 19 Apr 2021 07:37:00 -0700 (PDT)
Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A293A337F for <ietf@ietf.org>; Mon, 19 Apr 2021 07:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FV7BnblsG3VZTsElf01PMKCVp6j4RHghTyjgXuBwrxM=; b=ns9RS3dsxfDCbNAeuCYtKW2MB Do0UV4OfKFGrBic4C0XyGQ0AxIZeY3Tg/oXNi/y0XfN+uaP8ag3KLvCwkW5gWvm/0YvcvDbUjDGDw IFl0glZrcxSw1t3bKeOwdvirO7lE1888cU9hu9xPzyKTBYijHqfUEoUGoDNmjRzCRDM0xDrbWXpm9 QY5eGaik8V+pQRvLN5VbpGhWW9S5J2JZOLpINySIHQA9CWdXl/1GO4qB6ZBfrnfVTy4iA2kg0pm1H +w+PslNTnmfbdiBKkXm4eaDp1GGi5i1DhoDWimVDfAkA1Ken5xzpZQpD6La5ynZX2OcgiiVANaolt F0oRb8k0g==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61689 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <touch@strayalpha.com>) id 1lYV1A-001rGm-8t; Mon, 19 Apr 2021 10:36:56 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD03643D-1CC3-4B83-98FB-E762B9A562E7"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Subject: Re: New Approach For Discussing IPv10.
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CAMm+Lwhy0c6G7YLx8n7Ya7psG6VxcEckk-ncKg750rscuz-Yaw@mail.gmail.com>
Date: Mon, 19 Apr 2021 07:36:51 -0700
Cc: Khaled Omar <eng.khaled.omar@outlook.com>, Lloyd W <lloyd.wood@yahoo.co.uk>, IETF Discussion Mailing List <ietf@ietf.org>
Message-Id: <61894090-FA92-434D-B537-B368278B4912@strayalpha.com>
References: <CAMm+LwhV01N_uuFV8TfiyegpqDLmUYwxBcmkUAGG-HfJ7vSB+Q@mail.gmail.com> <989A5048-5EA8-479B-9231-D61B646E46F5@strayalpha.com> <CAMm+Lwhy0c6G7YLx8n7Ya7psG6VxcEckk-ncKg750rscuz-Yaw@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/dNIon2UDPSp09wUo3QLTH4Cq2Qg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 14:37:05 -0000


> On Apr 18, 2021, at 8:42 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> On Sun, Apr 18, 2021 at 1:23 AM Joe Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
> 
> 
> > On Apr 17, 2021, at 9:49 PM, Phillip Hallam-Baker <phill@hallambaker.com <mailto:phill@hallambaker.com>> wrote:
> > 
> > IPv6 isn't actually a 'protocol' as such.
> 
> It might be useful to provide your definition of a protocol...
> 
> > It is merely a data structure.
> 
> You have described the messages only, which alone has never been enough to define a protocol.
> 
> Usually that is the case. But IP is a rather peculiar exception. There is lots of stuff above and lots of stuff below and there is the routing layer out to the side. But what is there to the packet layer except the packet format and the rule that you take a packet from the input port, decrement a counter and pass it to the output port.

See the note I posted to Stephanie. There is a LOT there beyond just counter decrement.

Just because a separate mechanism populates the forwarding table also doesn’t override the longest-prefix nature of that table, nor that it includes both outgoing interface and next-hop IP.

> How far is it possible to move from that approach and still be doing packet data? You can change the selection of which packet is chosen to pass next or affect the pass/drop rules.

Yes, you can change the order - but that’s because IP is defined as not preserving order. You can drop - because IP does not guarantee delivery. That doesn’t undo the many other rules that are still followed.

> 
> You can redefine the bits’ behaviors and meanings, but that would be defining a new protocol, at which point there’s little utility if any in keeping the bit patterns the same.
> 
> My point is simply this: what is it that cannot be done within the constraints of IPv6 would motivate a new protocol?

Simply put, take anything IPv6 requires and change it. No RA. No ND. No longest-prefix match. Different address locations or bit meanings within those addresses. Basically, take everything that is IPv6 and undo it.

> We keep having people coming along making these suggestions for IPv8, IPv10, etc. etc. and the inventors never once seem fit to ask what is so different about their proposal it can't be done in IPv6.

It’s definitely fair to ask “is there a way to do what you want within the IPv6 protocol”, or, for that matter, any other existing protocol (GRE, IPsec, etc.).

> The whole point of the Internet is the narrow waist is really simple.

There are many “whole points” to the Internet. Globally unique addressing, local forwarding decisions with global impact, packets that can’t circulate forever, finite but variable length messages, etc. Narrow waist is only one of those points.

Joe