This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[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 ]