To All Concerned. I believe prop-164, as worked in version 5, allows for WHOIS, and RDAP records to be more granular, allowing /36, and /40 nibble-boundary allocated IPv6 prefixes, or resources to be recorded, and publicly identifiable.
Hence, I fully support this proposal. Kind Regards Rickash Raamah Chand (he/him/his) IP Manager – Fiji Hub, Technical Operations Digicel Central Resources (Fiji) PTE Limited Lot 2-3 Khalsa Road, Nasinu, Fiji | GMT +12 +6797015348 Upcoming Leave: Nil From: Bikram Shrestha <[email protected]> Sent: Saturday, 1 August 2026 04:31 To: [email protected] Cc: [email protected]; mailman_SIG-policy-chair <[email protected]> Subject: [EXTERNAL] [sig-policy] Prop-164-v005: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment Dear SIG members, A new version of the proposal "prop-164: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment" has been sent to the Policy SIG for review. Information about earlier versions is available Dear SIG members, A new version of the proposal "prop-164: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment" has been sent to the Policy SIG for review. Information about earlier versions is available from: https://www.apnic.net/community/policy/proposals/prop-164/<https://urldefense.com/v3/__https:/www.apnic.net/community/policy/proposals/prop-164/__;!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff9AQnVXO$> You are encouraged to express your views on the proposal: * Do you support or oppose the proposal? * Is there anything in the proposal that is not clear? * What changes could be made to this proposal to make it more effective? Please find the text of the proposal below. Regards, Bikram, Shaila, and Ching-Heng APNIC Policy SIG Chairs --------------------------------------------------------------------------------- prop-164-v005: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment --------------------------------------------------------------------------------- Proposers: Christopher Hawker ([email protected]<mailto:[email protected]>) Luke Thompson ([email protected]<mailto:[email protected]>) 1. Problem statement -------------------- Currently, if an account holder receives an assignment longer than a /32 (e.g. a /40), they cannot make sub-assignments to their customers or internal areas within their organisation and maintain accurate records of longer prefixes regarding these sub-assignments within Whois/RDAP. If they want to properly document sub-assignments and update Whois, they are required to request a /32. Maintaining accurate records is critical to ensure the stable and secure management of Internet Number Resources. 2. Objective of policy change ----------------------------- This policy change will reduce the minimum allocation size from a /32 prefix to a /40 prefix. This is to reduce the minimum amount of resources which a member has to apply for, which in turn allows them to maintain more accurate Whois/RDAP records. 3. Situation in other regions ----------------------------- - ARIN already allows for /36 and /40 prefix delegations under section 6.5.2.1 of their Number Resource Policy Manual. - LACNIC, RIPE NCC and AFRINIC policies all still list /32 as the minimum allocation size. 4. Proposed policy solution --------------------------- Update "APNIC-127 APNIC Internet Number Resource Policies" per the below: - 5.2.3.1 LIR-to-ISP allocation Add a new line that reads: "When an LIR makes a delegation to an ISP with whom they are directly connected, they must update the Whois database with the relevant delegation details." - 8.1 Minimum IPv6 allocation Replace the first paragraph with: "The minimum allocation size for IPv6 address space is /40." - 8.1.1 Returning excess IPv6 allocation/s Add new section 8.1.1 with: "If an account holder has been allocated a /32 or shorter, they will be eligible to return the balance of their allocation, reducing their allocation size to a /40. If a member has a /32 or shorter IPv6 allocation, they may reduce it to a /40 by keeping the first /40 and returning all other space." - 8.2.1 Account holders with existing IPv4 space Replace "An account holder that has an IPv4 allocation is eligible for a /32 IPv6 address block" with "An account holder that has an IPv4 allocation is eligible for a /40 IPv6 address block". - (NEW) 8.2.3 Reservation of IPv6 space for future expansion Add a new section with the above title and the following text: "When an account holder requests an allocation longer than a /28, APNIC will make a sparse allocation from a /28 address block. The difference in block size will be reserved for future allocations to the account holder. If in the event that APNIC exhausts its available IPv6 pool and is unable to secure further delegations, reserved space will be released into the free pool for further delegation to other account holders." [Context (not part of the proposal): If a member requests a /32, the Secretariat will select an available /28 block and allocate the first /32 to the account holder, reserving all other space from that /28 for the account holder's future requests. If the member in 2 year's time comes back to the Secretariat requesting another /32, the Secretariat will be able to allocate the second /32 from that reserved /28 and update delegation records to reflect that a /31 has been delegated as opposed to 2 x /32 blocks.] - 8.3.1 Existing IPv6 address resource holders Replace paragraph 1 with the following: "Resource holders that have received between a /40 and /33 IPv6 allocation are immediately entitled to have their allocation expanded to a /32 address block, without providing justification, so long as they satisfy the criteria in Section 8.2.2. "The /32 address block will contain the already allocated smaller address block (one or multiple /40 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the account holder. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in this document." - (NEW) 8.4 Size of IPv6 Allocation(s) Add a new section with the above title and the following text: "For all allocations (initial or subsequent) made under this policy, the allocation size must align with the next shortest 4-bit (nibble) boundary. For example, if an account holder submits a request for a /42 IPv6 allocation, they shall be allocated a /40 IPv6 address block without requiring additional justification." 5. Advantages / Disadvantages ----------------------------- Advantages: - This would allow members to maintain more accurate records for longer prefixes from a delegation within the Whois database. Disadvantages: - None known. 6. Impact on resource holders ----------------------------- No known impacts to resource holders. 7. References ------------- https://www.apnic.net/community/policy/resources#a_h_2_2_3<https://urldefense.com/v3/__https:/www.apnic.net/community/policy/resources*a_h_2_2_3__;Iw!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff0WTrTeG$> https://www.apnic.net/community/policy/resources#a_h_5_2_3_1<https://urldefense.com/v3/__https:/www.apnic.net/community/policy/resources*a_h_5_2_3_1__;Iw!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff-5hI6Ka$> https://www.apnic.net/community/policy/resources#a_h_8_1<https://urldefense.com/v3/__https:/www.apnic.net/community/policy/resources*a_h_8_1__;Iw!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064XdffyNArn77$> https://www.apnic.net/community/policy/resources#a_h_8_2_1<https://urldefense.com/v3/__https:/www.apnic.net/community/policy/resources*a_h_8_2_1__;Iw!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff_TDIAsB$> https://www.arin.net/participate/policy/nrpm/#6-5-2-1-size<https://urldefense.com/v3/__https:/www.arin.net/participate/policy/nrpm/*6-5-2-1-size__;Iw!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff8FhIguS$> _______________________________________________ Go to the SIG-policy-chair mailing list on Orbit -- https://orbit.apnic.net/mailing-list/[email protected]<https://urldefense.com/v3/__https:/orbit.apnic.net/mailing-list/[email protected]__;!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff_euWA3i$> Explore https://orbit.apnic.net<https://urldefense.com/v3/__https:/orbit.apnic.net__;!!GksAkFH6tHR23NI!tUmebPFCxhvj6VIBYPNJjFQY4WbnZY7W9mR-YGhWiz-V7aaWPZfnPEaIF0kMCh0Vz_obnLvwbs064Xdff0CGlLdM$>, where the APNIC community connect, discuss and share information related to Internet addressing and networking. To unsubscribe send an email to [email protected]<mailto:[email protected]> ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
