Re: Non routable IPv6 registry proposal

Masataka Ohta <> Sat, 23 January 2021 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03E513A1188 for <>; Sat, 23 Jan 2021 05:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.16
X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lVhuCzw1QxYq for <>; Sat, 23 Jan 2021 05:04:33 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B5E9A3A1187 for <>; Sat, 23 Jan 2021 05:04:32 -0800 (PST)
Received: (qmail 34105 invoked from network); 23 Jan 2021 12:43:15 -0000
Received: from (HELO ? ( by with SMTP; 23 Jan 2021 12:43:15 -0000
Subject: Re: Non routable IPv6 registry proposal
References: <> <> <> <> <>
From: Masataka Ohta <>
Message-ID: <>
Date: Sat, 23 Jan 2021 22:04:27 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 Jan 2021 13:04:35 -0000

Fernando Gont wrote:

>>> I'd have agreed with you. BUt since 
>>> draft-ietf-spring-srv6-network-programming has been approved by the
>>> IESG, you probably cannot make such assertion anymore.
>> One draft that doesn’t update or obsolete numerous others does not 
>> undermine 40 yrs of E2E.
>> Esp. when (AFAICT) that doc series never mentions how transport 
>> protocols are supposed to deal with indeterminate endpoint addresses
>>  in their pseudo headers or the impact to security protocols at the 
>> transport (not transport content) layer.
> One *internet-draft* certainly doesn't undermine E2E. However, I guess
> that an *RFC* published as a "Proposed Standard" probably does 
> (undermine) E2E? -- (draft-ietf-spring-srv6-network-programming has been 
> approved by the IESG).


That the draft state "any complex user-defined behavior" means
it is subject to incompleteness theorem applicable to any
system complex enough to be able to handle natural numbers, which
means its behavior can not be fully reversed by external systems
to restore the E2E transparency even though its behavior is
formally fully described, which means the E2E principle can
not be kept regardless of whatever random things IESG might
have stated.

It is *VERY* well known that powerful formal description can not
fully analyzed mechanically, which is the incompleteness theorem.

So, the draft or PS or whatever is totally broken. Just ignore
it along with people who are working for it.

The only formal system fully analyzed mechanically is finite
state systems.

So, if there is similar draft but only applicable to "behavior
only as complex as to be represented by finite state automaton",
the draft may be valid, but, such representation is so poor to
be useful.

						Masataka Ohta


The situation has been obvious when deoccifying was mentioned by
IAB, which means most, if not all, of them do not understand the 
incompleteness theorem.


E2E transparency can be fully restored by end systems, even if it
is disturbed by intermediate systems, if, and only if, the end
systems not merely have formal description of the intermediate
systems but can actively and properly interact with the intermediate
systems to control actively their internal activities.