July 2023 - db-wg - mailman.ripe.net

Using the RIPE Database for IPAM
by denis walker 04 Oct '23

04 Oct '23

Colleagues Do you use the RIPE Database as your IPAM solution? If so, read on.... The RIPE NCC has done a brief review of the recommendations made by the DB Task Force (DBTF). You can find it here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/initial-analys… There is one point in the summary that I disagree with: One recommendation can be implemented immediately by the RIPE NCC: - 3. Using the RIPE Database as an IPAM solution The recommendation from the DBTF was: "The task force recommends limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution." This has not yet been discussed by the community and there is no consensus on this recommendation. So the RIPE NCC should not be doing anything to implement this recommendation. There are a number of points relating to this. The first BoF held by the DBTF had 46 participants. They had some polls about IPAM: Where do you hold your canonical IP address assignment details? (13 answers) Internal database or IPAM system (5 - 38%) RIPE Database (5 - 38%) Internal database for detailed assignments and RIPE database for allocations (3 - 23%) What should we do about the IPAM use of the RIPE Database? (12 answers) We should discourage it (3-25%) We should tolerate it but provide restrictions and best practices (5-42%) We should promote it and facilitate it (4-33%) During the BoF some comments were also made on this: Shane's comment "IPAM seems to be an important thing" Nathalie said about 50% of people attending training courses over a number of years said they use the RIPE DB for IPAM. Also trainees said open source IPAM solutions often pull data out of the RIPE DB but have no functionality to push data to the RIPE DB. During the presentation by the DBTF in the DB-WG session at RIPE 83 Shane said (on IPAM): "if you had very light requirements for IPAM then maybe it is OK, but it's not really what it's for" "unable to find out if this [response] was based on misunderstanding of the question" "we think there are probably good ways to go forward with that, for example making hooks so that external IPAM solutions can hook into it...that makes sense, there are certainly many commercial vendors that make IPAM products who would be happy to use hooks, there are many ways that third parties could use this but probably not a requirement" So it looks like there are very mixed views on the use of the RIPE Database for IPAM. Some people also expressed surprise that so many people use the database for IPAM. It is clear that we don't actually understand who, how and why people use the database for IPAM. We need a better understanding of the how and why and the number of users doing this before we can make any decision about discouraging or encouraging this use of the database. Even to consider if IPAM should be defined as a purpose of the database. As we are talking about it, maybe now is the time to start this discussion. If you use the RIPE Database as your IPAM solution maybe you can offer some more details. cheers denis co-chair DB-WG

5 5

Geofeed purpose
by denis walker 07 Aug '23

07 Aug '23

Colleagues The conversation on deploying geofeed died shortly after RIPE 85. The last comment was from myself asking if anyone was willing to propose some wording for a new purpose covering the use of the RIPE Database for geolocation information. No one proposed any wording. So below I have made a proposal for a new purpose. Your comments are appreciated. cheers denis co-chair DB-WG The RIPE Database contains information for the following purposes: Ensuring the uniqueness of Internet number resource usage through registration of information related to the resources and Registrants Publishing routing policies by network operators (IRR) Facilitating coordination between network operators (network problem resolution, outage notification etc.) Provisioning of Reverse Domain Name System (DNS) and ENUM delegations Providing information about the Registrant and Maintainer of Internet number resources when the resources are suspected of being used for unlawful activities, to parties who are authorised under the law to receive such information. Scientific research into network operations and topology Providing information to parties involved in disputes over Internet number resource registrations to parties who are authorised under the law to receive such information. Providing information about the geolocation usage of Internet number resources.

6 15

Entry Deduplication
by Peter Potvin 04 Aug '23

04 Aug '23

Hey there DB-WG, Apologies in advance if this is the wrong mailing list for this. I noticed that the RIPE DB Query UI automatically deduplicates entries (i.e. multiple instances of an ASN in an AS-SET only appears once) through the webUI, however when queried through whois on any modem operating system the entry shows the raw data including the duplicates within it. I'm a bit curious as to how this is done, and whether it's possible/planned to have the same functionality implemented in the WHOIS back-end that RIPE uses. Regards, Peter Potvin | Executive Director ------------------------------------------------------------------------------ *Accuris Technologies Ltd.* 56A Mill St E, Unit #470, Acton, ON L7J 1H3 Canada Email: peter.potvin(a)accuristechnologies.ca Office: +1 (877) 352-6105 Network Operations Center: +1 (877) 321-1662

2 1

Authoritative check for domain objects seems to cache nameserver response
by Kjartan Hrafnkelsson - HI 02 Aug '23

02 Aug '23

Dear colleagues, When creating domain objects for reverse DNS delegation of a RIPE assigned inetnum or inet6num, I have observed behaviour where entering a nameserver not authoritative for the in-addr.arpa or ip6.arpa zone results in that nameserver being temporarily unable to be used for delegation. The interface keeps rejecting that particular nameserver for the reason of 'not being authoritative for <zone>', even if the nameserver's configuration has been updated accordingly. What I personally suspect is happening here is that the service on the backend of RIPE NCC's database has sent a DNS request to the specified nameserver, received a response, and cached it. I'm writing this email to ask a couple of questions: Is this intended behaviour? if it is, should it perhaps be changed? and if so, how should changes be implemented? I'm excited to hear back from you, especially as many colleagues within the networking space have expressed frustration from forgetting to configure their nameservers first or misconfiguring them and then having to wait a day or two to re-do the delegation. I had tried my best to search the db-wg list archives for a similar discussion before writing this entry but could find nothing of substance, please forgive me if this has been discussed before and perhaps decided on :) Best, -- Kjartan, AS51019 +354 784-0020 kjh14(a)hi.is

2 1

Removing RIPE-NCC-NONE-MNT remarks from objects in the RIPE database
by Edward Shryane 27 Jul '23

27 Jul '23

Dear colleagues, The "NONE" authentication scheme was deprecated in the RIPE database in 2004: https://www.ripe.net/publications/news/announcements/deprecation-of-the-non… At that time, "remarks:" attributes were added to objects in the RIPE database to explain this change: remarks: Maintainer RIPE-NCC-NONE-MNT removed and object remarks: LOCKED by the RIPE NCC due to remarks: deprecation of the NONE authentication scheme. remarks: Please visit the following URL to unlock this object remarks: http://www.ripe.net/db/none-deprecation-042004.html As mentioned in my Operational Update at RIPE86, I propose to remove these obsolete remarks from all objects, on *Thursday 27th July*. This change will affect approximately 613 objects. We plan to notify the maintainers of all affected objects afterwards. If you have any questions or comments, please let me know. Regards Ed Shryane RIPE NCC

1 1

Removing "rev-srv:" remarks from inetnum objects in the RIPE database
by Edward Shryane 27 Jul '23

27 Jul '23

Dear colleagues, The "rev-srv:" attribute was deprecated in inetnum objects in the RIPE database in April 2009: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2009-April/001130.h… However the "rev-srv:" attribute was not removed but was converted into a "remarks:" attribute. As mentioned in my Operational Update at RIPE86, I propose to remove these obsolete remarks from all objects, on *Thursday 27th July*. This change will affect approximately 34,711 objects. We plan to notify the maintainers of all affected objects afterwards. If you have any questions or comments, please let me know. Regards Ed Shryane RIPE NCC

2 2

Where are we with NWIs?
by denis walker 24 Jul '23

24 Jul '23

Colleagues One or two vocal members of this community frequently express their opinion that all WG chairs should sit silently in the background, post an occasional review and wait to declare consensus or not. I am always willing to try out ideas from the community. So for the last couple of months, since RIPE 86, I have stayed silent on DB matters. How has the conversation been on NWIs? Oh there hasn't been any. How have they progressed beyond some steps already in progress? Oh there hasn't been any. Are we any closer to completing action on most NWIs? Er no we aren't. So I think it is fair to say this is not an appropriate way of working with some WGs these days. I will now go back to my previous way of working where, as a co-chair, I do have an agenda - to get things done, for the good of the internet. Whether you consider that a 'personal' or 'professional' or 'DB' agenda is up to you. Just to be clear, this is not the same as for the good of 'operators'. There are many stakeholder groups in this community now. We are no longer just 'the operator community' or even 'the technical community'. So I will continue to engage with the community, push out ideas (even crazy ideas sometimes), start and drive conversations until we get resolutions. Incidentally, this quiet period since RIPE 86 does remind us how busy you all are and how difficult it is for you to find the time to get so involved with the fine detail of small technical and operational changes to the RIPE Database. Which does fit with the presentation I did at RIPE 86 on how to manage the RIPE Database. I will come back to that shortly. cheers denis co-chair DB-WG

7 12

WG Co-Chairs Tasks (was: Where are we with NWIs?)
by Sylvain Baya 21 Jul '23

21 Jul '23

{change the topic. focus: basic tasks} Dear RIPE DB-WG, Hope this email finds you in good health. Please see my comments below inline... Thanks. Le mercredi 19 juillet 2023, denis walker via db-wg <db-wg(a)ripe.net> a écrit : > Colleagues > > One or two vocal members of this community frequently express their > opinion that all WG chairs should sit silently in the background, post an > occasional review and wait to declare consensus or not. > Hi Denis, Thanks for your email, brother. ...you seem to disagree with the WG consensus :-) or it's just with those few "vocal" WG participants? Do seek, first, if there is any rough consensus, or not, please. Is there actually any consensus on the matter? > > I am always willing to try out ideas from the community. > That's not part of the tasks of Co-Chairs, imho :-/ ...i may be wrong, though. Again! you *must* ask to the WG participants if they are ok with that idea, first...prior to engage on disruptive behavior. > So for the last couple of months, since RIPE 86, I have stayed silent on > DB matters. > > Please, it's not about you, brother. If you push back to the WG, you would be less concerned about your WG participant's opinions. In what, as a Co-chair, shall you be concerned about your WG's participant opinions? Please think of it twice, brother...if you care much; then how could you act fairly? or in other words: Do you expect your WG participants to hope to get a fair process, at end? > How has the conversation been on NWIs? > > Which one? Is it into the Co-chair's tasks list to follow-up on the active NWIs progress? > > Oh there hasn't been any. > > This WG have three Co-chairs, may i suggest to our Co-chairs to: 1] organise their team; 2] identify their *willing* regular tasks list; 3] discuss it with the DB-WG; 4] distribute the resulting regular tasks list amongst them (Co-chairs) 5] bind on that. > > How have they progressed beyond some steps already in progress? > Oh there hasn't been any. > Are we any closer to completing action on most NWIs? > Er no we aren't. > > Please, do not justify a disruptive behavior by stats poured like that. It *should* not work that way, brother: 1| remove your hat first 2| voice your personal opinion 3| wait the other Co-chairs to seek any consensus 4| put back your Co-chair's hat 5| and go ahead. That's, imho, what Randy is trying to recommend, if i got it well. > > So I think it is fair to say this is not an appropriate way of working > with some WGs these days. > The DB-WG may be an exception, but how to deal with that difference? Revisit the Co-chair's tasks list? What else? > > I will now go back to my previous way of working where, as a co-chair, I > do have an agenda - to get things done, > Please read my previous comments :-) Yes to "Get Things Done"! No to handle "Things" without rough consensus! Yes to do any-"Thing " with "no hat"! > > for the good of the internet. > We have already experienced that before and we know that the "good of the Internet" is a matter of collaborative engagement of any stakeholders available. ...but! don't get me wrong, please: i have no doubt on your sincerity or capacity to act as fairly as it would be possible. Note that those who would come after you would also benefit to whatever disruption we would have agreed on now. Imagine, then, some really bad actor with own hidden *agenda* taking the position after you...what would be the safeguards? ...i stop here, while thinking to have said enough on this topic. By the way! i personally appreciate the fondamental values and expertise of Denis and i hope we would be able to get more benefit on his presence on this WG. Shalom, --sb. > Whether you consider that a 'personal' or 'professional' or 'DB' agenda is > up to you. Just to be clear, this is not the same as for the good of > 'operators'. There are many stakeholder groups in this community now. We > are no longer just > 'the operator community' or even 'the technical community'. > > So I will continue to engage with the community, push out ideas (even > crazy ideas sometimes), start and drive conversations until we get > resolutions. Incidentally, this quiet period since RIPE 86 does remind > us how busy you all are and how difficult it is for you to find the > time to get so involved with the fine detail of small technical and > operational changes to the RIPE Database. Which does fit with the > presentation I did at RIPE 86 on how to manage the RIPE Database. I > will come back to that shortly. > > cheers > denis > co-chair DB-WG > > -- > [...] -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

2 2

Progress on NWI-4
by Wessel Sandkuijl 20 Jul '23

20 Jul '23

Hi, I've reviewed Ed's impact analysis for NWI-4 and his proposal to add a new status value "ALLOCATED-ASSIGNED PA". This will not cover all use cases and it's use will most likely be limited as most people are used to the "ALLOCATED PA" versus "ASSIGNED PA" status values. I would highly prefer the earlier alternative proposal to use a tuple (using both prefix and status) so no new status value is introduced to the RIPE database. Can this be moved forward? Regards, Wessel Sandkuijl

4 4

Route(6) objects
by Kaupo Ehtnurm 12 Jul '23

12 Jul '23

Hello For example I have 2001:1234::/32 ipv6 network. And I want to start using DDoS protection service that one of my ip transit provider offers. But my edge routers are multihomed and enabling ddos protection on one transit provider lets half of the attack still come in from our other ip transit providers in case of DDoS attack. But if our ip transit provider that provides also a ddos protection would hijack the routes from us with more specific routes, then instead of traffic flowing from my other ip transit providers to my AS it flows to my DDOS protection providers AS. Route hijacking solves the problem where half of the attack still comes in to my AS from other transit providers. For in order for the DDoS protection service provider to be able to hijack the routes correctly from us we need to have more specific ROA and route(6) objects done. With ROA it is easy, I just create the following ROA: " 2001:1234::/32 max length 48 ASN AS1234" But with route(6) objects this isn't so easy, because these objects don't have max length or any other operators that it accepts. And because of that I need to hope the entire internet to accept all the /48s that fit into 2001:1234::/32 prefix if I have following route6 object: " 2001:1234::/32 AS1234". But to be correct with my db records I would need to make all the /48 route6 objects that fit into that /32 and instead of 1 object I need to create 65536 objects. First of all I would hit the object creation limit per day in ripe DB. With this limit enabled, I would create the records over 2 months. And the manageability of those records would be a nightmare. If ROAs and route(6) objects go hand-in-hand anyway for the most of the time, then why can't route objects have "max length" or somekind of operator like ROAs have? Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo(a)wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]

9 22