About the /22 allocation limitation
Hi Everyone, First of all, my name is Daniel and Im the Network Administrator of the AS199952 Im new to the address policy wg and Im sure you can answer the question. The /22 allocation restriction to new LIRs are only for new LIRs or for all LIRs? We only got a /22 as new LIR, and we cant ask for more IPs, proving we need it or not. I know, this is a recursive discussion, but I wonder if old LIRs can ask for more IPs or they are restricted as new LIRs are. For all people who are going to say "Move to IPv6" I already did it. About 75% of my network is IPv6 ready. 100% of our backbone network is IPv6 but, as all of you can see, only 18% of the World ASes are IPv6 ( http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_APNIC;s=_RIR_AfriNIC;s=_RIR_ARIN;s=... ) and IPv6 wont work for anybody if the rest of the world isnt IPv6 ready. To be honest, I think IPv6 will not be ready before lot of us (new lirs)run out of IPv4 address while old LIRs have thousands and thousands of unused IP address and they sell them for really expensive price. I saw one in the listing service asking for at least 2 digits per IP... 2 digits! for something they got for free in the past. Again, I know, IPv4 is exhausted but this cant be used for making lot and fast money from new LIRs that only have /22 allocation and need more. I wonder if a change proposal of the policy to allow to ask for more IPs, of course proving the use of the ones you already have, and only giving /24's would be accepted by the community or I will get flamed for making the proposal. Please, feel free to discuss about this if you are going to say something usefull. PS: Sorry about my english, if I didnt explained well about something, just tell me. I will not feel offended. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel, Welcome to the AP-WG list ;-)
The /22 allocation restriction to new LIRs are only for new LIRs or for all LIRs? We only got a /22 as new LIR, and we cant ask for more IPs, proving we need it or not. I know, this is a recursive discussion, but I wonder if old LIRs can ask for more IPs or they are restricted as new LIRs are.
The policy is that every LIR has the right for 1 final /22 from the 'final /8 pool' .. to be exact and copy the policy: http://www.ripe.net/ripe/docs/ripe-606#5 <quote> On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: The size of the allocation made will be exactly one /22. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). The LIR must confirm it will make assignment(s) from the allocation. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request. </end quote> That means that every old AND new LIR can get upto a single /22 worth in IP address or 1024 IP addresses. These IP addresses come from the 185.x.y.z range. Your LIR has been activated at : 2013-06-24, which is well after the IPv4 depletion date, and as such you fall in the group of LIR's that didn't had any IP space before the final /8 policy came active. So the only IPv4 you can request (from RIPE) is the /22 IPv4. You can however contact an IP broker if you require more IP space and ask them if they have customers who want to sell you their rights of use of PA space or the ownership of their ERX space.
Again, I know, IPv4 is exhausted but this can't be used for making lot and fast money from new LIRs that only have /22 allocation and need more.
I wonder if a change proposal of the policy to allow to ask for more IPs, of course proving the use of the ones you already have, and only giving /24's would be accepted by the community or I will get flamed for making the proposal.
Please, feel free to discuss about this if you are going to say something usefull.
Ah the discussion of those who have and those who haven't got any ... Remember that the policy that we work with currently is designed to allow for future LIR's to be able to have at least some IP space .. versus no IP space. By allowing more IP space to be handed out, someone in the future might think that it was unfair that the policy was changed and now they won't have any IP space to request at RIPE if RIPE runs out faster in the 'final /8 pool'. The current LIR's won't give back any IP addresses.. nor will a policy that might suggest such, ever get through (is my guess) ... On the suggestion to require to need to proof that you already use the IP's that you have ... ehh.. we just got rid of that type of text in the old policy documents as it was no longer required as there is a simple policy.. you can have 1 /22 ... if you are a LIR, you can request a final /22 from the 185.x.y.z range.. and that's it.. No documents needed anymore, no need to proof anything.. I hope this helps. Regards, Erik Bais
Hi Daniel,
First of all, my name is Daniel and Im the Network Administrator of the AS199952
Im new to the address policy wg and Im sure you can answer the question.
The /22 allocation restriction to new LIRs are only for new LIRs or for all LIRs? We only got a /22 as new LIR, and we cant ask for more IPs, proving we need it or not. I know, this is a recursive discussion, but I wonder if old LIRs can ask for more IPs or they are restricted as new LIRs are.
Since the runout (September 2012) every LIR, both existing and new, can get one (and only one) /22.
For all people who are going to say "Move to IPv6" I already did it. About 75% of my network is IPv6 ready. 100% of our backbone network is IPv6 but, as all of you can see, only 18% of the World ASes are IPv6 ( http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_APNIC;s=_RIR_AfriNIC;s=_RIR_ARIN;s=... ) and IPv6 wont work for anybody if the rest of the world isnt IPv6 ready.
Great to hear about your IPv6 deployment. And yes: we need to push the rest of the world as well.
To be honest, I think IPv6 will not be ready before lot of us (new lirs)run out of IPv4 address while old LIRs have thousands and thousands of unused IP address and they sell them for really expensive price. I saw one in the listing service asking for at least 2 digits per IP... 2 digits! for something they got for free in the past.
Again, I know, IPv4 is exhausted but this cant be used for making lot and fast money from new LIRs that only have /22 allocation and need more.
I wonder if a change proposal of the policy to allow to ask for more IPs, of course proving the use of the ones you already have, and only giving /24's would be accepted by the community or I will get flamed for making the proposal.
No, nobody gets flamed for making proposals here! :) The reason it is currently not possible to request more is that if that was possible then existing LIRs would use up the remaining addresses in a couple of months (at the most), and after that new LIRs would get 0 IPv4 address instead of the /22 they get today. So please think about the consequences before making that proposal :)
Please, feel free to discuss about this if you are going to say something usefull.
PS: Sorry about my english, if I didnt explained well about something, just tell me. I will not feel offended.
Your English is fine :) Most of the people on this list aren't native English speakers anyway. Cheers, Sander
Hi all, Thanks for your answers. I know and its ok the currect policy, but everybody should be ok too with what I said. Marco Schmidt, Policy Development Officer, have been in touch with me and told me to see this: http://www.apnic.net/policy/proposals/prop-105 http://www.apnic.net/__data/assets/text_file/0006/62763/prop-105-v002.txt In our region we have a similar situation. The reserved pool is growing over the last months (yellow part) http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-poo... Should we do a proposal like the APNIC's one? If yes, I would at least set conditions for recieving a new block, and setting the minimun allocation to /24 instead of /22. What do you think? Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Wed, Apr 09, 2014 at 06:39:51PM +0200, Dpto. Datos Television Costa Blanca wrote:
I know and its ok the currect policy, but everybody should be ok too with what I said. Marco Schmidt, Policy Development Officer, have been in touch with me and told me to see this: http://www.apnic.net/policy/proposals/prop-105 http://www.apnic.net/__data/assets/text_file/0006/62763/prop-105-v002.txt
Well, different regions are different, and this hasn't reached consensus in APNIC region yet. We've consciously decided that our last-/8 policy is a "no return" policy, to ensure new entrants in the market can still have *some* IPv4, even if they come in 5 years or 10 years time from now. If you think you can convince the community that we should now go and change it back, well, this is what the policy development process is for - but I don't think the chances are good. Of course everyone wants more IPv4 addresses, but nobody wants anyone *else* to take away those last bits from him... [..]
Should we do a proposal like the APNIC's one? If yes, I would at least set conditions for recieving a new block, and setting the minimun allocation to /24 instead of /22.
I know at least one community member who would violently object to the RIPE NCC hand out /24 allocations, because that would be fairly bad for the global routing table. This time, I would actually agree with him. Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, El 09/04/2014 20:15, Gert Doering escribió:
Hi,
On Wed, Apr 09, 2014 at 06:39:51PM +0200, Dpto. Datos Television Costa Blanca wrote:
I know and its ok the currect policy, but everybody should be ok too with what I said. Marco Schmidt, Policy Development Officer, have been in touch with me and told me to see this: http://www.apnic.net/policy/proposals/prop-105 http://www.apnic.net/__data/assets/text_file/0006/62763/prop-105-v002.txt Well, different regions are different, and this hasn't reached consensus in APNIC region yet.
We've consciously decided that our last-/8 policy is a "no return" policy, to ensure new entrants in the market can still have *some* IPv4, even if they come in 5 years or 10 years time from now.
If you think you can convince the community that we should now go and change it back, well, this is what the policy development process is for - but I don't think the chances are good. Of course everyone wants more IPv4 addresses, but nobody wants anyone *else* to take away those last bits from him...
OK to the last /8 policy. As I said, all the reasons are right. Now im talking about a new policy for the growing reserved pool when it reach a first defined quantity.
Should we do a proposal like the APNIC's one? If yes, I would at least set conditions for recieving a new block, and setting the minimun allocation to /24 instead of /22. I know at least one community member who would violently object to the RIPE NCC hand out /24 allocations, because that would be fairly bad for
[..] the global routing table. This time, I would actually agree with him.
If we make a proposal like the APNIC one, I and probably the rest of the LIRs, dont want to exhaust the reserved pool giving /22 to everybody even if the only need a /23 or /24. The problem of the actual IPv4 exhaustion was that. Giving big blocks where a little one would work. If the proposal goes well, then we can discuss what is better, big global routing tables or fulminate the reserved pool again and new LIRs will have again the actual problem. Again, i'd love to stop using IPv4. But be realistic, IPv6 isnt really deployed. Now, when a newly created LIR request an IPv4 allocation, first need to request a IPv6 allocation, but is not needed to use it or have it at least in the backbone network of the LIR. Im not asking for having IPv6 enabled on all your network, at least on the backbone. New LIRs have /32 IPv6 allocation and they are not really using it. What is the good way to force LIRs to start using IPv6? I dont know but Im sure with the work of this list/group we can have a solution. Of course, another big problem for the IPv6 are the client side cpe/computer... Kind Regards, PS: Please, remember I'm not english native and some words can be rude. Is not my purpose to be rude, so accept my apoligies. -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Thu, Apr 10, 2014 at 11:46:26AM +0200, Dpto. Datos Television Costa Blanca wrote:
The problem of the actual IPv4 exhaustion was that. Giving big blocks where a little one would work.
No :-) - the problem of IPv4 exhaustion is that there are more people living on earth than we have IPv4 addresses. Doing "more efficient" allocations would have put more load on the routing system (because you'd have many more small chunks for those ISPs that have grown over time), and you'd *still* run into IPv4 exhaustion. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, El 10/04/2014 11:50, Gert Doering escribió:
Hi,
On Thu, Apr 10, 2014 at 11:46:26AM +0200, Dpto. Datos Television Costa Blanca wrote:
The problem of the actual IPv4 exhaustion was that. Giving big blocks where a little one would work. No :-) - the problem of IPv4 exhaustion is that there are more people living on earth than we have IPv4 addresses.
Doing "more efficient" allocations would have put more load on the routing system (because you'd have many more small chunks for those ISPs that have grown over time), and you'd *still* run into IPv4 exhaustion. But instead of running into exhaustion in "2 months" we can handle it to be "2 years". Please, take in account the time between quotes as an example. Should we take more care in "efficient allocations" or "efficient routing tables"? Are in the actually routers with problems in the routings tables in the same way we have problems with the IPv4 exhaustion?
Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
2014-04-10 12:02 GMT+02:00 Dpto. Datos Television Costa Blanca < datos@tvt-datos.es>:
Hi,
Hello!
But instead of running into exhaustion in "2 months" we can handle it to be "2 years". Please, take in account the time between quotes as an example.
When this was discussed, it was essentially agreed on that it was pretty much irrelevant whether it was N days, weeks, months or years, for any value of N.
Should we take more care in "efficient allocations" or "efficient routing tables"?
Are in the actually routers with problems in the routings tables in the
same way we have problems with the IPv4 exhaustion?
There may be routers with such problems, but AFAICR, routing table lookups for IPv4 hasn't really been a big issue in quite a few years. However, maintaining more allocations just to delay the inevitable by a very small amount of time seems a waste of humans' time and resources. -- Jan
Hi,
But instead of running into exhaustion in "2 months" we can handle it to be "2 years". Please, take in account the time between quotes as an example.
An example, perhaps, but a wildly unlikely one if I understand¹ your proposal correctly. The LIRs in the RIPE region have over the last 18 month gathered up a large unmet demand. Therefore I expect that if we do create a new small pool for "normal" allocations, it will be gone pretty much overnight. It'll be like a lottery, just like when a radio host announces «we've got N free X for the first Y people to call us». I do not believe this would be useful to the community. [1] To 1) leave the "last /8 policy" as it currently is (1 /22 per LIR) for 185.0.0.0/8 only, and 2) allocate according to demonstrated need for all other addresses that somehow finds their way into the RIPE NCC's allocation pool (such as returned/reclaimed from LIRs, delegated from the IANA Recovered IPv4 Pool, and so forth). This new pool would have a minimum allocation size of /24 and no maximum size. Have I understood correctly? Tore
Hi,
But instead of running into exhaustion in "2 months" we can handle it to be "2 years". Please, take in account the time between quotes as an example. An example, perhaps, but a wildly unlikely one if I understand¹ your proposal correctly. The LIRs in the RIPE region have over the last 18 month gathered up a large unmet demand. Therefore I expect that if we do create a new small pool for "normal" allocations, it will be gone pretty much overnight. It'll be like a lottery, just like when a radio host announces «we've got N free X for the first Y people to call us». I do not believe this would be useful to the community.
[1] To 1) leave the "last /8 policy" as it currently is (1 /22 per LIR) for 185.0.0.0/8 only, and 2) allocate according to demonstrated need for all other addresses that somehow finds their way into the RIPE NCC's allocation pool (such as returned/reclaimed from LIRs, delegated from the IANA Recovered IPv4 Pool, and so forth). This new pool would have a minimum allocation size of /24 and no maximum size. Have I understood correctly? I would be against a policy proposal in this form. It would unequal to
Hi, On 10/04/14 13:13, Tore Anderson wrote: the members and would create more hassle for everyone (introducing the need based justification again, after we have just removed it...that would be the worst idea) Considering the size of the available and reserved pool, and noticing that it's mostly going up and not down, I would, support a policy proposal that would change the /22 in a /21 (for example). All members that already received a /22 could receive a second one, all members that have not requested a /22 from the last /8, could request a /21.
Tore
cheers, elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.
But instead of running into exhaustion in "2 months" we can handle it to be "2 years". Please, take in account the time between quotes as an example. An example, perhaps, but a wildly unlikely one if I understand¹ your proposal correctly. The LIRs in the RIPE region have over the last 18 month gathered up a large unmet demand. Therefore I expect that if we do create a new small pool for "normal" allocations, it will be gone pretty much overnight. It'll be like a lottery, just like when a radio host announces «we've got N free X for the first Y people to call us». I do not believe this would be useful to the community.
[1] To 1) leave the "last /8 policy" as it currently is (1 /22 per LIR) for 185.0.0.0/8 only, and 2) allocate according to demonstrated need for all other addresses that somehow finds their way into the RIPE NCC's allocation pool (such as returned/reclaimed from LIRs, delegated from the IANA Recovered IPv4 Pool, and so forth). This new pool would have a minimum allocation size of /24 and no maximum size. Have I understood correctly? I would be against a policy proposal in this form. It would unequal to the members and would create more hassle for everyone (introducing the need based justification again, after we have just removed it...that would be the worst idea) Isnt unequal right now? Are you saying is equal LIRs with thousands and
Good morning all, thousands of IP address when there are LIRs with only a /22? Is equal that the LIRs with thousands can make lot of money from LIRs with only a /22? Its so hard to prove you need more IPs?
Considering the size of the available and reserved pool, and noticing that it's mostly going up and not down, I would, support a policy proposal that would change the /22 in a /21 (for example). All members that already received a /22 could receive a second one, all members that have not requested a /22 from the last /8, could request a /21.
Thats could be a possibility, but again giving IP space to all the ones ask for it, in my honest opinion, will produce the same problem we have now. New LIRs will run out while old and big LIRs will make money selling IPs to little new LIRs. El 10/04/2014 13:30, Gert Doering escribió:
True. But will it change anything? We knew that we'd run out of IPv4 at least 10 years ago, and we've made lots of noise to push people towards IPv6 - and it only started for real when IPv4 had run out.
Yes it will. At least I think so. Im not saying to give more space to everyone. Please consider isnt the same LIRs with thousands and thousands of IP space and LIRs with only a /22 Without the possibility, even in the future, of giving more IP space to little new LIRs you are dooming them.
So if we had made it "last longer", then the "IPv6 for real" deployment in the large ISPs would have started later - and the installed basis of IPv4-using gear would have been much larger, so the migration would have been*more* work...
Sorry, didnt understood you. My english isnt so good. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
* Dpto. Datos Television Costa Blanca
Isnt unequal right now? Are you saying is equal LIRs with thousands and thousands of IP address when there are LIRs with only a /22? Is equal that the LIRs with thousands can make lot of money from LIRs with only a /22?
Depends on how you look at it. It is unequal in the sense that everyone doesn't have an equal amount. It is on the other hand equal in the sense that everyone had an equal opportunity to apply for IP addresses at any given time. In any case, it is what it is. There is no point crying over spilt milk.
Its so hard to prove you need more IPs?
That's not the problem with your proposal, the problem is to conjure up the IPv4 addresses required to fulfill the proven need of all the LIRs in the region, existing and future. The addresses simply do not exist, and no amount of policy proposals can change that.
Thats could be a possibility, but again giving IP space to all the ones ask for it, in my honest opinion, will produce the same problem we have now.
But isn't this exactly what you are proposing to do - let everyone ask for more IPv4 addresses according to whatever they need?
Im not saying to give more space to everyone. Please consider isnt the same LIRs with thousands and thousands of IP space and LIRs with only a /22
So are you saying that only LIRs that are holding a /22 (or less) will be allowed to request more space, under your proposed new policy? In other words, an LIR that holds, say, a /21, will not be eligible to apply? Or one that held a /22, and then requested and received a /24 from your new pool, will this LIR that now holds a /22 + a /24 be able to request more, or not?
Without the possibility, even in the future, of giving more IP space to little new LIRs you are dooming them.
It's IPv4 that is doomed, and that goes equally for old LIRs as well as new LIRs. I'm sure the community would enthusiastically give more IPv4 space to little new LIRs if that space existed, but it doesn't, and so it is impossible to give it. There is simply no good option available to us: 1) If you open up for requests that are bounded upwards only by demonstrated need, then that pool will be gone pretty much instantaneously, even if you limit its eligibility to new LIRs only. Except for a few luck "lottery winners", nobody will benefit. 2) If you only change the upper limit slightly, say from a /22 to a /21, then you haven't solved anything; the LIRs will still be unable to get the amount of space they actually need. It sucks to not have enough IPv4 space. I'm in that situation, myself. But there is unfortunately no way we can solve IPv4 depletion in this forum. Tore
El 11/04/2014 11:23, Tore Anderson escribió:
* Dpto. Datos Television Costa Blanca
Isnt unequal right now? Are you saying is equal LIRs with thousands and thousands of IP address when there are LIRs with only a /22? Is equal that the LIRs with thousands can make lot of money from LIRs with only a /22? Depends on how you look at it. It is unequal in the sense that everyone doesn't have an equal amount. It is on the other hand equal in the sense that everyone had an equal opportunity to apply for IP addresses at any given time. In any case, it is what it is. There is no point crying over spilt milk.
Its so hard to prove you need more IPs? That's not the problem with your proposal, the problem is to conjure up the IPv4 addresses required to fulfill the proven need of all the LIRs in the region, existing and future. The addresses simply do not exist, and no amount of policy proposals can change that.
Lets think the reserved pool grows enought. Lets say reserved pool gets arround a /10. There should be a policy that says: [...] When the reserved pool reachs the number of "N" millions of IP [...] a LIR that prove they need the space, will recieve a /X space
Thats could be a possibility, but again giving IP space to all the ones ask for it, in my honest opinion, will produce the same problem we have now. But isn't this exactly what you are proposing to do - let everyone ask for more IPv4 addresses according to whatever they need?
Im not saying to give more space to everyone. Please consider isnt the same LIRs with thousands and thousands of IP space and LIRs with only a /22 So are you saying that only LIRs that are holding a /22 (or less) will be allowed to request more space, under your proposed new policy?
In other words, an LIR that holds, say, a /21, will not be eligible to apply? Or one that held a /22, and then requested and received a /24 from your new pool, will this LIR that now holds a /22 + a /24 be able to request more, or not? Sorry, didnt mean that. Remember my english isnt really well, im doing my best to say what I want to say, but sometimes its hard. There should be a limit. Not all LIRs need space really.
Without the possibility, even in the future, of giving more IP space to little new LIRs you are dooming them. It's IPv4 that is doomed, and that goes equally for old LIRs as well as new LIRs. I'm sure the community would enthusiastically give more IPv4 space to little new LIRs if that space existed, but it doesn't, and so it is impossible to give it. There is simply no good option available to us: No its not equals. You have mooooooore game with 1 millions address than 1 thousand address.
1) If you open up for requests that are bounded upwards only by demonstrated need, then that pool will be gone pretty much instantaneously, even if you limit its eligibility to new LIRs only. Except for a few luck "lottery winners", nobody will benefit.
2) If you only change the upper limit slightly, say from a /22 to a /21, then you haven't solved anything; the LIRs will still be unable to get the amount of space they actually need.
It sucks to not have enough IPv4 space. I'm in that situation, myself. But there is unfortunately no way we can solve IPv4 depletion in this forum. In general terms, what I mean is. Lets give the chance not only to new LIRs but everyone to get more IP space, IF THEY REALLY PROVE the need. I didnt say anything about minimum or maximum allocation, and if I said something that mean that, sorry. I also said to change minimum allocation from /22 to something little, for not exhausting the reserved pool in "2 days" but seems to not be the right decision due to the routing table grow.
Of course, Im always talking about the reserved pool, not about the last 185/8 pool. Im really new to LIR and to this mailing list. For that im writting here to read all of you, your experiences and your opinion, and then if possible, do something. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel, Playing devil's advocate a bit.
Lets think the reserved pool grows enought. Lets say reserved pool gets arround a /10. There should be a policy that says: [...] When the reserved pool reachs the number of "N" millions of IP [...] a LIR that prove they need the space, will recieve a /X space
[...]
In general terms, what I mean is. Lets give the chance not only to new LIRs but everyone to get more IP space, IF THEY REALLY PROVE the need. I didnt say anything about minimum or maximum allocation, and if I said something that mean that, sorry. I also said to change minimum allocation from /22 to something little, for not exhausting the reserved pool in "2 days" but seems to not be the right decision due to the routing table grow.
I am looking at some research on RIPE labs: https://labs.ripe.net/Members/kistel/content-ipv4-address-allocation-rates, and especially this graph: https://labs.ripe.net/Members/kistel/images/userfiles-image-rir-speeds-20100.... It only goes up to 2010, but the trend of allocating 0.2 of a /8 per month seems to be stable over many years. And in those days there already was a strong need-based policy, so all that address space was really needed. You suggest to let the reserved pool grow to a /10. That would probably take quite a long time (it has been growing now for 1,5 years and we haven't reached a /10 yet). A /10 is only 0.25 of a /8. If the trend would continue it would mean that in between 1 and 2 months the /10 would be used up. So, if we allocate addresses like we used to then we would wait (let's say) 2 years, followed by 1 or 2 months of allocating addresses, then waiting 2 years again etc. And this assumes the allocation rate of the period when there was no rush. In the current situation people would know that they only have a tiny window of opportunity. I therefore suspect that the /10 would be gone in less than a week. Some people get lucky and have a larger number of IPv4 addresses, while the rest of the market would not get anything. This feels a bit like a lottery, and the economic imbalance created by it might be significant. So to make something like this work you would need a different policy. Some things you can think about: - stronger need required (but in a shortage situation there is lots of need) - maximum allocation sizes (which means people get a bit more, but still less than they need) This is difficult to get right. Try playing several scenarios in your mind, trying to look at the allocation speed, the potential loopholes to game the system, the resulting economic balance etc.
Of course, Im always talking about the reserved pool, not about the last 185/8 pool.
Ack
Im really new to LIR and to this mailing list. For that im writting here to read all of you, your experiences and your opinion, and then if possible, do something.
Very much appreciated! This is however a topic that has been thoroughly discussed in the past, and we know how difficult it is to make good policy considering the IPv4 runout. The current final /8 policy is the best this working group has come up with. While lots of people would be very happy if they were able to get more IPv4 addresses it will be difficult to make that happen in a fair and useful way. But it is always good to look at alternatives every once in a while. Thank you for that! Sander
Hi Sander, El 11/04/2014 13:44, Sander Steffann escribió:
So to make something like this work you would need a different policy. Some things you can think about: - stronger need required (but in a shortage situation there is lots of need) - maximum allocation sizes (which means people get a bit more, but still less than they need) When I said nothing to min/max allocs I didnt mean no max/min alloc. I just didnt get to that part. Im starting at the beggning.
This is difficult to get right. Try playing several scenarios in your mind, trying to look at the allocation speed, the potential loopholes to game the system, the resulting economic balance etc. I tried, its hard, and is the main reason Im here. I could make the
What I am talking right now is - Is it a potential proposal to use the reserved pool, when reaching a N (N is not defined yet) millions IPs, to give allocations of /X (X isnt defined yet too) to those LIRs that have the requirements (Requirements arent defined yet)? If it is, then we can start talking about N, X, Requirements and so. proposal alone, but that would have 99.99^(period)% of being a failed proposal.
Very much appreciated! This is however a topic that has been thoroughly discussed in the past, and we know how difficult it is to make good policy considering the IPv4 runout. The current final /8 policy is the best this working group has come up with. While lots of people would be very happy if they were able to get more IPv4 addresses it will be difficult to make that happen in a fair and useful way. Hard doesnt mean impossible. Thats the way i think. When was proposed the final /8 policy? Lets say 2011. What thought this group about how IPv6 would be in 2014? (dont know if I said it well) But it is always good to look at alternatives every once in a while. Thank you for that! Thank you!
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
As a general point, I don't support micromanaging and squeezing IPv4 to the nth degree, be it company or RIR level, only because it inhibits the overall development of IPv6. We know the sustainable growth of the internet, and internet companies, relies on the adoption of IPv6. Of course certain budget/resource restrictions may slow some companies/networks from launching v6, for which time they may indeed require some additional v4 space. But constantly managing v4 in an ambiguous state is more costly, not just in the long run. Harvesting v4 should be seen as a stopgap, a temporary workaround. We, as a community, should concentrate our efforts on enhancing and encouraging the deployment of IPv6. Rgds, James -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Sander Steffann Sent: 11 April 2014 13:44 To: Dpto. Datos Television Costa Blanca Cc: Tore Anderson; address-policy-wg@ripe.net Working Group Subject: Re: [address-policy-wg] About the /22 allocation limitation Hi Daniel, Playing devil's advocate a bit.
Lets think the reserved pool grows enought. Lets say reserved pool gets arround a /10. There should be a policy that says: [...] When the reserved pool reachs the number of "N" millions of IP [...] a LIR that prove they need the space, will recieve a /X space
[...]
In general terms, what I mean is. Lets give the chance not only to new LIRs but everyone to get more IP space, IF THEY REALLY PROVE the need. I didnt say anything about minimum or maximum allocation, and if I said something that mean that, sorry. I also said to change minimum allocation from /22 to something little, for not exhausting the reserved pool in "2 days" but seems to not be the right decision due to the routing table grow.
I am looking at some research on RIPE labs: https://labs.ripe.net/Members/kistel/content-ipv4-address-allocation-rates, and especially this graph: https://labs.ripe.net/Members/kistel/images/userfiles-image-rir-speeds-20100.... It only goes up to 2010, but the trend of allocating 0.2 of a /8 per month seems to be stable over many years. And in those days there already was a strong need-based policy, so all that address space was really needed. You suggest to let the reserved pool grow to a /10. That would probably take quite a long time (it has been growing now for 1,5 years and we haven't reached a /10 yet). A /10 is only 0.25 of a /8. If the trend would continue it would mean that in between 1 and 2 months the /10 would be used up. So, if we allocate addresses like we used to then we would wait (let's say) 2 years, followed by 1 or 2 months of allocating addresses, then waiting 2 years again etc. And this assumes the allocation rate of the period when there was no rush. In the current situation people would know that they only have a tiny window of opportunity. I therefore suspect that the /10 would be gone in less than a week. Some people get lucky and have a larger number of IPv4 addresses, while the rest of the market would not get anything. This feels a bit like a lottery, and the economic imbalance created by it might be significant. So to make something like this work you would need a different policy. Some things you can think about: - stronger need required (but in a shortage situation there is lots of need) - maximum allocation sizes (which means people get a bit more, but still less than they need) This is difficult to get right. Try playing several scenarios in your mind, trying to look at the allocation speed, the potential loopholes to game the system, the resulting economic balance etc.
Of course, Im always talking about the reserved pool, not about the last 185/8 pool.
Ack
Im really new to LIR and to this mailing list. For that im writting here to read all of you, your experiences and your opinion, and then if possible, do something.
Very much appreciated! This is however a topic that has been thoroughly discussed in the past, and we know how difficult it is to make good policy considering the IPv4 runout. The current final /8 policy is the best this working group has come up with. While lots of people would be very happy if they were able to get more IPv4 addresses it will be difficult to make that happen in a fair and useful way. But it is always good to look at alternatives every once in a while. Thank you for that! Sander
* Dpto. Datos Television Costa Blanca
Lets think the reserved pool grows enought. Lets say reserved pool gets arround a /10.
In likelihood this will happen really soon, when the IANA Recovered IPv4 Pool is activated the RIPE NCC will receive (at least) 3.83M addresses, which is enough to make the total non-185/8 space held by the NCC to exceed a /10. I doubt that subsequent allocations from the IANA Recovered IPv4 Pool will be of the same scale, though. Except for this exceptional one-time event, I expect that the NCC's total pool (returned/reserved + 185/8) will gradually diminish, but last for several years before emptying completely. Which is what we wanted to accomplish in the first place.
There should be a policy that says: [...] When the reserved pool reachs the number of "N" millions of IP [...] a LIR that prove they need the space, will recieve a /X space
[...]
I didnt say anything about minimum or maximum allocation, and if I said something that mean that, sorry.
What do you mean by «a /X», if it isn't a maximum allocation limit?
Lets give the chance not only to new LIRs but everyone to get more IP space, IF THEY REALLY PROVE the need.
Let's say that we do make a new "reserved" pool that gets activated for allocation when it contains a /10, as you suggest over. I can easily think of a dozen LIRs in the RIPE region who in all likelihood have absolutely no problems at all to "REALLY PROVE" that they need that entire /10 (and more). After all, they've had over 18 months to gather up all that unmet need. So how do you solve determining who actually will get anything from the pool? First come, first serve? Random draw? Something else entirely?
It's IPv4 that is doomed, and that goes equally for old LIRs as well as new LIRs. I'm sure the community would enthusiastically give more IPv4 space to little new LIRs if that space existed, but it doesn't, and so it is impossible to give it. There is simply no good option available to us: No its not equals. You have mooooooore game with 1 millions address than 1 thousand address.
Not necessarily. If that LIR has already delegated all of those 1M addresses on to its End Users, then that LIR has 0 addresses available for new deployments. Just like a newly-formed LIR with no allocations. Both are stuck, with no way to grow their businesses. You could even argue that the new LIR might have somewhat of a competitive advantage over the old one when it comes to further growth. They will both get a final /22, but the old LIR will probably have IPv4 inertia and find it difficult to adjust their business model and infrastructure from a situation where IPv4 was plentiful to one where it is scarce; while the new LIR might be working with a green-field deployment and have a much better chance to build its infrastructure in a way that does not rely too much on IPv4, and thus be able to make much better use of the /22 than the old LIR can. Tore
On Fri, Apr 11, 2014 at 10:19 AM, Dpto. Datos Television Costa Blanca < datos@tvt-datos.es> wrote:
Good morning all,
Good morning. :)
El 10/04/2014 13:30, Gert Doering escribió:
True. But will it change anything? We knew that we'd run out of IPv4 at least 10 years ago, and we've made lots of noise to push people towards IPv6 - and it only started for real when IPv4 had run out.
Yes it will. At least I think so. Im not saying to give more space to everyone. Please consider isnt the same LIRs with thousands and thousands of IP space and LIRs with only a /22 Without the possibility, even in the future, of giving more IP space to little new LIRs you are dooming them.
In terms of IPv4, the little new LIRs have been doomed for a long, long time. This is nothing new. -- Jan
Hi, On Fri, Apr 11, 2014 at 11:24:51AM +0200, Jan Ingvoldstad wrote:
In terms of IPv4, the little new LIRs have been doomed for a long, long time.
Actually this very much depends on what the little new LIRs are trying to do. - setup a web hosting shop for a few high profile customers? works. - setup a medium-sized access ISP that gives public IPv4 addresses to all customers? fail - setup a medium-sized access ISP that gives IPv6 and NATted IPv4 addresses to customers, using the /22 for the public side of the NAT64 and CGN NAT? -> works! (well, depending on how large "medium-sized" is) - setup a mass-market web hosting shop with public IPv4 addresses for each of a million customers? fail Insofar, I consider our "last /8 policy" to be a success - without that policy, the pool would be fully empty today, and of the cases above, all four would be "fail!". The intention of the policy is to be able to give every LIR a small amount of IPv4 "for the foreseeable future", to ensure that at least some business cases can still be met. If you want to start a business today that needs "large amounts of IPv4 space", put the costs for that into your business plan and see whether it's still viable - business 101, nothing special to see here. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
On 11.04.14 13:37, Dpto. Datos Television Costa Blanca wrote: On 11.04.14 11:19, Dpto. Datos Television Costa Blanca wrote:
Isnt unequal right now? Are you saying is equal LIRs with thousands and thousands of IP address when there are LIRs with only a /22? Is equal that the LIRs with thousands can make lot of money from LIRs with only a /22? I think this depends of how you define equality. Is equality just comparing the number of addresses or IP addresses relative to customers or even pr capita of the market the LIR operates in.
Its so hard to prove you need more IPs?
When I was new in this game I had to supply receipts of equipment to prove I was building a network. That was hard facts. But a customer prognosis based on historical growth or marketing plans was not accepted by the community. So I would say - yes its hard - and we have not been able to come up with a good criteria yet. On 11.04.14 13:37, Dpto. Datos Television Costa Blanca wrote:
No its not equals. You have mooooooore game with 1 millions address than 1 thousand address.
If the LIR with 1million IP addresses has 4 million customer it has a bigger challenge than the one with 1 thousand addresses if that LIR only has 1000 customers. -- Hans Petter Holen Mobile +47 45 06 60 54 | hph@oslo.net | http://hph.oslo.net
On 11.04.14 13:37, Dpto. Datos Television Costa Blanca wrote:
On 11.04.14 11:19, Dpto. Datos Television Costa Blanca wrote:
Isnt unequal right now? Are you saying is equal LIRs with thousands and thousands of IP address when there are LIRs with only a /22? Is equal that the LIRs with thousands can make lot of money from LIRs with only a /22? I think this depends of how you define equality. Is equality just comparing the number of addresses or IP addresses relative to customers or even pr capita of the market the LIR operates in. I give you half a point here. You cant ask for IPs for a per capita of
Hi Hans, El 14/04/2014 13:52, Hans Petter Holen escribió: the market the LIR operates in. Its unequal in the way a LIR have millions of unused IPs what dont return to RIPE just for selling and a new LIR who is growing up and need more than the /22 they have.
Its so hard to prove you need more IPs?
When I was new in this game I had to supply receipts of equipment to prove I was building a network. That was hard facts. But a customer prognosis based on historical growth or marketing plans was not accepted by the community. So I would say - yes its hard - and we have not been able to come up with a good criteria yet.
Maybe, if all this finish in a proposal, we should discuss how to prove you need it.
On 11.04.14 13:37, Dpto. Datos Television Costa Blanca wrote:
No its not equals. You have mooooooore game with 1 millions address than 1 thousand address.
If the LIR with 1million IP addresses has 4 million customer it has a bigger challenge than the one with 1 thousand addresses if that LIR only has 1000 customers.
Sure its a bigger challenge. But its biggest when you have 1k address and 4k customers. You know, concurrence % is better when you have more clients. Your example is not good because you dont set same terms. a LIR with 1M address and 1M customers have more game than a LIR with 1k address and 1k clients. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Thu, Apr 10, 2014 at 12:02:27PM +0200, Dpto. Datos Television Costa Blanca wrote:
Doing "more efficient" allocations would have put more load on the routing system (because you'd have many more small chunks for those ISPs that have grown over time), and you'd *still* run into IPv4 exhaustion. But instead of running into exhaustion in "2 months" we can handle it to be "2 years". Please, take in account the time between quotes as an example.
True. But will it change anything? We knew that we'd run out of IPv4 at least 10 years ago, and we've made lots of noise to push people towards IPv6 - and it only started for real when IPv4 had run out. So if we had made it "last longer", then the "IPv6 for real" deployment in the large ISPs would have started later - and the installed basis of IPv4-using gear would have been much larger, so the migration would have been *more* work...
Should we take more care in "efficient allocations" or "efficient routing tables"? Are in the actually routers with problems in the routings tables in the same way we have problems with the IPv4 exhaustion?
Highly so. Depending on which vendor you used, "typical" gear deployed about 5-7 years ago had a hard limit at 256.000 routes - and that came quite close for a number of ISPs. The hardware upgrade to support 1 million routes did cost significant money (like, 10.000-50.000 EUR/router), and it does not truly support "1 million IPv4" routes, if you also have IPv6 and MPLS in your network - more like 700.000 IPv4 routes in typical deployments. Now, before the big discussion starts: there is other gear in the market that scales up to 2 million, etc., but I wanted to point out that these are real-world hard limits, and the amount of "headroom" we have between "what is out there today" (500k) and "what some of the fairly widely deployed core routers can do today" (700k) is not so big that we want to risk an explosion by factor 2. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
deployments. Now, before the big discussion starts: there is other gear in the market that scales up to 2 million, etc., but I wanted to point out that these are real-world hard limits, and the amount of "headroom" we have between "what is out there today" (500k) and "what some of the fairly widely deployed core routers can do today" (700k) is not so big that we want to risk an explosion by factor 2.
Gert Doering — NetMaster
Hi all, New to list contributions but thought I’d simply add a +1 to this. As a network operator that just recently had to make significant changes in our core network to cope with the fact that the routing table is currently circa 500k I would be supportive of any policy that maintains /22 as a minimum. Mick
On Thu, Apr 10, 2014 at 1:30 PM, Gert Doering <gert@space.net> wrote:Highly so. Depending on which vendor you used, "typical" gear deployed
about 5-7 years ago had a hard limit at 256.000 routes - and that came quite close for a number of ISPs. The hardware upgrade to support 1 million routes did cost significant money (like, 10.000-50.000 EUR/router), and it does not truly support "1 million IPv4" routes, if you also have IPv6 and MPLS in your network - more like 700.000 IPv4 routes in typical deployments. Now, before the big discussion starts: there is other gear in the market that scales up to 2 million, etc., but I wanted to point out that these are real-world hard limits, and the amount of "headroom" we have between "what is out there today" (500k) and "what some of the fairly widely deployed core routers can do today" (700k) is not so big that we want to risk an explosion by factor 2.
Ah, that was worse than I thought it was, by far. Thanks for the clarification! -- Jan
On Wed, Apr 9, 2014 at 8:15 PM, Gert Doering <gert@space.net> wrote:
We've consciously decided that our last-/8 policy is a "no return" policy, to ensure new entrants in the market can still have *some* IPv4, even if they come in 5 years or 10 years time from now.
If you think you can convince the community that we should now go and change it back, well, this is what the policy development process is for - but I don't think the chances are good. Of course everyone wants more IPv4 addresses, but nobody wants anyone *else* to take away those last bits from him...
I am a bit late to the game, but I think this is the perfect summary and I would be forced to argue and vote against any policy proposal which wants to change the status quo regarding last /8. Sorry, Richard
Hi, El 15/04/2014 10:07, Richard Hartmann escribió:
On Wed, Apr 9, 2014 at 8:15 PM, Gert Doering <gert@space.net <mailto:gert@space.net>> wrote:
We've consciously decided that our last-/8 policy is a "no return" policy, to ensure new entrants in the market can still have *some* IPv4, even if they come in 5 years or 10 years time from now.
If you think you can convince the community that we should now go and change it back, well, this is what the policy development process is for - but I don't think the chances are good. Of course everyone wants more IPv4 addresses, but nobody wants anyone *else* to take away those last bits from him...
I am a bit late to the game, but I think this is the perfect summary and I would be forced to argue and vote against any policy proposal which wants to change the status quo regarding last /8. Never is late. This started about the last /8 but changed to the reserved pool (the one outside the last /8). We are talking about if we use and how the reserved pool when it reach "X" Millions (Not defined, yet).
Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
I see no substantial difference between last-/8 and the returned almost-/10. It would be used up within days and we are back to where we are today. I would still be against any proposal in this direction. Again, sorry, Richard Sent by mobile; excuse my brevity.
Richard Hartmann wrote:
I see no substantial difference between last-/8 and the returned almost-/10. It would be used up within days and we are back to where we are today.
I would still be against any proposal in this direction.
Same here. It was a conscious decision to *not* go back to whatever different policy after the last/8-mode kicked in. I still think it was, and is, the right decision. Although I'm reiterating stuff that was explained already, the reason for my position is: - the little excess in addresses in the pool would not really last, i.e. make a substantial difference overall, - fiddling around with erratic or short-term provisions would actually lead to less "equality" (for whatever definition) and send the wrong signal to those not yet doing IPv6 (old or new), - thus delaying the deployment of IPv6 even further.
Again, sorry, Richard
Wilfried.
Richard Hartmann wrote:
I see no substantial difference between last-/8 and the returned almost-/10. It would be used up within days and we are back to where we are today.
I would still be against any proposal in this direction. Yes, we will back to where we are today, but will give a respite to
El 15/04/2014 13:58, Wilfried Woeber escribió: those LIRs with only /22
Same here.
It was a conscious decision to *not* go back to whatever different policy after the last/8-mode kicked in. I still think it was, and is, the right decision. Im sure in that moment was the right decision. Even today is a right decision but there are LIRs with only /22 allocations. Have you more than a /22? Are you using IPv6? Are your customers IPv6 enabled? What will you do if you only have a /22?
Before saying NO, please take care of the LIRs that only have a /22 and will never recieve more from RIPE. Only will have more if they buy from the market, and again, they are not cheap.
Although I'm reiterating stuff that was explained already, the reason for my position is:
- the little excess in addresses in the pool would not really last, i.e. make a substantial difference overall,
Maybe not for you, for the LIRs with only a /22 will be substantial
- fiddling around with erratic or short-term provisions would actually lead to less "equality" (for whatever definition) and send the wrong signal to those not yet doing IPv6 (old or new), Im doing IPv6. IPv6 is not doing to me. I cant give a customer IPv6-only access because he will only see 17.5% of the Internet(17.5% is the number of ASN with IPv6, so to be realistic the percentage of IPv6 functioning networks are less). At this moment, all my web/mail/dns servers are IPv6, 25% of my customers have the possibility of connecting with IPv6. ) to let the other 75% of customer network to be IPv6. - thus delaying the deployment of IPv6 even further. True. Then only give IPv4 to those with IPv6 enabled, ready and in use and only have a /22 IPv4 allocation
This is an answer to all who are going to say giving more IPv4 address will delay IPv6 deploy. Yes it will delay but realistic. IPv6 isnt deployed. We are close to 2 years from IPv6 world launch and take a look to the IPv6 stats. http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_APNIC;s=_RIR_AfriNIC;s=_RIR_ARIN;s=... 17.59% of total ASes of the world have an IPv6 prefix announce in the RIS. With this you cant give only IPv6 access. Again, remember im not english native and sometimes I may sound rude, its not my intention. Sorry for that :) Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Tue, Apr 15, 2014 at 05:34:46PM +0200, Dpto. Datos Television Costa Blanca wrote:
Im doing IPv6. IPv6 is not doing to me. I cant give a customer IPv6-only access because he will only see 17.5% of the Internet(17.5% is the number of ASN with IPv6, so to be realistic the percentage of IPv6 functioning networks are less).
IPv6 access with a NAT64 or with ds-lite is what other providers do that do not have enough IPv4 addresses for their customer base. Why do you think that your situation is different from that of the local DSL ISP here in Munich, or the largest cable provider in Germany? You all do not have enough IPv4 addresses for all your customers - and there will never be a way to *have* enough IPv4 addresses for the fast-growing access ISPs, so workarounds need to be found. For access ISPs, the workarounds (NAT64, ds-lite, MAP) are actually not all that bad - for content hosting, it's MUCH worse, as you really can't share a single IPv4 among multiple large content offerings (= not virtual systems hosted on the same server). Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Im sure in that moment was the right decision. Even today is a right decision but there are LIRs with only /22 allocations. Have you more than a /22? Are you using IPv6? Are your customers IPv6 enabled? What will you do if you only have a /22?
Before saying NO, please take care of the LIRs that only have a /22 and will never recieve more from RIPE. Only will have more if they buy from the market, and again, they are not cheap.
I cant give a customer IPv6-only access because he will only see 17.5% of the Internet
Have you considered DS-Lite? A /22 goes a long way in this solution. Also, prior to the depletion of RIPE free IPv4 pools, I'm sure some of the savvy LIRs (not that I condone it) would have stockpiled what v4 they could. Now as their v4 dries up, surely IPv6 announcements will only increase as they move to v6. Creating or rewriting polices to harvest v4, which we all agree would delay v6 taking off, will indefinitely prolong the purgatory for those scraping around for v4 while the v6 adoption is low. Rgds, James -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Dpto. Datos Television Costa Blanca Sent: 15 April 2014 17:35 To: Address Policy Working Group Subject: Re: [address-policy-wg] About the /22 allocation limitation El 15/04/2014 13:58, Wilfried Woeber escribió:
Richard Hartmann wrote:
I see no substantial difference between last-/8 and the returned almost-/10. It would be used up within days and we are back to where we are today.
I would still be against any proposal in this direction. Yes, we will back to where we are today, but will give a respite to those LIRs with only /22 Same here.
It was a conscious decision to *not* go back to whatever different policy after the last/8-mode kicked in. I still think it was, and is, the right decision. Im sure in that moment was the right decision. Even today is a right decision but there are LIRs with only /22 allocations. Have you more than a /22? Are you using IPv6? Are your customers IPv6 enabled? What will you do if you only have a /22?
Before saying NO, please take care of the LIRs that only have a /22 and will never recieve more from RIPE. Only will have more if they buy from the market, and again, they are not cheap.
Although I'm reiterating stuff that was explained already, the reason for my position is:
- the little excess in addresses in the pool would not really last, i.e. make a substantial difference overall,
Maybe not for you, for the LIRs with only a /22 will be substantial
- fiddling around with erratic or short-term provisions would actually lead to less "equality" (for whatever definition) and send the wrong signal to those not yet doing IPv6 (old or new), Im doing IPv6. IPv6 is not doing to me. I cant give a customer IPv6-only access because he will only see 17.5% of the Internet(17.5% is the number of ASN with IPv6, so to be realistic the percentage of IPv6 functioning networks are less). At this moment, all my web/mail/dns servers are IPv6, 25% of my customers have the possibility of connecting with IPv6. ) to let the other 75% of customer network to be IPv6. - thus delaying the deployment of IPv6 even further. True. Then only give IPv4 to those with IPv6 enabled, ready and in use and only have a /22 IPv4 allocation
This is an answer to all who are going to say giving more IPv4 address will delay IPv6 deploy. Yes it will delay but realistic. IPv6 isnt deployed. We are close to 2 years from IPv6 world launch and take a look to the IPv6 stats. http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_APNIC;s=_RIR_AfriNIC;s=_RIR_ARIN;s=... 17.59% of total ASes of the world have an IPv6 prefix announce in the RIS. With this you cant give only IPv6 access. Again, remember im not english native and sometimes I may sound rude, its not my intention. Sorry for that :) Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel,
please take care of the LIRs that only have a /22 and will never recieve more from RIPE.
We'd love to, truly, but I do not see how we can without having an abundance of available addresses to hand out. The math just doesn't work out. There are currently 1849 LIRs that you want us to take care of, i.e., they are holding only a single /22. Considering that almost all of these joined in the last 18 months, I think it is quite safe to assume that the number will be 2500 or more by the time your proposal would be implemented by the NCC, even if it were to pass the PDP in record speed. You have suggested that you do want the proposed new "reserved pool" to have a max allocation size, but have so far not said what it should be. So, for the sake of the argument, I'll make up some possible max allocation sizes below. Also for the sake of the argument I'll make the assumption that the reserved pool is activated when it contains a /10, both because that's a figure you've mentioned earlier, and also because waiting until it contains a /9 will in all likelihood mean it will sit there inactive for years, and that won't help anyone either. First, let's try with a max allocation size of /22. Then there would be 4096 /22s in the pool, enough for all of the LIRs you want us to take care of. But, as I understand you've already noticed, a /22 doesn't last very long at all if you plan to hand out a "whole" address per subscriber (or more). Neither does a /21. So this doesn't really help much; /22 or /21, both are "not enough" - the change would not be worth the trouble. Also, if you consider the current LIR sign-up rate and assume that most of them will want all the IPv4 they can get their hands on while they still can, the entire pool would probably not lat a full year before being completely drained. Another reason why it wouldn't be worth the trouble. So, let's try with a max allocation size of /21 then. The /10 reserved pool would have 2048 /21s. But that is fewer /21s than the number of LIRs that would be eligible for receiving allocations from it. Oops. So with /21 (or greater obviously), we simply do not have enough addresses to take care of all the LIRs you want us to - and helping only a (randomly selected?) subset of them is much worse than helping none, IMHO, as it would create arbitrary inequalities and unfairness. Finally, in any case it would mean that we decide to burn through our remaining resources at the expense of the "future generations" to which those resources are currently earmarked. I do not think that would be wise at all. A proverb we have here in Norway about peeing one's pants in winter to warm up comes to mind... We should try to keep a /22 in reserve for those who decide to enter the business a decade from now too, and by the look of things, we might just succeed in that - IFF we don't fall for the temptation to pass policies such as the one you're proposing. Tore
Hi Tore,
Also for the sake of the argument I'll make the assumption that the reserved pool is activated when it contains a /10, both because that's a figure you've mentioned earlier, and also because waiting until it contains a /9 will in all likelihood mean it will sit there inactive for years, and that won't help anyone either.
First, let's try with a max allocation size of /22. Then there would be 4096 /22s in the pool, enough for all of the LIRs you want us to take care of.
Something about this worries me. I am afraid we will end up with more 'types' of LIRs: - the old ones that could request whatever they needed - the ones that started just before runout who have one /21 and one /22 - the first 4096 that started just after runout who have two /22s - the later ones that have one /22 The first 4096 of last category could potentially get another /22 when/if the pool reaches a /10 again, but as you say this will take years. This doesn't feel right. If we make a policy to give more IPv4 addresses to the LIRs that only have one /22 then it should be: - equal for all of them - sustainable for a long time If we can do this then I don't see a problem, but in order to do this the returned pool has to be able to grow to (almost) a /8 because otherwise we won't be able to give every LIR with one /22 their second /22. And that will create unfairness again... Cheers, Sander
I am still not convinced this is something we should doing. That being said: On Wed, Apr 16, 2014 at 1:06 PM, Sander Steffann <sander@steffann.nl> wrote:
This doesn't feel right. If we make a policy to give more IPv4 addresses to the LIRs that only have one /22 then it should be: - equal for all of them
Arguably, anyone with more than a /22 is in a better position, already. Allowing LIRs with less than one /21 to top up to a /21 and giving everyone else that one last-/8 /22 would be the "most equal" (for some value of). I.e. in times of scarcity, the absolute number, and not relative gains, would come nearest to "fairness" (for some value of). The last /8 could be used for the initial /22, the returned addresses for the second one; optionally with NCC-internal accounting so LIRs can get one single continuous /21. That way, last-/8 would remain in effect.
- sustainable for a long time
Well... no. It would only drag out v6 adoption a little more while admittedly easing the pain of new LIRs. Until they run out again and we restart the same discussion for /20. And if it turns out that we _need_ more than the absolute reserve of IPv4, we will have less wiggle room. Richard
On 16 April 2014 13:13, Richard Hartmann <richih.mailinglist@gmail.com> wrote:
And if it turns out that we _need_ more than the absolute reserve of IPv4, we will have less wiggle room.
How about we just carve out all the existing IPv4 space, hand it out to all LIRs that are extant on the 1st November 2014 and then IPv6 would be the only way forward and people can scramble to get themselves an LIR before the 1st if they really think they are going to need v4 space ever in the future? The world's not fair, networks need to move on.. J ps For the avoidance of doubt "There is a level of British sarcasm hidden in this email" -- James Blessing 07989 039 476
El 16/04/2014 13:06, Sander Steffann escribió: > Hi Tore, > >> Also for the sake of the argument I'll make the assumption that the >> reserved pool is activated when it contains a /10, both because that's a >> figure you've mentioned earlier, and also because waiting until it >> contains a /9 will in all likelihood mean it will sit there inactive for >> years, and that won't help anyone either. >> >> First, let's try with a max allocation size of /22. Then there would be >> 4096 /22s in the pool, enough for all of the LIRs you want us to take >> care of. > Something about this worries me. I am afraid we will end up with more 'types' of LIRs: > - the old ones that could request whatever they needed3 > - the ones that started just before runout who have one /21 and one /22 > - the first 4096 that started just after runout who have two /22s > - the later ones that have one /22 > > The first 4096 of last category could potentially get another /22 when/if the pool reaches a /10 again, but as you say this will take years. Soon we will get address space of around /10 from IANAs returned pool plus the reserved we already have. > This doesn't feel right. If we make a policy to give more IPv4 addresses to the LIRs that only have one /22 then it should be: > - equal for all of them > - sustainable for a long time Sustainable for a long time...this a tricky question. What is "long time"? Are we planning to still working in IPv4 in, lets say, 5-10 years? If yes, and in 5-10 years IPv6 isnt the main internet protocol all we, as LIRs, will have a very big problem. > > If we can do this then I don't see a problem, but in order to do this the returned pool has to be able to grow to (almost) a /8 because otherwise we won't be able to give every LIR with one /22 their second /22. And that will create unfairness again... Growing to a /8 could take several years. And not every LIR with one /22 will need a second /22. Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, Dpto. Datos Television Costa Blanca wrote: [...]
Soon we will get address space of around /10 from IANAs returned pool plus the reserved we already have.
I think I should clarify the policy and the contents of the pool because I don't want the RIPE or other communities to be surprised when the policy is implemented. The policy (https://www.icann.org/en/resources/policy/global-addressing/allocation-ipv4 -post-exhaustion) requires us to split the contents of the pool into five equal parts and then round down to the nearest CIDR boundary. The pool (https://www.iana.org/assignments/ipv4-recovered-address-space) currently has just short of five /10s, which means the size of the allocation units must be rounded down to /11 equivalents. This is based on the current contents of the pool. If the pool size grew by a precise amount then the policy would support the /10 equivalent allocation unit that has been mentioned. If that does not happen the contents of the pool are likely to be eked out in increasingly small allocations over a number of years. Kind regards, Leo Vegoda
Hi Leo, what is that precise amount? And, how much of those almost 5 /10s have been recovered (received by) IANA in the past 12 months? cheers, elvis On 17/04/14 22:49, Leo Vegoda wrote:
Hi,
Dpto. Datos Television Costa Blanca wrote:
[...]
Soon we will get address space of around /10 from IANAs returned pool
plus the reserved we already have.
I think I should clarify the policy and the contents of the pool because I don't want the RIPE or other communities to be surprised when the policy is implemented.
The policy (https://www.icann.org/en/resources/policy/global-addressing/allocation-ipv4-...) requires us to split the contents of the pool into five equal parts and then round down to the nearest CIDR boundary. The pool (https://www.iana.org/assignments/ipv4-recovered-address-space) currently has just short of five /10s, which means the size of the allocation units must be rounded down to /11 equivalents.
This is based on the current contents of the pool. If the pool size grew by a precise amount then the policy would support the /10 equivalent allocation unit that has been mentioned.
If that does not happen the contents of the pool are likely to be eked out in increasingly small allocations over a number of years.
Kind regards,
Leo Vegoda
Hi Elvis, Elvis Velea wrote:
what is that precise amount?
And, how much of those almost 5 /10s have been recovered (received by) IANA in the past 12 months?
Currently, it is slightly less than 20¼ million addresses. Incidentally, it might be worth noting that the registry is available for download as a CSV file, should you want to import it in to a spreadsheet and play around with the numbers. Nothing has been received in the last 12 months. The registry was last updated on 1 April 2013. Regards, Leo Vegoda
Hi, I apologise for following up on my own message. Leo Vegoda wrote: [...]
Nothing has been received in the last 12 months. The registry was last updated on 1 April 2013.
The RIPE NCC returned some addresses earlier today and we have now registered them here: https://www.iana.org/assignments/ipv4-recovered-address-space. Kind regards, Leo Vegoda
Hi Leo, On 23.04.2014 01:27, Leo Vegoda wrote:
The RIPE NCC returned some addresses earlier today and we have now registered them here: https://www.iana.org/assignments/ipv4-recovered-address-space.
but those 13 additional /24s and the one /21 (if I am correct) still wouldn't yet total to five /10s, right? I am too lazy to make the math myself... :-) Best, -C.
* Carsten Schiefner
but those 13 additional /24s and the one /21 (if I am correct) still wouldn't yet total to five /10s, right? I am too lazy to make the math myself... :-)
Nope. The IANA Recovered IPv4 pool now contains 19.1M addresses, and is 1.9M short of being able to give each RIR a /10. Also worth noting is that LACNIC today marked the equivalent of a /10 reserved in their delegated-extended file (probably in accordance with http://www.lacnic.net/web/lacnic/manual-11), so the "available" space in their registry is now down to 0.4 /8s. That means LACNIC is able to trigger the activation of the pool *right now*, if they so choose. Perhaps they already did and that's why Leo hasn't had time to answer you yet... ;-) Tore
* Tore Anderson
Nope. The IANA Recovered IPv4 pool now contains 19.1M addresses, and is 1.9M short of being able to give each RIR a /10.
Gah. My script wasn't quite bug-free...the above should have read: "The IANA Recovered IPv4 pool now contains 20.2M addresses and is 741K addresses short of being able to give each RIR a /10". Tore
As we are posting about who has what currently ... Announcement of Arin today: https://www.arin.net/announcements/2014/20140423.html Arin enters Phase four of their IPv4 countdown plan : https://www.arin.net/resources/request/ipv4_countdown.html Regards, Erik Bais -----Oorspronkelijk bericht----- Van: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] Namens Tore Anderson Verzonden: woensdag 23 april 2014 18:31 Aan: Carsten Schiefner; Leo Vegoda CC: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] About the /22 allocation limitation * Tore Anderson
Nope. The IANA Recovered IPv4 pool now contains 19.1M addresses, and is 1.9M short of being able to give each RIR a /10.
Gah. My script wasn't quite bug-free...the above should have read: "The IANA Recovered IPv4 pool now contains 20.2M addresses and is 741K addresses short of being able to give each RIR a /10". Tore
Hi all, Seems everybody stop writting with this topic, what I have changed to "Use of the Reserved IP Pool" Are we going to discuss if we made an use of the Reserved IP Pool when it reachs a non-defined-yet prefix to give at least another /22 to those LIRs with only 1 /22? Cheers, El 23/04/2014 21:07, Erik Bais escribió:
As we are posting about who has what currently ...
Announcement of Arin today: https://www.arin.net/announcements/2014/20140423.html
Arin enters Phase four of their IPv4 countdown plan : https://www.arin.net/resources/request/ipv4_countdown.html
Regards, Erik Bais
-----Oorspronkelijk bericht----- Van: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] Namens Tore Anderson Verzonden: woensdag 23 april 2014 18:31 Aan: Carsten Schiefner; Leo Vegoda CC: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] About the /22 allocation limitation
* Tore Anderson
Nope. The IANA Recovered IPv4 pool now contains 19.1M addresses, and is 1.9M short of being able to give each RIR a /10. Gah. My script wasn't quite bug-free...the above should have read:
"The IANA Recovered IPv4 pool now contains 20.2M addresses and is 741K addresses short of being able to give each RIR a /10".
Tore
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel, On 30.04.2014 11:56, Dpto. Datos Television Costa Blanca wrote:
Seems everybody stop writting with this topic, what I have changed to "Use of the Reserved IP Pool"
Are we going to discuss if we made an use of the Reserved IP Pool when it reachs a non-defined-yet prefix to give at least another /22 to those LIRs with only 1 /22?
it appears that you would need to send some text wrt. the parts of the relevant policies you would like to see changed. Best, -C.
Hi Carsten, I know, but before sending any proposal, and to be honest, I dont know what proposal I would need to change for the use of the Reserved IP Pool, I'd like to see others opinions, changes, etc... Regards, El 30/04/2014 12:20, Carsten Schiefner escribió:
Hi Daniel,
On 30.04.2014 11:56, Dpto. Datos Television Costa Blanca wrote:
Seems everybody stop writting with this topic, what I have changed to "Use of the Reserved IP Pool"
Are we going to discuss if we made an use of the Reserved IP Pool when it reachs a non-defined-yet prefix to give at least another /22 to those LIRs with only 1 /22?
it appears that you would need to send some text wrt. the parts of the relevant policies you would like to see changed.
Best,
-C.
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi all, As I said in this list, and since the Available IP Pool grow to near a /8 I want to start this topic again. And the question is: Should be use the Available IP Pool (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-poo...), what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 allocation for another /22 (or other prefix)??? Please, comment it. Regards, El 30/04/2014 12:23, Dpto. Datos Television Costa Blanca escribió:
Hi Carsten,
I know, but before sending any proposal, and to be honest, I dont know what proposal I would need to change for the use of the Reserved IP Pool, I'd like to see others opinions, changes, etc...
Regards,
El 30/04/2014 12:20, Carsten Schiefner escribió:
Hi Daniel,
On 30.04.2014 11:56, Dpto. Datos Television Costa Blanca wrote:
Seems everybody stop writting with this topic, what I have changed to "Use of the Reserved IP Pool"
Are we going to discuss if we made an use of the Reserved IP Pool when it reachs a non-defined-yet prefix to give at least another /22 to those LIRs with only 1 /22?
it appears that you would need to send some text wrt. the parts of the relevant policies you would like to see changed.
Best,
-C.
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
On Wed, Jul 2, 2014 at 10:47 AM, Dpto. Datos Television Costa Blanca <datos@tvt-datos.es> wrote:
Should be use the Available IP Pool (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-poo...), what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 allocation for another /22 (or other prefix)???
While I can see where you are coming from, this would open the door for perpetual "this is the last time, promise!" situations. If this was accepted policy, time passed, and addresses were used up, what would happen with all new LIRs which only have one /21? After the next upgrade, what would happen with those which only have one /20? Given the history of those threads, I can not see consensus forming to undo this change. Sorry, Richard
On Wed, Jul 2, 2014 at 10:47 AM, Dpto. Datos Television Costa Blanca <datos@tvt-datos.es> wrote:
Should be use the Available IP Pool (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-poo...), what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 allocation for another /22 (or other prefix)??? While I can see where you are coming from, this would open the door for perpetual "this is the last time, promise!" situations. If this was accepted policy, time passed, and addresses were used up, what would happen with all new LIRs which only have one /21? After the next upgrade, what would happen with those which only have one /20?
Given the history of those threads, I can not see consensus forming to undo this change. I really understand what you mean, but take our position (New LIR with only a /22). I have IPv6 deployed on our network, at least half of our customers have Dual-Stack access, the other half dont have IPv6 due to dont have a IPv6 enabled equiptment (most of actual home routers (TPLINK, Conceptronic, etc.) dont support it. Our LIR have 5 stars IPv6, we have reserved from our /22 a /24 for
El 02/07/2014 10:56, Richard Hartmann escribió: possible transitional mechanism if we run out of IPv4, but since transitional mechanism harm mental health I wish to dont need it. I know opening the door to this could make IPv6 deploy slower, but if one of the requirements to get another /22 (or other prefix) is to have 5 stars plus other ones to ensure the deploy and use of IPv6 it may help on IPv6 deployment. To ensure Im not crazy about asking for that, APNIC is doing something similar http://www.apnic.net/policy/proposals/prop-105 Regards,
Sorry, Richard
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
On 2 Jul 2014, at 10:10, Dpto. Datos Television Costa Blanca <datos@tvt-datos.es> wrote:
I know opening the door to this could make IPv6 deploy slower, but if one of the requirements to get another /22 (or other prefix) is to have 5 stars plus other ones to ensure the deploy and use of IPv6 it may help on IPv6 deployment.
I am not sure what problem you are trying to solve. Or how changing address policy will solve that problem. You say half your customers don't have IPv6-enabled CPE. This does not seem to me to be a justification for ripping up the current address policy to burn through the remaining dregs of IPv4 and leave absolutely nothing for any newcomers in 5, 10 or 20 years from now. To be quite blunt, ISPs these days really must be shipping dual-stack CPE AND have the supporting IPv6 infrastructure in place: working v6 transport/routing; provisioning; DNS; addressing/subnetting plans; etc, etc.
Hi Jim, You understandme wrong or I did not said it well. Im saying I have deployed IPv6 on my network. I cant "force" a customer to buy another home router supporting IPv6. Anyways, as all of you know, IPv6 isnt globally deployed to work only on that, so you need Dual-Stack or DS-lite,NAT64, etc... if you run out of IPv4. My infrastucture support full IPv6 conectivity, we as an ISP do our job on IPv6 deployment. About newcomers on 5,10 or 20 years... I will not talk about 5 years, but 10 or 20....if in 10-20 years IPv6 is not the main protocol as IPv4 is now, dude, we have a very big problem. We cant know what will happen then. But now, year 2014, LIRs with only /22 are having "troubles" managing their network with only 1024 addresses. What Im trying is to help them (and me!) with that additional /22 (or it could start with /24 since there is a proposal to remove the minium allocation of /22) so they will have a breath while IPv6 are fully deployed on the world. A /24 can give you the chance to grow in customers without wasting in expensive equipment for CGNAT, NAT64, etc.. for some time, maybe the time needed by the rest of the world to finish in the IPv6 deployment. Please, sorry about my very bad english, I know some phrases could not have sense. If so, please tell me and I will try to explain in other way so you all can understand what Im trying to say. Regards, El 02/07/2014 11:35, Jim Reid escribió:
On 2 Jul 2014, at 10:10, Dpto. Datos Television Costa Blanca <datos@tvt-datos.es> wrote:
I know opening the door to this could make IPv6 deploy slower, but if one of the requirements to get another /22 (or other prefix) is to have 5 stars plus other ones to ensure the deploy and use of IPv6 it may help on IPv6 deployment. I am not sure what problem you are trying to solve. Or how changing address policy will solve that problem.
You say half your customers don't have IPv6-enabled CPE. This does not seem to me to be a justification for ripping up the current address policy to burn through the remaining dregs of IPv4 and leave absolutely nothing for any newcomers in 5, 10 or 20 years from now.
To be quite blunt, ISPs these days really must be shipping dual-stack CPE AND have the supporting IPv6 infrastructure in place: working v6 transport/routing; provisioning; DNS; addressing/subnetting plans; etc, etc.
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
On 2 Jul 2014, at 10:52, "Dpto. Datos Television Costa Blanca" <datos@tvt-datos.es> wrote:
About newcomers on 5,10 or 20 years... I will not talk about 5 years, but 10 or 20....if in 10-20 years IPv6 is not the main protocol as IPv4 is now, dude, we have a very big problem. We cant know what will happen then.
Indeed. And that's why we have an address policy which tries to arrange for there to be some IPv4 left for the future. Of course everything will be on IPv6 in 10 or 20 years -- aye right as we say in Scotland! -- but even then there might still be a need for teeny amounts of IPv4. Nobody knows for sure. So best keep some in reserve, just in case our grandchildren might come up with a compelling need for them. It's a bit like the Svalbard repository of most of the world's seeds: they're stored in a very safe place just in case there's a disaster and those crop seeds are *really* needed.
But now, year 2014, LIRs with only /22 are having "troubles" managing their network with only 1024 addresses.
Tough. That's all they're going to get. LIRs knew/know that and should have planned accordingly. Throwing away even more IPv4 addresses at these troubles is just not going to help. It might buy a little short-term relief. But it can't make any difference to the eventual outcome. At best it would just push that crunch point back a few weeks or months. And what does the LIR do then, try to get yet another tweak to address policy to squeeze out another /24? Or a /28? When would this exercise in rearranging the furniture on the Titanic finally stop?
What Im trying is to help them (and me!) with that additional /22 (or it could start with /24 since there is a proposal to remove the minium allocation of /22) so they will have a breath while IPv6 are fully deployed on the world.
Sorry, I just don't get it. A new or existing LIR can get one final /22 of v4 along with their IPv6 allocation. What could they do with an additional /24 of v4 that couldn't already be done with that /22? Where's the use case or justification? And not just for your network, but for LIRs in general. If there is a sound, compelling case for this, please make it.
A /24 can give you the chance to grow in customers without wasting in expensive equipment for CGNAT, NAT64, etc.. for some time, maybe the time needed by the rest of the world to finish in the IPv6 deployment.
Er, that's a key reason why LIRs are eligible for their final /22. If this is genuinely not enough to deal with the v4-v6 transition, please explain how much would be and why. For bonus marks, show your working. As they say in school/college exams. :-)
Please, sorry about my very bad english, I know some phrases could not have sense. If so, please tell me and I will try to explain in other way so you all can understand what Im trying to say.
Your English is just fine Daniel. And far, far better than my Spanish. Which admittedly isn't saying much: "una cerveza por favor" :-).
On Wed, Jul 2, 2014 at 1:50 PM, Jim Reid <jim@rfc1035.com> wrote:
It's a bit like the Svalbard repository of most of the world's seeds: they're stored in a very safe place just in case there's a disaster and those crop seeds are *really* needed.
Having visited the Seed Vault (on my own, in permanent darkness, with a loaded WWII rifle which still had a swastika stamped into it, and an ice bear which roared on the slope behind me after an hour of me standing still and taking pictures in half a snow-storm; but that is another story), I have to disagree. The one is carved into bedrock, has double blast doors and two independent armoured storage chambers, is designed to withstand a nuclear explosion, be above the waterline even if the poles and glaciers melt down completely, and will remain cold enough for millennia to come even without active cooling and facing global warming. The other is just a place to store seeds. Richard
Hi Daniel, I don't see how handing out additional (free) space per LIR would solve the or your issue. Maybe it will solve your issue for a couple months, but not in the long run... The policy is clear, the reserved pool will provide a single /22 for every old and new LIR. If you require additional IP space there are options available, but the final /22 provided is the final free IP space that you and every other LIR is going to get. If you require additional space, other options are : - Transfer Market - setup a new LIR - buy an existing LIR that is moving out of business. And if that is not the solution for you, you need to see if CGNAT might be. I understand the issue you have and try to address, but the solution isn't to be found in the remaining Available IP Pool at RIPE. Running a new access network with only IPv6 will not fix the issue for today, you need to see how to overcome the period between today and when IPv6 will be the dominant protocol and customers don't care about v4 anymore because their XBOX or favorite website isn't only running on v4 anymore. Regards, Erik Bais -----Oorspronkelijk bericht----- Van: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] Namens Dpto. Datos Television Costa Blanca Verzonden: woensdag 2 juli 2014 10:47 Aan: address-policy-wg@ripe.net Onderwerp: Re: [address-policy-wg] Use of the Reserved IP Pool Hi all, As I said in this list, and since the Available IP Pool grow to near a /8 I want to start this topic again. And the question is: Should be use the Available IP Pool (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po ol-graph), what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 allocation for another /22 (or other prefix)??? Please, comment it. Regards, El 30/04/2014 12:23, Dpto. Datos Television Costa Blanca escribió:
Hi Carsten,
I know, but before sending any proposal, and to be honest, I dont know what proposal I would need to change for the use of the Reserved IP Pool, I'd like to see others opinions, changes, etc...
Regards,
El 30/04/2014 12:20, Carsten Schiefner escribió:
Hi Daniel,
On 30.04.2014 11:56, Dpto. Datos Television Costa Blanca wrote:
Seems everybody stop writting with this topic, what I have changed to "Use of the Reserved IP Pool"
Are we going to discuss if we made an use of the Reserved IP Pool when it reachs a non-defined-yet prefix to give at least another /22 to those LIRs with only 1 /22?
it appears that you would need to send some text wrt. the parts of the relevant policies you would like to see changed.
Best,
-C.
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel,
I don't see how handing out additional (free) space per LIR would solve the or your issue. Maybe it will solve your issue for a couple months, but not in the long run...
The policy is clear, the reserved pool will provide a single /22 for every old and new LIR Im not talking about the reserved pool. As the graph sais, there are Reserved Pool 0.15 /8 and Available Pool is 0.93 /8 Reserved pool is for the last /22 policy. With the actual numbers, 2490 new LIRs can set up with a /22 allocation. .
If you require additional IP space there are options available, but the final /22 provided is the final free IP space that you and every other LIR is going to get.
If you require additional space, other options are : - Transfer Market - setup a new LIR - buy an existing LIR that is moving out of business. All of them includes money, What Im trying is to be "fair" with new LIRs. I say fair betwen quotes becouse it wont be fair. Never. Old LIRs have multiple allocations, new LIRs only 1 /22 and all we pay the same fee. I dont care about paying the same fee, this is not the question here. Im saying, we have almost another /8 and it could help new lirs to move/wait to IPv6 be fully deployed. I know, and im not pointing anyone here, old LIRs/brokers with millions of address have a bussiness with the transfer market, and a new policy allowing new lirs to get another /22 is bad for them. Now, what is RIPE? A Regional Internet Registry for help Local Internet Registry or is a
Hi Erik, I'll comment inline: El 02/07/2014 12:56, Erik Bais escribió: place to make lots of money with IP transfers? If anyone replying this topic in the list have free IP allocations and are willing to sell or make money with them _should not_ be able to anwer here. Of course they will answer, and for sure, if they have free IP allocations and willing to sell they will not say it, but they are not objetives when saying: No more IP alloc than the /22 for new LIRs.
And if that is not the solution for you, you need to see if CGNAT might be.
I understand the issue you have and try to address, but the solution isn't to be found in the remaining Available IP Pool at RIPE. Running a new access network with only IPv6 will not fix the issue for today, you need to see how to overcome the period between today and when IPv6 will be the dominant protocol and customers don't care about v4 anymore because their XBOX or favorite website isn't only running on v4 anymore.
The non-expensive way to overcome the time betwen today and the day IPv6 is the dominant protocol is giving more space to those new lirs that need it. Regards,
Onderwerp: Re: [address-policy-wg] Use of the Reserved IP Pool
Hi all,
As I said in this list, and since the Available IP Pool grow to near a /8 I want to start this topic again. And the question is: Should be use the Available IP Pool (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po ol-graph), what is near to a /8 (0.93 /8) to those new LIRs that only have a /22 IPv4 allocation for another /22 (or other prefix)???
Please, comment it.
Regards,
El 30/04/2014 12:23, Dpto. Datos Television Costa Blanca escribió:
Hi Carsten,
I know, but before sending any proposal, and to be honest, I dont know what proposal I would need to change for the use of the Reserved IP Pool, I'd like to see others opinions, changes, etc...
Regards,
El 30/04/2014 12:20, Carsten Schiefner escribió:
Hi Daniel,
Seems everybody stop writting with this topic, what I have changed to "Use of the Reserved IP Pool"
Are we going to discuss if we made an use of the Reserved IP Pool when it reachs a non-defined-yet prefix to give at least another /22 to those LIRs with only 1 /22? it appears that you would need to send some text wrt. the parts of
On 30.04.2014 11:56, Dpto. Datos Television Costa Blanca wrote: the relevant policies you would like to see changed.
Best,
-C.
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel,
Im not talking about the reserved pool. As the graph sais, there are Reserved Pool 0.15 /8 and Available Pool is 0.93 /8 Reserved pool is for the last /22 policy. With the actual numbers, 2490 new LIRs can set up with a /22 allocation.
You have the numbers wrong here. The available pool is where the /22s are coming from. The reserved pool contains returned addresses. And for those the policy says: "5.3 Address Recycling: Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself." So, unless address space is returned to IANA (we don't have a policy for returning RIR space to IANA at the moment, but we might) the whole 1.08 /8 will eventually be allocated as /22s. Cheers, Sander
Hi Sander,
So, unless address space is returned to IANA (we don't have a policy for returning RIR space to IANA at the moment, but we might) the whole 1.08 >/8 will eventually be allocated as /22s.
The "non-expensive" way how to further delay the IPv6 implementation. Not every ISP is fully IPv6 ready yet and this sort of exercise would just postpone the action. Ok, then only give another alloc to those who already deployed IPv6 on
Throwing away even more IPv4 addresses at these troubles is just not going to help. It might buy a little short-term relief. But it can't make any difference to the >eventual outcome. At best it would just push
Er, that's a key reason why LIRs are eligible for their final /22. If
So, Are we going to keep 18.11 Million address for new LIRs?. Thats makes 17685 new lirs, way more than double as we have now...sorry but that is ridiculous when we have LIRs with v4 allocation problems. -- Hi Jan, their networks and customers. Its easy. Who do the job get a "gift" then you will see the IPv6 graph grow much faster than now. -- Hi Jim, that crunch point back a few weeks or months. And what does the LIR do then, try to get yet another tweak to address >policy to squeeze out another /24? Or a /28? When would this exercise in rearranging the furniture on the Titanic finally stop? For example, another /22 with give more than double time. Not just a few weeks/months. Double the time. If you make full use (not just assignements) of a /22 in 1 year, with a /21 you will have more than 2 years of breath. this is genuinely not enough to deal with the v4-v6 transition, please explain how much would be and >why. For bonus marks, show your working. As they say in school/college exams. How much? Dont really know. Im writting to the list for that matters. As I said before, another /22 to those LIRs who only own a /22 will give them more than double time. This is really LOT OF TIME. For the big telcos, who own millions of address, another /22 is nothing to them, for a Local ISP could be the breath they are waiting untill IPv6 is fully deployed. About your spanish, you know the better words you can know. With that you will make lot of friends here :) -- For all A little bit more than 20% of RIPE LIRs have 5 stars. We can be proud of being one. Are you guys one of them? Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
On Wed, Jul 2, 2014 at 5:01 PM, Dpto. Datos Television Costa Blanca <datos@tvt-datos.es> wrote:
For example, another /22 with give more than double time. Not just a few weeks/months. Double the time.
You can not know that.
A little bit more than 20% of RIPE LIRs have 5 stars. We can be proud of being one. Are you guys one of them?
Unless you are planning to take away v4 address space from people, I don't see how that is relevant. At this point, it's clear that consensus will not be reached. As you still seem to be determined, you are free to create a proposal like "any LIR which reaches five stars and has only one single /22 will get one additional /x", but I expect it to not come to fruition. Personally, I will try to stop posting in these threads, Richard
On Wed, Jul 2, 2014 at 5:01 PM, Dpto. Datos Television Costa Blanca <datos@tvt-datos.es> wrote:
For example, another /22 with give more than double time. Not just a few weeks/months. Double the time. You can not know that. You can not know if Im correct or not. But as my experience, as more space you have, more flexibility. IP use is "like" the bandwith use. Not for doubling your customers will make you use double bandwith. So if you double your max bandwith you can have more than double customers. Concurrency is the word. Doubling your IP space will give you mooooore time.
A little bit more than 20% of RIPE LIRs have 5 stars. We can be proud of being one. Are you guys one of them? Unless you are planning to take away v4 address space from people, I don't see how that is relevant. Is relevant to know if a LIR with only a /22 needs more v4 space. If we are trying to push ppl towards IPv6 this could be a good start point. It is real that, what we've done is not working since nobody is deploying IPv6, maybe becouse they took enough space before the exhaustion policy. At this point, it's clear that consensus will not be reached. Wow, 4 persons from 10k+ LIRs said no and it's clear...amazing.
As you still seem to be determined, you are free to create a proposal like "any LIR which reaches five stars and has only one single /22 will get one additional /x", but I expect it to not come to fruition. Why not? Are you selling IP Space so you dont want that policy going up? Or you just have enough IP space so dont really care about the rest of
Hi Richard, the LIRs?
Personally, I will try to stop posting in these threads,
Please, feel free to stop replying to any thread about this topic . As a community is not good, but I cant force you to keep posting on those threads.
Richard
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi Daniel,
At this point, it's clear that consensus will not be reached.
Wow, 4 persons from 10k+ LIRs said no and it's clear...amazing.
Being an LIR or not and the size of the company (if any) doesn't matter here. All discussions here are between persons, not between companies or their employees. So far you have shown that new LIRs are short on IPv4 space. Well known fact :) You haven't shown how we can make that less painful without endangering the long-term stability.
As you still seem to be determined, you are free to create a proposal like "any LIR which reaches five stars and has only one single /22 will get one additional /x", but I expect it to not come to fruition.
Why not? Are you selling IP Space so you dont want that policy going up? Or you just have enough IP space so dont really care about the rest of the LIRs?
Please don't start insulting people that offer you honest advice, even if you don't want to hear it. If you want to change anything then you really are free to submit a policy proposal, but be prepared to explain/defend your proposal to those on this list that don't agree with you without insulting people or calling other peoples opinions ridiculous. As I have asked you some time ago: when thinking about a policy proposal about these last IPv4 addresses you have to think about all the aspects: future developments, fairness, scalability, routing table size etc. Do the math. Ask people who are experienced in this field and be willing to learn and see things from different points of view. Policy making is hard and just stating that the current policy is ridiculous and that small LIRs should just get more address space is not going to get you consensus. Cheers, Sander
Hi, Please, again, sorry if my words in english are rude. Sometimes its hard to me to express what i want to say and to read what you want to say. I apologies if anyone here feel insulted by me. As I understood, he said no, he said _nobody_ wants it when at this time, only 6 ppl replied the thread. He expect not to come this proposal so is knocking it down before I made it. I just want to know if he is doing market with IP space (not an insult) or if he have enough space to dont care about our problem (not an insult). Maybe I could sound rude, but again, its not my intention to sound rude or being an asshole. As you said, this is not about LIR or how big is your company so I have the same right to express our concerns and a non-really-expensive way to solve them. I want to make it the better for everyone, actual LIRs and future ones, but when you have enough space you cant be objetive. At this point, again, Im very sorry if anyone feel insulted by my words. I only want to make consensous about the possibility of giving more space to new lirs who only have a /22 and have made their job implementing and deploying IPv6 to their network. And im talking about real work, not only having an allocation and announcing it on bgp. I do really care about what community think about it, always in a good way and being open-mind, trying to see the position of the new/unexperienced new as I try to take the position of the old and experienced ones. Also, you can say -hey, we did few years ago a policy, what is done is done- but, anything but dead can be undone or Now, another not-an-insult question. Are you doing CGNAT or another mechanism to save v4 space? Do you have enough space for sell or simple enough to dont bother about ppl who dont have enough and are in trouble? What I want to know is if there is anyone who only have a /22 and are ok with not recieving (even if there are) more allocations (unknow prefix) only for if in 10-15 years IPv6 isnt globally deployed. Kind Regards, El 02/07/2014 19:02, Sander Steffann escribió:
Hi Daniel,
At this point, it's clear that consensus will not be reached. Wow, 4 persons from 10k+ LIRs said no and it's clear...amazing. Being an LIR or not and the size of the company (if any) doesn't matter here. All discussions here are between persons, not between companies or their employees. So far you have shown that new LIRs are short on IPv4 space. Well known fact :) You haven't shown how we can make that less painful without endangering the long-term stability.
As you still seem to be determined, you are free to create a proposal like "any LIR which reaches five stars and has only one single /22 will get one additional /x", but I expect it to not come to fruition. Why not? Are you selling IP Space so you dont want that policy going up? Or you just have enough IP space so dont really care about the rest of the LIRs? Please don't start insulting people that offer you honest advice, even if you don't want to hear it. If you want to change anything then you really are free to submit a policy proposal, but be prepared to explain/defend your proposal to those on this list that don't agree with you without insulting people or calling other peoples opinions ridiculous.
As I have asked you some time ago: when thinking about a policy proposal about these last IPv4 addresses you have to think about all the aspects: future developments, fairness, scalability, routing table size etc. Do the math. Ask people who are experienced in this field and be willing to learn and see things from different points of view. Policy making is hard and just stating that the current policy is ridiculous and that small LIRs should just get more address space is not going to get you consensus.
Cheers, Sander
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Wed, Jul 02, 2014 at 07:53:08PM +0200, Dpto. Datos Television Costa Blanca wrote:
What I want to know is if there is anyone who only have a /22 and are ok with not recieving (even if there are) more allocations (unknow prefix) only for if in 10-15 years IPv6 isnt globally deployed.
You can assume that most receivers of a /22 will not be happy. But most other receivers of IPv4 address space are not happy either - here in Germany, all the access ISPs that are still growing truly fast (like, "Kabel Deutschland") have moved to a DS-Lite model where IPv4 is delivered over a CGNAT - because there is no way they can get enough IPv4 for millions of customers. It's even worse for hosting providers. You can't put web server farms behind a CGNAT box... (We've been unhappy with IPv4 for the last 15 years, because the whole topic of "you can only get what you fill in paperwork for" has been annyoing even back then) So: yeah, most ISPs are not exactly happy with the way IPv4 shortage plays out. But what's the alternative? "Some people are still not able to get all the IPv4 space they need, and other people will not get anything at all anymore"? This is what people are trying to tell you: RIPE policy needs to balance individual needs against the needs of everyone else. We fully understand that you're not happy, but the feedback you got so far is that nobody else supports the idea where you plan to go - and this is usually a pretty good indication that no, there is no consensus. (Judging comments, there is the type that says "yeah, support", the one that says "I like the general idea, but some details will not work" and the ones that say "this is a bad idea and will not work, because..." - unless you have more of the first ones, no go) Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, This is my last email for today, Im at home a need to unplug my mind from work till tomorrow. You are talking about an ISP with millions of subscribers. I know everyone here are the same, nobody is up to other, but I think the community should think about not every LIR is a giant telco with millions subscribers. There are also little telcos with only thousands, and for sure they dont have the same bucket. A giant telco can spend millions € on equipment, i+d, etc when the small ones cant. A hosting provider is not an example. A single IP can host hunders or thousands of webs,mails,dns, almost everything. An ISP cant do the same. About consensous, again, only 6 ppl of 3000k+ subscribers to the list cant be the consensous. Nobody cant say "This is going to nothing" because me and 3 more already said no, so dont go that way. I'll be very happy if tomorrow, or next week, i see emails with "Hey dude, your proposal can be better if..." instead of rotunds NOes with always the same; we discussed this few years ago. That means it cant me discussed again? Im trying to discuss, not to impose anything. Also, im being treated as crazy for what Im saying. As I said in first, another RIR is going to do what Im trying to propose here, even while they have a similar last /8 proposal, so I shouldnt be so crazy. Best regards to everyone. PS: Please, again, I dont want to offense or insult anybody. If any of the words/phrases I said expressed that, please correct me at anytime. El 02/07/2014 20:29, Gert Doering escribió:
Hi,
On Wed, Jul 02, 2014 at 07:53:08PM +0200, Dpto. Datos Television Costa Blanca wrote:
What I want to know is if there is anyone who only have a /22 and are ok with not recieving (even if there are) more allocations (unknow prefix) only for if in 10-15 years IPv6 isnt globally deployed. You can assume that most receivers of a /22 will not be happy.
But most other receivers of IPv4 address space are not happy either - here in Germany, all the access ISPs that are still growing truly fast (like, "Kabel Deutschland") have moved to a DS-Lite model where IPv4 is delivered over a CGNAT - because there is no way they can get enough IPv4 for millions of customers.
It's even worse for hosting providers. You can't put web server farms behind a CGNAT box...
(We've been unhappy with IPv4 for the last 15 years, because the whole topic of "you can only get what you fill in paperwork for" has been annyoing even back then)
So: yeah, most ISPs are not exactly happy with the way IPv4 shortage plays out. But what's the alternative? "Some people are still not able to get all the IPv4 space they need, and other people will not get anything at all anymore"?
This is what people are trying to tell you: RIPE policy needs to balance individual needs against the needs of everyone else. We fully understand that you're not happy, but the feedback you got so far is that nobody else supports the idea where you plan to go - and this is usually a pretty good indication that no, there is no consensus. (Judging comments, there is the type that says "yeah, support", the one that says "I like the general idea, but some details will not work" and the ones that say "this is a bad idea and will not work, because..." - unless you have more of the first ones, no go)
Gert Doering -- NetMaster
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Wed, Jul 02, 2014 at 09:15:36PM +0200, Dpto. Datos Television Costa Blanca wrote:
This is my last email for today, Im at home a need to unplug my mind from work till tomorrow.
You are talking about an ISP with millions of subscribers. I know everyone here are the same, nobody is up to other, but I think the community should think about not every LIR is a giant telco with millions subscribers. There are also little telcos with only thousands, and for sure they dont have the same bucket. A giant telco can spend millions ? on equipment, i+d, etc when the small ones cant.
It really does not matter whether you're a telco with a million subscribers that only has 10.000 IPv4 addresses, or a small ISP with 10.000 subscribers that only has 1.000 IPv4 addresses. You're f*cked anyway. The amount of money the big telco has to invent into their carrier grade NAT gear would make your eyes water... while a small ISP could get this done on a reasonably sized server with Linux on it (and I know some that do).
A hosting provider is not an example. A single IP can host hunders or thousands of webs,mails,dns, almost everything. An ISP cant do the same.
If you do simple "shared" web hosting, yes. But there's hosting customers that can't be served with some few CPU cycles on a shared platform, but really need dedicated hardware (and lots of them), and those will need a few IPv4 addresses dedicated to them. Maybe only two /29 or so, but if all you have is a /22, good luck growing your business. Because *you* do not see the pain others feel, don't assume it is not there.
About consensous, again, only 6 ppl of 3000k+ subscribers to the list cant be the consensous. Nobody cant say "This is going to nothing" because me and 3 more already said no, so dont go that way.
This is the way it works. Most people never speak up. Of those that speak up, you need someone to actually support the idea, and convince those that are sceptical. At this point, there is no support, and people are more negative than just "sceptical". So yeah, tomorrow 20 people could show up and say "hey, we think this is a great idea!", but today, I do not see them. [..]
Also, im being treated as crazy for what Im saying. As I said in first, another RIR is going to do what Im trying to propose here, even while they have a similar last /8 proposal, so I shouldnt be so crazy.
We'll see how the walls look like that the ARIN crowd is running into, and it will be interesting. The RIPE community has decided to play this one very conservatively, and draw out the hard crash as long as possible. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Good Morning everyone! I know you missed me since yesterday... El 02/07/2014 21:33, Gert Doering escribió:
Hi,
This is my last email for today, Im at home a need to unplug my mind from work till tomorrow.
You are talking about an ISP with millions of subscribers. I know everyone here are the same, nobody is up to other, but I think the community should think about not every LIR is a giant telco with millions subscribers. There are also little telcos with only thousands, and for sure they dont have the same bucket. A giant telco can spend millions ? on equipment, i+d, etc when the small ones cant. It really does not matter whether you're a telco with a million subscribers
On Wed, Jul 02, 2014 at 09:15:36PM +0200, Dpto. Datos Television Costa Blanca wrote: that only has 10.000 IPv4 addresses, or a small ISP with 10.000 subscribers that only has 1.000 IPv4 addresses. You're f*cked anyway.
The amount of money the big telco has to invent into their carrier grade NAT gear would make your eyes water... while a small ISP could get this done on a reasonably sized server with Linux on it (and I know some that do). About this point. Its clear, but at this moment cant know the legal implementations. I'll try to inform, but by the moment, what about if you recieve a court requirment saying: Hey, what customer had that IP Address in that date/hour? The court requirement NEVER said what the customer was doing so, at this moment noone of the "save IP space" mechanism is valid since we wont be able to correctly reply to the court requirement.
A hosting provider is not an example. A single IP can host hunders or thousands of webs,mails,dns, almost everything. An ISP cant do the same. If you do simple "shared" web hosting, yes. But there's hosting customers that can't be served with some few CPU cycles on a shared platform, but really need dedicated hardware (and lots of them), and those will need a few IPv4 addresses dedicated to them. Maybe only two /29 or so, but if all you have is a /22, good luck growing your business.
Because *you* do not see the pain others feel, don't assume it is not there. That is true and Im sorry, but with only 1 Public IP Address you can have a really fu**king big cluster, a cloud, whatever you want. If vhost work for ISP Customer, as we said in Spain "another roster would sing"
About consensous, again, only 6 ppl of 3000k+ subscribers to the list cant be the consensous. Nobody cant say "This is going to nothing" because me and 3 more already said no, so dont go that way. This is the way it works. Most people never speak up. Of those that speak up, you need someone to actually support the idea, and convince those that are sceptical.
At this point, there is no support, and people are more negative than just "sceptical".
So yeah, tomorrow 20 people could show up and say "hey, we think this is a great idea!", but today, I do not see them. I'll wait then. Im sure im not the only one in this position, and again, as we say in spain, who doesnt cry doesnt suck. And no, is not that kind of suck.
[..]
Also, im being treated as crazy for what Im saying. As I said in first, another RIR is going to do what Im trying to propose here, even while they have a similar last /8 proposal, so I shouldnt be so crazy. We'll see how the walls look like that the ARIN crowd is running into, and it will be interesting. The RIPE community has decided to play this one very conservatively, and draw out the hard crash as long as possible. Im just asking for a little bit of flexibility. I dont want to throw away all the IP space RIPE have.
At this moment, Im sure there are LIRs with a /22 who only need a /24 and LIRs with a /22 who need more. If the proposal to remove the minimum allocation of /22 goes well, maybe something can be done about this. - New LIRs recieving a first allocation of /23 or /24? (And you can say; This will f**k the routing table. But /24 announces already happens) - New LIRs can ask for more allocations but in stacks of /24 up to a total of /21? If the problem is saving IP space for future LIRs, giving away /22 to all LIRs, independent to their needs, is a waste of space. Maybe and for the future, we should start talking about what should IANA do about legacy allocations not in use. Maybe forcing them to return space if they dont use/dont want it anymore instead of giving the chance to sell it. Dont know, Im really new to the world of RIRs/LIRs so Im sure you will know more about this than me. This could have been discussed before, dont know. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Thu, Jul 03, 2014 at 10:28:04AM +0200, Dpto. Datos Television Costa Blanca wrote:
It really does not matter whether you're a telco with a million subscribers that only has 10.000 IPv4 addresses, or a small ISP with 10.000 subscribers that only has 1.000 IPv4 addresses. You're f*cked anyway.
The amount of money the big telco has to invent into their carrier grade NAT gear would make your eyes water... while a small ISP could get this done on a reasonably sized server with Linux on it (and I know some that do). About this point. Its clear, but at this moment cant know the legal implementations. I'll try to inform, but by the moment, what about if you recieve a court requirment saying: Hey, what customer had that IP Address in that date/hour? The court requirement NEVER said what the customer was doing so, at this moment noone of the "save IP space" mechanism is valid since we wont be able to correctly reply to the court requirement.
And this is different for you as compared to a big Cable ISP exactly why? Everybody who is growing his IPv4 network is facing the same challenges, as there are no more IPv4 addresses to sustain the demand. So yes, if these are the requirements, you will need to do logging of NAT pool mappings, and depending on the amount of customers you have, some pretty expensive storage to hold the data... (things like A+P / MAP help here, because you're not randomly masquerading customer IPs, but it will be done by block). Be assured, for a telco with a million customers, this will not be easier or cheaper than for an ISP with 10.000 [ hosting provider ]
That is true and Im sorry, but with only 1 Public IP Address you can have a really fu**king big cluster, a cloud, whatever you want. If vhost work for ISP Customer, as we said in Spain "another roster would sing"
So maybe changing line of business might be an option here... we cannot run multiple of our big hosting customers on a single IP address. If you can, this would be significant market advantage. [..]
At this moment, Im sure there are LIRs with a /22 who only need a /24 and LIRs with a /22 who need more. If the proposal to remove the minimum allocation of /22 goes well, maybe something can be done about this. - New LIRs recieving a first allocation of /23 or /24? (And you can say; This will f**k the routing table. But /24 announces already happens) - New LIRs can ask for more allocations but in stacks of /24 up to a total of /21?
Yes, this will f**k the routing table. If we go there, and next thing you find that ISPs are unwilling to accept these /24s, because their routers' TCAM is full, who are you going to complain to? [..]
Maybe and for the future, we should start talking about what should IANA do about legacy allocations not in use. Maybe forcing them to return space if they dont use/dont want it anymore instead of giving the chance to sell it. Dont know, Im really new to the world of RIRs/LIRs so Im sure you will know more about this than me. This could have been discussed before, dont know.
The only way to *solve* this is to go to IPv6. Everything else is just investing into a dead technology, and drawing out the pains. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, Im cutting a little bit this or it will be longer as the bible is.
And this is different for you as compared to a big Cable ISP exactly why? Everybody who is growing his IPv4 network is facing the same challenges, as there are no more IPv4 addresses to sustain the demand. So yes, if these are the requirements, you will need to do logging of NAT pool mappings, and depending on the amount of customers you have, some pretty expensive storage to hold the data... (things like A+P / MAP help here, because you're not randomly masquerading customer IPs, but it will be done by block). Be assured, for a telco with a million customers, this will not be easier or cheaper than for an ISP with 10.000
I dont know the legal things of other countrys, I dont even know everything for our country. Logging the NAT pool map could not be the solution. Again, the court dont sais what was doing, just say an IP and a Date, and for example, if court sais: Hey, tell me who was using this IP in this date/hour. The IP was scamming on Facebook. The logs will show like 75% of customers sharing the same IP were using facebook in that moment. There is also another legal problem. I'll try to inform but I think at this moment here is illegal to sniff and _save_ our customers connections. If i dont remember bad, you can sniff but only in realtime, just to see what is happening at the moment on your network.
At this moment, Im sure there are LIRs with a /22 who only need a /24 and LIRs with a /22 who need more. If the proposal to remove the minimum allocation of /22 goes well, maybe something can be done about this. - New LIRs recieving a first allocation of /23 or /24? (And you can say; This will f**k the routing table. But /24 announces already happens) - New LIRs can ask for more allocations but in stacks of /24 up to a total of /21? Yes, this will f**k the routing table. If we go there, and next thing you find that ISPs are unwilling to accept these /24s, because their routers' TCAM is full, who are you going to complain to? But there is actually /24's announces everywhere, Do you think it will mess up the table more than it is now?
[..]
Maybe and for the future, we should start talking about what should IANA do about legacy allocations not in use. Maybe forcing them to return space if they dont use/dont want it anymore instead of giving the chance to sell it. Dont know, Im really new to the world of RIRs/LIRs so Im sure you will know more about this than me. This could have been discussed before, dont know. The only way to *solve* this is to go to IPv6. Everything else is just investing into a dead technology, and drawing out the pains. I'm totally with you. Totally dude. Im an IPv6 fanboy. But that doesnt mean to dont try to have a solution for today. (<-- I dont know if I said it well) One of the requirements I said for having more allocation than /22 from RIPE was exactly that. Not only having an IPv6 allocation, not only having that allocation (or a chunk) announced. I said to have it in really production. From core network to customer cpe when supported, Dual-Stacking them. As you said, investing in IPv4 is investing into a dead technology. We dont want to spend lots of money and work in a dead technology. We spend money on new hardware that supports IPv6 and time doing it work.
Best Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On 02.07.2014 19:53, Dpto. Datos Television Costa Blanca wrote:
As I understood, he said no, he said _nobody_ wants it when at this time, only 6 ppl replied the thread.
Well maybe only 6 people replied to this thread, but the topic was discussed at length when the last /8 policy was developed in the first place. If you look at how for example LACNIC burned through the first half of their last /8, I prefer the policy in place in the RIPE region. The current policy ensures that new entrants get a least a bit of address space to bootstrap. If I understand your proposal correctly, this would mean a lot of LIRs still not getting the resources they need (a /22 does not make a big difference for many LIRs) and new entrants would eventually get no ip addresses at all. I do not see that happening. Regards André
Daniel - On 02.07.2014 19:53, Dpto. Datos Television Costa Blanca wrote:
[...]
As I understood, he said no, he said _nobody_ wants it when at this time, only 6 ppl replied the thread. He expect not to come this proposal so is knocking it down before I made it.
if only you would start writing it up eventually - as I have recommended already on 30 Apr - in the light of what Jim and Sander have written here: what exactly, reasoning, outlook, pros & cons. Instead of trying to find allies for a yet completely rough sketch of what you have in mind. And for the records: count me in as #7 if you wish - I remain fully unconvinced for the time being. Best, Carsten
Hi Carsten, Thank you for replying. El 03/07/2014 15:38, Carsten Schiefner escribió:
Daniel -
On 02.07.2014 19:53, Dpto. Datos Television Costa Blanca wrote:
[...]
As I understood, he said no, he said _nobody_ wants it when at this time, only 6 ppl replied the thread. He expect not to come this proposal so is knocking it down before I made it.
if only you would start writing it up eventually - as I have recommended already on 30 Apr - in the light of what Jim and Sander have written here: what exactly, reasoning, outlook, pros & cons.
Instead of trying to find allies for a yet completely rough sketch of what you have in mind. I'm not trying to find allies. As I know, this is not about allies and enemies. For sure, im not considering it that way. You recommended me to write up what policies to change, but I dont really know what policies and how should be changed for what I have in mind. Im a newbie in this specific world. Im here to find support on how to do it in the correct way. But all I read is like what Im triying to say/do/propose is crazyness and for some, I should be interned in a Psychiatric. But as I said, another RIR is doing just the same. Some RIPE IPRA said is not a bad idea what im talking about. Also a PDO told me if i was in the need of help, but I told to wait, since doing it without first discussing it here is like doing in the back of the community and I dont want that.
And for the records: count me in as #7 if you wish - I remain fully unconvinced for the time being. Oh please, stop that. I just only said that 5 or 6 ppl is not consensous. If you all wish, I did the math. 7 (counting you) of 3000 is 0.23% and the list have more than 3k subscribers. Im not going that way because if we start with that, not a single proposal would be accepted.
Please, dont take all my words literally. Best Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Thu, Jul 03, 2014 at 04:52:14PM +0200, Dpto. Datos Television Costa Blanca wrote:
Oh please, stop that. I just only said that 5 or 6 ppl is not consensous. If you all wish, I did the math. 7 (counting you) of 3000 is 0.23% and the list have more than 3k subscribers. Im not going that way because if we start with that, not a single proposal would be accepted.
You'll *have* to go that way, as this is the way RIPE policy making works. Only actual statements are evaluated, and if all you get is 7 people disagreeing with the idea, it does not matter if 100, 3000, or 5 million other people do not say anything about it. If you look at the archives, you'll see that it's quite different for different proposals - some ideas get much/only positive feedback right away (and in that case, 5 people telling us "yeah, go for it!" is also clear enough, as 2995 others do not find it necessary to say "I'm against it! stop!"), other ideas cause long discussions, eventually leading to the opponents being convinced - and yet other proposals come up, get strong headwind, and are withdrawn because it's clear that there is not enough support. This is not voting, this is "rough consensus", similar to RFC7282. Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, El 03/07/2014 17:16, Gert Doering escribió:
Hi,
On Thu, Jul 03, 2014 at 04:52:14PM +0200, Dpto. Datos Television Costa Blanca wrote:
Oh please, stop that. I just only said that 5 or 6 ppl is not consensous. If you all wish, I did the math. 7 (counting you) of 3000 is 0.23% and the list have more than 3k subscribers. Im not going that way because if we start with that, not a single proposal would be accepted. You'll *have* to go that way, as this is the way RIPE policy making works.
Only actual statements are evaluated, and if all you get is 7 people disagreeing with the idea, it does not matter if 100, 3000, or 5 million other people do not say anything about it.
If you look at the archives, you'll see that it's quite different for different proposals - some ideas get much/only positive feedback right away (and in that case, 5 people telling us "yeah, go for it!" is also clear enough, as 2995 others do not find it necessary to say "I'm against it! stop!"), other ideas cause long discussions, eventually leading to the opponents being convinced - and yet other proposals come up, get strong headwind, and are withdrawn because it's clear that there is not enough support.
This is not voting, this is "rough consensus", similar to RFC7282. You understand me wrong. Im saying just what you are saying. Not everybody on the list will vote, negative or positive. I know that and Im ok with that. Im not trying to do that way. I only said that if in 2 days, only a few said no there is no consensous. At least not only in 2 days of topic.
When I started the topic, few months ago, as far I can remember I stopped it until IANA return the space and see if we reach a /8 (somebody said we will not be even close) and then see what we do about it. I have a mess with Thunderbird and it crashes everytime I search for the emails, so I cant copy&paste or take a look now (still trying) but I remember that. IANA returned the space, we now have more than a /8 what makes me think... Its then the last /8 proposal invalid since now we have more than a /8? Didnt read the full proposal, and to be honest, I'll probably cant understand it in their totallity so if anyone can answer me that would be awesome. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, On Thu, Jul 03, 2014 at 05:54:17PM +0200, Dpto. Datos Television Costa Blanca wrote:
Its then the last /8 proposal invalid since now we have more than a /8?
It is not. The community consciously decided that as soon as the "last /8" policy change is activated, it will *stay*, and everything else is no longer valid. (And, to be precise, we removed everything else from the IPv4 policy earlier this year, because it is no longer relevant)
Didnt read the full proposal, and to be honest, I'll probably cant understand it in their totallity so if anyone can answer me that would be awesome.
Do not read individual proposals to understand current policy as a whole. Reading proposals and mailing list threads helps understand how the policy ended up in it's current form, but each proposal will only cover specific areas, not "all of the policy". So to really see what is policy today, read the full policy document, currently ripe-606 http://www.ripe.net/ripe/docs/ripe-606 as you'll see there is nothing left about "when we reach the last /8", as this has all been taken out after it was no longer relevant. *This* is the policy as it is in effect right now. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
On 03/07/14 16:52, Dpto. Datos Television Costa Blanca wrote:
Oh please, stop that. I just only said that 5 or 6 ppl is not consensous. If you all wish, I did the math. 7 (counting you) of 3000 is 0.23% and the list have more than 3k subscribers. Im not going that way because if we start with that, not a single proposal would be accepted.
Dear Daniel, Don't get me wrong, but RIPE community works in slightly different way from what is probably your current understanding. Please, join us in London for RIPE69, learn how this community works and maybe after that you'll approach the process and discussion differently. Best regards, Jan
Hi Daniel, a good friend of mine - a lawyer - quite often tells me: "If in doubt, have a look at the relevant law." So in your case... On 03.07.2014 16:52, Dpto. Datos Television Costa Blanca wrote:
[...] You recommended me to write up what policies to change, but I dont really know what policies and how should be changed for what I have in mind. Im a newbie in this specific world.
... I'd start with the RIPE document store at: http://www.ripe.net/ripe/docs As I don't really know what section might be the one, I go for all current documents: http://www.ripe.net/ripe/docs/current-ripe-documents/all-current-ripe-docume... As I strive down the list, ripe-606 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" looks like a hit: http://www.ripe.net/ripe/docs/ripe-606 Skipping the reasoning for all this in the first four chapters, I go straight to the fifth chapter "Policies and Guidelines for Allocations" at: http://www.ripe.net/ripe/docs/ripe-606#5 Here, part "5.1 Allocations made by the RIPE NCC to LIRs" looks as THE target for your proposal of text injection/deletion/modification.
Im here to find support on how to do it in the correct way.
You have gotten according advice at least three times so far.
[...] Also a PDO told me if i was in the need of help, but I told to wait, since doing it without first discussing it here is like doing in the back of the community and I dont want that.
Doing it "in the back of the community" as you are afraid of is simply impossible. You will be entering the community stage with a proper proposal - anything else is just preliminaries to it. Feeling the water temperature is OK. Discussing the water temperature is not. Either you let the cold water go to refill the tub with warmer one - or you add some hot water. Cheers, -C.
On 03/07/14 15:38, Carsten Schiefner wrote:
And for the records: count me in as #7 if you wish - I remain fully unconvinced for the time being.
here's #8 :) Cheers, jan
And #9... Cheers, Robert
Am 03.07.2014 um 17:28 schrieb "Jan Zorz @ go6.si" <jan@go6.si>:
On 03/07/14 15:38, Carsten Schiefner wrote: And for the records: count me in as #7 if you wish - I remain fully unconvinced for the time being.
here's #8 :)
Cheers, jan
On 3 July 2014 16:32, <Robert.Guentensperger@swisscom.com> wrote:
And #9...
Cheers, Robert
Am 03.07.2014 um 17:28 schrieb "Jan Zorz @ go6.si" <jan@go6.si>:
On 03/07/14 15:38, Carsten Schiefner wrote: And for the records: count me in as #7 if you wish - I remain fully unconvinced for the time being.
here's #8 :)
+1 -- James Blessing 07989 039 476
Hi, On Thu, Jul 03, 2014 at 05:27:51PM +0200, Jan Zorz @ go6.si wrote:
On 03/07/14 15:38, Carsten Schiefner wrote:
And for the records: count me in as #7 if you wish - I remain fully unconvinced for the time being.
here's #8 :)
For the sake of general sanity: please stop *that*. I think from a community consensus building pov, we have had clear feedback that if this is to be considered as a policy at all, it needs to be fleshed out in much more specific detail, also taking the cons into account. As in: - who will get extra address space? exactly under which conditions? - why is this helping? - what will be the consequences to routing table size, address pool, newcomers to the market in 5, 10 years? Even with a very specific proposal on the table (which would not need to describe the specific paragraphs to be changed in the RIPE policy documents, just the very exact "rules" to be followed - think of it as an algorithm for people to follow), I'm not sure it will go anywhere, but it would at least address some of the feedback given so far. I do not think further comments basically repeating what has been said before will change the situation. Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, I've changed my email address in the list. El 03/07/2014 17:38, Gert Doering escribió:
I think from a community consensus building pov, we have had clear feedback that if this is to be considered as a policy at all, it needs to be fleshed out in much more specific detail, also taking the cons into account.
As in:
- who will get extra address space? exactly under which conditions?
New LIRs created after 14th of September 2012 will recieve extra address up to another /22 (in lesser chunks) if they can: - Prove they really need the space, not only looking at assignements - In the cases of dhcp, the lease time are set to minimum possible without saturating their networks with dhcp messages. - Prove they have IPv6 5 star ripeness, IPv6 provisioned and deployed from the core network to customer (customers with compatible equipment should be able to connect with IPv6)
- why is this helping? Will help in giving time (determined by the LIR grow) to the transition from IPv4 to IPv6 to be the main protocol. In some cases it will give years, in others not so much but Im sure any time given will be appreciated. At this time, maybe 99% of new LIRs are not going to be big telcos with million customers so another 1024 address are giving they lot of time. - what will be the consequences to routing table size, address pool, newcomers to the market in 5, 10 years? This will only affect to new LIRs who started after 14th of September 2012 since they are the only ones having an unique allocation of /22 the address pool. I cant find how to see how many LIRs are being affected. The only graph I have found (https://labs.ripe.net/statistics/number-of-lirs) dont let me know the exact numbers, but there are arround 1.5k to 2k LIRs. Taking the highest number, 2.000 LIRs and taking in consideration all of them meet the requirements is 2,048M address. Our current pool have arround 18M address, if all new LIRs from today request the 2 allocations thats makes the possibility of having arround 8857 new LIRs. Again, in the LIRs graph cant see it well but I think we have 1k LIRs year. Thats makes, in the "worst" of the cases, 8 years of available IP space without taking in count if IANA returns more space. I dont really know how can affect the routing table if we reduce the minimun allocation to /23 or /24 (/24 seems to be auto discarded as Gert Doering said in previous emails) but I know there are lots of /23 announces in routing tables so I think the impact is not going to be really high. Even with a very specific proposal on the table (which would not need to describe the specific paragraphs to be changed in the RIPE policy documents, just the very exact "rules" to be followed - think of it as an algorithm for people to follow), I'm not sure it will go anywhere, but it would at least address some of the feedback given so far.
I do not think further comments basically repeating what has been said before will change the situation.
Thanks Gert for stopping that. I really appreciate it, even as I started it by mistake. Hope I answered your questions in a good way. Please, I did quick maths with this, Im really busy today and for the next week, but If any of you see I have made a mistake in any number, please feel free to correct it. Also, feel free to make any changes. Kind Regards, -Daniel
Hi, On Fri, Jul 04, 2014 at 01:30:03PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote:
El 03/07/2014 17:38, Gert Doering escribió:
I think from a community consensus building pov, we have had clear feedback that if this is to be considered as a policy at all, it needs to be fleshed out in much more specific detail, also taking the cons into account.
As in:
- who will get extra address space? exactly under which conditions? New LIRs created after 14th of September 2012 will recieve extra address up to another /22 (in lesser chunks) if they can: - Prove they really need the space, not only looking at assignements - In the cases of dhcp, the lease time are set to minimum possible without saturating their networks with dhcp messages. - Prove they have IPv6 5 star ripeness, IPv6 provisioned and deployed from the core network to customer (customers with compatible equipment should be able to connect with IPv6)
How can RIPE NCC IPRAs verify that these requirements are met? How can you prevent abuse? (Like, "all 1024 addresse must respond to ping!" - that's more easily achieved by faking it than if you connect real customers that have firewalls...) Rulese need to be a) easily verifable for someone not at your network, and b) not so easy to just circumvent. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, El 04/07/2014 13:53, Gert Doering escribió:
How can RIPE NCC IPRAs verify that these requirements are met?
How can you prevent abuse? (Like, "all 1024 addresse must respond to ping!" - that's more easily achieved by faking it than if you connect real customers that have firewalls...)
Rulese need to be a) easily verifable for someone not at your network, and b) not so easy to just circumvent.
Is that the only problem? Was hoping more... :) How was it done before? How ppl used to prove they needed more space? -Daniel
(As there is now a concrete proposal, I am replying again) On Fri, Jul 4, 2014 at 5:00 PM, Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> wrote:
Is that the only problem? Was hoping more... :)
IMO those are huge issues.
How was it done before? How ppl used to prove they needed more space?
There was less incentive to cheat in the past. Now, there's all sorts of desperation and the issue will only become worse over time. I fear this approach will either create huge administrative burdens or be easy to exploit... Richard
PS: There is no automatic cut-off if reserve X is hit. Does this mean you are expecting the depletion rate to roughly double? If not, what other rate do you expect and how is that run-out planned? This would need to be part of such a proposal, imo. Richard
Hi all, El 04/07/2014 17:10, Richard Hartmann escribió:
(As there is now a concrete proposal, I am replying again)
On Fri, Jul 4, 2014 at 5:00 PM, Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> wrote:
Is that the only problem? Was hoping more... :)
IMO those are huge issues.
Haha, of course, that was a joke.
How was it done before? How ppl used to prove they needed more space?
There was less incentive to cheat in the past. Now, there's all sorts of desperation and the issue will only become worse over time.
I fear this approach will either create huge administrative burdens or be easy to exploit...
PS: There is no automatic cut-off if reserve X is hit. Does this mean you are expecting the depletion rate to roughly double? If not, what other rate do you expect and how is that run-out planned? This would need to be part of such a proposal, imo.
Nice suggestion. As I said, the depletion in the worst of the cases and not taking in count if IANA returns more space in the future was ~8 years from now. And as you said, there should be a "cut-off" for reserve. I'll re-do the "proposal" as soon as I can. About "How to prove" problem, let me think about It but its very welcome anyone with a suggestion for this or any other point in the proposal.
Richard
-- Daniel Baeza Centro de Observación de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza@tvt-datos.es -- [Atención] La información contenida en este e-mail es confidencial, privilegiada y está dirigida exclusivamente a su destinatario. Cualquier revisión, difusión, distribución o copiado de este mensaje sin autorización del propietario está prohibido. Si ha recibido este e-mail por error por favor bórrelo y envíe un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario.
At Mon, 07 Jul 2014 12:11:10 +0200, Daniel Baeza (Red y Sistemas TVT) wrote:
And as you said, there should be a "cut-off" for reserve.
What I understand is that we have reached the cut-off point and are using the reserve up, one /22 at a time, according to consensus-based policy. I'll be happy to be corrected in case I'm mistaken. Best regards, Niall O'Reilly
Hi Niall, Op 8 jul. 2014, om 11:18 heeft Niall O'Reilly <niall.oreilly@ucd.ie> het volgende geschreven:
At Mon, 07 Jul 2014 12:11:10 +0200, Daniel Baeza (Red y Sistemas TVT) wrote:
And as you said, there should be a "cut-off" for reserve.
What I understand is that we have reached the cut-off point and are using the reserve up, one /22 at a time, according to consensus-based policy.
I'll be happy to be corrected in case I'm mistaken.
You are not mistaken. Cheers, Sander
Hi Daniel, Op 4 jul. 2014, om 17:00 heeft Daniel Baeza (Red y Sistemas TVT) <d.baeza@tvt-datos.es> het volgende geschreven:
El 04/07/2014 13:53, Gert Doering escribió:
How can RIPE NCC IPRAs verify that these requirements are met?
How can you prevent abuse? (Like, "all 1024 addresse must respond to ping!" - that's more easily achieved by faking it than if you connect real customers that have firewalls...)
Rulese need to be a) easily verifable for someone not at your network, and b) not so easy to just circumvent.
Is that the only problem? Was hoping more... :)
Probably no the only one, just the first one :) It's one of the major problems here. Almost everybody has need for more addresses, so there need to be clear and implementable rules about what is 'enough need'. Is 'I have 500 customers that don't want to be behind NAT' good enough?
How was it done before? How ppl used to prove they needed more space?
Show which assignments you are going to make, why the assignments need to be the size you give them (how many devices are connected etc). Most of the policy for this has been removed as the need to document all this became an unnecessary bureaucratic burden when the current policy gives every LIR a fixed /22 allocation if they need any IPv4 addresses anyway. See http://www.ripe.net/ripe/policies/proposals/2013-03 for the clean-up policy. One of the things people seem concerned about is re-introducing that bureaucratic burden again. Because how can you prove you need more than a /22 when you don't have to justify how you used the /22? You could then just use up the /22 in any way you like and then demand 'I now need more'. There are more side effects to giving LIRs more than a single /22 than you think :) Cheers, Sander
Daniel Baeza (Red y Sistemas TVT) wrote: [...]
Again, in the LIRs graph cant see it well but I think we have 1k LIRs year. Thats makes, in the "worst" of the cases, 8 years of available IP space without taking in count if IANA returns more space.
Allocations made under the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA are scheduled to take place every six months, as required in the policy. The formula for making the allocations has been put into software which has been published: https://github.com/icann/ipv4-recovery-algorithm What cannot be predicted is whether the RIRs will be returning more address space to the IANA IPv4 Recovered Address Space registry (http://www.iana.org/assignments/ipv4-recovered-address-space). However, if that does happen you can run the published software and see exactly how it will be distributed. Regards, Leo Vegoda
Hi Leo, Thanks for your reply. Since nobody knows if IANA is going to give more or how much space to RIRs from the returned pool, I was not taking in count IANAs possibility of returning space. If IANA, every six months, returns more space it will give more time till full depletion. Regards, El 04/07/2014 17:35, Leo Vegoda escribió:
Daniel Baeza (Red y Sistemas TVT) wrote:
[...]
Again, in the LIRs graph cant see it well but I think we have 1k LIRs year. Thats makes, in the "worst" of the cases, 8 years of available IP space without taking in count if IANA returns more space.
Allocations made under the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA are scheduled to take place every six months, as required in the policy. The formula for making the allocations has been put into software which has been published: https://github.com/icann/ipv4-recovery-algorithm
What cannot be predicted is whether the RIRs will be returning more address space to the IANA IPv4 Recovered Address Space registry (http://www.iana.org/assignments/ipv4-recovered-address-space). However, if that does happen you can run the published software and see exactly how it will be distributed.
Regards,
Leo Vegoda
-- Daniel Baeza Centro de Observación de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza@tvt-datos.es -- [Atención] La información contenida en este e-mail es confidencial, privilegiada y está dirigida exclusivamente a su destinatario. Cualquier revisión, difusión, distribución o copiado de este mensaje sin autorización del propietario está prohibido. Si ha recibido este e-mail por error por favor bórrelo y envíe un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario.
Hi Daniel, Daniel Baeza (Red y Sistemas TVT) wrote: [...]
Thanks for your reply. Since nobody knows if IANA is going to give more or how much space to RIRs from the returned pool, I was not taking in count IANAs possibility of returning space.
This community helped decide the policy that ICANN, as the IANA functions operator, implements. In general, the policies for allocating Internet Number Resources to the RIRs are deterministic. Kind regards, Leo
Hi Leo, El 07/07/2014 16:20, Leo Vegoda escribió:
Hi Daniel,
This community helped decide the policy that ICANN, as the IANA functions operator, implements. In general, the policies for allocating Internet Number Resources to the RIRs are deterministic.
Yeah I know. What I mean is we really dont know if IANA is going to give more address to RIRs since nobody knows if IANA is going to recieve more "unused" space. For that I didnt have in count what IANAs is going to do. I dont know if im expressing well or otherwise Im not understanding you. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza@tvt-datos.es -- [Atención] La información contenida en este e-mail es confidencial, privilegiada y está dirigida exclusivamente a su destinatario. Cualquier revisión, difusión, distribución o copiado de este mensaje sin autorización del propietario está prohibido. Si ha recibido este e-mail por error por favor bórrelo y envíe un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario.
Hi Daniel,
So, Are we going to keep 18.11 Million address for new LIRs?. Thats makes 17685 new lirs, way more than double as we have now...sorry but that is ridiculous when we have LIRs with v4 allocation problems.
The RIPE NCC is currently growing with ±1200 new members a year, and that rate is even accelerating a bit. The amount mentioned above will be enough for ±10 years. Of course there will be some extra addresses that are returned to the RIPE NCC, so let's say 10 to 12 years. Can you be completely certain that a new LIR in 2025 won't need *any* IPv4 addresses? The whole internet must have transitioned to IPv6 by then because they won't have any IPv4 addresses for their DNS servers and resolvers, NAT boxes etc. That is why everybody is so careful about this. What you call ridiculous might be less than we might actually need in the long run... Cheers, Sander
On 2 Jul 2014, at 16:01, "Dpto. Datos Television Costa Blanca" <datos@tvt-datos.es> wrote:
Are we going to keep 18.11 Million address for new LIRs?. Thats makes 17685 new lirs, way more than double as we have now...
Your reasoning is flawed. Each of the existing LIRs should be able to get their final /22 of v4. [I don't know or care how many have done that yet.] That accounts for about 10M of the 16M addresses in the NCC's last /8. It might even be less than that if some of those final /22s can come out of the space that's stuffed down the back of the NCC's sofa: eg any as yet unallocated blocks lurking in the other /8s that IANA issued years ago. Worst case, there's 6M addresses remaining for ~6000 new LIRs. The NCC gets ~1000 new LIRs each year. So there's enough available v4 for at least 6 years assuming current behaviour continues. Seems enough. YMMV.
sorry but that is ridiculous when we have LIRs with v4 allocation problems.
It's not. What *is* ridiculous IMO is making a request to change the current address policy without presenting any evidence why that policy is "broken" or how a change will "fix" whatever as yet unspecified problem needs fixing. What exactly are those allocation problems? How will they be fixed by handing out more v4 space? Why can't they be fixed in other ways? eg IPv6 on everything. You've not given any clear description of the problem. Saying vague things like "another /22 will give more than double time" are meaningless and unhelpful. Double what time? Why? And why double time, why not 10 times or 0.1 times? Where's the hard data? How come nobody else AFAICT is speaking up in support of your claims about allocation problems? If these problems were widespread and not just an isolated incident on your net, we should be hearing about them here. Your logic(?) here seems to be: "I'm going to stop smoking. But if you give me another packet of cigarettes I'll try to stop once they're done." The basic facts are unchanged. To all intents and purposes there is no more v4. Further discussion of v4 allocation policy is therefore like two bald men arguing over a comb. No amount of tweaking is going to change the fact there is essentially no more v4 to allocate. Or that LIRs have to face up to the conseqences there is no more v4. BTW it might be worth reading up on "the tragedy of the commons". You might also want to read the AP list archives and track the discussions which led to the adoption of the current policy. As I said before, please present a sound and compelling case for changing the current policy. Simply saying "it doesn't help me/my network" or "I want to have more time to finish my IPv6 transition" is not enough. You seem to be saying "I want a pony and I want one now". Well, you're not going to get a pony until you can make a valid case why you must have one and why other pets or means of transport can't be substitutes for that pony. :-) It would also help if your policy proposal clearly explained what an LIR could do with that extra /24 (say) that they couldn't already do with their final /22.
Hi, On Wed, Jul 02, 2014 at 05:01:19PM +0200, Dpto. Datos Television Costa Blanca wrote:
So, unless address space is returned to IANA (we don't have a policy for returning RIR space to IANA at the moment, but we might) the whole 1.08 >/8 will eventually be allocated as /22s.
So, Are we going to keep 18.11 Million address for new LIRs?.
This is current policy.
Thats makes 17685 new lirs, way more than double as we have now...sorry but that is ridiculous when we have LIRs with v4 allocation problems.
Actually, it's called "reasonable stewardship", at least trying to do so: make sure that a new LIR in 10 years time can still get their /22 as well. The number "/22" was based on the current number of LIRs and growth estimates, and we could well be up at 25.000 in 10 years. (I'm not voicing an opinion on the actual proposal, just explaining that the current policy didn't happen "by accident" but after quite some debate, and was found by consensus. For the existing LIRs back then, "just give it all to the existing LIRs and stop thinking IPv4" would have been much more straightforward, but I'm sure you'd have not liked it any better) Gert Doering -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
On 02/07/14 13:23, Dpto. Datos Television Costa Blanca wrote:
The non-expensive way to overcome the time betwen today and the day IPv6 is the dominant protocol is giving more space to those new lirs that need it.
The "non-expensive" way how to further delay the IPv6 implementation. Not every ISP is fully IPv6 ready yet and this sort of exercise would just postpone the action. Let's look at the IPv4 exhaustion problem from a different perspective - it's an accident that already happened, just that all parts did not stop moving yet... :) Cheers, Jan
W dniu 2014-07-02 12:56, Erik Bais pisze:
If you require additional space, other options are :
- Transfer Market
Dangerous, you can easily fall victim to fraud, especially on legacy resources, and RIPE will do nothing to help you.
- setup a new LIR
It is not obvious. I have an official position from Johem de Ruig that the new LIR does not always get the allocation.
- buy an existing LIR that is moving out of business.
Same as above. RIPE NCC simply just can not accept the transfer, and you're cooked hard. Regards TS
El 02/07/2014 19:25, Tomasz Śląski GMAIL escribió:
W dniu 2014-07-02 12:56, Erik Bais pisze:
If you require additional space, other options are :
- Transfer Market
Dangerous, you can easily fall victim to fraud, especially on legacy resources, and RIPE will do nothing to help you. True
- setup a new LIR
It is not obvious. I have an official position from Johem de Ruig that the new LIR does not always get the allocation. Very true
- buy an existing LIR that is moving out of business.
Same as above. RIPE NCC simply just can not accept the transfer, and you're cooked hard. And...also true too!
Finally someone that understand me! Regards! -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Hi, you will probably say - you represent a broker so you will not win anything if companies will get an additional /22 for free ( someone already said that in a previous message - using more or less these words) and therefore that is why you are against the proposal. I will respond saying that Brokers do not really handle /22 transactions. The amount of work done by a Broker for a transfer takes a lot of time. The commission received from a /22 transfer is so tiny that it's not really worth it. I'd also like to provide my input to a few statements below: On 02/07/14 21:01, Dpto. Datos Television Costa Blanca wrote:
El 02/07/2014 19:25, Tomasz Śląski GMAIL escribió:
W dniu 2014-07-02 12:56, Erik Bais pisze:
If you require additional space, other options are :
- Transfer Market
Dangerous, you can easily fall victim to fraud, especially on legacy resources, and RIPE will do nothing to help you. True
- setup a new LIR
It is not obvious. I have an official position from Johem de Ruig that the new LIR does not always get the allocation.
Very true Any new LIR will receive a /22 allocation as long as they can justify
I would say that it is only dangerous if you have never done business before. You should never pay in advance for something that you have not yet received. Various types of Escrow agreements or Bank Guarantee Letters are used, usually, when an IPv4 allocation is transferred. These are processes that do not involve the RIPE NCC but which make the transfers happen. Brokers are happy to assist with these processes. the use of at least one IP address. The policy is very simple in this regard. Off course, if you just open a new LIR to trick the system, you may end up not having a justification for that /22 (or that one IP). On the other hand, what stops you from opening a new company in a group for every 1000 customers? ;)
- buy an existing LIR that is moving out of business.
Same as above. RIPE NCC simply just can not accept the transfer, and you're cooked hard.
And...also true too!
RIPE NCC can not refuse the merger between two companies. If proper documentation is provided and (again) they do not smell the attempt of fraud, they will process and merge two LIRs easily. It is when you try to fraud or trick the system that you are 'cooked hard'. To conclude, my point of view is that we already have a process that works and that will provide the minimum amount of IP addresses to any start-up company for years to come. I do not have my crystal ball with me to see whether this will be for 1, 5, 10 or 20 years. I hope it will be for 20 years rather than 5. I say, let's keep the policy as is. Changing it from /22 to /21 will bring the pool down to 0 sooner than we expect and that may have really bad consequences for any new start-up registered in the RIPE Region. Kind regards, elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.
W dniu 2014-07-03 00:22, Elvis Daniel Velea pisze:
I would say that it is only dangerous if you have never done business before. You should never pay in advance for something that you have not yet received. Various types of Escrow agreements or Bank Guarantee Letters are used, usually, when an IPv4 allocation is transferred. These are processes that do not involve the RIPE NCC but which make the transfers happen. Brokers are happy to assist with these processes.
What do you say about situation: you bought, the transfers are made successfully, you paid after transfers, and suddenly after 8-12 months after transaction you see deletion and revert on the objects, because RIPE says that they were sold by a cheater. RIPE is not trying to help, they only said, that is because a due diligence process. My question is, where was the due diligence *during* the approved transfer?
Any new LIR will receive a /22 allocation as long as they can justify the use of at least one IP address. The policy is very simple in this regard.
Again - this is not obvious. What about a situation that you are paying for setting up a LIR and then you do not get allocation, even though you show its need? And in the dispute you get the answer: "By signing the RIPE NCC Standard Service Agreement you only become a member. The membership fee covers the membership alone. Whether you receive an IP allocation is being separately reviewed." Regards Tomasz Slaski
W dniu 2014-07-03 00:22, Elvis Daniel Velea pisze:
I would say that it is only dangerous if you have never done business before. You should never pay in advance for something that you have not yet received. Various types of Escrow agreements or Bank Guarantee Letters are used, usually, when an IPv4 allocation is transferred. These are processes that do not involve the RIPE NCC but which make the transfers happen. Brokers are happy to assist with these processes.
What do you say about situation: you bought, the transfers are made successfully, you paid after transfers, and suddenly after 8-12 months after transaction you see deletion and revert on the objects, because RIPE says that they were sold by a cheater. RIPE is not trying to help, they only said, that is because a due diligence process. My question is, where was the due diligence *during* the transfer?
Any new LIR will receive a /22 allocation as long as they can justify the use of at least one IP address. The policy is very simple in this regard.
Again - this is not obvious. What about a situation that you are paying for setting up a LIR and then you do not get allocation, even though you show its need? And in the dispute you get the answer: "By signing the RIPE NCC Standard Service Agreement you only become a member. The membership fee covers the membership alone. Whether you receive an IP allocation is being separately reviewed." Regards Tomasz Slaski
can we have a wiki, https://whack-a-mole.ripe.net/... so we do not have to repeat these discussions? we could just point to the last time we went through this. ramdu
I'm nearly sorry for this late tackle, but I'll just use my honeymoon as a valid excuse. ;) On Thu, Jul 3, 2014 at 9:02 AM, Randy Bush <randy@psg.com> wrote:
can we have a wiki, https://whack-a-mole.ripe.net/... so we do not have to repeat these discussions? we could just point to the last time we went through this.
That's how I felt when the subject came up earlier this year, and I haven't been here long. However, new list members should be able to address their questions and worries in some way. Regretfully, I don't see an easy way to point to the mailing list archives for the discussion either, because there have been several (many, as far as I can tell) discussions, but perhaps the list of archived proposals would give Daniel a certain overview of what's been going on in the past years, as well as access to the assessments of each policy proposal. It's a huge task to go through these, to be sure, but I think it's necessary when Daniel wants to change the policy that he's at least familiar with the past 4-5 years' worth of policy proposals did and didn't evolve into the current policy. Archived proposals: https://www.ripe.net/ripe/policies/archived-policy-proposals/archive-policy-... Current proposals: https://www.ripe.net/ripe/policies/current-proposals/current-policy-proposal... A few examples that may be relevant to Daniel's concern: There is, of course, "Allocations from the last /8" from 2010 (before my time): https://www.ripe.net/ripe/policies/proposals/2010-02 The "run out fairly" policy: https://www.ripe.net/ripe/policies/proposals/2012-06 There is the policy proposal about PI assignments from the last /8, which was withdrawn: https://www.ripe.net/ripe/policies/proposals/2012-04 (Discussions: https://www.google.no/search?q=address-policy-wg+archives+PI+Assignments+fro... ) There is the proposal about removing the requirement for a minimum allocation size: https://www.ripe.net/ripe/policies/proposals/2014-01 Also the post-depletion adjustment to the policy, which also saw some relevant discussion, particularly concerning "need", which I think bears some relevance to Daniel's arguments about how to tell whether someone should get an additional /24: https://www.ripe.net/ripe/policies/proposals/2013-03 There are other proposals which may be relevant, the above are just examples. I would wish that each proposal had links to archived discussion threads, but that's just wishful thinking now – Google is our friend in finding these old discussions, based on e.g. the policy text title and key phrases in the policy change text. -- Jan
Hi, On Thu, Jul 03, 2014 at 08:42:53AM +0200, Tomasz ??l??ski GMAIL wrote:
W dniu 2014-07-03 00:22, Elvis Daniel Velea pisze:
I would say that it is only dangerous if you have never done business before. You should never pay in advance for something that you have not yet received. Various types of Escrow agreements or Bank Guarantee Letters are used, usually, when an IPv4 allocation is transferred. These are processes that do not involve the RIPE NCC but which make the transfers happen. Brokers are happy to assist with these processes.
What do you say about situation: you bought, the transfers are made successfully??????, you paid after transfers, and suddenly after 8-12 months after transaction you see deletion and revert on the objects, because RIPE says that they were sold by a cheater. RIPE is not trying to help, they only said, that is because a due diligence process. My question is, where was the due diligence *during* the approved transfer?
If the NCC approved the transfer, and months later takes the addresses away without any fault on the side of the receiving party, I'd bring that up before the board or before the RIPE arbiters. This is not what should happen (but without more background information, nobody on this mailing list will be able to say more).
Any new LIR will receive a /22 allocation as long as they can justify the use of at least one IP address. The policy is very simple in this regard.
Again - this is not obvious. What about a situation that you are paying for setting up a LIR and then you do not get allocation, even though you show its need? And in the dispute you get the answer: "By signing the RIPE NCC Standard Service Agreement you only become a member. The membership fee covers the membership alone. Whether you receive an IP allocation is being separately reviewed."
This statement is fully correct. The /22 allocation is not automatic, you have to send in a request, and meet the criteria - which are not very many these days ("must have an IPv6 allocation", and even that is being softened to avoid a few corner cases). Depending on the time this was sent, you might have failed to demonstrate need (which was abandoned earlier this year, but that's a fairly recent change), or not have requested an IPv6 allocation yet. Again: bring it up to the arbiters. That's what they are there for - neutral oversight. Gert Doering -- NetMaster -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
W dniu 2014-07-03 09:14, Gert Doering pisze:
If the NCC approved the transfer, and months later takes the addresses away without any fault on the side of the receiving party, I'd bring that up before the board or before the RIPE arbiters. This is not what should happen (but without more background information, nobody on this mailing list will be able to say more).
The problem is, that this fraud cases is under investigation by the polish authorities and we signed one-copy NDA with them. As we explained to NCC many times, we cant disclose documents covered by NDA, additionaly regardless of confidentiality agreement signed when submitting evidence of fraud, the lawyers have warned, that the Polish criminal law in Article 241 § 1 of the Criminal Code states: "Whoever without authority distributes news and facts from investigation before they were disclosed in court proceedings, subject to the penalty of fine, or restriction of liberty, or imprisonment for 2 years".
This statement is fully correct. The /22 allocation is not automatic, you have to send in a request, and meet the criteria - which are not very many these days ("must have an IPv6 allocation", and even that is being softened to avoid a few corner cases). Depending on the time this was sent, you might have failed to demonstrate need (which was abandoned earlier this year, but that's a fairly recent change), or not have requested an IPv6 allocation yet.
All criteria are met. First of all we have an ASN and Ipv6 alloc. We need the v4 IP's because we are an small ISP and the bought IP's we lost. The NCC was not able and did not present any legal or contractual reasons to refuse v4 allocation to its member in this situation. Only reason was, that this is because of so-called fraud with v4 transfers. I can not agree with this, because RIPE NCC made this transfers, and after long time reverted it. I did possible to me checks of the seller, inclusive paid reports in relevant registers. And at this time I'm not sure, who really cheated me.
Again: bring it up to the arbiters. That's what they are there for - neutral oversight. Gert Doering -- NetMaster
Let's try. But I'm afraid that will be next loss of money. Regards Tomasz Slaski
Hi,
Nothing has been received in the last 12 months. The registry was last updated on 1 April 2013. The RIPE NCC returned some addresses earlier today and we have now registered them here: https://www.iana.org/assignments/ipv4-recovered-address-space. Those returned address, if Im not wrong, makes a total of the amazing amount of 21 /24's (5376 IPs)
Im sure there should be more returned addresses soon. The current IPv4 Address size recovered by IANA from RIRs is 18,204,416. If this is equally distribute to 5 RIRs, RIPE is expected to receive 3,640,883 after the global policy is activated. Those IPs, plus the ones we already have as Apr 21 (2.34 Millions) are 5.98 Millions on the reserved pool. That is more than a /10, close to a /9 (2 Millions more and is a /9) The reserved pool grew up from Mar 3 to Apr 7 from 1.58M to 2.29M (710k IP Addr) and only from Apr 7 to Apr 21 (2 weeks) it grew in 0.05Millions (50k Addrs) So, again I will ask. Should we discuss about making a policy like the APNIC's one??? (http://www.apnic.net/__data/assets/text_file/0006/62763/prop-105-v002.txt) Please, if I did the math wrong, punch me in the face!. Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Dpto. Datos Television Costa Blanca wrote: [...]
The reserved pool grew up from Mar 3 to Apr 7 from 1.58M to 2.29M (710k IP Addr) and only from Apr 7 to Apr 21 (2 weeks) it grew in 0.05Millions (50k Addrs)
This is suggesting that we have a sort of a steady or predictable flow of addresses back into the pool. Unfortunately, this is not the case. According to the IANA List, we had addresses returned between 2012-05 and 2012-08, nothing at all in 2013(!) and now the bunch of TWD /24s from RIPE in 2014-04. Wilfried
Hi Wilfried, El 23/04/2014 15:05, Wilfried Woeber escribió:
Dpto. Datos Television Costa Blanca wrote:
[...]
The reserved pool grew up from Mar 3 to Apr 7 from 1.58M to 2.29M (710k IP Addr) and only from Apr 7 to Apr 21 (2 weeks) it grew in 0.05Millions (50k Addrs) This is suggesting that we have a sort of a steady or predictable flow of addresses back into the pool. Unfortunately, this is not the case.
According to the IANA List, we had addresses returned between 2012-05 and 2012-08, nothing at all in 2013(!) and now the bunch of TWD /24s from RIPE in 2014-04. The thing is that the reserved pool is not only growing with the IANA returned pools. As you say, we hadnt recieved nothing in 2013 and nothing in 2014 until this month, but our reserved pool growed anyways and with a "good rate".
Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
2014-04-23 16:15 GMT+02:00 Dpto. Datos Television Costa Blanca < datos@tvt-datos.es>:
The thing is that the reserved pool is not only growing with the IANA returned pools. As you say, we hadnt recieved nothing in 2013 and nothing in 2014 until this month, but our reserved pool growed anyways and with a "good rate".
Could you please explain how zero growth for nearly two years is a "good rate"? -- Jan
Im not talking of the growth from 2 years ago, Im taking about 3rd March 2014 till today. El 23/04/2014 16:38, Jan Ingvoldstad escribió:
2014-04-23 16:15 GMT+02:00 Dpto. Datos Television Costa Blanca <datos@tvt-datos.es <mailto:datos@tvt-datos.es>>:
The thing is that the reserved pool is not only growing with the IANA returned pools. As you say, we hadnt recieved nothing in 2013 and nothing in 2014 until this month, but our reserved pool growed anyways and with a "good rate".
Could you please explain how zero growth for nearly two years is a "good rate"?
-- Jan
-- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos@tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).
Dpto. Datos Television Costa Blanca wrote: [....]
Have you more than a /22? Are you using IPv6? Are your customers IPv6 enabled? What will you do if you only have a /22?
Just fyi, as I do not intend to do advertising on this list, I sent the answers to Daniel's questions privately. Whoever wants to get a copy, just drop me a line :-) Wilfried.
participants (25)
-
-TOM-
-
Andre Keller
-
Carsten Schiefner
-
Daniel Baeza (Red y Sistemas TVT)
-
Dpto. Datos Television Costa Blanca
-
Elvis Daniel Velea
-
Elvis Velea
-
Erik Bais
-
Gert Doering
-
Hans Petter Holen
-
James Blessing
-
Jan Ingvoldstad
-
Jan Zorz @ go6.si
-
Jim Reid
-
Kennedy, James
-
Leo Vegoda
-
Mick O'Donovan
-
Niall O'Reilly
-
Randy Bush
-
Richard Hartmann
-
Robert.Guentensperger@swisscom.com
-
Sander Steffann
-
Tomasz Śląski GMAIL
-
Tore Anderson
-
Wilfried Woeber