- Test - lists.nanog.org

Dropping support for the .ru top level domain
by Patrick Bryant 15 Mar '22

15 Mar '22

I don't like the idea of disrupting any Internet service. But the current situation is unprecedented. The Achilles Heel of general public use of Internet services has always been the functionality of DNS. Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD can be accomplished without disrupting the Russian population's ability to access information and services in the West. The only countermeasure would be the distribution of Russian national DNS zones to a multiplicity of individual DNS resolvers within Russia. Russian operators are in fact implementing this countermeasure, but it is a slow and arduous process, and it will entail many of the operational difficulties that existed with distributing Host files, which DNS was implemented to overcome. The .ru TLD could be globally disrupted by dropping the .ru zone from the 13 DNS root servers. This would be the most effective action, but would require an authoritative consensus. One level down in DNS delegation are the 5 authoritative servers. I will leave it to the imagination of others to envision what action that could be taken there... ru nameserver = a.dns.ripn.net ru nameserver = b.dns.ripn.net ru nameserver = d.dns.ripn.net ru nameserver = e.dns.ripn.net ru nameserver = f.dns.ripn.net The impact of any action would take time (days) to propagate.

16 20

FCC Foreign SPonsorship Identification Rules Go Into Effect
by Sean Donelan 15 Mar '22

15 Mar '22

https://www.fcc.gov/document/fccs-foreign-sponsorship-identification-rules-… The Federal Communications Commission today announced a March 15, 2022 compliance date of sponsorship identification requirements that will now require broadcasters to disclose when foreign governments or their representatives lease time on their airwaves. This action was adopted unanimously by the FCC in April 2021 and increases transparency, ensuring audiences are aware when a foreign government, or its representatives, uses the airwaves to persuade the American public. These rules are effective immediately for new leasing agreements and will need to be implemented within 6 months from the Federal Register publication date for existing agreements.

1 0

Viaplay wrongly classifies IP as VPN
by Jimmy Huijbrechts 15 Mar '22

15 Mar '22

*cHi All,* I'm wondering if anyone here could help me out in reaching someone at Viaplay, we have customers that rent a internet connection from us as an ISP and are getting a message when trying to start something that they are behind a VPN, even at the office I have the issue (we are behind our own network too) so it seems they've classified at least some of our IP blocks wrongly. I tried contacting them on Twitter, Facebook messenger and their own webchat but all I get is we are currently business and it takes longer than usual to answer but until now no answers to any of them. Would like to get this solved pretty much. Best regards, Jimmy

1 0

Geolocation Data : MAX MIND - Out of Sync
by Paschal Masha 14 Mar '22

14 Mar '22

Hello, Not sure whether anyone out there is also experiencing this, seems MAX MIND ( [ https://www.maxmind.com/en/geoip2-precision-demo | https://www.maxmind.com/en/geoip2-precision-demo ] ) geo database is extremely out of sync with whois records on RIRs DBs. It's ok(not 100%) to submit corrections for a few(if not less than few) blocks, but getting it all wrong for more that 4 to many blocks- that's a big deal..especially when other services( like, whatsmyip), believe you more that other DBs e.g 102.217.58.0/24 an AFRNIC allocation, appears in Turkey on MAX MIND, while ip2location and other geoDBs correctly displays this. IS there anyone- with power- from MAX MIND in this list that can help out? Please contact me offlist - sorry for the broadcast to the other members. Regards Paschal Masha | Engineering Skype ID: paschal.masha

9 9

Re: V6 still not supported (was Re: CC: s to Non List, Members, (was Making Use of 240/4, NetBlock))
by Abraham Y. Chen 14 Mar '22

14 Mar '22

Hi, Fred: 0) Thanks for sharing your references to IPv6 statistics. 1) However, you might have looked this topic too deeply and missed the overview. Through our study of EzIP, we have discovered two aspects of this topic that frequently mislead readers: A. IPv6 equipment */Capability/* vs. IPv6 traffic */Volume/*: The former is about equipment "readiness". The latter is about the actual traffic "amount". High value of the former does not necessarily imply the same to the latter. Without explicitly stating which one is being presented, wasteful debates based on these numbers persist. In fact, this is where the big smoke screen that our team had to go through to finally see more clearly about the true reference that we have to base upon. B. The scope of the candidates for the source data set: Comparisons of the incident type needs to find the largest domain, not several sub-domains, to extract data from. This is important because an author can pick up a few datasets that support the "theory", while overlooking others that may be more significant and introduce counter views. This is also tricky, because how can one tell which type of domain is bigger than the others? Since we are discussing a global event, any domain that implies worldwide coverage is much more trustworthy than multiple full datasets, each is country-based . 2) Although all of your citations contain "IPv6", some even include "status", none of them clearly defines which one of the two choices in Pt. 1) A. it is referring to. Except, the browser tab of the following reads "IPv6 */Capability/* Metrics". This confirms, at least to me, that you have been looking at Capabilities instead of Volume. The former tends to show much higher numbers because it is just a report of how many devices online are ready to use IPv6 (I heard that such indication is carried in the IP packet somewhere?). This is because when users actually use IPv6, it then contributes to the Volume statistics. https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN 3) Allow me to share with you the IPv6 statistics that we have been following. On top of the two criteria in Pt. 1) above, we also look for consistency through time, i.e., track records such as how long and how frequently the data is updated. A. IPv6 Deployment / Readiness: The following has been updated every few days for quite sometime. Whatever metrics that it is based upon, we can assume that it is applied worldwide. This appears to be a superset of what you cited. https://stats.labs.apnic.net/ipv6/ B. IPv6 Traffic Volume: There was an annual report series by Cisco. But, the last one was in 2017. We could not find any later versions. Interestingly, Cisco TechSupport confirmed so. https://cloud.report/Resources/Whitepapers/eea79d9b-9fe3-4018-86c6-3d1df813… 4) These days, we primarily monitor the following two statistics to keep up with the IPv6 performance status: A. Google IPv6 Adoption: This is a daily report that goes back to 2008 Oct. The current peak is around 38%, while the average is around 36%. Also, a very interesting phenomenon can be observed if you zoom into a small segment of the graph. It shows the weekly fluctuations that peak during weekends or holidays when users are mostly accessing Google services from homes. In fact, the lock-down during the COVID-19 pandemic pushed the average up notably. Although this is only within Google, it is a worldwide statistics. More importantly, Google is one of the stronger IPv6 promoters. Similar statistics from other business should logically be capped by this graph. https://www.google.com/intl/en/ipv6/statistics.html B. AMS-IX Traffic Statistics: There are various measurements that are constantly (between every 7 to 15 minutes) updated. The URL below leads you to a set of composite graphs showing the percentages of various type of protocols being transported through AMS-IX. What you will find in the below graph is that IPv6 Traffic is only around 4.5% which is in the 10% range of that in the Google graph above. https://stats.ams-ix.net/sflow/ether_type.html 5) Pt. 4) B. is a surprise statistics. We have not been able to pin-point exactly how could this happen. Two factors should be kept in mind: A. AMS-IX may not be the largest IX (Internet eXchange), but their operation is worldwide. They are the only business of this kind that has been providing the continuous reports (This kind of reports have been going on for ages. AMS-IX does not provide archived data. But, you can search Archive.org for historical data as far back as 2010-06.). So, we believe that this is more reliable than others. B. IX businesses take the overflow traffic from Internet backbone carriers' peering arrangements. So, the ratio between IPv4 and IPv6 could be different from the bulk in the core. However, one historical event (see URL below) hints that the IPv6 traffic on AMS-IX should have been even lower than what is reported if its peering agreements had been settled in a similar manner as those for IPv4. https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/ Hope this run-down of background and history enable us to synchronize our perspective of the IPv6 status. Regards, Abe (2022-03-14 14:04) ------------------------------ NANOG Digest, Vol 170, Issue 15 Message: 15 Date: Sun, 13 Mar 2022 21:06:51 -0700 From: Fred Baker<fredbaker.ietf(a)gmail.com> To: Joe Maimon<jmaimon(a)jmaimon.com>, "Chen, Abraham Y." <AYChen(a)alum.mit.edu>, "Abraham Y. Chen"<aychen(a)avinta.com>, Ca By <cb.list6(a)gmail.com> Cc: NANOG<nanog(a)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:<7E0B159F-43AC-4507-8FB9-3120B2B9046A(a)gmail.com> Content-Type: text/plain; charset=us-ascii > On Mar 11, 2022, at 8:39 AM, Joe Maimon<jmaimon(a)jmaimon.com> wrote: > > Google's statistics... I'm not sure which of you I'm replying to. The comment was made on NANOG the other day that we should discount Google statistics because they have been promoting IPv6 for a decade. It's true that they have been doing so. But they aren't the only people with statistics. https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=in,my,sa,b… You might look at the following links. Eric Vyncke has been putting up charts basically on Google, Akamai, and APNIC statistics for a while. One thing to consider is that around 90 countries (92 in this capture, as low as 89 a couple of days ago) have 5% or greater response rate using IPv6. Google and Akamai have their own content networks, and in at least some countries only externalize AAAA records or respond to IPv6 requests. APNI isn't that way; they don't operate a content network, but rather accept traffic from across the backbone. Consider that a content network essentially reports traffic from a customer network to their first hop ISP, while when APNIC reports an IPv6 access, the father form APNIC to the collector in question has to include every network and every router in the path. Now look at these: https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=in https://www.vyncke.org/ipv6status/compare.php?metric=k&countries=in https://stats.labs.apnic.net/ipv6/CC?x=1&s=1&p=1&w=30&c=IN I think the APNIC numbers demonstrate that paths through the backbone generally support IPv6 end to end, and that from a routing perspective there is no reason to favor IPv4. There are 8 Countries (this evening) that Google reports roughly equal response rates from using IPv4 or IPv6. cfhttps://www.vyncke.org/ipv6status/compare.php?metric=p&countries=in,my,sa…. This doesn't prove that IPv6 has taken over the world, but it does prove that those who would discount available statistics sources are a little too shrill in doing so. Where IPv6 has a problem today is with enterprise. IMHO, this is basically because enterprise is looking at the bottom line. If ISPs were to do what Mythic Beasts says they do, which is charge their users for address space, IPv6 is virtually free while IPv4 costs something. I suspect that enterprise would change its tune dramatically. ------------------------------ -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Docusign
by Bruno Vane 14 Mar '22

14 Mar '22

Hello, Anyone from Docusign here?

4 3

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))
by Abraham Y. Chen 14 Mar '22

14 Mar '22

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_… 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<cb.list6(a)gmail.com> To: Saku Ytti<saku(a)ytti.fi> Cc: Joe Greco<jgreco(a)ns.sol.net>,nanog(a)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: <CAD6AjGTyQT-OMq_KXxFe-sozWq3mSJ5gC_tKswdpJpi7mMEwFQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Wed, Mar 9, 2022 at 11:56 PM Saku Ytti<saku(a)ytti.fi> wrote: > On Wed, 9 Mar 2022 at 21:00, Joe Greco<jgreco(a)ns.sol.net> 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

11 12

Re: Making Use of 240/4 NetBlock Re: 202203140004.AYC
by Abraham Y. Chen 14 Mar '22

14 Mar '22

Hi, John: 0) Thanks for your comments. 1) Re: Ur. Pt. 1): I have recently been informed of such activities. So far, my attempt to submit a draft and to reach the group chairs have not been successful. 2) Re: Ur. Pt. 2): Our work looks very much inline with your Unicast project. My quick reaction is that EzIP appears to be a practical application that can benefit from your proposal. Although we further limit the application of 240/4 netblock to be "on-premises" (from the Internet core's perspective) use, the scheme of the EzIP deployment actually makes the scope bigger. Since I am not very familiar with the terminologies, does this interpretation make any sense? Please comment. Regards, Abe (2022-03-14 00:22) On 2022-03-12 23:26, John Gilmore wrote: > Abraham Y. Chen<aychen(a)avinta.com> wrote: >> 1) Thanks for confirming my understanding of the 240/4 history. >> Basically, those in charge of the Internet appear to be leaving the >> community in the state of informal debates, since there is no more >> formal IPv4 working group. > There is one; it's called "intarea" and is a working group of the IETF. > >> 2) On the other hand, there was a recent APNIC blog that specifically >> reminded us of a fairly formal request for re-designating the 240/4 >> netblock back in 2008 (second grey background box). To me, this means >> whether to change the 240/4 status is not an issue. The question is >> whether we can identify an application that can maximize its impact. >> >> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/ > Please read our recent Internet-Draft on the subject: > > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > In section 2, you will find references to all the previous allocations > (and requests for allocation) of the 240/4 address block. > > John -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Making Use of 240/4 NetBlock
by Abraham Y. Chen 13 Mar '22

13 Mar '22

Hi, Jordi: 1) " ... Because it is a single Internet, and what we do in some parts of Internet will affect others? ... ": The nice thing about the EzIP scheme is that it proposes a collection of overlay network modules (the RAN - Regional Area Network), each is tethered from the existing Internet core via one IPv4 public address as the umbilical cord which isolates the two, except exchanging IP packets conforming to the established Internet protocol. So, EzIP essentially proposes to create a parallel cyberspace practically independent of the current one. There should be no concern about interfering each other. 2) " ... many previous unsuccessful discussions at IETF about 240/4: ... ": Perhaps I am from the old engineer school, I was inspired by a street legend that, After Thomas Edison tried over one thousand types of material to replace the lead-acid battery, people with conventional wisdom declared that he had failed one thousand times. Edison responded by saying that "I now know there are at least one thousand types of material that can not replace the lead-acid battery. The moral of the story is that after one century, we are now beginning to use Lithium based battery which by itself went through tremendous amount of R&D efforts. So, I highly respect those who focus on alternative possibilities, instead of those regurgitating on unsuccessful discussions of proposals, let alone those avoid studying the root cause of the failed experiments. Regards, Abe (2022-03-13 21:45) ------------------------------ NANOG Digest, Vol 170, Issue 13 Message: 23 Date: Sat, 12 Mar 2022 09:21:01 +0100 From: JORDI PALET MARTINEZ<jordi.palet(a)consulintel.es> To: North American Network Operators' Group<nanog(a)nanog.org> Subject: Re: Making Use of 240/4 NetBlock Message-ID:<BE38196A-ABE8-4445-BF65-CB3E02B8C343(a)consulintel.es> Content-Type: text/plain; charset="UTF-8" Because it is a single Internet, and what we do in some parts of Internet will affect others? Because, at least in my case, I'm investing my efforts in what it seems to be the best in the long-term for the global community, not my personal preferences? ?El 12/3/22 9:10, "William Herrin"<bill(a)herrin.us> escribi?: On Fri, Mar 11, 2022 at 11:58 PM JORDI PALET MARTINEZ via NANOG <nanog(a)nanog.org> wrote: > 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. Why are so many otherwise smart engineers so vulnerable to false dilemma style fallacies? There's no "either/or" here. It's not a zero sum game. If you don't see value in doing more with IPv4 then why don't you get out of the way of folks who do? Regards, Bill Herrin -- William Herrin bill(a)herrin.us https://bill.herrin.us/ ********************************************** -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Cogent cutting links to Russia?
by Michael Thomas 11 Mar '22

11 Mar '22

I know the link is paywalled, but it's super high level so not much is lost. But what does everybody think of this? I imagine that just Cogent cutting them off isn't going to make much difference. https://www.washingtonpost.com/technology/2022/03/04/russia-ukraine-interne… Mike

22 34