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)

[Jeff Behrns via NANOG]

Lumen / Level3 filtergen is trimming these routes now.  Don't bother trying
to query filtergen.level3.net currently; server is full.  Small AS cone does
not equal small societal footprint & impact.  While I appreciate the
intention upthread of proxy registering at ATLDB, it really just distracted
from finding the root issue.

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)

[Wes George]

On 4/4/2022 7:08 PM, Tom Beecher wrote:


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
similar reminders.


I'm extremely grateful to Job and Kenneth for stepping in to address
ARIN's failure here before it ruined a lot of people's weeks.


ARIN clearly stated they were attempting to reach people with records 
for the last year. If the contact info you had was correct and they 
still didn't get to you, perhaps it better to speak with them to 
figure out why before just branding it a 'failure'.



In the interest of fairness and accuracy, there's an important 
clarifying detail. ARIN *did* notify the POCs associated with the actual 
NONAUTH IRR records. But those are wholly separate from the POCs for the 
actual address or ASN resources, which is what I was referencing above, 
and thus it resulted in a bad assumption on my part. That said, if the 
email addresses associated with what are likely 
stale/crufty/unmaintained records in the NONAUTH IRR were dead, no one 
got notified. Reasonable people can disagree on whether that was enough 
of an attempt. In this case, I didn't know these existed, and thus 
didn't know that the contact info for them was similarly out of date. I 
suspect I'm not the only one in this situation.


My calling this a failure was too strong, and for that I apologize, but 
I disagree with their choice to not notify the current resource holder 
POCs when they were unable to successfully notify the POCs for the 
corresponding objects. That said, it's not an easy problem, and there 
are things that multiple parties (including me) could or should have 
done to address this, so the blame is not solely ARIN's.


Wes George

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)

[J. Hellenthal via NANOG]

Hope this is 40 business hours

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Apr 5, 2022, at 22:42, Rubens Kuhl  wrote:
> 
> For the inclusion of proxy objects in ALTDB for ARIN-NONAUTH, this is
> the current state of objects among known IRRs:
> 
> 
> source  total obj rt objaut-num obj
> 
> AFRINIC127024  99313   2116
> ALTDB   29342  21385   1481
> APNIC  879374 572495  17737
> ARIN   151087  61535   2461
> ARIN-NONAUTH34334  29291932(* Final
> mirror obtained April 4 *)
> BBOI 1200869 57
> BELL29827  29613105
> CANARIE  1832   1425177
> HOST2  0  1
> IDNIC9301   4886   1845
> JPIRR   13404  11398425
> LACNIC   8008   4742   1039
> LEVEL3 111542  90593300
> NESTEGG 8  4  2
> NTTCOM 453257 444518548
> OPENFACE   25 17  1
> PANIX  42 40  1
> RADB  15943761397813   9077
> REACH   20280  18177  2
> RGNET  80 43  6
> RIPE  1394165 379711  37475
> RIPE-NONAUTH57851  54281   2140
> TC  29936  12207   3703
> WCGDB   65135  62849773None
> 
> 
> Rubens
> 
>> On Mon, Apr 4, 2022 at 12:57 PM Job Snijders via NANOG  
>> wrote:
>> 
>> 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 result of this change, as validation against the
>>> ARIN-NONAUTH IRR database will not longer be possible.
>>> 
>>> Please be aware of this upcoming event and make alternative
>>> arrangements if you are presently relying on upon routing objects in
>>> the ARIN-NONAUTH IRR database.
>> 
>> I ran an analysis just now in which I created an intersection between
>> prefixes observed in the BGP default-free zone and exactly matching
>> route:/route6: objects in ARIN-NONAUTH. I then substracted exact
>> matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
>> APNIC IRR sources. The result is a list of routes which might
>> experience service disruptions due to missing IRR objects.
>> 
>> The below 2,749 Prefix + Origin AS pairings are at risk as a result of
>> ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
>> are likely to manifest themselves in the coming 24 - 32 hours. Prior to
>> this announcement, ARIN consulted with its community on the future of
>> its IRR service.
>> 
>> I voiced objection and raised concerns about (what appeared to be)
>> limited visibility into what exactly the effects of such a database
>> shutdown would mean for the Internet: 
>> https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
>> Other community members also shared concerns: 
>> https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
>> A number of graceful alternative mechanisms were proposed, but not
>> acted upon: 
>> https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html
>> 
>> 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 perhaps were unable to
>> understand the message.
>> 
>> Please check if any of your prefixes are on the below list, and if so,
>> double check whether your IRR administration is able to overcome the
>> disappearance of ARIN-NONAUTH. Godspeed!
>> 
>> This tool might be useful: https://irrexplorer.nlnog.net/
>> 
>> Kind regards,
>> 
>> Job
>> 
>> Prefix OriginAS
>> 100.42.100.0/24 33353
>> 100.42.101.0/24 33353
>> 100.42.102.0/24 33353
>> 100.42.104.0/24 33353
>> 100.42.105.0/24 33353
>> 100.42.106.0/23 33353
>> 100.42.108.0/24 33353
>> 100.42.109.0/24 33353
>> 100.42.96.0/23 33353
>> 100.42.98.0/24 33353
>> 103.11.202.0/24 33517
>> 103.13.12.0/24 38057
>> 103.13.135.0/24 51830
>> 103.15.168.0/23 55532
>> 103.196.22.0/23 7489
>> 103.219.78.0/24 55256
>> 103.219.79.0/24 55256
>> 103.232.224.0/24 125
>> 103.250.176.0/24 134795
>> 

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)

[Rubens Kuhl]

For the inclusion of proxy objects in ALTDB for ARIN-NONAUTH, this is
the current state of objects among known IRRs:


 source  total obj rt objaut-num obj

 AFRINIC127024  99313   2116
 ALTDB   29342  21385   1481
 APNIC  879374 572495  17737
 ARIN   151087  61535   2461
 ARIN-NONAUTH34334  29291932(* Final
mirror obtained April 4 *)
 BBOI 1200869 57
 BELL29827  29613105
 CANARIE  1832   1425177
 HOST2  0  1
 IDNIC9301   4886   1845
 JPIRR   13404  11398425
 LACNIC   8008   4742   1039
 LEVEL3 111542  90593300
 NESTEGG 8  4  2
 NTTCOM 453257 444518548
 OPENFACE   25 17  1
 PANIX  42 40  1
 RADB  15943761397813   9077
 REACH   20280  18177  2
 RGNET  80 43  6
 RIPE  1394165 379711  37475
 RIPE-NONAUTH57851  54281   2140
 TC  29936  12207   3703
 WCGDB   65135  62849773None


Rubens

On Mon, Apr 4, 2022 at 12:57 PM Job Snijders via NANOG  wrote:
>
> 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 result of this change, as validation against the
> > ARIN-NONAUTH IRR database will not longer be possible.
> >
> > Please be aware of this upcoming event and make alternative
> > arrangements if you are presently relying on upon routing objects in
> > the ARIN-NONAUTH IRR database.
>
> I ran an analysis just now in which I created an intersection between
> prefixes observed in the BGP default-free zone and exactly matching
> route:/route6: objects in ARIN-NONAUTH. I then substracted exact
> matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
> APNIC IRR sources. The result is a list of routes which might
> experience service disruptions due to missing IRR objects.
>
> The below 2,749 Prefix + Origin AS pairings are at risk as a result of
> ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
> are likely to manifest themselves in the coming 24 - 32 hours. Prior to
> this announcement, ARIN consulted with its community on the future of
> its IRR service.
>
> I voiced objection and raised concerns about (what appeared to be)
> limited visibility into what exactly the effects of such a database
> shutdown would mean for the Internet: 
> https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
> Other community members also shared concerns: 
> https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
> A number of graceful alternative mechanisms were proposed, but not
> acted upon: 
> https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html
>
> 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 perhaps were unable to
> understand the message.
>
> Please check if any of your prefixes are on the below list, and if so,
> double check whether your IRR administration is able to overcome the
> disappearance of ARIN-NONAUTH. Godspeed!
>
> This tool might be useful: https://irrexplorer.nlnog.net/
>
> Kind regards,
>
> Job
>
> Prefix OriginAS
> 100.42.100.0/24 33353
> 100.42.101.0/24 33353
> 100.42.102.0/24 33353
> 100.42.104.0/24 33353
> 100.42.105.0/24 33353
> 100.42.106.0/23 33353
> 100.42.108.0/24 33353
> 100.42.109.0/24 33353
> 100.42.96.0/23 33353
> 100.42.98.0/24 33353
> 103.11.202.0/24 33517
> 103.13.12.0/24 38057
> 103.13.135.0/24 51830
> 103.15.168.0/23 55532
> 103.196.22.0/23 7489
> 103.219.78.0/24 55256
> 103.219.79.0/24 55256
> 103.232.224.0/24 125
> 103.250.176.0/24 134795
> 103.250.177.0/24 134795
> 103.250.178.0/24 134795
> 103.250.179.0/24 134795
> 103.35.217.0/24 125
> 103.47.244.0/24 55256
> 103.88.172.0/24 136271
> 103.88.173.0/24 136271
> 103.88.174.0/24 136271
> 104.128.96.0/20 19233
> 104.142.128.0/23 33353
> 104.142.130.0/23 33353
> 104.142.136.0/22 33353
> 104.142.140.0/23 33353
> 104.142.144.0/24 33353
> 

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)

[Rubens Kuhl]

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 networking engineering team.
>
> In my opinion, they are not acceptable collateral damage to
> demonstrate ARIN's lack of regard for the community in shutting this
> down without a transition plan for the RPSL objects, so as one of the
> admins for the ALTDB IRR database, I've taken it upon myself to create
> proxy registrations for all of these prefixes in ALTDB.

While I won't discuss the issue of proxy registrations, the key here
is the responsiveness in removing such proxy registrations if/when
asked to do so.

> Like any proxy registration, asset owners are welcome to contact the
> maint POC, and if no response from them, db-ad...@altdb.net,
> requesting that stale records be deleted, but please also note that

If you as the maint POC is willing to commit to responsiveness in
doing that, great.

> ALTDB automatically deletes any route objects which conflict with a
> publishes RPKI ROA, so the most effective way to clean up stale IRR
> records is to publish RPKI ROAs for your address space.

Which only would clear up proxy regs with wrong origin AS, not with
right origin AS but wrong maintainer.

Rubens

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)

[Aftab Siddiqui]

> 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
> this. Couple of reasons why: 1. this isn't your data and this is an
> unexpected action on the part of the registrants, 2. this is a sure-fire
> way of accumulating even more cruft in ALTDB in a way which is
> troublesome to clean up afterwards, 3. there are several thousand
> objects in there which are already marked as proxy registrations, and
> are already likely to be inaccurate, 4. you're losing authentication
> information for people to self-manage their registrations, and 5. you
> have likely not cross-checked this data against RIR transfers /
> de-registrations - it's not really possible to do with with the
> arin-nonauth db because that db doesn't include the last-modified
> timestamp, and the changed: attribute is unreliable.
>

Can't express it any better than 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)

[John Curran]

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 deliberately NOT
an ARIN (or other RIR) member.  And I have a small address block of my
own, ditto.

ARIN doesn't provide authenticated RPKI entries for just anybody.  You
have to pay them for that service.  And in order to pay them, you have
to sign their contract.  And if you sign that contract, ARIN can take
away your legacy allocation -- anytime they decide it would be in their
best interest.  Whereas, if you don't sign, the courts have held that
you have a *property right* in your IP addresses and they *belong* to
you.  As a result, most legacy address holders (a large fraction of the
Internet addresses) have declined to sign such contracts, pay such
bills, and thus can't be in the ARIN authenticated routing registry.

Hello John -

Your legal summary is patently incorrect; I’d be happy to discuss it anytime 
with you – in public or private as you prefer – but the short version is that 
courts have indeed held that a party can have an interest (such as bankruptcy 
estate or probate estate interest) in specific rights to Internet number blocks 
in the ARIN registry, but that doesn’t equate to rights to free-held property 
(i.e. property that one can dispose of independently of interests of other 
parties in the same address block entries, such as ARIN’s right to enforce the 
community-policies for transfers, specify the format and content of registry 
entries, etc.)

The most often cited case in this regard is probably Nortel/Microsoft sale 
which did not proceed until the agreement was conditioned as ARIN required – 
reference [In re Nortel Networks, Inc., No. 09-10138, KG 2011 WL 110098, Docket 
# 5315, at 4 (Bankr. D. Del. 2011) (assignee’s interest limited to exclusive 
right to use)]

To date ARIN hasn’t never been instructed to update our registry contrary to 
our community-developed policies, and in fact, courts have repeated enforced 
conditions on transfer in bankruptcy, probate, and other contexts that the 
parties involved must comply with ARIN’s policies.   Feel free to reach out to 
any of the many IP address brokers out there 

 and ask if you have any doubt on this...

For years, ARIN has been deliberately limiting access to the RPKI
registry as a lever to force people to sign one-sided contracts
beneficial to ARIN.  (They do the same lever thing when you sell an
address block -- at ARIN, it loses its legacy status, requiring the
recipient to pay annual rent to ARIN, and risk losing their block if
political winds shift.)

Let me make it a little simpler - ARIN’s RPKI services have been developed at 
the behest of its member community and are available to that same community who 
bear its costs.

You may not like such decisions, but you certainly have the ability to get 
involved to change things, or even run for the member-elected ARIN Board of 
Trustees if you so choose.  We recently even changed the membership structure 
recently so that any member with IPv4 or IPv6 resources (not just “ISPs”) can 
be a General Member and vote in the elections.   In the end, we are 
not-for-profit membership organization and will be accountable to members (and 
the community) that get involved in the organization.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

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)

[babydr DBA James W. Laferriere]

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
Anchors.

There are variances in how stakeholders implement this paradigm shift:
some operators move towards wholesale ignorance of non-auth databases
(like Tata); some operators use softer transition mechanisms (examples:
what RIPE NCC did in lieu of RIPE-731, or how IRRd v4 in its default
configuration magically makes RPKI-invalid IRR objects disappear).

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 there being parts of the Internet which
are not squatting on anyone's numbers *and* also are not contracted to a
specific RIR.
Kind regards,
Job
	Your final paragraph hits directly on my situation ,  That is as soon as 
I can get my small network connected again via hardline connections again .

I am not a customer of ARIN except for one asn .
I hold maintainership a couple of pre-arin /24's .

	And until a (imo) reasonable contract with pre-arin holders can be 
created AND a reasonable fund dispersement calculation with HARD Set $ values 
assigned ,  I will not be a Arin customer except for my one little ASN .  Which 
when I was assigned that resource was just $100/yr ,  Imo a reasonable cost . 
that cost has now only gone up 50% ,  Again somewhat reasonable cost ,  BUT that 
cost going UP is of concern to my meager financial status .


	I am greatly exasperated that I am not hearing about Public versions of 
RPKi repositories in the veign of ALTDB .

In other words a Publicly held and Volunteer based entity .

	Blast I wish I had the financial witheral to back such an enterprise . 
If I did it would remain totally vounteer & a not for profit & I'd really like 
it to be Voluntarilly funded by the Community .


	I ask the Community why someone or some entity IS not coming forward and 
doing so ?


Sorry about the rambling .

Twyl ,  JimL
--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

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)

[Jon Sands]

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 invalid and caused traffic disruption already a long time 
ago if it were going to. Carry on!


On 4/4/2022 8:08 PM, Jon Sands wrote:
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 error of "Prefix cannot be registered" which I assumed 
was due to it already matching an entry in NON-AUTH. The problem is 
this /24 is given to the customer by cogent, and the NON-AUTH entry 
was entered by a previous cogent customer, so we have no way of 
removing it and the email I sent to the POC for the ASN that made this 
entry years ago never got a reply.


What's the best move here? I'd rather not wait for NON-AUTH to be 
removed and *then* try and successfully create a current IRR entry. I 
see the /24 has an overlapping /8 entry in RADB from Cogent that 
should be valid, hopefully that will prevent any catastrophic routing 
decisions for this /24 in the next 24 hours but I'd rather get this 
sorted for sure instead of hoping: 
https://irrexplorer.nlnog.net/prefix/38.114.113.0/24


Emails offlist are more than welcome

On 4/4/2022 11:56 AM, Job Snijders via NANOG wrote:

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 result of this change, as validation against the
ARIN-NONAUTH IRR database will not longer be possible.

Please be aware of this upcoming event and make alternative
arrangements if you are presently relying on upon routing objects in
the ARIN-NONAUTH IRR database.

I ran an analysis just now in which I created an intersection between
prefixes observed in the BGP default-free zone and exactly matching
route:/route6: objects in ARIN-NONAUTH. I then substracted exact
matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
APNIC IRR sources. The result is a list of routes which might
experience service disruptions due to missing IRR objects.

The below 2,749 Prefix + Origin AS pairings are at risk as a result of
ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
are likely to manifest themselves in the coming 24 - 32 hours. Prior to
this announcement, ARIN consulted with its community on the future of
its IRR service.

I voiced objection and raised concerns about (what appeared to be)
limited visibility into what exactly the effects of such a database
shutdown would mean for the Internet: 
https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
Other community members also shared concerns: 
https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html

A number of graceful alternative mechanisms were proposed, but not
acted upon: 
https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html


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 perhaps were unable to
understand the message.

Please check if any of your prefixes are on the below list, and if so,
double check whether your IRR administration is able to overcome the
disappearance of ARIN-NONAUTH. Godspeed!

This tool might be useful: https://irrexplorer.nlnog.net/

Kind regards,

Job

Prefix OriginAS
100.42.100.0/24 33353
100.42.101.0/24 33353
100.42.102.0/24 33353
100.42.104.0/24 33353
100.42.105.0/24 33353
100.42.106.0/23 33353
100.42.108.0/24 33353
100.42.109.0/24 33353
100.42.96.0/23 33353
100.42.98.0/24 33353
103.11.202.0/24 33517
103.13.12.0/24 38057
103.13.135.0/24 51830
103.15.168.0/23 55532
103.196.22.0/23 7489
103.219.78.0/24 55256
103.219.79.0/24 55256
103.232.224.0/24 125
103.250.176.0/24 134795
103.250.177.0/24 134795
103.250.178.0/24 134795
103.250.179.0/24 134795
103.35.217.0/24 125
103.47.244.0/24 55256
103.88.172.0/24 136271
103.88.173.0/24 136271
103.88.174.0/24 136271
104.128.96.0/20 19233
104.142.128.0/23 33353
104.142.130.0/23 33353
104.142.136.0/22 33353
104.142.140.0/23 33353
104.142.144.0/24 33353
104.142.145.0/24 33353
104.142.146.0/24 33353
104.142.147.0/24 33353
104.142.148.0/24 33353
104.142.149.0/24 33353
104.142.152.0/24 33353
104.142.153.0/24 33353
104.142.156.0/24 33353
104.142.160.0/24 33353
104.142.164.0/24 33353
104.142.165.0/24 33353
104.142.175.0/24 33353
104.142.176.0/24 33353

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)

[John Gilmore]

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) technical achievements behind the Internet -- the decentralized
routing system.

I'm on the board of a large legacy allocation that is deliberately NOT
an ARIN (or other RIR) member.  And I have a small address block of my
own, ditto.

ARIN doesn't provide authenticated RPKI entries for just anybody.  You
have to pay them for that service.  And in order to pay them, you have
to sign their contract.  And if you sign that contract, ARIN can take
away your legacy allocation -- anytime they decide it would be in their
best interest.  Whereas, if you don't sign, the courts have held that
you have a *property right* in your IP addresses and they *belong* to
you.  As a result, most legacy address holders (a large fraction of the
Internet addresses) have declined to sign such contracts, pay such
bills, and thus can't be in the ARIN authenticated routing registry.

For years, ARIN has been deliberately limiting access to the RPKI
registry as a lever to force people to sign one-sided contracts
beneficial to ARIN.  (They do the same lever thing when you sell an
address block -- at ARIN, it loses its legacy status, requiring the
recipient to pay annual rent to ARIN, and risk losing their block if
political winds shift.)

The pro-RPKI faction also seems to have completely ignored what I
consider a major concern among anti-RPKI folks.  The distributed
Internet routing system is resilient to centralized failures, and should
remain so.  Inserting five points of failure (signatures of RIRs) would
undermine that resilience.

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 jurisdiction over those RIRs can force them to not sign
routes for sites that are politically incorrect.  How convenient -- for
authoritarians.  You can have all the IP addresses you want, you just
can't get 90% of the ISPs in the world to route packets to them.

There is no shortage of Horsemen of the Infopocalypse (child porn,
terrorism, sex slavery, Covid misinformation, manipulative propaganda,
war news, copyright violations, etc, etc, etc) that Absolutely Need To
Be Stamped Out Today whenever politicians decide that Something Must Be
Done.  As an example, we have regularly seen courts force centralized
domain registrars to reject perfectly good applicants for just such
reasons (e.g. SciHub).  The distributed Internet has "routed around"
their ability to censor such information via the routing table.  ISPs
should not hand governments a tool that they have abused so many times
in the past.

John

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)

[Jon Sands]

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 error of "Prefix cannot be registered" which I assumed was 
due to it already matching an entry in NON-AUTH. The problem is this /24 
is given to the customer by cogent, and the NON-AUTH entry was entered 
by a previous cogent customer, so we have no way of removing it and the 
email I sent to the POC for the ASN that made this entry years ago never 
got a reply.


What's the best move here? I'd rather not wait for NON-AUTH to be 
removed and *then* try and successfully create a current IRR entry. I 
see the /24 has an overlapping /8 entry in RADB from Cogent that should 
be valid, hopefully that will prevent any catastrophic routing decisions 
for this /24 in the next 24 hours but I'd rather get this sorted for 
sure instead of hoping: https://irrexplorer.nlnog.net/prefix/38.114.113.0/24


Emails offlist are more than welcome

On 4/4/2022 11:56 AM, Job Snijders via NANOG wrote:

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 result of this change, as validation against the
ARIN-NONAUTH IRR database will not longer be possible.

Please be aware of this upcoming event and make alternative
arrangements if you are presently relying on upon routing objects in
the ARIN-NONAUTH IRR database.

I ran an analysis just now in which I created an intersection between
prefixes observed in the BGP default-free zone and exactly matching
route:/route6: objects in ARIN-NONAUTH. I then substracted exact
matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
APNIC IRR sources. The result is a list of routes which might
experience service disruptions due to missing IRR objects.

The below 2,749 Prefix + Origin AS pairings are at risk as a result of
ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
are likely to manifest themselves in the coming 24 - 32 hours. Prior to
this announcement, ARIN consulted with its community on the future of
its IRR service.

I voiced objection and raised concerns about (what appeared to be)
limited visibility into what exactly the effects of such a database
shutdown would mean for the Internet: 
https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
Other community members also shared concerns: 
https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
A number of graceful alternative mechanisms were proposed, but not
acted upon: https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html

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 perhaps were unable to
understand the message.

Please check if any of your prefixes are on the below list, and if so,
double check whether your IRR administration is able to overcome the
disappearance of ARIN-NONAUTH. Godspeed!

This tool might be useful: https://irrexplorer.nlnog.net/

Kind regards,

Job

Prefix OriginAS
100.42.100.0/24 33353
100.42.101.0/24 33353
100.42.102.0/24 33353
100.42.104.0/24 33353
100.42.105.0/24 33353
100.42.106.0/23 33353
100.42.108.0/24 33353
100.42.109.0/24 33353
100.42.96.0/23 33353
100.42.98.0/24 33353
103.11.202.0/24 33517
103.13.12.0/24 38057
103.13.135.0/24 51830
103.15.168.0/23 55532
103.196.22.0/23 7489
103.219.78.0/24 55256
103.219.79.0/24 55256
103.232.224.0/24 125
103.250.176.0/24 134795
103.250.177.0/24 134795
103.250.178.0/24 134795
103.250.179.0/24 134795
103.35.217.0/24 125
103.47.244.0/24 55256
103.88.172.0/24 136271
103.88.173.0/24 136271
103.88.174.0/24 136271
104.128.96.0/20 19233
104.142.128.0/23 33353
104.142.130.0/23 33353
104.142.136.0/22 33353
104.142.140.0/23 33353
104.142.144.0/24 33353
104.142.145.0/24 33353
104.142.146.0/24 33353
104.142.147.0/24 33353
104.142.148.0/24 33353
104.142.149.0/24 33353
104.142.152.0/24 33353
104.142.153.0/24 33353
104.142.156.0/24 33353
104.142.160.0/24 33353
104.142.164.0/24 33353
104.142.165.0/24 33353
104.142.175.0/24 33353
104.142.176.0/24 33353
104.142.177.0/24 33353
104.142.180.0/24 33353
104.142.181.0/24 33353
104.142.184.0/24 33353
104.142.185.0/24 33353
104.142.186.0/24 33353
104.142.187.0/24 33353
104.142.188.0/24 33353
104.142.189.0/24 33353
104.142.190.0/24 33353
104.142.191.0/24 33353
104.142.192.0/24 33353
104.142.224.0/24 33353
104.142.248.0/21 33353
104.142.249.0/24 33353
104.142.251.0/24 33353
104.142.252.0/24 33353
104.142.253.0/24 33353
104.142.254.0/24 33353

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)

[Tom Beecher]

>
> 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 PM Kenneth Finnegan <
kennethfinnegan2...@gmail.com> wrote:

> 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 really bad / confusing few days while they tried to figure
> out why their Internet is somewhere between slightly and completely
> broken due to no action of their own.
>
> > Couple of reasons why: 1. this isn't your data and this is an
> > unexpected action on the part of the registrants,
>
> The registrants had a year to fix this themselves, and they didn't,
> which implies to me that they are unaware of the issue. How can
> something be unexpected to those who are unaware?
>
> > 2. this is a sure-fire
> > way of accumulating even more cruft in ALTDB in a way which is
> > troublesome to clean up afterwards,
>
> Is it? What is terrible about cruft sitting in IRR databases? It
> doesn't cause conflict with anyone else announcing their new address
> space from any other ASN.
>
> 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.
>
> > 3. there are several thousand
> > objects in there which are already marked as proxy registrations, and
> > are already likely to be inaccurate,
>
> And there's lots of non-proxy registrations which are inaccurate too.
> The fact that RPSL was so contrived and routing security has been so
> sidecar for decades that carriers have found it easier to create proxy
> registrations vs getting their customers to go spend money on an RADB
> account or figure out this IRR thing in general means that proxy
> registrations are a reality we live in.
>
> IRR objects lacking any kind of expiration date was a failing of the
> original design. Proxy registration or not, when a company shuts down
> operations, there is kind of by definition no one left around to care
> about cleaning up their IRR records. If RIRs published RPKI ROAs for
> unallocated space to AS0 to give us an authoritative way to know that
> the address space is defunct, clean up could happen automatically. I
> looked into using the RIR registration databases to try and find
> objects which predate the current allocation, but even that data isn't
> clean enough to trace which objects are actually "stale" in some
> definition of the term.
>
> > 4. you're losing authentication
> > information for people to self-manage their registrations
>
> Anyone on that list who would like to self-manage your IRR objects,
> PLEASE email me saying so. Bonus points if you include a reason why
> you waited until T-0 to change your mind on managing them.
>
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
>
> On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard  wrote:
> >
> > 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
> > unexpected action on the part of the registrants, 2. this is a sure-fire
> > way of accumulating even more cruft in ALTDB in a way which is
> > troublesome to clean up afterwards, 3. there are several thousand
> > objects in there which are already marked as proxy registrations, and
> > are already likely to be inaccurate, 4. you're losing authentication
> > information for people to self-manage their registrations, and 5. you
> > have likely not cross-checked this data against RIR transfers /
> > de-registrations - it's not really possible to do with with the
> > arin-nonauth db because that db doesn't include the last-modified
> > timestamp, and the changed: attribute is unreliable.
> >
> > Nick
>

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]

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 really bad / confusing few days while they tried to figure
out why their Internet is somewhere between slightly and completely
broken due to no action of their own.

> Couple of reasons why: 1. this isn't your data and this is an
> unexpected action on the part of the registrants,

The registrants had a year to fix this themselves, and they didn't,
which implies to me that they are unaware of the issue. How can
something be unexpected to those who are unaware?

> 2. this is a sure-fire
> way of accumulating even more cruft in ALTDB in a way which is
> troublesome to clean up afterwards,

Is it? What is terrible about cruft sitting in IRR databases? It
doesn't cause conflict with anyone else announcing their new address
space from any other ASN.

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.

> 3. there are several thousand
> objects in there which are already marked as proxy registrations, and
> are already likely to be inaccurate,

And there's lots of non-proxy registrations which are inaccurate too.
The fact that RPSL was so contrived and routing security has been so
sidecar for decades that carriers have found it easier to create proxy
registrations vs getting their customers to go spend money on an RADB
account or figure out this IRR thing in general means that proxy
registrations are a reality we live in.

IRR objects lacking any kind of expiration date was a failing of the
original design. Proxy registration or not, when a company shuts down
operations, there is kind of by definition no one left around to care
about cleaning up their IRR records. If RIRs published RPKI ROAs for
unallocated space to AS0 to give us an authoritative way to know that
the address space is defunct, clean up could happen automatically. I
looked into using the RIR registration databases to try and find
objects which predate the current allocation, but even that data isn't
clean enough to trace which objects are actually "stale" in some
definition of the term.

> 4. you're losing authentication
> information for people to self-manage their registrations

Anyone on that list who would like to self-manage your IRR objects,
PLEASE email me saying so. Bonus points if you include a reason why
you waited until T-0 to change your mind on managing them.

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/

On Mon, Apr 4, 2022 at 4:04 PM Nick Hilliard  wrote:
>
> 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
> unexpected action on the part of the registrants, 2. this is a sure-fire
> way of accumulating even more cruft in ALTDB in a way which is
> troublesome to clean up afterwards, 3. there are several thousand
> objects in there which are already marked as proxy registrations, and
> are already likely to be inaccurate, 4. you're losing authentication
> information for people to self-manage their registrations, and 5. you
> have likely not cross-checked this data against RIR transfers /
> de-registrations - it's not really possible to do with with the
> arin-nonauth db because that db doesn't include the last-modified
> timestamp, and the changed: attribute is unreliable.
>
> Nick

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)

[Tom Beecher]

>
> 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
> similar reminders.
>

I'm extremely grateful to Job and Kenneth for stepping in to address
> ARIN's failure here before it ruined a lot of people's weeks.
>

ARIN clearly stated they were attempting to reach people with records for
the last year. If the contact info you had was correct and they still
didn't get to you, perhaps it better to speak with them to figure out why
before just branding it a 'failure'.


On Mon, Apr 4, 2022 at 5:59 PM Wes George  wrote:

>
> 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 perhaps were unable to
> > understand the message.
>
> Delurking to underscore this.
>
> On 2/16/2022 4:33 PM, John Curran via NANOG wrote:
> > We also notified by email Points of Contact (POCs) of organizations who
> > have objects in the ARIN-NONAUTH database of the retirement date and
> > offered them our assistance with the
> >   transition.
>
> 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
> similar reminders.
>
> I do not see any OrgID-specific communication about this.
>
> No message saying "you are receiving this notification because you have
> the following items that are in this thing we're retiring and nowhere
> else" or "this may cause problems with your routes being propagated on
> the internet" or some similar warning, or even something in the generic
> note about how one should check to confirm whether they are affected. I
> didn't realize until looking at the list Job provided that this was
> something that affected me specifically, so the "don't care bits" were
> set on the generic form letters I got from ARIN.
>
> Nowhere does it say clearly what action should be taken in response
> other than to contact ARIN with questions. It's getting me to generate
> ROAs for my prefixes, so good job there, but ARIN failed in its efforts
> to communicate what was happening in terms of the actual effects in
> order to make an appropriate call to action for those who were either
> like me, thinking we weren't affected, or are unfamiliar with how this
> interacts with the rest of the Internet's routing infrastructure.
>
> I'm extremely grateful to Job and Kenneth for stepping in to address
> ARIN's failure here before it ruined a lot of people's weeks.
>
> Wes George
>
>

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)

[Nick Hilliard]

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 
unexpected action on the part of the registrants, 2. this is a sure-fire 
way of accumulating even more cruft in ALTDB in a way which is 
troublesome to clean up afterwards, 3. there are several thousand 
objects in there which are already marked as proxy registrations, and 
are already likely to be inaccurate, 4. you're losing authentication 
information for people to self-manage their registrations, and 5. you 
have likely not cross-checked this data against RIR transfers / 
de-registrations - it's not really possible to do with with the 
arin-nonauth db because that db doesn't include the last-modified 
timestamp, and the changed: attribute is unreliable.


Nick

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]

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 networks like Tata announcing that they won't honor route objects
> > > created in non-authoratative IRR DBs after late last year and plan to 
> > > ignore
> > > them entirely by late next year?  i.e.
> > > 
> > > From: https://lg.as6453.net/doc/cust-routing-policy.html
> > > 
> > >   Special note, deprecation of non-authoritative registries
> > > 
> > >   Please note that 'route' and 'route6' objects created after 2021-Aug-15
> > >   in non-authoritative registries like RADB, NTTCOM, ALTDB and others
> > >   will not work. Objects created before that date will continue to work 
> > > till
> > >   2023-Aug-15. It is recommended to create RPKI ROA objects instead. In
> > >   rare cases if that's not possible, 'route' and 'route6' must be created
> > >   in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, 
> > > RIPE,
> > >   NIC.br or IDNIC.
> > 
> > I very much appreciate Tata's efforts to strive to only use authoritive
> > data when making BGP routing decisions; however the scope of their
> > charter is of course confined to just Tata's own operations. Tata's
> > routing policies affect only Tata's customer cone.
> 
> I'm (well, work is) a Tata customer.  So their policy wrt which IRR's
> they'll honor objects in matters to me, and going forward, it makes no sense
> for us to create new objects in ALTDB or RADB...and those proxy
> registrations Kenneth created in ALTDB, if any of those networks are
> originated by Tata customers, I presume the new ALTDB objects won't cause
> Tata prefix-list filters to include those routes.

Right.

> I just wonder if Tata is alone leading the charge to deprecate non-auth
> IRRs, or if there are other notable networks with similar policies?

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
Anchors.

There are variances in how stakeholders implement this paradigm shift:
some operators move towards wholesale ignorance of non-auth databases
(like Tata); some operators use softer transition mechanisms (examples:
what RIPE NCC did in lieu of RIPE-731, or how IRRd v4 in its default
configuration magically makes RPKI-invalid IRR objects disappear).

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 there being parts of the Internet which
are not squatting on anyone's numbers *and* also are not contracted to a
specific RIR.

Kind regards,

Job

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)

[Jon Lewis]

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 IRR DBs after late last year and plan to ignore
them entirely by late next year?  i.e.

From: https://lg.as6453.net/doc/cust-routing-policy.html

  Special note, deprecation of non-authoritative registries

  Please note that 'route' and 'route6' objects created after 2021-Aug-15
  in non-authoritative registries like RADB, NTTCOM, ALTDB and others
  will not work. Objects created before that date will continue to work till
  2023-Aug-15. It is recommended to create RPKI ROA objects instead. In
  rare cases if that's not possible, 'route' and 'route6' must be created
  in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE,
  NIC.br or IDNIC.


I very much appreciate Tata's efforts to strive to only use authoritive
data when making BGP routing decisions; however the scope of their
charter is of course confined to just Tata's own operations. Tata's
routing policies affect only Tata's customer cone.


I'm (well, work is) a Tata customer.  So their policy wrt which IRR's 
they'll honor objects in matters to me, and going forward, it makes no 
sense for us to create new objects in ALTDB or RADB...and those proxy 
registrations Kenneth created in ALTDB, if any of those networks are 
originated by Tata customers, I presume the new ALTDB objects won't cause 
Tata prefix-list filters to include those routes.


I just wonder if Tata is alone leading the charge to deprecate non-auth 
IRRs, or if there are other notable networks with similar policies?



--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

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]

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 too many small networks who likely don't
> > have a savy networking engineering team.
> > 
> > In my opinion, they are not acceptable collateral damage to
> > demonstrate ARIN's lack of regard for the community in shutting this
> > down without a transition plan for the RPSL objects, so as one of the
> > admins for the ALTDB IRR database, I've taken it upon myself to create
> > proxy registrations for all of these prefixes in ALTDB.
> > 
> > Like any proxy registration, asset owners are welcome to contact the
> > maint POC, and if no response from them, db-ad...@altdb.net,
> > requesting that stale records be deleted, but please also note that
> > ALTDB automatically deletes any route objects which conflict with a
> > publishes RPKI ROA, so the most effective way to clean up stale IRR
> > records is to publish RPKI ROAs for your address space.
> 
> Does any other IRR do that?

An event not too dissimilar to the current situation at hand was when
the server systems on which the "SAVVIS" IRR database existed
experienced a catastrophic failure. At that time, Savvis had already
been acquired by another entity, but they were unable to
integrate/migrate dataset in time, and no backups appeared to be
available.

After some delibration and attempts to untangle the spaghetti of
potential consequences for the BGP customer cone of my then-employer, I
took the liberty to copy (proxy register) a significant number of
route+route6 objects into NTTCOM (similar to what Kenneth did) because
the alternative seemed worse. Deprecation of IRR databases is something
very few people in this industry really have hands-on experience with.

> What does ALTDB do if a route object exists (or multiple route objects exist
> for the same route with different origins) and multiple ROAs exist allowing
> the route to be originated by multiple ASNs?  Technically, some of those
> ROAs would conflict with some route objects.

I can't speak with any authority on ALTDB operational matters, but I
think they use a tool based on https://github.com/job/irr-nonauth-cleanup/

The 'irr-nonauth-cleanup' utility uses an algorithm similar to what is
described in RFC 6811 in context of classifying BGP routes, and also is
similar to what RIPE NCC uses to periodically clean up the
"RIPE-NONAUTH" IRR database. RIPE NCC's cleanup effort was codified
through community consensus and published as 
https://www.ripe.net/publications/docs/ripe-731

In the same spirit as RFC 6811 stipulates - RPKI ROAs never are
considered "in conflict" with each other. As long as at least one ROA
permits the specific (Prefix, Origin AS) tuple at hand to exist, the IRR
object may exist. It's fine for multiple ROAs to exist which cover the
same address space, this is what makes migrations/reconfigurations
possible.

> 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 IRR DBs after late last year and plan to ignore
> them entirely by late next year?  i.e.
> 
> From: https://lg.as6453.net/doc/cust-routing-policy.html
> 
>   Special note, deprecation of non-authoritative registries
> 
>   Please note that 'route' and 'route6' objects created after 2021-Aug-15
>   in non-authoritative registries like RADB, NTTCOM, ALTDB and others
>   will not work. Objects created before that date will continue to work till
>   2023-Aug-15. It is recommended to create RPKI ROA objects instead. In
>   rare cases if that's not possible, 'route' and 'route6' must be created
>   in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE,
>   NIC.br or IDNIC.

I very much appreciate Tata's efforts to strive to only use authoritive
data when making BGP routing decisions; however the scope of their
charter is of course confined to just Tata's own operations. Tata's
routing policies affect only Tata's customer cone.

Depending on the exact characteristics of one's customer cone it may be
feasible to only use RIR-provided IRR data sources, but it's not hard to
imagine that for some providers this is a bridge too far at this point
in time.

Kind regards,

Job

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)

[Wes George]

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 perhaps were unable to
understand the message.


Delurking to underscore this.

On 2/16/2022 4:33 PM, John Curran via NANOG wrote:

We also notified by email Points of Contact (POCs) of organizations who
have objects in the ARIN-NONAUTH database of the retirement date and
offered them our assistance with the
  transition.


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 
similar reminders.


I do not see any OrgID-specific communication about this.

No message saying "you are receiving this notification because you have 
the following items that are in this thing we're retiring and nowhere 
else" or "this may cause problems with your routes being propagated on 
the internet" or some similar warning, or even something in the generic 
note about how one should check to confirm whether they are affected. I 
didn't realize until looking at the list Job provided that this was 
something that affected me specifically, so the "don't care bits" were 
set on the generic form letters I got from ARIN.


Nowhere does it say clearly what action should be taken in response 
other than to contact ARIN with questions. It's getting me to generate 
ROAs for my prefixes, so good job there, but ARIN failed in its efforts 
to communicate what was happening in terms of the actual effects in 
order to make an appropriate call to action for those who were either 
like me, thinking we weren't affected, or are unfamiliar with how this 
interacts with the rest of the Internet's routing infrastructure.


I'm extremely grateful to Job and Kenneth for stepping in to address 
ARIN's failure here before it ruined a lot of people's weeks.


Wes George

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)

[Jon Lewis]

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 team.

In my opinion, they are not acceptable collateral damage to
demonstrate ARIN's lack of regard for the community in shutting this
down without a transition plan for the RPSL objects, so as one of the
admins for the ALTDB IRR database, I've taken it upon myself to create
proxy registrations for all of these prefixes in ALTDB.

Like any proxy registration, asset owners are welcome to contact the
maint POC, and if no response from them, db-ad...@altdb.net,
requesting that stale records be deleted, but please also note that
ALTDB automatically deletes any route objects which conflict with a
publishes RPKI ROA, so the most effective way to clean up stale IRR
records is to publish RPKI ROAs for your address space.


Does any other IRR do that?

What does ALTDB do if a route object exists (or multiple route objects 
exist for the same route with different origins) and multiple ROAs exist 
allowing the route to be originated by multiple ASNs?  Technically, some 
of those ROAs would conflict with some route objects.


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 IRR DBs after late last year and plan 
to ignore them entirely by late next year?  i.e.


From: https://lg.as6453.net/doc/cust-routing-policy.html

  Special note, deprecation of non-authoritative registries

  Please note that 'route' and 'route6' objects created after 2021-Aug-15
  in non-authoritative registries like RADB, NTTCOM, ALTDB and others
  will not work. Objects created before that date will continue to work till
  2023-Aug-15. It is recommended to create RPKI ROA objects instead. In
  rare cases if that's not possible, 'route' and 'route6' must be created
  in the authoritative registry - AfriNIC, APNIC, ARIN, LACNIC, RIPE, RIPE,
  NIC.br or IDNIC.

Once upon a time, RADB and ALTDB were (at least in my experience) the 
IRR's to use, but it seems now that all the RIRs provide authoratative IRR 
service (and some networks are deprecating the non-auth ones), it's time 
for us to move our records to the appropriate RIR IRRs.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

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]

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 collateral damage to
demonstrate ARIN's lack of regard for the community in shutting this
down without a transition plan for the RPSL objects, so as one of the
admins for the ALTDB IRR database, I've taken it upon myself to create
proxy registrations for all of these prefixes in ALTDB.

Like any proxy registration, asset owners are welcome to contact the
maint POC, and if no response from them, db-ad...@altdb.net,
requesting that stale records be deleted, but please also note that
ALTDB automatically deletes any route objects which conflict with a
publishes RPKI ROA, so the most effective way to clean up stale IRR
records is to publish RPKI ROAs for your address space.
--
Kenneth Finnegan
ALTDB Admin
http://blog.thelifeofkenneth.com/

On Mon, Apr 4, 2022 at 8:59 AM Job Snijders via NANOG  wrote:
>
> 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 result of this change, as validation against the
> > ARIN-NONAUTH IRR database will not longer be possible.
> >
> > Please be aware of this upcoming event and make alternative
> > arrangements if you are presently relying on upon routing objects in
> > the ARIN-NONAUTH IRR database.
>
> I ran an analysis just now in which I created an intersection between
> prefixes observed in the BGP default-free zone and exactly matching
> route:/route6: objects in ARIN-NONAUTH. I then substracted exact
> matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
> APNIC IRR sources. The result is a list of routes which might
> experience service disruptions due to missing IRR objects.
>
> The below 2,749 Prefix + Origin AS pairings are at risk as a result of
> ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
> are likely to manifest themselves in the coming 24 - 32 hours. Prior to
> this announcement, ARIN consulted with its community on the future of
> its IRR service.
>
> I voiced objection and raised concerns about (what appeared to be)
> limited visibility into what exactly the effects of such a database
> shutdown would mean for the Internet: 
> https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
> Other community members also shared concerns: 
> https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
> A number of graceful alternative mechanisms were proposed, but not
> acted upon: 
> https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html
>
> 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 perhaps were unable to
> understand the message.
>
> Please check if any of your prefixes are on the below list, and if so,
> double check whether your IRR administration is able to overcome the
> disappearance of ARIN-NONAUTH. Godspeed!
>
> This tool might be useful: https://irrexplorer.nlnog.net/
>
> Kind regards,
>
> Job
>

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]

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 result of this change, as validation against the
> ARIN-NONAUTH IRR database will not longer be possible.
> 
> Please be aware of this upcoming event and make alternative
> arrangements if you are presently relying on upon routing objects in
> the ARIN-NONAUTH IRR database.

I ran an analysis just now in which I created an intersection between
prefixes observed in the BGP default-free zone and exactly matching
route:/route6: objects in ARIN-NONAUTH. I then substracted exact
matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
APNIC IRR sources. The result is a list of routes which might
experience service disruptions due to missing IRR objects.

The below 2,749 Prefix + Origin AS pairings are at risk as a result of
ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
are likely to manifest themselves in the coming 24 - 32 hours. Prior to
this announcement, ARIN consulted with its community on the future of
its IRR service.

I voiced objection and raised concerns about (what appeared to be)
limited visibility into what exactly the effects of such a database
shutdown would mean for the Internet: 
https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
Other community members also shared concerns: 
https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
A number of graceful alternative mechanisms were proposed, but not
acted upon: https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html

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 perhaps were unable to
understand the message.

Please check if any of your prefixes are on the below list, and if so,
double check whether your IRR administration is able to overcome the
disappearance of ARIN-NONAUTH. Godspeed!

This tool might be useful: https://irrexplorer.nlnog.net/

Kind regards,

Job

Prefix OriginAS
100.42.100.0/24 33353
100.42.101.0/24 33353
100.42.102.0/24 33353
100.42.104.0/24 33353
100.42.105.0/24 33353
100.42.106.0/23 33353
100.42.108.0/24 33353
100.42.109.0/24 33353
100.42.96.0/23 33353
100.42.98.0/24 33353
103.11.202.0/24 33517
103.13.12.0/24 38057
103.13.135.0/24 51830
103.15.168.0/23 55532
103.196.22.0/23 7489
103.219.78.0/24 55256
103.219.79.0/24 55256
103.232.224.0/24 125
103.250.176.0/24 134795
103.250.177.0/24 134795
103.250.178.0/24 134795
103.250.179.0/24 134795
103.35.217.0/24 125
103.47.244.0/24 55256
103.88.172.0/24 136271
103.88.173.0/24 136271
103.88.174.0/24 136271
104.128.96.0/20 19233
104.142.128.0/23 33353
104.142.130.0/23 33353
104.142.136.0/22 33353
104.142.140.0/23 33353
104.142.144.0/24 33353
104.142.145.0/24 33353
104.142.146.0/24 33353
104.142.147.0/24 33353
104.142.148.0/24 33353
104.142.149.0/24 33353
104.142.152.0/24 33353
104.142.153.0/24 33353
104.142.156.0/24 33353
104.142.160.0/24 33353
104.142.164.0/24 33353
104.142.165.0/24 33353
104.142.175.0/24 33353
104.142.176.0/24 33353
104.142.177.0/24 33353
104.142.180.0/24 33353
104.142.181.0/24 33353
104.142.184.0/24 33353
104.142.185.0/24 33353
104.142.186.0/24 33353
104.142.187.0/24 33353
104.142.188.0/24 33353
104.142.189.0/24 33353
104.142.190.0/24 33353
104.142.191.0/24 33353
104.142.192.0/24 33353
104.142.224.0/24 33353
104.142.248.0/21 33353
104.142.249.0/24 33353
104.142.251.0/24 33353
104.142.252.0/24 33353
104.142.253.0/24 33353
104.142.254.0/24 33353
104.142.255.0/24 33353
104.143.64.0/20 13739
104.152.174.0/24 393586
104.152.175.0/24 393586
104.152.40.0/22 10302
104.153.160.0/22 36203
104.153.180.0/23 26021
104.153.182.0/23 26414
104.156.200.0/22 21743
104.167.96.0/19 394991
104.192.254.0/24 14244
104.193.40.0/22 396317
104.219.166.0/23 54804
104.225.100.0/24 36236
104.225.102.0/24 36236
104.225.103.0/24 36236
104.225.107.0/24 36236
104.225.11.0/24 36236
104.225.2.0/24 36236
104.225.21.0/24 36236
104.225.22.0/24 36236
104.225.99.0/24 36236
104.243.160.0/20 63353
104.244.144.0/21 14869
104.244.208.0/24 13737
104.244.210.0/24 13737
104.255.40.0/21 23465
104.37.242.0/24 7311
107.182.192.0/21 22534
107.182.200.0/21 22534
107.191.224.0/21 23317
107.191.232.0/22 23317
108.161.224.0/20 14244
108.169.208.0/23 62943
119.252.189.0/24 56106
12.10.107.0/24 40230
12.109.82.0/23 20034
12.111.223.0/24 23094
12.144.72.0/22 33247
12.148.232.0/22 33247
12.149.246.0/23 33247
12.151.71.0/24 33358
12.175.119.0/24 23094
12.182.253.0/24 40110
12.188.18.0/24 36136
12.191.163.0/24 27632
12.199.50.0/24 40230
12.203.197.0/24 22034
12.205.14.0/24 40230
12.229.190.0/23 1641
12.229.60.8/29 46826
12.27.186.0/23 33247
12.27.188.0/22 

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

[David Ratkay]

Looks like Honeywell will be affected.

On Sat, Apr 2, 2022, 5:11 PM John Curran  wrote:

> NANOGers -
>
> 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 result of this change, as validation against the
> ARIN-NONAUTH IRR database will not longer be possible.
>
> Please be aware of this upcoming event and *make alternative arrangements
> if you are presently relying on upon routing objects in the ARIN-NONAUTH
> IRR database.*
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
> Begin forwarded message:
>
> *From: *John Curran 
> *Subject: **TIMELY - IMPORTANT NOTICE - Retirement of ARIN
> Non-Authenticated IRR scheduled for 4 April 2022*
> *Date: *25 March 2022 at 7:26:06 PM EDT
> *To: *nanog list 
>
> NANOGers -
>
> Please take note of the following event that will take place in less than
> 10 days time - *ARIN will shut down the ARIN-NONAUTH IRR database on
> Monday, 4 April 2022 at 12:00 PM ET*
>
> Any networks relying on upon routing objects in the ARIN-NONAUTH IRR
> database should be actively working on alternative arrangements.
>
>
> If you have questions about this transition or need any assistance, you
> can contact ARIN by:
>
> • Submitting an Ask ARIN ticket or chat with us using your ARIN Online
> account
> • emailing the Routing Security Team at routing.secur...@arin.net
> • contacting the Registration Services Help Desk by phone Monday through
> Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660
>
>
> Thank you!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>
> Begin forwarded message:
>
> *From: *John Curran 
> *Subject: **IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR
> rescheduled for 4 April 2022*
> *Date: *16 February 2022 at 4:33:24 PM EST
> *To: *NANOG Operators' Group 
>
> NANOGers -
>
> An important reminder – On 4 April 2022, ARIN's non-authenticated Internet
> Routing Registry (IRR) will be retired.
>
> Please review the attached notice for details, and do not hesitate to
> contact ARIN if you have any questions about this transition or need
> assistance.
>
> I ask that you do not hesitate to forward this notice to any others you
> know that are potentially unaware & impacted by this important transition.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> Begin forwarded message:
>
> *From: *ARIN 
> *Subject: **[arin-announce] UPDATE: Retirement of ARIN Non-Authenticated
> IRR rescheduled for 4 April 2022*
> *Date: *28 January 2022 at 9:01:07 PM GMT+4
> *To: *"arin-annou...@arin.net" 
>
> This announcement is to inform you that the retirement of the ARIN
> non-authenticated Internet Routing Registry (IRR) has been rescheduled to 4
> April 2022 at 12:00 PM EST. After this time, users will no longer be able
> to create, update, or delete records in the ARIN-NONAUTH database, and the
> ARIN-NONAUTH data stream will no longer be available in Near Real Time
> Mirroring (NRTM) or via FTP or Whois Port 43. This date change is being
> made in order to ensure that the first day after retirement does not fall
> on a Friday.
>
> The following information is from the initial announcement:
>
> ARIN has been engaged in a multi-year project to create and deploy a new
> and improved Internet Routing Registry (IRR). As a result of these efforts,
> ARIN now provides users with the ability to create, update, and delete
> objects in ARIN’s authenticated IRR database using ARIN Online or ARIN’s
> RESTful API. Unfortunately, use of ARIN’s previous non-authenticated
> email-based IRR service actually increased after ARIN released its
> authenticated IRR, in opposition to the outcome ARIN anticipated when
> improving its IRR.
>
> On 8 February 2021, ARIN held a consultation to solicit input on the
> retirement of ARIN’s non-authenticated email-based IRR service. This
> retirement was originally scheduled for 30 September 2021. Based on
> community input, the proposed date for the ARIN-NONAUTH retirement was
> delayed to 31 March 2022 to allow more transition time for users. We also
> notified by email Points of Contact (POCs) of organizations who have
> objects in the ARIN-NONAUTH database of the retirement date and offered
> them our assistance with the transition.
>
> If you have questions about this transition or need assistance, you can
> contact us by:
>
> • submitting an Ask ARIN ticket or chat with us using your ARIN Online
> account
> • emailing the Routing Security Team at routing.secur...@arin.net
> • contacting the Registration Services Help Desk by phone Monday through
> Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660
>
> Regards,
>
> Brad Gorman
> Senior Product Owner, Routing Security
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>

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

[John Curran]

NANOGers -

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 result of this change, as validation against the ARIN-NONAUTH 
IRR database will not longer be possible.

Please be aware of this upcoming event and make alternative arrangements if you 
are presently relying on upon routing objects in the ARIN-NONAUTH IRR database.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: John Curran mailto:jcur...@arin.net>>
Subject: TIMELY - IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR 
scheduled for 4 April 2022
Date: 25 March 2022 at 7:26:06 PM EDT
To: nanog list mailto:nanog@nanog.org>>

NANOGers -

Please take note of the following event that will take place in less than 10 
days time - ARIN will shut down the ARIN-NONAUTH IRR database on Monday, 4 
April 2022 at 12:00 PM ET

Any networks relying on upon routing objects in the ARIN-NONAUTH IRR database 
should be actively working on alternative arrangements.

If you have questions about this transition or need any assistance, you can 
contact ARIN by:

• Submitting an Ask ARIN ticket or chat with us using your ARIN Online account
• emailing the Routing Security Team at 
routing.secur...@arin.net
• contacting the Registration Services Help Desk by phone Monday through 
Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660

Thank you!
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: John Curran mailto:jcur...@arin.net>>
Subject: IMPORTANT NOTICE - Retirement of ARIN Non-Authenticated IRR 
rescheduled for 4 April 2022
Date: 16 February 2022 at 4:33:24 PM EST
To: NANOG Operators' Group mailto:nanog@nanog.org>>

NANOGers -

An important reminder – On 4 April 2022, ARIN's non-authenticated Internet 
Routing Registry (IRR) will be retired.

Please review the attached notice for details, and do not hesitate to contact 
ARIN if you have any questions about this transition or need assistance.

I ask that you do not hesitate to forward this notice to any others you know 
that are potentially unaware & impacted by this important transition.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] UPDATE: Retirement of ARIN Non-Authenticated IRR 
rescheduled for 4 April 2022
Date: 28 January 2022 at 9:01:07 PM GMT+4
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

This announcement is to inform you that the retirement of the ARIN 
non-authenticated Internet Routing Registry (IRR) has been rescheduled to 4 
April 2022 at 12:00 PM EST. After this time, users will no longer be able to 
create, update, or delete records in the ARIN-NONAUTH database, and the 
ARIN-NONAUTH data stream will no longer be available in Near Real Time 
Mirroring (NRTM) or via FTP or Whois Port 43. This date change is being made in 
order to ensure that the first day after retirement does not fall on a Friday.

The following information is from the initial announcement:

ARIN has been engaged in a multi-year project to create and deploy a new and 
improved Internet Routing Registry (IRR). As a result of these efforts, ARIN 
now provides users with the ability to create, update, and delete objects in 
ARIN’s authenticated IRR database using ARIN Online or ARIN’s RESTful API. 
Unfortunately, use of ARIN’s previous non-authenticated email-based IRR service 
actually increased after ARIN released its authenticated IRR, in opposition to 
the outcome ARIN anticipated when improving its IRR.

On 8 February 2021, ARIN held a consultation to solicit input on the retirement 
of ARIN’s non-authenticated email-based IRR service. This retirement was 
originally scheduled for 30 September 2021. Based on community input, the 
proposed date for the ARIN-NONAUTH retirement was delayed to 31 March 2022 to 
allow more transition time for users. We also notified by email Points of 
Contact (POCs) of organizations who have objects in the ARIN-NONAUTH database 
of the retirement date and offered them our assistance with the transition.

If you have questions about this transition or need assistance, you can contact 
us by:

• submitting an Ask ARIN ticket or chat with us using your ARIN Online account
• emailing the Routing Security Team at 
routing.secur...@arin.net
• contacting the Registration Services Help Desk by phone Monday through 
Friday, 7:00 AM to 7:00 PM ET at +1.703.227.0660

Regards,

Brad Gorman
Senior Product Owner, Routing Security
American Registry for Internet Numbers (ARIN)