IETF Logo Mail Archive

Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

"touch@strayalpha.com" <touch@strayalpha.com> Fri, 22 March 2024 04:01 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BC1C14F6B8 for <int-area@ietfa.amsl.com>; Thu, 21 Mar 2024 21:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.326
X-Spam-Level:
X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJOhCI411Ih2 for <int-area@ietfa.amsl.com>; Thu, 21 Mar 2024 21:01:42 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C16E6C14F60E for <int-area@ietf.org>; Thu, 21 Mar 2024 21:01:42 -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=vzMpmMCg42Gfdq16eRU6EVaeeRVt1y2tMOc5CeC0I54=; b=omeE8Xllcx726fmJe3GrMUhH30 85gyLI4jedGIeD11F4OOIaHPekrbQgRqiAOST7R+dXSZKZi2wrB68oaXcdZNij57/6BEit52BS2uU lfvIOmrPFU5bqwujVL5/KlbDJ2+4LdEawOrRBeQLtbsDJTYcgGtP4wfik+UjfSVu16MLQczB/fO8k ZVb7Pj9dG7vAOfxdPoj2Pb5P5t7qWjUcDTJISXcgGwpUj6VNqN3LXlOCsn+CvEIsXYFgPo78EPwne Bsb0FUfUgWJy31C3/OxUzVrhSpe50MsgqhcNy92KbZng7TzvznamUr7DgY8q9N8MmFPfDtxa0y9AX zNdqYMrg==;
Received: from [172.58.209.101] (port=14939 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <touch@strayalpha.com>) id 1rnW64-0079ij-0n; Fri, 22 Mar 2024 00:01:41 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_F58DE3BF-68DF-41A8-839C-4CF6EDB56B5A"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CALx6S34F0FTyUhf8ew0tAuyaLJquRPdiOHVnT0OE7pFAQY+c_Q@mail.gmail.com>
Date: Thu, 21 Mar 2024 21:01:23 -0700
Cc: Toerless Eckert <tte@cs.fau.de>, int-area <int-area@ietf.org>
Message-Id: <5820339B-C98C-4F1F-93E7-B56106C66C99@strayalpha.com>
References: <170865175505.14082.3856617737779580933@ietfa.amsl.com> <CALx6S363oh+7rNMaMa0s+9A-xeyLBy+ct-Q_Bx0xQm_di1PPJA@mail.gmail.com> <ZeZjGyxmuapXz5tb@faui48e.informatik.uni-erlangen.de> <CALx6S34OFL7tzabL+RMvB3nkad5k9esCD_dFpMi6DUtUEG-Dmg@mail.gmail.com> <ZedO1u7aheBhZ26N@faui48e.informatik.uni-erlangen.de> <ZfurRK_oNVES2hVz@faui48e.informatik.uni-erlangen.de> <CALx6S36L57vPa5YkiV3khYbFpPPgPUVynWaRVno0BufvXcALeA@mail.gmail.com> <Zfu5GQ7101lMnHGs@faui48e.informatik.uni-erlangen.de> <DCE2D4E2-9C5D-40B7-952F-7424E7FCBAFE@strayalpha.com> <CALx6S37XnjWcpeGZUQWXFyE0jP=XyodmUBBh+69SonLw3ndvaQ@mail.gmail.com> <57C622DE-2C8E-4415-805D-7053309B0D01@strayalpha.com> <CALx6S36Dpn0qC9e0ZGaK-ckbT58hRkeLHDKkNqmmJn0vQ5ONUw@mail.gmail.com> <B1CC8B09-A701-4401-8BEA-C31DE0FD0FD3@strayalpha.com> <CALx6S354xQHqk4y+0dTkTQ524n5vrN01gJe57FBjbV1UuToWLA@mail.gmail.com> <FF84650B-6739-4D12-B390-977627A1296E@strayalpha.com> <CALx6S34ePRxNNqx1TOSon9=QgKvq0wJh7mMFRH7gr2OUjZ_zmw@mail.gmail.com> <E89DABED-3612-4B18-93FF-4FB31A072508@strayalpha.com> <CALx6S34F0FTyUhf8ew0tAuyaLJquRPdiOHVnT0OE7pFAQY+c_Q@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3774.500.171.1.1)
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/int-area/g6jfwAXWpkpYZRG00c5F4hQgQ9s>
Subject: Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Internet Area WG Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 04:01:46 -0000

On Mar 21, 2024, at 8:48 PM, Tom Herbert <tom@herbertland.com> wrote:
> 
> 
> 
> On Thu, Mar 21, 2024, 8:28 PM touch@strayalpha.com <mailto:touch@strayalpha.com> <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
>> <Joe>
>>> 
>>>> You’ve just described a transport protocol that the intermediate nodes know.
>>> 
>>> 
>>> Joe,
>>> 
>>> A transport protocol doesn't meet the requirements. They don't work with any transport protocol other than themselves,
>> 
>> They do when you define them that way, i.e., “here’s a transport protocol header A, after which you can use any transport protocol, as indicated in field X”.
>> 
>>> and intermediate nodes cannot robustly parse transport headers 
>> 
>> They can’t parse these either. But, if upgraded to do so for headers “A”, as per above.
>> 
>>> This has to be L3 protocol.
>> 
>> It’s not. It’s L4, or at least that’s what it is* to IP.
> 
> 
> Joe,
> 
> Please give one concrete example of a transport protocol explicitly designed to be processed and modified by intermediate nodes.

The one in this draft.

> ...
> IMO, network nodes have no business participating in transport layer, doing so has led to a lot of protocol ossification.

Nodes participate in the protocols that they know about. 

There are BITW stacks that process IPsec. As noted many times, NATs do this for TCP.  There have been BITW devices that coalesce or split TCP packets.

No, this isn’t possible for protocols designed to NOT allow it (authentication, encryption, etc.).

But the protocol defined in this draft IS designed to allow - and encourage - just that.

It does’t make it “not a transport”. It makes it a “transport that intermediate nodes know they can modify”.

Again, I’m not saying it’s not useful. I’m saying it’s just another transport - one with particular properties, but still just a transport.

Joe

v2.23.0 | Report a Bug | By Email