getting second IPv6 PA as a LIR
hello, Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ? The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers. However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes. For SponsorLIR agreement customers - little ISPs, willing to advertise their i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA (not advertised as whole by LIRs ASes) would be great... Regards, Marcin
Marcin, On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera <marcin@leon.pl> wrote:
hello,
Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ?
See below.
The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers.
However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes.
I doubt this is correct. You mentioned that you had not filled the /32. In other words, there should be /48s left over unallocated internally. These /48s can be (sub-)allocated to customers (please forgive my flawed internet-numbers-delegation-vocabulary), who are free to announce them over BGP sessions. It is then up to your customers to find transit providers willing to accept these announcements, which may be helped by them having route6 objects registered. If they have trouble with connectivity due to AS:es filtering out these long prefixes from IPv6 PA regions, they will have to get their own PA by becoming a LIR member themselves.
For SponsorLIR agreement customers - little ISPs, willing to advertise their i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA (not advertised as whole by LIRs ASes) would be great...
The yet-to-be properly challenged (legacy?) consensus/opinion of this WG is that ISPs must pay to play IPv6. I.e., you must become LIR to be allowed to announce routes into the DFZ. IPv6 PI (PIv6) is nearly useless, by design: Only customer-less end-users can use PIv6 space today without stepping into a grey zone in the policy documents. I.e., these end-users can't have customers. So, essentially, PIv6 is usable by either normal private persons, or businesses who do not use their PIv6 space for any business purposes (none, I think). Presumably, the more ISPs that sign up for this Internet tax (the LIR membership fees), the lower it will become (#LIRs is most definitely sub-linearly proportional to the RIPE NCC:s operational costs). It is fairly obvious to me that this attempt to (at least partially) solve a *perceived* network model problem with taxes is not long-term stable in itself.* If you think what I've described above sounds strange, read up on the AP-WG list archives. This and related topics have been discussed in the following threads at considerable lengths this year alone: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00205.... http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00164.... http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00069.... http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00039.... Personally I'd much prefer if the policies were aligned with reality better, since it would allow us to get rid of the more or less arbitrary policy-interpreting role the IPRA:s at the RIPE NCC has for v6 resources today. This would make the landscape much more honest and just. After all, it's just bits anyway. Regards, Martin * This is *the* major source for all this head ache. There is a considerable fear among many AP-WG participants that making IPv6 PI easier to get will (1) lead to an uncontrolled explosion of IPv6 prefixes in the DFZ (2), which hardware will fail to handle (3) and the IPv6(**) internet will break down (4). As you can see, (1, 2, 3, 4) are several issues that all deserve to be further researched IMO. ** And possibly IPv4 too, if both networks are physically over-layered on the same network gear. Continued expansion of prefixes is going to occur both in IPv4 and in IPv6 until there are no more "buyers". The biggest difference between these prefixes coming from unallocated space (IPv6) or from existing allocated space seeing its "usage-density" increased (IPv4) is that IPv6 is cheaper. At some point, it is going to be cheaper to become a IPv6 LIR than get even a small IPv4 block, and the problem remains just as unsolved then as it is now.
Hi, On Tue, Apr 26, 2011 at 11:10:15PM -0400, Martin Millnert wrote:
Personally I'd much prefer if the policies were aligned with reality better, since it would allow us to get rid of the more or less arbitrary policy-interpreting role the IPRA:s at the RIPE NCC has for v6 resources today. This would make the landscape much more honest and just. After all, it's just bits anyway.
It's on our agenda for next week's APWG meeting, in the Thursday 11:00-12:30 time slot. (And towards Marcin: if these policies stop you from assigning /128 to end customers, that was partly the intention. Customers are supposed to receive at least a /64, or better a /56 or /48 - which is why LIRs can get a huge block of addresses quite easily. Don't return into IPv4 "single-address-plus-NAT" land!) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Wed, Apr 27, 2011 at 08:36, Gert Doering <gert@space.net> wrote:
(And towards Marcin: if these policies stop you from assigning /128 to end customers, that was partly the intention. Customers are supposed to receive at least a /64, or better a /56 or /48 - which is why LIRs can get a huge block of addresses quite easily. Don't return into IPv4 "single-address-plus-NAT" land!)
This point can not be emphasized enough... _Please_ do no assign longer than a /64 to any customer, for any reason. And yes, I am talking about transfer prefixes, as well. Richard
(And towards Marcin: if these policies stop you from assigning /128 to end customers, that was partly the intention. Customers are supposed to receive at least a /64, or better a /56 or /48 - which is why LIRs can get a huge block of addresses quite easily. Don't return into IPv4 "single-address-plus-NAT" land!)
Well, we have never had used NAT, that's not good when you want to be serious ISP. /128 is just an example. Probably the simplest way will be subnet /64 or smaller, where part of IP will be MAC address of enduser. Marcin
Hi, On Sun, May 01, 2011 at 11:03:34PM +0200, Marcin Kuczera wrote:
(And towards Marcin: if these policies stop you from assigning /128 to end customers, that was partly the intention. Customers are supposed to receive at least a /64, or better a /56 or /48 - which is why LIRs can get a huge block of addresses quite easily. Don't return into IPv4 "single-address-plus-NAT" land!)
Well, we have never had used NAT, that's not good when you want to be serious ISP. /128 is just an example.
If you give your customers a single /128, you're forcing *them* to use NAT. This is bad.
Probably the simplest way will be subnet /64 or smaller, where part of IP will be MAC address of enduser.
The strong recommendation is to give your customers something between a /48 and a /64. NO LESS, unless you know for sure(!) that they only have a single machine, and no network behind it. IPv6 is not IPv4, and we have enough addresses. Let's make good use out of it. (And the math has been done: giving a /56 to every single end customers out in the world will use up well below 0.0001% of the global address space) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
unless you know for sure(!)
I know for sure, for instance, under our policy, if you are purchasing web hosting and want a real SSL/TLS endpoint (i.e you can't use the shared one via SNI), we'll give you a /128 to bind the cert to. </pedantry> Dave.
Hi, On Mon, May 02, 2011 at 02:48:42PM +0000, David Freedman wrote:
unless you know for sure(!)
I know for sure, for instance, under our policy, if you are purchasing web hosting and want a real SSL/TLS endpoint (i.e you can't use the shared one via SNI), we'll give you a /128 to bind the cert to.
</pedantry>
I think that this pretty well matches the criteria of "knowing for sure", no? :-) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
You wrote:
If you give your customers a single /128, you're forcing *them* to use NAT. This is bad.
And they wouldn't be able to use stateless auto-configuration or RFC 3041 privacy extensions.
Probably the simplest way will be subnet /64 or smaller, where part of IP will be MAC address of enduser.
The strong recommendation is to give your customers something between a /48 and a /64. NO LESS, unless you know for sure(!) that they only have a single machine, and no network behind it.
Even if they only have one machine there are advantages to assigning at least a /64. Regards, Leo
Hi, On Mon, May 02, 2011 at 07:55:15AM -0700, Leo Vegoda wrote:
Even if they only have one machine there are advantages to assigning at least a /64.
Indeed. Thanks for reminding me (and all of us :-) ). Gert Doering -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hello Leo Vegoda wrote:
Probably the simplest way will be subnet /64 or smaller, where part of IP will be MAC address of enduser.
The strong recommendation is to give your customers something between a /48 and a /64. NO LESS, unless you know for sure(!) that they only have a single machine, and no network behind it.
Even if they only have one machine there are advantages to assigning at least a /64.
Actually about 50% of all IPv4 address space was allocated from 1990 till 1995 (five years). Yes, IPv6 provide much more address space but if this address space will be wastefully allocated as IPv4, history will repeat itself Community should be more farseeing to avoid similar situation in future (and if we hope that any toothbrush will pretend for its own IPv6 address - near future) So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion -- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
Hi Andrey, You wrote:
So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion
Can you describe your concerns in numbers? Thanks, Leo
On Mon, 2 May 2011, Andrey Semenchuk wrote:
So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion
If 10 billion people on earth has 10 devices with a /48 for each device, you will have spent approximately one 1/2800th of the IPv6 address space. There are 281 thousand billion /48s. Let's use this current allocation policy until the first /3 is used up, then we have 7 more tries to "get it right" if we decide we need to change something. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 2 May 2011, at 21:45, Andrey Semenchuk wrote:
Yes, IPv6 provide much more address space but if this address space will be wastefully allocated as IPv4, history will repeat itself
This is just a statement of the bleedin' obvious Andrey. However you don't seem to have any data that shows how current IPv6 allocation policies could repeat those earlier mistakes.
So, the strong recommendation to give customers between a /48 and a / 64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion
If the Internet doles out a billion /64s every day -- several orders of magnitude more than any forseeable assignment rate -- it will take 50 million years to deplete the IPv6 address space. I'm happy to leave that problem to the next generation. :-)
* Jim Reid:
If the Internet doles out a billion /64s every day -- several orders of magnitude more than any forseeable assignment rate -- it will take 50 million years to deplete the IPv6 address space. I'm happy to leave that problem to the next generation. :-)
There have been suggestions to use multiple /24s for each ISP using certain IPv6 deployment strategies. Exhaustion isn't so remote anymore if such efforts become widespread. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Hi, I support the concerns of Florian. We need addresses for addressing AND ROUTING. In the original design a few bits had been reserved for routing purposes in the IPv6 address scheme just to facilitate routing in the future. These bits completely disappeared -- which is not a a problem in the first phase of the transition, where we are now; however the missing functinality will case problems as the Internet will further grow. Jim, probably you are better expert in this field than me - what do you foresee about scaling of routing and the possibilities of chosing between different backbone service providers in the future? Best, Géza On Tue, May 3, 2011 at 10:10 AM, Florian Weimer <fweimer@bfk.de> wrote:
* Jim Reid:
If the Internet doles out a billion /64s every day -- several orders of magnitude more than any forseeable assignment rate -- it will take 50 million years to deplete the IPv6 address space. I'm happy to leave that problem to the next generation. :-)
There have been suggestions to use multiple /24s for each ISP using certain IPv6 deployment strategies. Exhaustion isn't so remote anymore if such efforts become widespread.
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 3 May 2011, at 09:26, Turchanyi Geza wrote:
Jim, probably you are better expert in this field than me
I very much doubt that.
- what do you foresee about scaling of routing and the possibilities of chosing between different backbone service providers in the future?
If I knew the answers to your question, I would have a much more lucrative career as a commodities trader or buying lottery tickets. :-) One thing that does worry me is the use of very long prefixes for v6 "to save address space" which then causes the size of DFZ to explode.
One thing that does worry me is the use of very long prefixes for v6 "to save address space" which then causes the size of DFZ to explode.
??? If an ISP receive max 2 IPv6 blocks, this is just two entries in the (current BGP) routing table. The use of long prefixes in the costumer's network means more costumers served from the same block. Is there a point where we disagree? Géza
On 3 May 2011, at 09:48, Turchanyi Geza wrote:
If an ISP receive max 2 IPv6 blocks, this is just two entries in the (current BGP) routing table.
The use of long prefixes in the costumer's network means more costumers served from the same block.
Is there a point where we disagree?
Not with the above. However the initial context of this discussion was about issing PI space to end customers. [For some definition of PI space and end customer.] So if one of those customers was to get one of these long prefixes, they might want to keep it if they switch providers => an extra route for a mickey-mouse amount of space. We know from v4 that this is a Bad Thing.
On Tue, May 3, 2011 at 11:12 AM, Jim Reid <jim@rfc1035.com> wrote:
On 3 May 2011, at 09:48, Turchanyi Geza wrote:
If an ISP receive max 2 IPv6 blocks, this is just two entries in the
(current BGP) routing table.
The use of long prefixes in the costumer's network means more costumers served from the same block.
Is there a point where we disagree?
Not with the above. However the initial context of this discussion was about issing PI space to end customers. [For some definition of PI space and end customer.] So if one of those customers was to get one of these long prefixes, they might want to keep it if they switch providers => an extra route for a mickey-mouse amount of space. We know from v4 that this is a Bad Thing.
Fully agree. The IPv6 PI space concept is Bad Thing, because creates routing table fragmantation. Short prefix or long prefix - it does not matter. Routing table fragmentation do matter. G
Hay, Am 02.05.2011 um 22:45 schrieb Andrey Semenchuk: [...]
So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion
That's not the case. PLEASE use your favorite search engine to find the last thousand discussions about this and do the math yourself. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hi, On Mon, May 02, 2011 at 11:45:36PM +0300, Andrey Semenchuk wrote:
So, the strong recommendation to give customers between a /48 and a /64 (and /64 even for a single machine) - is the right way to lay the foundation of a new address space exhaustion
Please do some basic math. Number of /56s in FP001, number of people the earth can sustain. How many /56s per person. Add to that that we're only assigning from FP001, so even if it turns out that the world can sustain 1000x more humans than everybody thinks possible today, we have 6 more FPs to try again. Right now, we should try to get rid of conservationist IPv4 thinking, and *do the math* that clearly shows that with IPv6, you can affort that. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Tue, May 03, 2011 at 11:57:06AM +0200, Gert Doering wrote:
Right now, we should try to get rid of conservationist IPv4 thinking,
You mean like /56 and (much worse) HD-ratio 0.94? :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, On Tue, May 03, 2011 at 08:08:50PM +0200, Daniel Roesen wrote:
On Tue, May 03, 2011 at 11:57:06AM +0200, Gert Doering wrote:
Right now, we should try to get rid of conservationist IPv4 thinking,
You mean like /56 and (much worse) HD-ratio 0.94? :)
Well, I remain to convinced that a typical end-user household can find uses for more than a 100 different *networks* - but then, it's by no means mandatory to assign /56s, as the policy explicitely allows assignments of /48 (which we discussed last year in Rome to make it very clear how that is currently counted regarding usage ratio). I can't actually say for which classes of networks a HD-Ratio of 0.94 will work, and for which classes it might fail. It does give the ISP quite some slack (for example, a /32 is considered "full" if an efficiency of 37% is reached - as opposed to the 80% in IPv4 today [RIPE-512, Appendix A]). If that is not sufficient or does not really "fit" real-world networks, maybe we need a different HD-Ratio, or a different "fullnesss" metric altogether - your suggestions are welcome. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Tue, May 03, 2011 at 10:31:08PM +0200, Gert Doering wrote:
Well, I remain to convinced that a typical end-user household can find uses for more than a 100 different *networks* - but then, it's by no means mandatory to assign /56s, as the policy explicitely allows assignments of /48 (which we discussed last year in Rome to make it very clear how that is currently counted regarding usage ratio).
Right, but that doesn't help, as your allocation size is still being judged by looking at /56s (that a /48 assignment is counted as 256 assigned /56 doesn't help at all). Think of prefix delegation pool sizing when you have a lot of aggregation points.
I can't actually say for which classes of networks a HD-Ratio of 0.94 will work, and for which classes it might fail. It does give the ISP quite some slack (for example, a /32 is considered "full" if an efficiency of 37% is reached - as opposed to the 80% in IPv4 today [RIPE-512, Appendix A]). If that is not sufficient or does not really "fit" real-world networks, maybe we need a different HD-Ratio, or a different "fullnesss" metric altogether - your suggestions are welcome.
The point is, that HD ratio 0.8 allowed MUCH cleaner, nicer addressing schemes with semantic/geographic/technical hierarchy encoded on nibble boundaries than HD ratio 0.94. With the latter, far less encoding with "one size fits all" approach on a certain level is possible, otherwise we'd be screwed later. When you go off-nibble, things become cumbersome for anyone reading, planning, delegating (revDNS), routing - basically DEALING - with IPv6 addressing. This may be viewed as "less luxury", but also as added operational cost. Anyway, all off-topic in this thread. I just wanted to point out that people already started to apply "IPv4 mindset" to IPv6 policy, even before any significant deployment has taken place and operational experience has been collected. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
If you give your customers a single /128, you're forcing *them* to use NAT. This is bad.
Probably the simplest way will be subnet /64 or smaller, where part of IP will be MAC address of enduser.
The strong recommendation is to give your customers something between a /48 and a /64. NO LESS, unless you know for sure(!) that they only have a single machine, and no network behind it.
ok, I understand the concept.. still have to wait for proper BRAS and CPE implementations... And I understand, that i.e. /64 for subscribers network is something that in IPv4 PI world would be forbidden (i.e. /29). If all of us agree, that there is enough address space for every toothbrush, subscribers can get something between /48 an /64 and this is will be usual, and even in IPv6 PA space there will be no every subnet registration (as I understand, and as it is requiured for IPv4 PA) - why IPv6 PI can not be similar to IPv6 PA then ??? Regards, Marcin
Hi On Mon, May 02, 2011 at 08:37:35PM +0200, Marcin Kuczera wrote:
And I understand, that i.e. /64 for subscribers network is something that in IPv4 PI world would be forbidden (i.e. /29). If all of us agree, that there is enough address space for every toothbrush, subscribers can get something between /48 an /64 and this is will be usual, and even in IPv6 PA space there will be no every subnet registration (as I understand, and as it is requiured for IPv4 PA)
Mostly, yes.
- why IPv6 PI can not be similar to IPv6 PA then ???
This is pretty much what we're going to propose in Thursday's APWG session, reorganize the whole PA/PI structure, possibly completely doing away with the distinction. I'm going to bring up some background info, and then we'll go into the discussion what *the working group* thinks the goal should be - and then we'll take it to the formal policy process to put the ideas in writing. Planned time frame: Thursday, 11:00-12:00, main room (and webcast, of course) Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Martin wrote:
On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera <marcin@leon.pl> wrote:
hello,
Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ? See below.
The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers.
However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes.
I doubt this is correct. You mentioned that you had not filled the /32. In other words, there should be /48s left over unallocated internally.
These /48s can be (sub-)allocated to customers (please forgive my flawed internet-numbers-delegation-vocabulary), who are free to announce them over BGP sessions.
It is then up to your customers to find transit providers willing to accept these announcements, which may be helped by them having route6 objects registered.
My question there would be wether larger prefixes then /32 from the pa-ranges would be generally accepted? As far as I understand, that would be a problem.
If they have trouble with connectivity due to AS:es filtering out these long prefixes from IPv6 PA regions, they will have to get their own PA by becoming a LIR member themselves.
Or forcing their customers to apply for PIv6 for their purposes.
For SponsorLIR agreement customers - little ISPs, willing to advertise their i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA (not advertised as whole by LIRs ASes) would be great... The yet-to-be properly challenged (legacy?) consensus/opinion of this WG is that ISPs must pay to play IPv6. I.e., you must become LIR to be allowed to announce routes into the DFZ.
IPv6 PI (PIv6) is nearly useless, by design: Only customer-less end-users can use PIv6 space today without stepping into a grey zone in the policy documents. I.e., these end-users can't have customers.
There is one other solution. You apply for v6-PI for your own infrastructure and encourage your customers apply for their own pi-space in order to get v6. This is what the non-profit-organization I work for is now going to do (since we cannot afford becoming LIR). Obviously, this blows up the routing table (which I strongly dislike), but policy is clear that this is the only way to continue what we are doing without willingly violating the current policy. IMHO obviously, changing PI policy would be a more elegant solution.
Presumably, the more ISPs that sign up for this Internet tax (the LIR membership fees), the lower it will become (#LIRs is most definitely sub-linearly proportional to the RIPE NCC:s operational costs). It is fairly obvious to me that this attempt to (at least partially) solve a *perceived* network model problem with taxes is not long-term stable in itself.*
Yea, that would be nice. But that will only help eventually, not now.
Personally I'd much prefer if the policies were aligned with reality better, since it would allow us to get rid of the more or less arbitrary policy-interpreting role the IPRA:s at the RIPE NCC has for v6 resources today. This would make the landscape much more honest and just. After all, it's just bits anyway.
I strongly support that!
* This is *the* major source for all this head ache. There is a considerable fear among many AP-WG participants that making IPv6 PI easier to get will (1) lead to an uncontrolled explosion of IPv6 prefixes in the DFZ (2), which hardware will fail to handle (3) and the IPv6(**) internet will break down (4).
I don't really see why suddenly a lot of organizations should come up wanting PIv6. I think the need of PIv6 would be quite compareable to PIv4, and at least nowadays, the PI-Prefixes aren't really that problem as far as I see. And, as pointed out before, the current PIv6 policy can even be interpreted as source of much more v6-routes in the DFZ anyways. regards, Immo
Immo, On Sun, May 1, 2011 at 2:16 PM, Immo 'FaUl' Wehrenberg <immo.ripe@be.free.de> wrote:
IPv6 PI (PIv6) is nearly useless, by design: Only customer-less end-users can use PIv6 space today without stepping into a grey zone in the policy documents. I.e., these end-users can't have customers.
I'm surprised that I had not realized that myself. IPv6-hosting ::= (bring-your-own-PIv6-prefix, @ 50EUR/year+registry fees | buy from a LIR) At 65536 /48s in a /32, that's a big source of revenue for RIPE right there. :) Current break-even seems to be around 50 customers (for when it's cheaper to be LIR). Which in other words means 50:1 prefixes in DFZ, before break-even. And I'm betting there's a significant long-tail of hosting providers who have less than 50 customers. Oh the joy of DFZ :) Regards, Martin
I don't really see why suddenly a lot of organizations should come up wanting PIv6. I think the need of PIv6 would be quite compareable to PIv4, and at least nowadays, the PI-Prefixes aren't really that problem as far as I see. And, as pointed out before, the current PIv6 policy can even be interpreted as source of much more v6-routes in the DFZ anyways.
That is not so simple in post-communist countries. As I know, there are around 200 ISPs in Germany. In Poland, we have - 2000-3000 of ISPs.. however they are very little sometimes - i.e. serving 300 or 700 customers. let's say - 10 euro /month per customer (+ VAT) * 700 = 7000 euro of a budget. Pay taxes, pay salaries, pay lawyers, office, investments, upstreams, infrastructure... I's just a little for the owner if you compare it to large ISPs. So, if there is no possibility to use IPv6 PI for own customers (/128 for customer) any more, the only way is to use other LIR's part of PA space. There is NO WAY that they will pay for beeing LIR. Regards, Marcin
Martin Millnert wrote:
Marcin,
On Tue, Apr 26, 2011 at 5:51 PM, Marcin Kuczera <marcin@leon.pl> wrote:
hello,
Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ?
See below.
The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers.
However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes.
I doubt this is correct. You mentioned that you had not filled the /32. In other words, there should be /48s left over unallocated internally.
These /48s can be (sub-)allocated to customers (please forgive my flawed internet-numbers-delegation-vocabulary), who are free to announce them over BGP sessions.
Indeed, however there is one "little" issue. /32 is already advertised @AS13000 as whole. So there are 2 possibilities: - add paralel route objects, but then MNT-LOWER must be added and all related inter-ISP communiaction problems. - not adverising /32 @ AS13000, adverising only prefixes in use. Both cases I would like to avoid. So, I would prefer to have /32 for own purposes, eventually customers who buy Internet from us, and other, who are just SponsorLIR customers.
Presumably, the more ISPs that sign up for this Internet tax (the LIR membership fees), the lower it will become (#LIRs is most definitely sub-linearly proportional to the RIPE NCC:s operational costs). It is fairly obvious to me that this attempt to (at least partially) solve a *perceived* network model problem with taxes is not long-term stable in itself.*
You can't use this argument for people who earn around 500-1000 euro per month with their business... Post comunistic block is much different than old EU, and most people from old EU do not realize that... Marcin
Hi Marcin, On Sun, May 1, 2011 at 4:59 PM, Marcin Kuczera <marcin@leon.pl> wrote:
These /48s can be (sub-)allocated to customers (please forgive my flawed internet-numbers-delegation-vocabulary), who are free to announce them over BGP sessions.
Indeed, however there is one "little" issue. /32 is already advertised @AS13000 as whole.
So there are 2 possibilities: - add paralel route objects, but then MNT-LOWER must be added and all related inter-ISP communiaction problems. - not adverising /32 @ AS13000, adverising only prefixes in use.
3: - at 50 EUR/year/customer, retrieve 1 PIv6 prefix, per customer.
Presumably, the more ISPs that sign up for this Internet tax (the LIR membership fees), the lower it will become (#LIRs is most definitely sub-linearly proportional to the RIPE NCC:s operational costs). It is fairly obvious to me that this attempt to (at least partially) solve a *perceived* network model problem with taxes is not long-term stable in itself.*
You can't use this argument for people who earn around 500-1000 euro per month with their business... Post comunistic block is much different than old EU, and most people from old EU do not realize that...
To which I wonder, how painful is 50 EUR/year per business ("additional fees may apply"), to bring its own prefix to someone else's hosting/network infrastructure? Regards, Martin
To which I wonder, how painful is 50 EUR/year per business ("additional fees may apply"), to bring its own prefix to someone else's hosting/network infrastructure?
ok, we still do not understand each other. My SponsorLIR customer is and ISP who has their own customers. For IPv4 PI this works great. For IPv6 PI, arguments that addresses will be used for customers (same way as in IPv4 PI) results rejection of the IPv6 PI request. So - 50 euro is ok, but we can't get IPv6 PI with the same explanations as for IPv4 PI.... Regards, Marcin
Marcin, On Sun, May 1, 2011 at 5:17 PM, Marcin Kuczera <marcin@leon.pl> wrote:
To which I wonder, how painful is 50 EUR/year per business ("additional fees may apply"), to bring its own prefix to someone else's hosting/network infrastructure?
ok, we still do not understand each other.
Yes, sorry, I forgot you were talking about ISPs. Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;) Cheers, Martin
Martin Millnert wrote:
Marcin,
On Sun, May 1, 2011 at 5:17 PM, Marcin Kuczera <marcin@leon.pl> wrote:
To which I wonder, how painful is 50 EUR/year per business ("additional fees may apply"), to bring its own prefix to someone else's hosting/network infrastructure? ok, we still do not understand each other.
Yes, sorry, I forgot you were talking about ISPs.
Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;)
ha ha ha.... Seriously, is there ANY resonable reason why policy for IPv6 PI can not be same as for IPv4 PI ? Regards, Marcin
Marcin Kuczera wrote:
Seriously, is there ANY resonable reason why policy for IPv6 PI can not be same as for IPv4 PI ?
Because the IPv4 PI policy is an unfortunate relic that has seen much uhm, creative use that required a policy such as 2007-01 to clean up and has so far taken dozens of man years to implement? If you don't want to or can't pay for resources you use, you should be asking yourself questions. If you're not running a sustainable business, you're exercising a hobby. Why would somebody else pay for your hobby? As far as I've seen, the cost of utility power and network hardware in what you describe as 'post communistic block' is not that different from what you describe as 'old Europe', so I'm intrigued how those (I think far more significant) costs affect you. Remco No hats. This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
Remco, On Sun, May 1, 2011 at 6:18 PM, Remco Van Mook <Remco.vanMook@eu.equinix.com> wrote:
Marcin Kuczera wrote:
Seriously, is there ANY resonable reason why policy for IPv6 PI can not be same as for IPv4 PI ?
Because the IPv4 PI policy is an unfortunate relic that has seen much uhm, creative use that required a policy such as 2007-01 to clean up and has so far taken dozens of man years to implement?
Isn't 2007-01 in place for IPv6 PI today already?
If you don't want to or can't pay for resources you use, you should be asking yourself questions.
If you're not running a sustainable business, you're exercising a hobby. Why would somebody else pay for your hobby?
The business *is* sustainable, with IPv4! They're even paying for it according to the policies of the community. How is it even possible that a IPv6 resource, which are practically infinite, can bear a cost which is ~50x higher for the same use, than the cost of a IPv4 resource, which is about to run out? If anything, these are *not* values derived from a market. The cost with prefixes that I think you refer to, comes not from the act of registering them in a registry, but from the use of them with a routing protocol, like BGP. If the cost in the core of BGP cannot scale with the size of the internetwork, I'd say this is primarily a problem with the routing protocol and not the mere fact that some chunks of space has names next to them in a database, chunks of space which may or may not participate in this voluntary routing activity.
As far as I've seen, the cost of utility power and network hardware in what you describe as 'post communistic block' is not that different from what you describe as 'old Europe', so I'm intrigued how those (I think far more significant) costs affect you.
Power/network hardware scales closer to number of customers than the LIR cost, which is a *much* more stepwise cost at small sizes, do. Maybe we can get one such example ISP with 300-700 customers to show its books to prove this point. Now, assuming that point can be proven: that 50 EUR/year is a bearable cost for IPv4 resources, but ~2000+ EUR for IPv6 is not(*), the question becomes: Would the RIPE community like to adjust this unbalance between IPv4 and IPv6 somehow? Any decision/agreement, or lack thereof, has consequences. Regards, Martin * It's also not very hard to imagine that the highly competitive market (good thing, no?) may make it very hard for one ISP to increase its prices, just to offer IPv6 to its customers via means of being a LIR, when another may find a much cheaper way to obtain an IPv6 prefix (from some sponsoring LIR/co-op LIR in some fashion, say, for example). If that scales up, two things will occur: 1) RIPE's policies will be overrun, 2) filtering praxis's will be eroded. I think it's quite optimistic to believe any *registration* policies are going to hold off this particular piece of reality.
Martin Millnert wrote:
Remco,
On Sun, May 1, 2011 at 6:18 PM, Remco Van Mook <Remco.vanMook@eu.equinix.com> wrote:
Marcin Kuczera wrote:
Seriously, is there ANY resonable reason why policy for IPv6 PI can not be same as for IPv4 PI ? Because the IPv4 PI policy is an unfortunate relic that has seen much uhm, creative use that required a policy such as 2007-01 to clean up and has so far taken dozens of man years to implement?
Isn't 2007-01 in place for IPv6 PI today already?
If you don't want to or can't pay for resources you use, you should be asking yourself questions.
If you're not running a sustainable business, you're exercising a hobby. Why would somebody else pay for your hobby?
The business *is* sustainable, with IPv4! They're even paying for it according to the policies of the community.
How is it even possible that a IPv6 resource, which are practically infinite, can bear a cost which is ~50x higher for the same use, than the cost of a IPv4 resource, which is about to run out? If anything, these are *not* values derived from a market.
That's the point !
As far as I've seen, the cost of utility power and network hardware in what you describe as 'post communistic block' is not that different from what you describe as 'old Europe', so I'm intrigued how those (I think far more significant) costs affect you.
Power/network hardware scales closer to number of customers than the LIR cost, which is a *much* more stepwise cost at small sizes, do. Maybe we can get one such example ISP with 300-700 customers to show its books to prove this point.
I have asked some of the small ISP's to provide me some simplified data about their businesses. If I get some more, I'll put them on the list.
Now, assuming that point can be proven: that 50 EUR/year is a bearable cost for IPv4 resources, but ~2000+ EUR for IPv6 is not(*), the question becomes: Would the RIPE community like to adjust this unbalance between IPv4 and IPv6 somehow?
Any decision/agreement, or lack thereof, has consequences.
I.e. RIPE (willing or not) may lead to massive closing of little ISPs, their businesses will be incorporated by those who are LIRs.. Ok, similar process happens all the time, however - RIPE should not act as "regulator"/cathalysator in business domain... Regards, Marcin
Regards, Martin
* It's also not very hard to imagine that the highly competitive market (good thing, no?) may make it very hard for one ISP to increase its prices, just to offer IPv6 to its customers via means of being a LIR, when another may find a much cheaper way to obtain an IPv6 prefix (from some sponsoring LIR/co-op LIR in some fashion, say, for example). If that scales up, two things will occur: 1) RIPE's policies will be overrun, 2) filtering praxis's will be eroded. I think it's quite optimistic to believe any *registration* policies are going to hold off this particular piece of reality.
On Sun, May 01, 2011 at 11:18:41PM +0100, Remco Van Mook wrote:
Why would somebody else pay for your hobby?
Why do businesses pay for their competitor's business? Assuming LIRs are generally businesses (first order approximation), LIRs seem to be totally fine to pay for hardware to support all their competitors DFZ deaggregation pollution. I'm missing any call to arms to get THAT in check. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Tue, 3 May 2011, Daniel Roesen wrote:
Why do businesses pay for their competitor's business?
I'm going to sum up my reasons for my views in this email and then most likely stop writing as this is going nowhere. I started using the Internet in early 90ties and as soon as I heard about PI, I thought it was a great idea and why shouldn't I have one? It's great for me, I never have to renumber. Then I started working with routing and udnerstood how this global system worked, and all of a sudden I understood the global implications of PI. I still think it's a great idea for each individual, but bad for the humanity as a whole. It's just like driving a hummer to go shoe-shopping is a bad idea in that it's wasteful to use this resource. A DFZ route has to be carried by everybody, meaning as the DFZ increases, everybody has to upgrade their platforms, whether they might need it for bandwidth reasons or not. It also means people have to buy more expensive platforms. The largest 1U L3 switch FIB size I know of is the Extreme Summit 480X, it can do almost 512k IPv4 routes. With IPv4 and IPv6 table still growing, I'd hesitate to recommend anyone to buy it right now because it won't be able to handle DFZ in 3-5 years. This means someone who wants to take the DFZ needs a bigger and more expensive platform that most likely uses more energy over its lifetime, not to talk about what it costs to manufacture it. In my 10-15 years in core routing, I've seen the table rise from ~100 to ~350k routes, but the platforms haven't gotten very much faster compared to the routing table size. They still take tens of seconds to converge when it comes to programming all these routes into FIB, and the algorithms we use to calculate the routes are from the 1980ies or earlier. As far as I know, there are no magical new much better ways of doing this on the horizon, most of the improvement suggestions involves doing overlay networks or having end systems be more flexible on their behaviour regarding how tightly services are bound to addresses. So to sum it all up. I don't trust moores law to keep up with routing table growth if we let "everybody" get PI, but it seems I am in very much minority here with that view. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, On Tue, May 03, 2011 at 09:41:55PM +0200, Daniel Roesen wrote:
Assuming LIRs are generally businesses (first order approximation), LIRs seem to be totally fine to pay for hardware to support all their competitors DFZ deaggregation pollution.
I'm missing any call to arms to get THAT in check.
Different orders of magnitude. How many "ISP-like" operations can you have, and how many "just end users" can you have? So what we have tried to work for is a reasonable(*) balance - that end users *can* have independent address space, but not all end users would actually *want* it. To stress the obvious: not all "end users" are identical - there's "medium sized businesses" and "my mom's computer at home". I don't think my mom should have PI addresses being globally visible in the DFZ... (and as far as I remember, Daniel's employer isn't offering to route PI addresses to their customer base either). Just something to keep in mind. Gert Doering APWG chair (*) reasonable = some think it's too loose, others think it's too strict, but generally mostly workable and nothing has exploded yet -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Sun, 1 May 2011, Martin Millnert wrote:
Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;)
Is this really true? IPv6 PI at 50EUR/year? In the last discussion we had on this list, it was indicated that it was NOT the case, and it would be a lot more expensive (1000+ EUR per year). I am all for raising the yearly IPv4 PI price to the same level as well. Also, if you have a /32 PA it was my understanding that generally the encompassing /29 is already reserved for you as soon as you provide justification, so this will keep down the number of DFZ announcements for PA blocks. That's the main reason I don't want to see IPv6 PI proliferation, we're trying hard to keep down the number of IPv6 DFZ routes, let's not explode it by allowing easy PI. Let's keep the pressure up on other ways to multihome instead. -- Mikael Abrahamsson email: swmike@swm.pp.se
Is this really true? IPv6 PI at 50EUR/year?
http://www.ripe.net/ripe/docs/ripe-499 "set fee of EUR 50 for each independent Internet number resource assignment" ____________________________________ Tero Toikkanen Nebula Oy
On Tue, 3 May 2011, Tero Toikkanen wrote:
Is this really true? IPv6 PI at 50EUR/year?
http://www.ripe.net/ripe/docs/ripe-499 "set fee of EUR 50 for each independent Internet number resource assignment"
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble. And regarding per-item billing being low, I refer to: <http://lib.store.yahoo.net/lib/demotivators/irresponsibilitydemotivationalposter.jpg> No Single Raindrop Belives It Is To Blame For The Flood. -- Mikael Abrahamsson email: swmike@swm.pp.se
* Mikael Abrahamsson:
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble.
And why wouldn't the Internet work with 600,000 prefixes in the DFZ? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Tue, 3 May 2011, Florian Weimer wrote:
* Mikael Abrahamsson:
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble.
And why wouldn't the Internet work with 600,000 prefixes in the DFZ?
Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k). Also, IPv6 uses twice the TCAM resources as IPv4... -- Mikael Abrahamsson email: swmike@swm.pp.se
Am 03.05.2011 um 12:39 schrieb Mikael Abrahamsson:
On Tue, 3 May 2011, Florian Weimer wrote:
* Mikael Abrahamsson:
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble.
And why wouldn't the Internet work with 600,000 prefixes in the DFZ?
Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k).
Also, IPv6 uses twice the TCAM resources as IPv4...
so, basically what you are saying is that you know that your routers need an upgrade in 5 years and you don't want to pay for an upgrade or you can't figure out a business plan which covers the costs for that? But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get their business plan right if they don't can afford paying $$$ for PI space or rather would prefer to pay other bills with the money? WTF?! Guys, don't discriminate. The cost for independent resources is there just to remind the people that they should give them back if they don't need it anymore (in contrast to the former solution where just abandoning resources didn't cost anyone anything), not to hinder anyone from actually getting them in the first place. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
On Tue, 3 May 2011, Sascha Lenz wrote:
The cost for independent resources is there just to remind the people that they should give them back if they don't need it anymore (in contrast to the former solution where just abandoning resources didn't cost anyone anything), not to hinder anyone from actually getting them in the first place.
That's your opinion, I don't agree. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
On Tue, 3 May 2011, Sascha Lenz wrote:
The cost for independent resources is there just to remind the people that they should give them back if they don't need it anymore (in contrast to the former solution where just abandoning resources didn't cost anyone anything), not to hinder anyone from actually getting them in the first place.
That's your opinion, I don't agree.
Well, if you don't agree (you have a right to) please list some arguments that will change others opinion. I personally support Sascha arguments. Regards, Marcin
* Mikael Abrahamsson:
On Tue, 3 May 2011, Florian Weimer wrote:
* Mikael Abrahamsson:
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble.
And why wouldn't the Internet work with 600,000 prefixes in the DFZ?
Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k).
But this happens every couple of years. The global table has outgrown the capacity of the PFC3C, and before that, of the PFC2. So despite seemingly unescapable hardware limitations, a gradual growth of the prefix count is not much of a problem in itself for the network as a whole.
Also, IPv6 uses twice the TCAM resources as IPv4...
This is an implementation detail of one particular vendor. 8-) -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Tue, 3 May 2011, Florian Weimer wrote:
But this happens every couple of years. The global table has outgrown the capacity of the PFC3C, and before that, of the PFC2. So despite seemingly unescapable hardware limitations, a gradual growth of the prefix count is not much of a problem in itself for the network as a whole.
This is definitely solvable, it just costs money. Money it seems the "polluter" doesn't pay. Sure, one can see it as "cost of doing business" to be an ISP, but it's also easy to see that a prefix in the DFZ most likely costs more than 50EUR per year in equipment having to be paid by SOMEONE. There is no free lunch. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
On Tue, 3 May 2011, Florian Weimer wrote:
* Mikael Abrahamsson:
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble.
And why wouldn't the Internet work with 600,000 prefixes in the DFZ?
Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a full table (at around 750k).
Also, IPv6 uses twice the TCAM resources as IPv4...
good, I think that all hardware vendors will be happy to sell new equimpment Marcin
On 05/03/2011 08:50 AM, Mikael Abrahamsson wrote:
Oki, I don't know enough about the ripe billing system , but I do know that if we get many more hundreds of thousands of PI assignments (regardless of v4 or v6), the global routing system is going to be in real trouble.
You'll not solve this problem by any RIPE policy. Deaggregation of assigned address space is here in both IPv4 and IPv6. >40% of announced IPv4 prefixes into global table are unnecessary and this is NOT problem of PI address existence, it's human problem - people are deaggregating their address space. Almost the same thing starts to be happening in IPv6 table. And comercial ISPs simply will NOT filter these deaggregated blocks, because of money - there're only few operators, where clean network setup is necessary - but majority just accepts and announces to the world anything from the customer, because customer is paying money for that. Almost nobody realy cares about PI/PA separation or aggregation, address is just a number from the router point of view. CIDR reports are good proof of this - that's the reality of internet routing. If there will not be regular PI from RIPE (or very limited by the policy), market just finds another "solution" of the problem. And the easy solution is - yes, yes... deaggregation of assigned /32. Some LIRs started carving their /32 IPv6 PA already. I don't think, that blocking IPv6 PI assigments will reduce table growth or bring more members/LIRs. 2007-01 is just cleanup of historic mess. If we'll apply this to IPv6 PI assigments, I don't see reason for blocking IPv6 PI assigments using similar rules, as we have in IPv4 already. Policies for IPv6 should not bring more limitations for assigment compared to IPv4 policies - this will simply slow down IPv6 deployment in networks, where IPv4 PI is used these days. And I'm not supporting any policy, what will slow down IPv6 deployment in real words. And yes, I understand troubles mentioned, I'm aware about hardware limitations of many routing platforms used worldwide. But as I mentioned already, I don't think, that problem of growing global table can be solved just by reducing PI assigments, this is minor part of whole issue... With regards, Daniel
That's the main reason I don't want to see IPv6 PI proliferation, we're trying hard to keep down the number of IPv6 DFZ routes, let's not explode it by allowing easy PI. Let's keep the pressure up on other ways to multihome instead.
ok, look @ this scenario: 1. I'am a SponsorLIR 2. I open second LIR to get next /32, and I merge it immediatelly with my LIR - so I will have x2 /32 3. first of my /32 is used under my main AS only 4. second of my /32 is segmented into /48. Every /48 is advertised under different AS number, of a different little ISP who receives these /48 from me. So - this little (and expansive in first moment) trick also causes that routing table grows up. Now - the money. I'll charge for each /48 50 euro yearly. If /48 would be PI, then RIPE would charge me 50 euro, and I would recharge 50 euro + something. - first case - I earn a lot of money, RIPE - no extra money (except opening a new LIR, just once) - second case - we share ;) I can provide /48 for every operator in PL, exaclty the same way as I do it today with SponsorLIR and IPv4 PI. They don't have to be my downstreams. And you know what, I suppose that this already happens and RIPE can't stop it. If new policy will try to block it, people will find our legal workaround. People are smarter than any institution. Regards, Marcin
On Tue, 3 May 2011, Marcin Kuczera wrote:
And you know what, I suppose that this already happens and RIPE can't stop it. If new policy will try to block it, people will find our legal workaround. People are smarter than any institution.
That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 05/03/2011 12:40 PM, Mikael Abrahamsson wrote:
On Tue, 3 May 2011, Marcin Kuczera wrote:
And you know what, I suppose that this already happens and RIPE can't stop it. If new policy will try to block it, people will find our legal workaround. People are smarter than any institution.
That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR.
This doesn't making sense at all. Or then each (!!) PA assigment also must cost 2000EUR (or more, depending on assigment size, as PA assignments are generally larger than PI assignments). If you only increase cost of PI, "smart people" just starts using their PA block divided into several parts... As mentioned by Marcin Kuczera today, this is happening ALREADY... just look into your BGP table, his scenario isn't fiction (just is hapening on their 1st IPv6 PA)... Any policy doesn't block organisation from becoming LIR, obtain maybe in some case "cheaper" PA and then split it into several blocks (and resell it). And nothing will block deaggregated advertisments in the BGP table in effect, as any policy doesn't imply real filtering... Global table will grow anyway, independently of the policy. Restrictions doesn't make sense here, on paper you can wrote anything and each limitation can be circumvented, some people are very creative... Daniel
On Tue, 3 May 2011, Daniel Suchy wrote:
This doesn't making sense at all. Or then each (!!) PA assigment also must cost 2000EUR (or more, depending on assigment size, as PA assignments are generally larger than PI assignments).
Well, you're already getting charged for the LIR cost, I don't have a problem giving discount for LIR+PA costing the same as PA.
If you only increase cost of PI, "smart people" just starts using their PA block divided into several parts... As mentioned by Marcin Kuczera today, this is happening ALREADY... just look into your BGP table, his scenario isn't fiction (just is hapening on their 1st IPv6 PA)...
Well, then I guess we'll just have to make sure we filter at RIR allocation size. If people announce /36 from /32 PA space, we won't accept their routes. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 05/03/2011 01:21 PM, Mikael Abrahamsson wrote:
On Tue, 3 May 2011, Daniel Suchy wrote:
This doesn't making sense at all. Or then each (!!) PA assigment also must cost 2000EUR (or more, depending on assigment size, as PA assignments are generally larger than PI assignments).
Well, you're already getting charged for the LIR cost, I don't have a problem giving discount for LIR+PA costing the same as PA.
Not really. As LIR, I can obtain second, third, fourth PA and I'll pay almost the same membership fee. Well, there will be slight change due to category change - but extra large LIR pays 5500EUR - that's less than cost of three PI blocks in your pricing scheme and much larger address space available for anything...
Well, then I guess we'll just have to make sure we filter at RIR allocation size. If people announce /36 from /32 PA space, we won't accept their routes.
And who does that, in reality? Just look into global BGP table, look on prefixes advertised by Google, for example. Reality is, that people deaggregates right now and nobody filters them. Prefixes are announced by customers and customers are paying for that to their upstream providers. In the fact, not policy, but sales department controls, what is announced in global tables. Daniel
On Tue, 3 May 2011, Daniel Suchy wrote:
Not really. As LIR, I can obtain second, third, fourth PA and I'll pay almost the same membership fee. Well, there will be slight change due to category change - but extra large LIR pays 5500EUR - that's less than cost of three PI blocks in your pricing scheme and much larger address space available for anything...
I surely hope not, then the current policy is defective. Last I heard, RIPE made reservation for growth when handing out first /32, so next it'll be /31, /30 etc, up to the reserved /29. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 05/03/2011 01:45 PM, Mikael Abrahamsson wrote:
I surely hope not, then the current policy is defective. Last I heard, RIPE made reservation for growth when handing out first /32, so next it'll be /31, /30 etc, up to the reserved /29.
But, PI has minimum at /48. In /32, there're 65536 /48 blocks. And costs of LIR doesn't increase so much, if he moves from /32 to /31, 30... (and similary in IPv4). Thats' the point... And probably nobody will support change in current billing policy of RIPE NCC towards higher cost of larger PA assignments (=increase it's own costs). Daniel
That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR. Please understand, that it will never happen. People, who are using now PI IPv4 space will never pay extra 2K Euro for IPv6 addresses. It's a historical issue of PI addresses, it's impossible describe to
Hello, Mikael. these users the difference between PI v 4 and PI v 6. They will rather use NAT IPv4 or PA IPv6, as Marcin Kuczera described. Also I fully agree with Daniel Suchy. We have now around 350 customers with PI IPv4 blocks and our customers decided to NOT implement IPv6 till IPv6 PI policy will not change. Just imagine - we have now around 350 PI IPv4 blocks and 10 PI IPv6, it doesn't look like a "IPv6 act now " ! So, during last year no one user of PI IPv4 became a LIR. They simply ignore it. So if we will not change the IPv6 policy, these customers will not implement IPv6 in their networks, or will implement it with using of PA IPv6 addresses of LIR, but routing table will still growth. best regards, Alexander Vishnyakov, Tel.: (+420) 257 218 437 | (+420) 603 109 280 Fax: (+420) 257 218 437 ICQ: 164 695 837 Skype: isp-servis-cz Vissado s.r.o. | Hevlínská 435/8, 155 21 Praha 5 www.isp-servis.cz On Tue, May 3, 2011 at 12:40 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Tue, 3 May 2011, Marcin Kuczera wrote:
And you know what, I suppose that this already happens and RIPE can't stop it. If new policy will try to block it, people will find our legal workaround. People are smarter than any institution.
That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, 3 May 2011, Alex Vishnyakov wrote:
They will rather use NAT IPv4 or PA IPv6, as Marcin Kuczera described. Also I fully agree with Daniel Suchy.
I'm fine with them using NAT.
We have now around 350 customers with PI IPv4 blocks and our customers decided to NOT implement IPv6 till IPv6 PI policy will not change. Just imagine - we have now around 350 PI IPv4 blocks and 10 PI IPv6, it doesn't look like a "IPv6 act now " !
Listen, I don't care about your issues. I'm looking global here. PI is a way to cut costs for future renumbering, for some this is a real issue and they'll be prepared to pay. For some it's just a "nice to have" and they won't use it, and then we won't have to carry their PI in the DFZ.
So, during last year no one user of PI IPv4 became a LIR. They simply ignore it. So if we will not change the IPv6 policy, these customers will not implement IPv6 in their networks, or will implement it with using of PA IPv6 addresses of LIR, but routing table will still growth.
No, because people who sub-delegate from /32 PA space won't get their routes spread, just like the /24 situation for IPv4. -- Mikael Abrahamsson email: swmike@swm.pp.se
> Listen, I don't care about your issues. I'm looking global here. It's your mistake that you don't care, because it's not just my issue - I can bring here to this discussion more then 1000 ISPs from Russia and Ukraine, who are using PIs IPv4 now and want to move to IPv6 technology, but cannot, because of the policy and people like you, and then it will become very quickly a global issue. Or 1000 of ISPs is still a small number for you ? It's more than million potential IPv6 users, content servers etc. best regards, Alex Vishnyakov On Tue, May 3, 2011 at 1:24 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote: > On Tue, 3 May 2011, Alex Vishnyakov wrote: > >> They will rather use NAT IPv4 or PA IPv6, as Marcin Kuczera described. >> Also I fully agree with Daniel Suchy. > > I'm fine with them using NAT. > >> We have now around 350 customers with PI IPv4 blocks and our customers >> decided to NOT implement IPv6 till IPv6 PI policy will not change. >> Just imagine - we have now around 350 PI IPv4 blocks and 10 PI IPv6, >> it doesn't look like a "IPv6 act now " ! > > Listen, I don't care about your issues. I'm looking global here. PI is a way > to cut costs for future renumbering, for some this is a real issue and > they'll be prepared to pay. For some it's just a "nice to have" and they > won't use it, and then we won't have to carry their PI in the DFZ. > >> So, during last year no one user of PI IPv4 became a LIR. They simply >> ignore it. So if we will not change the IPv6 policy, these customers will >> not implement IPv6 in their networks, or will implement it with using of PA >> IPv6 addresses of LIR, but routing table will still growth. > > No, because people who sub-delegate from /32 PA space won't get their routes > spread, just like the /24 situation for IPv4. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se >
On Tue, 3 May 2011, Alex Vishnyakov wrote:
It's your mistake that you don't care, because it's not just my issue - I can bring here to this discussion more then 1000 ISPs from Russia and Ukraine, who are using PIs IPv4 now and want to move to IPv6 technology, but cannot, because of the policy and people like you, and then it will become very quickly a global issue. Or 1000 of ISPs is still a small number for you ? It's more than million potential IPv6 users, content servers etc.
You're seriously saying 2EUR per year per customer (1000 customers) breaks their back? If it does, then they should look into other solutions such as renumbering each time they switch upstream provider instead of externalising the cost to the rest of the world. <http://en.wikipedia.org/wiki/Marginal_cost#Externalities> -- Mikael Abrahamsson email: swmike@swm.pp.se
If it does, then they should look into other solutions such as renumbering each time they switch upstream provider instead of externalising the cost to the rest of the world. <http://en.wikipedia.org/wiki/Marginal_cost#Externalities> Thank you for your link, I appreciate your help in this issue...
You're seriously saying 2EUR per year per customer (1000 customers) breaks their back? Try to explain it to them. You don't understand that few thousands of ISPs are using PI IPv4 and your policy limitation will not change their behaviour. You had to forbid PI IPv4 to end-users in the past, but not to make some prohibitions in the IPv6 policy.
Regarding filtering IPv6 prefixes I agree with Daniel Suchy, I think there will be a lot of people (let's say 99% ?:-)) who will not do it. best regards, Alex Vishnyakov On Tue, May 3, 2011 at 1:43 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Tue, 3 May 2011, Alex Vishnyakov wrote:
It's your mistake that you don't care, because it's not just my issue - I can bring here to this discussion more then 1000 ISPs from Russia and Ukraine, who are using PIs IPv4 now and want to move to IPv6 technology, but cannot, because of the policy and people like you, and then it will become very quickly a global issue. Or 1000 of ISPs is still a small number for you ? It's more than million potential IPv6 users, content servers etc.
You're seriously saying 2EUR per year per customer (1000 customers) breaks their back?
If it does, then they should look into other solutions such as renumbering each time they switch upstream provider instead of externalising the cost to the rest of the world.
<http://en.wikipedia.org/wiki/Marginal_cost#Externalities>
-- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
On Tue, 3 May 2011, Marcin Kuczera wrote:
And you know what, I suppose that this already happens and RIPE can't stop it. If new policy will try to block it, people will find our legal workaround. People are smarter than any institution.
That's why I want (v4|v6) PI to cost 2000EUR, not 50EUR.
Yeap, do what all the stupid governments do, increase taxes, if it doesn't work - put people into a prison and add more taxes (prisons are expansive)... Marcin
Hi, to come back to one specific question here: On Tue, May 03, 2011 at 07:47:07AM +0200, Mikael Abrahamsson wrote:
Though, 50 EUR/year for PIv6 for each one of the ISPs customer is merely 4 EUR/month per customer. And they get their own /48 PIv6 prefix! ;)
Is this really true? IPv6 PI at 50EUR/year?
Right now, the price for an "independent numbering resource" is 50 EUR / year per piece - that's IPv4 PI assignments, IPv6 PI assignments and AS numbers. This price is decided upon by the RIPE general meeting (AGM), where the actual paying members decide how they want the fee structure to be. The address policy working group can influence this decision by giving input to the RIPE NCC / NCC board as in "the community thinks that this price is too low / too high / should be dependent on the size / ...", but we don't get to actually *decide* this - money is decided by paying members. Now, something else to keep in mind regarding PI space: you need someone who is actually willing to route that space for you - which usually isn't done on "mass market end user" type contracts (at least, over here in .DE, none of the big DSL or cable ISPs would route someone else's PI for them), so you need a "business ISP contract", which adds indeed cost that "the polluter" has to bear. This discussion is drifting back and forth between "I'm a hosting provider, I run a business providing IP connectivity to the content my customers want to be visible in the Internet, and I need space for that" and "if millions of end users all get PI into the DFZ, routers will explode". Which both is correct - but somewhat unrelated, as this is talking about different types of "internet entities" that come in vastly different numbers. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
participants (18)
-
Alex Vishnyakov -
Andrey Semenchuk -
Daniel Roesen -
Daniel Suchy -
David Freedman -
Florian Weimer -
Gert Doering -
Immo 'FaUl' Wehrenberg -
Jim Reid -
Leo Vegoda -
Marcin Kuczera -
Martin Millnert -
Mikael Abrahamsson -
Remco Van Mook -
Richard Hartmann -
Sascha Lenz -
Tero Toikkanen -
Turchanyi Geza