Dear Christopher,
Thank you very much for your detailed review and constructive comments on
prop-170. We appreciate your careful consideration of the proposal,
particularly regarding the relationship between existing needs-based
assessment, nibble-boundary alignment, larger subsequent allocations, and the
interaction with prop-164.
We would like to clarify several aspects of the proposal as follows.
1. Relationship with existing needs-based justification requirements
We respectfully disagree that existing justification requirements make prop-170
redundant.
We fully acknowledge that current APNIC policy already requires account holders
to provide appropriate justification for all initial and subsequent IPv6
allocation requests. Prop-170 does not replace, bypass, or weaken any existing
needs-based assessment, HD-Ratio requirements, utilization requirements, or
documentation requirements.
However, needs-based assessment and allocation boundary selection address
different aspects of IPv6 resource management.
Existing policy determines whether an applicant has a justified requirement for
additional address space and the amount of address space supported by that
requirement.
Prop-170 addresses a different question: after a requirement has been
validated, how the resulting allocation boundary can better support long-term
IPv6 operational planning.
In this sense, prop-170 aims to provide an explicit policy mechanism between
validated address requirements and operationally meaningful IPv6 allocation
boundaries
2. Nibble-boundary alignment is not an additional address entitlement
We understand the concern that operators should not be required to request
address space beyond their actual requirements.
This is also not the intention of prop-170.
The proposal does not allow an applicant to obtain additional address space
merely because a nibble-boundary prefix is preferred. The underlying address
requirement must still be justified and validated according to the existing
APNIC policy framework.
Nibble-boundary alignment is only considered when:
the applicant explicitly requests such alignment;
the applicant provides supporting long-term IPv6 address planning information;
and
the requested aligned allocation is considered within the context of the
validated requirement and the applicant’s long-term planning objectives.
The purpose of the proposal is not to encourage unnecessary address
consumption. Rather, it recognizes that IPv6 address planning often involves
long-term hierarchical organization, routing aggregation, automation, security
segmentation, and overall operational management considerations in addition to
immediate address utilization.
For operators that place importance on long-term IPv6 deployment planning,
prop-170 provides a standardized and policy-supported path for considering
operationally meaningful allocation boundaries.
For example, an applicant may have a validated immediate requirement
corresponding to a /31 prefix but request a larger nibble-boundary aligned
allocation for long-term hierarchical planning purposes. Such a request would
not be approved solely because of alignment preference. The applicant would
need to provide supporting information demonstrating how the requested aligned
allocation supports the documented long-term IPv6 address plan.
The alignment mechanism therefore does not create an independent entitlement to
additional address space. Any larger allocation boundary is considered within
the context of the validated requirement and the applicant’s documented
long-term IPv6 planning objectives.
3. Clarification regarding allocations larger than one-bit doubling
Thank you for raising the example of a request from /31 to /29.
We would like to clarify that prop-170 does not introduce a requirement that
all allocations larger than one-bit doubling must be nibble-boundary aligned.
The one-bit doubling mechanism remains the default mechanism for subsequent
allocations.
Where an account holder requests a larger allocation than the default doubling
but does not request nibble-boundary alignment, the request will continue to be
processed under the existing policy framework.
For example, an account holder requesting an expansion from /31 to /29 without
requesting nibble-boundary alignment would continue to be evaluated according
to the existing rules.
If the same applicant requests nibble-boundary alignment, the request would be
considered under prop-170. Where applicable, supporting long-term IPv6 address
planning information would be considered as part of the alignment request, in
addition to satisfying all existing needs-based assessment requirements.
Therefore, prop-170 does not create a mandatory alignment requirement for
larger allocations. It only provides an optional mechanism for applicants that
choose to request such alignment.
4. Interaction with prop-164
We appreciate the question regarding the possible interaction between prop-170
and prop-164.
Prop-170 is not dependent on the current /32 minimum allocation size. The
proposal applies to IPv6 allocations under Section 8 and introduces an optional
nibble-boundary alignment mechanism after the applicant’s address requirement
has been assessed.
Therefore, if prop-164 reaches community consensus and changes the minimum IPv6
allocation size, prop-170 can continue to operate within the revised Section 8
framework.
The two proposals address different aspects of IPv6 resource policy:
prop-164 addresses the minimum allocation granularity;
prop-170 addresses an optional allocation-boundary alignment mechanism for
validated requirements.
They are therefore compatible and can coexist independently.
Notably, the revised prop-164 also follows the same nibble-boundary definition
used in prop-170. Both /32 and /36 are prefix lengths divisible by four and
therefore follow the same 4-bit alignment principle. The two proposals use
consistent technical logic regarding IPv6 allocation boundaries.
For both initial allocation and subsequent allocation scenarios, the same
fundamental conditions apply: nibble-boundary alignment is optional, must be
explicitly requested by the applicant, and can only be considered after the
underlying address requirement has been validated. The alignment mechanism does
not change existing eligibility, utilization, or documentation requirements.
We support maintaining consistent terminology between prop-164 and prop-170,
particularly regarding the definition of nibble boundary and 4-bit alignment.
5. Policy impact and compatibility
Thank you for pointing out the wording issue regarding “Preserves existing
policy scope” in the Advantages section.
We would like to clarify that the intended meaning of this statement is not
that simply leaving other policy sections unchanged should itself be considered
an advantage.
Rather, the intention is to emphasize that prop-170 introduces a limited and
optional nibble-boundary alignment mechanism under Section 8 while maintaining
compatibility with the existing IPv6 allocation framework.
In particular, prop-170 does not modify IPv6 assignment policy under Section 9,
does not change existing needs-based assessment requirements, does not alter
HD-Ratio requirements or the default one-bit doubling mechanism, and does not
require existing resource holders to renumber or modify their existing
allocations.
We consider this limited and targeted scope to be an important characteristic
of the proposal. It provides an optional mechanism to support long-term IPv6
planning objectives where nibble-boundary alignment is operationally
beneficial, while allowing other operators to continue using the existing
allocation process without additional requirements.
6. Regarding policy complexity
We understand the concern that a new mechanism may introduce additional
considerations for policy implementation.
However, prop-170 does not introduce a mandatory new process for normal IPv6
allocation requests.
For account holders that do not request nibble-boundary alignment:
the existing allocation process remains unchanged;
no additional documentation is required;
no additional assessment criteria are introduced.
Only applicants that voluntarily request nibble-boundary alignment would
provide supporting long-term IPv6 address planning information. All existing
eligibility, utilization, and needs-based assessment requirements remain
unchanged.
The intention of prop-170 is not to increase complexity, but to provide a clear
and transparent policy mechanism for cases where operators have long-term IPv6
address planning objectives.
By defining the scope, conditions, and limitations of nibble-boundary
alignment, prop-170 aims to improve policy clarity while preserving the
flexibility of the existing IPv6 allocation framework.
Closing
Thank you again for your thoughtful review and for raising these important
questions. Your comments have helped us further clarify the scope, optional
nature, and interaction model of prop-170.
We believe these clarifications help distinguish between the existing
needs-based assessment framework and the optional allocation-boundary planning
mechanism introduced by prop-170.
We welcome further discussion with you and the APNIC community during the
Policy SIG process.
Best regards,
Haisheng Yu
---- Replied Message ----
FromChristopher Hawker<[email protected]>Date7/25/2026
19:00To<[email protected]>Subject[sig-policy] Re: prop-170:
Nibble-Boundary Alignment for IPv6 Allocations
Hello,
As a co-author of prop-164 that is still open for discussion (with a revised
version to be submitted shortly), this proposal modifies sections that are
already being reviewed for potential changes. I invite the authors to review
the proposed changes in prop-164 (and the overlapping sections), and reach out
to me directly to discuss this further.
Now, having said that, there are several concerns that I have with this
proposal:
Policy currently does not require account holders to request allocations that
align with a nibble boundary. I believe that this is a good thing, as it means
that network operators do not need to request resources that they would not
otherwise not need.
Account holders already need to provide justification for any sized initial or
subsequent allocation. This alone (in my opinion) makes this proposal redundant.
It's acknowledged that one-bit doubling will remain the default method, and
that if someone wants more than doubling and requests an allocation that aligns
with a boundary, they must justify the request. What do the authors propose
should happen if an account holder requests an allocation that is more than
double, but does not align with a boundary (e.g. going from a /31 to a /29)? Is
it the intent that if an account holder requests more than double, it must
align with a boundary?
Not modifying a section of a policy, does not count as an advantage to a
proposal (see "Preserves existing policy scope" under Advantages/Disadvantages).
Further, prop-164 proposes reducing the minimum allocation size from a /32 to a
/36. Should prop-164 reach consensus and be implemented into policy, is it the
author's position that prop-170 would also apply to account holders who hold an
allocation between a /36 and /32?
In my view, this proposal adds a layer of complexity to allocations that is not
necessary. As it is currently written, I oppose this proposal as there are a
number of considerations not accounted for leaving room for interpretation as
well as adding unnecessary complexity. It already stands in current policy that
regardless of the request size the account holder must already provide
justification.
Regards,
Christopher Hawker
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]
