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

Marco wrote:

[...]

> 
> As Leo already suggested, opening up a new LIR will introduce some  
> burden in the form of costs and overhead which will probably make  
> people think twice about what they are doing and wether or not it is  
> absolutely neccessary. 
> 

  I can assure you that the burden of opening up a new LIR is nothing
  in comparison to maintaining a seperate routing policy up to the client.
  It costs additional money and an expertise and nobody sane will willingly do it.
  So raising up this as an argument that it will stop people from opening
  up a new LIR is probably meaningless.

----
  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.
  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.

  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.

----

[...]

> 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.


[...]

> 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.


Regards,

Jurek