[address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
- Previous message (by thread): [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
- Next message (by thread): [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Fri Apr 17 11:54:55 CEST 2009
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
- Previous message (by thread): [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
- Next message (by thread): [address-policy-wg] 2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]