- db-wg - mailman.ripe.net

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

restrict usage of RIPE-NCC-RPSL-MNT
by Job Snijders 20 Nov '14

20 Nov '14

Dear working group, The RIPE databse provides a mntner object which can be used to create route objects for IP ranges which are not allocated or assigned through the RIPE NCC. http://www.ripe.net/data-tools/db/faq/faq-db/how-to-create-a-route-object-w… I did some digging to understand how the RIPE-NCC-RPSL-MNT mntner object is used in practise. You can fetch the dataset through this command: $ whois -h whois.ripe.net -- '-K -i mnt-by RIPE-NCC-RPSL-MNT' Usage exceeded my expectations: (object type: occurances) route: 12195 route6: 77 And much to my suprise I found that there are all kinds of objects which reference RIPE-NCC-RPSL-MNT with an "mnt-by:" attribute: aut-num: 341 mntner: 51 as-set: 37 person: 40 route-set: 33 organisation: 5 rtr-set: 1 inet-rtr: 1 key-cert: 1 Would it be an idea to prevent objects from being updated/created when they carry a "mnt-by: RIPE-NCC-RPSL-MNT" attribute? Secondly, should RIPE NCC proactively remove all "mnt-by: RIPE-NCC-RPSL-MNT" references from the database? Kind regards, Job

3 7

-V database query semantics
by Nick Hilliard 17 Nov '14

17 Nov '14

Could someone from RIPE clarify the semantics for the -V query? In the database query reference manual, section 2.6 it says: > -V --client <client-tag> Sends information about the client to the server. But in section 2.11, it says: > The database server provides a facility for such proxy clients that > allows accounting to be based on the IP address of the clients using the > proxy to query the RIPE Database and not on the IP address of the proxy > server. This is done using the “-V” flag as follows: > > -V <version>,<ipv4-address> > > where > > <version> is a client tag that usually represents the software version > that the proxy uses > <ipv4-address> is the IPv4 address of the client that queries the > database using the proxy According to the source code, the argument for the -V parameter is passed into the QueryFlag.CLIENT variable and then parsed using getProxyIp(). If the format looks like "version,ipv4addr" then the argument is passed to the proxy accounting mechanism for rate limiting. But if the argument is not formatted like this, it looks like the "-V" parameter is ignored. Is this understanding correct, and should all whois clients use the "-V" query to pass their client ID to the whois server by default? As an aside, the isProxyValid() function uses InetAddresses.isInetAddress(), which suggests that the code should also understand "-V <version>,<ipv6-address>". If this is correct+tested, the documentation should be updated. Nick

2 1

RIPE Database Release 1.76 Deployed to Release Candidate Environment
by Tim Bruijnzeels 12 Nov '14

12 Nov '14

Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.76 to the Release Candidate (RC) environment. Detailed information about features, changes and how this release might affect your operations, are available in the release notes: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.76 This release includes many small bug fixes and feature improvements. Notably, we have addressed the following issues: - Issue #221: It is now possible to change the name of a PERSON or ROLE object - Issue #256: Abuse contact information is now shown when using web lookups - Issue #220: Failed update notifications now include a diff of the attempted change A number of users requested the notification of a failed update to include a diff showing what was attempted to be changed. A consequence of this change is that, if you mistype the password pseudo-attribute (eg "pasword: clear_password"), the notification will include your clear text password. This is a good time for all maintainers of data in the RIPE Database to review to whom these notifications are sent. The "upd-to:" attribute in a MNTNER object should only include the email address of a person or team in your organisation who deals with security issues. If this team receives such a notification, they should advise the user to change their password. 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… We look forward to any questions or comments you might have. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

3 3

Launching the RIPE NCC Academy
by Rumy Kanis 11 Nov '14

11 Nov '14

Dear colleagues, The RIPE NCC is pleased to announce the launch of the RIPE NCC Academy, a virtual learning environment that allows you to take courses and obtain certificates online: https://academy.ripe.net/ The first course available is the RIPE Database Expert Course. You can sign in to the RIPE NCC Academy with your RIPE NCC Access account (if you don’t already have one, you can easily create one through the link provided). The RIPE NCC Academy is available to everyone, free of charge. Before starting a course, you should know that: - You have 90 days to complete the course from the moment you start it. - We are working to automate the evaluation of all of the activities. In the meantime, some of them need to be checked manually, so you may have to wait for a trainer to review them. - If you’re very confident that you already know all you need to know about the RIPE Database, you can choose to complete the activities without studying the content. - You will earn a certificate when you achieve a score of 70% or better, including all the activities and the final test. - Your certificate will remain valid for three years. The first 100 users to earn a certificate will get a limited edition RIPE NCC Academy Graduate t-shirt. Don’t wait too long - graduate to the next level today! In the coming months, we’ll be making more courses available via the RIPE NCC Academy, so stay tuned. If you have any questions, please feel free to contact us at academy(a)ripe.net. Watch the RIPE NCC Academy teaser at https://www.youtube.com/watch?v=P7K89w8VXCI Happy learning, Rumy Spratley-Kanis, Training Services Manager and Sandra Bras, E-Learning Coordinator — Rumy Spratley-Kanis Training Services Manager RIPE NCC Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC

1 0

[training] RIPE NCC Training Courses January-March 2015
by Training Services 10 Nov '14

10 Nov '14

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 Milan, Madrid, Munich, Podgorica, Prague, Moscow, Riga, Ramallah, Edinburgh, Copenhagen, Amsterdam. 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: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course The RIPE NCC delivers the following tailor-made workshops: - Measurements Tools Workshop - Introduction to BGP For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

RIPE69 DB-WG Draft Agenda V2
by Nigel Titley 06 Nov '14

06 Nov '14

Attached please find the V2 of the draft agenda for today's DB-WG meeting. Nigel pp Wilfried

1 0

RIPE69 DB-WG Draft Agenda V1
by Wilfried Woeber 05 Nov '14

05 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear DB-WG folks, Chairpersons, "Meeting"! This is the 1st -rough- draft of an agenda for the DB-WG Meeting at RIPE69 in London. For time slot allocations please refer to the most up-to-date meeting plan at https://ripe69.ripe.net/programme/meeting-plan/ The DB-WG Meeting is scheduled for *Thursday*, November 6th, starting at 16:00 local time[1], after the coffee break. The length of our timeslot is 90 Minutes. The overall (draft) RIPE 69 meeting outline is already available at https://ripe69.ripe.net/programme/meeting-plan/ Please feel free to propose additional topics to be discussed! I'd also suggest that you submit your points of view regarding the topics on the proposed agenda on the mailing list, preferably before the WG meeting's start :-) Best regards, hope to see you soon in London, Wilfried. PS: thanks to Job and Piotr for suggesting items! [1] for remote participation, this 15:00 UTC ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list B. Data Base Operational Update (N.N., RIPE NCC, t.b.c.) C. New DB-Software functionality (proposed, test, deployment) . referral-by deprecation - (based on deprecation guidelines) - present time table for 'referral-by' . from "changed:" to "last-modified:" / "created:" - explain new attr., examples, - timeline for implementation D: Personalised authentication? E: Maintainer Password resets? X. Working Group Management [~10 min] . chair replacement procedure . WW144 to resign . new DB-WG Chairs to take over Y. Input from other Working Groups and/or Task Forces Z. AOB __________________________________________ 2014-10-21 19:15 UTC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQCVAwUBVEazMt/RXX7wrLNpAQK3xQQAutAXz+LcI53fGT4dmNbfSyDGuc10RQLG S3liIaKCwRgLg0sKSkInShdHjE8zIINdN4WGwZ1EECTfEahzYilmau9jgfxWy3E9 vx3QRtQ9iXDd43CvyUDjOW09j1g2CfTlXCx8oEJaM9oULihGte3ECRzn9Acvptl0 3UuUmikSt3s= =5Rjx -----END PGP SIGNATURE-----

4 3

Draft minutes of RIPE 67 meeting
by Nigel Titley 05 Nov '14

05 Nov '14

Please find draft minutes of the DB-WG meeting held in Athens today. Comments, complaint, misrepresentations etc, to me Nigel

1 1

Revised RIPE Database Documentation on ripe.net
by Denis Walker 03 Nov '14

03 Nov '14

Dear colleagues, The RIPE NCC has expanded the revised RIPE Database documentation to include the information from the RIPE Database Query Reference Manual. The RIPE Database Query Reference Manual itself will be removed over the coming weeks. This revised documentation is available for version 1.76 of the RIPE Database software: https://www.ripe.net/data-tools/support/documentation/ripe-database-documen… We look forward to your feedback. Regards, Denis Walker RIPE NCC

1 0

WG chair selection procedure
by Nigel Titley 28 Oct '14

28 Oct '14

Folks We need to have a documented procedure in place by the end of the next WG meeting for the affirmation and re-affirmation of WG chairs. I strongly feel that voting has no place in the running of RIPE working groups and also feel that inability to attend a RIPE meeting should not be a barrier to either becoming a chair or participating in the selection process. So I propose the following procedure. 1. A call for interested parties is made on the WG mailing list at yearly intervals 2. Interested parties have 2 weeks to make their interest known, again on the mailing list 3. The DB-WG chairs issue a call for discussion as per normal. WG members express their approval or otherwise of the presented candidates. 4. After two weeks the chairs declare consensus as they would do for a policy proposal I would propose a maximum number of 3 co-chairs. If at the end of the discussion phase there are more than 3 proposed co-chairs then a call is made for any of the candidates to withdraw. If there are still more than 3 candidates then names are put into a hat and the first three names drawn from the hat will take on the role of chairs for the next 12 months. Comments are welcome. Best regards Nigel

5 5

Call for agenda items, DB-WG Meeting during RIPE69, London, UK
by Wilfried Wöber 15 Oct '14

15 Oct '14

Dear DB-WG folks, this is a _call for agenda items for the meeting of the DataBase-WG during RIPE69 in London, UK, November 3 - 7, 2014 Please submit (to the WG list!) your item requests and|or suggest topics for discussion to be included in the draft agenda! Please note that the DataBase-WG meeting is *at the moment* scheduled for *Thursday*, Nov. 6 (starting at 16:00 local time). This is according to the *draft* meeting plan - which is pretty stable already, but may still need to be changed as we get closer to the meeting date! The overall (draft) RIPE 68 meeting outline is already available at https://ripe69.ripe.net/programme/meeting-plan/ Looking forward to a successful meeting and see you soon in London! Wilfried.

1 0

Revised RIPE Database Documentation on www.ripe.net
by Denis Walker 07 Oct '14

07 Oct '14

Dear colleagues, Earlier this year, the RIPE NCC announced our intentions to revise the RIPE Database documentation, as requested by the community at RIPE Meetings: https://labs.ripe.net/Members/fatemah_mafi/revising-the-ripe-database-docum… The first batch of new documentation pages are available online: https://www.ripe.net/data-tools/support/ripe-database-documentation These pages replace the contents of the RIPE Database Update Reference Manual, which has now been removed fromwww.ripe.net, and include the contents of several other database-related webpages. We will publish further documentation pages, replacing the RIPE Database Query Reference Manual, before RIPE 69 in London, 3-7 November 2014. Features of this new documentation include: - A glossary of commonly-used terms shown throughout the documentation marked by dots (...) underneath. Mousing over these words will show the corresponding glossary entry. Alternatively, you can browse the glossary for a list of words and phrases and their definitions. - An export feature so that you can export the entire contents of the documentation to a .pdf for printing. We invite feedback from the community about the new documentation, which will be revised with each release of the RIPE Database software. Please reply toripe-dbm(a)ripe.net or provide your feedback on the RIPE Database Working Group mailing list. Regards, Denis Walker RIPE NCC

1 0

Revers DNS
by Colin Pyne 07 Oct '14

07 Oct '14

Hello, Please can anyone offer any advice as to what I am doing wrong in the setup of my revers DNS zone? I am getting two error messages when I submit the domain via webupdates. * No name servers found at child. No name servers could be found at the child. This usually means that the child is not configured to answer queries about the zone. * Fatal error in delegation for zone 38.57.185.in-addr.arpa. No name servers found at child or at parent. No further testing can be performed. Object data domain 38.57.185.in-addr.arpa descr Reverse DNS for LCH admin-c CP9084-RIPE tech-c CP9084-RIPE zone-c CP9084-RIPE nserver lchns1.unlimitednameservers.com nserver lchns2.unlimitednameservers.com mnt-by MOTIVE-MNT changed colin.pyne(a)motive.co.uk 20141007 source RIPE I have looked at this https://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-deleg… I can perform a zone lookup 38.57.185.in-addr.arpa using NSLOOKUP > server 185.57.38.1 Default Server: host-185-57-38-1.lowcosthosting.co.uk Address: 185.57.38.1 > set type=ns > 38.57.185.in-addr.arpa Server: host-185-57-38-1.lowcosthosting.co.uk Address: 185.57.38.1 38.57.185.in-addr.arpa nameserver = lchns2.unlimitednameservers.com 38.57.185.in-addr.arpa nameserver = lchns1.unlimitednameservers.com lchns1.unlimitednameservers.com internet address = 185.57.38.1 lchns2.unlimitednameservers.com internet address = 185.57.38.2 Any advice would be very appreciated. Regards, Colin Pyne Colin Pyne | IT Manager T: 01539 797464 E: Colin.Pyne(a)motive.co.uk Visit our website: www.motivetechnology.com<http://www.motivetechnology.com/> Credentials & Partnerships [http://www.motivetechnology.com/MotiveTechnology/media/Motive/email/sponsor…] Lets Connect [http://www.motivetechnology.com/MotiveTechnology/media/Motive/email/motiveB…] <http://www.motivetechnology.com/Blog> [http://www.motivetechnology.com/MotiveTechnology/media/Motive/email/motiveF…] <https://www.facebook.com/motivetechnologyUK> [http://www.motivetechnology.com/MotiveTechnology/media/Motive/email/motiveT…] <https://twitter.com/Team_Motive_UK> [http://www.motivetechnology.com/MotiveTechnology/media/Motive/email/motiveL…] <https://www.linkedin.com/company/motive-technology-uk-limited> The content of this message and attached file are confidential and / or privileged and are for the intended recipient only. If you are not the intended recipient, any unauthorised review, use, re-transmission, dissemination, copying, disclosure or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you receive this message in error please contact the sender immediately and then delete this email from your system. Copyright in this email and attachments created by us belongs to Motive Technology UK Limited . Any attachment with this message should be checked for viruses before it is opened. Motive Technology UK Limited cannot be held responsible for any failure by the recipient to test for viruses before opening any attachments. Should you communicate with anyone at Motive Technology UK Limited by email you consent to us monitoring and reading any such correspondence. Motive Technology UK Limited - Company No: 06813205 - Registration Number: 947 4034 15 Registered Office: Richard House, Winckley Square, Preston, Lancashire, PR1 3HP

2 1

Proposal to remove "referral-by" attribute in "mntner" object or make it optional
by Martin Tõnusoo 06 Oct '14

06 Oct '14

Hello, "referral-by" attribute(defined in RFC2725) is mandatory in "mntner" object: [martint@ ~/ripe-db]$ whois -BHrh whois.ripe.net -t mntner | grep referral-by referral-by: [mandatory] [single] [ ] [martint@ ~/ripe-db]$ I checked the db-wg mailing-list archive since January 2000 and only discussion I found regarding this attribute was from Engin Gunduz(former RIPE NCC Senior Software Engineer) in June 2004: [martint@ ~/ripe-db]$ for year in {2000..2014}; do for month in January February March April May June July August September October November December; do wget -q --no-check-certificate https://www.ripe.net/ripe/mail/archives/db-wg/$(printf '%s-%s.txt.gz\n' "$year" "$month"); done; done [martint@ ~/ripe-db]$ zgrep -Hi "referral-by" * 2000-August.txt.gz:-irb (or -ireferral-by) <maintainer name> 2000-August.txt.gz:Returns all objects whose referral-by attribute matches the query 2001-August.txt.gz:referral-by: RIPE-DBM-MNT 2001-May.txt.gz:If you mean referral-by, it points to mntner handle, mandatory in mntner 2003-April.txt.gz:referral-by: RIPE-DBM-MNT 2003-April.txt.gz:referral-by: RIPE-DBM-MNT 2003-August.txt.gz:> referral-by: RIPE-DBM-MNT 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz: referral-by: MAINT-RGNET 2003-December.txt.gz:> referral-by: MAINT-RGNET 2003-December.txt.gz:> referral-by: MAINT-RGNET 2003-December.txt.gz:> > referral-by: MAINT-RGNET 2003-December.txt.gz:> > referral-by: MAINT-RGNET 2003-July.txt.gz:referral-by: RIPE-DBM-MNT 2004-April.txt.gz:referral-by: RIPE-DBM-MNT 2004-June.txt.gz:referral-by: [mandatory] [single] [inverse key] 2004-June.txt.gz:referral-by: RIPE-DBM-MNT 2004-June.txt.gz:Subject: [db-wg] Proposed Change 2004.2: Removal of "referral-by:" Attribute 2004-June.txt.gz:[2004.2] Removal of "referral-by:" Attribute from the MNTNER Object 2004-June.txt.gz:Remove the "referral-by:" attribute from the MNTNER objects' schema. This 2004-June.txt.gz:The "referral-by:" attribute was introduced into MNTNER objects when the 2004-June.txt.gz:"referral-by:" is defined in RFC2725: 2004-June.txt.gz: referral-by This attribute is required in the maintainer object. It 2004-June.txt.gz: referral-by. An auth-override can only be added to a maintainer 2004-June.txt.gz: those identified by the maintainer in the referral-by have 2004-June.txt.gz: "referral-by" attribute is now mandatory in the "maintainer" object 2004-June.txt.gz: referenced by a "referral-by" attribute elsewhere. 2004-June.txt.gz:The RIPE NCC introduced the "referral-by:" attribute as a place-holder, 2004-May.txt.gz:referral-by: [mandatory] [single] [inverse key] 2005-May.txt.gz:> referral-by: [mandatory] [single] [inverse key] 2005-May.txt.gz:> > referral-by: [mandatory] [single] [inverse key] 2005-November.txt.gz:>referral-by: RIPE-DBM-MNT 2005-November.txt.gz:> >referral-by: RIPE-DBM-MNT 2005-November.txt.gz:> > >referral-by: RIPE-DBM-MNT 2007-July.txt.gz:> referral-by: RIPE-DBM-MNT 2007-July.txt.gz:>> referral-by: RIPE-DBM-MNT 2007-June.txt.gz: referral-by: RIPE-DBM-MNT 2007-June.txt.gz: referral-by: RIPE-DBM-MNT 2007-June.txt.gz:> referral-by: RIPE-DBM-MNT 2007-June.txt.gz:> referral-by: RIPE-DBM-MNT 2012-April.txt.gz:referral-by: DEV-ROOT-MNT 2013-March.txt.gz:referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:>> referral-by: TRUBNIKOV-MNT 2013-March.txt.gz:>>> referral-by: TRUBNIKOV-MNT [martint@ ~/ripe-db]$ He also proposed to remove the "referral-by" attribute, but there was no feedback to his e-mail. One can read his e-mail here: https://www.ripe.net/ripe/mail/archives/db-wg/2004-June/002797.html In addition, while RIPE database manual says that "referral-by attribute may never be altered after the addition of the maintainer", one can easily change it at least in current RIPE database version. Is the "referral-by" attribute obsolete? Or is it needed in some specific situation? If not, I propose to remove the "referral-by" attribute in "mntner" object or at least make it optional. WBR, Martin Tonusoo -------------------------- LINXTELECOM www.linxtelecom.com -------------------------- NOC 24/7: +372 622 3300

13 25

last-modified:, a succesor to changed:
by Job Snijders 16 Sep '14

16 Sep '14

Dear DB Working Group, Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled: Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed Eleanor:~ job$ whois -h whois.radb.net AS15562 | grep changed changed: unread(a)ripe.net 20000101 Eleanor:~ job$ Fantastic! Now we are absolutely none the wiser. :-) I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:". The "last-modified" attribute is set by the whois server software and represents the date and time at which the last succesful modification was received by the server. When a user submits an update for an object in which the attribute is present, the server software will ignore the attribute, insert its own attribute with the current time, and present a warning to the user that the user's version of "last-modified" was ignored. The "last-modified" attribute should be presented by the server software in all types of objects (autnums, poems, etc) for which the server is responsible (e.g. do not touch foreign or mirrored objects). The date and time are represented following the ISO 8601 [1] profile for complete date plus hours, minutes and seconds, always expressed in UTC, including the special UTC designator 'Z'. The "last-modified" attribute should be presented above, but close to the "source:" attribute. The advantage is that the date and time are both human readable and computer parsable! A valid example "last-modified" attribute would be: last-modified: 2014-04-15T13:15:30Z I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation. Kind regards, Job [1] - https://xkcd.com/1179/

15 43

[training] RIPE NCC Webinars - new dates
by Training Services 11 Sep '14

11 Sep '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