- db-wg - mailman.ripe.net

avoiding RIPE IRR vs. RPKI ROA mismatches/inconsistencies
by nusenu 14 Sep '18

14 Sep '18

Dear DB Working Group, when looking into RPKI and RIPE IRR coverage I stumbled on prefixes that are covered by a RIPE route object and a RPKI ROA, which is great, but there are cases where these records make conflicting statements about the origin of a prefix. example: 185.46.20.0/22 origin according to ROA: AS199785 origin according to route object: AS61952 origin according to RIS: AS61952 (matches route object) Note: this is just an example to better illustrate the issue. (I didn't do a comprehensive analysis to be able to tell how often this is the case but for a sample of ~1900 prefixes I found 3 such occurrences.) Since route objects and ROAs are created by the prefix holders this is possible (human mistake). Are there any measures in place to prevent or at least warn about the inconsistency when the IP holder creates/updates route objects and ROAs that would result in inconsistencies? What do you think about an UI feature that says something like: "You are about to change/create the route object for prefix ... would you also like to update the existing ROA to match the route object and help avoid inconsistencies?" [ ] yes [ ] no, I know what I'm doing, I'll fix the mismatch manually similarly for updating/creating ROAs. Should there even be a 'No' option? Should the question even be exposed to the user or should records simply be synced automatically once one of either is changed by the IP holder? and simply showing an info like: "We took care of updating your ROA/route object to keep in sync." In case there are well established best practices for an ASN change of a prefix these best practices should be incorporated (i.e. delete the route object and ROA, change the actual announcement in BGP, create new route and ROAs that match the announcement) kind regards, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 3

Whois release 1.92.5 deployed to Production
by Edward Shryane 11 Sep '18

11 Sep '18

Dear Working Group, after deploying the NWI-5 changes last week, we found an issue preventing out of region transfers (the top-level placeholder template still referenced the RPSL maintainer). We have now deployed a bug-fix release 1.92.5 to production that fixes this issue. Regards Ed Shryane RIPE NCC

1 0

Re: [db-wg] WG Chair Selection - Call for Discussion
by Erik Bais 10 Sep '18

10 Sep '18

In case of 1 chair this time, my vote would be for Sean Stuart. Piotr already got selected for the RIPE exec board last meeting, I’m sure he has enough to deal with on that ‘WG’ 😉 Sean has been looking for a way to volunteer for a while in the community and his background could provide a good fit for the role imho. Regards, Erik Bais From: db-wg <db-wg-bounces(a)ripe.net> on behalf of William Sylvester via db-wg <db-wg(a)ripe.net> Reply-To: William Sylvester <william.sylvester(a)addrex.net> Date: Wednesday 5 September 2018 at 22:32 To: "db-wg(a)ripe.net" <db-wg(a)ripe.net> Subject: Re: [db-wg] WG Chair Selection - Call for Discussion WG Members, Congratulations to everyone on the success of NWI-5! With the deployment behind us and everyone back from holiday in August we are moving to the next step in our chair selection process. This email opens the two (2) weeks of chair selection discussion. All members of the community are encourage to make a discussion and express their approval or otherwise of the presented candidates. The candidates are as follows and have either made their interest known on this mailing list, or directly to the chair(s). I encourage each candidate to reiterate their qualifications to the mailing list. Piotr Strzyzewski Sean Stuart As members of this working group please discuss your approval or otherwise of each candidate. Best regards, Denis & William DB-WG Chairs

2 1

Re: [db-wg] WG Chair Selection - Call for Discussion
by Andy Davidson 06 Sep '18

06 Sep '18

Hi, William Thank you kindly for working on this process. Please could you confirm how many seats are open for selection this time? Are we selecting for one seat or two from this list of people? Andy

2 1

Status Update on NWI-5 Deployment: Completed
by Nathalie Trenaman 05 Sep '18

05 Sep '18

Dear colleagues, On 4 September, 21:55 UTC+2, we completed the following changes needed for NWI-5: Out of region ROUTE(6)/AUT-NUM objects. - Removal of mnt-routes from AUT-NUM objects - Removal of the RIPE-NCC-RPSL-MNT - Update the source attribute for out-of-region ROUTE(6) objects to RIPE-NONAUTH On 5 September, 04:32 UTC+2, we also completed the new database dump and split files at: ftp://ftp.ripe.net/ripe/dbase/ <ftp://ftp.ripe.net/ripe/dbase/> We have updated the release notes accordingly: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… <https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel…> Of course, we will keep monitoring the impact on operators. We would like to thank everyone who contributed with valuable input during the test and deployment phases. Kind regards, Nathalie Trenaman Product Manager RIPE NCC

2 1

Implementation plan and time line for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.
by Nathalie Trenaman 05 Sep '18

05 Sep '18

Dear colleagues, On Tuesday, 4 September, we will make changes to the way out-of-region objects are handled in the RIPE Database, as directed by the RIPE Database Working Group. We will implement the following changes in this order between 09:00 and 15:00 UTC+2. 1. The RIPE Routing Registry will no longer support the creation of out-of-region ROUTE(6) and AUT-NUM objects 2. The creation of ROUTE(6) objects will no longer need authorisation from the ASN holder 3. Existing out-of-region objects will have their "source:" attribute changed to "RIPE-NONAUTH” For users of NRTM, these changes will be reflected on the FTP website after 00:00 UTC+2 on Wednesday, 5 September. You can find our implementation plan at: https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple… <https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-imple…> We also published an article on RIPE Labs with some background and additional context: https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec… <https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objec…> We will inform the Database Working Group once all changes have been implemented. Kind regards Nathalie Trenaman Product Manager RIPE NCC

2 2

Status Update on NWI-5 Deployment
by Nathalie Trenaman 04 Sep '18

04 Sep '18

Dear colleagues, We are currently deploying the changes for NWI-5 in the RIPE Database. At the moment, we have successfully rolled out: - the removal of mnt-routes from AUT-NUM objects - removal of the RIPE-NCC-RPSL-MNT The rollout of updating the “source:" attribute to RIPE-NONAUTH on out-of-region ROUTE, ROUTE6 and AUT-NUM objects is taking slightly longer than expected. This means that the source will gradually be updated on out-of-region objects for the rest of today as the script runs. Kind regards, Nathalie Trenaman Product Manager RIPE NCC

1 0

Increasing the Limit of IP Addresses Used for the NRTM Service
by Theodoros Polychniatis 30 Aug '18

30 Aug '18

Dear colleagues, We would like to increase the limit of IP addresses used with the NRTM service. The limit of two addresses per member was set eight years ago and we might be able to handle up to three times that amount now. We are in the process of determining the new limit. If you are interested in helping us test the capacity of our NRTM servers, please open a ticket with us to add more IP addresses to the ones you currently use: https://www.ripe.net/contact-form?topic=ripe-dbm&show_form=true Kind regards, Theodoros Polychniatis Manager SW Engineering RIPE NCC

1 0

improve --list-sources query to display latest serial?
by Job Snijders 30 Aug '18

30 Aug '18

Hi all, It appears there currently is no easy way to retrieve the current serial from the RIPE DB. We're implementing some software to monitor whether our local mirror is wildly out of sync with the RIPE DB or not. I kind of expected th serial to be listed in the --list-sources command, but that field is set to 0. hanna:~ job$ whois -h whois.ripe.net -- --list-sources | grep RIPE % This is the RIPE Database query service. % The RIPE Database is subject to Terms and Conditions. RIPE:3:N:0-0 RIPE-GRS:3:N:0-0 % This query was served by the RIPE Database Query Service version 1.91.2 (HEREFORD) In comparison, IRRd will display the current serial when the !j query is issued: hanna:~ job$ whois -h rr.ntt.net -- '!jNTTCOM' A25 NTTCOM:N:0-978492:978492 C hanna:~ job$ I came up with a really ugly oneliner: $ whois -h 193.0.6.135 -p 4444 -- \ "-g RIPE:3:$(curl -s https://ftp.ripe.net/ripe/dbase/RIPE.CURRENTSERIAL)-LAST" | \ grep -v : | sed '/^$/d' | tail -n 2 | head -1 | awk '{ print $NF }' 42486238 Depending on the time of day that oneliner may be quite quick, or take several minutes to complete... obviously not ideal. Can --list-sources perhaps be improved to list the current serial? Kind regards, Job

2 2

improve --list-sources query to retain history
by Erik Bais 30 Aug '18

30 Aug '18

If the WG is going to look at improving the --list-sources code base, I have something that I would love to see on the wish list to be implemented.. Maintaining history (upto the point where a prefix is leaving the RIPE DB, due to an inter-rir transfer. ) is helpful to see who the previous holder was or where the prefix came from. This is particular the case with Legacy prefixes that are being split up.. as it is current practise to delete the parent prefix after a prefix split and transfer. Once the parent is deleted, you can't list or request the history of the parent prefix anymore. If the historic --list-versions and --show-version could be preserved somehow (on the original prefix size.. instead of them being deleted..), that would be very helpful. Regards, Erik Bais

2 1