Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol

Joseph Touch <> Fri, 20 March 2020 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D287B3A09ED for <>; Fri, 20 Mar 2020 08:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ecRlAmkTb__S for <>; Fri, 20 Mar 2020 08:04:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2D3D43A09B3 for <>; Fri, 20 Mar 2020 08:04:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=VYKxJGuF47Rom7vN01u1bCZw15XwxGGMSdIlbF5cF70=; b=XCIwfcxauYlqjfaG9quHpvFfD mg0Ko6NDscDOe9JdLAd+qBo4DmcU3NuKPegS1M67KHCKRF5o3p5NAmUSsUHt1CMP04SdioBgd/5fz ly636K2z2NinlXSEDAQLxe2BSxZuiAEm7/hmrZL/sbUXbXWZnNNOV05hxwsLDzC0TDcXr2hguz2BV r01rrS4/MhsQ/pwPkrJYUgDegCJvxd6SokGiIO29EDRh8oo0rgyGrsMcAtxDMwswvOY3b2P2hbmDK 4pBBGVmNdii9GXcYowaZ0BYklpMGW4QwoOXHUdr9vs7KQeLLjsSsfM13h+mHNY42aPTKzV0fNqSkN TV5xpgfVQ==;
Received: from ([]:52907 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1jFJCU-0046VY-MU; Fri, 20 Mar 2020 11:04:47 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_86F97028-90EC-4BA4-8B0C-41C1671159BC"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Fri, 20 Mar 2020 08:04:40 -0700
Cc: int-area <>, Suresh Krishnan <>
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Jon Maloy <>
X-Mailer: Apple Mail (2.3445.9.1)
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] IP Protocol number allocation request for Transparent Inter Process Communication (TIPC) protocol
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Mar 2020 15:04:51 -0000

> On Mar 20, 2020, at 7:09 AM, Jon Maloy <> wrote:
> Adding cc to <>, since I forgot that in my original response.
> On 3/19/20 9:18 PM, Joseph Touch wrote:
>>> On Mar 19, 2020, at 4:46 PM, Jon Maloy < <>> wrote:
>>>>> IP addresses are no good in the *user API*, because they are location bound. 
>>>>> That is also why DNS was invented, I  believe. 
>>>> DNS names are intended to be a human-rememberable alias to an IP address. They do not indicate a location any more than an IP address does or does not.
>>> Exactly. Read what I wrote again.
>> IP addresses are no good in the USER API because they are location bound.
>> 	False. DNS names are provided as an alternative for the user API because they are easier for people to remember and type.
> Then I should probably rephrase this so saying that "IP addresses AND DNS names and are no good in the user API...", although I don't quite agree with that. DNS names are of course much more convenient for a user to deal with than IP addresses. 

Type in <>

Now type in its IPv6 address.

Now see if you remember google’s website DNS or its IPv6 address. That’s what the DNS was originally intended for.

>> 	DNS names are no more or less location-independent than IP addresses.
>> This is also why DNS was invented...
>> 	False. The reason the DNS exists has nothing to do with location. It’s simply string substitution for convenience, or at least was ONLY that originally.
> I think you just supported my case for a location independent addressing scheme.

I am - but then I’m baffled why you want to run direct over IP. Ethernet has location independent addresses; IP does not* (see next part).

> This was one of the original motivations for developing TIPC in the first place.  A programmer using TIPC can hard code his service addresses if he wants to, ignoring the number of or location of the corresponding endpoints, even as those move around or scale up/down quite fast.

Anycast gives you location independent addresses at the cost of doing discovery “inside the network layer”.

However, even if you have those addresses, you still need to identify the service types (which is what we use ports for).


I’m still stuck at why you want to run direct over IP. If you want Ethernet that bridges across routers, GRE does that. If you want loc-independent addresses for services, UDP over IP using anycast does that.

What is the specific gain of needing IP but not allowing a transport? AFAICT, it’s all down to GSO - which is an implementation. If GSO doesn’t do what you want, it would be useful to take your issues there or edit the code yourself and submit the patches.