Re: New Approach For Discussing IPv10.

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 19 April 2021 03:42 UTC

Return-Path: <hallam@gmail.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 BFADE3A1BAB for <ietf@ietfa.amsl.com>; Sun, 18 Apr 2021 20:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Level:
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 dCRH186O3H_q for <ietf@ietfa.amsl.com>; Sun, 18 Apr 2021 20:42:42 -0700 (PDT)
Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CA63A1BAA for <ietf@ietf.org>; Sun, 18 Apr 2021 20:42:41 -0700 (PDT)
Received: by mail-yb1-f176.google.com with SMTP id n12so37091546ybf.8 for <ietf@ietf.org>; Sun, 18 Apr 2021 20:42:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zb6MVGjRl0gs5fmQUTVp46NKRvGYsk7tYgPwn8MBS6k=; b=kI4iHwaOICQtEFdQ/KMbHSEt1m3RZPz6ZP+lAWjVaIb9RzUSXszs++YWJE19BBp0uY u+L9a2/qJ53EkXCVNszAFRry/tbBlItHHRQ0QLFbHugpM4/GOdbsAPRaYZGRrsFf9DmK zZ8cyZsRMszlUJCBvlGXP6StkdVjnha9iASWovu5Gx6A+61b9rD5Vsnbwt4bZUkKtZq+ xbIPr80ciUxY3Pbw2XRL2BsqYiZAhE8yqFHDEq6JVusJhQtfzCXhGS3qlH1RUqeSjCiZ Z8I2MvD4afZAfLqzR/+EfTLdSfiR3+g8QcEZQFI54qQ/+dwa0JJ2cPAjq1MD5P7qtXNV RzxA==
X-Gm-Message-State: AOAM532cWuMIyLp0suT9wyn+Qf6i8c2/2iLvY2wlsuPJi3qnXaHWBZWl sHr+hpkMLRmqFZu25l7Et+eHHVen+C68R7BYQIo=
X-Google-Smtp-Source: ABdhPJxU9lSG1bFhaSlilYhZkNVRyMlF0Pm4KaXy15ZREienBcN6iog5TjvrWHLg1yXAWyzodGsDSu3TGLzHZUq+b2A=
X-Received: by 2002:a25:aa90:: with SMTP id t16mr13686747ybi.56.1618803760986; Sun, 18 Apr 2021 20:42:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwhV01N_uuFV8TfiyegpqDLmUYwxBcmkUAGG-HfJ7vSB+Q@mail.gmail.com> <989A5048-5EA8-479B-9231-D61B646E46F5@strayalpha.com>
In-Reply-To: <989A5048-5EA8-479B-9231-D61B646E46F5@strayalpha.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sun, 18 Apr 2021 23:42:28 -0400
Message-ID: <CAMm+Lwhy0c6G7YLx8n7Ya7psG6VxcEckk-ncKg750rscuz-Yaw@mail.gmail.com>
Subject: Re: New Approach For Discussing IPv10.
To: Joe Touch <touch@strayalpha.com>
Cc: Khaled Omar <eng.khaled.omar@outlook.com>, Lloyd W <lloyd.wood@yahoo.co.uk>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000227dee05c04b1fed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IsiUPs22zEFNqWZfIKyRmY1M0S4>
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 03:42:47 -0000

On Sun, Apr 18, 2021 at 1:23 AM Joe Touch <touch@strayalpha.com> wrote:

>
>
> > On Apr 17, 2021, at 9:49 PM, Phillip Hallam-Baker <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.

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.


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?

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.


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