Two new suggestions have been received (2026.7 & 2026.8). You may find the new suggestions and links in full below.
Regards, ARIN ----- ACSP Suggestion 2026.7: Allow Customers with Reallocated Resources to Create ROAs https://www.arin.net/participate/community/acsp/suggestions/2026/2026-07/ Author: Salvador Bertenbreiter Description: This is a follow-up suggestion related to ACSP Suggestion 2023.8, “Allow Customers with reallocated resources to create ROAs.” We would like to kindly ask ARIN to revisit this topic, or to provide an updated status on whether there may be a path to support ROA creation for downstream organizations that have valid reallocated or reassigned resources registered under their ARIN OrgID. Today, a downstream organization may have NET objects properly registered under its ARIN OrgID, but ARIN Online may still show RPKI Eligibility as disabled. In that situation, the downstream organization cannot create ROAs directly, even if it is the network actually originating the prefixes in BGP and managing the day-to-day routing operations. In our case, our organization, has received some reallocation from Cogent, these prefixes are visible as reallocated to our ARIN OrgID, but ARIN Online currently shows RPKI Eligibility as disabled for our organization. Because of this, we are not able to create or update ROAs directly for these prefixes. We understand that there may be technical, policy, legal, and operational considerations involved. Our goal is not to bypass the direct resource holder or change the registration status of the resources, but rather to explore whether ARIN could support a safe and controlled way for downstream organizations to manage routing security for resources that are already registered to them. A possible outcome could be that ARIN allows downstream organizations with properly registered reallocated or reassigned resources under their OrgID to create ROAs for those specific resources, subject to appropriate safeguards. If direct support is not feasible, another possible approach could be an opt-in model where the direct resource holder authorizes the downstream OrgID to manage ROAs for specific reallocated or reassigned NET objects. We would also appreciate any update ARIN can share regarding ACSP Suggestion 2023.8, including whether the previous review or community consultation identified specific blockers, concerns, or possible implementation paths. Potential implementation models could include: Direct downstream ROA management: Allow an OrgID with a valid reallocation or reassignment record to create ROAs for the exact registered resource, limited to that resource and its more-specifics. Opt-in authorization: Allow the direct resource holder to delegate ROA-management authority to the downstream OrgID for specific reallocated or reassigned NET objects. Ticket-based approval: Allow the downstream OrgID to request RPKI eligibility for a reallocated or reassigned resource, with notice to the direct holder and an approval or non-objection workflow. API-supported delegation: Expose this authorization through ARIN Online and Reg-RWS so organizations can manage ROA delegation and revocation in a consistent and auditable way. Value to Community: This suggestion could help improve routing security and make RPKI adoption easier for organizations that operate networks using legitimately reallocated or reassigned ARIN resources. In many cases, the downstream organization is the party operating the network, originating the prefixes in BGP, managing traffic engineering, and responding to operational events such as DDoS attacks. However, under the current model, that organization may not be able to directly create or update ROAs for the resources it operates. Instead, it must ask the direct resource holder to create or modify ROAs on its behalf. Many direct resource holders are very helpful and responsive, but the current model can still create operational friction. ROA changes may be time-sensitive, especially when a network needs to add a new origin ASN, update a maximum prefix length, or temporarily use a DDoS mitigation provider. This change could provide value to the community in several ways: Better operational alignment: It would allow routing security management to be closer to the organization actually operating and originating the prefixes. Faster response during incidents: Downstream operators could respond more quickly when ROA changes are needed for DDoS mitigation, traffic engineering, or emergency routing changes. Reduced support burden: Direct resource holders would no longer need to manually handle every routine ROA change for every downstream customer, especially if ARIN implements a clear delegation or authorization model. Lower risk of routing errors: Allowing the operational network to manage its own ROAs could reduce the chance of incomplete, outdated, or incorrect ROA information. Increased RPKI adoption: Some downstream operators may be more likely to adopt RPKI if they can manage the ROAs for the resources they operate, or if there is a clear and trusted authorization workflow. Better support for real-world network operations: Many networks today use reallocated or reassigned resources in legitimate operational scenarios. A controlled ROA management model would make RPKI more practical for these networks without changing resource ownership or registration control. This suggestion is intended to be collaborative. It does not seek to change the ownership of resources, bypass the direct resource holder, or remove appropriate safeguards. Rather, it asks whether ARIN can provide a secure and auditable way for downstream organizations to help maintain accurate routing-security information for resources that are already registered to their OrgID. Status: Confirmed ----- ACSP Suggestion 2026.8: Lowercase IPv6 in Networks CSV per RFC 5952 https://www.arin.net/participate/community/acsp/suggestions/2026/2026-08/ Description: Lowercase IPv6 in Networks CSV per RFC 5952 Value to Community: The “Manage Networks” page has a button to download a CSV. The IPv6 networks in the CSV are formatted in uppercase. It would be more readable and more standard to use lowercase instead, as recommended by RFC 5952. Manage Networks page: https://account.arin.net/public/secure/net Download CSV endpoint: https://accountws.arin.net/public/rest/net/download RFC 5952: https://www.rfc-editor.org/rfc/rfc5952#page-10 Status: Confirmed _______________________________________________ arin-suggestions mailing list [email protected] https://lists.arin.net/mailman/listinfo/arin-suggestions
