HTTP/2 200 date: Mon, 14 Jul 2025 10:31:27 GMT content-type: text/plain content-length: 1223 x-xss-protection: 1; mode=block referrer-policy: no-referrer, same-origin, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-content-type-options: nosniff last-modified: Fri, 17 Jan 2020 00:35:40 GMT etag: "c9f-59c4b1efe0f00-gzip" cache-control: max-age=3600, public expires: Mon, 14 Jul 2025 11:31:27 GMT vary: Accept-Encoding content-encoding: gzip x-envoy-upstream-service-time: 4 strict-transport-security: max-age=15552000; preload cf-cache-status: MISS accept-ranges: bytes content-security-policy: frame-ancestors 'self' https://rex.apnic.net https://rex.stg.xyz.apnic.net server: cloudflare cf-ray: 95f059bdbf8e755c-BLR ------------------------------------------------------- prop-133-v001: Clarification on Sub-Assignments ------------------------------------------------------- Proposer: Jordi Palet Martinez jordi.palet@theipv6company.com 1. Problem statement ------------------------------------------------------- Note that this proposal is ONLY relevant when end-users obtain direct assignments from APNIC, or when a LIR obtains, also from APNIC, and assignment for exclusive use within its infrastructure. Consequently, this is NOT relevant in case of LIR allocations. The intended goal of assignments is for usage by end-users or LIRs in their own infrastructure (servers, equipment, interconnections, employees, guest devices, subcontractors, only within that infrastructure), not for sub-assignment in other networks. The current text uses a ?must? together with ?documented purposes?. As a consequence, if there is a request with a documented purpose, and in the future the assigned space is used for some other purposes, it will violate the policy. For example, a university may document in the request, that the assigned addressing space will be used for their own network devices and serves, but afterwards they also sub-assign to the students in the campus (still same infrastructure). This last purpose was not documented, so it will fall out of the policy. 2. Objective of policy change ------------------------------------------------------- Clarification of the text, by rewording it. 3. Situation in other regions ------------------------------------------------------- This situation, has already been corrected in AFRINIC, ARIN, LACNIC and RIPE. 4. Proposed policy solution ------------------------------------------------------- Actual text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific, documented purposes and may not be sub-assigned. Proposed text: 2.2.3. Assigned address space Assigned address space is address space that is delegated to an LIR, or end-user, for exclusive use within the infrastructure they operate, and may not be sub-assigned to other networks. 5. Advantages / Disadvantages ------------------------------------------------------- Advantages: Advantages of the proposal: Fulfilling the objective above indicated and making sure to match the real situation in the market. Disadvantages: Disadvantages of the proposal: None foreseen. 6. Impact on resource holders ------------------------------------------------------- Impact on resource holders: None. 7. References ------------------------------------------------------- AFRINIC: https://www.afrinic.net/policy/2018-v6-002-d3#details ARIN: https://www.arin.net/participate/policy/nrpm/#2-5-allocation-assignment-reallocation-reassignment and https://www.arin.net/participate/policy/drafts/2019_15/ LACNIC: https://politicas.lacnic.net/politicas/detail/id/LAC-2018-7?language=en RIPE NCC: https://www.ripe.net/participate/policies/proposals/2016-04