Dear Colleagues, I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share key feedback from our community regarding prop-170, based on a meeting we organized on 24th Aug to discuss these proposals. Please note that this is a summary of the discussions among the 17 Japanese community members who attended the meeting. Overall, participants expressed mostly negative opinions toward this proposal. (Comment details) - Participants questioned whether there is sufficient operational demand for nibble-boundary allocations to justify changing the policy. - The proposal would result in significantly larger allocations than actually requested in many cases. Participants felt that stronger justification is needed for such additional address consumption. - Some participants considered that existing sparse allocation practices already provide sufficient flexibility for future expansion. - Several participants felt that improved readability alone is not a sufficient reason to justify allocating substantially larger address blocks. Regards, Satoru Tsurumaki Japan Open Policy Forum Steering Team 2026年7月25日(土) 14:08 Shaila Sharmin <[email protected]>: > Dear SIG members, > > > > A new proposal "prop-170: Nibble-Boundary Alignment for IPv6 Allocations" > > has been sent to the Policy SIG for review. > > > > It will be presented at the Open Policy Meeting (OPM) at APNIC 62 on > Thursday, 10 September 2026. > > > > https://conference.apnic.net/62/program/program/index.html#/day/7/ > > > > We invite you to review and comment on the proposal on the mailing list > before the OPM. > > > > The comment period on the mailing list before the OPM is an important part > of the Policy Development Process (PDP). > > We encourage you to express your views on the proposal: > > > > Do you support or oppose this proposal? > > > > Does this proposal solve a problem you are experiencing? If so, > > tell the community about your situation. > > > > Do you see any disadvantages in this proposal? > > > > Is there anything in the proposal that is not clear? > > > > What changes could be made to this proposal to make it more effective? > > > > Information about this proposal is appended below as well as available at: > > > > > > https://www.apnic.net/community/policy/proposals/prop-170/ > > > > Regards, > > Bikram, Shaila, and Ching-Heng > > APNIC Policy SIG Chairs > > > > > > > > ------------------------------------------------------------------------ > > prop-170-v001: Nibble-Boundary Alignment for IPv6 Allocations > > ------------------------------------------------------------------------ > > > > > > Proposer: Haisheng Yu* > > [email protected]* > > [email protected] > > > > > > Joint proposer: Haijun Li > > [email protected] > > > > > > 1. Problem statement* > > -------------------- > > > > The APNIC Internet Number Resource Policies establish the rules for IPv6 > allocations and assignments in the Asia Pacific region. Section 8 governs > IPv6 allocations. Section 8.1 establishes a minimum IPv6 allocation size of > /32 and allows a larger initial allocation where comprehensive > documentation supports a larger calculated address requirement. Section > 8.3.4 provides that an eligible account holder may receive a subsequent > allocation that doubles the address space allocated to it and, where > possible, expands the existing allocation using adjacent address space. > > > > The current policy does not establish a general principle for aligning > IPv6 allocations to hexadecimal nibble boundaries. A nibble boundary is a > prefix length evenly divisible by four, such as /20, /24, /28, or /32. > Because IPv6 addresses are expressed in hexadecimal notation and each > hexadecimal character represents four bits, nibble-boundary aligned blocks > are generally easier to read, document, subdivide, automate, audit, and > incorporate into long-term IPv6 address plans. > > > > Under the current policy, valid allocation outcomes may include prefixes > such as /21, /23, /27, /29, /30, or /31. These prefixes are technically > valid and can be routed, registered, and used. However, repeated one-bit > expansions, or allocations based only on a non-aligned calculated > requirement, may produce address plans that require additional operational > handling in IP address management systems, customer addressing structures, > routing templates, security segmentation records, audit systems, and future > expansion planning. > > > > APNIC already uses a Sparse Allocation Framework to improve the > possibility of contiguous growth. However, Section 8 does not currently > provide a clear policy basis for nibble-boundary alignment where an LIR > explicitly requests alignment and supports the request with a long-term > IPv6 address plan. > > > > This proposal introduces a conditional nibble-boundary alignment mechanism > for IPv6 allocations under Section 8. It applies to larger initial > allocations and to subsequent allocations where the applicable eligibility > and needs-based requirements have been met. It does not amend any IPv6 > assignment policy under Section 9. > > > > Nibble-boundary alignment does not replace APNIC's existing needs-based > assessment. This proposal does not change: > > > > - the /32 minimum IPv6 allocation size; > > - the HD-Ratio utilization requirements; > > - the one-bit doubling mechanism as the default mechanism for > subsequent allocations; > > - the eligibility and documentation requirements for larger > allocations; > > - APNIC's Sparse Allocation Framework; > > - the treatment of multiple discrete networks; or > > - any IPv6 assignment policy under Section 9. > > > > Existing resource holders will not be required to renumber, return, or > resize any previously delegated IPv6 prefix. > > > > > > 2. Objective of policy change > > ----------------------------- > > > > The objective of this proposal is to introduce a clear and conditional > nibble-boundary alignment mechanism for LIR IPv6 allocations under Section > 8, while preserving APNIC's existing needs-based review, resource > stewardship, and operational flexibility. > > > > Under the proposed policy: > > > > - Section 8.0 will define a nibble boundary, define the supporting > long-term IPv6 address plan, and clarify the scope of the proposal; > > - Section 8.1 will provide that, where an applicant explicitly > requests nibble-boundary alignment and supports the request with a > long-term IPv6 address plan, APNIC will normally delegate the smallest > nibble-boundary aligned block that can satisfy the calculated address > requirement; > > - Section 8.3.4 will retain one-bit doubling as the default subsequent > allocation size; > > - an account holder requesting a subsequent allocation larger than the > default doubling must continue to justify the new requirement under the > existing needs-based criteria; > > - after the larger requirement has been validated, where possible, the > existing allocation will be expanded so that the resulting aggregate is > nibble-boundary aligned and sufficient to satisfy the validated requirement; > > - if the existing allocation cannot be expanded, or cannot be expanded > adequately, APNIC may make a separate allocation of the size justified, on > a nibble boundary where operationally practicable; > > - nibble-boundary alignment will not be an unconditional entitlement; > and > > - Sections 8.2.1, 8.2.2, and all of Section 9 will remain unchanged. > > > > > > 3. Situation in other regions > > ----------------------------- > > > > ARIN Number Resource Policy Manual (NRPM), Section 6, provides the > clearest existing RIR policy example for nibble-boundary IPv6 allocation > and assignment. > > > > Key original wording from ARIN includes: > > > > - Section 6.5.1 defines a nibble boundary as a "network mask which > aligns on a 4-bit boundary". > > - Section 6.5.2.1 states: "All allocations shall be made on nibble > boundaries." > > - Section 6.5.8.3 uses the concept of "one or more justified nibble > boundaries" for subsequent end-user assignments. > > > > The relevant ARIN policy structure is broader than a single definition. > Section 6.3.4 identifies aggregation as an IPv6 address management goal and > explains that IPv6 policy should avoid fragmentation of address ranges. > Section 6.3.7 addresses the need to reduce administrative overhead and > avoid repeated small incremental requests. Section 6.3.8 states that > aggregation is the most important IPv6 address policy goal. > > > > ARIN's policy demonstrates that nibble-boundary allocation can coexist > with needs-based review. It does not operate as uncontrolled > over-allocation. Instead, it combines a clear definition, needs-based > eligibility, controls for large allocation sizes, contiguous expansion > where possible, and operational flexibility for special network structures. > > > > The current RIPE IPv6 policy, RIPE-738, does not establish a general > mandatory nibble-boundary rule for LIR allocations equivalent to ARIN's. > However, its top-level policy objectives are closely aligned with the > operational rationale of this proposal and provide policy-level support for > the same direction: aggregation, avoidance of fragmentation, and reduced > administrative overhead. > > > > Key original wording from RIPE-738 includes: > > > > - Section 2.7 identifies minimizing overhead as a policy goal, > including minimizing "overhead associated with obtaining address space". > > - Section 3.4 states that IPv6 address space should be distributed in > a hierarchical manner "to permit the aggregation of routing information" > and that aggregation is the "highest priority" in IPv6 address policy. > > > > RIPE Policy Proposal 2024-01 is not current RIPE policy and does not > revise LIR PA allocation rules. It concerns IPv6 Provider Independent > assignments for end users. Although the scope is different, the proposal's > core operational logic is relevant: nibble-boundary sizing can reduce > repeated incremental requests, avoid network-wide renumbering, and trade a > modest short-term increase in delegated address space for longer-term > operational stability. > > > > This proposal is distinct from APNIC prop-164. It does not reduce the > minimum IPv6 allocation from /32, does not establish /36 as the new minimum > allocation, and does not require existing resource holders to return > address space. Prop-164 addressed whether smaller initial IPv6 allocations > should be available under APNIC policy. This proposal instead adds a > conditional nibble-boundary planning rule for Section 8 LIR IPv6 > allocations while preserving APNIC's existing needs-based review framework. > > > > > > 4. Proposed policy solution > > --------------------------- > > > > This proposal makes three policy text changes: > > > > - add definitions and scope under Section 8.0; > > - add a conditional alignment paragraph under Section 8.1; and > > - add a conditional alignment mechanism under Section 8.3.4. > > > > > > 4.1 Add definitions and scope under Section 8.0 > > > > Insert the following text immediately after the heading "8.0 IPv6 > allocations": > > > > Nibble-boundary alignment > > > > A nibble boundary is a prefix length evenly divisible by four. > > > > For the purposes of Sections 8.1 and 8.3.4, a long-term IPv6 address > plan is documentation supporting the requested allocation size. It may > include, as applicable, expected user, customer, or site growth; the extent > of the infrastructure; hierarchical and geographical network structure; > security segmentation; and the planned longevity of the allocation. > > > > Nibble-boundary alignment applies only where an applicant explicitly > requests it and provides the supporting long-term IPv6 address plan > required by the applicable section. > > > > Nibble-boundary alignment does not replace or reduce any eligibility, > utilization, HD-Ratio, or documentation requirement. It does not create an > unconditional entitlement to additional address space. > > > > These provisions apply only to IPv6 allocations under Section 8. They > do not amend any IPv6 assignment policy under Section 9. > > > > > > 4.2 Amend Section 8.1 Minimum IPv6 allocation > > > > Retain the existing text of Section 8.1 and add the following paragraph > after its existing final paragraph: > > > > Where an applicant explicitly requests nibble-boundary alignment and > provides a long-term IPv6 address plan, APNIC will normally delegate the > smallest nibble-boundary aligned block that can satisfy the calculated > address requirement. > > > > This provision applies only after the address requirement has been > assessed in accordance with this section. It does not replace the HD-Ratio > based utilization policy or any supporting-documentation requirement. > > > > Section 8.1 establishes the /32 minimum allocation size and governs the > sizing of larger initial allocations. > > > > The expression "the smallest nibble-boundary aligned block that can > satisfy the calculated address requirement" means the least amount of > nibble-boundary aligned address space capable of meeting the requirement > calculated under the existing policy. The alignment mechanism does not > independently establish or enlarge the underlying requirement. > > > > If nibble-boundary alignment is not requested, the initial allocation will > continue to be processed under the existing Section 8.1 and Section 8.2 > rules. > > > > > > 4.3 Amend Section 8.3.4 Size of subsequent allocation > > > > Retain the existing text of Section 8.3.4: > > > > When an account holder has achieved an acceptable utilization for its > allocated address space, it is immediately eligible to obtain an additional > allocation that results in a doubling of the address space allocated to it. > > > > Where possible, except where separate disaggregated ranges are > requested for multiple discrete networks, the allocation will be made from > an adjacent address block, meaning that its existing allocation is extended > by one bit to the left. > > > > If an account holder needs more address space, it must provide > documentation justifying its new requirements. The allocation size will be > based on the new needs (the number of users, the extent of the > infrastructure, the hierarchical and geographical structuring of the > account holder's operations, the segmentation of infrastructure for > security and the planned longevity of the allocation). > > > > Add the following text at the end of Section 8.3.4: > > > > The one-bit doubling described above remains the default subsequent > allocation size where eligibility is based on acceptable utilization alone. > > > > Where an account holder explicitly requests nibble-boundary alignment > for a subsequent allocation larger than the default doubling, it must > provide a long-term IPv6 address plan as part of the documentation > justifying its new requirements. > > > > After APNIC validates the larger requirement: > > > > 1. Where possible, the subsequent allocation will result in the > expansion of the existing allocation by one or more nibble boundaries, as > justified by the validated requirement. > > > > 2. If the existing allocation cannot be expanded, or cannot be > expanded adequately to meet the validated requirement, APNIC may make a > separate new allocation using a nibble-boundary aligned block sufficient to > satisfy the validated additional requirement. > > > > If nibble-boundary alignment is not requested, the subsequent > allocation will continue to be processed under the existing one-bit > doubling and needs-based sizing rules in this section. > > > > This amendment preserves one-bit doubling as the default subsequent > allocation mechanism. > > > > An account holder cannot obtain a substantially larger allocation solely > because it prefers nibble-boundary alignment. A request larger than the > default doubling must first be supported and validated under the existing > needs-based criteria. > > > > The wording follows the operational structure used in ARIN policy: expand > the existing allocation where possible and, where sufficient expansion is > not possible, make a separate allocation of the size justified. > > > > > > 4.4 Sections and mechanisms not amended > > > > This proposal makes no text change to: > > > > - Section 8.2.1, Account holders with existing IPv4 space; > > - Section 8.2.2, Account holders without existing IPv4 space; > > - Section 8.3.1, Existing IPv6 address resource holders; > > - Section 8.3.2, Applied HD-Ratio; > > - Section 8.3.3, Alternative allocation criteria; or > > - Section 9, IPv6 assignments. > > > > The following existing mechanisms also remain unchanged: > > > > - the /32 minimum IPv6 allocation; > > - the HD-Ratio value and utilization thresholds; > > - one-bit doubling as the default subsequent allocation size; > > - APNIC's Sparse Allocation Framework; and > > - the exception for multiple discrete networks. > > > > > > 5. Advantages / Disadvantages > > ----------------------------- > > > > Advantages > > > > - Establishes a clear Section 8 allocation mechanism > > > > The proposal gives APNIC, NIRs, LIRs, and request evaluators a clear > policy basis for considering nibble-boundary alignment instead of treating > it only as an informal operational preference. > > > > - Improves operational clarity > > > > Nibble-boundary aligned blocks are easier to read, document, verify, > subdivide, and process in IP address management, automation, logging, > routing policy, security segmentation, reverse DNS, and audit systems. > > > > - Supports hierarchical planning and aggregation > > > > Nibble-boundary alignment provides a clearer basis for dividing > address space by geography, network layer, service, security domain, site, > or customer group while preserving cleaner aggregates for routing and > long-term internal planning. The proposal does not regulate BGP > announcements, but it improves the address-planning conditions that support > aggregation. > > > > - Reduces repeated incremental expansion > > > > Where a larger requirement has been validated, expansion of the > existing allocation by one or more nibble boundaries, as justified, may > reduce repeated small subsequent requests, administrative overhead, future > fragmentation, and the risk of renumbering. > > > > - Preserves needs-based safeguards > > > > The proposal does not allow nibble-boundary alignment to substitute > for eligibility, utilization, HD-Ratio, or documentation requirements. The > underlying requirement must be validated before alignment is applied. > > > > - Preserves existing policy scope > > > > The proposal does not amend Section 9 assignments, reduce the /32 > minimum allocation size, or alter the default one-bit doubling mechanism. > > > > > > Disadvantages > > > > - Larger address blocks in some cases > > > > Nibble-boundary alignment may result in the delegation of more > address space than the exact non-aligned calculated requirement. For > example, where a calculated requirement is larger than /32 but can be > satisfied by /30, the smallest nibble-boundary aligned block that can > satisfy that requirement is /28. > > > > The additional address space results from alignment to the > applicable nibble boundary. It is not an independent justification for a > larger underlying requirement. > > > > - Resource-management and system impact > > > > APNIC and NIRs may need to update request-evaluation procedures, > registration systems, internal tools, and operational guidance to support > nibble-boundary alignment consistently. > > > > Existing sparse allocation spacing may not always provide sufficient > adjacent address space for the requested expansion. In those cases, a > separate allocation may be required. > > > > - Possible fee impact > > > > Where membership tiers or fees are affected by the total IPv6 > address space delegated to an account holder, nibble-boundary alignment may > result in a higher fee category. > > > > APNIC and the relevant NIR should assess this impact and inform an > applicant of any material fee consequence before the applicant accepts a > nibble-boundary aligned allocation. > > > > - Implementation discretion > > > > The terms "will normally", "the smallest nibble-boundary aligned > block", "one or more nibble boundaries, as justified", and "where > operationally practicable" require implementation judgment. > > > > APNIC may need to publish implementation guidance to promote > consistent evaluation across APNIC and NIR workflows. > > > > > > 6. Impact on APNIC > > ------------------ > > > > Existing resource holders will not be required to renumber, return, or > resize IPv6 allocations delegated before implementation of this proposal. > > > > For initial allocations, the existing eligibility and needs-based > assessment remain unchanged. Where a larger initial allocation has been > validated and the applicant explicitly requests nibble-boundary alignment, > APNIC will normally delegate the smallest nibble-boundary aligned block > that can satisfy the calculated address requirement. > > > > For subsequent allocations, one-bit doubling remains the default where > eligibility is based on acceptable utilization alone. A request for a > larger nibble-boundary aligned allocation must satisfy the existing > documentation and needs-assessment requirements. > > > > After the larger requirement has been validated, where possible, the > subsequent allocation will result in the expansion of the existing > allocation by one or more nibble boundaries, as justified by the validated > requirement. If the existing allocation cannot be expanded, or cannot be > expanded adequately, APNIC may make a separate allocation of the size > justified, on a nibble boundary where operationally practicable. > > > > IPv6 assignments under Section 9 remain outside the scope of this proposal. > > > > Where an allocation request is processed through an NIR, the NIR will > implement this mechanism through its local operational workflow, subject to > the same policy safeguards and applicable APNIC-NIR operational procedures. > > > > APNIC and NIRs may need to update request-evaluation procedures, > registration systems, internal tools, and operational guidance to support > nibble-boundary alignment consistently. APNIC and the relevant NIR should > also assess whether nibble-boundary alignment has any material fee > consequence for an applicant before the applicant accepts the allocation. > > > > > > References > > ---------- > > > > APNIC Internet Number Resource Policies, Sections 3.1.7, 5.1.2, 8.0, 8.1, > 8.2.1, 8.2.2, 8.3.1-8.3.4, and 9: > > https://www.apnic.net/community/policy/resources/ > > > > APNIC Guidelines for IPv6 Allocation and Assignment Requests: > > > https://www.apnic.net/about-apnic/corporate-documents/documents/resource-guidelines/ipv6-guidelines/ > > > > ARIN Number Resource Policy Manual, Sections 6.5.1, 6.5.2.1, 6.5.3, and > 6.5.8.3: > > https://www.arin.net/participate/policy/nrpm/ > > > > RIPE-738, IPv6 Address Allocation and Assignment Policy: > > https://www.ripe.net/publications/docs/ripe-738/ > > > > RIPE Policy Proposal 2024-02, IPv6 Initial Allocations /28 and Extension > to /28, withdrawn 26 February 2026: > > https://www.ripe.net/community/policies/proposals/2024-02/ > > > > RIPE Policy Proposal 2024-01, Revised IPv6 PI Assignment Policy: > > https://www.ripe.net/community/policies/proposals/2024-01/ > > > > APNIC prop-164, Allocations of IPv6 Resources Longer Than a /32 with > Nibble-Boundary Alignment: > > https://www.apnic.net/community/policy/proposals/prop-164/ > > > _______________________________________________ > Go to the SIG-policy-chair mailing list on Orbit -- > https://orbit.apnic.net/mailing-list/[email protected] > Explore https://orbit.apnic.net, where the APNIC community connect, > discuss and share information related to Internet addressing and networking. > To unsubscribe send an email to [email protected] > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected] -- -- Satoru Tsurumaki BBIX, Inc
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
