- Test - lists.nanog.org

Re: V6 still not supported Re: 202203181137.AYC
by Abraham Y. Chen 18 Mar '22

18 Mar '22

Dear Matt: 1) "... I would *love* to see IPv4 get extended, a software patch applied to devices, ... ": Please have a look at a concise whitepaper below that does what you are hoping for and more. It proposes an overlay architecture, called EzIP, tethered from the current Internet proper. Each EzIP module, called RAN is supported by one IPv4 public address. Since the RANs appear to be private networks from the Internet's perspective, all equipment and operation within it can make use of what is possible by current IPv4 hardware and software but avoids any undesired ones. In particular, the only engineering effort required to enable this process is "*/disabling/* the program code that has been */disabling /*the use of the 240/4 netblock". This applies only to the routers, not patching the individual IoTs (devices). I believe this is much simpler than you are envisioning. I will be glad to describe any specifics that you may come across. https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf 2) "... IPv6 die a quick painless death. ... ": EzIP work only focuses on enhancing the IPv4 portion of the Internet. What happens to the future of the IPv6 is entirely a separate topic. Or, as a common expression says, let the market decide. 😉 Regards, Abe (2022-03-18 12:12) ------------------------------ NANOG Digest, Vol 170, Issue 20 Message: 31 Date: Thu, 17 Mar 2022 23:34:19 -0500 From: Matt Hoppes<mattlists(a)rivervalleyinternet.net> To: Joe Maimon<jmaimon(a)jmaimon.com>,bzs(a)theworld.com, Tom Beecher <beecher(a)beecher.cc> Cc: NANOG<nanog(a)nanog.org> Subject: Re: V6 still not supported Message-ID: <de9f4abc-99bc-2eb1-80d7-ef62cfd6799e(a)rivervalleyinternet.net> Content-Type: text/plain; charset=utf-8; format=flowed At this point I would*love* to see IPv4 get extended, a software patch applied to devices, and IPv6 die a quick painless death. > Its not impossible to envision that IPv4 does not ever go away but > actually gets extended in such a way that it obsoletes IPv6. The longer > this drags out the less implausible it seems. > > Joe > > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Zayo contact help?
by Ray Bellis 18 Mar '22

18 Mar '22

Hi all, I have transit donated from Zayo at Equinix SV8 (529 Bryant St, Palo Alto) but it's so old that no-one at Zayo appears to know it exists and they can't find records of it. It probably dates to the MFN / Above.net days. If you can assist with discussions about delivery of that transit to HE FMT2 instead, please let me know! thanks, Ray

1 0

For those in the Phoenix area - ARIN on the Road taking place 29 March 2022
by John Curran 18 Mar '22

18 Mar '22

For those in the Phoenix area, there will be an ARIN on the Road taking place 29 March 2022 – an excellent opportunity to get any questions/concerns/issues addressed in person. See below for details. Thanks! /John John Curran President and CEO American Registry for Internet Numbers === ARIN on the Road Coming Soon to Phoenix, Arizona ---------------------------------------------------------------------- ARIN on the Road is back ... and we are eager to see you! We will be packing our shades for sunny Arizona for the first ARIN on the Road event since 2020. Held on Tuesday, 29 March at the Sheraton Phoenix Downtown, this is an educational experience you do not want to miss. CLICK TO REGISTER: https://arin.net/AOTRPhoenix Throughout the day, members of ARIN's Executive leadership team will present an overview of current ARIN activities and services and answer your questions. You will also have the chance to meet and network with others in the ARIN community. You will also be able to meet with Lisa Liedel, ARIN's Director of Registration Services, who is running the ARIN Registration Services Help Desk and answering questions related to acquiring Internet number resources, IPv6 deployment, routing security and more. Our panel of experts include: - John Curran - ARIN's President and CEO - John Sweeting - ARIN's Chief Customer Officer - Hollis Kara - ARIN’s Director of Communications - Brad Gorman - ARIN's Senior Product Owner - Routing Security And they will speak to and answer your questions regarding: - ARIN's Mission and Core Functions - IPv6 Deployment - The Status of IPv4, including the Waiting List, Transfers, and more - Routing Security - Using your ARIN Online Account - Participating in the ARIN community - Introduction to the Policy Development Process ... and more! Registration is free and lunch is on us. Seating is limited so pre-registration is required. Two individuals per ARIN customers (an organization holding resources directly issued from ARIN) are welcome to attend. Doors open at 9:00 AM; we will start promptly at 9:30 AM and are slated to end at 3:00 PM. Please contact meetings(a)arin.net<mailto:meetings@arin.net> if you have any questions. We look forward to seeing you! Our Commitment to Health and Safety: During the COVID-19 pandemic, ARIN believes the health and well-being of our community members and staff is a top priority. We continue to follow official guidance from national and local governments regarding COVID-19 response measures. Additional recommendations can be found on the ARIN on the Road registration sites Health & Safety page at https://arin.swoogo.com/aotr_phoenix/safety. For additional information and to register, please visit https://arin.net/AOTRPhoenix Regards, American Registry for Internet Numbers (ARIN)

1 0

FCC docket on BGP routing vulnerabilities
by Andrew Hadenfeldt 17 Mar '22

17 Mar '22

https://www.federalregister.gov/documents/2022/03/11/2022-05121/secure-inte… https://www.fcc.gov/document/fcc-launches-inquiry-internet-routing-vulnerab… (FCC) seeks comment on vulnerabilities threatening the security and integrity of the Border Gateway Protocol (BGP), which is central to the Internet's global routing system, its impact on the transmission of data from email, e-commerce, and bank transactions to interconnected Voice-over Internet Protocol (VoIP) and 9-1-1 calls, and how best to address them. Comments are due on or before April 11, 2022

1 0

Ukraine electric grid now synced with Europe grid (year ahead of schedule)
by Sean Donelan 17 Mar '22

17 Mar '22

The Ukraine electric grid has been synched with the Russian electric grid since the fall of U.S.S.R. In 2017, Ukrain and ENTSO-E (Continental Europe electric grid authority) began planning to interconnect the Ukraine grid with the Europe Grid (and disconnect from the Russian grid). The original schedule was testing throughout 2022, and interconnecting the grids in 2023. NPC UKRENERGO announced as of yesterday (March 16, 2022), it has synched with the Continental Europe grid a year ahead of schedule. https://www.linkedin.com/feed/update/urn:li:activity:6910298679274815488 https://time.com/6153039/ukraines-electricity-grid-escape-russia/

1 0

Russia attempts mandating installation of root CA on clients for TLS MITM
by Eric Kuhnke 17 Mar '22

17 Mar '22

https://bugzilla.mozilla.org/show_bug.cgi?id=1758773 I think we'll see a lot more of this from authoritarian regimes in the future. For anyone unfamiliar with their existing distributed DPI architecture, google "Russia SORM".

9 12

Network Policies Towards Software Supply Chain Compromise
by Matt Corallo 17 Mar '22

17 Mar '22

Hi network operators, As RPKI validation continues to become increasingly broadly deployed (yay!), I wanted to highlight and ask what deployment policies are towards dependency validation and pinning of RPKI validation software. For example, routinator's dependency graph is somewhat large, and includes at least one or two single-maintainer projects[1] which could inject arbitrary results into the RPKI-based filters. Certainly routinator is not the only project to fall prey to modern development practices which tend to have an exponentially expanding TCB, which makes it a concern that has landed in the laps of sysadmins instead of developers. I assume the large players are considering these issues and taking them into account when deploying, eg by writing tools to compare the feeds of multiple RPKI validators and rejecting any differences, am I correct in that assumption, and are there any open source projects to do so that smaller operators should be looking at using as well? Matt [1] eg https://github.com/vorner/log-reroute could edit your RPKI feed if, vorner wanted to.

1 0

Re: CC: s to Non List Members (Was Re: Making Use of 240/4 NetBlock) Re: 2022031711315.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Tom: 1) " ... it has serious deficiencies. ... ": Could you please be specific? Branding something without qualifying information is unprofessional. Regards, Abe (2022-03-17 13:18) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 2 Date: Wed, 16 Mar 2022 08:28:36 -0400 From: Tom Beecher<beecher(a)beecher.cc> To: Greg Skinner<gregskinner0(a)icloud.com> Cc:bzs@theworld.com, "North American Network Operators' Group" <nanog(a)nanog.org> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock) Message-ID: <CAL9Qcx5v4Mko-kAdHpRx4KiRZ8e2ubQ-dV6GHg8djOYqxDUMuQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" No quibble about the discussion happening on a NOG list, not at all. But frankly unless the proposal is even starting to move forward in the IETF process such that a standards change is possible, it's just noise. ( I don't predict that the draft being discussed ever gets that far anyways ; it has serious deficiencies.) On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG<nanog(a)nanog.org> wrote: > I agree. iMO, this 240/4 issue is another one of those tussles in > cyberspace > <https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>. But > I don?t fault IETF people or anyone else who pursues technical solutions to > these types of problems as long as they are open and honest about the > limitations of these solutions. > > Also, IMO, the value of having a discussion about this issue here (and > other NOG forums) is to get the perspective of people who (generally > speaking) deal more immediately with the problems the broader ?online" > population has with IETF-based technology. > > ?gregbo > > On Mar 8, 2022, at 9:25 PM,bzs(a)theworld.com wrote: > > > I'm beginning to wonder if the internet will survive the ipv6 adoption > debates. > > Here's the real problem which you all can promptly ignore: > > The IETF et al are full of bright technical people who can design > protocols, packet formats, etc. > > But many of the major problems facing the internet are not, at their > core, engineering problems. > > They're in the realm of social, legal, marketing, politics, int'l > policy, governance, law enforcement, commerce, economics, sociology, > psychology, etc. which TBH as bright as many of the engineers et al > are these problems are way beyond their ken, occasional polymath > excepted. > > But first you have to admit you have a problem, and limitations. > > Shouting at the rafters about address space depletion etc while waving > RFCs may not quite do it. > > Similar can be said about spam, malware attacks, phishing, etc. > > Yet another cryptographic protocol probably won't save the day but as > the expression goes when all you have is a hammer the whole world > looks like a nail. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility |*oo* > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

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

17 Mar '22

Hi, Tom: 1) " I've read the draft. ... ": Then, you still overlooked the essence of the keyword "overlay": A. The EzIP project started with the goal of getting enough IP addresses for end-to-end communication according to the old fashioned definition in telecommunications, such as PSTN. Upon correlated the three private netblocks to the reusable PBX numbering convention and discovered the availability of the 240/4 netblock, we enlisted the Option Word for carrying such additional information to accomplish this goal. B. Next, we realized that since 240/4 is so big, we can deploy it over a much larger area than a commonly known private premises. The concept of RAN (Regional Area Network) was born. Since the existing Internet routers will drop any 240/4 addressed packets, RANs can deploy on their own, without interference in either direction. With each RAN served from one IPv4 public address, the entire RAN can be viewed as an isolated island or a piece of land floating in the air and tethered to the Internet core via one umbilical cord. C. This configuration frees up the need for updating any current Internet equipment while growing by expanding from one IPv4 address. That is, the RAN deployment can be done via SPRs (Semi-Public Routers) as needed. All of these introductory activities do not need to use the Option Word, at all. This phase of the deployment can use the degenerated EzIP header mentioned in the Draft which is actually the conventional basic IPv4 header (without Option Word). D. Only when direct communication between IoTs residing in separate RANs is desired, IoTs capable of the full EzIP header will be used. (These are not wide spread requirement, but case-by-case for elite users.) Since the number of umbilical cords is finite, interconnecting RANs for this purpose can be achieved by deploying SPRs where is needed. Of course, if existing routers are wiling to support (by "trimming down" the existing code), the deployment will go much faster. But, it is not necessary. 2) The above is why "overlay" network can be used to characterize the EzIP architecture. One interesting online graphics that we recently came across depicts this configuration very nicely (see URL below). One can visualize that each continent, country, and even all the way down a Region or an island is floated above the earth core (the Internet) and tethered to it via an umbilical cord (IPv4 address). With this architecture, everything in the RAN can start fresh, yet supported by the core all the time. The involvement of the latter is optional. This relationship is the same as national versus international telephony networks in the PSTN world. In other words, the current Internet proper will serve just the current type of interconnections among RANs, if no update is made to its routers. https://dotconnectafrica.org/icann-wins-by-technical-knockout-dca-blocked-f… Hope I am not boring you by being too wordy. Regards, Abe (2022-03-17 12:20) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 9 Date: Wed, 16 Mar 2022 11:38:51 -0400 From: Tom Beecher <beecher(a)beecher.cc> To: "Abraham Y. Chen" <aychen(a)avinta.com> Cc: Mark Andrews <marka(a)isc.org>, NANOG <nanog(a)nanog.org> Subject: Re: Making Use of 240/4 NetBlock Re: 202203161019.AYC Message-ID: <CAL9Qcx46RzdqYWRQ+Fo_+a8L9Kr=ZQi9J2Ej+FNtzTFs=eSpuA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" > 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. I've read the draft. Your proposal appears to rely on a specific value in the IP option header to create your overlay. While that sounds good on paper, it's operationally been best practice for at least the last decade (maybe longer) to drop any packet with an IP option set that you don't explicitly want because a significant number of routers kick every packet with options to CPU, so any substantive traffic flow with options set could knock devices over. I can't speak to the current state of router processing, but I'd bet dollars to donuts most of those filters are still in place. So, assuming your proposal were to eventually become an adopted standard, before it could reliably work across the general internet : - Any device that still treated 240/4 differently would need to be updated to treat it like anything else. - Any existing filters that dropped packets with*any* IP option set would have to be modified to permit the ones you define for EzIP - At least some router software would have to have IP option handling adjusted in some way. ( At one point in the past, one big router vendor only allowed you to configure an ip-options filter based on the IANA defined values, not others. ) This is a LOT of work and time for an overlay. On Wed, Mar 16, 2022 at 10:51 AM Abraham Y. Chen<aychen(a)avinta.com> wrote: > 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) > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Re: CC: s to Non List Members (Re: Making Use of 240/4 NetBlock Re: 202203171135.AYC
by Abraham Y. Chen 17 Mar '22

17 Mar '22

Hi, Greg: 1) " ... The IETF has changed its position on several (IMO) key issues during its existence. ... ": Well said! In fact, I believe (from one of the APNIC blogs recounting the Internet history) that CG-NAT was one of those "bastards" who turned to be accepted as a prince whom everyone is defending him now, without realizing that an enhancement is at the front door steps again. Regards, Abe (2022-03-17 11:50) ------------------------------ NANOG Digest, Vol 170, Issue 19 Message: 34 Date: Wed, 16 Mar 2022 15:32:45 -0700 From: Greg Skinner<gregskinner0(a)icloud.com> To: Tom Beecher<beecher(a)beecher.cc> Cc:bzs@theworld.com, North American Network Operators' Group <nanog(a)nanog.org> Subject: Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock) Message-ID:<109DB49C-2471-4FE2-AC68-E4EEAFE1C886(a)icloud.com> Content-Type: text/plain; charset="utf-8" I have qualms about these drafts also. However, even if the IETF does not move forward with any of them (not even to adopt them as WG items), that doesn?t mean they never will. Times change. Circumstances change. The IETF has changed its position on several (IMO) key issues during its existence. Perhaps this will be one of those times. Incidentally, if you take a look at this post from Theodore Ts?o<https://mailarchive.ietf.org/arch/msg/ietf/IGKkL8IM1IptV4Q3Z3pko6OC1Xs/> he?s pretty much saying the same thing that Barry Shein said, that the IETF isn?t as good at policy as it is in producing protocol standards. (The thread it?s from started from a response to the publication of RFC2008<https://www.rfc-editor.org/rfc/rfc2008.txt> as a Best Current Practice, in spite of ?vigorous opposition?.) The other thing I wanted to say is for anyone who doesn?t know a lot about the IETF workings, the contributions of some of the authors of the Schoen drafts are recognized and respected in the IETF Transport Area. They?re not new to this stuff. They have ?clue?. They do due diligence. They produce running code, and (IMO) are seeking rough consensus. I believe that in the IETF of, say, a quarter century ago, their drafts would have progressed further through the standards process. For various reasons, today?s IETF is different, but could still change its minds. I believe the authors of the Schoen drafts are capable of drumming up support for their ideas even if they don?t (immediately) become IETF drafts, and that the IETF might change its position on their ideas, as a result of such support. ?gregbo > On Mar 16, 2022, at 5:28 AM, Tom Beecher<beecher(a)beecher.cc> wrote: > > No quibble about the discussion happening on a NOG list, not at all. > > But frankly unless the proposal is even starting to move forward in the IETF process such that a standards change is possible, it's just noise. ( I don't predict that the draft being discussed ever gets that far anyways ; it has serious deficiencies.) > > On Sat, Mar 12, 2022 at 6:53 PM Greg Skinner via NANOG <nanog(a)nanog.org <mailto:nanog@nanog.org>> wrote: > I agree. iMO, this 240/4 issue is another one of those tussles in cyberspace<https://david.choffnes.com/classes/cs4700fa14/papers/tussle.pdf>. But I don?t fault IETF people or anyone else who pursues technical solutions to these types of problems as long as they are open and honest about the limitations of these solutions. > > Also, IMO, the value of having a discussion about this issue here (and other NOG forums) is to get the perspective of people who (generally speaking) deal more immediately with the problems the broader ?online" population has with IETF-based technology. > > ?gregbo > >> On Mar 8, 2022, at 9:25 PM,bzs(a)theworld.com <mailto:bzs@theworld.com> wrote: >> >> >> I'm beginning to wonder if the internet will survive the ipv6 adoption >> debates. >> >> Here's the real problem which you all can promptly ignore: >> >> The IETF et al are full of bright technical people who can design >> protocols, packet formats, etc. >> >> But many of the major problems facing the internet are not, at their >> core, engineering problems. >> >> They're in the realm of social, legal, marketing, politics, int'l >> policy, governance, law enforcement, commerce, economics, sociology, >> psychology, etc. which TBH as bright as many of the engineers et al >> are these problems are way beyond their ken, occasional polymath >> excepted. >> >> But first you have to admit you have a problem, and limitations. >> >> Shouting at the rafters about address space depletion etc while waving >> RFCs may not quite do it. >> >> Similar can be said about spam, malware attacks, phishing, etc. >> >> Yet another cryptographic protocol probably won't save the day but as >> the expression goes when all you have is a hammer the whole world >> looks like a nail. >> >> -- >> -Barry Shein >> >> Software Tool & Die | bzs at TheWorld.com<http://theworld.com/> |http://www.TheWorld.com <http://www.theworld.com/> >> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >> The World: Since 1989 | A Public Information Utility |*oo* >>

1 0