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

[Jay R. Ashworth]

- Original Message -
> From: "William Herrin" 

> 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.

Maybe it's not.

Looking at threads in NANOGs piper, though, it's easy to see threads where
the Subject line evolves to follow the conversation, without dropping people
who still want to participate in it.

The fact that the "(was: old subject)" convention continues in good service
to this day, *even though no mailer does that for you* (so far as I'm aware)
suggests that people will put in the effort, to me at least.

The number of times when I've consciously wanted to break a reply chain -- and
usually was not provided with the facility by my mailer -- is much smaller than
the number when I wanted it to continue.  The only mailer I remember being able
to do it in, really, is mutt, where you could get all the headers into vi, and
delete In-Reply-To:.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

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

[Jay R. Ashworth]

- Original Message -
> From: "Abraham Y. Chen" 

> Hi, Bryan:

[ ... ]

> 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?

Well, when Bryan says:
>> 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.

he's not wrong... but he fails to take into account that there are still
email clients which don't thread based on *that*, as they should; they
make up cock-a-mamie rules about the contents of the Subject line, and 
use those to thread with, and those clients *will* come apart if you make
'gratuitous' edits to it.

Well, at least, this *has been* a running problem for 20 or 30 years; I don't
have my fingers on a list of which clients get it right and which wrong, and
which might have gotten religion over the years on the topic.  5322 isn't my
primary RFC.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

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

[Christopher Hawker]

Bryan:

> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.

Actually, no it's not. RFC5322 reads: "This specification is not intended
to dictate ... any of the characteristics of user interface programs that
create or read messages".

5822 has not been issued, see https://www.rfc-editor.org/info/rfc5822.

Abraham:

> For more than one year, I have been accused of breaking the eMail
etiquette established by a standard, yet identified.

If multiple people have been asking you for over a year to not change
subject headings on emails, does this not indicate a bigger issue regarding
your mailing list etiquette? The fact that it continues indicates a
complete disregard. I cannot think of one technical reason to include a
manual timestamp in a subject line (such as your 202401102221.AYC).

> If we have trouble to keep our communication tool's framework solid, we
will be spending needless extra resources on technical discussions. This is
not productive.

One person changing the subject line of a mailing list thread every few
emails for their own benefit, and no one else, is not productive. There is
nothing wrong with MUAs currently in use. A user adapts to the MUA, not the
other way around.

> Obviously, I am just barely able to read the exchanges on this thread due
to so many terminologies that I have never heard of.

If a number of people on a mailing list were using terminologies that I
didn't understand, I would:
1. Listen to and understand what they are saying.
2. Contact them off-list and ask for clarification.
3. Heed their advice.

Regards,
Christopher Hawker

On Mon, 15 Jan 2024 at 00:12, Abraham Y. Chen  wrote:

> Hi, Bryan:
>
> 1)"  ...  Gmail is therefore in violation of the RFC5822. ...  I
> think it's quite unreasonable to expect others to compensate for an MUA which
> doesn't implement 25+ year old standards properly. ...  ":
>
> I am so glad that you decided to come out to be a well-informed
> referee. For more than one year, I have been accused of breaking the eMail
> etiquette established by a standard, yet never identified. It seriously
> distracted our attention from the topic of essence. You now have
> demonstrated that the reverse appears to be the case. What a big surprise!
>
> 2)If we have trouble to keep our communication tool's framework solid,
> we will be spending needless extra resources on technical discussions. This
> is not productive.
>
> 3)Obviously, I am just barely able to read the exchanges on this
> thread due to so many terminologies that I have never heard of. I shall
> remain silent on this thread from now on, awaiting for you to lead us out
> of this puzzlement.
>
> Sincerely and Best Regards,
>
>
> Abe (2024-01-14 08:11 EST)
>
>
>
> On 2024-01-14 03:53, Bryan Fields wrote:
>
> On 1/14/24 1:01 AM, William Herrin wrote:
>
> Respectfully, your MUA is not the only MUA. Others work differently.
>
> Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
> zimbra web interface.  All follow and implement RFC5822 as it pertains to
> threading.
>
> Note, threading works fine in the list archives too, but only displays two
> levels deep.
>
>
> 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.
>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>
>
> 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.
>
> I think it's quite unreasonable to expect others to compensate for an MUA
> which doesn't implement 25+ year old standards properly.
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_4325909844379148972_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

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

[Tom Beecher]

>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>

Well, no. Asterisks added for emphasis.

 This specification is intended as a definition of what message
>content format is to be passed between systems.  Though some message
>systems locally store messages in this format (which eliminates the
>need for translation between formats) and others use formats that
>differ from the one specified in this specification, local storage is
>outside of the scope of this specification.
>
>   Note: This specification is not intended to dictate the internal
>   formats used by sites, the specific message system features that
>   they are expected to support, *** or any of the characteristics of
>   user interface programs that create or read messages. ***  In
>   addition, this document does not specify an encoding of the
>   characters for either transport or storage; that is, it does not
>   specify the number of bits used or how those bits are specifically
>   transferred over the wire or stored on disk.
>
> 5822 defines the structure and syntax of the data. Not how mail agents
should work with it.



On Sun, Jan 14, 2024 at 3:55 AM Bryan Fields  wrote:

> On 1/14/24 1:01 AM, William Herrin wrote:
> > Respectfully, your MUA is not the only MUA. Others work differently.
>
> Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even
> the
> zimbra web interface.  All follow and implement RFC5822 as it pertains to
> threading.
>
> Note, threading works fine in the list archives too, but only displays two
> levels deep.
>
> > 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.
>
> Gmail is therefore in violation of the RFC5822.  It's quite clear how it
> should work per the RFC appendix.
>
> > 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.
>
> I think it's quite unreasonable to expect others to compensate for an MUA
> which doesn't implement 25+ year old standards properly.
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

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

[James R Cutler]

On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields mailto:br...@bryanfields.net>> 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.

Bryan,

My personal use of email agents involves ordering incoming messages by date 
sent. Many others order their inbox by date received. I don't use MUA ordering 
by thread or conversation because I must use MUAs on many diverse systems. So 
for many decades, I have continued to use my own mental programming to sort and 
group messages by subject. This, by the way, is akin to aural conversations 
between persons where announcing a change of subject is expected to be followed 
by a new topic.

For those of us on OCD, ADD, or Autism spectrums, multiple subjects lines cause 
cognitive dissonance - sometimes damaging comprehension of the continuing 
thread (conversation). I don't claim it violates the ADA, but it should 
especially when willfully continued after requests for amended behavior. 
Lazarus Long would probably express this more cogently.

In the interest of polite conversation,
-
James R. Cutler
james.cut...@consultant.com

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

[Giorgio Bonfiglio via NANOG]

> I am so glad that you decided to come out to be a well-informed referee. 
> For more than one year, I have been accused of breaking the eMail etiquette 
> established by a standard, yet never identified. It seriously distracted our 
> attention from the topic of essence. You now have demonstrated that the 
> reverse appears to be the case. What a big surprise! 

Even if it doesn’t break the threading RFCs, I am at a loss looking for a 
reason why the subject line of a thread should be a/ arbitrarily changed 
without a correlated change in subject, b/ extended to a point where it takes 
1/3rd of the screen of my iPhone and doesn’t fit in the table view in my 
Thunderbird and c/ in a list with thousands of individuals be changed to 
include some sort of timestamp specific to one of them (202401102221.AYC).

Please, think at scale. If every single one of us had to randomly change 
subject at every response or add their own timestamp (why even?) 
202401151356.BG this would quickly get out of hand.

I don’t think we need to be in specific breach of an RFC to ask an individual 
which is clearly acting off the standard ML practice to please stop, no?

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:

1)    "  ...  Gmail is therefore in violation of the RFC5822. ... I 
think it's quite unreasonable to expect others to compensate for an MUA 
which doesn't implement 25+ year old standards properly. ...  ":


    I am so glad that you decided to come out to be a well-informed 
referee. For more than one year, I have been accused of breaking the 
eMail etiquette established by a standard, yet never identified. It 
seriously distracted our attention from the topic of essence. You now 
have demonstrated that the reverse appears to be the case. What a big 
surprise!


2)    If we have trouble to keep our communication tool's framework 
solid, we will be spending needless extra resources on technical 
discussions. This is not productive.


3)    Obviously, I am just barely able to read the exchanges on this 
thread due to so many terminologies that I have never heard of. I shall 
remain silent on this thread from now on, awaiting for you to lead us 
out of this puzzlement.


Sincerely and Best Regards,


Abe (2024-01-14 08:11 EST)



On 2024-01-14 03:53, Bryan Fields wrote:

On 1/14/24 1:01 AM, William Herrin wrote:

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

Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
zimbra web interface.  All follow and implement RFC5822 as it pertains to
threading.

Note, threading works fine in the list archives too, but only displays two
levels deep.


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.

Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.


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.

I think it's quite unreasonable to expect others to compensate for an MUA
which doesn't implement 25+ year old standards properly.




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

Re: 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/14/24 1:01 AM, William Herrin wrote:
> Respectfully, your MUA is not the only MUA. Others work differently.

Bill, I use multiple MUA's, among them Thunderbird, mutt, kmail and even the
zimbra web interface.  All follow and implement RFC5822 as it pertains to
threading.

Note, threading works fine in the list archives too, but only displays two
levels deep.

> 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.

Gmail is therefore in violation of the RFC5822.  It's quite clear how it
should work per the RFC appendix.

> 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.

I think it's quite unreasonable to expect others to compensate for an MUA
which doesn't implement 25+ year old standards properly.
-- 
Bryan Fields

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

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: 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: 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

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: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Mu]

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.
On Friday, January 12th, 2024 at 2:55 PM, Abraham Y. Chen  
wrote:

> Hi, Tony:
>
> 0) As the saying goes, there is more than one way to skin a cat. We do not 
> need to address a request by literally following the thought trend. In 
> troubleshooting, engineers are taught to look for the Root-Cause which more 
> than often turns out to be something else originally thought. In this case, 
> the "Any idea" hints that requester is open-minded for possible alternatives 
> other than stated on the surface.
>
> 1) When reviewing a problem, we need to go one or more steps toward the 
> source or the origin to look for the solution. Since the predominant 
> operation model is CDN supported by CG-NAT, the primary reason to look for a 
> publicly routable IPv4 address is to create another CG-NAT cluster. On the 
> other hand, if there is a way to expand the capacity of the existing CG-NAT 
> cluster, the need for additional publicly routable IPv4 address is reduced.
>
> Regards,
>
> Abe (2024-01-12 14:54)
>
> On 2024-01-10 23:26, Tony Wicks wrote:
>
>> 2) "... an operator clearly looking to acquire *publicly routable* space 
>> without being clear that this suggestion wouldn't meet their needs. ":
>>
>> Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current CG-NAT 
>> cluster can be expanded 64 fold once the 240/4 is used. Looking from another 
>> angle, an IAP will then be able to expand the subscriber set 64 fold with 
>> still the original one publicly routable IPv4 address.
>>
>> The OP asked for “Any idea please on the best way to buy IPv4 blocs and what 
>> is the price”. I would expect they want actual public IPv4 address blocks 
>> and not internal CGNAT space. While the idea of using 240/4 instead of 
>> 100.64/10 would certainly have some merit I don’t believe its in any way 
>> related to what this OP asked for.
>>
>> regards
>
> https://www.avast.com/sig-email   
> Virus-free.[www.avast.com](https://www.avast.com/sig-email)#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2

Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Tony:

0)    As the saying goes, there is more than one way to skin a cat. We 
do not need to address a request by literally following the thought 
trend. In troubleshooting, engineers are taught to look for the 
Root-Cause which more than often turns out to be something else 
originally thought. In this case, the "Any idea" hints that requester is 
open-minded for possible alternatives other than stated on the surface.


1)    When reviewing a problem, we need to go one or more steps toward 
the source or the origin to look for the solution. Since the predominant 
operation model is CDN supported by CG-NAT, the primary reason to look 
for a publicly routable IPv4 address is to create another CG-NAT 
cluster. On the other hand, if there is a way to expand the capacity of 
the existing CG-NAT cluster, the need for additional publicly routable 
IPv4 address is reduced.


Regards,


Abe (2024-01-12 14:54)



On 2024-01-10 23:26, Tony Wicks wrote:


2)    "... an operator clearly looking to acquire *publicly routable* 
space without being clear that this suggestion wouldn't meet their 
needs.  ":


    Since 240/4 has 256M addresses while 100.64/10 has only 4M, a 
current CG-NAT cluster can be expanded 64 fold once the 240/4 is used. 
Looking from another angle, an IAP will then be able to expand the 
subscriber set 64 fold with still the original one publicly routable 
IPv4 address.


The OP asked for “Any idea please on the best way to buy IPv4 blocs 
and what is the price”. I would expect they want actual public IPv4 
address blocks and not internal CGNAT space. While the idea of using 
240/4 instead of 100.64/10 would certainly have some merit I don’t 
believe its in any way related to what this OP asked for.


regards




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

Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Tom Beecher]

>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities.


No, it is not.

The original question from Karim was about acquiring some IPv4 space. We
can absolutely infer he wanted that space to be publically routable *today*.

The facts are that *today* :

1. 240/4 is not space that will provide expected internet connectivity
2. There are no plans or timelines in place that would change #1.

You stated to Karim that there was a way he could get IPs for free , and
implied if he reached out to you off list , you could help him make it
work. That was intentionally misleading, and frankly doesn't reflect very
well on you at all.


On Wed, Jan 10, 2024 at 11:09 PM Abraham Y. Chen  wrote:

> Hi, Tom:
>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities. Since this
> is rather philosophical, it can distract us from the essence unless we
> carry on a lengthy debate. Instead, I would like to address below only one
> aspect that you brought up.
>
> 2)"... an operator clearly looking to acquire *publicly routable*
> space without being clear that this suggestion wouldn't meet their needs.
> ":
>
> Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current
> CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from
> another angle, an IAP will then be able to expand the subscriber set 64
> fold with still the original one publicly routable IPv4 address.
>
> 3)This 64 fold scaling factor is critical because it allows one CG-NAT
> cluster to serve a geographical area that becomes sufficient to cover a
> significant political territory. For example, if we assign two 240/4
> addresses to each subscriber, one for stationary applications, one for
> mobile devices. And, each 240/4 address can be expanded by RFC1918
> netblocks (total about 17.6M each). Each CG-NAT can now serve a country
> with population up to 128M. It turns out that population of over 90+ % of
> countries are fewer than this. So, each of them needs only one publicly
> routable IPv4 address. Then, the demand for IPv4 address is drastically
> reduced.
>
> 4)In brief, the 240/4 is to substitute that of 100.64/10. So that the
> need for the publicly routable IPv4 addresses is significantly reduced.
>
> Regards,
>
>
> Abe (2024-01-10 23:08 EST)
>
>
> On 2024-01-10 10:12, Tom Beecher wrote:
>
> Karim-
>
> Please be cautious about this advice, and understand the full context.
>
> 240/4 is still classified as RESERVED space. While you would certainly be
> able to use it on internal networks if your equipment supports it, you
> cannot use it as publicly routable space. There have been many proposals
> over the years to reclassify 240/4, but that has not happened, and is
> unlikely to at any point in the foreseeable future.
>
> Mr. Chen-
>
> I understand your perspective surrounding 240/4, and respect your
> position, even though I disagree. That being said, it's pretty dirty pool
> to toss this idea to an operator clearly looking to acquire *publicaly
> routable* space without being clear that this suggestion wouldn't meet
> their needs.
>
> ( Unless people are transferring RFC1918 space these days, in which case
> who wants to make me an offer for 10/8? )
>
> On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
> wrote:
>
>> Interesting and thank you for sharing.
>>
>>
>>
>> KARIM
>>
>>
>>
>> *From:* Abraham Y. Chen 
>> *Sent:* January 10, 2024 7:35 AM
>> *To:* KARIM MEKKAOUI 
>> *Cc:* nanog@nanog.org; Chen, Abraham Y. 
>> *Subject:* 202401100645.AYC Re: IPv4 address block
>> *Importance:* High
>>
>>
>>
>> Hi, Karim:
>>
>>
>>
>> 1)If you have control of your own equipment (I presume that your
>> business includes IAP - Internet Access Provider, since you are asking to
>> buy IPv4 blocks.), you can get a large block of reserved IPv4 address *for
>> free* by *disabling* the program codes in your current facility that has
>> been *disabling* the use of 240/4 netblock. Please have a look at the
>> below whitepaper. Utilized according to the outlined disciplines, this is a
>> practically unlimited resources. It has been known that multi-national
>> conglomerates have been using it without announcement. So, you can do so
>> stealthily according to the proposed mechanism which establishes uniform
>> practices, just as well.
>>
>>
>>
>> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>>
>>
>>
>> 2)Being an unorthodox solution, if not controversial, please follow
>> up with me offline. Unless, other NANOGers express their interests.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>>
>>
>> Abe (2024-01-10 07:34 EST)
>>
>>
>>
>>
>>
>>
>>
>> On 2024-01-07 22:46, KARIM MEKKAOUI wrote:
>>
>> Hi Nanog Community
>>
>>
>>
>> Any idea 

Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Ryan Hamel]

Abraham,

There is no need to run one giant cluster. Many small clusters with VRFs and 
CG-NAT devices to bridge the gap from the VRF to the Internet and keep the 
blast radius small, are enough. A CG-NAT ISP should not need to work so hard to 
provide a unique enough CG-NAT IP address, as long as they can match a MAC 
address of the customer router + MAC address of the carrier equipment, to the 
DHCP and flow logs.

As along as the carrier implements IPv6, it will cut down on the active NAT 
sessions and port forwards the equipment needs to process.

Ryan Hamel


From: NANOG  on behalf of Abraham Y. 
Chen 
Sent: Wednesday, January 10, 2024 8:09 PM
To: Tom Beecher 
Cc: Chen, Abraham Y. ; nanog@nanog.org 
Subject: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: 
IPv4 address block

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.

Hi, Tom:

1)Your caution advice to Karim is professional. With a lot of convoluted 
topics behind it, however, the net result is basically discouraging the 
listener from investigating the possibilities. Since this is rather 
philosophical, it can distract us from the essence unless we carry on a lengthy 
debate. Instead, I would like to address below only one aspect that you brought 
up.

2)"... an operator clearly looking to acquire *publicly routable* space 
without being clear that this suggestion wouldn't meet their needs.  ":

Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current 
CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from 
another angle, an IAP will then be able to expand the subscriber set 64 fold 
with still the original one publicly routable IPv4 address.

3)This 64 fold scaling factor is critical because it allows one CG-NAT 
cluster to serve a geographical area that becomes sufficient to cover a 
significant political territory. For example, if we assign two 240/4 addresses 
to each subscriber, one for stationary applications, one for mobile devices. 
And, each 240/4 address can be expanded by RFC1918 netblocks (total about 17.6M 
each). Each CG-NAT can now serve a country with population up to 128M. It turns 
out that population of over 90+ % of countries are fewer than this. So, each of 
them needs only one publicly routable IPv4 address. Then, the demand for IPv4 
address is drastically reduced.

4)In brief, the 240/4 is to substitute that of 100.64/10. So that the need 
for the publicly routable IPv4 addresses is significantly reduced.

Regards,


Abe (2024-01-10 23:08 EST)


On 2024-01-10 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly be able 
to use it on internal networks if your equipment supports it, you cannot use it 
as publicly routable space. There have been many proposals over the years to 
reclassify 240/4, but that has not happened, and is unlikely to at any point in 
the foreseeable future.

Mr. Chen-

I understand your perspective surrounding 240/4, and respect your position, 
even though I disagree. That being said, it's pretty dirty pool to toss this 
idea to an operator clearly looking to acquire *publicaly routable* space 
without being clear that this suggestion wouldn't meet their needs.

( Unless people are transferring RFC1918 space these days, in which case who 
wants to make me an offer for 10/8? )

On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI 
mailto:amekka...@mektel.ca>> wrote:

Interesting and thank you for sharing.



KARIM



From: Abraham Y. Chen mailto:ayc...@avinta.com>>
Sent: January 10, 2024 7:35 AM
To: KARIM MEKKAOUI mailto:amekka...@mektel.ca>>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>; Chen, Abraham Y. 
mailto:ayc...@alum.mit.edu>>
Subject: 202401100645.AYC Re: IPv4 address block
Importance: High



Hi, Karim:



1)If you have control of your own equipment (I presume that your business 
includes IAP - Internet Access Provider, since you are asking to buy IPv4 
blocks.), you can get a large block of reserved IPv4 address for free by 
disabling the program codes in your current facility that has been disabling 
the use of 240/4 netblock. Please have a look at the below whitepaper. Utilized 
according to the outlined disciplines, this is a practically unlimited 
resources. It has been known that multi-national conglomerates have been using 
it without announcement. So, you can do so stealthily according to the proposed 
mechanism which establishes uniform practices, just as well.



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



2)Being an unorthodox solution, if not controversial, please follow up with 
me offline. Unless, other NANOGers express their interests.





Regards,





Abe (2024-01-10 07:34 EST)







On 2024-01-07 22:46, KARIM ME

RE: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Tony Wicks]

 

 

 

2)"... an operator clearly looking to acquire *publicly routable* space 
without being clear that this suggestion wouldn't meet their needs.  ":

 

Since 240/4 has 256M addresses while 100.64/10 has only 4M, a current 
CG-NAT cluster can be expanded 64 fold once the 240/4 is used. Looking from 
another angle, an IAP will then be able to expand the subscriber set 64 fold 
with still the original one publicly routable IPv4 address.

 

The OP asked for “Any idea please on the best way to buy IPv4 blocs and what is 
the price”. I would expect they want actual public IPv4 address blocks and not 
internal CGNAT space. While the idea of using 240/4 instead of 100.64/10 would 
certainly have some merit I don’t believe its in any way related to what this 
OP asked for.

 

regards

 

202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Tom:

1)    Your caution advice to Karim is professional. With a lot of 
convoluted topics behind it, however, the net result is basically 
discouraging the listener from investigating the possibilities. Since 
this is rather philosophical, it can distract us from the essence unless 
we carry on a lengthy debate. Instead, I would like to address below 
only one aspect that you brought up.


2)    "... an operator clearly looking to acquire *publicly routable* 
space without being clear that this suggestion wouldn't meet their 
needs.  ":


    Since 240/4 has 256M addresses while 100.64/10 has only 4M, a 
current CG-NAT cluster can be expanded 64 fold once the 240/4 is used. 
Looking from another angle, an IAP will then be able to expand the 
subscriber set 64 fold with still the original one publicly routable 
IPv4 address.


3)    This 64 fold scaling factor is critical because it allows one 
CG-NAT cluster to serve a geographical area that becomes sufficient to 
cover a significant political territory. For example, if we assign two 
240/4 addresses to each subscriber, one for stationary applications, one 
for mobile devices. And, each 240/4 address can be expanded by RFC1918 
netblocks (total about 17.6M each). Each CG-NAT can now serve a country 
with population up to 128M. It turns out that population of over 90+ % 
of countries are fewer than this. So, each of them needs only one 
publicly routable IPv4 address. Then, the demand for IPv4 address is 
drastically reduced.


4)    In brief, the 240/4 is to substitute that of 100.64/10. So that 
the need for the publicly routable IPv4 addresses is significantly reduced.


Regards,


Abe (2024-01-10 23:08 EST)


On 2024-01-10 10:12, Tom Beecher wrote:

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly 
be able to use it on internal networks if your equipment supports it, 
you cannot use it as publicly routable space. There have been many 
proposals over the years to reclassify 240/4, but that has not 
happened, and is unlikely to at any point in the foreseeable future.


Mr. Chen-

I understand your perspective surrounding 240/4, and respect your 
position, even though I disagree. That being said, it's pretty dirty 
pool to toss this idea to an operator clearly looking to acquire 
*publicaly routable* space without being clear that this suggestion 
wouldn't meet their needs.


( Unless people are transferring RFC1918 space these days, in which 
case who wants to make me an offer for 10/8? )


On Wed, Jan 10, 2024 at 9:48 AM KARIM MEKKAOUI  
wrote:


Interesting and thank you for sharing.

KARIM

*From:*Abraham Y. Chen 
*Sent:* January 10, 2024 7:35 AM
*To:* KARIM MEKKAOUI 
*Cc:* nanog@nanog.org; Chen, Abraham Y. 
*Subject:* 202401100645.AYC Re: IPv4 address block
*Importance:* High

Hi, Karim:

1) If you have control of your own equipment (I presume that your
business includes IAP - Internet Access Provider, since you are
asking to buy IPv4 blocks.), you can get a large block of reserved
IPv4 address */_for free_/* by */_disabling_/* the program codes
in your current facility that has been */_disabling_/* the use of
240/4 netblock. Please have a look at the below whitepaper.
Utilized according to the outlined disciplines, this is a
practically unlimited resources. It has been known that
multi-national conglomerates have been using it without
announcement. So, you can do so stealthily according to the
proposed mechanism which establishes uniform practices, just as well.

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

2) Being an unorthodox solution, if not controversial, please
follow up with me offline. Unless, other NANOGers express their
interests.

Regards,

Abe (2024-01-10 07:34 EST)

On 2024-01-07 22:46, KARIM MEKKAOUI wrote:

Hi Nanog Community

Any idea please on the best way to buy IPv4 blocs and what is
the price?

Thank you

KARIM






Virus-free.www.avast.com






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