- NANOG - lists.nanog.org

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

PoE, Comcast Modems, and Service Outages
by Aaron de Bruyn 31 Mar '22

31 Mar '22

I just got off the phone with a Comcast tech, and wanted to double-check my sanity. Somehow in the last 6 months I've managed to reach the exact same rep twice when dealing with an outage or a degraded service event. I asked him to remotely reboot the modem because there was high packet loss. Both times I've talked with him, he noted the high packet loss, started to reboot the modem, and then asked me point-blank if we had any PoE switches on our network. When I said "yes", he said I needed to disable PoE because it messes with the Comcast modems and he can see "buildups" in his graphs that show power is "leaking" to the Comcast modem every 24 hours. For reference, our setup is: Internal Network ←→ PoE Switch ←→ My Router (FreeBSD Box) ←→ Comcast Modem I told him the Comcast modem isn't plugged into the PoE Switch, it's plugged into My Router (FreeBSD box) and My Router does not negotiate PoE+ and the switch shows PoE isn't being send to My Router's LAN port. While the switch is capable of outputting old-school 24v PoE, it must be specifically turned on for a port, and it's not enabled or used anywhere on the networks I manage. When provided with that information, the Comcast tech still insisted that the switch was sending PoE to My Router and it was "leaking through" to the Comcast modem and that's why every 4-6 weeks the Comcast modem needs to be reset. The tech insisted that switches that *are* PoE-capable *always* send PoE even if the device doesn't request it or negotiate it. Attempts to explain the difference between the old 24-volt PoE and PoE+/++ were met with arguing that he's been in the industry for decades and I don't know what I'm talking about...and that all my problems would go away if I just disabled PoE everywhere on the switch. Again, I double-checked the port and said "It's not sending PoE to my router, but even if I were, I highly doubt PoE would leak through a PCI card to the opposite side of the chassis to the on-board NIC and out to your modem". He insisted it happened "all the time" and he had previously fried equipment by plugging it into a PoE switch. He insisted that he's also handled quite a few calls relating to this magic PoE problem over the years and Comcast has internal tools that show graphs of how much PoE power "builds up" inside their modems and he "can see a buildup in my router that resets every 24 hours". I didn't have the heart to tell him that I manage about 40 networks that have Comcast connections...and they *all* have identical FreeBSD boxes acting as their router, and they are *all* using the exact same PoE switches at every location with all ports set to PoE+...and we only have degraded service or outages after ~30 days at ~3 locations. Slightly off-topic, but if I call Comcast about outages or degraded service and any *other* tech but this guy answers, they all say "you need to unplug your Comcast modem and plug it back in once every 3-4 weeks" and they act like it's normal to reboot the modems every few weeks. In fact, last week I wanted Comcast to check on a modem setting at one location and they said the modem had been up for over 127 days and it should be rebooted. I said "it's up and working fine, why would I reboot it?". Anyways, am I insane for thinking the tech was flat-out wrong? I mean...occasionally some really bizarre stuff happens in IT...but this seems extremely far-fetched and contrary to everything I know about the PoE standard. -A

15 28

MAP-T (was: Re: V6 still not supported)
by Jared Brown 31 Mar '22

31 Mar '22

Most IPv6 transition mechanisms involve some form of (CG)NAT. After watching a NANOG presentation on MAP-T, I have a question regarding this. Why isn't MAP-T more prevalent, given that it is (almost) stateless on the provider side? Is it CPE support, the headache of moving state to the CPE, vendor support, or something else? NANOG 2017 Mapping of Address and Port using Translation MAP T: Deployment at Charter Communications https://www.youtube.com/watch?v=ZmfYHCpfr_w - Jared

9 10