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

On 17 apr 2009, at 11:42, Jerzy Pawlus wrote:
> ----
>  I only state that the current RIPE policy will not stand. Either the
>  5.1.1 shall be removed or  5.2.1 modified.
>  The policy, in my opinion, is and was in the past more restrictive
>  than equivalent IPv4 policy. Lets just recall 200 clients rule or  
> lack
>  of IPv6 PI space.

I find it less restrictive, administrative ease is allowed and you'll  
always get a /32.

>  In its current form it is harmful to IPv6 deployment. So far we  
> have seen
>  only two groups interested in changing it, but the others will follow
>  when they try to bring IPv6 into production.

Please stop this nonsense, you find a ton of reasons why IPv6 isn't  
deployed and I don't see proof that changing the policy actually  
caused an increase in IPv6 addoption. Surely somebody probably got  
himself a /32, which by now is gathering dust somewhere being bound to  
null0.

>  In it simplest: Under current policy some LIRs cannot offer the  
> same set
>  of services they used to offer in IPv4, and IPv6 was supposed to  
> offer
>  new oportunities.
>

Yes agian, we here you....it's not the problem that is bothering me,  
it's the proposed solution.

>> The other big objections I read are concerning the
>> filters. Routabillity of address blocks (any address block) is as
>> always not guarenteed and routing policy for individual networks is
>> way out of scope for this WG or the RIPE NCC as a whole. Maybe you
>> should follow up to the IETF and draft a BCP on IPv6 route filtering,
>> otherwise I guess the market will eventually solve it, if it turns  
>> out
>> to really be a problem, and alter the filters.
>
>  But we also cannot create a policy for policy itself. It must respect
>  a real life scenario too.
>  Of course "Routabillity of address blocks (any address block) is as  
> always
>  not guarenteed" but as practise shows most "legally" obtained  
> legacy prefixes
>  are still routable and special rules for some IPv4 ranges are  
> generally
>  accepted. I am afraid you can't say the same for a more specific
>  /32 PA prefix.

I have had to lower my filters in the past a few times after  
complaints from customers and I guess I'm not the only one, at the  
same time I have had boxes which not even accepted /24 as a general  
rule because of memory shortage.

That's what I meant by 'let the market do it's work'.

>
> [...]
>
>> To me a large part of what you are saying, in v4 land can would be  
>> put
>> under 'administrative ease' which by RIPE-449 is not a valid reason
>> for assignment and I personally don't see reasons to allow it for  
>> IPv6
>> even when it's not explicitly stated in the policy document.
>>
>
>
>  It is not 'administrative ease'. It is be or not to be.


We'll I've been running networks in the same situation, one company  
with 2 policies and 2 ASns which from time to time didn't touch  
eachother and I'm still here :)

Groet,

MarcoH