[address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)

Either that or a global policy proposal to use a /4 to automatically
allocate a /32 to every 28-bit AS (maximizing the potential here :) - that
should keep everybody happy and remove the need for the RIRs to be involved
with all but the largest IPv6 requirements. Future generations might ask why
we wasted all this space linking it to AS-numbers but at least it will then
be in a block that can be easily filtered.

Not that I¹d support that proposal, either. We¹ve already wasted quite
enough bits of IPv6 space in policy, IMHO.

Remco


On 15-04-09 11:16, "Florian Weimer" <fweimer at bfk.de> wrote:

> * Piotr Strzyzewski:
> 
>> > We could add those two things together and make that like: /32 for every
>> > AS owned by LIR (in simplification).
> 
> This is more IETF material, IMHO.  There could be a magic /5 which
> contains a /32 for every 27-bit AS number, and a magic /16 with a /48
> for every 32 bit AS number.  RIRs are only needed to handle the
> reverse delegation.
> 
> In any case, to me it looks like multiple requests for /32s are needed
> only to work around route filters.  If this is really the case, those
> filters have to go.
> 
> --
> Florian Weimer                <fweimer at bfk.de>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
> 



This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately.  Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20090415/1d28e8f3/attachment.html>