Hi Chris, Satoru, Koki, and all,
I'd like to preface my comments by saying I don't come from a technical
networking background. My interest in this proposal comes from the WHOIS
accuracy angle, which is a topic I follow closely in other policy contexts.
I don't have a confirmed position on prop-164-v005 at this stage. In general,
I'm supportive of efforts to improve WHOIS/RDAP accuracy - it's a goal I think
most of the community can get behind. That said, there are a few items I'd like
to clarify, and some background research I've done that I think may be useful
to the wider discussion.
1. Scope - IPv4 vs IPv6
Looking through the proposal text, every section it touches (8.1, 8.1.1, 8.2.1,
8.2.3, 8.3.1, 8.4) sits under Part 3: IPv6 Policy of APNIC-127. IPv4 only
appears as an eligibility signal in 8.2.1 (i.e. "an account holder that already
has an IPv4 allocation is eligible for..."), not as something the policy itself
changes. Given how the problem statement is worded, it might not be obvious to
everyone reading it that IPv4 allocation, sub-allocation, and Whois
requirements are entirely out of scope here. It may be worth the authors adding
an explicit line stating that this proposal does not affect IPv4 policy, just
to remove any ambiguity for readers less familiar with the document structure.
2. "Assignment" vs "allocation" in the problem statement
The problem statement opens with: "if an account holder receives an assignment
longer than a /32 (e.g. a /40), they cannot make sub-assignments to their
customers..."
Based on APNIC's own Whois status-field documentation
(https://www.apnic.net/manage-ip/using-whois/updating-whois/network-assignments/),
"assigned" status objects are explicitly the ones that cannot have further
delegations registered under them - that's the defining feature of an
assignment versus an allocation. If that's correct, then a resource holder who
has received an "assignment" would, by definition, never be able to make
further sub-assignments to customers, regardless of its size. I'd suggest the
proposal consistently use "allocation" here instead, since that's the category
that actually carries re-delegation rights and is what the proposal is trying
to make available at smaller sizes. This may also be what the Secretariat was
pointing at in the v002 impact assessment (prop-164-v002-IA.txt), which asked
the authors to "consider consistency of language (i.e.:
allocation/assignment/delegation)" - happy to be corrected if I've misread the
intent there. It may worth noting that ARIN has retired the term "Assignment"
altogether, which might be a relevant context as the community reference ARIN
policy in our deliberation.
3. ARIN reference - relevant section for discussion
Since the proposal cites ARIN as precedent ("ARIN already allows for /36 and
/40 prefix delegations under section 6.5.2.1"), I looked up the exact text for
reference. Pasting the relevant part of NRPM 6.5.2.1 here for the list's
convenience (source:
https://www.arin.net/participate/policy/nrpm/#6-5-2-1-size):
> 2. In no case shall an LIR receive smaller than a /32 unless they
> specifically request a /36 or /40.
> In order to be eligible for a /40, an ISP must meet the following
> requirements:
> - Hold IPv4 direct allocations totaling a /24 or less (to include zero)
> - Hold IPv4 reassignments/reallocations totaling a /22 or less (to include
> zero)
> In no case shall an ISP receive more than a /16 initial allocation.
>
> 7. An LIR that requests a smaller /36 or /40 allocation is entitled to expand
> the allocation to any nibble aligned size up to /32 at any time without
> renumbering or additional justification. /40 allocations shall be
> automatically upgraded to /36 if at any time said LIR's IPv4 direct
> allocations exceed a /24. [...] Partial returns of any IPv6 allocation that
> results in less than a /36 of holding are not permitted regardless of the
> ISP's current or former IPv4 address holdings.
Two things worth flagging from this text: the /40 option at ARIN is gated on
specific IPv4 holdings thresholds, not available on request to any ISP; and
ARIN's actual floor for held space is /36 - it does not permit anyone to end up
holding less than /36 long-term, even though /40 can be an initial allocation
size in qualifying cases.
4. ARIN's PDP record - stated intention
For background on why ARIN introduced this, the policy development record is
public here:
https://www.arin.net/vault/participate/policy/drafts/2020/2020_3/
This was ARIN-2020-3, "IPv6 Nano-allocations," adopted 16 December 2020. The
stated intention, in the proposal's problem statement, was to address a
fee-schedule disincentive - specifically, that the smallest ISPs (holding a /24
or less of IPv4) would see their annual ARIN fees double if forced into a /36
IPv6 allocation, and that a meaningful number of them were abandoning IPv6
requests entirely once informed of the fee impact. It doesn't appear that
WHOIS/RDAP registration accuracy was part of ARIN's original rationale. I raise
this only because it may be useful context for the community in weighing how
directly the ARIN precedent applies to the problem this proposal is trying to
solve. WHOIS/RDAP issue not being part of ARIN-2020-3, does not mean APNIC
cannot make allocation size change based on WHOIS accuracy issue.
Hope these infomation would be useful for the discussion.
Regards,
Alban Kwan_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]
