prop-164: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment

Assignment-definition amendment withdrawn · Version v002 removes v001's proposed replacement of section 2.1.3, which would have described assigned space as usable in an LIR's own or direct downstream customer's network. Its proposed amendments now begin with section 5.2.3.1. This withdraws that definition edit from the proposal; it does not establish a change to the policy already in force.

Whois duty refers to delegations · The proposed Whois-record duty changes from an LIR making an allocation to an ISP to an LIR making a delegation, with the record described as delegation details. The /36 minimum and IPv4-holder eligibility proposal remain unchanged. The revised terminology alone does not define every delegation category to which the duty would apply.

Directly connected downstream ISP condition · Compared with the retained v002 text, v004 limits the proposed Whois-update clause to a delegation to an ISP with which the LIR is directly connected. The earlier clause did not express that connection condition. This comparison does not establish whether an intervening v003 introduced it.

Return option for an existing larger allocation · Version v004 adds section 8.1.1: an account holder allocated a /32 or shorter prefix could retain the first /36 and return the balance. Version v002 proposed the /36 minimum but did not provide this explicit reduction path for existing larger allocations. The proposed return is optional, not a requirement to surrender addresses.

Smaller /40 minimum and retained block · Version v005 changes the proposed minimum from /36 to /40, a smaller address block. It also changes the proposed IPv6 entitlement for existing IPv4 allocation holders to /40 and lets a holder of a /32 or shorter prefix retain the first /40 when returning the balance. Those passages previously used /36.

Reserved /28 space for future expansion · Version v005 adds a sparse-allocation rule: an allocation longer than /28 would come from a /28, with the remainder reserved for that account holder's future allocations. It would release reservations if APNIC exhausted its IPv6 pool and could not obtain further delegations. The illustrative /32-to-/31 example is expressly context, not proposed operative text; a reservation is not an immediate allocation of the whole /28.

Expansion of existing smaller blocks to /32 · Version v005 adds an amendment to section 8.3.1: holders of /40 through /33 allocations could expand to /32 without additional justification, provided they satisfy section 8.2.2. The expanded block is intended to contain the existing smaller allocation; requests beyond /32 would still be evaluated under other provisions. The retained v004 proposal did not include this amendment.

Explicit nibble-boundary sizing rule · Version v005 supplies an explicit four-bit-boundary rule for all initial and subsequent allocations. Its example rounds a requested /42 to /40 without extra justification. Although the earlier proposal title already mentioned nibble alignment, v004 did not include this operative sizing clause.

Routing-risk and conservation rationale revised · Version v005 replaces the earlier possible routing-table-growth disadvantage with 'None known' and drops the separate advantage about avoiding unnecessarily large delegations. Accurate Whois records remain its stated benefit. These are changes in the authors' stated rationale, not independent proof that additional routing impact is absent.

Choice of /36 or /40 when returning excess space · Version v006 gives holders of /32 or shorter allocations the choice of keeping the first /36 or /40 and returning the balance. Version v005's return clause offered only /40. The proposed minimum allocation remains /40; the /36 option concerns reduction of an existing larger holding.

Fallback when a suitable /28 is unavailable · Version v006 adds a fallback to the /28 reservation scheme: allocate the requested size from the largest contiguous space available, without a future expansion reservation. A later request would be evaluated against the pool then available. If no block can fulfil a request, APNIC would begin releasing reserved space. The earlier exhaustion clause remains; this addition specifies a request-level shortage path.

Alternative /32 when adjacent space is unavailable · Version v006 addresses a reserved expansion area that is no longer fully available. It proposes the nearest available /32 containing the existing allocation, or, if none is available, the nearest available /32. Version v005 described a containing /32 only. The new text permits an alternative block but does not explain renumbering or disposal of the old block, so those consequences cannot be asserted from this passage alone.