- db-wg - mailman.ripe.net

Proposal: make phone number optional in person objects
by Shane Kerr 17 Apr '15

17 Apr '15

All, Piotr's set of proposed improvements to the RIPE database has inspired me! Proposal: Make the phone number optional in person objects. Motivation: For ages the "phone" attribute has been mandatory in person objects (since 1995 with document RIPE 49 at least). But I don't see any reason that this should be mandatory. Many people prefer to be contacted via e-mail or some other method. Oddly, "phone" is optional on role objects, which would seem to be the ideal place for help desks and the like. (I am NOT proposing that we change this.) Cheers, -- Shane

3 4

Proposal to cleanup some hack's with status values
by Piotr Strzyzewski 16 Apr '15

16 Apr '15

Dear DB-WG Members Proposal: I propose to introduce some new status lines for INET(6)NUM objects to cleanup some hacks. Problem description: Right now we have at least four category of hacks in the status lines: 1. ::/0 inet6num: ::/0 netname: IANA-BLK (...) status: ALLOCATED-BY-RIR remarks: This network in not allocated. This object is here for Database consistency and to allow hierarchical authorisation checks. (...) 2. 0/0 inetnum: 0.0.0.0 - 255.255.255.255 (...) status: ALLOCATED UNSPECIFIED (...) 3. IPv6 allocations made by IANA to RIPE NCC inet6num: 2001:600::/23 (this is just an example) (...) status: ALLOCATED-BY-RIR # This block was actually allocated by the IANA (...) 4. IPv4 allocations made by IANA to RIPE NCC inetnum: 185.0.0.0 - 185.255.255.255 (this is just an example) (...) status: ALLOCATED UNSPECIFIED (...) Hacks no 1 and 3 looks easy. Those are definately not ALLOCATED-BY-RIR. So I propose to introduce two new status values: IPV6 for ::/0 and ALLOCATED-BY-IANA for IANA IPv6 allocations. Hacks no 2 and 4 are bit tricky. According to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region": "ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR or RIR. Assignments may be PA or PI. This status is intended to document past allocations (...)" It is quite obvious that 0/0 is not "past allocation". So I propose to introduce new status value: IPV4 for 0/0. Moreover, it looks like "ALLOCATED UNSPECIFIED" has been overused also. For example 185/8 has been allocated to RIPE NCC on 2011-02-08. This was done after many of the previous versions of the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" which include quoted definition have been published. So I propose to introduce new status value ALLOCATED IANA for such cases. Some possible issues to be addressed: 1. When this proposal will be supported by the DB-WG, then it has to be discussed with AP-WG and IPv6-WG. 2. There are two more hacks which could be discussed: IETF reserved blocks and legacy allocations under various RIR administration. Looking for your comments. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] [ncc-announce] [news] Phase 1 of Deprecation of "changed:" Attribute Deployed to RIPE Database Release Candidate Environment
by * IP - Detal 10 Apr '15

10 Apr '15

Dear Colleagues from RIPE NCC, Thank you for information. <http://www.google.pl/url?source=transpromo&rs=rssf&q=//translate.google.com…> In relation to the following e-mail we have a question. We are one of the largest ISP in Poland (we have a huge number of object registered in ripe database). We do not understand how we would add so many attributes "last-modified:" and "created:" to tens of thousands our records registered in ripe database? It takes a long time and we are obliged to modify it to the end of July 2015. The "created" and "last-modified" fields can be automatically generated to new records, but how to updated the already registered objects without manual input ? We are waiting to your reply. Kind regards, Ewa Hilmantel - Debska pl.tpsa ________________________________ From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels Sent: Thursday, April 02, 2015 5:15 PM To: ncc-announce(a)ripe.net Subject: [ncc-announce] [news] Phase 1 of Deprecation of "changed:" Attribute Deployed to RIPE Database Release Candidate Environment Dear colleagues, The RIPE Database Working Group has asked the RIPE NCC to replace the "changed:" attribute in the RIPE Database with "created:" and "last-modified:". We want to inform the wider community, in case you have any feedback you would like to share with the Database WG. Following discussions at RIPE 69, we met with the WG chairs and finalised an implementation plan consisting of three phases: 1) Introduce the new attributes "created:" and "last-modified:" 2) Make the "changed:" attribute optional 3) Deprecate the "changed:" attribute Details of this implementation plan can be found here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… We recently informed the Database WG that Phase 1 of this implementation had been deployed to the Release Candidate environment. We are planning to deploy this to the production environment on 28 April: <https://www.ripe.net/ripe/mail/archives/db-wg/2015-March/004504.html>https://www.ripe.net/ripe/mail/archives/db-wg/2015-March/004504.html If you have any questions or comments, please raise them on the RIPE Database WG mailing list at <db-wg(a)ripe.net<mailto:db-wg@ripe.net>>. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

2 1

RIPE-NCC-LEGACY-MNT
by Hank Nussbacher 07 Apr '15

07 Apr '15

Not sure which list is appropriate so please reply only to the list that people point out as the one which should handle the following issue: I have modified a number of objects to be now LEGACY objects. inet-nums and aut-nums. When the object is processed and converted into a LEGACY object, RIPE auto-adds the following line to each object: mnt-by: RIPE-NCC-LEGACY-MNT This is documented here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 Policy 2012-07: Legacy holder organisations cannot change their organisation name in their org object if it is referenced by an INETNUM or AUTNUM that is maintained by RIPE-NCC-LEGACY-MNT. I then noticed I needed to delete some import and export lines on my aut-num policy. No can do any more. I now get the error: Authorisation for [aut-num] AS378 failed using "mnt-by:" not authenticated by: RIPE-NCC-LEGACY-MNT, AS378-MNT So this now means *every* change to any legacy IP block or ASN has to go via RIPE. But I have been unable to find how to go about informing RIPE that I need to make an object modification. Any pointers would be helpful. Regards, Hank

2 2

[training] RIPE NCC Webinars - new dates
by Training Services 30 Mar '15

30 Mar '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Call for agenda items DB-WG meeting during RIPE70, Amsterdam, NL
by Job Snijders 23 Mar '15

23 Mar '15

Dear DB-WG participants, We are reaching out to you for agenda items for the Database Working Group session during the RIPE70 meeting in Amsterdam, Netherlands 11-15 May 2015. Some of the current topics are: - 'source:' differentiation - RIPE-NCC-RPSL-MNT - UTF-8 in the DB - cross-registry authorisation - updates from RIPE NCC - .... your topic? Please submit your items or topic suggestions to the chairs directly or to the list for public discussion. Soon we'll publish a draft agenda, waste no day if you want microphone time! :-) The Database Working Group session is scheduled Thursday 14 May, from 16:00 till 17:30. Looking forward to a successful session and see you soon in the beautiful city of Amsterdam! Kind regards, Job, Piotr & Nigel

1 0

RIPE NCC to remove mnt-lower RIPE-NCC-END-MNT from ASSIGNED PI objects
by Tim Bruijnzeels 06 Mar '15

06 Mar '15

Dear colleagues, Sub-assignments of ASSIGNED PI objects are technically possibly in the RIPE Database, but not allowed by RIPE policy. And to prevent that such sub-assignments are created, the RIPE NCC has been including "mnt-lower: RIPE-NCC-END-MNT" on ASSIGNED PI Objects. Nowadays however we prefer to enforce such policy restrictions by the use of special "business rules" and a rule has already been implemented for this particular case. Therefore the RIPE NCC would like to do a bulk change on all ASSIGNED PI objects in the RIPE Database and remove "mnt-lower: RIPE-NCC-END-MNT" where it's present. Since we feel that this operation does not significantly alter the affected objects we plan to suppress sending out notify messages regarding this change, and we will make sure that this change is excluded when the "last-modified:" attribute is added in future. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

4 5

Monthly open-items summary
by Nigel Titley 02 Mar '15

02 Mar '15

Folks, The WG chairs have decided that a monthly "open-items" list might be useful to the WG. I'm doing the first and it will then rotate around the other chairs on a monthly basis. - "source: field for non RIPE address space", this proposal needs to be reworked to accommodate the large transfer of route objects from RIPE to the new AFRINIC DB - "restrict usage of RIPE-NCC-RPSL-MNT" we need to continue this discussion and request action from RIPE NCC - proposal for latin1 primary keys, utf8 allowed in user modifiable data - cross routing registry authorisation. This is a long term project which will ultimately allow authorisation between registries and will allow de-duplication of data across the registry system as a whole. This will be progressed as a BOF at RIPE 70 meeting if possible. - continue promotion of the the new Afrinic RR If I've missed anything please let me know. Nigel

1 0

RIPE NCC to stop enforcing accurate organisation names in "descr:" attribute
by Tim Bruijnzeels 26 Feb '15

26 Feb '15

Dear colleagues, The "org:" attribute now provides a consistent way to find the organisation for all resources in the RIPE Database. The RIPE NCC is planning to stop enforcing the organisation name in the "descr:" attribute for those resources allocated or assigned by it. There was a time when the "org:" attribute was not mandatory for INETNUM, INET6NUM and AUT-NUM objects. And to make it clear which organisation is the holder of a resource, the RIPE NCC has been enforcing that the first "descr:" line of these objects reflects the organisation name for resources that are allocated or assigned by the RIPE NCC. But this limit was never enforced on resources not allocated or assigned by the RIPE NCC, such as sub-assignments and legacy resources. Nowadays these object types do have a mandatory "org:" attribute, and today the RIPE NCC also enforces that the organisation referenced here, and its name, reflect the registry records for these resources. For resources not allocated or assigned by the RIPE NCC it's the responsibility of resource holders to ensure that the referenced organisation accurately reflects the holder of e.g. sub-assignments and legacy resources. Please let us know if you have any comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

4 4

RIPE Database Release 1.78 Deployed to Release Candidate Environment
by Tim Bruijnzeels 23 Feb '15

23 Feb '15

Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.78 to the Release Candidate (RC) environment. Please note that the previous release candidate, 1.77, was rolled back because of an issue with concurrent updates that only became apparent in the production environment. Release 1.78 includes a fix for this issue. Extensive automated tests have been added to prevent similar issues from happening again. This release includes all features and fixes from release 1.77. In addition, release 1.78 of the RIPE Database software also includes a number of other improvements: = We added a dry-run option for the REST API = We improved the error message when creating an organisation object without and AUTO primary key = Fix for Issue #286: Pending create route requests are not removed when the route is created Detailed release notes are published on the web site: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.78 We invite all users of the RIPE Database to review the new release in the RC environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… Please let us know if you find any issues. We plan to deploy this release to the production environment on Monday 23 February. We look forward to any questions or comments you might have. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

1 1

[training] RIPE NCC Training Courses April-June 2015
by Training Services 17 Feb '15

17 Feb '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Tashkent, Lisbon, Poznan, Belgrade, Manchester, Kuwait, Helsinki, Dublin, Nicosia, Kazan, Amsterdam, Vienna, Hamburg. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - Local Internet Registry (LIR) Training Course - RIPE Database Training Course - Basic IPv6 Training Course - Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

[training] RIPE NCC Training Courses April-June 2015
by Training Services 17 Feb '15

17 Feb '15

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Tashkent, Lisbon, Poznan, Belgrade, Manchester, Kuwait, Helsinki, Dublin, Nicosia, Kazan, Amsterdam, Vienna, Hamburg. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - Local Internet Registry (LIR) Training Course - RIPE Database Training Course - Basic IPv6 Training Course - Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Implementation plan for replacing "changed:" with "last-modified:" and "created:" published
by Tim Bruijnzeels 02 Feb '15

02 Feb '15

Dear colleagues, The RIPE Database Working Group requested the RIPE NCC to replace the “changed:” attribute in the RIPE Database with “created:” and “last-modified:”. Following discussions at RIPE 69, the RIPE NCC has met with the working group chairs and finalised an implementation plan consisting of three phases: 1) introduce the new attributes “created:” and “last-modified:” 2) make the "changed:" attribute optional 3) deprecate the "changed:" attribute. The time lines and documentation for each phase are detailed here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… We look forward to any questions or comments you might have. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

2 3

[training] RIPE NCC Webinars - new dates
by Training Services 02 Feb '15

02 Feb '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

RIPE DB updates service disruption
by Theodoros Polychniatis 29 Jan '15

29 Jan '15

Dear Colleagues, A short downtime for RIPE DB Updates is necessary today, between 14:00 - 15:00 CET, to apply an urgent security patch. The downtime for updates will be a few minutes and queries will not be affected. We apologise for the short notice and thank you for your understanding. Kind regards, Theodoros Polychniatis, Software Engineer, RIPE NCC

1 0

Reporting un-assigned but used ip-space
by Arnd Vehling 29 Jan '15

29 Jan '15

Hello, today i recognized a spambot attack from "62.122.74.100" which lies in an un-assigned ip-range. How to correctly report this? cheers, Arnd

2 1

RIPE Database Release 1.77 Deployed to Release Candidate Environment
by Tim Bruijnzeels 26 Jan '15

26 Jan '15

Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.77 to the Release Candidate (RC) environment. This release includes: = Business rules to support the 2012-07 policy = A clear banner in the Release Candidate (RC) and Training web tools = Internal code to support resiliency improvements = Fixes for four infrequently occurring bugs This release also includes the bug fix released earlier in 1.76.1: = Incorrectly formatted blank lines in updates were crashing the NRTM service (issue #284) This release does not introduce any major functional changes. Detailed release notes are published on the web site: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 We invite all users of the RIPE Database to review the new release in the RC environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… Please let us know if you find any issues. We plan to deploy this release to the production environment on Monday 26 January. We look forward to any questions or comments you might have. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

1 1

[training] RIPE NCC Webinars
by Training Services 26 Jan '15

26 Jan '15

Dear colleagues, The RIPE NCC Training Services Department invites you to register for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

AS-NULL
by Nick Hilliard 17 Dec '14

17 Dec '14

For various reasons, the AS-NULL as-set scratched a rather pressing itch earlier today. In the interests of neutrality, would the RIPE NCC be interested in maintaining ownership of this object as an empty set? Nick

7 8

RIPE Database Release 1.76.1 Deployed to Production
by Edward Shryane 16 Dec '14

16 Dec '14

Dear colleagues, We have identified an issue in Whois with RPSL objects containing blank continuation lines. The software was not correctly parsing these lines, and this resulted in invalid objects being created in the RIPE Database. This can cause serious problems with the NRTM service. We have deployed a minor release 1.76.1 to production, to fix this issue. Regards Ed Shryane RIPE NCC

1 0

FR: Publish list of RIPE NCC managed space
by Job Snijders 07 Dec '14

07 Dec '14

Hi All, RIPE NCC, It would make my life easier if I could fetch a list of prefixes from either ftp.ripe.net or an API endpoint that contains all address space for which RIPE NCC is authoritive. (E.g. not NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK etc). I'd use this list to create a patricia tree to do lookups in and assess the validity of route objects. It is important that this list does not cover space which RIPE does not administrate. Please don't fill it with /8s unless RIPE NCC truely manages that entire /8. The list should solely create prefixes for which route objects can only be created following RIPE's solid authentication mechanism. I'd expect the dump on ftp.ripe.net to be updated on a daily basis. I don't care if the prefixes in the list match prefix-lengths of inetnums, I only care about the totally of the chunk of space out of 0/0 which RIPE manaages. Can this be implemented? Kind regards, Job

3 6

[training] RIPE NCC Webinars - new dates
by Training Services 01 Dec '14

01 Dec '14

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

FW: IRR Report for RIPE managed space
by Job Snijders 28 Nov '14

28 Nov '14

Hi db-wg, I think this is might interest some of you as well. I am researching impact of ignoring route objects in non-RIPE IRRs which cover RIPE managed space when generating filters. I encourage discussion in on the routing-wg list. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)instituut.net> ----- Date: Fri, 28 Nov 2014 11:32:06 +0100 From: Job Snijders <job(a)instituut.net> To: routing-wg(a)ripe.net Subject: IRR Report for RIPE managed space Hi routing-wg, I am assessing the state of IRR. I took yesterday's IRR dumps which we use to generate filters, and correlated that with a RIB dump from the NLNOG RING Looking Glass. Keep in mind that prefixes can overlap, duplicate route objects can exist, etc when looking at this data. Consider all values carefully. Blocks IANA handed down to RIPE: 2/8 5/8 31/8 37/8 46/8 62/8 77/8 78/8 79/8 80/8 81/8 82/8 83/8 84/8 85/8 86/8 87/8 88/8 89/8 90/8 91/8 92/8 93/8 94/8 95/8 109/8 176/8 178/8 185/8 193/8 194/8 195/8 212/8 213/8 217/8 (any holes in these blocks are dealt with). BGP Snapshot taken on 27 November 2014 around 18:00 UTC. TOTALS: - total IPv4 route objects present in the specific IRR. - total of prefixes observed in DFZ which length-wise match with a route object in the IRR. (the closer this number is to the previous value, the better) - total of prefixes with a exact matching prefix-length AND origin AS as observed in the BGP table snapshot. (higher is better) - total of prefixes which fall within RIPE IP space for which a route object was detected AND a exact match in the BGP snapshot. note: this includes non-ripe-managed-space (lower is better) - total of prefixes which fall within RIPE IP space for which a route object was detected AND a exact match in the BGP snapshot AND where the origin AS as listed in the foreign object matches with the BGP table. note: this includes non-ripe-managed-space (lower is better) DUPLICATE: a route object that exists both in a foreign IRR and the RIPE IRR with same prefix-length and origin AS number. Because this data is duplicated such these foreign objects can safely be ignored when generating filters. ERROR_ROAMING: a route object that covers RIPE IP space, but for which no route object in the RIPE IRR database exists. Such objects should be moved to the RIPE IRR. Possible operational impact. Lower value is better. MORE_SPECIFIC_ROAMING: a route object in a foreign IRR which covers part of a route object which is present in the RIPE IRR. Origin AS is the same in both objects. NON_RIPE_MANAGED: IANA handed /8 blocks down to RIPE, but there are holes in these /8 blocks. For informative purposes the number is listed. The filter implementation would not give these blocks special protection like it would protect "RIPE proper" IP space. RIPE lists these blocks as 'NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK' in inetnums in RIPE IRR. ORIGIN_MISMATCH - IRR: both a route object exist in the RIPE IRR as well as in a foreign IRR, for the exact same prefix + prefix-length. The origin AS does not match between the RIPE version and the foreign version. Lower is better, but operational impact depends on the next two values. ORIGIN_MISMATCH - BGP: both a route object exist in the RIPE IRR as well as in a foreign IRR, for the exact same prefix + prefix-length. The origin AS does not match between the RIPE version and the foreign version. The lower this number is, the better. ORIGIN_MISMATCH - RIPE's version in BGP: both a route object exist in the RIPE IRR as well as in a foreign IRR, for the exact same prefix + prefix-length. The origin AS does not match between the RIPE version and the foreign version. The closer this number is to the previous value, the better. afrinic.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 315 119 in DFZ w/ matching origin: 119 RIPE pfx in DFZ : 54 RIPE pfx in DFZ w/ origin: 54 DUPLICATE : 0 ERROR_ROAMING : 0 0 MORE_SPECIFIC_ROAMING : 0 0 NON_RIPE_MANAGED : 131 54 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 altdb.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 13998 7940 in DFZ w/ matching origin: 5032 RIPE pfx in DFZ : 235 RIPE pfx in DFZ w/ origin: 149 DUPLICATE : 71 ERROR_ROAMING : 155 79 MORE_SPECIFIC_ROAMING : 96 42 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 76 55 RIPE's version in DFZ : 42 apnic.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 90224 30804 in DFZ w/ matching origin: 27875 RIPE pfx in DFZ : 0 RIPE pfx in DFZ w/ origin: 0 DUPLICATE : 0 ERROR_ROAMING : 0 0 MORE_SPECIFIC_ROAMING : 8 0 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 arin.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 24032 10416 in DFZ w/ matching origin: 6925 RIPE pfx in DFZ : 240 RIPE pfx in DFZ w/ origin: 79 DUPLICATE : 56 ERROR_ROAMING : 92 39 MORE_SPECIFIC_ROAMING : 361 45 NON_RIPE_MANAGED : 53 16 ORIGIN_MISMATCH : 118 96 RIPE's version in DFZ : 91 bboi.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 1326 857 in DFZ w/ matching origin: 764 RIPE pfx in DFZ : 4 RIPE pfx in DFZ w/ origin: 2 DUPLICATE : 5 ERROR_ROAMING : 0 0 MORE_SPECIFIC_ROAMING : 0 0 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 1 1 RIPE's version in DFZ : 1 bell.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 29531 1710 in DFZ w/ matching origin: 655 RIPE pfx in DFZ : 2 RIPE pfx in DFZ w/ origin: 2 DUPLICATE : 2 ERROR_ROAMING : 2 0 MORE_SPECIFIC_ROAMING : 6 0 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 gt.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 2479 1196 in DFZ w/ matching origin: 754 RIPE pfx in DFZ : 0 RIPE pfx in DFZ w/ origin: 0 DUPLICATE : 0 ERROR_ROAMING : 0 0 MORE_SPECIFIC_ROAMING : 1 0 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 jpirr.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 7685 6019 in DFZ w/ matching origin: 5821 RIPE pfx in DFZ : 11 RIPE pfx in DFZ w/ origin: 11 DUPLICATE : 4 ERROR_ROAMING : 9 5 MORE_SPECIFIC_ROAMING : 5 2 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 level3.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 87609 44874 in DFZ w/ matching origin: 23408 RIPE pfx in DFZ : 1155 RIPE pfx in DFZ w/ origin: 678 DUPLICATE : 384 ERROR_ROAMING : 316 102 MORE_SPECIFIC_ROAMING : 1526 233 NON_RIPE_MANAGED : 208 69 ORIGIN_MISMATCH : 591 460 RIPE's version in DFZ : 367 nttcom.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 208425 60603 in DFZ w/ matching origin: 42122 RIPE pfx in DFZ : 1135 RIPE pfx in DFZ w/ origin: 875 DUPLICATE : 623 ERROR_ROAMING : 229 92 MORE_SPECIFIC_ROAMING : 5020 510 NON_RIPE_MANAGED : 77 40 ORIGIN_MISMATCH : 144 100 RIPE's version in DFZ : 85 radb.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 677083 205492 in DFZ w/ matching origin: 136172 RIPE pfx in DFZ : 7051 RIPE pfx in DFZ w/ origin: 4550 DUPLICATE : 4647 ERROR_ROAMING : 1932 789 MORE_SPECIFIC_ROAMING : 8958 1271 NON_RIPE_MANAGED : 519 151 ORIGIN_MISMATCH : 2602 1764 RIPE's version in DFZ : 1680 rgnet.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 311 77 in DFZ w/ matching origin: 45 RIPE pfx in DFZ : 0 RIPE pfx in DFZ w/ origin: 0 DUPLICATE : 0 ERROR_ROAMING : 0 0 MORE_SPECIFIC_ROAMING : 0 0 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 savvis.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 92031 33113 in DFZ w/ matching origin: 18417 RIPE pfx in DFZ : 4417 RIPE pfx in DFZ w/ origin: 3076 DUPLICATE : 3626 ERROR_ROAMING : 674 367 MORE_SPECIFIC_ROAMING : 4052 927 NON_RIPE_MANAGED : 512 157 ORIGIN_MISMATCH : 1329 784 RIPE's version in DFZ : 725 tc.db-result-parsed IRR BGP TOTAL ROUTE OBJECTS : 3070 1462 in DFZ w/ matching origin: 1432 RIPE pfx in DFZ : 0 RIPE pfx in DFZ w/ origin: 0 DUPLICATE : 0 ERROR_ROAMING : 0 0 MORE_SPECIFIC_ROAMING : 0 0 NON_RIPE_MANAGED : 0 0 ORIGIN_MISMATCH : 0 0 RIPE's version in DFZ : 0 Total number of prefixes for which a route object ONLY exists in a foreign IRR AND which were observed in the DFZ: 1004 prefixes (aggregated 522), spread over 280 ASNs. List "ERROR_ROAMING.txt" is attached. Total number of prefixes for which a route object exists in both RIPE IRR and a foreign IRR (with mismatching origins), AND where the foreign version is observered in the DFZ: 269 prefixes spread over 119 ASNs. List is attached as "ORIGIN_MISMATCH.txt". Kind regards, Job

1 0

Re: [db-wg] db-wg Digest, Vol 39, Issue 12
by nikolaj ilchik 25 Nov '14

25 Nov '14

помочь 2014-11-25 13:00 GMT+02:00 <db-wg-request(a)ripe.net>: > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: source: field for non RIPE address space (Job Snijders) > 2. Re: source: field for non RIPE address space (Job Snijders) > 3. Re: source: field for non RIPE address space (Randy Bush) > 4. Re: source: field for non RIPE address space (Randy Bush) > 5. Re: source: field for non RIPE address space (Job Snijders) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 24 Nov 2014 19:16:54 +0100 > From: Job Snijders <job(a)instituut.net> > Subject: Re: [db-wg] source: field for non RIPE address space > To: Edward Shryane <eshryane(a)ripe.net> > Cc: Kaveh Ranjbar <kranjbar(a)ripe.net>, db-wg(a)ripe.net, Nigel Titley > <nigel(a)titley.com> > Message-ID: <20141124181654.GD44694(a)Vurt.local> > Content-Type: text/plain; charset=us-ascii > > On Thu, Nov 20, 2014 at 06:41:16PM +0100, Job Snijders wrote: > > On Thu, Nov 20, 2014 at 03:03:49PM +0100, Edward Shryane wrote: > > > I checked all route objects in the RIPE database, against the > > > delegated stats file for each region, and found which region the > > > (IPv4) address space belongs in. > > > > > > RIPE: 185,537 > > > ARIN: 7,609 > > > AFRINIC: 37,683 > > > LACNIC: 1,930 > > > APNIC: 2,004 > > Edward was kind enough to provide me with data dumps. I've run some > simple seek & count code, comparing the route objects (and their real > source) and the BGP table: > > Correct route object, prefix-length, origin which are visible in BGP DFZ: > IPv6 IPv4 > AFRINIC: 72 7146 > APNIC: 17 498 > ARIN: 264 4030 > LACNIC: 11 1448 > OTHER: 2 NaN > RIPE: 6430 106081 > > Registered route objects which are NOT visible in BGP DFZ: > IPv6 IPv4 > AFRINIC: 95 31018 > APNIC: 9 515 > ARIN: 168 2694 > LACNIC: 15 448 > OTHER: 0 NaN > RIPE: 3038 78393 > > Correct route object prefix length, wrong origin & visible in BGP DFZ: > IPv6 IPv4 > AFRINIC: 7 582 > APNIC: 3 1002 > ARIN: 84 1085 > LACNIC: 0 35 > OTHER: 45 NaN > RIPE: 357 10896 > > OK, so what does this mean?! > > If we proceed with our plan to set 'source: RIPE-NONAUTH' for objects, > the prefixes from the first category (correct length & origin & visible) > might be impacted. Roughly 13k prefixes, of which ARIN & AFRINIC are the > largest. The real number might be lower as it is quite possible that > route objects for those 13k prefixes exist in other registries as well. > Curiously enough running those 13122 prefixes through aggregate(1), the > set is shrunken down to only 3941 prefixes. > > So, what's next? Please share your thoughts & insights. > > Kind regards, > > Jobi > > ps. My data and crude scripts are available here: > http://instituut.net/~job/correlate-route-objects-with-bgp-ripe/ > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 Nov 2014 00:34:34 +0100 > From: Job Snijders <job(a)instituut.net> > Subject: Re: [db-wg] source: field for non RIPE address space > To: Randy Bush <randy(a)psg.com> > Cc: Database WG <db-wg(a)ripe.net> > Message-ID: <20141124233434.GG44694(a)Vurt.local> > Content-Type: text/plain; charset=us-ascii > > On Tue, Nov 25, 2014 at 08:28:55AM +0900, Randy Bush wrote: > > > Correct route object prefix length, wrong origin & visible in BGP DFZ: > > > > is this not legitimate in a make before break origin transfer? of > > course, many will forget to clean old up afterward. > > Yes, good remark. > > I have not attempted to figure out why those route objects are there. > > One could for instance take a wider time window for the BGP data (6 > months?) and run the correlations to assess which are in transfer/mbb > and which potentially are stale garbage. > > Kind regards, > > Job > > > > ------------------------------ > > Message: 3 > Date: Tue, 25 Nov 2014 08:35:56 +0900 > From: Randy Bush <randy(a)psg.com> > Subject: Re: [db-wg] source: field for non RIPE address space > To: Job Snijders <job(a)instituut.net> > Cc: Database WG <db-wg(a)ripe.net> > Message-ID: <m2r3ws6ujn.wl%randy(a)psg.com> > Content-Type: text/plain; charset=US-ASCII > > >>> Correct route object prefix length, wrong origin & visible in BGP DFZ: > >> is this not legitimate in a make before break origin transfer? of > >> course, many will forget to clean old up afterward. > > I have not attempted to figure out why those route objects are there. > > is there a second route: object for the same prefix which is correct? > > randy > > > > ------------------------------ > > Message: 4 > Date: Tue, 25 Nov 2014 08:28:55 +0900 > From: Randy Bush <randy(a)psg.com> > Subject: Re: [db-wg] source: field for non RIPE address space > To: Job Snijders <job(a)instituut.net> > Cc: Database WG <db-wg(a)ripe.net> > Message-ID: <m2tx1o6uvc.wl%randy(a)psg.com> > Content-Type: text/plain; charset=US-ASCII > > > Correct route object prefix length, wrong origin & visible in BGP DFZ: > > is this not legitimate in a make before break origin transfer? of > course, many will forget to clean old up afterward. > > randy > > > > ------------------------------ > > Message: 5 > Date: Tue, 25 Nov 2014 00:46:38 +0100 > From: Job Snijders <job(a)instituut.net> > Subject: Re: [db-wg] source: field for non RIPE address space > To: Randy Bush <randy(a)psg.com> > Cc: Database WG <db-wg(a)ripe.net> > Message-ID: <20141124234638.GH44694(a)Vurt.local> > Content-Type: text/plain; charset=us-ascii > > On Tue, Nov 25, 2014 at 08:35:56AM +0900, Randy Bush wrote: > > >>> Correct route object prefix length, wrong origin & visible in BGP > DFZ: > > >> is this not legitimate in a make before break origin transfer? of > > >> course, many will forget to clean old up afterward. > > > I have not attempted to figure out why those route objects are there. > > > > is there a second route: object for the same prefix which is correct? > > Quickly ran something for IPv4: > > {'AFRINIC': 99, > 'APNIC': 10, > 'ARIN': 112, > 'LACNIC': 1, > 'RIPE': 6200} > > This means there are 99 objects which fall within AfriNIC administrated > space which have an origin not seen in the DFZ, but a _correct_ route > object already exists. > > Kind regards, > > Job > > > > End of db-wg Digest, Vol 39, Issue 12 > ************************************* >

1 0

source: field for non RIPE address space
by Nick Hilliard 25 Nov '14

25 Nov '14

Hello, There's been a bit of media panic recently about registration of non RIPE address space in the RIPE IRRDB, e.g. > http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-loop… The premise is that if you can register a prefix in a routing registry, this will give you the ability to inject a prefix into the DFZ. We'll ignore the fact that what you actually need to inject a prefix into the DFZ is a complicit transit provider and that most transit providers don't use the IRRDBs for bgp leaf filtering anyway, and even if they did, there are plenty of other IRRDBs where this information can be registered. But that aside, some organisations use IRRDB information extensively, particularly IXPs running route servers. Many of these organisations filter on source: because of the amount of trash in alternative IRRDBs. So, could the RIPE NCC database people consider using a different source: value for non RIPE address space, so that it would be possible for irrdb users to easily filter out authoritative data from non authoritative data? E.g. 185.6.36.0/22 might continue to have "source: RIPE", but a prefix like "210.57.192.0/20" might have "source: RIPE-NONAUTH". Would this be feasible for the RIPE DB software? Interesting to note that Mega-Spred has started providing transit for Telstra Hong Kong, Sify in Chennai, iWay Africa in Cape Town and others: > % peval AS201640 > ({210.57.192.0/20, 210.57.0.0/19, 202.39.112.0/20, 119.227.224.0/19, 105.154.248.0/21, 41.198.224.0/20}) Nick

8 14