7. 2018#apricot2018 45
No more foreign objects in RIPE RPSL
• As a result of ongoing policy discussions over several years
the RIPE NCC is closing off a hole which permitted APNIC
region resources to be included in the RIPE RPSL
• This should hopefully prevent some forms of ‘hijack’ of
prefixes because RPSL in RIPE IRR can no longer lift filters
for these prefixes to be origin-AS from the RIPE region ASN
• Existing foreign objects are maintained in a different RPSL
”source” which is now closed.
7
8. 2018#apricot2018 45
Background/History
• May 2015, discussions at the RIPE70 meeting Amsterdam
• 2015-2017 ongoing DB-WG, Routing-WG discussion
• 2017 concrete proposals to deprecate foreign objects
• End 2017, Q1 2018 consensus reached
• Q1 2018 RIPE NCC Technical staff publish work program to
move data, close foreign object admission in source RIPE
8
9. 2018#apricot2018 45
Proposed body of work (WG chairs)
• Remove the ASN authorisation requirement for ROUTE(6) object creation
– Deprecate the "mnt-routes:" attribute in the AUT-NUM object
– Remove the 'pending object creation' functionality for route creation
• Create the source 'RIPE-NONAUTH’
– Move all ROUTE(6) objects relating to non RIPE managed address space to this new
source
• (pending eventual deletion after further discussion)
– Move all non ripe managed AUT-NUM objects to this new source
• (pending eventual deletion after further discussion)
• Adjust the query service relating to serving the RIPE-NONAUTH data
9
10. 2018#apricot2018 45
Proposed body of work (WG chairs)
• Disallow creation of any new AUT-NUM or ROUTE(6) objects in the RIPE Database
for non RIPE managed resources, but allow existing objects to be modified or
deleted
• Remove the "mnt-routes:" attribute from all the placeholder INET(6)NUM objects in
the RIPE Database for non RIPE managed address space
• Delete the MNTNER object with the public password
– ('fixing' any other database objects that may refer to it)
• Update all documentation to reflect the new processes
• Ensure that the inter RIR transfer process for resources moving into the RIPE
managed address space does not allow the transfer of ROUTE(6) objects from
source RIPE-NONAUTH to source RIPE without the agreement of the resource
holder
10
11. 2018#apricot2018 45
Outcome: you control your resources
• Existing data held in the RIPE NCC IRR is moved into a
clearly denoted ‘foreign’ space
– It is probably heading to being removed. You will be informed.
• If your resources need to be routed via an Origin-AS held in
the RIPE-NCC, your inclusion in the decision is now explicit
(but, out-of-band)
• Future routing assertions in IRR/RPSL should always
include your explicit consent.
11