Hi Erik, <div class="gmail_quote">2011/8/19 Erik Bais <<a href="mailto:ebais@a2b-internet.com">ebais@a2b-internet.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div link="blue" vlink="purple" lang="EN-US"><div>Hi Andrzej & Turchanyi, That is a difference in that respect between IPv4 and IPv6. End-customers that request IPv4 PI might find themselves after a while in a situation where the initial request allocation isn’t big enough and they can and will request another prefix. </div></div></blockquote><div> It would have been better and still would be better even in that case to use only one prefix and return the original one to the RIR. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div link="blue" vlink="purple" lang="EN-US"><div> For IPv6 that isn’t likely and I’ve heard that some people are a bit concerned about this. One of the things we might want to put into the IPv6 PI limitations is that an end-customer can only request a single IPv6 PI Prefix and to a maximum of a certain size. ( say a /34 ) </div></div></blockquote><div> The example (/34) given is very fare from that I would support. If an end user needmore than a /48 the and user should provide very detailed plan of its network. (For a home network /60 tipically more than enough). Any organization that might need a /40 (or more) AND PI address space, should become a LIR and contribute in the normal way to the internet address administration costs, I think. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div link="blue" vlink="purple" lang="EN-US"><div>Anything beyond that should be considered LIR sized and the end-customer should become a LIR and turn in their PI prefix. Regards,Erik Bais <div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"> From: <a href="mailto:address-policy-wg-admin@ripe.net" target="_blank">address-policy-wg-admin@ripe.net</a> [mailto:<a href="mailto:address-policy-wg-admin@ripe.net" target="_blank">address-policy-wg-admin@ripe.net</a>] On Behalf Of Turchanyi Geza Sent: Friday, August 19, 2011 5:41 AM To: Andrzej Dopiera�a Cc: <a href="mailto:address-policy-wg@ripe.net" target="_blank">address-policy-wg@ripe.net</a> Subject: Re: [address-policy-wg] PI for IPv6 == PI for IPv4? </div></div><div><div></div><div class="h5"> Hello Andrzej, Good point. You said that some ISPs are using IPv4 PI address space just because they asked it in their very small ISP status, as being pre-LIR. It would have been much better to change back these addresses to PA already long time. Is there anybody who can suggest a cleaning policy? Of course, vleaning is very difficult whan almost all IPv4 address space have gone... ;-(( Anyhow, the danger og creating too many routing table entries by allocating Provider Independent (IPv6) addresses is still exist and should not be overlooked. Best, G�za <div> 2011/8/18 Andrzej Dopiera�a <<a href="mailto:undefine@aramin.net" target="_blank">undefine@aramin.net</a>>W dniu 18.08.2011 23:42, Turchanyi Geza pisze:<div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> Second point: if ALL IPv4 PI holder would request IPv6 PI then you might expect another 17K prefixes in the routing table just from the RIPE Region! And this is just the start! </blockquote></div>Most ipv4 PI holders have more than one prefix - when first was not enought - they get another. Few ISP in poland get 3-4 prefixes when they weren't LIR. For ipv6 one prefix is always enought - so 17k is much to much :) Regards, Andrzej </div> </div></div><div class="MsoNormal" style="text-align:center" align="center"> <hr style="color:#A0A0A0" align="center" noshade size="1" width="100%"></div>No virus found in this message. Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a> Version: 10.0.1392 / Virus Database: 1520/3843 - Release Date: 08/18/11 </div></div></div></blockquote></div>