Hi Erik,
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.
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 )
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
From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Turchanyi Geza
Sent: Friday, August 19, 2011 5:41 AM
To: Andrzej Dopiera³a
Cc: address-policy-wg@ripe.net
Subject: Re: [address-policy-wg] PI for IPv6 == PI for IPv4?
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éza2011/8/18 Andrzej Dopiera³a <undefine@aramin.net>
W dniu 18.08.2011 23:42, Turchanyi Geza pisze:
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!
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
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1392 / Virus Database: 1520/3843 - Release Date: 08/18/11