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

Hallo Jan,
du schrobst:

> On 7/19/11 9:38 AM, Jasper Jans wrote:
> >The RIPE currently reserves a /29 for every initial /32.
> >So as long as there is a policy that allows expansion of the initial
> >assignment based upon a sound network design there should not be
> >any issue to bump it up to a bigger block.
> Hi,
> 
> As presented, discussed and suggested at RIPE62 in Amsterdam, we are
> currently working on policy change proposal, that would rise the
> minimum IPv6 allocation size to /29 and automatically made of use
> that "reserved" /29 space for each legacy /32 allocation (that would
> almost never be used otherwise).
> 
> Primary reason for that proposal was wasteful transition mechanisms
> (like 6RD...), but this change also solves some of issues, rised in
> this thread.

For me that sounds like this is curing symptoms snstead of the real
cause. I would suggest to add a clause that a) NCC can hand out new
allocations if the addressing plan for the new addresses is sound and 
b) that simplifying administrational causes  should also be an valid
reason for address need (such as wastful transition mechanisms like 6rd
or assigning /36 per pop eventhough not all pops have more then 2048 /48 to 
be assigned but for the sake of a clear network design). 

We do have enough addresses and we will not get short on them any time if we 
don't to something incredibly stupid So lets not create artifical obstacles.
IPv6 is designed to allow that. Don't give that benefit away by some 
IPv4-we-don't-have-enough-addresses-and-must-save-addresses-at-all-costs
habbits. In IPv6 thats just not necessary anymore, there are enough 
addresses and making things complicated in order to save addresses is 
just not reasonable!

regards,

Immo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20110720/e6c85797/attachment.sig>