Re: Making Use of 240/4 NetBlock

[JORDI PALET MARTINEZ via NANOG]

Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is 
the only viable long-term solution.

 

The effort to “reinvent” any part of IPv4 or patches to it, then test that 
everything keeps working as expected, versus the benefits and gained time, it 
is much best invested in continue the IPv6 deployment which is already going on 
in this region and the rest of the world.

 

It would not make sense, to throw away all the efforts that have been already 
done with IPv6 and we should avoid confusing people.

 

I just think that even this thread is a waste of time (and will not further 
participate on it), time that can be employed in continue deploying IPv6.

 

Regards,

Jordi

@jordipalet

 

 

 

El 12/3/22 6:32, "NANOG en nombre de Greg Skinner via NANOG" 
 escribió:

 

 



On Mar 10, 2022, at 8:44 PM, Masataka Ohta  
wrote:


IIRC, at some time, perhaps when CIDR was deployed widely and
having something other than IPv4 was a hot topic, there was a
discussion on releasing 240/4 in IETF. Reasonings against it were
that the released space will be consumed quickly (at that time,
NAT already existed but was uncommon) and that new IP will be
designed and deployed quickly (we were optimistic).

    
   Masataka Ohta

 

There have been many discussions about 240/4 in the IETF.  For some examples, 
query “240/4” in the ‘ietf’ mail archive on mailarchive.ietf.org.

 

—gregbo



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: Making Use of 240/4 NetBlock

[Greg Skinner via NANOG]

> On Mar 10, 2022, at 8:44 PM, Masataka Ohta  
> wrote:
> 
> IIRC, at some time, perhaps when CIDR was deployed widely and
> having something other than IPv4 was a hot topic, there was a
> discussion on releasing 240/4 in IETF. Reasonings against it were
> that the released space will be consumed quickly (at that time,
> NAT already existed but was uncommon) and that new IP will be
> designed and deployed quickly (we were optimistic).
> 
>   Masataka Ohta
> 

There have been many discussions about 240/4 in the IETF.  For some examples, 
query “240/4” in the ‘ietf’ mail archive 
 on 
mailarchive.ietf.org.

—gregbo

Re: V6 still widely supported (was Re: CC: s to Non List Members,

[Josh Luthman]

Verizon Wireless does have v6.  I see a 100.64/24 on my phone all the time.

On Fri, Mar 11, 2022 at 4:11 PM John Covici  wrote:

> Verizon does not support ipv6 as far as I know, I have fios and they
> said it was not supported.
>
> On Fri, 11 Mar 2022 15:20:48 -0500,
> John Levine wrote:
> >
> > It appears that Joe Maimon  said:
> > >higher penetration of native v6, I would restate that a bit more
> > >conservatively as
> > >
> > >Google's statistics are likely a fair barometer for USA usage in the
> > >large content provider arena which have a strong mobile representation.
> >
> > AT, Comcast, and Charter/Spectrum, the three largest cable companies,
> have IPv6
> > support.  I expect a lot of Google searches and Gmail messages come from
> them, too.
> >
> > I think it's more accurate to say that large networks have looked at the
> > costs and implemented IPv6.  Small networks, many of which have no need
> > to expand beyond their existing IPv4 allocations, largely have not.
> >
> > Of course, there are a lot more small networks than large ones, even
> though
> > they don't necessarily represent many users, so guess who we hear from?
> >
> > R"s,
> > John
>
> --
> Your life is like a penny.  You're going to lose it.  The question is:
> How do
> you spend it?
>
>  John Covici wb2una
>  cov...@ccs.covici.com
>

Re: V6 still widely supported (was Re: CC: s to Non List Members,

[John Covici]

Verizon does not support ipv6 as far as I know, I have fios and they
said it was not supported.

On Fri, 11 Mar 2022 15:20:48 -0500,
John Levine wrote:
> 
> It appears that Joe Maimon  said:
> >higher penetration of native v6, I would restate that a bit more 
> >conservatively as
> >
> >Google's statistics are likely a fair barometer for USA usage in the 
> >large content provider arena which have a strong mobile representation.
> 
> AT, Comcast, and Charter/Spectrum, the three largest cable companies, have 
> IPv6
> support.  I expect a lot of Google searches and Gmail messages come from 
> them, too.
> 
> I think it's more accurate to say that large networks have looked at the
> costs and implemented IPv6.  Small networks, many of which have no need
> to expand beyond their existing IPv4 allocations, largely have not.
> 
> Of course, there are a lot more small networks than large ones, even though
> they don't necessarily represent many users, so guess who we hear from?
> 
> R"s,
> John

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: V6 still widely supported (was Re: CC: s to Non List Members,

[David Conrad]

On Mar 11, 2022, at 12:20 PM, John Levine  wrote:
> It appears that Joe Maimon  said:
>> higher penetration of native v6, I would restate that a bit more
>> conservatively as
>> 
>> Google's statistics are likely a fair barometer for USA usage in the
>> large content provider arena which have a strong mobile representation.
> 
> AT, Comcast, and Charter/Spectrum, the three largest cable companies, have 
> IPv6
> support.

As do (so I hear) mobile providers, which is increasingly how people around the 
world get access to the Internet.

However, this discussion has drifted a bit — it wasn’t (supposed to be) a 
discussion about IPv6 deployment per se, but rather network operations reality 
as they impact IPv6 deployment.

There was an assertion (that I am not questioning) that there are various kit 
vendors who claim IPv6 support, but when network operators attempt to deploy 
that kit, the IPv6 support is found to be show-stoppingly buggy, lacking in 
required features, or otherwise causing said network operators 
frustration/irritation/etc and/or to give up on deploying IPv6 “until it is 
more mature” (or “more/any customers demand it”).

For whatever reason, there appears to be a reluctance to name names in such 
cases. My question was whether it might be helpful in encouraging IPv6 
deployment (or at least reducing the amount of disappointment) for network 
operators to be more public when reality does not match vendor claims, just as 
“timed full disclosure” has helped in addressing (some) security-related issues.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: V6 still widely supported (was Re: CC: s to Non List Members,

[John Levine]

It appears that Joe Maimon  said:
>higher penetration of native v6, I would restate that a bit more 
>conservatively as
>
>Google's statistics are likely a fair barometer for USA usage in the 
>large content provider arena which have a strong mobile representation.

AT, Comcast, and Charter/Spectrum, the three largest cable companies, have 
IPv6
support.  I expect a lot of Google searches and Gmail messages come from them, 
too.

I think it's more accurate to say that large networks have looked at the
costs and implemented IPv6.  Small networks, many of which have no need
to expand beyond their existing IPv4 allocations, largely have not.

Of course, there are a lot more small networks than large ones, even though
they don't necessarily represent many users, so guess who we hear from?

R"s,
John

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Abraham Y. Chen]

Hi, Ca By:

1)    Re: Ur. Pt. 1) " ... the number is 46% in the USA.  ":    Whoa! 
Your revised number is even higher. And, I could round it up to 50%! 
Seriously, please be specific about where are you reading the number 
that you are reporting? I commented after reading your second reference, 
because I could not find relevant data from the first one. Is there 
something hidden there? Please identify.


2)    Re: Ur. Pt. 2): I have to wait for your clarification for Pt. 1) 
above to proceed with these additional statements.


Regards,


Abe (2022-03-11 15:06)




On 2022-03-11 11:19, Ca By wrote:



On Fri, Mar 11, 2022 at 7:15 AM Abraham Y. Chen  wrote:

Dear Ca By:

1)    It appears that you are reading the Google graph too
optimistically, or incorrectly. That is, the highest peaks of the
graph are about 38%. The average of the graph is about 36%. Citing
"over 40%" from these is a gross exaggeration. In fact, the peaks
were reached on weekends and holidays due to more residential
usage, you can clearly see such by zooming into the graph. In
addition, the graph has been exhibiting an asymptomatic trend ever
since a few years back. The COVID-19 pushed this graph up a bit
due to the lock-down and work-from-home factors. Below was an
analysis pre-pandemic:


Sorry for being imprecise in my communication, the number is 46% in 
the USA.



https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/

2)    Since Google is one of the stronger IPv6 promoters, usage of
IPv6 outside of the Google domain can only be lower, by simple
logic deduction.


Google’s number represents how many users reach it over ipv6. Given 
Google’s ubiquity in the usa, it is a fair barometer for the usa at 
large.  This data is helpful for content providers  estimating demand 
for ipv6 (46% of users will use ipv6 if it is available)  and for the 
network operator community to understand where their peers sit.


In summary, there is a lot of ipv6 on the usa internet today. Almost 
half for Google, per their published numbers. Over 75% end to end ipv6 
on some large mobile networks.  Hence my appeal to view published data.


Reading anecdotal Nanog mails from a handful of folks concluding ipv6 
has failed will not leave the passive impartial observer with an 
accurate view.


Regards,


Abe (2022-03-11 10:11)


--
NANOG Digest, Vol 170, Issue 12

Message: 12
Date: Thu, 10 Mar 2022 08:00:17 -0800
From: Ca By  
To: Saku Ytti  
Cc: Joe Greco  ,nanog@nanog.org
Subject: Re: V6 still not supported (was Re: CC: s to Non List Members
(was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4
NetBlock))
Message-ID:
  

Content-Type: text/plain; charset="utf-8"

On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti  
  wrote:


On Wed, 9 Mar 2022 at 21:00, Joe Greco  
  wrote:


I really never thought it'd be 2022 and my networks would be still
heavily v4.  Mind boggling.

Same. And if we don't voluntarily agree to do something to it, it'll
be the same in 2042, we fucked up and those who come after us pay the
price of the insane amount of work and cost dual stack causes.

It is solvable, easily and cheaply, like most problems (energy,
climate), but not when so many poor leaders participate in decision
making.

--
   ++ytti


Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is
on ipv6 (all your smartphone, many of your home router, a growing amount of
your clouds [i see you aws])

https://www.worldipv6launch.org/measurements/

Google sees over 40% of their users on ipv6, with superior latency

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



-- next part --




Virus-free. www.avast.com




<#m_6390985030485347940_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>




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

Re: Cogent cutting links to Russia?

[Martin Hannigan]

On Fri, Mar 4, 2022 at 5:17 PM Aaron Wendel 
wrote:

> I think you're reading it incorrectly.
>
> The US government and many other countries have imposed sanctions
> against Russia and barred businesses in those countries from doing
> business in Russia.  Cogent is a US based company and, even if it
> operates on foreign jurisdictions through subsidiaries, has issues
> providing services to sanctioned entities.  That's how I read the
> excerpt provided.
>
> Aaron
>




Yes.

I picked this up via news related to Lumen and Russia today.

"We decided to disconnect the network due to increased security risk inside
Russia."

https://news.lumen.com/RussiaUkraine

Warm regards,

-M<

Re: Russia attempts mandating installation of root CA on clients for TLS MITM

[Eric Kuhnke]

Clarification, Google Chrome has its own root CA revocation/CRL program. It
does still rely on the operating system root CA trust store.

Using a typical intranet/RFC1918 IP space environment as an example, as you
might see in any $BIGCORP, if you install your own choice of root CA in the
Windows 10 root CA trust store, Chrome's TLS1.2/TLS1.3 access to internal
resources that are https only will work flawlessly without any security
warnings. Very normal configuration these days. Used for things like DLP in
banking/corporate environments or places where the gateway between internal
IP space and the public world has a firewall in place with MITM ability for
all TLS traffic.

On any windows 10 system with local admin privileges you can manually find
this by opening MMC, go to add/remove snap-ins, select the certificates
(local computer) snap-in, left side menu browse to trusted root
certificates.



On Fri, 11 Mar 2022 at 10:48, Mu  wrote:

> >Mozilla is the only browser vendor these days that maintains its own
> independent root CA storage for the browser. Chrome, Chromium, Safari,
> Edge, IE etc all use whatever root CAs are trusted by the operating system.
> If they can get Windows 10 client PCs pushed to retail with an image that
> includes their CA...
>
> Google Chrome has it's own root program, and all vendors have been reliant
> on Mozilla's setup for some time. They don't just blindly trust the OS.
>
>
> --- Original Message ---
> On Friday, March 11th, 2022 at 1:34 PM, Eric Kuhnke 
> wrote:
>
> Considering that 99% of non-technical end users of windows, macos,
> android, ios client devices *have no idea what a root CA is,* if an
> authoritarian regime can mandate the installation of a government-run root
> CA in the operating system CA trust store of all new devices sold at
> retail, as equipment is discarded/upgraded/replaced incrementally over a
> period of years, they could eventually have the capability of MITM of a
> significant portion of traffic.
>
> Presumably with Apple ending shipment of new MacOS devices to Russia and
> retail sales of new devices, this wouldn't be so much of an issue with
> MacOS. The process of re-imaging a modified MacOS install .DMG onto a
> "blank" macbook air or similar with a new root CA included would be non
> trivial, and hopefully might be impossible due to crypto signature required
> for a legit MacOS bootable install image.
>
> Mozilla is the only browser vendor these days that maintains its own
> independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
> IE etc all use whatever root CAs are trusted by the operating system. If
> they can get Windows 10 client PCs pushed to retail with an image that
> includes their CA...
>
>
>
>
>
>
> On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
> nanog@nanog.org> wrote:
>
>> I think the point Eric was trying to make is that while, indeed, the
>> initial, stated goal might be to be able to issue certificates to replace
>> those expired or expiring, there's just a jump/skip/hop to force
>> installation of this root CA certificate in all browsers, or for Russia to
>> block downloads of Firefox/Chrome from outside the Federation, and instead
>> distribute versions which would already include this CA's certificate. And
>> then MITM the whole population without their knowledge or approval.
>>
>> GIVEN: savvy users might know how to delete the certificate, or others
>> may teach them how, and how to download other CA's certificates (if the
>> government was to ship only this certificate with the browser). Cat and
>> mouse game. The North Korean and Chinese governments have been doing these
>> kind of shenanigans for a long time - I am sure Russia could copy their
>> model. And considering the tight media control they’re already exercising,
>> I don't think it is crazy or paranoid to think Internet will be next. They
>> seem to be already going down that path.
>>
>> PS: opinions and statements, like the above, are my very own personal
>> take or opinion. Nothing I say should be interpreted to be my employer's
>> position, nor be supported by my employer.
>>
>> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
>> 
>> wrote:
>>
>> On Thu, 10 Mar 2022, Eric Kuhnke wrote:
>> > I think we'll see a lot more of this from authoritarian regimes in the
>> > future. For anyone unfamiliar with their existing distributed DPI
>> > architecture, google "Russia SORM".
>>
>> Many nation's have a government CA.
>>
>> The United States Government has its Federal Public Key Infrastructure,
>> and Federal Bridge CA.
>>
>> https://playbooks.idmanagement.gov/fpki/ca/
>>
>> If you use DOD CAC ID's or FCEB PIV cards or other federal programs, your
>> computer needs to have the FPKI CA's. You don't need the FPKI CA's for
>> other purposes.
>>
>> Some countries CA's issue for citizen and business certificates.
>>
>>
>> While X509 allows you to specify different CA's for different purposes,
>> since the 

Re: Russia attempts mandating installation of root CA on clients for TLS MITM

[Eric Kuhnke]

Considering that 99% of non-technical end users of windows, macos, android,
ios client devices *have no idea what a root CA is,* if an authoritarian
regime can mandate the installation of a government-run root CA in the
operating system CA trust store of all new devices sold at retail, as
equipment is discarded/upgraded/replaced incrementally over a period of
years, they could eventually have the capability of MITM of a significant
portion of traffic.

Presumably with Apple ending shipment of new MacOS devices to Russia and
retail sales of new devices, this wouldn't be so much of an issue with
MacOS.  The process of re-imaging a modified MacOS install .DMG onto a
"blank" macbook air or similar with a new root CA included would be non
trivial, and hopefully might be impossible due to crypto signature required
for a legit MacOS bootable install image.

Mozilla is the only browser vendor these days that maintains its own
independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
IE etc all use whatever root CAs are trusted by the operating system. If
they can get Windows 10 client PCs pushed to retail with an image that
includes their CA...






On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
nanog@nanog.org> wrote:

> I think the point Eric was trying to make is that while, indeed, the
> initial, stated goal might be to be able to issue certificates to replace
> those expired or expiring, there's just a jump/skip/hop to force
> installation of this root CA certificate in all browsers, or for Russia to
> block downloads of Firefox/Chrome from outside the Federation, and instead
> distribute versions which would already include this CA's certificate. And
> then MITM the whole population without their knowledge or approval.
>
> GIVEN: savvy users might know how to delete the certificate, or others may
> teach them how, and how to download other CA's certificates (if the
> government was to ship only this certificate with the browser). Cat and
> mouse game. The North Korean and Chinese governments have been doing these
> kind of shenanigans for a long time - I am sure Russia could copy their
> model. And considering the tight media control they’re already exercising,
> I don't think it is crazy or paranoid to think Internet will be next. They
> seem to be already going down that path.
>
> PS: opinions and statements, like the above, are my very own personal take
> or opinion. Nothing I say should be interpreted to be my employer's
> position, nor be supported by my employer.
>
> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
> 
> wrote:
>
> On Thu, 10 Mar 2022, Eric Kuhnke wrote:
> > I think we'll see a lot more of this from authoritarian regimes in
> the
> > future. For anyone unfamiliar with their existing distributed DPI
> > architecture, google "Russia SORM".
>
> Many nation's have a government CA.
>
> The United States Government has its Federal Public Key
> Infrastructure,
> and Federal Bridge CA.
>
> https://playbooks.idmanagement.gov/fpki/ca/
>
> If you use DOD CAC ID's or FCEB PIV cards or other federal programs,
> your
> computer needs to have the FPKI CA's.  You don't need the FPKI CA's
> for
> other purposes.
>
> Some countries CA's issue for citizen and business certificates.
>
>
> While X509 allows you to specify different CA's for different
> purposes,
> since the days of Netscape, browsers trust hundreds of root or bridged
> CA
> in its trust repository for anything.
>
> Neither commercial or government CA's are inherently more (or less)
> trustworthy.  There have been trouble with CA's of all types.
>
> A X509 certificate is a big integer number, in a fancy wrapper.  Its
> not a
> magical object.
>
>

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 12 Mar, 2022

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  892760
Prefixes after maximum aggregation (per Origin AS):  335982
Deaggregation factor:  2.66
Unique aggregates announced (without unneeded subnets):  428829
Total ASes present in the Internet Routing Table: 72817
Prefixes per ASN: 12.26
Origin-only ASes present in the Internet Routing Table:   62477
Origin ASes announcing only one prefix:   25673
Transit ASes present in the Internet Routing Table:   10340
Transit-only ASes present in the Internet Routing Table:383
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  53
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:   935
Number of instances of unregistered ASNs:   938
Number of 32-bit ASNs allocated by the RIRs:  38762
Number of 32-bit ASNs visible in the Routing Table:   32261
Prefixes from 32-bit ASNs in the Routing Table:  151001
Number of bogon 32-bit ASNs visible in the Routing Table:24
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:527
Number of addresses announced to Internet:   3068579968
Equivalent to 182 /8s, 230 /16s and 208 /24s
Percentage of available address space announced:   82.9
Percentage of allocated address space announced:   82.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  303160

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   233372
Total APNIC prefixes after maximum aggregation:   66144
APNIC Deaggregation factor:3.53
Prefixes being announced from the APNIC address blocks:  228376
Unique aggregates announced from the APNIC address blocks:94526
APNIC Region origin ASes present in the Internet Routing Table:   12459
APNIC Prefixes per ASN:   18.33
APNIC Region origin ASes announcing only one prefix:   3550
APNIC Region transit ASes present in the Internet Routing Table:   1723
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   7662
Number of APNIC addresses announced to Internet:  774176768
Equivalent to 46 /8s, 37 /16s and 0 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-151865
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:260476
Total ARIN prefixes after maximum aggregation:   119468
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   260455
Unique aggregates announced from the ARIN address blocks:123999
ARIN Region origin ASes present in the Internet Routing Table:18970
ARIN Prefixes per ASN:

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Grant Taylor via NANOG wrote:



I believe that talking about removing IPv4 in any capacity /now/ is a 
disservice to the larger conversation.


We mostly agree. Except that there is a significant vocal portion of the 
IPv6 spectrum that would like to start obsoleting IPv4 now.


I have my doubts about getting back to a single protocol Internet 
(IPv6) in my lifetime, much less my career.


I both doubt and very much hope that it will not be quite that long, but 
even so, the fact that it can even be considered a possibility should be 
a significant wake up call.


In any event, all this underscores the reality that IPv4 requires more 
investment to carry along until that point.



And until that point, IPv6 is an optimization, not a requirement.


How long do you wait during the "optimization" window before actually 
deploying IPv6?  The 11th hour?  Why not start deploying IPv6 with new 
green field deployments at the 2nd hour?



Until you have the itch to do so, until you have a business case to do 
so, until you no longer have any excuse not to do so. The opt in 
optimization is optional.


Joe

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Grant Taylor via NANOG]

On 3/11/22 9:39 AM, Joe Maimon wrote:
I am not really convinced that IPv4 can be 
ignored/marginalized/obsoleted without penetration reaching over 90%, 
globally.


I feel like that's an unfair characterization / summarization.

The VAST MAJORITY of the pro IPv6 discussions that I see are targeting 
parity between IPv4 and IPv6.  As such, there is absolutely no ignoring, 
no marginalizing, no obsoleting of IPv4 in those discussions.


The vast majority of the discussions that I've participated in have not 
been IPv4 exclusive or IPv6.  --  The breakdown tends to be three 
categories, exclusive IPv4 (old), dual IPv4 and IPv6 (current), and 
exclusive IPv6 (far Far FAR future).


As I see it, if we divide the three categories equally, 0-33% is IPv4 
only, 34-66% is dual IPv4 and IPv6, and 67-99% (can be) IPv6 only.  -- I 
fudged the numbers a %, to simplify the 1/3 fractional math.  --  As 
such, we have crossed over from the exclusive IPv4 (0-33%) into the dual 
IPv4 and IPv6 (34-66%).  We have a long way to go before even 
considering exclusive IPv6 (67% (or higher)).


I believe that talking about removing IPv4 in any capacity /now/ is a 
disservice to the larger conversation.


I have my doubts about getting back to a single protocol Internet (IPv6) 
in my lifetime, much less my career.



And until that point, IPv6 is an optimization, not a requirement.


How long do you wait during the "optimization" window before actually 
deploying IPv6?  The 11th hour?  Why not start deploying IPv6 with new 
green field deployments at the 2nd hour?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Joe Maimon]

Ca By wrote:




Google’s number represents how many users reach it over ipv6. Given 
Google’s ubiquity in the usa, it is a fair barometer for the usa at 
large.


Given google's popularity on handheld platforms, the users of which tend 
to be much less sensitive to IPv4 translation mechanisms and have a much 
higher penetration of native v6, I would restate that a bit more 
conservatively as


Google's statistics are likely a fair barometer for USA usage in the 
large content provider arena which have a strong mobile representation.






Reading anecdotal Nanog mails from a handful of folks concluding ipv6 
has failed will not leave the passive impartial observer with an 
accurate view.


Its incontrovertible that IPv6 has racked up a long list of failures in 
its original objectives, expectations, predictions and timelines, even 
up to this point.


I am not really convinced that IPv4 can be 
ignored/marginalized/obsoleted without penetration reaching over 90%, 
globally. And until that point, IPv6 is an optimization, not a requirement.


Perhaps it will accelerate at some percentage point. But if it drags out 
for another decade or two, all bets are off.



Joe

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[William Herrin]

On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen  wrote:
> 1)Thanks for the reference. However, Informative Reference 7 of our IETF 
> Draft cites another IANA document which puts the initial date of the 240/4 
> topic back to 1981-09 which was much earlier, in fact, coincided with that of 
> RFC 791.

Hi Abraham,

As I said, RFC1112 documents the _most recent_ standards action with
respect to 240/4. The earlier RFC 791 you mention described 224/3
(which included 240/4) as "escape to extended addressing mode" which
it specified as "undefined" and "reserved for future use." RFC 988
then redefined and split 224/3 into "class D" and "class E" addresses,
defined "class D" as multicast and "class E" as reserved for future
use without any particular purpose. This saw updates in RFC1112 which
has the current disposition of "class E" aka 240/4.

RFC 1112 spends a grand total of one sentence on Class E addresses. If
you're looking for more, you won't find it. That one sentence is all
they said.


> 2)My curiosity questions were not about "when" or "how", but "why" and 
> for "whom".

As documented or unambiguously inferred, "why" is because the folks in
the 1980s wanted to hold some addresses aside for uses not then known,
and "for whom" was explicitly undefined.


> Particularly at a time that IPv4 was planned to be "dead" soon, what was its 
> "Future" that deserved to be Reserved for?

As I've said in other postings on the subject, I believe the time has
passed where it was reasonable to expect that a non-unicast use might
be found for 240/4 within the remaining lifetime of the IPv4 protocol.
Nor is there any reason to believe we will need more of another sort
of address such as multicast or broadcast. More, it's well understood
that the network routing and software client behavior for anycast is
identical to unicast, and indeed addresses defined as global unicast
have been routinely allocated to anycast uses. I thus think a
standards action changing 240/4 from "reserved, undefined" to
"reserved, unicast" is justified.

Exactly what unicast use remains a reasonable topic of debate. Such
debate, however, is irrelevant to the hardware and software
implementing it which need only care that the addresses should be
handled in normal unicast routing and termination. Changes to hardware
and software to make use of 240/4 as ordinary unicast IP addresses can
and should proceed in parallel to such debate.

Regards,
Bill Herrin


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

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Ca By]

On Fri, Mar 11, 2022 at 7:15 AM Abraham Y. Chen  wrote:

> Dear Ca By:
>
> 1)It appears that you are reading the Google graph too optimistically,
> or incorrectly. That is, the highest peaks of the graph are about 38%. The
> average of the graph is about 36%. Citing "over 40%" from these is a gross
> exaggeration. In fact, the peaks were reached on weekends and holidays due
> to more residential usage, you can clearly see such by zooming into the
> graph. In addition, the graph has been exhibiting an asymptomatic trend
> ever since a few years back. The COVID-19 pushed this graph up a bit due to
> the lock-down and work-from-home factors. Below was an analysis
> pre-pandemic:
>

Sorry for being imprecise in my communication, the number is 46% in the USA.


>
> https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/
>
> 2)Since Google is one of the stronger IPv6 promoters, usage of IPv6
> outside of the Google domain can only be lower, by simple logic deduction.
>
>
Google’s number represents how many users reach it over ipv6. Given
Google’s ubiquity in the usa, it is a fair barometer for the usa at large.
This data is helpful for content providers  estimating demand for ipv6 (46%
of users will use ipv6 if it is available)  and for the network operator
community to understand where their peers sit.

In summary, there is a lot of ipv6 on the usa internet today. Almost half
for Google, per their published numbers. Over 75% end to end ipv6 on some
large mobile networks.  Hence my appeal to view published data.

Reading anecdotal Nanog mails from a handful of folks concluding ipv6 has
failed will not leave the passive impartial observer with an accurate view.


Regards,
>
>
> Abe (2022-03-11 10:11)
>
>
> --
> NANOG Digest, Vol 170, Issue 12
>
> Message: 12
> Date: Thu, 10 Mar 2022 08:00:17 -0800
> From: Ca By  
> To: Saku Ytti  
> Cc: Joe Greco  , nanog@nanog.org
> Subject: Re: V6 still not supported (was Re: CC: s to Non List Members
>   (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4
>   NetBlock))
> Message-ID:
>
> 
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti   wrote:
>
>
> On Wed, 9 Mar 2022 at 21:00, Joe Greco  
>  wrote:
>
>
> I really never thought it'd be 2022 and my networks would be still
> heavily v4.  Mind boggling.
>
> Same. And if we don't voluntarily agree to do something to it, it'll
> be the same in 2042, we fucked up and those who come after us pay the
> price of the insane amount of work and cost dual stack causes.
>
> It is solvable, easily and cheaply, like most problems (energy,
> climate), but not when so many poor leaders participate in decision
> making.
>
> --
>   ++ytti
>
> Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is
> on ipv6 (all your smartphone, many of your home router, a growing amount of
> your clouds [i see you aws])
> https://www.worldipv6launch.org/measurements/
>
> Google sees over 40% of their users on ipv6, with superior latency
> https://www.google.com/intl/en/ipv6/statistics.html
>
>
>  -- next part --
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_6390985030485347940_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Re: V6 still not supported (was Re: CC: s to Non List Members, (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4, NetBlock))

[Abraham Y. Chen]

Dear Ca By:

1)    It appears that you are reading the Google graph too 
optimistically, or incorrectly. That is, the highest peaks of the graph 
are about 38%. The average of the graph is about 36%. Citing "over 40%" 
from these is a gross exaggeration. In fact, the peaks were reached on 
weekends and holidays due to more residential usage, you can clearly see 
such by zooming into the graph. In addition, the graph has been 
exhibiting an asymptomatic trend ever since a few years back. The 
COVID-19 pushed this graph up a bit due to the lock-down and 
work-from-home factors. Below was an analysis pre-pandemic:


https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/

2)    Since Google is one of the stronger IPv6 promoters, usage of IPv6 
outside of the Google domain can only be lower, by simple logic deduction.



Regards,


Abe (2022-03-11 10:11)


--
NANOG Digest, Vol 170, Issue 12

Message: 12
Date: Thu, 10 Mar 2022 08:00:17 -0800
From: Ca By
To: Saku Ytti
Cc: Joe Greco,nanog@nanog.org
Subject: Re: V6 still not supported (was Re: CC: s to Non List Members
(was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4
NetBlock))
Message-ID:

Content-Type: text/plain; charset="utf-8"

On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti  wrote:


On Wed, 9 Mar 2022 at 21:00, Joe Greco  wrote:


I really never thought it'd be 2022 and my networks would be still
heavily v4.  Mind boggling.

Same. And if we don't voluntarily agree to do something to it, it'll
be the same in 2042, we fucked up and those who come after us pay the
price of the insane amount of work and cost dual stack causes.

It is solvable, easily and cheaply, like most problems (energy,
climate), but not when so many poor leaders participate in decision
making.

--
   ++ytti


Ah, the quarterly ipv6 thread? where i remind you all? most of the USA is
on ipv6 (all your smartphone, many of your home router, a growing amount of
your clouds [i see you aws])

https://www.worldipv6launch.org/measurements/

Google sees over 40% of their users on ipv6, with superior latency

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



-- next part --


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

Re: The role of Internet governance in sanctions

[Mel Beckman]

Sylvain,

Thank you for posting this plausible scenario. It is this kind of bad effect 
that I’m concerned about.

Consider also that the document doesn’t specify government specifically, only 
“agencies“, without defining what those are. I think it’s quite possible that a 
future operational team might decide that particular political party is an 
agency requiring sanctions.

-mel via cell

On Mar 11, 2022, at 6:21 AM, Sylvain Baya  wrote:

Dear NANOG-ers,
Hope this email finds you in good health!

Please see my comments below, inline...

Le vendredi 11 mars 2022, Brandon Price 
mailto:pri...@sherwoodoregon.gov>> a écrit :


-Original Message-
From: NANOG 
mailto:sherwoodoregon@nanog.org>>
 On Behalf Of Bill Woodcock
Sent: Thursday, March 10, 2022 11:37 AM
To: nanog@nanog.org
Subject: Re: The role of Internet governance in sanctions




>Perhaps not.  My goal is to minimize Internet disconnection.  Maybe that’s not 
>your goal.  I was trying to give what you wrote the most generous possible 
>interpretation.

There is no realistic way for these disconnects to happen now, as acknowledged 
by the fifth principal in the draft. How does creating a framework to 
accomplish this do anything other than increase the disconnects?


Hi Brandon,

Thanks for your email, brother!

You put forward a good objection for this proposal.

...i think the proposal is a wise idea, but imho it can
 not touch the root-causes of the problem at hand.

It seems to be the same approach as the anti-shutdown
 DPP (Draft Policy Proposal) [1].
__
[1]: 

Applying sanctions to a country has side effects... :'-(

To figure it out, one should look at the below scenario:

~°~
1] This draft proposal reaches a rough consensus
2] A selection is done to build the Operational Team (OT)
3] The OT agrees on a rough consensus on the
decision to apply specific sanctions on a given
country government's Internet infrastructure used
to spread their "propaganda" globaly...
4] The OT implements the consensual decision
5] The Internet's infrastructure of that ccGov is
shutdown. No more trafic from it to the Internet!
6] That ccGov decides to cut the rest of the
Internet's interconnexions of their country to the
Internet...
7] The whole country is unreacheable from the Internet
8] That ccGov is the only source of "information"
 within their country boundaries
9] ...
~°~

As the draft proposal seems to target cc Governments,
 practically speaking, then what if the policy-decision
 to be implemented concerns the usGov?

Thanks.

Shalom,
--sb.



Brandon


--

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous 
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après 
TOI, ô DIEU!»(#Psaumes42:2)

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Abraham Y. Chen]

Hi, Bill:

1)    Thanks for the reference. However, Informative Reference 7 of our 
IETF Draft cites another IANA document which puts the initial date of 
the 240/4 topic back to 1981-09 which was much earlier, in fact, 
coincided with that of RFC 791.


2)    My curiosity questions were not about "when" or "how", but "why" 
and for "whom". Particularly at a time that IPv4 was planned to be 
"dead" soon, what was its "Future" that deserved to be Reserved for?


Regards,


Abe (2022-03-11 09:36)



On 2022-03-10 23:16, William Herrin wrote:

On Thu, Mar 10, 2022 at 7:51 PM Abraham Y. Chen  wrote:

1)" ...  should be ...  ":Instead of "hand wave", this is a diplomatic 
expression to challenge the software engineers' knowledge of the networking program code for the 
current case. Ever since we started our study, we were quite puzzled by why the 240/4 netblock was 
regarded so special? Why no one could tell us what led to its current status, and even after IPv4 
was set to transition to IPv6?

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Which leads to RFC 1112 section 4, the disposition of which last
changed in 1989.

You are now informed about its current status along with when and how
it got to be that way.

Regards,
Bill Herrin






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

The role of Internet governance in sanctions

[Sylvain Baya]

Dear NANOG-ers,
Hope this email finds you in good health!

Please see my comments below, inline...

Le vendredi 11 mars 2022, Brandon Price  a
écrit :

>
>
> -Original Message-
> From: NANOG  On Behalf
> Of Bill Woodcock
> Sent: Thursday, March 10, 2022 11:37 AM
> To: nanog@nanog.org
> Subject: Re: The role of Internet governance in sanctions
>
>
>
>
> >Perhaps not.  My goal is to minimize Internet disconnection.  Maybe
> that’s not your goal.  I was trying to give what you wrote the most
> generous possible interpretation.
>
> There is no realistic way for these disconnects to happen now, as
> acknowledged by the fifth principal in the draft. How does creating a
> framework to accomplish this do anything other than increase the
> disconnects?
>
>
Hi Brandon,

Thanks for your email, brother!

You put forward a good objection for this proposal.

...i think the proposal is a wise idea, but imho it can
 not touch the root-causes of the problem at hand.

It seems to be the same approach as the anti-shutdown
 DPP (Draft Policy Proposal) [1].
__
[1]: 

Applying sanctions to a country has side effects... :'-(

To figure it out, one should look at the below scenario:

~°~
1] This draft proposal reaches a rough consensus
2] A selection is done to build the Operational Team (OT)
3] The OT agrees on a rough consensus on the
decision to apply specific sanctions on a given
country government's Internet infrastructure used
to spread their "propaganda" globaly...
4] The OT implements the consensual decision
5] The Internet's infrastructure of that ccGov is
shutdown. No more trafic from it to the Internet!
6] That ccGov decides to cut the rest of the
Internet's interconnexions of their country to the
Internet...
7] The whole country is unreacheable from the Internet
8] That ccGov is the only source of "information"
 within their country boundaries
9] ...
~°~

As the draft proposal seems to target cc Governments,
 practically speaking, then what if the policy-decision
 to be implemented concerns the usGov?

Thanks.

Shalom,
--sb.



>
> Brandon
>


-- 

Best Regards !
__
baya.sylvain[AT cmNOG DOT cm]|
Subscribe to Mailing List: 
__
#‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous
tous! ‪#‎Amen‬!»
‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬
«Comme une biche soupire après des courants d’eau, ainsi mon âme soupire
après TOI, ô DIEU!»(#Psaumes42:2)

Re: Asia Apac networks

[Jon Lewis]

More likely a couple hundred ms.  I believe what is being seen is the 
result of Cogent trying to get established in Asia.  They won't pay to 
peer with the established players, and those players don't want Cogent 
disrupting their market, so their peering in Asia is rather poor.  If 
you're successful in forcing traffic from networks on NTT or other "Asian 
service providers" to ingress on your Cogent port, you're not going to 
like the result, as that traffic will take the scenic route via the west 
coast US or possibly Europe (twice) before reaching you.


As an NTT customer, perhaps Edvinas should complain to NTT about their 
lack of peering [in Asia] with Cogent making it difficult to utilize your 
Cogent port.  Of course, that's intentional on NTT's part...so they're 
unlikely to care about your complaint.



On Fri, 11 Mar 2022, Siyuan Miao wrote:


Cogent didn't peer with NTT and PCCW in Asia so it's normal if they still 
prefer local routes. Otherwise
the latency might be at least 100ms.

On Fri, Mar 11, 2022 at 12:50 Lady Benjamin Cannon of Glencoe, ASCE 
 wrote:
  This sort of thing in general is not uncommon in my experience.  Many 
networks weight our
  outbound with local preferences.

  Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
  6x7 Networks & 6x7 Telecom, LLC
  CEO
  l...@6by7.net
  "The only fully end-to-end encrypted global telecommunications company in 
the world.”

  FCC License KJ6FJJ

  Sent from my iPhone via RFC1149.

  > On Mar 9, 2022, at 2:30 AM, Edvinas Kairys  
wrote:
  >
  >
  >   Hello,
  >
  > We've introduced Cogent network in Equinix Honk Kong DC. But seems via 
that link we're just
  receiving just only 5% of our traffic, other part of incoming traffic is 
received via our other
  ISPs like NTT, Simcentrc, and Equinix IXP.
  > I know it's very naïve to expect the traffic load balance equally 
between 3 ISPs (4 if IXP is
  counted) using just one /24 subnet. According to most of BGP looking 
glasses in Asia, traffic
  via Cogent is least preferred even when i've added 6x prepend AS on our 
other mentioned
  providers to make route via Cogent more attractive. But nothing helps - 
seems main providers in
  Asia made routes via Cogent least preferable by lowering the local 
preference to it, that why
  prepending from our side doesn't help.
  >
  > Maybe someone has experience or similar problems with ISPs in Asia 
network ?
  >
  >





--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_