Re: [Int-area] Continuing the addressing discussion: what is an address anyway? Re: 2201291533.AYC

"Abraham Y. Chen" <aychen@avinta.com> Sat, 29 January 2022 21:05 UTC

Return-Path: <aychen@avinta.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 5AF983A0E89; Sat, 29 Jan 2022 13:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=avinta.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 yjiGyfR9R5zL; Sat, 29 Jan 2022 13:05:48 -0800 (PST)
Received: from mx22-1.lowesthosting.com (cp22.lowesthosting.com [23.111.133.162]) (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 A17383A0E88; Sat, 29 Jan 2022 13:05:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avinta.com; s=default; h=In-Reply-To:References:Cc:To:Subject:From:MIME-Version:Date: Message-ID: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=uH7aaQ2HK6MvIULQ8DsLfcBxePuTt4zZddyknHTdXik=; b=j/MCYHmWcCZfVPfN0W/V4n5hEE nxwkV/mIQYvE6LgXUfWg7+taIBZ/1AZOtk5Hy46cu5jDxxPOK2///aS5DiliEELuh2pKRkBV/lwSG d2EQ3KD1zmHMWZPpzYBkfPB0d8ZwdZ/qWHIs0rCPULTgKa738Xm4+SI+h3AFkNX+A3yDZLBNa3d4l M4m2SZKgQ4tG9pLTK30hA7soNt4GK2vC+tpJ67bEzqkX2DsIL/F/Wu2HGJ3XxiBkB1hNAZnKKUgvm VdTwiy6COMa86IHRQ97u12A2xSHk6ssDRZYEuavdboET3fLRRT6sZtdYFsXRH3Yq2fAznP5CF4xV0 FD39M2ZA==;
Received: from cpe-24-193-166-56.nyc.res.rr.com ([24.193.166.56]:57248 helo=[192.168.1.142]) by mx22-1.lowesthosting.com with esmtpa (Exim 4.94.2) (envelope-from <aychen@avinta.com>) id 1nDuug-0001JN-4Q; Sat, 29 Jan 2022 16:05:43 -0500
Content-Type: multipart/alternative; boundary="------------qqKEqXP1sODSHsEUo4mlLe79"
Message-ID: <63c406a4-41ff-5cd2-c4f5-918919c7a7d8@avinta.com>
Date: Sat, 29 Jan 2022 16:05:33 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
From: "Abraham Y. Chen" <aychen@avinta.com>
To: "int-area@ietf.org" <int-area@ietf.org>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, int-area-request@ietf.org
References: <mailman.53.1643400011.23818.int-area@ietf.org>
Content-Language: en-US
X-Priority: 1 (Highest)
In-Reply-To: <mailman.53.1643400011.23818.int-area@ietf.org>
X-Antivirus: Avast (VPS 220129-6, 1/29/2022), Outbound message
X-Antivirus-Status: Clean
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 - mx22-1.lowesthosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - avinta.com
X-Get-Message-Sender-Via: mx22-1.lowesthosting.com: authenticated_id: aychen@avinta.com
X-Authenticated-Sender: mx22-1.lowesthosting.com: aychen@avinta.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/m-88ypR01CN8-qxmknWOKSgZhO0>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway? Re: 2201291533.AYC
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 29 Jan 2022 21:05:53 -0000

Hi, Alex:

1)    Thanks for bringing up many aspects related to the IP address 
subject. Rather than dealing with them individually within the confine 
of the current Internet environment that each will lead to many other 
involved discussions, I would suggest you to look at this subject from 
an "outside the box" perspective. That is, is there an addressing / 
identification scheme that may lead to a different set of conditions 
which could perhaps be less problematic?

2)    Please review a short whitepaper below. Its Reference IV is an 
IETF Draft that provides the technical background for the proposal.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

I look forward to your thoughts.

Regards,


Abe (2022-01-29 16:05 EST)




> Message: 4
> Date: Fri, 28 Jan 2022 12:48:59 +0100
> From: Alexandre Petrescu<alexandre.petrescu@gmail.com>
> To:int-area@ietf.org
> Subject: Re: [Int-area] Continuing the addressing discussion: what is
> 	an address anyway?
> Message-ID:<092dc5e4-2dc8-26f5-5f63-edc72f00c54a@gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Sorry, I  take advantage of this valuable public conversation between
> you to mention a point that might be related.
>
> Le 25/01/2022 ? 20:30, Geoff Huston a ?crit :
>> [...] various judgemental observations (Like "NAT is evil?, ?NBATs
>> break stuff?, etc,) feel free, but they are your constructions, not
>> mine. The issue for me is not judgments of ?good? or ?bad?, but
>> simply to explore, without overtones of judgement, exactly what an IP
>> address represents in today?s Internet. [...]
> Without jugding, and without thinking others might judge, i.e. to
> qualify as 'good' or 'bad'.
>
> I do think there might be value in questioning whether there might be
> something inherent in the IP addressing system which might lead to less
> positive consequences.  It is a question on the cause-to-effect dynamics.
>
> What in the IP addressing system makes it possible that NAT has been
> designed and used largely?  Lack of space in v4 - ok - but is there
> anything more to that problem, now that IPv6 solves the space size
> problem?  Is the fact that NAT kind of probably protection is helping?
>
> For example, if the IP addressing system had variable length addresses
> (instead of fixed length) - would that make the translation process of
> NAT be unacceptably long, and hence no NAT would be feasible?
>
> Other than that, what other characteristic of the IP addressing system
> might have an impact on the existence of NATs?
>
> What other characteristic of the IP addressing system has no impact at
> all on the existence of NATs?  I.e. one could change that characteristic
> but NATs would still be designed.
>
> Other than NAT and IP addresses, there are other aspects of the current
> Internet addressing that are less desirable.
>
> For example: the open Internet and its open addressing system leads to a
> need of privacy respecting for the individual; which is good.  At the
> same time, the new privacy rules are not making everyone happy.  Some
> times it goes to large extents.  For example, some addresses of web
> sites are not visible to others _because_ of that privacy ruling.  Not
> all websites in all countries accept to abide to the privacy rules of
> other countries.  Such websites refuse to abide and block access altogether.
>
> That situation is clearly against the openness of access in the Internet.
>
> It is not a matter of paying money or not to access data.  Even if one
> pays one is still not given access because one is situated in a country
> of a particular privacy ruling.
>
> It is a strange situation in which the ruling of privacy is not
> accepted.  Those sites who do not accept to deliver data according to
> the privacy rules do so not because they dont agree with a general
> principle of privacy, but because they dont agree with that particular
> ruling (GDPR in this case) of privacy.
>
> What is at fault for that situation?
>
> Is there something in the Internet addressing system at higher layer
> (above IP) that might be qualified as being a little bit in error for
> that lack of access?
>
> For example, if the 'cookies' used by HTTP involved host names (host
> names are also a sort of addresses) whose structure was agreed locally,
> then there would be more positive view of the generally negative view of
> 'tracking'.  For example, a locally agreed way to identify people is
> generally accepted (license plates, faces, more) but a universal way of
> identification (hostname containing 'Windows' characteristics) might be
> less accepted.
>
> Alex
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> ------------------------------
>
> End of Int-area Digest, Vol 197, Issue 25
> *****************************************



-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus