March 2022 - Test - lists.nanog.org

"Permanent" DST
by Jay R. Ashworth 08 Apr '22

08 Apr '22

In a unanimous vote today, the US Senate approved a bill which would 1) Cancel DST permanently, and 2) Move every square inch of US territory 15 degrees to the east. My opinion of this ought to be obvious from my rhetoric. Hopefully, it will fail, because it's likely to be the end of rational time worldwide, and even if you do log in UTC, it will still make your life difficult. I'm poleaxed; I can't even decide which grounds to scream about this on... Hopefully, the House or the White House will be more coherent in their decision on this engineering construct. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

53 97

Re: V6 still not supported
by Jared Brown 06 Apr '22

06 Apr '22

Owen DeLong via NANOG wrote: > When your ISP starts charging $X/Month for legacy protocol support Out of interest, how would this come about? - Jared

9 17

Re: V6 still not supported
by Jared Brown 05 Apr '22

05 Apr '22

Not to necessarily disagree with you, but that is more of a Sony problem than an IPv4 problem. - Jared Jordi Palet wrote: It is not a fixed one-time cost ... because if your users are gamers behind PSP, Sony is blocking IPv4 ranges behind CGN. So, you keep rotating your addresses until all then are blocked, then you need to transfer more IPv4 addresses ... So under this perspective, in many cases it makes more sense to NOT invest in CGN, and use that money to transfer up-front more IPv4 addresses at once, you will get a better price than if you transfer them every few months. Regards, Jordi @jordipalet El 30/3/22, 18:38, "NANOG en nombre de Jared Brown" <nanog-bounces+jordi.palet=consulintel.es at nanog.org en nombre de nanog-isp at mail.com> escribió: Randy Carpenter wrote: > >> >> Owen DeLong via NANOG wrote: > >> >> When your ISP starts charging $X/Month for legacy protocol support > >> > > >> > Out of interest, how would this come about? > >> > >> ISPs are facing ever growing costs to continue providing IPv4 services. > > Could you please be more specific about which costs you are referring to? > > > > It's not like IP transit providers care if they deliver IPv4 or IPv6 bits to > > you. > > Have you priced blocks of IPv4 addresses lately? IPv4 address blocks have a fixed one-time cost, not an ongoing $X/month cost. - Jared

4 4

More product suggestions: small/cheap IS-IS or VXLAN devices?
by Adam Thompson 05 Apr '22

05 Apr '22

At the risk of sounding like a broken record, I’m asking for product suggestions yet again: We’re wondering if anything small & cheap (think CPE-grade) exists that supports either IS-IS or VXLAN? If IS-IS, total route count it would have to carry would be small, probably in the ~500 range. If VXLAN, it needs to interoperate with Arista. If both… yay! When I say CPE-grade, I mean under C$1k (~US$800, ~€700), and can be emplaced at a customer site without any unusual infrastructure (e.g. no -48VDC power, or DIN rail mounting, non-business-office-typical). Thanks in advance, everyone. -Adam Adam Thompson Consultant, Infrastructure Services [MERLIN] 100 - 135 Innovation Drive Winnipeg, MB, R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) athompson(a)merlin.mb.ca<mailto:athompson@merlin.mb.ca> www.merlin.mb.ca<http://www.merlin.mb.ca/>

5 5

Re: IPv6 Only
by Jacques Latour 05 Apr '22

05 Apr '22

Exactly what I was asking, when and how will we collectively turn off the lights on IPv4? > -----Original Message----- > From: NANOG <nanog-bounces+jacques.latour=cira.ca(a)nanog.org> On > Behalf Of Mark Andrews > Sent: March 30, 2022 7:29 PM > To: NANOG <nanog(a)nanog.org> > Subject: [EXT] Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 > still not supported re: 202203261833.AYC > > Sites looking at the traffic they get and saying, you know what all our > customers connect to us over IPv6 with some of them also connecting over > IPv4. I think we can stop supporting IPv4 now. > > ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source it > for the few customers that are still using it. Lots of ISPs are well down the > path leading to this point by turning off IPv4 on the access networks. > > Home / enterprise networks. All my gear is IPv6 capable and supports > IPv4aaS for the few legacy > IPv4 sites I need to connect to. This is happening today. > > In the end almost all the IPv4 traffic with be with the third party IPv4aaS > providers and collectively they will decide to turn off the lights. > > > On 30 Mar 2022, at 07:53, Jacques Latour <Jacques.Latour(a)cira.ca> wrote: > > > > 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> > 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> > 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. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

5 5

ICANN Survey on DNS Suffix Usage and New gTLD Delegation
by Casey Deccio 04 Apr '22

04 Apr '22

Dear colleagues, tl;dr: Please take our survey on DNS suffix usage here: https://forms.gle/ntvsn6eqzYH9YcTN6 The Internet Corporation for Assigned Names and Numbers (ICANN) is researching the technical impact of delegating new generic top-level domains (gTLDs). This research is part of the Name Collision Analysis Project (NCAP). More information about NCAP can be found at https://community.icann.org/display/NCAP. Since 2013 hundreds of new gTLDs have been introduced into the public DNS (https://newgtlds.icann.org/en/program-status/delegated-strings) In some cases those gTLDs might have been used as part of a DNS suffix by one or more organizations around the Internet, prior to their introduction. (By “DNS suffix” we mean a domain name used in the DNS resolver search list of a device, e.g., the “domain” and “search” entries in /etc/resolv.conf on UNIX/Linux, “Search Domains” in the macOS DNS configuration pane, and “DNS suffix search list” on Windows.) As a result, the behavior of systems or devices in these organizations might have changed because of a “name collision”. A name collision occurs when a name used in one context (in the organization's network) is interpreted in another context (in this case, in the public DNS after the corresponding gTLD went live). We are researching the causes and impact of name collisions. We are seeking qualitative data based on experiences of those organizations potentially affected. We expect that this additional data will greatly enhance our understanding of name collisions that resulted from adding new gTLDs. If you suspect that your organization has been impacted by the delegation of any new gTLDs, we invite you to please fill out the following brief survey regarding your experience. We would be grateful for your input! https://forms.gle/ntvsn6eqzYH9YcTN6 Your responses will remain anonymous, and any personal information will be discarded after the research has concluded. If you have any questions, please reply to this email. Thank you for your help! Sincerely, Casey Deccio ICANN Name Collisions Analysis Project

1 1

Cogent ...
by Laura Smith 02 Apr '22

02 Apr '22

Hmmm.... Spring has sprung and the waft of drivel from a new season Cogent salesdroid filled my telephone earpiece today. I've never liked the Cogent way of business and my understanding of their IP transit is that it falls into the "cheap for a reason" category. However, perhaps someone would care to elaborate (either on or off-list) what the deal is with the requirement to sign NDAs with Cogent before they'll discuss things like why they still charge for BGP, or indeed any other technical or pricing matters. Seems weird ?!? Laura

9 9

Opinions on Arista for BGP?
by David Hubbard 01 Apr '22

01 Apr '22

Hi all, would love to get any current opinions (on or off list) on the stability of Arista’s BGP implementation these days. Been many years since I last looked into it and wasn’t ready for a change yet. Past many years have been IOS XR on NCS5500 platform and Arista everywhere but the edge. I’ve been really happy with them in the other roles, so am thinking about edge now. I do like and use XR’s RPL, and prefix/as/community/object sets, but we can live without via our own config management if there aren’t easy equivalents. No fancy needs at all, just small web server networks, so just need reliable eBGP and internal OSPF/OSPFv3. Thanks, David

4 3

AS21299 - 46.42.196.0/24 ASN prepending 255 times
by Erik Sundberg 01 Apr '22

01 Apr '22

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's say 20. Thanks! This is a Kazakhstan register IP Block and ASN Network Next Hop Metric LocPrf Weight Path *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 i ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

13 20

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