2018-06 Proposal Implemented (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
Dear Working Group, The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up". We plan to deploy this to production on Wednesday 15th January. A nightly job will run from that evening onwards. We expect approximately 965 route objects will be initially marked for cleanup (which will happen 2 weeks after that). Regards Ed Shryane RIPE NCC
From: Petrit Hasani <phasani@ripe.net> Subject: [policy-announce] 2018-06 Proposal Accepted (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up) Date: 6 November 2019 at 16:03:18 GMT+1 To: policy-announce@ripe.net
Dear colleagues,
Consensus has been reached on 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
This proposal aimed at creating a process to delete a non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06
The new RIPE Document is called ripe-731 and is available at: https://www.ripe.net/publications/docs/ripe-731
We estimate that this proposal will take around two to three months to fully implement.
We will send another announcement once the implementation is complete and the new procedures are in place.
Thank you to everyone who provided us with your input.
Kind regards,
-- Petrit Hasani Policy Officer RIPE NCC
Dear Working Group, The Non-authoritative Route Object cleanup job ran for the first time last night. We identified 978 route(6) objects with conflicting ROA(s) which are now marked for cleanup, and emailed 269 addresses. Regards Ed Shryane RIPE NCC
On 6 Jan 2020, at 15:26, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear Working Group,
The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
We plan to deploy this to production on Wednesday 15th January.
A nightly job will run from that evening onwards. We expect approximately 965 route objects will be initially marked for cleanup (which will happen 2 weeks after that).
Regards Ed Shryane RIPE NCC
From: Petrit Hasani <phasani@ripe.net <mailto:phasani@ripe.net>> Subject: [policy-announce] 2018-06 Proposal Accepted (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up) Date: 6 November 2019 at 16:03:18 GMT+1 To: policy-announce@ripe.net <mailto:policy-announce@ripe.net>
Dear colleagues,
Consensus has been reached on 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
This proposal aimed at creating a process to delete a non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-06 <https://www.ripe.net/participate/policies/proposals/2018-06>
The new RIPE Document is called ripe-731 and is available at: https://www.ripe.net/publications/docs/ripe-731
We estimate that this proposal will take around two to three months to fully implement.
We will send another announcement once the implementation is complete and the new procedures are in place.
Thank you to everyone who provided us with your input.
Kind regards,
-- Petrit Hasani Policy Officer RIPE NCC
In message <7747EE59-A4AD-4191-93B7-0A3B0A1C6AAC@ripe.net>, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
The Non-authoritative Route Object cleanup job ran for the first time last night. We identified 978 route(6) objects with conflicting ROA(s) which are now marked for cleanup, and emailed 269 addresses.
Praise be unto you. Cleanliness is next to Godliness. Regards, rfg
Hello, On 06/01/2020 16:26, Edward Shryane via db-wg wrote:
The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
While I think this is a very commendable effort, I'm worried about resources that have been assigned directly by IANA through IETF action. They aren't covered by any RIR db and cannot be signed by RPKI. I'm primarily worried about the anycast addresses that we (AS29432) announce: AS112 prefixes, 6to4 prefixes and Teredo prefixes. We're already having trouble getting those into automatic filters, and I'm worried that some day the route(6) objects might disappear completely. I found the above prefixes listed at iana.org: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia... I strongly suspect that there may also be a few root or TLD name server prefixes that fall into this category, even tho they aren't listed in the above links. As far as I've understood, IANA is not going to operate a RIR db or start maintaining their own RPKI signer. So we have to find some other solution. Ultimately this may need to be solved by an RFC, but I thought I'd start here by soliciting some ideas and opinions on what the correct approach should be. Please Comment, -- +358 44 9756548 / http://www.trex.fi/ Aleksi Suhonen / TREX Regional Exchanges Oy You say "potato", I say "closest-exit."
On Fri, Jan 31, 2020 at 09:04:58AM +0200, Aleksi Suhonen via db-wg wrote:
On 06/01/2020 16:26, Edward Shryane via db-wg wrote:
The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
While I think this is a very commendable effort, I'm worried about resources that have been assigned directly by IANA through IETF action. They aren't covered by any RIR db and cannot be signed by RPKI.
If they can not be signed by RPKI, these objects will not be impacted by clean up effort described in RIPE-731. So, I'd posit there is no reason to worry.
I'm primarily worried about the anycast addresses that we (AS29432) announce: AS112 prefixes, 6to4 prefixes and Teredo prefixes. We're already having trouble getting those into automatic filters, and I'm worried that some day the route(6) objects might disappear completely.
There is no proposal for further deletion as far as I know. Should at some point the Internet numbers community figure out a way how to do RPKI for such prefixes, again we wouldn't need to worry since the RPKI ROA registrations will act as a superior successor to the IRR registrations (and they wouldn't be in conflict).
I found the above prefixes listed at iana.org: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia...
I strongly suspect that there may also be a few root or TLD name server prefixes that fall into this category, even tho they aren't listed in the above links.
As far as I've understood, IANA is not going to operate a RIR db or start maintaining their own RPKI signer. So we have to find some other solution. Ultimately this may need to be solved by an RFC, but I thought I'd start here by soliciting some ideas and opinions on what the correct approach should be.
Until a problem has been defined, and a solution specified, I'm happy to accomodate this type of special registration in the NTTCOM database. Kind regards, Job
participants (4)
-
Aleksi Suhonen -
Edward Shryane -
Job Snijders -
Ronald F. Guilmette