- db-wg - mailman.ripe.net

Two Proposals
by Ronald F. Guilmette 01 Oct '21

01 Oct '21

PROPOSED 1) RIPE NCC shall be tasked to begin updating the following file on a near real-time basis, as number resource assignments are transferred either into or out of the authority of RIPE: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest 2) RIPE NCC shall be tasked to begin making the above file available for incremental remote update via the rsync protrocol. RATIONALE Background At the present time the most reliable and up-to-the-minute information indicating which RIR any given number resource is being administered by is contained within the so-called "daily stats files" that are generated and published by the five RIRs: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest ftp://ftp.apnic.net/public/apnic/stats/apnic/delegated-apnic-extended-latest ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest ftp://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-latest Additionally, a single file representing the union of all of the above five files, along with additional data relating to (some but not all) IANA reserved number resources is also available: https://nro-extended-stats-from-rpki-team-prod.s3.eu-west-1.amazonaws.com/n… Note however that the data in this (NRO stats) file lags behind the contents of the five RIR daily stats files, and the content of this file is therfore often less fresh and up-to-date than the information contained in the five RIR stats files. Problem Statement (Proposal 1) Because the five RIR stats files are only updated once a day, and at different times for each RIR, and because number resources are, with increasing frequency, being transfered between regions, it is nowadays frequently the case that there will be, in effect, instances of "version skew" between the five RIR stats files. Instance of such inter-RIR stats files version skew can render it impossible to know, based on the stats files, which RIR currently administers a given number resource. Instances of internet-RIR stats file version skew can arise, and in practice they actually do arise as follows: *) RIR 'A' transfers a number resource `R' to RIR `B'. *) RIR `B' records its administration of `R' in its stats file which is then published within 1 hour. *) RIR `A' records the fact that it no longer administers `R' by removing the associated line from its stats file, and RIR `A's stats file is then published 23 hours later. Under the above scenario, the union of all five of the daily RIR stats files will indicate that *both* RIR `A" and also RIR `B' are the responsible RIRs for the resource `R' for a period of 22 hours. An actual example: As of approximately 07:13 (-0700 / PDT) on 2021-09-17 the following blocks were listed in *both* the stats file for ARIN and also the stats file for RIPE: 140.228.32.0/19 140.228.64.0/19 (Evidence indicates that these 2 block have just been transferred from administration by the ARIN region to administration by the RIPE region.) The problem of version skew between the various daily stats files that are currently published by the various RIRs could be largely or entirely eliminated if all five RIRs henceforth began to update these files on a near real-time basis. RIPE can and should begin doing this as an example to the other RIRs, which may then follow suit. Problem Statement (Proposal 2) The RIR daily stats files, including the one that is generated and published by RIPE NCC, consist of plain text files which are themselves composed of a sequence of plain text lines. As a general matter, very few of these lines change, even over time scales as long as a month. Changes to these files, if any, are entirely minimal when viewed over even shorter time scales, e.g. a day or less. The rsync protocol and rsync servers and clients are especially adept at keeping remote copies of exactly such plain text files up-to-date and synchronized with a master copy stored elsewhere on the Internet. They do so while minimizing bandwidth usage by transfering only those portions of a given file that have changed since the last time a local mirrored copy of the file was updated. Publishing RIPE's stats file via rsync would thus be beneficial to all concerned by minimizing bandwidth usage on both the sending and receiving end. Ideally, RIPE NCC could and should take the lead in making its stats file available via rsync. Once it has done so, other RIRs can be encouraged to follow suit and do likewise with their own daily stats files. Regards, rfg P.S. On a personal note I find it nearly unfathomable that these "daily" stats files are being updated and published only once a day. This seems to me almost reminicent of technological solutions considered appropriate in the prior century.

3 5

Upcoming Usability improvements to the RIPE Database Web Search page
by Edward Shryane 01 Oct '21

01 Oct '21

Dear colleagues, In the RIPE NCC's Activity Plan 2021, we planned to make usability improvements to the RIPE database, including the web search feature. My colleague Rehan Syed Muhammad has now published a RIPE Labs article detailing some upcoming improvements: https://labs.ripe.net/author/rehan_syed_muhammad/four-ideas-for-quicker-que… We plan to make incremental changes to the search page in the coming months. We will keep the community informed, and we welcome any feedback. Regards Ed Shryane RIPE NCC

1 1

RIPE Database Planning Q4 2021
by Edward Shryane 30 Sep '21

30 Sep '21

Dear colleagues, We are now publishing our quarterly planning for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning Our goals here are to make it clear what we are working on in the coming months, and also to get discussion around those plans so we can make developments based on community input. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact me and the team directly at <ripe-dbm(a)ripe.net>. Kind regards, Ed Shryane Senior Technical Analyst RIPE NCC

2 1

Cosmetic changes to the RIPE Database
by denis walker 19 Sep '21

19 Sep '21

Colleagues There have been a number of cosmetic changes to the RIPE Database in recent months. There is no agreed procedure for making these type of changes. In particular the extent to which the community is informed. Examples of the type of changes we are talking about are: 1/ When the ORGANISATION object addresses were synced with the internal registry the address lines were entered in the wrong order. The RIPE NCC did a cosmetic update to reverse the order of the address lines. It had no operational impact at all. 2/ Capitalisation of status values. Again this had no operational impact at all. We would like some feedback from the community about how you want these type of cosmetic changes announced. We see four possible options: 1/ individual notification in advance to all affected maintainers plus general announcement on the mailing list plus update notifications (full disclosure) 2/ general announcement on the mailing list plus update notifications 3/ general announcement on mailing list and silent update (no notifications) 4/ no announcement, no notifications, just do it without disturbing anyone (totally silent) Some points to note: -In all cases the object history will show the changes. -There is also an option to not change the "last-modified:" attribute if you don't want that to reflect cosmetic changes. -The full disclosure option (1) can sometimes lead to considerable extra work load for the RIPE NCC. If people are individually told in advance of a change they don't always realise it has no operational impact and ask questions. Every question opens a ticket that needs to be manually addressed. -Perhaps options 2 or 3 are the most practical? Your feedback is welcomed... cheers denis co-chair DB-WG

4 5

running in whios-circles...?
by Frank Habicht 18 Sep '21

18 Sep '21

Hi, so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62 Whois directed to ripe, ripe said it's iana, iana said it's ripe [ BGP said ..... 4134 23724 45090 ] and ..... there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC) So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ? It seems to tell me something different from what APNIC is saying. PS: a prefix containing IP in question is not seen in https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovere… am i right to be confused by the iana answer? who should get 'encouraged' to change something? Thanks, Frank [frank@fisi ~]$ whoisiana 82.156.114.62 [Querying whois.iana.org] [whois.iana.org] % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 82.0.0.0 - 82.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2002-11 source: IANA [frank@fisi ~]$ whois 82.156.114.62 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '82.156.0.0 - 82.157.255.255' % No abuse contact registered for 82.156.0.0 - 82.157.255.255 inetnum: 82.156.0.0 - 82.157.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: For registration information, remarks: you can consult the following sources: remarks: remarks: IANA remarks: http://www.iana.org/assignments/ipv4-address-space remarks: http://www.iana.org/assignments/iana-ipv4-special-registry remarks: http://www.iana.org/assignments/ipv4-recovered-address-space remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ country: EU # Country is really world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2019-01-07T10:49:20Z last-modified: 2019-01-07T10:49:20Z source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT created: 1970-01-01T00:00:00Z last-modified: 2001-09-22T09:31:27Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.101 (ANGUS) [frank@fisi ~]$

11 28

Re: [db-wg] running in whios-circles...?
by Lutz Donnerhacke 16 Sep '21

16 Sep '21

* Ronald F. Guilmette wrote: > Gert Doering <gert(a)space.net> wrote: > >Ideally, IANA should point to the final RIR right away. > > That would certainly be more helpful than the present state of affairs, > within which the IANA WHOIS server is not merely failing to give out > correct referrals, but is actually giving out demonstratably incorrect > referrals. > > Functionally and operationally, the portion of the IANA WHOIS service that > provides referrals for IP addresses is, at present, worse than useless > due to the innumerable incorrect referrals it provides. If IANA does not > wish to correct that, then they should at least configure the thing so that > it will stop providing *any* responses at all when queried about IP > addresses. Did you ever tried to correct wrong entries in the IANA whois? I did and the entries were fixed (within a period of about a year). It's certainly possible to have correct data in the IANA server. OTOH if the problem is serious enough, an IANA review can be triggered.

3 4

What do you think of our new UI?
by Edward Shryane 02 Sep '21

02 Sep '21

Dear colleagues, We have created a short survey to get your feedback and comments on the new user interface (UI) we have deployed across RIPE NCC’s services, including the RIPE DB website. We kindly ask you to take part in the survey and help us improve the user experience for you. You can access the survey at: https://www.surveymonkey.com/r/RIPENCCservicesUI The survey is anonymous and will remain open until 30 September 2021. Regards Ed Shryane RIPE NCC

3 3

"status:" attribute values in the RIPE database
by Edward Shryane 30 Aug '21

30 Aug '21

Dear colleagues, In Remco van Mook's presentation to the Address Policy WG at RIPE 82: "What Colour Is My IP(v4) space? PI Addresses and LIRs", he pointed out that resource "status:" attribute values may not always be all UPPERCASE. This is because the RIPE database is case-insensitive and case preserving in general, meaning a "status:" attribute value is the same regardless of the case. However, this may make parsing this value more difficult as the case should be ignored. Should the DB team implement a rule to always force the "status:" attribute value to uppercase, for consistency? Regards Ed Shryane RIPE NCC

13 24

Bogon Route object update
by Ronald F. Guilmette 26 Aug '21

26 Aug '21

NONAUTH / IPv4: 41.217.128.0/19 37034 2018-09-04 41.217.144.0/20 37034 2018-09-04 41.217.144.0/21 37034 2018-09-04 41.242.128.0/22 327933 2018-09-04 41.242.129.0/24 327933 2018-09-04 41.242.131.0/24 327933 2018-09-04 107.168.204.0/24 47447 2018-09-04 192.31.196.0/24 112 2018-09-04 192.88.99.0/24 1101 2018-09-04 192.88.99.0/24 12816 2018-09-04 192.88.99.0/24 12871 2018-09-04 192.88.99.0/24 15598 2021-02-25 192.88.99.0/24 1741 2018-09-04 192.88.99.0/24 1835 2018-09-04 192.88.99.0/24 20640 2018-09-04 192.88.99.0/24 21416 2018-09-04 192.88.99.0/24 25192 2018-09-04 192.88.99.0/24 25308 2018-09-04 192.88.99.0/24 2847 2018-09-04 192.88.99.0/24 29076 2018-09-04 192.88.99.0/24 29259 2018-09-04 192.88.99.0/24 29432 2018-09-04 192.88.99.0/24 29632 2018-09-04 192.88.99.0/24 3243 2018-09-04 192.88.99.0/24 3344 2018-09-04 192.88.99.0/24 35244 2018-09-04 192.88.99.0/24 39326 2018-09-04 192.88.99.0/24 43097 2018-09-04 192.88.99.0/24 50113 2018-09-04 192.88.99.0/24 5408 2018-09-04 192.88.99.0/24 5413 2018-09-04 192.88.99.0/24 680 2018-09-04 192.88.99.0/24 8473 2018-09-04 192.88.99.0/24 8903 2020-11-18 NONAUTH / IPv6: 2001::/32 1101 2018-09-04 2001::/32 12816 2018-09-04 2001::/32 12871 2018-09-04 2001::/32 1741 2018-09-04 2001::/32 21155 2018-09-04 2001::/32 25192 2018-09-04 2001::/32 25308 2018-09-04 2001::/32 25525 2018-09-04 2001::/32 29259 2018-09-04 2001::/32 29432 2018-09-04 2001::/32 44980 2018-09-04 2001::/32 57801 2018-09-04 2001:4:112::/48 112 2018-09-04 2002::/16 1101 2018-09-04 2002::/16 12871 2018-09-04 2002::/16 15598 2021-02-23 2002::/16 1741 2018-09-04 2002::/16 1835 2018-09-04 2002::/16 20640 2018-09-04 2002::/16 21416 2018-09-04 2002::/16 25192 2018-09-04 2002::/16 25308 2018-09-04 2002::/16 2847 2018-09-04 2002::/16 29259 2018-09-04 2002::/16 29432 2018-09-04 2002::/16 29632 2018-09-04 2002::/16 3344 2018-09-04 2002::/16 35244 2018-09-04 2002::/16 39326 2018-09-04 2002::/16 43097 2018-09-04 2002::/16 5413 2018-09-04 2002::/16 559 2018-09-04 2002::/16 680 2018-09-04 2002::/16 8473 2018-09-04 2002::/16 8903 2018-09-04 2011:4188::/48 12880 2018-09-04

2 1

Historical queries
by denis walker 20 Aug '21

20 Aug '21

Colleagues At RIPE 82 during the NWI review, the chairs recommended two changes to the way historical queries for operational data work: 1/ Drop arbitrary restriction of most recent deletion point of re-created objects 2/ Allow access to history of deleted objects that have not been re-created These recommendations are based on positive comments made by the community in recent years. The restrictions were arbitrary at the time historical queries were implemented in the absence of any hard requirements. So if no one objects the chairs will ask the RIPE NCC to do an impact analysis on these changes. cheers denis co-chair DB-WG

2 1