- db-wg - mailman.ripe.net

Archiving the "Action List"
by Peter Hessler 04 Jun '25

04 Jun '25

As seen on the website, the Database Working Group has an Action List, instead of an Action Movie. https://www.ripe.net/community/wg/active-wg/db/action-list/ From a basic perusal of them, this seems to be a basic tracking system of TODOs and Proposals. Notice it says "last updated 7 May 2009". I propose we simply archive this list. If anything is still relevant, please bring it up as if it were new. Peter Hessler, On behalf of the DB WG Co-Chairs

4 3

status levels
by denis walker 03 Jun '25

03 Jun '25

Colleagues Maybe I asked too many questions in one email, so I'll take it bit by bit. Is it reasonable to limit the number of levels of SUB-ALLOCATED PA to 4? That is the most we have now in the RIPE Database. Or do you have another number in mind...maybe even 1? Should there be a limit on the number of levels in a LEGACY hierarchy? Currently it is infinite. cheers denids

5 17

NWI proposal: adjusting contact method requirements and adding new methods
by Leo Vegoda 02 Jun '25

02 Jun '25

Hi, A while back Cynthia, Dmitry and I looked at the possibility of adding new contact methods. Dmitry presented this at RIPE 88: https://ripe88.ripe.net/archives/video/1347/ I've tried to put this into a more complete NWI and offer it for discussion. The TLDR is: 1) Align the requirement levels for contact methods 2) Let people use new contact methods, like Signal We hope that by offering the methods people want to use, the contact data in the RIPE Database can be as useful as is possible. Kind regards, Leo ## Problem statement The requirement level for contact methods for person and role objects are inconsistent. This is both confusing and inconvenient. This is a proposal to add flexibility to the contact methods offered at the database level. It is not a proposal to change policy requirements for contact methods. This proposal is limited to admin-c and tech-c contact types. Our world offers more contact methods than were available when the currently supported methods were chosen for the RIPE Database. User acceptance of these methods differ by country and generation. Whether this proposal is accepted or not, it is good to review the rationale for these rules and have an updated rationale published. 1. Person and role objects have four contact methods. A postal address is mandatory for both. A phone is mandatory for person objects but not role objects. E-mail is mandatory for role but not person objects. 2. Postal mail is less useful than it was 20 years ago. Some countries are reducing the frequency of postal deliveries. And geographically distributed teams find postal mail less useful. 3. The telephone is becoming less useful, too. Call volumes are dropping and popular psychology publications explain why calls are less likely to be answered: - https://www.statista.com/statistics/551035/finland-call-volume-by-type-of-c… - https://www.bbc.com/news/articles/ckg8jllq283o - https://www.psychologytoday.com/intl/blog/un-numb/202405/why-gen-zers-keep-… ## Proposal We should provide contacts with more flexibility. We should also add new options that were not available when the RIPE Database's contact methods were last reviewed. The three elements below follow on from NWI-15, which is based on the RIPE Database Requirements Task Force recommendations for what should be published about resource holders. The registry needs to retain the full set of required data. The DBTF report did not mention contacts methods for the resources. 1. Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all contact methods optional for the public RIPE Database as long as one is chosen. There is no point publishing a contact method that will not be used. That would just waste the time of people trying to make contact. 2. Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. 3. Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. Making these changes will require updates to the RPSL and RDAP publication methods. The RIPE NCC should manage the specifics of the design and implementation. ## Recommendation for Impact Assessment The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement. The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.

6 9

Proposal: Privacy in RIPE database objects
by Rodolfo García Peñas (kix) 27 May '25

27 May '25

Hi, I would like to make a proposal regarding the database so that privacy can be included in the objects. Among the main objectives of the database [1] are "To provide accurate registration information of these resources in order to meet a variety of operational requirements" and "Facilitating coordination between network operators (network problem resolution, outage notification etc.)", and therefore the database contains information to facilitate these actions. However, this information can be used to obtain information about individuals and entities in order to carry out unwanted actions (network recognition, phishing, etc.). To prevent network information and contact information from being obtained, objects with anonymized information are stored in the database, role objects are used instead of person objects, non-real information is used, or inetnum objects are not created. Some mailing threads related to these issues have been seen on the mailing list [2][3]. My proposal is that the database offers privacy regarding the information it contains, allowing real information to be stored while protecting LIRs and end users by providing filtered information. To this end, I propose using a system similar to "domain privacy" in DNS registries to hide desired information: - Use the option to hide sensitive information in mandatory fields. - Provide an option to maintain contact with the person responsible for the object. Example: person: Privacy protected address: Privacy protected address: Privacy protected e-mail: Privacy protected (contact link) phone: Privacy protected (contact link) remarks: For mail filtering or abuse problems contact with the abuse mailbox nic-hdl: ABCD1-RIPE mnt-by: Privacy protected (contact link) created: 2008-11-13T15:53:02Z last-modified: 2024-09-23T13:25:48Z source: RIPE One proposal is to use a Boolean model for each field (or for all fields in the object) to indicate whether the information should be "protected" or "public." Another example option would be to include levels such as "public" (publicly accessible), "LEA" (accessible by LEAs), "LIR" (accessible by other authenticated LIRs), and "private" (fully private). This information could be included by default at the user or LIR level using the LIR portal. For email or telephone communication, the platform could act as a mail intermediary or by providing anonymized email addresses, facilitating coordination between network operators/users. IMO, first, we must reach a consensus on whether this option is useful for database management, and then we can discuss implementation details. Regards, Rodolfo García (kix) PS. Thanks Jordi, Miguel for your help. [1] https://docs.db.ripe.net/What-is-the-RIPE-Database/Purpose-and-Content-of-t… [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-September/01… [3] https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/MEOS4MD7ZYLVOA… The content of this email reflects personal opinions and does not represent the views of any organization.

4 6

Publishing End-Site Prefix Lengths
by Randy Bush 26 May '25

26 May '25

i received a suggestion to mention this on the ripe wg list. similar to geofeed, it allows one to document the prefix length one is using. Publishing End-Site Prefix Lengths https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/ This document specifies how to augment the Routing Policy Specification Language (RPSL) inetnum: class to refer specifically to prefixlen comma-separated values (CSV) data files and describes an optional scheme that uses the Resource Public Key Infrastructure (RPKI) to authenticate the prefixlen data files. randy

2 2

RIPE89 Database Working Group Minutes
by Peter Hessler 16 May '25

16 May '25

Hello Database Working Group, The draft minutes from our session at RIPE89 has been published on the RIPE website, available at https://www.ripe.net/community/wg/active-wg/db/minutes/ripe-database-workin… We'd like to thank Alena from the RIPE NCC for preparing the draft. Please review the minutes, and send any necessary corrections to the working group mailing list. Peter Hessler, On behalf of the DB WG Co-Chairs

1 1

Regarding the issue of empty AS-SET in databases
by liu haoran 15 May '25

15 May '25

As the administrator of AKIX , we have observed a recurring issue where newly joined members frequently submit AS-SET objects without populating the mandatory members attribute in IRR databases. From both operational and RPSL (Routing Policy Specification Language) specification perspectives, an AS-SET containing no members represents an invalid configuration, as it fundamentally defeats its purpose of aggregating Autonomous Systems (AS) for routing policy management. We formally propose that IRR database maintainers implement mandatory validation during AS-SET creation to enforce: 1. Require at minimum one valid AS number in the members field 2. Reject AS-SET submissions containing empty/null members attributes 3. Provide clear error messaging specifying the validation requirements This technical enforcement would align with RFC 2725 (Routing Policy System Security) recommendations while significantly improving routing registry data quality and operational reliability for Internet Exchange ecosystems.

4 5

Hierarchical AS-SET names
by James Bensley 12 May '25

12 May '25

Hi all, I raised a request with ARIN to enforce the use of hierarchical AS-SET names moving forward, as is the case in RIPE, APNIC, and LACNIC. ARIN have opened a consultation process, which closes on the 23rd of May. If you would like to see ARIN also adopt the requirement for AS-SETs to have hierarchical names, please visit the following page and contact ARIN to record your support for this request: https://www.arin.net/participate/community/acsp/consultations/2025/2025-1/ Kind regards, James Bensley (he/him) Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: hello(a)inter.link, Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss

1 0

RIPE Database Acceptable Use Policy Updated
by Edward Shryane 30 Apr '25

30 Apr '25

Dear colleagues, At the 183rd RIPE NCC Executive Board meeting on 21st March 2025, the following changes to the RIPE Database Acceptable Use Policy were approved: * Clarified that the RIPE NCC accounts by prefix, the size of which is determined by the RIPE NCC. This better reflects the reality of how we implemented the feature. * Clarified that the RIPE NCC may lift a permanent block of a user from querying the RIPE database on request, at our sole discretion and on a case-by-case basis. * Use the term "RIPE NCC Access" rather than "SSO". The minutes from the 183rd Executive Board meeting are available: https://www.ripe.net/about-us/executive-board/minutes/2025/183rd-executive-… The updated Acceptable Use Policy is available on the RIPE NCC website : https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… A diff of the changes is visible in the DB documentation repository : https://github.com/RIPE-NCC/ripe-database-documentation/blame/main/docs/25.… Previous discussion: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/VNZW422LST24X6… Regards Ed Shryane RIPE NCC

1 0

Questions on "status:"
by denis walker 29 Apr '25

29 Apr '25

Colleagues I am working with the RIPE NCC to document the current rules for the "status:": attribute values. This is not an attempt to simplify or substantially change the values, although some aspects do need clarifying. There is no documentation anywhere on what the current rules are. This information only exists completely in the RIPE Database software and in the test suite for the database software. The goal is to describe all the current status rules and relationships in the RIPE Database documentation. Some of these rules have never been discussed by the community to the point of a consensus. Some are interpretations made by the database developers over the years (myself included) based on comments in various other discussions. I have some questions that need clarification from the community. I have listed them below. Some might seem obvious, but within the software some things are allowed and some things are not disallowed just because no one has ever specified what it should (not) be. If you have a strong opinion on any of these questions, please share it. Any questions that no one comments on, then as we have done in the past we will document 'an interpretation'. If the community accepts the resulting documentation, the software will be adjusted accordingly. cheers denis 1/ Is there a use case for AGGREGATED-BY-LIR more specific to AGGREGATED-BY-LIR? If so, to how many levels? 2/ Is there a use case for LIR-PARTITIONED PA more specific to ALLOCATED UNSPECIFIED? 3/ Is there a use case for LIR-PARTITIONED PA more specific to SUB-ALLOCATED PA? As the name suggests, it was introduced to partition an allocation. There are currently about 438 hierarchies with LIR-PARTITIONED PA more specific to SUB-ALLOCATED PA in the database. 4/ Is there a use case for LIR-PARTITIONED PA more specific to LIR-PARTITIONED PA? If so, to how many levels? There are currently about 83 hierarchies with LIR-PARTITIONED PA more specific to LIR-PARTITIONED PA in the database. They only exist to two levels. 5/ Should we say that SUB-ALLOCATED PA 'must' be defined in the RIPE Database? This is not clear in the address policy. As we move to a world where not everything must be defined in the database, we probably should be clear about what must be defined there. (Which may require an update to the address policy.) 6/ There are currently multiple levels of SUB-ALLOCATED PA in the database. The max that exists at the moment is 4 levels of SUB-ALLOCATED PA. Is that a reasonable level to set as a limit? Or should we not allow it at all? 7/ Should there be a limit on the number of levels in a LEGACY hierarchy?

1 0

Re: DRAFT Agenda @ RIPE90 - Database Working Group
by William Sylvester 21 Apr '25

21 Apr '25

All, We are a few weeks away from RIPE90 in Lisbon, Portugal. Our session will be after the morning coffee break @ 11:00 in the Main room on 15 May (Thursday). Please take a look at the NWIs to foster good discussion at the meeting. The NWIs are viewable at: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/ Below is the draft agenda, please feel free to offer feedback as appropriate. If you have an interest in presenting to the working group please contact the Database Working Group Chairs at db-wg-chairs(a)ripe.net<mailto:db-wg-chairs@ripe.net>. Best regards, William, Peter, & David DB-WG Chairs A. Introduction - 15 min * Welcome * Scribe * Agenda B. Operational Update– 20 mins Edward Shryane, RIPE NCC C. Your Presentation Here – 25 mins, You, Your Org D. NWI Review – 10 mins, WG Chairs Z. AOB (open discussion)

1 0

Whois Release 1.117
by Edward Shryane 17 Apr '25

17 Apr '25

Dear colleagues, RIPE Database release 1.117 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 17th April. Whois release 1.117 contains the following changes : Inetnum status hierarchy : * Parent status for LIR-PARTITIONED PA cannot be ASSIGNED PA (#1669) * ASSIGNED PA Cannot have less/more specific ASSIGNED PA (#1672) * Aggregation by LIR Parent should not be allowed for Aggregation by LIR (#1673) * Do not allow LIR-PARTITIONED PA under SUB-ALLOCATED PA in (#1702) RDAP RIR Search: * RDAP Self Links Must Have the Type Set (#1685) * RDAP Validate Correct Key Before Redirect (#1689) * RDAP Fix Relation For Cross-Prefix Inetnum Range (#1693) * RDAP Bottom should check Parent does not CONTAINS search term (#1701) * RDAP Non Existing Search IP Terms in TOP and UP (#1703) * RDAP Add "-rdap" prefix to Relations And Change links (#1700) * RDAP Minimum status for Relations (#1705) NRTMv4: * NRTMv4 Correct aut-num object class name in delta file (#1692) * NRTMv4 Client Reject Deltas When Discontinuous and reinitialise (#1699) * NRTMv4 Client Reject update in case client is ahead instead of reinitialise (#1698) OAuth 2.0 (not ready for production use yet) : * Support OAuth 2.0 (#1688) The full list of changes is visible in the source repository: https://github.com/RIPE-NCC/whois/compare/66dd8671...fba36664 The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-117 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 31st March. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Removing all MD5 Hashed Passwords Not Used for Authentication in the past year
by Edward Shryane 02 Apr '25

02 Apr '25

Dear colleagues, According to January's updated migration plan to remove all MD5 hashed passwords from the RIPE database in 2025 : https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/NGCRQWJPF7MT24… In Q2 2025, the RIPE NCC plans to remove all MD5 hashed passwords that have not been used for authentication in the past year, to reduce the risk of having so many MD5 hashes in the database in case of a data breach. Using 1st January 2024 as a cut-off, we found this will affect approximately 17,000 out of 62,000 maintainers. Accordingly, between this April and June, we will split these affected 17,000 maintainers into small groups and email each group separately, explaining that we plan to remove any such hash(es) from their mntner object. We will give each group at least one week's notice before updating their mntner object. We will not quote a password hash in any email to avoid exposing it, the maintainer is expected to know which password(s) are in active use. Affected maintainers will be free to create a replacement MD5 hashed password themselves. However as passwords will be removed by the end of 2025, we will encourage them to switch to an alternative authentication method instead, such as API keys. Most affected maintainers have an alternative method of authentication. However, approximately 3,000 of those do *not* have any alternative. If a maintainer is left without any authentication method, the Forgot Maintainer Password process will have to be followed to regain access to the maintainer. We plan to leave these maintainers until last. Please let us know your comments and/or questions regarding this planned change. Regards Ed Shryane RIPE NCC

2 3

RIPE NCC User Research on OAuth 2.0 Authentication
by Edward Shryane 14 Mar '25

14 Mar '25

Dear colleagues, On 16 April, the RIPE NCC will host an Open House from 13:00 to 14:00 CET to discuss and demo the new OAuth 2.0-based authentication solution for maintainers in the RIPE Database. We have developed a prototype and would like to share it with the community to gather your feedback and find out what your needs are. Please join us for this online discussion. Whether you are a database maintainer, network operator or just interested in authentication developments, your feedback will help shape the final implementation. You can sign up at: https://ripe.net/s/open-house-oauth2-authentication Regards Ed Shryane RIPE NCC

1 0

Mailupdates were not applied to the RIPE database
by Edward Shryane 13 Mar '25

13 Mar '25

Dear colleagues, Between approximately 12:34 UTC on March 11th and 08:18 UTC on March 13th, some mailupdates messages were not applied to the RIPE database. This was due to an upgrade of the database software. The current Long Term Support (LTS) release of Mariadb dropped a reference to mysql which the mailupdates script depended on. If you did not receive any acknowledgement for a mailupdates message during this time, then please re-submit the mailupdate. The DB team apologies for any inconvenience this incident may have caused. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.116
by Edward Shryane 03 Mar '25

03 Mar '25

Dear colleagues, RIPE Database release 1.116 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Monday 3rd March. Whois release 1.116 contains the following changes : * RDAP Relation Searches Endpoint (#1603) * Fixes to RDAP RIR-Search (Basic Searches) Feature (#1611) * Return Abuse-c Entity for RDAP organisation Entity Query (#1659) * Update key-cert lookup URL in update notification (#1631) * Warn if mbrs-by-ref in set object is changed (#1662) * Warn on override if set membership claim is not supported by mbrs-by-ref (#1660) * NRTMv4 use EC p256 key instead of ec25519 (#1645) * Remove old NRTMv4 Update Notification File Links (#1652) * Do not send the SOURCE in NRTMv4 relative URLs (#1654) The full list of changes is available in the source repository: https://github.com/RIPE-NCC/whois/compare/930e4aba...66dd8671?expand=1 We plan to enable API keys functionality in test envionments after this production release. The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-116 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the Release Candidate environment is a dummified copy of production from 16th February. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

2 1

Something wrong?
by Hank Nussbacher 28 Feb '25

28 Feb '25

Hi, When attempting to update an in-addr.arpa object today, I repeatedly get: Unexpected error: please retry later Did not happen yesterday. Is it just me or everyone? Regards, Hank

2 3

Whois Release 1.115.1
by Edward Shryane 03 Feb '25

03 Feb '25

Dear colleagues, We have just deployed Whois release 1.115.1 to production. This release contains a single change since release 1.115 last week. We fixed an issue where the mntner details were not parsed properly when authenticating an API key, even though the API key was valid. We did not wait for the usual 2 week testing period in the RC environment because this issue was sometimes causing updates using API key authentication to fail. There was no other impact to application security, and no other changes were included. Thanks to the community member who reported this issue. Regards Ed Shryane RIPE NCC

1 0

Using API Keys in the RIPE Database
by Edward Shryane 31 Jan '25

31 Jan '25

Dear colleagues, We have now enabled API keys for authenticating updates in the RIPE database. We have written a RIPE Labs article including a video on how to use this feature: https://labs.ripe.net/author/ed_shryane/using-api-keys-in-the-ripe-database/ Please let me know if you have any comments. Regards Ed Shryane RIPE NCC

2 2

Chicken and egg in regards to inverse
by Hank Nussbacher 30 Jan '25

30 Jan '25

We have a customer with an inverse object (in-addr.arpa) whereby the 3 nameservers listed are long extinct and need to be replaced. So the customer went to Cloudflare and paid to use their 2 nameservers (specifically harley.ns.cloudflare.com and teagan.ns.cloudflare.com). Yet, when I go to RIPE to update their inverse record I get many standard errors that the nameservers do not exist yet to serve this inverse domain. The customer tried to create the zone in cloudflare, but CF asks them to change the DNS in the RIPE object, but to change the RIPE object they need first to have an active DNS zone…. So what is one to do in such a case? Thanks, Hank

3 3

Updated Migration Plan to Remove MD5 Hashed Passwords from the RIPE Database
by Edward Shryane 30 Jan '25

30 Jan '25

Dear colleagues, You will find below an updated draft of the migration plan to remove MD5 hashed passwords from the RIPE Database in 2025. The original migration plan was announced last September to the DB-WG and at RIPE 89 in October: https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/FTOPBPOGWIQFQP… Thank you all for your valuable feedback, which we have taken into consideration, and in summary we now plan to deploy support for OAuth 2.0 in mid-2025, and we will delay the phase-out of MD5 hashed passwords completely to the end of 2025. The updated migration plan is as follows: * 30 January: Introduced support for API keys in the RIPE Database. * Q2 2025: Remove all MD5 hashed passwords that have not been used for authentication in the past year. This new step reduces the risk of having so many MD5 hashes in the database in case of a data breach, while minimising inconvenience for maintainers that are actively using passwords. This step will affect about 14,000 maintainers which have an alternative method of authentication (out of 62,000 total maintainers), and about 2,000 maintainers with no alternative method of authentication other than passwords. We will communicate this in advance to the DB-WG and to affected maintainers, and encourage them to switch to an alternative authentication method. * Q3 2025: Introduce support for OAuth 2.0 authentication, which will provide automation, including key rollover. * Q3 2025: Communicate to the DB-WG and affected maintainers that we plan to remove support for MD5 hashed passwords before the end of 2025. * Q3 2025: Select batches of maintainers to migrate away from passwords. * Warn that we will remove their MD5 hashed passwords in one month * Assist anyone who asks for help to switch to an alternative * Remove MD5 hashed passwords in batches * Q4 2025: Remove support for MD5 hashed passwords altogether. After that, any maintainers without an alternative authentication method must follow the “Forgot Maintainer Password” process, or contact the RIPE Database support directly. Please let us know if you have any comments on the details and timing. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.115
by Edward Shryane 30 Jan '25

30 Jan '25

Dear colleagues, RIPE Database release 1.115 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 30th January. The 1.115 release has the following main changes: * API key authentication for queries and updates * Use relative path in NRTMv4 update notification file * Add JWS Support To Fix Race Condition in NRTMv4 * NRTMv4 client implementation * Add MNTNER to RDAP Entities Search * Import ARIN and LACNIC IRR database dumps into mirror * Syncupdates will return an error in future if used over HTTP * Mailupdates will return an error in future if a password is used * Include password authentication type in Whois Update notifications * Extend Maximum Length of an Email Address * Allow blocking by source address on Port 43 Queries * Generate mail Message-ID including angle brackets. * Change Database Schema from Latin-1 to UTF-8 The full list of changes is available in the source repository: https://github.com/RIPE-NCC/whois/compare/15434524...930e4aba?expand=1 Please note that because API key functionality in RIPE NCC Access is not available yet, it will not be enabled in the Release Candidate environment for now. The release notes are on the website: https://docs.db.ripe.net/Release-Notes/#ripe-database-release-1-115 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the RC environment is a dummified copy of production from 13th January. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Identifying IX space in the database
by Ben Cartwright-Cox 23 Jan '25

23 Jan '25

Hey everybody! I was wondering if it was possible to tell if an inetnum or inet6num was assigned for the purpose of an internet exchange. Looking at the inetnum objects for 185.1.0.0/16 (that seems to now be depleted) it does not seem there is anything different between a IX allocation and a regular allocation, in either the delegate file or the actual DB. Anyone know any better? Ben

3 2

ALLOCATED-ASSIGNED PA with another org than the LIR's org itself ?
by Clement Cavadore 16 Dec '24

16 Dec '24

Dear all, I am trying to make my first ALLOCATED-ASSIGNED PA block for one of my end user. It seems that I cannot change the org: line, as it's also the same inetnum than my own LIR. Is there any way to be able to associate another org object to the whole inetnum, without loosing the link with the parent LIR of that block ? Thanks in advance for your help ! Kind regards, Clément Cavadore

4 4

sub-allocation
by denis walker 31 Oct '24

31 Oct '24

Colleagues During the discussion in the DB-WG session this morning there was a question about sub-allocations. It was asked if it could be possible to identify when resources have been sub-allocated. Hans Petter said it would be possible to give some indication of this. Well, sorry, but NO. Thanks to 2023-04 it is no longer possible to identify sub-allocations. I believe most people were so focused on making assignments optional, no one gave any thought to the consequences of making the simple technical change of adding the status value 'aggregated-by-lir'. As I pointed out in an email some months ago, this has broken the database in many ways. An LIR with an allocation can now simply split that allocation in half and create two objects with status 'aggregated-by-lir'. The boundary between the two aggregations does not even need to match the boundaries of any more specific ranges. There are NO rules about using this status. Absolutely nothing else more specific to these aggregations needs to be documented in the RIPE Database, in any public domain or notified to the RIPE NCC. The LIR may make a sub-allocation of, say, a /24 below one of these aggregations. Or maybe below both of them, crossing the boundary. You will never know what they have done. That sub-allocation holder may sub-allocate again. They can even sub-allocate the whole sub-allocation. Because you do not need to create objects in the database, there is no reason why the whole range cannot be sub-allocated. There are no rules!!! The same block can be sub-allocated 100 times in a long chain of downstream customers. There are no rules!!! Even if there were rules, they would not be enforceable as no one can 'see' what is being done with these addresses. Finally the whole block could be assigned to an End User. This has serious consequences to rights enforcers and law enforcement trying to find that End User. They will never be found. As things stand, because none of the details of this chain of downstream customers is public information, court orders will be needed to identify each layer. In practice this means 100 sequential court orders, each one identifying the next link in the chain. This could zig zag across multiple countries, multiple legal jurisdictions, in multiple languages.The LIR does not know who the End User is. They only know who they sub-allocated to. Only the last link in the sub-allocation chain knows who the End User is. This situation was created by 2023-04 and a lack of attention to detail. We cannot allow this situation to continue. I would suggest we create/amend a policy so that when an LIR is served a court order to identify the (End) User of an IP address, the obligation is on the LIR to internally follow any such chain of sub-allocations, whether it is 1 or 100, to identify the End User. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================

3 8