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

Dear Colleagues,

>> When the RIRs and IANA were discussing the /12
>> allocations, the RIRs claimed one of the reasons they needed /12s was
>> because they would all be using the "bisection method" of allocation
>> to remove the need for reservation. It would be sad to hear RIPE
>> still hadn't followed through.
> 
> Again, from my source, since some months or maybe a year, RIPE-NCC allocates IPv6 on "bit-boundry" (or bisection) method, so reservation is not needed anymore. But legacy allocations made us think of /29 :)

For a long time, the RIPE NCC's internal IP address management system would not easily allow us to implement the binary chop algorithm and we made each IPv6 allocation inside a reservation that was three bits larger than the allocation itself, ie. a /32 allocation inside a /29 reservation.

In December 2010 we deployed a new system and since then we have been allocating IPv6 using the binary chop algorithm:

ripencc|DE|ipv6|2a03:4000::|32|20101202|allocated
ripencc|NL|ipv6|2a03:4800::|32|20101215|allocated
ripencc|DE|ipv6|2a03:5000::|32|20101207|allocated
ripencc|RU|ipv6|2a03:5800::|32|20101215|allocated
ripencc|NL|ipv6|2a03:6000::|32|20101202|allocated
ripencc|IT|ipv6|2a03:6800::|32|20101215|allocated

Eventually, the algorithm will begin allocating in the middle of these available blocks, for example 2a03:4400::/32, 2a03:4c00::/32, etc.

Best regards,

Alex Le Heux
RIPE NCC