[address-policy-wg] Re: [ipv6-wg] additional IPv6 allocation (ripe-512 issues)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Leo,

Leo Vegoda wrote:
> Hi Andrea,
> 
> [...]
> 
>>>> According to our experience only LIRs that needed a block much larger
>>>> than /29 found it worth the effort to return their /32.
>>> I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else?
>> There are a number of LIRs who received a /32 in the past who later
>> realise that they might have qualified for a larger initial allocation.
>> We allow these LIRs to return their /32 and then evaluate their request
>> based on the data they submit.
> 
> In the event that the LIR plans to qualify for an allocation that will fit inside the /29 you have reserved for them, do you allow them to receive a block from the same /29? That is, do you allow them to do the "return and new initial allocation" as a book keeping exercise or will they normally need to renumber?

We treat "return and new initial allocation" the same as a normal
initial allocation request. This includes, as with all initial
allocation requests, reserving space for future growth, in the past by
reserving three bits and currently using the binary chop algorithm.

Simply expanding an LIR's current allocation would constitute an
additional allocation and would follow the established additional
allocation policy and procedure and would require the LIR to demonstrate
that they have utilised their current allocation up to the threshold
defined by the HD-ratio.

Should it turn out that an LIR who received a /32 since the
implementation of the binary chop algorithm would have qualified for a
larger allocation, we could consider allocating the "new" larger block
overlapping with their /32. However, most of these "return and new
initial allocation" cases concern relatively old /32 allocations so we
do not expect to have to do this very often, if at all.

Best regards,

Andrea Cima
RIPE NCC


> Thanks,
> 
> Leo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAk4paxoACgkQXOgsmPkFrjP0BQCcDIbhGhqIr6O2UiGhpQ+tUiTs
TRYAn3dWTKCkuPU6T0ORQyVg2L9LRd5L
=z6MP
-----END PGP SIGNATURE-----