IRRD v4 Migration FAQ
Below is a list of relevant questions for the upcoming IRRDv4 Launch on November 13th, 2023.
If your question is not on this list, please contact RADb Support.
Frequently Asked Questions
- Does this transition require updates to NRTM configurations?
- What objects will be imported?
- What are the "admin-c/tech-c" attributes used for?
- What is a ROLE object?
- How are invalid nic-handles handled at import?
- Does this transition require that I undertake RPKI?
- Do I need to update my maintainer object?
- Will you eventually perform a clean up of RPKI-Invalid objects?
- Will I have to update my maintainer password?
- Will this impact my existing objects?
- How do I check my objects RPKI status?
- Will RPKI-Invalid route objects be removed?
- Will the existing objects and database still be in place?
- "Prevention of RPKI-Invalid objects from being created in RADb" - Is this only for new objects?
- If there is an existing route object with conflicting ROA information, would this be deleted? Or is this just for the creation of new route-objects?
- Would we be able to query our own records to find invalid objects to fix or delete?
- Are there test servers available?
- Can you provide samples of RPKI output?
- How can I list all route objects with RPKI status?
Does this transition require updates to NRTM configurations?
Yes, whois.radb.net
will no longer answer NRTM queries. The new host for mirroring
is nrtm.radb.net
on port 43. In addition to this hostname change the CURRENTSERIAL
is being reset back to 0. A reseed will be required.
What objects will be imported?
Everything from the IRRDv3 database export will be imported.
What are the "admin-c/tech-c" attributes used for?
"admin-c" and/or "tech-c" attributes refer to nic-handles used for point of contacts with RIRs (ARIN, RIPE, LACNIC, etc..)
What is a ROLE object?
Role objects publish details of the technical or administrative contacts associated with a maintainer.
It is recommended that you use a unique name for your Role object.
You can create this object in the RADb Portal.
How are invalid nic-handles handled at import?
All existing objects are imported as-is.
Any updates after the import to an object with invalid nic-handle(s) will need to be corrected at that time.
Does this transition require that I undertake RPKI?
No, but if you have RPKI Invalid
objects, then they will no longer be visible to query.
Do I need to update my maintainer object?
No, but if there is incorrect information, you can update it in the RADb Portal.
Will you eventually perform a clean up of RPKI-Invalid objects?
No objects will be deleted.
Invalid
objects will be marked as such and then filtered out of query responses.
Will I have to update my maintainer password?
No changes to your maintainer password are required.
Will this impact my existing objects?
It will not unless your objects are RPKI Invalid
.
RPKI Invalid
objects will no longer visible in a query.
Objects that have not_found
or valid
RPKI will not be effected.
How do I check my objects RPKI status?
Customers can check their objects for RPKI status using the RIPE RPKI Validator.
If the object is Not Found
or Valid
then the object will not be impacted.
Invalid
objects will no longer show up in a query.
Will RPKI-Invalid route objects be removed?
The initial import of IRRDv3 data will include all objects, once IRRDv4 is live, RPKI Invalid
objects will be filtered from query responses.
Nothing will be deleted from the database.
Qnly filtered for RPKI state.
Will the existing objects and database still be in place?
All existing objects will be imported (unless there is a syntax issue with the object that we will resolve or work with the maintainer to correct).
Nothing is deleted.
Going forward new route objects that are created or updated that are RPKI Invalid
will be rejected.
"Prevention of RPKI-Invalid objects from being created in RADb" - Is this only for new objects?
Existing objects will be imported regardless of the RPKI status.
They will then have a RPKI state applied after IRRDv4 has had a chance to evaluate them.
Any new objects that are Invalid
will be rejected and any modification of an existing Invalid
object will be rejected as well.
If there is an existing route object with conflicting ROA information, would this be deleted? Or is this just for the creation of new route-objects?
Nothing is deleted.
Invalid
objects are filtered from query responses.
New objects will be rejected that are not RPKI Valid
.
Would we be able to query our own records to find invalid objects to fix or delete?
The RPKI filter can be disabled for a connection with the !fno-rpki-filter
command.
The filter is disabled only for !r
queries and all RIPE style queries.
For example:
$ nc whois.radb.net 43
!!
!fno-rpki-filter
<object-to-query>
The objects will have the rpki-ov-state:
attribute which will be one of valid
, invalid
, or not_found
.
We will also be updating the web UI to include this state as a badge on the route object listings.
Are there test servers available?
Yes, the following demo environments are available for your testing (please use your existing credentials):
- whois2.radb.net - IRRDv4 with current RADb objects and live mirroring of other RIRs
- whois2demo.radb.net - IRRDv4 with sample data (IRRDv4 version of whoisdemo.radb.net)
- wwwdemo.radb.net - demo web portal backed by whois2.radb.net
- apidemo2.radb.net - demo API (available October 1st)
Can you provide samples of RPKI output?
Yes, below are examples of the three possible states (valid
, invalid
, not_found
) route(6) object could report.
Valid RPKI
$ whois -h whois2.radb.net -- 192.122.184.0/21
route: 192.122.184.0/21
descr: MERIT Network Inc.
1000 Oakbrook Drive, Suite 200
Ann Arbor
MI 48104, USA
origin: AS237
mnt-by: MAINT-AS237
changed: [email protected] 20080802
source: RADB
rpki-ov-state: valid
Not Found RPKI
$ whois -h whois2.radb.net -- 198.17.132.0/23
route: 198.17.132.0/23
descr: Western Michigan University
Academic Computing Services
Kalamazoo
MI 49008, USA
origin: AS237
mnt-by: MAINT-AS237
changed: [email protected] 20080802
source: RADB
rpki-ov-state: not_found # No ROAs found, or RPKI validation not enabled for source
Invalid RPKI
Invalid objects are normally not visible when queried but can be view by adding the !fno-rpki-filter
filter.
$ nc whois2.radb.net 43
!!
!fno-rpki-filter
A103
Filtering out RPKI invalids is disabled for !r and RIPE style queries for the rest of this connection.
C
93.175.147.0/24
route: 93.175.147.0/24
descr: RIPE-NCC-RIS Routing Certification Beacon Prefix (invalid ROA)
mnt-by: RIPE-NCC-RIS-MNT
origin: AS12654
pingable: 93.175.147.1
ping-hdl: DUMY-RIPE
created: 2010-12-13T16:14:50Z
last-modified: 2014-09-25T14:31:40Z
source: RIPE
remarks: ****************************
remarks: * THIS OBJECT IS MODIFIED
remarks: * Please note that all data that is generally regarded as personal
remarks: * data has been removed from this object.
remarks: * To view the original object, please query the RIPE Database at:
remarks: * http://www.ripe.net/whois
remarks: ****************************
rpki-ov-state: invalid
How can I list all route objects with RPKI status?
Using the !fno-rpki-filter
filter to list all objects which will include the rpki-ov-state
value including invalid
objects. Replace -T route
with -T route6
to get the ipv6 route objects.
# this will list of all route objects
$ echo -e '!!\n!fno-rpki-filter\n-s RADB -T route -i mnt-by MAINT-AS237\n!q' | nc whois2.radb.net 43
# combine with grep, sort, and uniq to get some totals
$ echo -e '!!\n!fno-rpki-filter\n-s RADB -T route -i mnt-by MAINT-AS237\n!q' | nc whois2.radb.net 43 | grep rpki | sort | uniq -c
13 rpki-ov-state: invalid
100 rpki-ov-state: not_found # No ROAs found, or RPKI validation not enabled for source
61 rpki-ov-state: valid