I oppose this proposal (can not tell more, than James has told ).

Best regards,

Dmitry V. Menzulskiy (DM3740-RIPE)

address-policy-wg-admin@ripe.net ΞΑΠΙΣΑΞΟ 19.03.2008 18:09:33:

> > If this proposal reaches consensus, the RIPE NCC will conduct a one-time
> > operation to assign a /56 IPv6 PI prefix to all End Users with an IPv4
> > assignment registered in the RIPE Database.
>
> > We encourage you to send your comments to address-policy-wg@ripe.net
> > before 16 April 2008.
>
>
> I strongly oppose on a number of counts:
>
> Not every inetnum holder in the RIPE database justifies a PI IPv4
> assignment, why on earth should they receive a PI IPv6 assignment?
>
> Many entities will have no use for the /56 you're planning on giving them.
>
> Many entities will have no way of announcing the /56 you're planning on
> giving them even if they had a use for it.
>
> Theres lots of entities with multiple inetnum objects, that don't use a
> single person/role object. You'll end up assigning multiple /56s to
> entities when they have no need for them.
>
> The routing tables can't support another 2.25 million prefixes.
>
>
>
>
>
> Now, I would suggest dishing out /48 PI IPv6 space to entities who request
> them, and have genuine plans to announce them (making a one off and a
> yearly charge for this would be nice, for the sake of conserving routing
> table size rather than conserving available address space at this stage).
>
> This shouldn't cause the same amount of growth in the routing tables that
> dishing out /24s of v4 PI space has done since /48 is enough subnets to
> last (hopefully forever), thus a single entity announcing PI from a single
> location should only ever need a /48 (whereas a /56 might be pushing it).
>
> I'd also suggest marking a block of v6 space as never to be allocated for
> the purposes of global routability, but for the sake of internal
> networking for the sake of global uniqness. Theres little point in making
> this a /48 rather than a /56 since aggregation isn't an issue if they're
> not going to be globally routable anyway.
>
> Regards
> James
>