- NANOG - lists.nanog.org

Regarding BGP offloading
by Anurag Bhatia 17 Mar '22

17 Mar '22

Hello NANOG! I have seen limited talks about offloading of BGP as a whole into containers/VMs etc. Take e.g this old Google blog post <https://www.blog.google/products/google-cloud/making-google-cloud-faster-mo…> from 2017. Quoting from that: *Second, we separate the logic and control of traffic management from the > confines of individual router “boxes.” Rather than relying on thousands of > individual routers to manage and learn from packet streams, we push the > functionality to a distributed system that extracts the aggregate > information. We leverage our large-scale computing infrastructure and > signals from the application itself to learn how individual flows are > performing, as determined by the end user’s perception of quality.* If I am reading this correctly, it gives an impression of just BGP signalling offload (to VMs/containers...). Is that understanding correct? Speaking from network topology wise anyone here has an idea or could point to a resource on how it is actually achieved? If the frontend device simply starts passing TCP 179 requests to some backend server running say bird, frr etc, how will that information be passed back to the forwarding plane? Are there more public deployments of this sort of setup where BGP as a whole (that is sessions, route calculation, policies, filtering etc) is offloaded to some x86 device in the backend? Or am I just reading it wrong and it's actually smaller VM/containers will full router functionality and BGP alone is not being offloaded? So the logical L3 endpoint here is VMs? What sort of config the device sitting in frontend would have at the interface level to achieve that? Appreciate your responses! Thanks. -- Anurag Bhatia anuragbhatia.com

3 3

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

16 Mar '22

Dear Seth: 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? ... etc. We also could not find anyone who could describe to us how was it being handled in the existing programs. This included those who claimed to be experts in the subject. Perhaps they intentionally tried to hide the detail, or they also did not know? One day, we finally came across a program fragment that could perform the "disabling 240/4 netblock" function. Upon presenting it to an acquaintance knowledgeable of networking programs, he confirmed that it was one concise technique to do the job. That was sufficient for our purpose as system engineers, because we should not overstep our duties by doing software engineer's programing task. That is, as long as we can demonstrate that "there exists" a solution, like proofing a mathematics theorem, we have completed our part of the deal. 2) " ... discussed to death many times over ... ": This was what we were told when we first looked into this subject over half a dozen years ago, and more times along the way. As long as there was an issue not resolved, however, every angle should be continuously explored. In science and engineering, if we stopped studying, because of this kind of viewpoint, we would have missed a lot of inventions and discoveries. So, this particular consideration is not in our books. Regards, Abe (2022-03-10 22:49 EST) ------------------------------ NANOG Digest, Vol 170, Issue 11 Message: 10 Date: Wed, 9 Mar 2022 10:29:22 -0800 From: Seth Mattinen<sethm(a)rollernet.us> To:nanog@nanog.org Subject: Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock Message-ID:<0c6c8b63-6e84-92da-2e28-89b2b5c6d639(a)rollernet.us> Content-Type: text/plain; charset=UTF-8; format=flowed On 3/7/22 2:14 PM, Abraham Y. Chen wrote: > The cost of this software engineering should be minimal. So basically no solution is offered to what is the showstopper for this proposal, only a hand wave that it "should be" easy to fix (but that's everyone else's problem). I mean, I believe this has been discussed to death many times over in the past and yet here we still are. ------------------------------ -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

16 29

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

16 Mar '22

Hi, Mark: 1) Re: Ur. Pt. 1) " ISE != IETF. ... ": On a public forum like NANOG, it is much more expeditious to provide forward guidance than reciting past failures, especially those of a third party due to improper system setup. 2) Re: Ur. Pt. 2) " So replace every CPE device, including ... ": It is evident that you even did not glance at the EzIP Draft Abstract before commenting, but just relying on your recollection of the past 240/4 efforts. Please spend a minute or two on reading the EzIP Abstract. In particular, please look for a keyword "overlay". Hint, this was not our invention. It was a concise characterization by an authoritative Internet figure. So, we imported it into our latest IETF draft update. Hopefully, this keyword will steer your opinion on EzIP. Regards, Abe (2022-03-16 10:49) ------------------------------ NANOG Digest, Vol 170, Issue 18 Message: 42 Date: Wed, 16 Mar 2022 13:04:01 +1100 From: Mark Andrews <marka(a)isc.org> To: "Abraham Y. Chen" <aychen(a)avinta.com> Cc: Tom Beecher <beecher(a)beecher.cc>, "Chen, Abraham Y." <AYChen(a)alum.mit.edu>, NANOG <nanog(a)nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC Message-ID: <DB491106-7130-41B0-8EFA-3C4461E4D06F(a)isc.org> Content-Type: text/plain; charset=utf-8 > On 16 Mar 2022, at 07:27, Abraham Y. Chen<aychen(a)avinta.com> wrote: > > Hi, Tom: > > 1) " .... better to have that conversation via the appropriate IETF channels. ": Thanks for the recommendation. I would appreciate very much if you could guide us to the specific contact. Before we attempt to do so, however, it would be prudent to report the history of our team's experience: > > A. The first IETF Draft on EzIP Project started from 2016-12 as instructed by the ISE (Independent Submission Editor). Although, at that time Working Group SunSet4 had been in session for awhile. But, we were not aware of, nor being informed about such. ISE != IETF. There is no responsible AD assigned so this is not classed as IETF work. For ISE work to become IETF work you need to convince a AD to sponsor the work. https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/ > B. In Summer of 2018, we discovered that SunSet4 had Concluded. We contacted the person in charge of keeping an eye on possible future IPv4 activities, but did not receive any instruction to revise our course. > > C. Recently, we were made aware of the Int-Area activities. Attempts to reach the Group Chairs have not received any responses. > > D. I just received an Int-Area Digest Vol 199, Issue 14 requesting IETF to reactivate the IPv4 support. Firstly nobody uses mailing list digests as references. Secondly anyone can post to the mailing list, you just need to subscribe. If you read the thread you can see there is no interest in this. https://mailarchive.ietf.org/arch/msg/int-area/iZnR1Dkomu4D8AfHTI2xR_npJ8Y/ > Hope you can help us to close the loose ends. > > 2) In the meantime, we realized that the simplest implementation of the EzIP proposal is to replace the 100.64/10 netblock used by CG-NAT with the 240/4 netblock. Next, taking advantage of the much larger address pool to begin practicing static address assignment related disciplines, a "packetized PSTN" is realized. From such a base, the EzIP powered CG-NAT behaving as an overlay network in parallel to the existing Internet for providing the same services, many of the drawbacks in the latter are mitigated! So, we decided to discuss the EzIP proposal directly with the NANOG colleagues, because the EzIP deployment can actually be rather stealthy. So replace every CPE device, including the ones you don?t own, to support 240/4 then later replace every CPE device again or replace every CPE device with one that supports the IPv4aaS you have chosen to use and switch to IPv6-only between the ISP and the CPE and get IPv6 delivered to your customers. Lots of ISP?s have already gone to DS-Lite or 464XLAT, to name two IPv4aaS methods, to provide their clients access to the legacy IPv4 internet over IPv6-only links. Note nothing prevents there being a mixture of dual stack and IPv6-only clients on the same access network hardware. Remember even using these addresses as a replacement for 100.64/10 requires every device behind the CPE to also support 240/4 or any traffic emitted from these addresses is subject to be discarded. > I look forward to your thoughts. > > Regards, > > > Abe (2022-03-15 16:26) > > > > On 2022-03-14 14:48, Tom Beecher wrote: >> If you want to garner discussion or support for your draft RFC, it's probably better to have that conversation via the appropriate IETF channels. >> >> On Mon, Mar 14, 2022 at 2:43 PM Abraham Y. Chen<aychen(a)avinta.com> wrote: >> Hi, Fred: >> >> 0) Thank you for a set of references. >> >> 1) We cited only one IETF Draft (Wilson, et al.) among them, because it was the first and only one that clearly stated its limitation (Section 2. Caveats of Use). More importantly, it was written by three top APNIC officials. Later efforts on this topic have not introduced (based on my reading) any more essence to the topic. >> >> 2) "... I was there for those discussions, and I'm not sure how to put it more simply.... ": With your knowledge of the past, you are uniquely qualified to critique on our work. However, it would be more expedient for everyone, if you could first read through at least the Abstract and the Conclusions of the EzIP IETF Draft, before commenting. This is because EzIP proposal is based on the same general idea as the references you cited, but with a slight extra step that produced a series of surprising results. In particular, we took the "Caveats" above to our hearts before proceeding. So, please put such issues behind you while reviewing our work. Thanks, >> >> Regards, >> >> >> >> Abe (2022-03-14 14:39) >> >> >> >> >> >> ------------------------------ >> NANOG Digest, Vol 170, Issue 15 >> Message: 17 -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Sprint contact - stop bgp announcement
by Elvis Daniel Velea 16 Mar '22

16 Mar '22

Hi, I am looking for a Sprint/T-mobile contact that can help stop the bgp announcement of 45.158.132.0/22 from AS1239. If questions, please contact me offlist. Thank you, Elvis

2 1

Bombs and Hackers are Battering Ukraine's Internet Providers
by Sean Donelan 15 Mar '22

15 Mar '22

https://www.forbes.com/sites/thomasbrewster/2022/03/15/internet-technicians… Images sent to Forbes by Kyivstar show what the conditions are like. Despite obliterated terrain and internet wires, fire-blackened data centers, curfews, lack of light, and the danger of death from above, the fixers go out and turn the internet back on so Ukrainians can stay in touch with one another and get word out beyond borders, to illuminate for the world the darkness that’s descended on their nation. Their government calls them the “invisible heroes” of the war, entering dangerous places to replace and upgrade equipment. [...] Satellite outage caused 'huge loss in communications' at war's outset -Ukrainian official https://www.reuters.com/world/satellite-outage-caused-huge-loss-communicati… A senior Ukrainian cybersecurity official said that the digital sabotage that hit Viasat's KA-SAT network last month caused a massive communications outage at the outset of Russia's invasion. Speaking to journalists on Tuesday, Victor Zhora said he could not reveal much about the incident, which crippled tens of thousands of satellite modems across Europe on the morning of Feb. 24, just as Russian armor pushed into Ukraine. [...] New narrative forms on Russia-Ukraine cyberwar as Viasat outage investigated https://www.scmagazine.com/analysis/cyberespionage/new-narrative-forms-on-r… Gen. Paul Nakasone, head of the National Security Agency, issued what retroactively seems like a carefully worded answer at a Senate hearing to a question about the relative lack of cyberwarfare during the war in Ukraine, saying that the U.S. was aware of "three or four" cyberattacks in Ukraine. He did not mention which attacks those were, though three or four candidates other than Viasat were already known to the public.

4 3

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