- NANOG - lists.nanog.org

Proper Planning for Cellular Networks in Ukraine
by Sean Donelan 01 Apr '22

01 Apr '22

Whether its preparing for a natural disaster like a hurricane or a russian invasion, proper advance planning makes a difference. The cellular network operators and national regulator in Ukraine have been preparing for years. "It must be kept in mind, that many of these changes could not have taken place over-night, that they are the culmination of months, and in some cases years of preparation." The Mobile Network Battlefield in Ukraine - Part 1 https://blog.adaptivemobile.com/the-mobile-network-battlefield-in-ukraine-p… The Mobile Network Battlefield in Ukraine - Part 2 https://blog.adaptivemobile.com/the-mobile-network-battlefield-in-ukraine-p… "Finally, one unusual perspective that has been taken by some observers, in trying to explain why Ukrainian Mobile Networks were still functioning after several weeks of war, was to put it all down to decisions made by the Russian forces. [...] We believe that this viewpoint is fundamentally wrong, as the cadence and scope of the decisions made by the Ukrainian Mobile Operators, both before and after the Invasion - as well as their ongoing work to keep them active - show that they are clearly engaged in the fight to keep these networks alive."

1 0

deadly wifi
by William Herrin 01 Apr '22

01 Apr '22

In Venezuela, asking for the wifi password can get you killed. https://www.washingtonpost.com/world/2022/03/31/venezuela-army-yanomami-kil… -- William Herrin bill(a)herrin.us https://bill.herrin.us/

1 0

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Abraham Y. Chen 01 Apr '22

01 Apr '22

Hi, Pascal: What I would appreciate is an IP packet header design/definition layout, word-by-word, ideally in bit-map style, of an explicit presentation of all IP addresses involved from one IoT in one realm to that in the second realm. This will provide a clearer picture of how the real world implementation may look like. Thanks, Abe (2022-04-01 09:48) On 2022-04-01 08:49, Vasilenko Eduard wrote: > > As I understand: “IPv4 Realms” between “Shaft” should be capable to > have a plain IPv4 header (or else why all of these). > > Then Gateway in the Shaft should change headers (from IPv4 to IPv6). > > Who should implement this gateway and why? He should be formally > appointed to such an exercise, right? > > Map this 2 level hierarchy to the real world – you may fail with this. > > Ed/ > > *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > *Sent:* Friday, April 1, 2022 3:41 PM > *To:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com>; Justin Streiner > <streinerj(a)gmail.com>; Abraham Y. Chen <aychen(a)avinta.com> > *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > Hello Eduard: > > Did you just demonstrate that POPs cannot exist? Or that there cannot > be a Default Free Zone? > > I agree with your real world issue that some things will have to be > planned between stake holders, and that it will not be easy. > > But you know what the French say about “impossible”. > > Or to paraphrase Sir Arthur, now that we have eliminated all the > impossible transition scenarios, whatever remains… > > There will be YADA prefixes just like there are root DNS. To be > managed by different players as you point out. And all routable within > the same shaft. > > Keep safe; > > Pascal > > *From:* Vasilenko Eduard <vasilenko.eduard(a)huawei.com> > *Sent:* vendredi 1 avril 2022 14:32 > *To:* Pascal Thubert (pthubert) <pthubert(a)cisco.com>; Justin Streiner > <streinerj(a)gmail.com>; Abraham Y. Chen <aychen(a)avinta.com> > *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > Hi Pascal, > > In general, your idea to create a hierarchy is good. > > In practice, it would fail because you have created a virtual > hierarchy that does not map to any administrative border. Who should > implement gateways for the “Shaft”? Why? > > If you would appoint Carrier as the Shaft responsible then it is not > enough bits for Shaft. > > If you would appoint Governments as the Shaft responsible then would > be a so big scandal that you would regret the proposal. > > Hence, I do not see proper mapping for the hierarchy to make YADA > successful. > > Eduard > > *From:* NANOG > [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org > <mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On > Behalf Of *Pascal Thubert (pthubert) via NANOG > *Sent:* Friday, April 1, 2022 2:26 PM > *To:* Justin Streiner <streinerj(a)gmail.com>; Abraham Y. Chen > <aychen(a)avinta.com> > *Cc:* NANOG <nanog(a)nanog.org> > *Subject:* RE: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > For the sake of it, Justin, I just published > https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/. > > The first section of the draft (YADA) extends IPv4 range in an > IPv4-only world. For some people that might be enough and I’m totally > fine with that. > > Keep safe; > > Pascal > > *From:* NANOG <nanog-bounces+pthubert=cisco.com(a)nanog.org> *On Behalf > Of *Justin Streiner > *Sent:* dimanche 27 mars 2022 18:12 > *To:* Abraham Y. Chen <aychen(a)avinta.com> > *Cc:* NANOG <nanog(a)nanog.org> > *Subject:* Re: Let's Focus on Moving Forward Re: V6 still not > supported re: 202203261833.AYC > > Abe: > > To your first point about denying that anyone is being stopped from > working on IPv4, I'm referring to users being able to communicate via > IPv4. I have seen no evidence of that. > > I'm not familiar with the process of submitting ideas to IETF, so I'll > leave that for others who are more knowledgeable on that to speak up > if they're so inclined. > > Thank you > > jms > > On Sat, Mar 26, 2022 at 6:43 PM Abraham Y. Chen <aychen(a)avinta.com> wrote: > > 1) "... no one is stopping anyone from working on IPv4 ... ": > After all these discussions, are you still denying this basic > issue? For example, there has not been any straightforward way to > introduce IPv4 enhancement ideas to IETF since at least 2015. If > you know the way, please make it public. I am sure that many are > eager to learn about it. Thanks. > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

IPv6 "bloat"
by Michael Thomas 01 Apr '22

01 Apr '22

So out of the current discussions a lot of people have claimed that ipv6 is bloated or suffers from second system syndrome, etc. So I decided to look at a linux kernel (HEAD I assume) and look at the differences between the v6 and v4 directories. I just crudely did a line count as a quick measure: ipv6: 68k lines ipv4: 97k lines ipv4 looks to have the tcp and udp implementations (35k) so backing that out it is about 62k lines. That's pretty comparable. Linux has full routing capability so the kernel implements it for both. So I'm just not getting where this "bloat" is. 10% growth for a second system syndrome seems almost miraculously good, imo. What am i missing? This is in complete agreement with my intuition 30 years ago that it was no big deal, at least from a software standpoint. Mike

10 32

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Abraham Y. Chen 01 Apr '22

01 Apr '22

Hi, Justin: 1) "... no one is stopping anyone from working on IPv4 ... ": After all these discussions, are you still denying this basic issue? For example, there has not been any straightforward way to introduce IPv4 enhancement ideas to IETF since at least 2015. If you know the way, please make it public. I am sure that many are eager to learn about it. Thanks. Regards, Abe (2022-03-26 18:42) On 2022-03-26 11:20, Justin Streiner wrote: > While the Internet is intended to allow the free exchange of > information, the means of getting that information from place to place > is and has to be defined by protocols that are implemented in a > consistent manner (see: BGP, among many other examples). It's > important to separate the ideas from the plumbing. > > That said, no one is stopping anyone from working on IPv4, so what > personal freedoms are being impacted by working toward deploying IPv6, > with an eye toward sunsetting IPv4 in the future? > > Keep in mind that IPv4 started out as an experiment that found its way > into wider use. It's a classic case of a test deployment that > suddenly mutated into a production service. Why should we continue to > expend effort to perpetuate the sins of the past, rather work toward > getting v6 into wider use? > > Is IPv6 a perfect protocol? Absolutely not, but it addresses the key > pain point of IPv4 - address space exhaustion. > > Thank you > jms > > On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen <aychen(a)avinta.com> wrote: > > > 3) Re: Ur. Pts. 5) & 6): I believe that there is a > philosophic / logic baseline that we need to sort out, first. That > is, we must keep in mind that the Internet community strongly > promotes "*/personal freedom/*". Assuming that by stopping others > from working on IPv4 will shift their energy to IPv6 is totally > contradicting such a principle. A project attracts contributors by > its own merits, not by relying on artificial barriers to the > competitions. Based on my best understanding, IPv6 failed right > after the decision of "not emphasizing the backward compatibility > with IPv4". It broke one of the golden rules in the system > engineering discipline. After nearly three decades, still evading > such fact, but defusing IPv6 issues by various tactics is the real > impedance to progress, not only to IPv4 but also to IPv6. > > > > <#m_4226728999263060367_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

9 19

What's a "normal" ratio of web sites to IP addresses...
by Bill Woodcock 01 Apr '22

01 Apr '22

…in a run-of-the-mill web hoster? This is really a question specifically for folks with web-site-hosting businesses. If you had, say, ten million web site customers, each with their own unique domain name, how many IPv4 addresses would you think was a reasonable number to host those on? HTTP name-based virtual-hosting means that you could, hypothetically, pile all ten million into a single IP address. At the other end of the spectrum, you could chew up ten million IPv4 addresses, giving a unique one to each customer. Presumably the actual practice lies somewhere in-between. But what ratio do people in that business think is reasonable? 10:1? 100:1? 1,000:1? I’m happy to take private replies and summarize/anonymize back to the list, if people prefer. Thanks! -Bill

4 4

End of Mariupol's Internet
by Sean Donelan 01 Apr '22

01 Apr '22

The Last Days Of Mariupol’s Internet https://www.forbes.com/sites/thomasbrewster/2022/03/31/the-last-days-of-mar… "Engineers who kept Ukraine’s port city online have gone missing or died in the carnage inflicted by Russia’s siege. Hope remains that Ukrainian cities knocked off the internet map will come back online fast once the shelling ends."

1 0

IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC
by Jacques Latour 01 Apr '22

01 Apr '22

So, in 25, 50 or 100 years from now, are we still going to be dual stack IPv4/IPv6? When are we going to give up on IPv4? People can run IPv4 all they want inside their networks for 1000s of years. What will it take to be IPv6 only? 😊 From: NANOG <nanog-bounces+jacques.latour=cira.ca(a)nanog.org> On Behalf Of Owen DeLong via NANOG Sent: March 29, 2022 3:52 PM To: Abraham Y. Chen <aychen(a)avinta.com> Cc: NANOG <nanog(a)nanog.org> Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC Submit an Internet draft, same as any other IP related enhancement gets introduced. What you’re really complaining about is that it’s been virtually impossible to gain consensus to move anything IPv4 related forward in the IETF since at least 2015. Well… It’s a consensus process. If your idea isn’t getting consensus, then perhaps it’s simply that the group you are seeking consensus from doesn’t like your idea. Your inability to convince the members of the various working groups that your idea has merit isn’t necessarily a defect in the IETF process… It might simply be a lack of merit in your ideas. Owen On Mar 26, 2022, at 15:43 , Abraham Y. Chen <aychen(a)avinta.com<mailto:aychen@avinta.com>> wrote: Hi, Justin: 1) "... no one is stopping anyone from working on IPv4 ... ": After all these discussions, are you still denying this basic issue? For example, there has not been any straightforward way to introduce IPv4 enhancement ideas to IETF since at least 2015. If you know the way, please make it public. I am sure that many are eager to learn about it. Thanks. Regards, Abe (2022-03-26 18:42) On 2022-03-26 11:20, Justin Streiner wrote: While the Internet is intended to allow the free exchange of information, the means of getting that information from place to place is and has to be defined by protocols that are implemented in a consistent manner (see: BGP, among many other examples). It's important to separate the ideas from the plumbing. That said, no one is stopping anyone from working on IPv4, so what personal freedoms are being impacted by working toward deploying IPv6, with an eye toward sunsetting IPv4 in the future? Keep in mind that IPv4 started out as an experiment that found its way into wider use. It's a classic case of a test deployment that suddenly mutated into a production service. Why should we continue to expend effort to perpetuate the sins of the past, rather work toward getting v6 into wider use? Is IPv6 a perfect protocol? Absolutely not, but it addresses the key pain point of IPv4 - address space exhaustion. Thank you jms On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen <aychen(a)avinta.com<mailto:aychen@avinta.com>> wrote: 3) Re: Ur. Pts. 5) & 6): I believe that there is a philosophic / logic baseline that we need to sort out, first. That is, we must keep in mind that the Internet community strongly promotes "personal freedom". Assuming that by stopping others from working on IPv4 will shift their energy to IPv6 is totally contradicting such a principle. A project attracts contributors by its own merits, not by relying on artificial barriers to the competitions. Based on my best understanding, IPv6 failed right after the decision of "not emphasizing the backward compatibility with IPv4". It broke one of the golden rules in the system engineering discipline. After nearly three decades, still evading such fact, but defusing IPv6 issues by various tactics is the real impedance to progress, not only to IPv4 but also to IPv6.

5 5

NANOG 85 Registration is now OPEN! + VIDEO | Internet Innovators
by Nanog News 31 Mar '22

31 Mar '22

VIDEO | New Episode of "Internet Innovators" *Kleinrock Tells His Story + History of the Internet * Kleinrock's story begins on the streets of Harlem, where he credits his ability to see the world "without pretense" and how this ideology has influenced his research. *Watch the full episode to learn more about:* • Leonard's childhood • The day an engineer was born • The historic day where the first message was transmitted • What the first message was, and why • What Leonard would have done differently • Internet 50 Bash • Future predictions for the Internet • What he thinks the Internet still hasn't gotten right • His most recent project: the UCLA Connection Lab • + More *WATCH NOW <https://www.nanog.org/news-stories/nanog-tv/internet-innovators/internet-in…>* NANOG 85 Registration is Now OPEN! *Our 85th Community-Wide gathering is June 6 - 8* *Join us for the next meeting, NANOG 85. * Registration is open for our upcoming meeting, June 6 - 8 in Montréal, Québec. Attendees are welcome to attend in-person + virtually. *REGISTER NOW * <https://www.nanog.org/events/nanog-85/registration/> Safety + Travel for NANOG 85 Your health and safety are very important to us and NANOG is ready to host everyone safely in Montreal. We will require that everyone attending NANOG 85 be fully vaccinated against COVID-19 no later than May 23, 2022. *GUIDELINES <https://www.nanog.org/events/nanog-85/safety-travel/>*

1 0

A few questions regarding about RPKI/invalids
by Drew Weaver 31 Mar '22

31 Mar '22

Hello, We've noticed that there are a number of routes being passed along from 3356 with invalid origin AS. Of those, almost all of them are being passed to 3356 from 3549 (legacy Global Crossing) and there is no valid path available for any of these prefixes (at least according to the ROA). Ex 45.176.191.0/24 3356 3549 11172 270150 RPKI ROA entry for 45.176.191.0/24-24 Origin-AS: 265621 Two questions: First, are you also seeing this on this specific route? Second, is there a certain number of "expected" invalid routes? (not including unknowns) Third, how are you handling specifically the large number of routes from 3356 3549 which invalid origin AS? Are you just "letting the bodies hit the floor"? or are you carving those out somehow? I'm mostly just curious what other members of the community are seeing/doing in regards to this. Thanks, -Drew

5 5