Re: Diversity of MUAs (was Re: How threading works (was Re: Root Cause Re: 202401102221.AYC ...))

[Peter Potvin via NANOG]

*audible sigh*

Yet another useless thread added to my Gmail inbox because of a changed
subject line.

Can we please stop doing this for conversations that are about the same
topic? Numerous users on this list have clearly shown they are annoyed by
this, and frankly is something that the list admins should be looking into
- it spams everyone’s inboxes and makes conversations harder to follow.

Kind regards,
Peter

On Sun, Jan 14, 2024 at 01:34 Ellenor Bjornsdottir via NANOG <
nanog@nanog.org> wrote:

> On Sunday, January 14, 2024 6:01:45 AM UTC William Herrin wrote:
> > On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields 
> wrote:
> > > On 1/12/24 3:04 PM, Mu wrote:
> > > > Would it be possible for you to reply in-thread, rather than
> creating a new thread with a new subject line every time you reply to
> someone?
> > > >
> > > > Trying to follow the conversation becomes very difficult for no
> reason.
> > >
> > > Threading has nothing to do with subject lines.  RFC822 (now 5822)
> specifies
> > > how this works based on message ID.  This thread displays fine in
> threaded
> > > mode in my MUA and in the archives.
> >
> > Hi Bryan,
> >
> > Respectfully, your MUA is not the only MUA. Others work differently.
> >
> > GMail, for example, follows the message IDs as you say but assumes
> > that if you change the subject line in your reply (more than adding
> > "Re:") then you intend to start a new thread from that point in the
> > discussion. It groups messages accordingly.
> >
> > This is not an unreasonable expectation: if you merely want to
> > continue the current conversation without going off on a new tangent
> > then there's no need for a different subject line.
> >
> > Regards,
> > Bill Herrin
>
> I have been using KMail to read this list. Just thought I'd throw my hat
> in the ring there, I guess!

Re: Diversity of MUAs (was Re: How threading works (was Re: Root Cause Re: 202401102221.AYC ...))

[Ellenor Bjornsdottir via NANOG]

On Sunday, January 14, 2024 6:01:45 AM UTC William Herrin wrote:
> On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields  wrote:
> > On 1/12/24 3:04 PM, Mu wrote:
> > > Would it be possible for you to reply in-thread, rather than creating a 
> > > new thread with a new subject line every time you reply to someone?
> > >
> > > Trying to follow the conversation becomes very difficult for no reason.
> >
> > Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies
> > how this works based on message ID.  This thread displays fine in threaded
> > mode in my MUA and in the archives.
> 
> Hi Bryan,
> 
> Respectfully, your MUA is not the only MUA. Others work differently.
> 
> GMail, for example, follows the message IDs as you say but assumes
> that if you change the subject line in your reply (more than adding
> "Re:") then you intend to start a new thread from that point in the
> discussion. It groups messages accordingly.
> 
> This is not an unreasonable expectation: if you merely want to
> continue the current conversation without going off on a new tangent
> then there's no need for a different subject line.
> 
> Regards,
> Bill Herrin

I have been using KMail to read this list. Just thought I'd throw my hat in the 
ring there, I guess!

signature.asc
Description: This is a digitally signed message part.

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[William Herrin]

On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields  wrote:
> On 1/12/24 3:04 PM, Mu wrote:
> > Would it be possible for you to reply in-thread, rather than creating a new 
> > thread with a new subject line every time you reply to someone?
> >
> > Trying to follow the conversation becomes very difficult for no reason.
>
> Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies
> how this works based on message ID.  This thread displays fine in threaded
> mode in my MUA and in the archives.

Hi Bryan,

Respectfully, your MUA is not the only MUA. Others work differently.

GMail, for example, follows the message IDs as you say but assumes
that if you change the subject line in your reply (more than adding
"Re:") then you intend to start a new thread from that point in the
discussion. It groups messages accordingly.

This is not an unreasonable expectation: if you merely want to
continue the current conversation without going off on a new tangent
then there's no need for a different subject line.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Oliver O'Boyle]

Thank you, everyone, for your responses.

Abe, I appreciate your enthisam but it is obvious you are not interested in
collaboration. You are singularly-minded and trollish.

I am assigning your email address to my spam filters. I will not see any
future communication from you.

O.


On Sat, Jan 13, 2024, 4:13 p.m. Abraham Y. Chen  wrote:

> Hi, Seth:
>
> 0)Thanks for bringing up this pair of Drafts.
>
> 1)While I believe your "IPv4 Unicast Extension" team carried on with
> the first, Avinta got accidentally exposed to the second. After analyzed
> the hurdle it faced in adding on to RFC1918, the EzIP Project is now
> focusing on enhancing CG-NAT by expanding  RFC6598.
>
> Regards,
>
>
> Abe (2024-01-13 16:08)
>
> On 2024-01-12 14:45, Seth David Schoen wrote:
>
> Michael Thomas writes:
>
>
> I wonder if the right thing to do is to create a standards track RFC that
> makes the experimental space officially an add on to rfc 1918. If it works
> for you, great, if not your problem. It would at least stop all of these
> recurring arguments that we could salvage it for public use when the
> knowability of whether it could work is zero.
>
> In 2008 there were two proposals
> https://datatracker.ietf.org/doc/draft-fuller-240space/https://datatracker.ietf.org/doc/draft-wilson-class-e/
>
> where the former was agnostic about how we would eventually be able to
> use 240/4, and the latter designated it as RFC 1918-style private space.
> Unfortunately, neither proposal was adopted as an RFC then, so we lost a
> lot of time in which more vendors and operators could have made more
> significant progress on its usability.
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_2842409467345373561_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: classic mail, was Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[John Levine]

It appears that Randy Bush  said:
>> Some of us still use pine$B!D(B
>
>i thought most pine users had moved to mutt

Some, but pine (now called alpine) is still actively maintained and
does some things better than mutt, particularly if you want to keep
track of multiple inboxes on different servers.

>randy, who uses wanderlust under emacs :)
>

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Joel Esler]

Things you have to remember.  Not everyone uses thunderbird.  Not every mail client threads like thunderbird.  — Sent from my iPhoneOn Jan 13, 2024, at 17:39, Abraham Y. Chen  wrote:

  

  
  
Hi, Bryan:

  
0)    Thank you so much
for coming to the rescue!!! 
  

  
1)    Basically trained
as a radio frequency hardware engineer, I am only capable of
using software as tools necessary for my work. For eMail, I have
been using ThunderBird ever since its beginning. With my own
time-stamping Subject line discipline, I never needed its
threading function. When I received complaints last year, I
experimented threading on it and found that it was doing just
fine. Whether I prefixed or suffixed the timestamps to the
Subject line could not break it. I requested counter examples
from those who were having difficulties with my MSGs, but
received none. Frustrated but not able to do anything, I went
back to continue my EzIP work, leaving this subject in the back
burner of my mind. This time around, the problem popped up again
in the midst of large number of MSG exchanges. I am so relieved
that you presented the threading on the NANOG eMail server that
mirrors what I saw on my own PC. So, we now have a common
reference for everyone to look at this phenomenon. (Why no one else knew about this facility?) 
  

  
2)    From the Wikipedia
explanation of RFC5822, I as a ThunderBird user, really have
nothing to do with the Message-ID that it puts on my MSGs nor
how does it make use of such to display the threads. And, my
Subject line style can't affect it either. So, why some
colleagues are having difficulties with just my eMails, but
seemly not from others? Could this be caused by the large number
of MSGs within a short period of time that amplified this issue?
From another feedback, I realized that some colleagues may be
using plain text text editors or alike for eMail, because they
could not see color nor italic emphasizing of my text. Could
such be related to this issue?
  

  
I would appreciate very
much if you could advance my education with some explanations
after perhaps discussions with those offended by my MSGs. 
  


Regards,

  

  
Abe (2024-01-13 17:37)



 







On
  1/12/24 3:04 PM, Mu wrote: 
  Would it be possible for you to reply
in-thread, rather than creating a new thread with a new subject
line every time you reply to someone? 

Trying to follow the conversation becomes very difficult for no
reason. 
  
  
  Threading has nothing to do with subject lines.  RFC822 (now 5822)
  specifies how this works based on message ID.  This thread
  displays fine in threaded mode in my MUA and in the archives. 
  
  https://en.wikipedia.org/wiki/Conversation_threading
  
  https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html
  
  
  If people could please reply to threads properly, inline and
  trimming non relevant text, it would make following discussion
  much easier. 
  



  Virus-free.www.avast.com 

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Warren Kumari]

On Sat, Jan 13, 2024 at 9:48 AM, Tom Beecher  wrote:

> Vint told you the same thing other people have been telling you for years.
> You don't seem to name drop anyone else. Weird.
>


Indeed — Vint made an observation, but this was not intended to be
endorsement…

Implying that it is is disingenuous…

W


> Respectfully, you have no credibility in this area. I happened to notice
> this gem re-reading your draft last night,
>
> A.1.1. T1a Initiates a Session Request towards T4a
>>
>>T1a sends a session request to SPR4 that serves T4a by a plain IP
>>packet with header as in Figure 5, to RG1. There is no TCP port
>>number in this IP header yet.
>>
>>
> That's a curious statement there at the end. Let's continue though.
>
> A.1.2. RG1 Forwards the Packet to SPR1
>>
>>  RG1, allowing be masqueraded by T1a, relays the packet toward SPR1
>>by assigning the TCP Source port number, 3N, to T1a, with a header as
>>in Figure 6,. Note that the suffix "N" denotes the actual TCP port
>>number assigned by the RG1's RG-NAT. This could assume multiple
>>values, each represents a separate communications session that T1a is
>>engaged in. A corresponding entry is created in the RG1 state table
>>for handling the reply packet from the Destination site. Since T4a's
>>TCP port number is not known yet, it is filled with all 1's.
>>
>> 0   1   2   3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  1 |Version|IHL (6)|Type of Service|   Total Length (24)   |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  2 |Identification |Flags| Fragment Offset |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  3 | Time to Live  |Protocol   |Header Checksum|
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  4 |  Source Host Number (240.0.0.0)   |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  5 |   Destination Host Number (69.41.190.148) |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  6 |   Source Port (3N)|   Destination Port (All 1's)  |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>  Figure 6  TCP/IP Header: From RG1 to SPR1
>>
>>
> Wait a second.. what is a 'TCP/IP header'?
>
> A.1.5. T4a Replies to SPR4
>>
>>T4a interchanges the Source and Destination identifications in the
>>incoming TCP/IP packet to create a header as in Figure 9, for the
>>reply packet to SPR4.
>>
>> 0   1   2   3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  1 |Version|IHL (6)|Type of Service|   Total Length (24)   |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  2 |Identification |Flags| Fragment Offset |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  3 | Time to Live  |Protocol   |Header Checksum|
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  4 |  Source Host Number (240.0.0.10)  |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  5 |   Destination Host Number (69.41.190.110) |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>  6 |  Source Port (10C)| Destination Port (0C) |
>>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>  Figure 9  TCP/IP Header: From T4a to SPR4
>>
>>
> Oh my.. you actually meant it.
>
> The draft authors don't appear to understand that TCP headers and IP
> headers **are not the same thing**.
>
> I would suggest reviewing RFC 791 ( IPv4 ) , and RFC 793 / 9293 ( TCP,
> original and updated ).
>
>
>
> On Sat, Jan 13, 2024 at 7:35 AM Abraham Y. Chen  wrote:
>
>>
>> Hi, Tom:
>>
>> 1)" ...  Implying that Vint Cerf ever said anything about EzIP
>> ... ":
>>
>> FYI - Please see the below copy of a partial eMail thread. Bold, red
>> colored and Italicized letters are to focus on the topic.
>>
>> ***
>>
>>
>> internetpol...@elist.isoc.org  eMail thread
>>
>>
>>  On 2021-10-18 16:34, Abraham Y. Chen wrote:
>>
>>
>> Dear Vint:
>>
>>
>>  Yes, this is one perspective for visualizing the EzIP proposal.
>>
>> Thanks,
>>
>>  Abe (2021-10-18 16:33 EDT)
>>
>>
>>  Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation
>>
>>
>>  On 2021-10-18 10:39, *vinton cerf* wrote:
>>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Randy Bush]

> Some of us still use pine…

i thought most pine users had moved to mutt

randy, who uses wanderlust under emacs :)

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Abraham Y. Chen]

Hi, Bryan:

0)    Thank you so much for coming to the rescue!!!

1)    Basically trained as a radio frequency hardware engineer, I am 
only capable of using software as tools necessary for my work. For 
eMail, I have been using ThunderBird ever since its beginning. With my 
own time-stamping Subject line discipline, I never needed its threading 
function. When I received complaints last year, I experimented threading 
on it and found that it was doing just fine. Whether I prefixed or 
suffixed the timestamps to the Subject line could not break it. I 
requested counter examples from those who were having difficulties with 
my MSGs, but received none. Frustrated but not able to do anything, I 
went back to continue my EzIP work, leaving this subject in the back 
burner of my mind. This time around, the problem popped up again in the 
midst of large number of MSG exchanges. I am so relieved that you 
presented the threading on the NANOG eMail server that mirrors what I 
saw on my own PC. So, we now have a common reference for everyone to 
look at this phenomenon. (Why no one else knew about this facility?)


2)    From the Wikipedia explanation of RFC5822, I as a ThunderBird 
user, really have nothing to do with the Message-ID that it puts on my 
MSGs nor how does it make use of such to display the threads. And, my 
Subject line style can't affect it either. So, why some colleagues are 
having difficulties with just my eMails, but seemly not from others? 
Could this be caused by the large number of MSGs within a short period 
of time that amplified this issue? From another feedback, I realized 
that some colleagues may be using plain text text editors or alike for 
eMail, because they could not see color nor italic emphasizing of my 
text. Could such be related to this issue?


I would appreciate very much if you could advance my education with some 
explanations after perhaps discussions with those offended by my MSGs.



Regards,


Abe (2024-01-13 17:37)






On 1/12/24 3:04 PM, Mu wrote:
Would it be possible for you to reply in-thread, rather than creating 
a new thread with a new subject line every time you reply to someone?


Trying to follow the conversation becomes very difficult for no reason.


Threading has nothing to do with subject lines.  RFC822 (now 5822) 
specifies how this works based on message ID.  This thread displays 
fine in threaded mode in my MUA and in the archives.


https://en.wikipedia.org/wiki/Conversation_threading
https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html

If people could please reply to threads properly, inline and trimming 
non relevant text, it would make following discussion much easier.





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

Re: IPv6? Re: Where to Use 240/4 Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Seth:

0)    Thanks for bringing up this pair of Drafts.

1)    While I believe your "IPv4 Unicast Extension" team carried on with 
the first, Avinta got accidentally exposed to the second. After analyzed 
the hurdle it faced in adding on to RFC1918, the EzIP Project is now 
focusing on enhancing CG-NAT by expanding  RFC6598.


Regards,


Abe (2024-01-13 16:08)

On 2024-01-12 14:45, Seth David Schoen wrote:

Michael Thomas writes:


I wonder if the right thing to do is to create a standards track RFC that
makes the experimental space officially an add on to rfc 1918. If it works
for you, great, if not your problem. It would at least stop all of these
recurring arguments that we could salvage it for public use when the
knowability of whether it could work is zero.

In 2008 there were two proposals

https://datatracker.ietf.org/doc/draft-fuller-240space/
https://datatracker.ietf.org/doc/draft-wilson-class-e/

where the former was agnostic about how we would eventually be able to
use 240/4, and the latter designated it as RFC 1918-style private space.
Unfortunately, neither proposal was adopted as an RFC then, so we lost a
lot of time in which more vendors and operators could have made more
significant progress on its usability.




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

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Mike Lyon]

Some of us still use pine…-MikeOn Jan 13, 2024, at 12:57, Abraham Y. Chen  wrote:

  

  
  
Hi, Gary:
0)    My apologies!
1)    I thought that I am one of only a few who
insist on using the most basic tools that get the job done, such
preferring hand tools than power tools if possible. I believed
that the ThunderBird eMail client software was pretty basic.
Your message just reminds me that there are colleagues here
probably still using plain text editors for eMail?
I shall keep this in mind for my future eMails.
Regards,

  
Abe (2024-01-13 15:54)







On 2024-01-13 14:45, Gary E. Miller
  wrote:


  Yo Abraham!

On Sat, 13 Jan 2024 07:35:09 -0500
"Abraham Y. Chen"  wrote:


  
     FYI - Please see the below copy of a partial eMail thread. Bold, 
red colored and Italicized letters are to focus on the topic.

  
  Uh, you realize many of us never see your red or italics?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	g...@rellim.com  Tel:+1 541 382 8588

	Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin




  Virus-free.www.avast.com 

How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[Bryan Fields]

On 1/12/24 3:04 PM, Mu wrote:

Would it be possible for you to reply in-thread, rather than creating a new 
thread with a new subject line every time you reply to someone?

Trying to follow the conversation becomes very difficult for no reason.


Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies 
how this works based on message ID.  This thread displays fine in threaded 
mode in my MUA and in the archives.


https://en.wikipedia.org/wiki/Conversation_threading
https://mailman.nanog.org/pipermail/nanog/2024-January/thread.html

If people could please reply to threads properly, inline and trimming non 
relevant text, it would make following discussion much easier.


--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[William Herrin]

On Sat, Jan 13, 2024 at 6:32 AM Christopher Hawker  wrote:
> Further, over the last three days you've changed the subject
> line of the thread at least 12 times. Can you please stop changing
>  it because every time you do, it starts a new thread and makes it
> rather difficult to keep track of the discussion. I also don't believe
> I'm the first one to raise this either.

He has indeed been asked to do so before but is too rude to comply.

Stop feeding the troll.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Abraham Y. Chen]

Hi, Gary:

0)    My apologies!

1)    I thought that I am one of only a few who insist on using the most 
basic tools that get the job done, such preferring hand tools than power 
tools if possible. I believed that the ThunderBird eMail client software 
was pretty basic. Your message just reminds me that there are colleagues 
here probably still using plain text editors for eMail?


I shall keep this in mind for my future eMails.

Regards,


Abe (2024-01-13 15:54)




On 2024-01-13 14:45, Gary E. Miller wrote:

Yo Abraham!

On Sat, 13 Jan 2024 07:35:09 -0500
"Abraham Y. Chen"  wrote:


      FYI - Please see the below copy of a partial eMail thread. Bold,
red colored and Italicized letters are to focus on the topic.

Uh, you realize many of us never see your red or italics?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com   Tel:+1  541 382 8588

Veritas liberabit vos. -- Quid est veritas?
 "If you can't measure it, you can't improve it." - Lord Kelvin




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

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Gary E. Miller]

Yo Abraham!

On Sat, 13 Jan 2024 07:35:09 -0500
"Abraham Y. Chen"  wrote:

>      FYI - Please see the below copy of a partial eMail thread. Bold, 
> red colored and Italicized letters are to focus on the topic.

Uh, you realize many of us never see your red or italics?

RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588

Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin


pgptJVE3TwVmO.pgp
Description: OpenPGP digital signature

Re: IPv4 address block

[Randy Bush]

>> If you limit each requesting organization to a /22 per year, we can
>> keep the internet mostly functional for decades to come,
> 
> at least in the ripe ncc service region, all this proved was that if
> the cost of registering a company (or LIR) and applying for an
> allocation was lower than the market rate of ipv4 addresses, then
> people would do that.
> 
> The root problem is unavoidable: ipv4 is a scarce resource with an
> inherent demand. Every policy designed to mitigate against this will
> create workarounds, and the more valuable the resource, the more
> inventive the workaround.

and complex policies lead to more complex workarounds which make the
internet crappier

> In terms of hard landings vs soft landings, what will make ipv6
> succeed is how compelling ipv6 is, rather than whether someone created
> a policy to make ipv4 less palatable. In particular, any effect from a
> hard landing compared would have been ephemeral.

amen

randy

Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

[Niels Bakker]

* ayc...@avinta.com (Abraham Y. Chen) [Sat 13 Jan 2024, 18:16 CET]:
0)    Your sender name is in an unusual format. It becomes just the 
generic NANOG address as the recipient for me to MSG send to.


Your numbered lists are 0-indexed. So clever! Also, your MUA 
seems to understand Mail-Followup-To, which is nice.



    Thanks for catching the typo. My understanding is that there is a 
general desire (human nature) to get a larger netblock than 100.64/10 
in CG-NAT. This could be used for either growing market or less 
dynamic reassignment. The 240/4 can provide additional benefits to 


So nobody in particular is asking for this. Thanks for confirming.


CG-NAT operations such as static addressing that no one has realized 
possible. So, I am putting the solution on the table. This is a basic 
process of sharing the new discoveries. Is there anything wrong with 
the process? On the other hand, if RFC6598 had picked 240/4 instead of 
100.64/10 as the netblock, we do not need today's discussions.


What's wrong with the process is that you're wasting the time of a lot 
of people on this mailing list with this crusade that has already 
veered into personal attacks such as when you questioned Randy Bush's 
experience. In that respect it would indeed have been better for 
RFC6598 to have picked 240/4 in the sense that it would have saved us 
94 out of the 104 mails currently in this thread and, unfortunately, 
counting.



-- Niels.

Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Niels:

0)    Your sender name is in an unusual format. It becomes just the 
generic NANOG address as the recipient for me to MSG send to.


1)   "  You have posted this statement like five times now in the past 
two days.   ":


    Perhaps so, I have been responding to numerous comments since my 
initial post in response to Karim Mekkaoui's inquiry. Since I have to 
address each individually, some from different angles, while some others 
are new discussions or debates, it is no surprise that the same 
expression has been used more than once to deal with them respectively. 
If you count this specific item on the sideline, you definitely will see 
the repeats. The important criterion here is whether any of them are out 
of the context? (To be honest with you, I myself feel that I have been 
playing broken records on this pretty simple and straightforward topic.)


2)   " Who is asking for this expansion of 100.64/10 (which you 
misspelled, by the way)?    ":


    Thanks for catching the typo. My understanding is that there is a 
general desire (human nature) to get a larger netblock than 100.64/10 in 
CG-NAT. This could be used for either growing market or less dynamic 
reassignment. The 240/4 can provide additional benefits to CG-NAT 
operations such as static addressing that no one has realized possible. 
So, I am putting the solution on the table. This is a basic process of 
sharing the new discoveries. Is there anything wrong with the process? 
On the other hand, if RFC6598 had picked 240/4 instead of 100.64/10 as 
the netblock, we do not need today's discussions.


Regards,

Abe (2024-01-13 12:14)


On 2024-01-12 07:34, Niels Bakker wrote:

* ayc...@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]:
    EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which 
is reusable for each isolated geographical area. Thus, there is no 
"Burn-rate" to talk about.


You have posted this statement like five times now in the past two days.

Who is asking for this expansion of 100.64/10 (which you misspelled, 
by the way)? Where are the claims that the amount of private space 
behind a CGNAT is the limiting factor in CGNAT deployments?


[five meters of superfluous quote history snipped]


-- Niels.




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

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Brett O'Hara]

Ok you've triggered me on your point 2.  I'll address the elephant in the
room.

IPv4 is never ever going away.

Right now consumer services are mostly (mobile, wireless, landline, wide
generalization) are IPv6 capable.  Most consumer applications are ipv6
capable, Google, Facebook, etc.There is light at the very end of the tunnel
that suggests that one day we won't have to deploy CGNAT444 for our
consumers to get to content, we may only have to do NAT64 for them to get
to the remaining Ipv4 Internet.  We're still working hard on removing our
reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a
long way off, but it's coming.

Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.
You might be able to get away with giving CGNAT to your consumers, but your
enterprise customer will not accept this. How will they terminate their
remote users?  How will they do B2B with out inbound NAT?  Yes, there are
solutions, but if you don't need to, why?  They pay good money, why can't
they have real ipv4?  All their internal networks are IPv4 rfc1918.  They
are happy with NAT.  Their application service providers are ipv4
only. Looking at the services I access for work things like SAP,
SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
more, none can not be accessed on ipv6 alone..  Their internal network
lifecycle is 10+ years.  They have no interest in trying new things or
making new technology work without a solid financial reason and there is
none for them implementing ipv6.   And guess where all the IP addresses
we're getting back from our consumers are going?  Straight to our good
margin enterprise customers and their application service providers.
Consumer CGNAT isn't solving problems, it's creating more.

The end of IPv4 isn't nigh, it's just privileged only.

PS When you solve that problem in 50 years time, I'll be one of those old
fogey's keeping an IPv4 service alive as an example of "the old Internet"
for those young whippersnappers to be amazed by.

Regards,
   Brett



On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) <
li...@packetflux.com> wrote:

> A couple of points:
>
> 1) There is less work needed to support IPv6 than your proposed solution.
> I'm not taking about 230/4.  I'm talking about your EzIP overlay.
>
> 2) Assume that Google decided that they would no longer support IPv4 for
> any of their services at a specific date a couple of years in the future.
> That is,  you either needed an IPv6 address or you couldn't reach Google,
> youtube, Gmail and the rest of the public services.  I bet that in this
> scenario every eyeball provider in the country all of a sudden would be
> extremely motivated to deploy IPv6, even if the IPv4 providers end up
> natting their IPv4 customers to IPv6.  I really expect something like this
> to be the next part of the end game for IPv4.
>
> Or stated differently: at some point someone with enough market power is
> going to basically say "enough is enough" and make the decision for the
> rest of us that IPv4 is effectively done on the public internet.   The
> large tech companies all have a history of sunsetting things when it
> becomes a bigger problem to support than it's worth.  Try getting a modern
> browser that works on 32 bit windows.   Same with encryption protocols,
> Java in the browser,  Shockwave and flash, and on and on.
>
> I see no reason why IPv4 should be any different.
>
> On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:
>
>> Hi, Forrest:
>>
>> 0)You put out more than one topic, all at one time. Allow me to
>> address each briefly.
>>
>> 1)   "  The existence of that CG-NAT box is a thorn in every provider's
>> side and every provider that has one wants to make it go away as quickly as
>> possible.   ":
>>
>> The feeling and desire are undeniable facts. However, the existing
>> configuration was evolved from various considerations through a long time.
>> There is a tremendous inertia accumulated on it. There is no magic bullet
>> to get rid of it quickly. We must study carefully to evolve it further
>> incrementally. Otherwise, an even bigger headache or disaster will happen.
>>
>> 2)"  The quickest and most straightforward way to eliminate the need
>> for any CG-NAT is to move to a bigger address space.  ":
>>
>> The obvious answer was IPv6. However, its performance after near two
>> decades of deployment has not been convincing. EzIP is an alternative,
>> requiring hardly any development, to address this need immediately.
>>
>> 3)   "  Until the cost (or pain) to stay on IPv4 is greater than the
>> cost to move,  we're going to see continued resistance to doing so.   ":
>>
>> This strategy is easily said than done. It reminds me of my system
>> planning work for the old AT At that time, Bell Operating Companies
>> (BOCs) could be coerced to upgrade their facility by just gradually raising
>> the cost of owning the old equipment by assuming fewer 

Re: Streamline the CG-NAT Re: 202401101433.AYC Re: EzIP Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Christopher:

Thanks for the confirmation.

Regards,


Abe (2024-01-13 11:42)


On 2024-01-12 07:30, Christopher Hawker wrote:
"Source NAT changes the source address in IP header of a packet. It 
may also change the source port in the TCP/UDP headers. The typical 
usage is to change the a private (rfc1918) address/port into a public 
address/port for packets leaving your network."


"Destination NAT changes the destination address in IP header of a 
packet. It may also change the destination port in the TCP/UDP 
headers.The typical usage of this is to redirect incoming packets with 
a destination of a public address/port to a private IP address/port 
inside your network."


Source: 
https://serverfault.com/questions/119365/what-is-the-difference-between-a-source-nat-destination-nat-and-masquerading


Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 23:17, Abraham Y. Chen  wrote:

Hi, Christopher:

1)   "  destination/source NAT  ":

    I am not sure about this terminology. Could you please
elaborate? If you are referring EzIP being a bigger CG-NAT, it is
exactly correct. That is, the first step of EzIP implementation is
just to give CG-NAT a larger netblock to work with, so that the
chore of dynamic address assignment to the client may be avoided.

Regards,

Abe (2024-01-12 07:16)



On 2024-01-11 22:46, Christopher Hawker wrote:

Not going to lie, EzIP just seems to be some version of
destination/source NAT on steroids.

Regards,
Christopher Hawker

On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen 
wrote:

Hi, Forrest:

0)    Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP
concept clearer. That is, one way to look at the EzIP scheme
is to substitute the current 100.64/10  netblock in the
CG-NAT with 240/4. Everything else in the current CG-NAT
setup stays unchanged. This makes each CG-NAT cluster 64 fold
bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)



On 2024-01-11 02:02, Forrest Christian (List Account) wrote:

I shouldn't probably go down this path... as I know this has
been discussed but I'm hoping that this might make a
difference.

Abraham,

Even if 240/4 is "fixed", your EzIP scheme will require some
sort of NAT box between the 240/4 addressed devices and the
non-EzIP internet.  That NAT box will have to remain in
place until such time as every single publically addressed
device on the public internet has been updated to support
EzIP.  In addition, protocols such as DNS, SIP, and others
which pass around addresses will need to be updated to be
able to pass the full EzIP addressing around so endpoints
can properly insert the EzIP header,  and so on.

The point I'm trying to make is that, at this point,
deploying EzIP as an end to end address exhaustion solution
has MORE challenges that simply deploying IPv6 would.  This
is because, just like EzIP, deploying IPv6 requires a NAT
box of some sort to be put in place until the last IPv4
device is turned off.   But unlike EzIP, almost every new
device coming out supports IPv6 out of the box.   All of the
technical standards work has already been done.  Thus, the
only meaningful barrier to IPv6 at this point is convincing
people to use it, not convincing people to use it PLUS
convincing the tech companies to support it,  and doing
protocol changes like you would with EzIP.

I applaud your attempt at a unique solution but I really
feel that ship has sailed, at least for an EzIP type of
solution. Maybe something like this would have better
received years ago, but at this point IPv6 is a much more
logical path forward.

I do wonder,  however,  if some of your concepts might be
able to be applied to the IPv6 transition.  I have some
ideas here,  but most, if not all, of them are only
partially cooked but some have similar approaches as EzIP
but with an actual IPv6 packet inside.







Virus-free.www.avast.com





<#m_7003280393758044796_m_-3759812132042785637_m_-2040759016673337921_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>








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

Re: IPv4 address block

[Christopher Hawker]

> at least in the ripe ncc service region, all this proved was that if the
> cost of registering a company (or LIR) and applying for an allocation
> was lower than the market rate of ipv4 addresses, then people would do
that.

Funny you say that, I had the same discussion with someone yesterday. It
wouldn't be hard from a PDP perspective to implement a policy that
prohibits companies from the same corporate group from applying for
allocations to ensure a fair distribution for new members, so for example
if two LLCs had the same owners/directors (forgive the terminology) both
LLCs could not both hold resources, it'd be one or the other.

Going back to allocation rates...

After looking at the APNIC Resource Explorer (https://rex.apnic.net/) since
policy "prop-127: Change maximum delegation size of 103/8 IPv4 address pool
to a /23" was implemented, there have been on average (the equivalent of)
1834 x /23 prefixes delegated per-year, from 09 May 2019 to 08 May 2024.
I've averaged the future delegation rates from 09 January to 08 May based
on the prior 8 months. Looking at the equivalent number of /23 prefixes in
3 x /8 prefixes, this calculates to quite a substantial 98,304 x /23
prefixes in 3 x /8 which would last ~50 years based on delegation rates in
the APNIC region. Even if we were to reserve 10% of that pool, that would
still give us a timeframe of about 48 years. Want to increase the maximum
delegation to a /22 and retrospectively apply it to those who could only
apply for a /23? Still gives us just under 22 years.

A substantial amount of time.

Regards,
Christopher Hawker

P.S. All the figures above are based on the 5 RIRs getting an equal
distribution of 3 x /8 prefixes. LACNIC and AFRINIC may (as an example)
only receive 1x or 2x /8 prefixes due to their service region sizes with
the balance distributed between ARIN, RIPE NCC and APNIC. This again, would
affect figures and is difficult to forecast.

On Sun, 14 Jan 2024 at 01:39, Nick Hilliard  wrote:

> Matthew Petach wrote on 13/01/2024 00:27:
> > In light of that, I strongly suspect that a second go-around at
> > developing more beneficial post-exhaustion policies might turn out
> > very differently than it did when many of us were naively thinking
> > we understood how people would behave in a post-exhaustion world.
>
> Naah, any future relitigation would end up the same if new ipv4
> addresses fell out of the sky and became available. The ipv4 address
> market turned out exactly like most people suspected: it was a market;
> people bought and sold addresses; the addresses cost money; there
> were/are some sharks; life moved on.
>
> > If you limit each requesting organization to a /22 per year, we can
> > keep the internet mostly functional for decades to come,
>
> at least in the ripe ncc service region, all this proved was that if the
> cost of registering a company (or LIR) and applying for an allocation
> was lower than the market rate of ipv4 addresses, then people would do
> that.
>
> The root problem is unavoidable: ipv4 is a scarce resource with an
> inherent demand. Every policy designed to mitigate against this will
> create workarounds, and the more valuable the resource, the more
> inventive the workaround.
>
> In terms of hard landings vs soft landings, what will make ipv6 succeed
> is how compelling ipv6 is, rather than whether someone created a policy
> to make ipv4 less palatable. In particular, any effect from a hard
> landing compared would have been ephemeral.
>
> Nick
>

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Tom Beecher]

Vint told you the same thing other people have been telling you for years.
You don't seem to name drop anyone else. Weird.

Respectfully, you have no credibility in this area. I happened to notice
this gem re-reading your draft last night,

A.1.1. T1a Initiates a Session Request towards T4a
>
>T1a sends a session request to SPR4 that serves T4a by a plain IP
>packet with header as in Figure 5, to RG1. There is no TCP port
>number in this IP header yet.
>
>
That's a curious statement there at the end. Let's continue though.

A.1.2. RG1 Forwards the Packet to SPR1
>
>  RG1, allowing be masqueraded by T1a, relays the packet toward SPR1
>by assigning the TCP Source port number, 3N, to T1a, with a header as
>in Figure 6,. Note that the suffix "N" denotes the actual TCP port
>number assigned by the RG1's RG-NAT. This could assume multiple
>values, each represents a separate communications session that T1a is
>engaged in. A corresponding entry is created in the RG1 state table
>for handling the reply packet from the Destination site. Since T4a's
>TCP port number is not known yet, it is filled with all 1's.
>
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  1 |Version|IHL (6)|Type of Service|   Total Length (24)   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  2 |Identification |Flags| Fragment Offset |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  3 | Time to Live  |Protocol   |Header Checksum|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  4 |  Source Host Number (240.0.0.0)   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  5 |   Destination Host Number (69.41.190.148) |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  6 |   Source Port (3N)|   Destination Port (All 1's)  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  Figure 6  TCP/IP Header: From RG1 to SPR1
>
>
Wait a second.. what is a 'TCP/IP header'?

A.1.5. T4a Replies to SPR4
>
>T4a interchanges the Source and Destination identifications in the
>incoming TCP/IP packet to create a header as in Figure 9, for the
>reply packet to SPR4.
>
> 0   1   2   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  1 |Version|IHL (6)|Type of Service|   Total Length (24)   |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  2 |Identification |Flags| Fragment Offset |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  3 | Time to Live  |Protocol   |Header Checksum|
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  4 |  Source Host Number (240.0.0.10)  |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  5 |   Destination Host Number (69.41.190.110) |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  6 |  Source Port (10C)| Destination Port (0C) |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  Figure 9  TCP/IP Header: From T4a to SPR4
>
>
Oh my.. you actually meant it.

The draft authors don't appear to understand that TCP headers and IP
headers **are not the same thing**.

I would suggest reviewing RFC 791 ( IPv4 ) , and RFC 793 / 9293 ( TCP,
original and updated ).


On Sat, Jan 13, 2024 at 7:35 AM Abraham Y. Chen  wrote:

> Hi, Tom:
>
> 1)" ...  Implying that Vint Cerf ever said anything about EzIP ...
> ":
>
> FYI - Please see the below copy of a partial eMail thread. Bold, red
> colored and Italicized letters are to focus on the topic.
>
> ***
>
> internetpol...@elist.isoc.org  eMail thread
>
>  On 2021-10-18 16:34, Abraham Y. Chen wrote:
>
> Dear Vint:
>
>  Yes, this is one perspective for visualizing the EzIP proposal.
>
> Thanks,
>
>  Abe (2021-10-18 16:33 EDT)
>
>  Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation
>
>  On 2021-10-18 10:39, *vinton cerf* wrote:
>
> sounds like *eZIP* is basically an *overlay* network.
>
>  *v*
>
>  On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy <
> internetpol...@elists.isoc.org> wrote:
>
> Hi, Scott:
>
>  0)Thanks for your research.
>
>  1)Both SCION (based on my best understanding) and our work named EzIP
> (phonetic for 

Re: IPv4 address block

[Nick Hilliard]

Matthew Petach wrote on 13/01/2024 00:27:
In light of that, I strongly suspect that a second go-around at 
developing more beneficial post-exhaustion policies might turn out 
very differently than it did when many of us were naively thinking

we understood how people would behave in a post-exhaustion world.


Naah, any future relitigation would end up the same if new ipv4 
addresses fell out of the sky and became available. The ipv4 address 
market turned out exactly like most people suspected: it was a market; 
people bought and sold addresses; the addresses cost money; there 
were/are some sharks; life moved on.


If you limit each requesting organization to a /22 per year, we can 
keep the internet mostly functional for decades to come,


at least in the ripe ncc service region, all this proved was that if the 
cost of registering a company (or LIR) and applying for an allocation 
was lower than the market rate of ipv4 addresses, then people would do that.


The root problem is unavoidable: ipv4 is a scarce resource with an 
inherent demand. Every policy designed to mitigate against this will 
create workarounds, and the more valuable the resource, the more 
inventive the workaround.


In terms of hard landings vs soft landings, what will make ipv6 succeed 
is how compelling ipv6 is, rather than whether someone created a policy 
to make ipv4 less palatable. In particular, any effect from a hard 
landing compared would have been ephemeral.


Nick

Re: Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Christopher Hawker]

Implementing EzIP, as Forrest mentioned 3 days ago, has far more challenges
than implementing IPv6. It will also cause far more incompatibilities when
it comes to routing traffic between a network which has implemented it and
one that hasn't. It also sounds like another version of NAT, non-routable
addresses behind a box which allows other networks to access it via a
gateway. The implementation of IPv6 can be done within weeks for smaller
organisations and networks and in less than a year for larger
organisations, and the best part is that virtually every hardware vendor
already supports it. The majority of our problems can be solved by using
existing protocols, in my view we don't need another. If anything it only
detracts from what we should be working towards.

Further, over the last three days you've changed the subject line of the
thread at least 12 times. Can you please stop changing it because every
time you do, it starts a new thread and makes it rather difficult to keep
track of the discussion. I also don't believe I'm the first one to raise
this either.

https://i.imgur.com/7WIzwEP.png

Regards,
Christopher Hawker

On Sat, 13 Jan 2024 at 23:35, Abraham Y. Chen  wrote:

> Hi, Tom:
>
> 1)" ...  Implying that Vint Cerf ever said anything about EzIP ...
> ":
>
> FYI - Please see the below copy of a partial eMail thread. Bold, red
> colored and Italicized letters are to focus on the topic.
>
> ***
>
> internetpol...@elist.isoc.org  eMail thread
>
>  On 2021-10-18 16:34, Abraham Y. Chen wrote:
>
> Dear Vint:
>
>  Yes, this is one perspective for visualizing the EzIP proposal.
>
> Thanks,
>
>  Abe (2021-10-18 16:33 EDT)
>
>  Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation
>
>  On 2021-10-18 10:39, *vinton cerf* wrote:
>
> sounds like *eZIP* is basically an *overlay* network.
>
>  *v*
>
>  On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy <
> internetpol...@elists.isoc.org> wrote:
>
> Hi, Scott:
>
>  0)Thanks for your research.
>
>  1)Both SCION (based on my best understanding) and our work named EzIP
> (phonetic for Easy IPv4) are technical solutions for improving the Internet
> from its foundation level (the architecture). There are many implications
> with such schemes including social and legal if one looks into them.
>
>  2)As I responded to Gene's questions (See my eMail with subject line
> tag: "202110171756.AYC"), the SCION approach implements certain
> restrictions ..
>
> 
>
> 2)Prior to the above, we were quite unsure about what our team was
> doing. So, I purposely avoided having any contact with Vint. We had been
> describing the EzIP's RANs (Regional Area Networks) as "kites floating in
> the air over an geographic area anchored by an IPv4 address based cord".
> Although visually clear, it was too wordy. By using one concise word,
> *overlay*, Vint eloquently classified the EzIP network in terminology
> sense. It opened our eyes about what were the implications of EzIP and what
> could be the interactions with respect to the existing Internet, because
> EzIP was a non-interfering enhancement to an existing system which was a
> text book case of systems engineering.
>
> Hope the above clears the air.
>
>
> Regards,
>
>
> Abe (2024-01-13 07:34)
>
>
> On 2024-01-12 19:24, Tom Beecher wrote:
>
> I go into my cave to finish the todo list for the week, and I come out to
> see Mr. Chen :
> - Telling Randy Bush he should "read some history" on IPv6
> - Implying that Vint Cerf ever said anything about EzIP
>
> Fairly impressive sequence of self ownage.
>
> On Fri, Jan 12, 2024 at 5:46 PM Randy Bush  wrote:
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_-4880440387061228082_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Brandon Butterworth]

On 13/01/2024, 08:40:11, "Giorgio Bonfiglio via NANOG"  
wrote:

 2) Assume that Google decided that they would no longer support IPv4 for any 
of their services at a specific date a couple of years in the future. […] I 
really expect something like this to be the next part of the end game for IPv4.


It’s never gonna happen … why would Google, or any other internet property, 
launch something which artificially cuts the potential revenue pool to 
IPv6-ready customers?


A step before that might not cost anything: add IPv6 search ranking 
boost

and see how fast the SEO hawkers push all content to v6, then it's just
down to those with cgnat realising they can save money by moving to IPv6 
too.


brandon

Vint Cerf Re: Backward Compatibility Re: IPv4 address block

[Abraham Y. Chen]

Hi, Tom:

1)    " ...  Implying that Vint Cerf ever said anything about EzIP 
... ":


    FYI - Please see the below copy of a partial eMail thread. Bold, 
red colored and Italicized letters are to focus on the topic.


***

internetpol...@elist.isoc.orgeMail thread

On 2021-10-18 16:34, Abraham Y. Chen wrote:

Dear Vint:

Yes, this is one perspective for visualizing the EzIP proposal.

Thanks,

Abe (2021-10-18 16:33 EDT)

 Re: [Internet Policy] 202110180800.AYC Re: Platform self-regulation

 On 2021-10-18 10:39, */vinton cerf/* wrote:

sounds like /*eZIP*/is basically an */overlay/*network.

/*v*/

On Mon, Oct 18, 2021 at 8:33 AM Abraham Y. Chen via InternetPolicy 
 wrote:


Hi, Scott:

 0)    Thanks for your research.

 1)    Both SCION (based on my best understanding) and our work named 
EzIP (phonetic for Easy IPv4) are technical solutions for improving the 
Internet from its foundation level (the architecture). There are many 
implications with such schemes including social and legal if one looks 
into them.


 2)    As I responded to Gene's questions (See my eMail with subject 
line tag: "202110171756.AYC"), the SCION approach implements certain 
restrictions ..




2)    Prior to the above, we were quite unsure about what our team was 
doing. So, I purposely avoided having any contact with Vint. We had been 
describing the EzIP's RANs (Regional Area Networks) as "kites floating 
in the air over an geographic area anchored by an IPv4 address based 
cord". Although visually clear, it was too wordy. By using one concise 
word, */overlay/*, Vint eloquently classified the EzIP network in 
terminology sense. It opened our eyes about what were the implications 
of EzIP and what could be the interactions with respect to the existing 
Internet, because EzIP was a non-interfering enhancement to an existing 
system which was a text book case of systems engineering.


Hope the above clears the air.


Regards,


Abe (2024-01-13 07:34)


On 2024-01-12 19:24, Tom Beecher wrote:

I go into my cave to finish the todo list for the week, and I come out 
to see Mr. Chen :

- Telling Randy Bush he should "read some history" on IPv6
- Implying that Vint Cerf ever said anything about EzIP

Fairly impressive sequence of self ownage.

On Fri, Jan 12, 2024 at 5:46 PM Randy Bush  wrote:




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

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Forrest Christian (List Account)]

Let me start with I think we're largely on the same page here.

The transition I see happening next is that the consumer traffic largely
moves to IPv6 with no CG-NAT.  That is, if you're at home or on your phone
watching video or doing social media or using whatever app is all the rage
it's going to be over IPv6.

My point was largely that I believe that at some point the big consumer
(not business) focused companies are going to realize they can use market
forces to encourage the remaining IPv4-only eyeball networks to transition
to support IPv6 connections from their customers.  I don't know if the
timeframe is next year or 20 years from now,  but I do know the tech
companies are very good at looking at the costs of maintaining backwards
compatibility with old tech and figuring out ways to shed those costs when
they no longer make sense.  If they can utilize various forms of pressure
to make this happen quicker, I fully expect them to do so.

Inside a business network,  or even at home,  it wouldn't surprise me if
we're both long gone before IPv4 is eradicated.   I know there is going to
be a lot of IPv4 in my network for years to come just because of product
lifecycles.

As far as "CG-NAT-like" technologies go (meaning NAT in a provider's
network), they're unfortunately going to be with us for a long time since
customers seem to want to be able to reach everything regardless of the
IPv4 or IPv6 status of the customer or endpoint.   I also expect that most
service providers with business customers are going to be carrying both
IPv4 and IPv6 for a long time, not to mention doing a fair bit of
translation in both directions.

I won't go deeply into the whole IPv4 vs IPv6 discussion for a business
customer's "public address" because the topic is far too nuanced for an
email to cover them accurately.   Suffice it to say that I don't disagree
that business today largely wants IPv4, but some seem to be becoming aware
of what IPv6 can do and are looking to have both options available to them,
at least outside the firewall.

On Sat, Jan 13, 2024, 2:04 AM Brett O'Hara  wrote:

> Ok you've triggered me on your point 2.  I'll address the elephant in the
> room.
>
> IPv4 is never ever going away.
>
> Right now consumer services are mostly (mobile, wireless, landline, wide
> generalization) are IPv6 capable.  Most consumer applications are ipv6
> capable, Google, Facebook, etc.There is light at the very end of the tunnel
> that suggests that one day we won't have to deploy CGNAT444 for our
> consumers to get to content, we may only have to do NAT64 for them to get
> to the remaining Ipv4 Internet.  We're still working hard on removing our
> reliance on genuine ipv4 ranges to satisfy our customer needs, It's still a
> long way off, but it's coming.
>
> Here's the current problem.  Enterprise doesn't need ipv6 or want ipv6.
> You might be able to get away with giving CGNAT to your consumers, but your
> enterprise customer will not accept this. How will they terminate their
> remote users?  How will they do B2B with out inbound NAT?  Yes, there are
> solutions, but if you don't need to, why?  They pay good money, why can't
> they have real ipv4?  All their internal networks are IPv4 rfc1918.  They
> are happy with NAT.  Their application service providers are ipv4
> only. Looking at the services I access for work things like SAP,
> SerivceNow, Office386, Sharepoint, Okta, Dayforce, Xero, and I'm sure many
> more, none can not be accessed on ipv6 alone..  Their internal network
> lifecycle is 10+ years.  They have no interest in trying new things or
> making new technology work without a solid financial reason and there is
> none for them implementing ipv6.   And guess where all the IP addresses
> we're getting back from our consumers are going?  Straight to our good
> margin enterprise customers and their application service providers.
> Consumer CGNAT isn't solving problems, it's creating more.
>
> The end of IPv4 isn't nigh, it's just privileged only.
>
> PS When you solve that problem in 50 years time, I'll be one of those old
> fogey's keeping an IPv4 service alive as an example of "the old Internet"
> for those young whippersnappers to be amazed by.
>
> Regards,
>Brett
>
>
>
> On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
>
>> A couple of points:
>>
>> 1) There is less work needed to support IPv6 than your proposed
>> solution.  I'm not taking about 230/4.  I'm talking about your EzIP
>> overlay.
>>
>> 2) Assume that Google decided that they would no longer support IPv4 for
>> any of their services at a specific date a couple of years in the future.
>> That is,  you either needed an IPv6 address or you couldn't reach Google,
>> youtube, Gmail and the rest of the public services.  I bet that in this
>> scenario every eyeball provider in the country all of a sudden would be
>> extremely motivated to deploy IPv6, even if the IPv4 providers end up
>> natting 

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Giorgio Bonfiglio via NANOG]

> 2) Assume that Google decided that they would no longer support IPv4 for any 
> of their services at a specific date a couple of years in the future. […] I 
> really expect something like this to be the next part of the end game for 
> IPv4.

It’s never gonna happen … why would Google, or any other internet property, 
launch something which artificially cuts the potential revenue pool to 
IPv6-ready customers?

I’m with you it would be amazing and a strong driver, but it’s just not in the 
realm of possibility…

Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: IPv4 address block

[Forrest Christian (List Account)]

A couple of points:

1) There is less work needed to support IPv6 than your proposed solution.
I'm not taking about 230/4.  I'm talking about your EzIP overlay.

2) Assume that Google decided that they would no longer support IPv4 for
any of their services at a specific date a couple of years in the future.
That is,  you either needed an IPv6 address or you couldn't reach Google,
youtube, Gmail and the rest of the public services.  I bet that in this
scenario every eyeball provider in the country all of a sudden would be
extremely motivated to deploy IPv6, even if the IPv4 providers end up
natting their IPv4 customers to IPv6.  I really expect something like this
to be the next part of the end game for IPv4.

Or stated differently: at some point someone with enough market power is
going to basically say "enough is enough" and make the decision for the
rest of us that IPv4 is effectively done on the public internet.   The
large tech companies all have a history of sunsetting things when it
becomes a bigger problem to support than it's worth.  Try getting a modern
browser that works on 32 bit windows.   Same with encryption protocols,
Java in the browser,  Shockwave and flash, and on and on.

I see no reason why IPv4 should be any different.

On Fri, Jan 12, 2024, 3:42 PM Abraham Y. Chen  wrote:

> Hi, Forrest:
>
> 0)You put out more than one topic, all at one time. Allow me to
> address each briefly.
>
> 1)   "  The existence of that CG-NAT box is a thorn in every provider's
> side and every provider that has one wants to make it go away as quickly as
> possible.   ":
>
> The feeling and desire are undeniable facts. However, the existing
> configuration was evolved from various considerations through a long time.
> There is a tremendous inertia accumulated on it. There is no magic bullet
> to get rid of it quickly. We must study carefully to evolve it further
> incrementally. Otherwise, an even bigger headache or disaster will happen.
>
> 2)"  The quickest and most straightforward way to eliminate the need
> for any CG-NAT is to move to a bigger address space.  ":
>
> The obvious answer was IPv6. However, its performance after near two
> decades of deployment has not been convincing. EzIP is an alternative,
> requiring hardly any development, to address this need immediately.
>
> 3)   "  Until the cost (or pain) to stay on IPv4 is greater than the cost
> to move,  we're going to see continued resistance to doing so.   ":
>
> This strategy is easily said than done. It reminds me of my system
> planning work for the old AT At that time, Bell Operating Companies
> (BOCs) could be coerced to upgrade their facility by just gradually raising
> the cost of owning the old equipment by assuming fewer would be be used,
> while the newer version would cost less because growing number of
> deployments. Looking at resultant financial forecast, the BOC decisions
> were easy. Originally trained as a hardware radio engineer, I was totally
> stunned. But, it worked well under the regulated monopoly environment.
>
> Fast forward by half a century, the Internet promotes distributed
> approaches. Few things can be controlled by limited couple parties. The
> decision of go or no-go is made by parties in the field who have their own
> respective considerations. Accumulated, they set the direction of the
> Internet. In this case, IPv6 has had the opportunity of over four decades
> of planning and nearly two decades of deployment. Its future growth rate is
> set by its own performance merits. No one can force its rate by persuasion
> tactic of any kind. Hoping so is wishful thinking which contributes to
> wasteful activities. So, we need realistic planning.
> Regards,
>
>
> Abe (2024-01-12 18:42)
>
>
>
> On 2024-01-12 01:34, Forrest Christian (List Account) wrote:
>
> The problem isn't the quantity of "inside" CG-NAT address space.  It's the
> existence of CG-NAT at all.
>
> It doesn't matter if the available space is a /12 or a /4, you still need
> something to translate it to the public internet.   The existence of that
> CG-NAT box is a thorn in every provider's side and every provider that has
> one wants to make it go away as quickly as possible.
>
> The quickest and most straightforward way to eliminate the need for any
> CG-NAT is to move to a bigger address space.  As I pointed out, IPv6 is
> already ready and proven to work so moving to IPv6 is a straightforward
> process technically.  What isn't straightforward is convincing IPv4 users
> to move.  Until the cost (or pain) to stay on IPv4 is greater than the cost
> to move,  we're going to see continued resistance to doing so.
>
>
> On Thu, Jan 11, 2024, 7:36 PM Abraham Y. Chen  wrote:
>
>> Hi, Forrest:
>>
>> 0)Thanks for your in-depth analysis.
>>
>> 1) However, my apologies for not presenting the EzIP concept clearer.
>> That is, one way to look at the EzIP scheme is to substitute the current
>> 100.64/10  netblock in the CG-NAT with