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

[Vasilenko Eduard via NANOG]

+1

From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Brett O'Hara
Sent: Saturday, January 13, 2024 1:04 PM
To: Forrest Christian (List Account) 
Cc: Chen, Abraham Y. ; NANOG 
Subject: Re: One Can't Have It Both Ways Re: Streamline the CG-NAT Re: EzIP Re: 
IPv4 address block

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) 
mailto: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 
mailto:ayc...@avinta.com>> 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.   

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

[Saku Ytti]

On Mon, 15 Jan 2024 at 06:18, Forrest Christian (List Account) <
li...@packetflux.com> wrote:

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
> IPv6 traffic will be around 25% since both ends have to do IPv6.
>

This assumes cosmological principle applies to the Internet, but Internet
traffic is not uniformly distributed.

It is entirely possible, and even reasonable, that AMSIX ~5% and GOOG 40%
are bps shares, and both are correct. Because AMSIX sees large entropy
between A-B end-points, GOOG sees very low entropy, it being always the B.

Certain tier1 transit network could see traffic being >50% IPv6 between two
specific pops, so great IPv6 adoption? Except it was a single CDN sending
traffic from them to them, if you'd exclude that CDN flows between the pop,
the IPv6 traffic share was low single digit percentage.

I am not saying IPv6 traffic is not increasing, I am saying that we are not
doing any favours to anyone, pretending we are on-track and that this will
happen, and that there are organic drivers which will ensure we are going
to end up with IPV6-only Internet.

-- 
  ++ytti

Re: Diversity in threading, Diversity of MUAs (was Re: How threading works

[Andy Smith]

Hi,

On Sun, Jan 14, 2024 at 11:10:23AM -0800, William Herrin wrote:
> On Sun, Jan 14, 2024 at 10:21 AM John Levine  wrote:
> > If I were you, I would call up Google and demand that they fix this bug.
> 
> What bug? In a decade and a half, Abe's bizarre subject changing
> behavior is the only time GMail has failed to group messages exactly
> as I find convenient. It's doing the right thing. Abe isn't.

Quite a lot of people prefer a proper threaded view as provided by
MUAs that understand In-Reply-To and so on. For those people, Mr
Chen's emails just look a bit strange and annoying (before one even
consumes the content ) but are kept part of the same thread tree.

As you note, gmail doesn't work this way and with it being such a
large mailbox provider some of its users have never actually
experience threading done any other way, may not even know that is
an option.

Over on a technical support list there are actually some prolific
old time posters asking for subject changes in sprawling threads
(and citing the list's FAQ…) but also gmail users asking for people
to *not* do that as it spawns new "conversations" for them. There,
the gmail users are at odds with ancient mailing list etiquette as
followed by a dwindling tech priesthood, but the gmailers now form
more than 30% of the active posting user base of the list.

Thanks,
Andy

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: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Randy Bush]

>     My apologies! For an uninitiated, I misread your message as if
> IPv6 was originally designed with a plan to assure smooth transition
> from IPv4.

i'll try again

there was a transition plan; it was dual stack.  i did not say it was a
*good* transition plan.

the plan's fatal flaw was that it assumed there was sufficient ipv4 to
be congruent until ipv6 was widely enough deplayed that the ipv4 could
be turned off.  this was in the face of very real data (props to frank
kastenholz) projecting the ipv4 run out rate.

the v6 fantasy was that ipv6 would be quickly deployed.  i guess it has
been from the perspective of geologic time.

randy

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

To my knowledge IPv6 is designed to replace IPv4. Anyone, feel free to
correct me if I'm wrong. There are just short of 4.3 billion IPv4
addresses, where the number of IPv6 addresses is 39 digits long.

Regards,
Christopher Hawker

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

> Hi, Randy:
>
> 1)   " ... unfortunately i already had grey hair in the '90s and was in
> the room for all this,  ...  ":
>
> My apologies! For an uninitiated, I misread your message as if IPv6
> was originally designed with a plan to assure smooth transition from IPv4.
>
> Regards,
>
>
> Abe (2024-01-14 23:17)
>
>
> On 2024-01-12 17:45, Randy Bush wrote:
>
> Perhaps you are too young to realize that the original IPv6 plan was
> not designed to be backward compatible to IPv4, and Dual-Stack was
> developed (through some iterations) to bridge the transition between
> IPv4 and IPv6? You may want to spend a few moments to read some
> history on this.
>
> ROFL!!!  if there is anything you can do to make me that young, you
> could have a very lucrative career outside of the internet.
>
> hint: unfortunately i already had grey hair in the '90s and was in the
> room for all this, and spent a few decades managing to get some of the
> worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
> rolled ipv6 on the backbone in 1997.
>
> randy
>
>
>
>
> 
> Virus-free.www.avast.com
> 
> <#m_854094815002427858_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Christopher Hawker]

Hang on... So EzIP is now about using 240/4 as CGNAT space? Wait, I'm
lost...

With CGNAT, there is either public IP space in front of the gateway, or
private space behind it. There is no such thing as "semi-private" space in
the world of CGNAT, as devices with public IPs can't directly access
devices behind a CGNAT gateway with a 100.64/10 address. It's either a
public address, or a private address (not to be confused with an RFC1918
private address).

Let's talk hypothetically for a minute and assume that 240/4 is used as
CGNAT space. Your "solution" to residential gateways not supporting the use
of 240/4 space being upgraded to OpenWRT won't work, because not all CPE
supports OpenWRT.

Instead of attempting to use a larger prefix for CGNAT, IPv6 is definitely
the easier solution to implement as the vast majority of vendors already
support v6.

Regards,
Christopher Hawker

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

> Hi, Mike:
>
> 1)   "... only private use. ...":
>
> The EzIP deployment plan is to use 240/4 netblock as "Semi-Public"
> addresses for the existing CG-NAT facility. With many RG-NATs (Routing /
> Residential Gateway -NATs) already capable of being 240/4 clients thru the
> upgrade to OpenWrt, no IoT on any private premises will sense any change.
>
> Regards,
>
>
> Abe (2024-01-14 23:04)
>
>
> On 2024-01-12 15:16, Mike Hammett wrote:
>
> I'm not talking about global, public use, only private use.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Tom Beecher"  
> *To: *"Mike Hammett"  
> *Cc: *"Ryan Hamel"  , "Abraham Y.
> Chen"  , nanog@nanog.org
> *Sent: *Friday, January 12, 2024 2:06:32 PM
> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
> address block
>
> You don't need everything in the world to support it, just the things
>> "you" use.
>
>
> You run an ISP, let me posit something.
>
> Stipulate your entire network infra, services, and applications support
> 240/4, and that it's approved for global , public use tomorrow. Some
> company gets a block in there, stands up some website. Here are some
> absolutely plausible scenarios that you might have to deal with.
>
> - Some of your customers are running operating systems / network gear that
> doesn't support 240/4.
> - Some of your customers may be using 3rd party DNS resolvers that don't
> support 240/4.
> - Some network in between you and the dest missed a few bogon ACLs ,
> dropping your customer's traffic.
>
> All of this becomes support issues you have to deal with.
>
> On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:
>
>> I wouldn't say it's unknowable, just that no one with a sufficient enough
>> interest in the cause has been loud enough with the research they've done,
>> assuming some research has been done..
>>
>> You don't need everything in the world to support it, just the things
>> "you" use.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Tom Beecher" 
>> *To: *"Mike Hammett" 
>> *Cc: *"Ryan Hamel" , "Abraham Y. Chen" <
>> ayc...@alum.mit.edu>, nanog@nanog.org
>> *Sent: *Friday, January 12, 2024 1:16:53 PM
>> *Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4
>> address block
>>
>> How far are we from that, in reality? I don't have any intention on using
>>> the space, but I would like to put some definition to this boogey man.
>>
>>
>> It's unknowable really.
>>
>> Lots of network software works just fine today with it. Some don't. To my
>> knowledge some NOS vendors have outright refused to support 240/4 unless
>> it's reclassified. Beyond network equipment, there is an unknowable number
>> of software packages , drivers, etc out in the world which 240/4 is still
>> hardcoded not to work. It's been 

Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Randy:

1)   " ... unfortunately i already had grey hair in the '90s and was in 
the room for all this,  ...  ":


    My apologies! For an uninitiated, I misread your message as if IPv6 
was originally designed with a plan to assure smooth transition from IPv4.


Regards,


Abe (2024-01-14 23:17)


On 2024-01-12 17:45, Randy Bush wrote:

Perhaps you are too young to realize that the original IPv6 plan was
not designed to be backward compatible to IPv4, and Dual-Stack was
developed (through some iterations) to bridge the transition between
IPv4 and IPv6? You may want to spend a few moments to read some
history on this.

ROFL!!!  if there is anything you can do to make me that young, you
could have a very lucrative career outside of the internet.

hint: unfortunately i already had grey hair in the '90s and was in the
room for all this, and spent a few decades managing to get some of the
worst stupidities (TLA, NLA, ...) pulled out of the spec.  at iij, we
rolled ipv6 on the backbone in 1997.

randy




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

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

[Forrest Christian (List Account)]

If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
IPv6 traffic will be around 25% since both ends have to do IPv6.

If you're running an IPv6 enabled server you'll see 50% of your traffic as
IPv6 in the above scenario.   Likewise, if you are on an IPv6 connected
client, then you'll also see 50٪ of your traffic as IPv6.

Note that if your adoption rates are lower, say 30% and 40%, your IPv6
traffic will be lower..  around 12% in the 30/40٪ scenario.

Cloudflare has an interesting analysis.
https://blog.cloudflare.com/ipv6-from-dns-pov#:~:text=IPv6%20Adoption%20on%20the%20Server%20Side,-The%20following%20graph=IPv6%20adoption%20by%20servers%20is,what%20was%20observed%20for%20clients
.

On Sun, Jan 14, 2024, 8:51 PM Abraham Y. Chen  wrote:

> Hi, Ryan:
>
> 1) " ... it accounts for 40% of the traffic at Google.   ":
>
> Perhaps you were referring to the following?
>
> https://www.google.com/intl/en/ipv6/statistics.html
>
> 2)If so, your quotation is correct, except there are some hidden
> stories below the surface:
>
> A.When you Google for it with key words "IPv6 Traffic Google", the
> first hit shows "IPv6 *Adoption*" that lead to the above. So, strictly
> speaking, it is *not traffic *data that you are looking at.
>
> B.Above the actual graph, you will find statements, such as "
> ...  the *availability of IPv6 connectivity* among Google users. "
> So, legally, the graph is correct on its own right, but may not be exactly
> what you thought. Reader be aware!
>
> It implies that the graph the IPv6 capability (equipment readiness) of
> Google users, not necessarily the actual traffic they generate. The two do
> not equate to each other.
>
> 3)However, the above did seem to support what was generally said in
> the public. Until, we found an interesting ongoing (the only one of such
> resource that is updated about every ten minutes) statistics by AMS-IX
> (AMSterdam Internet eXchange) :
>
> https://stats.ams-ix.net/sflow/ipv6.html
>
> https://stats.ams-ix.net/sflow/ether_type.html
> a
> The second URL shows that IPv6 accounts for approximately 5.7% of the
> overall Internet traffic that AMS-IX sees today. If one traces back through
> the archived data, the earlier numbers were even much lower. In fact, those
> graphs looked meaningless, because there was hardly any visible trace
> colored for IPv6. This has been going on for at least the last one decade.
> So, it could not be an error.
>
> 4)We contacted AMS-IX for a possible explanation of the obvious
> discrepancy. They politely referred us to our own ISPs. This triggered our
> curiosity. We decided that we needed to find the full world-wide IPv6
> traffic data.
>
> 5)There was an annual world-wide Internet traffic statistics and
> forecast published by Cisco that stopped after 2017 (see URL below to the
> last issue). We contacted Cisco in 2020 and got an eMail confirmation.
>
>
> https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf
>
> 6)However, there has never been any equivalent publication for the
> IPv6 by itself that we could locate.
>
> 7)In search for a possible explanation of the discrepancy between Pts.
> 1) & 3), we came across the following article. In brief, it reported that
> the Peering agreements among Internet backbone providers were less settled
> for IPv6 than IPv4. Thus, higher percentage of IPv6 traffic than that of
> IPv4 should have been directed through the IXs (Internet eXchanges), such
> as AMS-IX.
>
> https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/
>
> 8)The conclusion of Pt. 7) furthered our puzzlement, because it was
> opposite to what we were hoping for. That is, the roughly 5.7% IPv6 traffic
> that AMS-IX sees implies that within the overall Internet, the IPv6 traffic
> should be even less than 5.7%, not as high as Google's 40+% (Adoption)
> rate. Since we did not have the resources to further the research on this
> topic, we saved the above summary to share with anyone interested in
> pursuing for a better understanding. It will be much appreciated, if you
> could share your insights of this topic.
>
> Regards,
>
>
> Abe (2024-01-14 22:49 EST)
>
>
>
>
> On 2024-01-12 09:20, Ryan Hamel wrote:
>
> Abraham,
>
> It has existed for many years, already supported on many devices, does
> not require NAT, address space is plentiful, does not require additional
> proposals, and it accounts for 40% of the traffic at Google.
>
> Ryan
>
> --
> *From:* Abraham Y. Chen  
> *Sent:* Friday, January 12, 2024 3:45:32 AM
> *To:* Ryan Hamel  
> *Cc:* nanog@nanog.org  ; Michael Butler
>  ; Chen, Abraham
> Y.  
> *Subject:* IPv6? Re: Where to Use 240/4 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, Ryan:
>
> 1)   " ...  

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[Abraham Y. Chen]

Hi, Mike:

1)   "... only private use. ...":

    The EzIP deployment plan is to use 240/4 netblock as "Semi-Public" 
addresses for the existing CG-NAT facility. With many RG-NATs (Routing / 
Residential Gateway -NATs) already capable of being 240/4 clients thru 
the upgrade to OpenWrt, no IoT on any private premises will sense any 
change.


Regards,


Abe (2024-01-14 23:04)


On 2024-01-12 15:16, Mike Hammett wrote:

I'm not talking about global, public use, only private use.



-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Tom Beecher" 
*To: *"Mike Hammett" 
*Cc: *"Ryan Hamel" , "Abraham Y. Chen" 
, nanog@nanog.org

*Sent: *Friday, January 12, 2024 2:06:32 PM
*Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 
address block


You don't need everything in the world to support it, just the
things "you" use.


You run an ISP, let me posit something.

Stipulate your entire network infra, services, and applications 
support 240/4, and that it's approved for global , public use 
tomorrow. Some company gets a block in there, stands up some website. 
Here are some absolutely plausible scenarios that you might have to 
deal with.


- Some of your customers are running operating systems / network gear 
that doesn't support 240/4.
- Some of your customers may be using 3rd party DNS resolvers that 
don't support 240/4.
- Some network in between you and the dest missed a few bogon ACLs , 
dropping your customer's traffic.


All of this becomes support issues you have to deal with.

On Fri, Jan 12, 2024 at 2:21 PM Mike Hammett  wrote:

I wouldn't say it's unknowable, just that no one with a sufficient
enough interest in the cause has been loud enough with the
research they've done, assuming some research has been done..

You don't need everything in the world to support it, just the
things "you" use.



-
Mike Hammett
Intelligent Computing Solutions 


Midwest Internet Exchange 


The Brothers WISP 



*From: *"Tom Beecher" 
*To: *"Mike Hammett" 
*Cc: *"Ryan Hamel" , "Abraham Y. Chen"
, nanog@nanog.org
*Sent: *Friday, January 12, 2024 1:16:53 PM
*Subject: *Re: Stealthy Overlay Network Re: 202401100645.AYC Re:
IPv4 address block

How far are we from that, in reality? I don't have any
intention on using the space, but I would like to put some
definition to this boogey man.


It's unknowable really.

Lots of network software works just fine today with it. Some
don't. To my knowledge some NOS vendors have outright refused to
support 240/4 unless it's reclassified. Beyond network equipment,
there is an unknowable number of software packages , drivers, etc
out in the world which 240/4 is still hardcoded not to work. It's
been unfortunate to see this fact handwaved away in many
discussions on the subject.

The Mirai worm surfaced in 2016. The software vulnerabilities used
in its attack vectors are still unpatched and present in massive
numbers across the internet; there are countless variants that
still use the same methods, 8 years later. Other
vulnerabilities still exist after multiple decades. But we somehow
think devices will be patched to support 240/4 quickly?

It's just unrealistic.

On Fri, Jan 12, 2024 at 1:03 PM Mike Hammett  wrote:

" every networking vendor, hardware vendor, and OS vendor"

How far are we from that, in reality? I don't have any
intention on using the space, but I would like to put some
definition to this boogey man.



-
Mike Hammett
Intelligent Computing Solutions 

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

[Abraham Y. Chen]

Hi, Ryan:

1) " ... it accounts for 40% of the traffic at Google.   ":

    Perhaps you were referring to the following?

https://www.google.com/intl/en/ipv6/statistics.html

2)    If so, your quotation is correct, except there are some hidden 
stories below the surface:


    A.    When you Google for it with key words "IPv6 Traffic Google", 
the first hit shows "IPv6 *_/Adoption/_*" that lead to the above. So, 
strictly speaking, it is _/*not traffic */_data that you are looking at.


    B.    Above the actual graph, you will find statements, such as " 
... the *_/availability of IPv6 connectivity/_*_/**/_among Google users. 
" So, legally, the graph is correct on its own right, but may not be 
exactly what you thought. Reader be aware!


    It implies that the graph the IPv6 capability (equipment readiness) 
of Google users, not necessarily the actual traffic they generate. The 
two do not equate to each other.
3)    However, the above did seem to support what was generally said in 
the public. Until, we found an interesting ongoing (the only one of such 
resource that is updated about every ten minutes) statistics by AMS-IX 
(AMSterdam Internet eXchange) :


https://stats.ams-ix.net/sflow/ipv6.html

https://stats.ams-ix.net/sflow/ether_type.html
a
    The second URL shows that IPv6 accounts for approximately 5.7% of 
the overall Internet traffic that AMS-IX sees today. If one traces back 
through the archived data, the earlier numbers were even much lower. In 
fact, those graphs looked meaningless, because there was hardly any 
visible trace colored for IPv6. This has been going on for at least the 
last one decade. So, it could not be an error.


4)    We contacted AMS-IX for a possible explanation of the obvious 
discrepancy. They politely referred us to our own ISPs. This triggered 
our curiosity. We decided that we needed to find the full world-wide 
IPv6 traffic data.


5)    There was an annual world-wide Internet traffic statistics and 
forecast published by Cisco that stopped after 2017 (see URL below to 
the last issue). We contacted Cisco in 2020 and got an eMail confirmation.


https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813d3b8_white-paper-c11-741490.pdf

6)    However, there has never been any equivalent publication for the 
IPv6 by itself that we could locate.


7)    In search for a possible explanation of the discrepancy between 
Pts. 1) & 3), we came across the following article. In brief, it 
reported that the Peering agreements among Internet backbone providers 
were less settled for IPv6 than IPv4. Thus, higher percentage of IPv6 
traffic than that of IPv4 should have been directed through the IXs 
(Internet eXchanges), such as AMS-IX.


https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/

8)    The conclusion of Pt. 7) furthered our puzzlement, because it was 
opposite to what we were hoping for. That is, the roughly 5.7% IPv6 
traffic that AMS-IX sees implies that within the overall Internet, the 
IPv6 traffic should be even less than 5.7%, not as high as Google's 40+% 
(Adoption) rate. Since we did not have the resources to further the 
research on this topic, we saved the above summary to share with anyone 
interested in pursuing for a better understanding. It will be much 
appreciated, if you could share your insights of this topic.


Regards,


Abe (2024-01-14 22:49 EST)




On 2024-01-12 09:20, Ryan Hamel wrote:

Abraham,

It has existed for many years, already supported on many devices, does 
not require NAT, address space is plentiful, does not require 
additional proposals, and it accounts for 40% of the traffic at Google.


Ryan


*From:* Abraham Y. Chen 
*Sent:* Friday, January 12, 2024 3:45:32 AM
*To:* Ryan Hamel 
*Cc:* nanog@nanog.org ; Michael Butler 
; Chen, Abraham Y. 
*Subject:* IPv6? Re: Where to Use 240/4 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, Ryan:

1)   " ...  Save yourself the time and effort on this and implement 
IPv6.    ":


    What is your selling point?


Regards,


Abe (2024-01-12 06:44)





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

[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: Diversity in threading, Diversity of MUAs (was Re: How threading works

[William Herrin]

On Sun, Jan 14, 2024 at 10:21 AM John Levine  wrote:
> If I were you, I would call up Google and demand that they fix this bug.

What bug? In a decade and a half, Abe's bizarre subject changing
behavior is the only time GMail has failed to group messages exactly
as I find convenient. It's doing the right thing. Abe isn't.

Regards,
Bill Herrin


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

Re: Diversity in threading, Diversity of MUAs (was Re: How threading works

[John Levine]

It appears that Peter Potvin via NANOG  
said:
>-=-=-=-=-=-
>
>*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?

I don't think the rest of us are obliged to arrange our lives around one
mail provider's imperfect heuristics.

If I were you, I would call up Google and demand that they fix this bug.
What do they think you're paying for?  Oh, wait ...

R's,
John

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