Re: V6 still not supported

I don't think this can happen if I'm right and the reason they need to block "shared" IPs is because the games/apps just don't work. If I'm a gamer, and one of my possible ISPs is using CGN, and from time to time stops working, and another ISP is providing me a public and/or static IPv4

Re: [nanog] opendkim (was: Re: Gmail (thus Nanog) rejecting ipv6 email)

On Mon, 4 Apr 2022, Bjørn Mork wrote: "John Levine" writes: It appears that Michael Thomas said: On 4/3/22 12:12 PM, Bjørn Mork wrote: On a slightly related subject... This DKIM failure surprised me, but at least I verified that many NANOG subscribers have mailservers returning DMARC

Re: IP Reputation Services

On Mon, Apr 4, 2022 at 9:12 AM Laura Smith via NANOG wrote: > On Monday, April 4th, 2022 at 15:37, Mike Hammett > wrote: > > > I'm checking in to see what people think of IP reputation services. > > Pre-IPv6 I was always a little apprehensive of using them for general use > because it was

Re: V4 via V6 and IGP routing protocols

Pascal Thubert (pthubert) wrote: Hello Ohta-san Hi, it is hopeless. If you look at it, LS - as OSPF and ISIS use it - My team developed our own. Hierarchical QoS Link Information Protocol (HQLIP) https://datatracker.ietf.org/doc/draft-ohta-ric-hqlip/ which support 256

Re: V4 via V6 and IGP routing protocols

On 4/4/22 15:45, Masataka Ohta wrote: MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which means the source hosts have the current most routing table at

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

The vocabulary is distracting... In practice this extends IPv4 addresses by 32 bits, making them 64 bits in total. They are referring to the top 32 bits (240.0.0.0/6) as a “shaft.” The bottom 32 bits make up the "realm." Here is the way my teeny tiny brain understands it: 1. We get our shafts

Re: IPv6 Only

Is there a status page for this initiative? * M-21-07 (whitehouse.gov) * SUBJECT: Completing the Transition to Internet Protocol Version 6 (IPv6) “Develop an IPv6 implementation plan by the end of FY 2021, and update the

Re: Gmail (thus Nanog) rejecting ipv6 email

Accepting mail for delivery, and then either silently dropping it, delaying it for days, or putting mail that in no way resembles spam into a spam folder seems a little worse than “doing what the standards say”. If you’re going to decide, on little or no evidence, that a message is spam or

2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Dear all, On Sat, Apr 02, 2022 at 09:09:58PM +, John Curran wrote: > As previously reported here, ARIN will be shutting down the > ARIN-NONAUTH IRR database on Monday, 4 April 2022 at 12:00 PM ET. > > It is quite likely that some network operators will see different > route processing as a

RE: V4 via V6 and IGP routing protocols

Hello Ohta-san > it is hopeless. If you look at it, LS - as OSPF and ISIS use it - depends on the fact that all nodes get the same information and react the same way. Isn't that hopeless too? Clearly, the above limits LS applicability to stable links and topologies, and powered devices. This

Re: V6 still not supported

No, isn't only a Sony problem, becomes a problem for every ISP that has customers using Sony PSN and have CGN (NAT444), their IP blocks are black-listed when they are detected as used CGN. This blocking is "forever" (I'm not aware of anyone that has been able to convince PSN to unblock them).

Re: Gmail (thus Nanog) rejecting ipv6 email

Hello, On Sun, Apr 03, 2022 at 07:44:59PM -0500, Andy Ringsmuth wrote: > I’m running into this with clients for whom we do web site work. > Mail not being delivered to Gmail accounts. No bounceback, not > being delayed, not marked as spam, just black-holed for no > discernible reason. Like,

Re: IP Reputation Services

On Monday, April 4th, 2022 at 15:37, Mike Hammett wrote: > I'm checking in to see what people think of IP reputation services. Pre-IPv6 I was always a little apprehensive of using them for general use because it was always a bit murky how they collected the IPs in the first place. This of

Re: Enhance CG-NAT Re: V6 still not supported

Hi, Eduard: 0)    Appreciate very much for you spending the time to read all 55 pages of our draft and then offering your extensive thoughts. 1)    "Your first pages are oriented for low-level engineers (“for dummies”).  ...  ": Thanks. I believe that the Abstract, Introduction, etc. at

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Hello Nicholas Sorry for the distraction with the names; I did not forge realm, found it in the art. OTOH I created shaft because of elevator shaft, could have used staircase. > In practice this extends IPv4 addresses by 32 bits, making them 64 bits in > total. They are referring to the top

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Hello Eduard As (badly) written, all ASes and IP addresses that exist today in the internet could be either reused or moved in any parallel realm. Now that the ASN space is 32 bits, there would not be room for non-ASN based shaft routers. I fail to see the value in conflating. IBM could move

Re: V4 via V6 and IGP routing protocols

On Mon, Apr 4, 2022 at 5:16 AM Mark Tinka wrote: > > > > On 4/4/22 03:06, Dave Taht wrote: > > > I'm actually not here to start a debate... happy to learn that the v4 > > over v6 feature I'm > > playing with actually exists in another protocol, mainly. I'm > > critically dependent on > > source

Re: V4 via V6 and IGP routing protocols

Dave Taht wrote: Are MPLS or SR too heavy a bat? MPLS was not an option at the time. It might become one. MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which

Re: V4 via V6 and IGP routing protocols

Mark Tinka wrote: MPLS with nested labels, which is claimed to scale because nesting represents route hierarchy, just does not scale because source hosts are required to provide nested labels, which means the source hosts have the current most routing table at destinations, which requires flat

Re: is it still nfsen?

There is always Argus —Dave > On Apr 4, 2022, at 8:30 AM, John Kristoff wrote: > > On Sun, 03 Apr 2022 19:10:18 -0700 > Randy Bush wrote: > >> i am setting up new app/port monitoring. i like nfsen because i can >> zooom in and see who is sending all that port 43 tls between 11:42 and >>

Re: V6 still not supported

On Mon, Apr 04, 2022 at 04:24:49PM +0200, JORDI PALET MARTINEZ via NANOG wrote: > Related to the LEA agencies and CGN: > >

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Hi Nicholas, In fact, your explanation is much better than the draft explanation. Could I propose a small modification? Every AS announces 240.0.0.0 + AS# that they already have then there is no need for "shafts from ARIN" - AS# is already distributed and unique. Eduard -Original Message-

Re: V6 still not supported

> > . Less so a problem inherent to IPv4. A root cause fix would address > Sony's hostile behavior. > Disagree, to a point. The problem isn't technically with IPv4 itself, but with the lack of availability of V4 addresses. This tends to force things like CGNAT, which then compounds the problem

Re: Gmail (thus Nanog) rejecting ipv6 email

> On Apr 4, 2022, at 9:39 AM, Andy Smith wrote: > > On Sun, Apr 03, 2022 at 07:44:59PM -0500, Andy Ringsmuth wrote: >> I’m running into this with clients for whom we do web site work. >> Mail not being delivered to Gmail accounts. No bounceback, not >> being delayed, not marked as spam, just

Re: IP Reputation Services

Mike, > I've found a few of them out there, but they seem to be priced as if I'm a > hosting company or an ESP, not an end-user-focused ISP. There are only two IP-based reputation services that are truly widely used, world-wide, ours and Validity's (nee ReturnPath). Our have *always* been

Re: V6 still not supported

My guess is that fixing that means fixing tons of games/apps. They are somehow presuming that every user of the game has a different IP. Note that we are talking only about PSN because it is probably the most affected one, but I heard about other services with similar problems and similar

Re: opendkim

Bjørn Mork writes: > Any hints on how to configure sendmail to avoid this are appreciated. This turned out to be simple. Should have looked first, as usual. The sendmail config problem was Debian specific, caused by dnl # add .' to mustquote chars (and match the binary default)

Re: V4 via V6 and IGP routing protocols

The other question for this list I'd basically had was this: > https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6 > Please let me know if you feel that it should be possible to > completely disable v4-via-v6 even on newer kernels, and whether you > feel that v4-via-v6 should be

Re: V6 still not supported

Hi, Jared: 1)    " For cloud providers your IPv4 blocks become your moat. ":    It is interesting that your closing statement summarizing the current tactics of keeping customers captive and fending against competition mirrors well with the "Towers of Babel" metaphor of the ancient days

Re: V6 still not supported

Related to the LEA agencies and CGN: https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online Regards, Jordi @jordipalet El 4/4/22, 16:12, "NANOG en nombre de

opendkim (was: Re: Gmail (thus Nanog) rejecting ipv6 email)

"John Levine" writes: > It appears that Michael Thomas said: >> >>On 4/3/22 12:12 PM, Bjørn Mork wrote: >>> On a slightly related subject... This DKIM failure surprised me, but at >>> least I verified that many NANOG subscribers have mailservers returning >>> DMARC failure reports ;-) >> >>Oh

Re: V6 still not supported

I think you’re jumping to conclusions that Sony is doing this purely from the darkness in their hearts. The same thing could be said about Netflix and Hulu blocking traffic from addresses that appear as proxies/VPNs. Like it or not we had many years where the primary expectation of the Internet

IP Reputation Services

I'm checking in to see what people think of IP reputation services. I run an ISP (well, a couple of them) and we occasionally run into issues where customer IPs stop working with various services because of reputation issues. We run a fairly light-touch as to our customer's traffic, but when

Re: Gmail (thus Nanog) rejecting ipv6 email

On 2022-04-03 07:18, Owen DeLong via NANOG wrote: I’ve not experienced this problem sending emails via IPv6 to gmail destinations from my personal domain. (delong.com ) Likely this email will, in fact, get sent to GMAIL via IPv6. I do have good SPF and DKIM records and

Re: V6 still not supported

JORDI PALET MARTINEZ via NANOG wrote: No, isn't only a Sony problem, becomes a problem for every ISP that has customers using Sony PSN and have CGN (NAT444), their IP blocks are black-listed when they are detected as used CGN. This blocking is "forever" (I'm not aware of anyone that has

RE: V4 via V6 and IGP routing protocols

Hello Dave: There's RFC 8950 in the context of BGP. That's a refresher of RFC 5589 which is the one we typically refer to internally. I glanced at homenet too early, and then too late. Too early, it seemed that the protocol would be OSPFv3; no discussion. So I left till too late, when the

Re: V6 still not supported

My apologies for expressing myself poorly. What I meant to say is that this is primarily a problem caused by Sony and the Sonys of the world. Less so a problem inherent to IPv4. A root cause fix would address Sony's hostile behavior. - Jared Jordi Palet wrote: No, isn't only a Sony

RE: Enhance CG-NAT Re: V6 still not supported

Hi Abraham, I propose you improve EzIP by the advice in the draft on the way how to randomize small sites choice inside 240/4 (like in ULA?). To give the chance for the merge that may be needed for a business. Minimize probability for address duplication inside 240/4 block (that everybody would

Re: is it still nfsen?

On Sun, 03 Apr 2022 19:10:18 -0700 Randy Bush wrote: > i am setting up new app/port monitoring. i like nfsen because i can > zooom in and see who is sending all that port 43 tls between 11:42 and > 12:19. is there some other tool at which i should look? If you are using nfcapd/nfdump I think

Re: V6 still not supported

> 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

Re: V4 via V6 and IGP routing protocols

On 4/4/22 03:06, Dave Taht wrote: I'm actually not here to start a debate... happy to learn that the v4 over v6 feature I'm playing with actually exists in another protocol, mainly. I'm critically dependent on source specific routing, also, so I am hoping there's an isis or ospf that can do

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

2)When you extend each floor to use the whole IPv4 address pool, however, you are essential talking about covering the entire surface of the earth. Then, there is no isolated buildings with isolated floors to deploy your model anymore. There is only one spherical layer of physical earth

Re: V4 via V6 and IGP routing protocols

On 4/4/22 02:55, Dave Taht wrote: it was how hard adding source specific routing to isis turned out to be that turned me. At the time I needed simple means to get ipv6 working on multiple consumer uplinks. I suppose the presence of MPLS (and SR) for many operators is probably why this

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

About IBM I meant that they already live in a wall garden that is limited in size to one /8. They could move it to another realm without renumbering, and now they would have 200 times more addresses for whatever else they need. They could still own their /8 in the main internet and repurpose

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Hello Eduard In the YADA draft 240.0.0.1 is effectively programmed on the shaft router loop ack and used as router ID on the IGP inside the shaft… 240 addresses are the only ones advertised by the IGP. No prefix, Regards, Pascal > Le 4 avr. 2022 à 19:41, Pascal Thubert (pthubert) a >

Re: antique CGN complaints, was V6 still not supported

It appears that JORDI PALET MARTINEZ via NANOG said: >Related to the LEA agencies and CGN: > >https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online Before we freak

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Hi Pascal, The world has moved to 32bit AS# not far in the past. For sure, AS# would not cross 28bits. I do not understand why you need something different from AS# to point to the Realm. The one who would need a new realm - could go to RIR and ask for AS. Realm would be calculated

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

240.0.01.1 address is appointed not to the router. It is appointed to Realm. It is up to the realm owner (ISP to Enterprise) what particular router (or routers) would do translation between realms. -Original Message- From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] Sent:

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Well, if something is stateless then it is not CGNAT, it is just a router that may be called a gateway. It is a very similar thing that we have on the border between any domains when having a different data plane: - DC (VxLAN) and Backbone (MPLS) - Backbone and Metro (both

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Very right; the stateless operation is simpler than say tunneling in MPLS. Very easy to program in asic. The key points that make this feasible : - not trying the infeasible: any v4 to any v6 is a non goal. - legacy v4 host to legacy v4 application can still work the same long as they are

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Howdy All, While I agree that it might be politically entertaining to let this one blow up as a demonstration of how ARIN conducts business, this list of networks includes too many small networks who likely don't have a savy networking engineering team. In my opinion, they are not acceptable

Re: V6 still not supported

On 4/4/22 8:00 AM, Tom Beecher wrote: ( Of course, the better solution is really on the service end to have a better system to associate bad activity to specific users, or other methods that aren't reliant on reputation services , but that won't happen unless they start seeing revenue

RE: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Then change it. It may still be programmed on loopbacks, but treat it as anycast. -Original Message- From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com] Sent: Monday, April 4, 2022 8:50 PM To: Vasilenko Eduard Cc: Nicholas Warren ; Abraham Y. Chen ; Justin Streiner ; NANOG

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

This seems pretty unworkable. We would now all need to maintain large CG-NAT boxes in the network to decasulate the traffic from a source to the subscriber. It does seem like it would be fairly stateless, it is not improving things. Assuming the end host is sending traffic with the magic header

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

Isn’t load balancing one of the neat things you do with loopbacks? Certainly the router that serves the shaft is virtual and distributed. The shaft itself can/should be physically distributed in multiple IXPs. For now let us agree on the simple view. Things like load balancing and physical

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On Tue, 5 Apr 2022, Job Snijders wrote: Are others jumping ship or planning to from ALTDB (no offense intended, and grateful for the service you've provided) and other non-auth IRRs like RADB due to networks like Tata announcing that they won't honor route objects created in non-authoratative

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On Mon, Apr 04, 2022 at 06:35:31PM -0400, Jon Lewis wrote: > On Tue, 5 Apr 2022, Job Snijders wrote: > > > Are others jumping ship or planning to from ALTDB (no offense intended, > > > and > > > grateful for the service you've provided) and other non-auth IRRs like > > > RADB > > > due to

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Job Snijders via NANOG wrote: > our community also has to be cognizant about there being parts of the > Internet which are not squatting on anyone's numbers *and* also are > not contracted to a specific RIR. Let's not undermine one of the few remaining widely distributed (with no center)

RPKI adoption (was: Re: 2749 routes AT RISK )

On 4 Apr 2022, at 8:16 PM, John Gilmore mailto:g...@toad.com>> wrote: ... Also, centralizing control over route acceptance can be used for censorship. If the RIRs succeed in convincing "enough of the net" to reject any route that doesn't come with an RIR signature, then any government with

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On Mon, Apr 4, 2022 at 5:06 PM Kenneth Finnegan wrote: > > Howdy All, > > While I agree that it might be politically entertaining to let this > one blow up as a demonstration of how ARIN conducts business, this > list of networks includes too many small networks who likely don't > have a savy

Is it time to bring back the IPv6-only hour (well, half hour)?

On Thu, Mar 31, 2022 at 2:01 PM Mark Andrews wrote: > You have to try running IPv6 only occasionally to weed out the > dependencies. You can do this on a per node basis. Just turn off the IPv4 > interface and see how you run. I do this periodically on my Mac and disable > IPv4. This also

Re: [nanog] Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT -

On Tue, 5 Apr 2022, John Curran wrote: On 4 Apr 2022, at 9:52 PM, Jon Lewis wrote: ... I guess this legacy IP space, which is probably visible in ARIN's whois DB, but for which they provide no additional services unless you sign a LRSA and are then on the hook for annual membership fees?

Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

On Mon, Apr 4, 2022 at 10:41 AM Vasilenko Eduard via NANOG wrote: > 240.0.01.1 address is appointed not to the router. It is appointed to > Realm. > It is up to the realm owner (ISP to Enterprise) what particular router (or > routers) would do translation between realms. > Please forgive me as

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Kenneth Finnegan wrote on 04/04/2022 21:05: I've taken it upon myself to create proxy registrations for all of these prefixes in ALTDB. Please don't. You're not doing the routing security ecosystem any favours by doing this. Couple of reasons why: 1. this isn't your data and this is an

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

> > I am an ARIN admin and tech POC for one of the affected ASNs/sets of > prefixes across 2 OrgIDs. I looked back at the messages I've received > that mention NONAUTH or Non-Authenticated. The only thing I've gotten is > the message originally sent via ARIN-Announce that John forwarded, plus >

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

> > Cleaning it up is easy too. Publish an RPKI ROA for your space. We > will automatically delete any route objects which disagree with an > RPKI ROA. The routing security ecosystem should be doing that anyways. > "should" is a pretty tricky word to be using there. On Mon, Apr 4, 2022 at 7:21

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Hello Job , On Tue, 5 Apr 2022, Job Snijders via NANOG wrote: ...snip... I think there clearly is an industry-wide trend to move away from 'unsigned plain-text non-authoritative' datasets, towards better sources of truth such as the VRP data available through the RIR RPKI Trust

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On 4 Apr 2022, at 8:16 PM, John Gilmore mailto:g...@toad.com>> wrote: Let's not undermine one of the few remaining widely distributed (with no center) technical achievements behind the Internet -- the decentralized routing system. I'm on the board of a large legacy allocation that is

Re: [nanog] Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

On Mon, 4 Apr 2022, Dan Mahoney (Gushi) wrote: As one datapoint, two tiny /24's I (not-dayjob) originate are legacy resources. They cannot be added to either RPKI or the ARIN IRR objects without endeavoring to spend an at-least-this-much-money-price-will-only-go-up-over-time amount.

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On Mon, 4 Apr 2022, Kenneth Finnegan wrote: Howdy All, While I agree that it might be politically entertaining to let this one blow up as a demonstration of how ARIN conducts business, this list of networks includes too many small networks who likely don't have a savy networking engineering

Re: [nanog] Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

On Tue, 5 Apr 2022, Job Snijders via NANOG wrote: I think all of us recognize a need to declaw "third party" IRR databases like RADB and ALTDB ("declawing" meaning that it is not desirable that anyone can just register *anything*); on the other hand our community also has to be cognizant about

Re: [nanog] Re: [nanog] Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT -

On Mon, 4 Apr 2022, Jon Lewis wrote: On Mon, 4 Apr 2022, Dan Mahoney (Gushi) wrote: As one datapoint, two tiny /24's I (not-dayjob) originate are legacy resources. They cannot be added to either RPKI or the ARIN IRR objects without endeavoring to spend an

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Dear Jon, others, On Mon, Apr 04, 2022 at 05:48:42PM -0400, Jon Lewis wrote: > On Mon, 4 Apr 2022, Kenneth Finnegan wrote: > > While I agree that it might be politically entertaining to let this > > one blow up as a demonstration of how ARIN conducts business, this > > list of networks includes

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Thank you very much Job - a customer's block I've had trouble with in the past is unsurprisingly listed here due to a legacy non-auth IRR entry. When I first encountered this a few months ago, I was trying to get modern IRR entries for this block entered into ARIN, and ARIN kept returning an

Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

> On 4 Apr 2022, at 7:42 PM, Dan Mahoney (Gushi) wrote: > > On Tue, 5 Apr 2022, Job Snijders via NANOG wrote: > >> I think all of us recognize a need to declaw "third party" IRR databases >> like RADB and ALTDB ("declawing" meaning that it is not desirable that >> anyone can just register

Re: [nanog] [nanog] Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT -

On 5 Apr 2022, at 12:09 AM, Dan Mahoney (Gushi) wrote: > ... > You're allowed to insert, into WHOIS, an assertion of your originating AS > (like a pre-rpki-rpki) but I do not know of anything that consumes this, and > I believe this is not visible anywhere but WHOIS. I’m not aware of anything

Re: [nanog] [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT -

On 5 Apr 2022, at 12:21 AM, Dan Mahoney (Gushi) mailto:d...@prime.gushi.org>> wrote: John (C), just out of curiosity, is there a good count of how many of these resources exist (i.e. legacy resources without an LRSA?). If you can easily say an aggregate number I'm curious. In terms of IPv4

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On 4/4/2022 11:56 AM, Job Snijders via NANOG wrote: One might argue "well, folks had more than a year to move their objects!", but on the other hand, it is entirely possible not all the right people were reached, or in cases where affected parties did receive a communication from ARIN, they

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard wrote: > Please don't. > > You're not doing the routing security ecosystem any favours by doing > this. The routing security ecosystem is less of a concern to me than the lone network engineer at some water district or county who were about to have a

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

Exiting panic mode and stopping to think for a second, the NON-AUTH entry for this block is already invalid as it was entered by a previous owner/AS, and it doesn't match the current announcement from the current AS owner (my customer), so anything relying on NON-AUTH would have marked this

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

> Kenneth Finnegan wrote on 04/04/2022 21:05: > > I've taken it upon myself to create > > proxy registrations for all of these prefixes in ALTDB. > > Please don't. > Too late, all 394 routes mentioned above are now in ALTDB. > You're not doing the routing security ecosystem any favours by doing

Re: [nanog] 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40

On 4 Apr 2022, at 9:52 PM, Jon Lewis wrote: > ... > I guess this legacy IP space, which is probably visible in ARIN's whois DB, > but for which they provide no additional services unless you sign a LRSA and > are then on the hook for annual membership fees? ARIN has provided decades of