From tore at fud.no Tue Apr 1 10:21:04 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 01 Apr 2014 10:21:04 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: References: Message-ID: <533A76F0.1000007@fud.no> * Marco Schmidt > https://www.ripe.net/ripe/policies/proposals/2014-02 I think it makes sense to allow PI transfers, at least when taking into account that we already do so for PA. So I'm generally supportive of this proposal A few comments though: 1) The new policy says: ?Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid?. What exactly are the implications of this requirement? I am assuming that the ?RIPE Registry? is not the RIPE DB; as the original criteria isn't documented in the RIPE DB to begin with. As I understand it, any criteria that somehow involves ?operating a network? is a valid assignment criteria (cf. section 3.0.3), with no requirement for specifics. I'm thinking that it might be better to simply say something along the lines of an assignment being valid for as long as it is being used according to the policy, rather than worrying about the ?original criteria? and how it possibly have changed. Most networks evolve and change over time; it wouldn't surprise me if a majority of assignments are now being used differently than originally documented in their associated assignment request form. That's not a bad thing though, is it? 2) Editorial: The new section 6.4 ?Transfers of PI space? appears to me to be pretty much a carbon copy of section 5.5 ?Transfers of Allocations? with a tiny bit changed here and there. Rather than duplicating all that text, would it not be better to move 5.5 out of section 5, and re-title and generalise it so that it applies equally to PI and PA? 3) The new section 6.4 speaks of ?Non-approved transfers?. Under which circumstances would a transfer not be approved, exactly? Do we really need this language anymore? (I'm regretting that 2013-03 didn't do away with it already. Oh well...) Tore From ebais at a2b-internet.com Tue Apr 1 11:47:34 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 1 Apr 2014 11:47:34 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <533A76F0.1000007@fud.no> References: <533A76F0.1000007@fud.no> Message-ID: <006801cf4d8f$70badbf0$523093d0$@a2b-internet.com> Hi Tore, > A few comments though: > 1) The new policy says: ?Changes to the original criteria must be > documented in the RIPE Registry, or the assignment will no longer be > considered valid?. What exactly are the implications of this > requirement? I am assuming that the ?RIPE Registry? is not the RIPE DB; > as the original criteria isn't documented in the RIPE DB to begin with. The new phrase as it states in the policy proposal is: - 6.3 Validity of an Assignment - An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be - considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid. There is indeed a difference with what we see in the RIPE DB and the actual RIPE Registry. (The RIPE back-end) The reason of why I kept it in the policy is, is to keep the original policy text as much as possible and not change entire PI criteria. The change to the original part is the deletion of: - If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. And also we kept the sentence that if PI assignments were requested in the past under false / falsified information and that those assignments can't be changed into a valid assignment via a transfer. Think in that respect about incorrect company information or false ID's etc. > As I understand it, any criteria that somehow involves ?operating a > network? is a valid assignment criteria (cf. section 3.0.3), with no > requirement for specifics. I'm thinking that it might be better to > simply say something along the lines of an assignment being valid for as > long as it is being used according to the policy, rather than worrying > about the ?original criteria? and how it possibly have changed. Most > networks evolve and change over time; it wouldn't surprise me if a > majority of assignments are now being used differently than originally > documented in their associated assignment request form. That's not a bad > thing though, is it? That is also why we removed the part in 6.4 that if an assignment is made for a specific purpose and that purpose no longer exist, the assignment is no longer valid. (in the policy proposal) > 2) Editorial: The new section 6.4 ?Transfers of PI space? appears to me > to be pretty much a carbon copy of section 5.5 ?Transfers of > Allocations? with a tiny bit changed here and there. Rather than > duplicating all that text, would it not be better to move 5.5 out of > section 5, and re-title and generalise it so that it applies equally to > PI and PA? Good point .. we spoke about this and decided to get this through and then (via a 2 phased approach) take the transfer parts away in a new proposal to get them changed into a new RIPE document (away from RIPE 606) During the Athens meeting it was agreed that I would propose a Transfer policy for PI. (that is what I've done) There are some other tasks that we came across during the prep for this proposal that I would like to fix (like the ability to transfer IPv6 and AS number resources), which would be able to in the above mentioned phase 2. > 3) The new section 6.4 speaks of ?Non-approved transfers?. Under which > circumstances would a transfer not be approved, exactly? Do we really > need this language anymore? (I'm regretting that 2013-03 didn't do away > with it already. Oh well...) Good point.. especially since the only non-approved PA transfer in the past, would under the current operations, be approved from what I've heard.. however the goal of this proposal is to get the same result for both IPv4 PA and PI space. That is also for instance why I kept the same restrictions as with PA and also the same reporting structure. It would make it a lot easier later to merge them together and get this in a separate Transfer document for all kinds of resources.. regardless of color of origin. Thanks for the feedback, Erik Bais From erik at bais.name Tue Apr 1 11:51:08 2014 From: erik at bais.name (Erik Bais) Date: Tue, 1 Apr 2014 09:51:08 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140324132317.DB224440B05@meelsurfur.a2b-internet.com> References: <20140324132317.DB224440B05@meelsurfur.a2b-internet.com> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91CB47979DF@E2010-MBX04.exchange2010.nl> > You can find the full proposal at: > http://www.ripe.net/ripe/policies/proposals/2014-01 Support +1 Erik Bais From tore at fud.no Tue Apr 1 12:50:02 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 01 Apr 2014 12:50:02 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <006801cf4d8f$70badbf0$523093d0$@a2b-internet.com> References: <533A76F0.1000007@fud.no> <006801cf4d8f$70badbf0$523093d0$@a2b-internet.com> Message-ID: <533A99DA.2030002@fud.no> * Erik Bais >> 1) The new policy says: ?Changes to the original criteria must be >> documented in the RIPE Registry, or the assignment will no longer be >> considered valid?. What exactly are the implications of this >> requirement? I am assuming that the ?RIPE Registry? is not the RIPE DB; >> as the original criteria isn't documented in the RIPE DB to begin with. > > The new phrase as it states in the policy proposal is: > - 6.3 Validity of an Assignment > > - An assignment is valid as long as the original criteria on which it was > based remain valid and it is properly registered in the RIPE Database. > Changes to the original criteria must be documented in the RIPE Registry, or > the assignment will no longer be > - considered valid. An assignment that was based on information that turns > out to be incorrect is no longer valid. > > There is indeed a difference with what we see in the RIPE DB and the actual > RIPE Registry. (The RIPE back-end) > The reason of why I kept it in the policy is, is to keep the original policy > text as much as possible and not change entire PI criteria. Yeah, I fully understand why you want to remove the requirement that the original criteria must be unchanged for the assignment to remain valid. This requirement was always completely out of touch with operational realities anyway. Good riddance! However, considering that the NCC no longer has any mandate to evaluate the validity of the given criteria, asking assignees to send updates to the NCC whenever they want to change the way the assignment is being used seems rather pointless to me. After all there's not much the NCC would do with that information except to archive it somewhere. If you want to allow people to change how they're using their assignments, then I'd prefer that you let them do so freely, without introducing any new bureaucracy and forms. If I may, here's my suggested version of a new 6.3: ?All assignments are valid as long they are properly registered in the RIPE Database. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.? > Good point .. we spoke about this and decided to get this through and then > (via a 2 phased approach) take the transfer parts away in a new proposal to > get them changed into a new RIPE document (away from RIPE 606) > During the Athens meeting it was agreed that I would propose a Transfer > policy for PI. (that is what I've done) > There are some other tasks that we came across during the prep for this > proposal that I would like to fix (like the ability to transfer IPv6 and AS > number resources), which would be able to in the above mentioned phase 2. Understood, thanks for elaborating. Tore From tom.norda at gmail.com Tue Apr 8 00:34:10 2014 From: tom.norda at gmail.com (Tom Norda) Date: Mon, 7 Apr 2014 23:34:10 +0100 Subject: [address-policy-wg] report address policy violation Message-ID: Hi: I know a RIPE member with an unused ipv4 /20 block not used in the last 2 years and i'm wondering if that's a RIPE community policy violation. I checked https://www.ripe.net/ripe/docs/current-ripe-documents/ripe-policiesbut i still have doubts if it is accepted or not. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From datos at tvt-datos.es Tue Apr 8 13:28:07 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Tue, 08 Apr 2014 13:28:07 +0200 Subject: [address-policy-wg] About the /22 allocation limitation Message-ID: <5343DD47.7060106@tvt-datos.es> 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=_RIR_LACNIC;s=_RIR_RIPE_NCC;s=ES ) 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 at 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). From ebais at a2b-internet.com Tue Apr 8 14:07:35 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 8 Apr 2014 14:07:35 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5343DD47.7060106@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> Message-ID: <00dc01cf5323$2975a3d0$7c60eb70$@a2b-internet.com> 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 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. 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 From sander at steffann.nl Tue Apr 8 17:18:43 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 8 Apr 2014 17:18:43 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5343DD47.7060106@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> Message-ID: <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> 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=_RIR_LACNIC;s=_RIR_RIPE_NCC;s=ES ) 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 From gert at space.net Tue Apr 8 21:41:13 2014 From: gert at space.net (Gert Doering) Date: Tue, 8 Apr 2014 21:41:13 +0200 Subject: [address-policy-wg] report address policy violation In-Reply-To: References: Message-ID: <20140408194113.GC43641@Space.Net> Hi, On Mon, Apr 07, 2014 at 11:34:10PM +0100, Tom Norda wrote: > I know a RIPE member with an unused ipv4 /20 block not used in the last > 2 years and i'm wondering if that's a RIPE community policy violation. I > checked https://www.ripe.net/ripe/docs/current-ripe-documents/ripe-policiesbut > i still have doubts if it is accepted or not. If it's an allocation, it's not a violation. There is no clause about returning allocations if you don't meet your growth estimates. gert -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Wed Apr 9 11:25:02 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 09 Apr 2014 11:25:02 +0200 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333EA69.7020403@schiefner.de> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <5333EA69.7020403@schiefner.de> Message-ID: <534511EE.7050807@schiefner.de> Hi Tore, all - On 27.03.2014 10:07, Carsten Schiefner wrote: > On 27.03.2014 09:34, Tore Anderson wrote: >> I'm just of the opinion that removing one without the other leaves the >> policy in a counter-intuitive state. To me it would appear appropriate >> for a proposal titled ?Abandoning the Minimum Allocation Size for IPv4? >> to remove all flavours of the minimum allocation size, including the one >> specific for sub-allocations. >> >> Besides, one of the two stated reasons for having the minimum >> sub-allocation size (?[/24] is the smallest prefix length that can be >> reverse delegated?) is quite simply false, given RFC 2317, and if we >> also accept the rationale for 2014-01, then we've essentially rejected >> the other reason too (?allows for a reasonable number of small >> assignments to be made?). > > fair points - I shall retreat to my thinking chamber once more. ;-) as I couldn't really come up with any good reason to keep the minimum SUB-allocation size in the policy, instead I was and still am able to follow your and others' reasoning to kick it out as well (although I also still believe these two are only loosely coupled :-), I have just filed a V2.0. Cheers, -C. From datos at tvt-datos.es Wed Apr 9 18:39:51 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Wed, 09 Apr 2014 18:39:51 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> Message-ID: <534577D7.8020300@tvt-datos.es> 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-pool-graph 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 at 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). From gert at space.net Wed Apr 9 20:15:53 2014 From: gert at space.net (Gert Doering) Date: Wed, 9 Apr 2014 20:15:53 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534577D7.8020300@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> Message-ID: <20140409181553.GK43641@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From datos at tvt-datos.es Thu Apr 10 11:46:26 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Thu, 10 Apr 2014 11:46:26 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <20140409181553.GK43641@Space.Net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> Message-ID: <53466872.3040103@tvt-datos.es> 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 at 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). From gert at space.net Thu Apr 10 11:50:28 2014 From: gert at space.net (Gert Doering) Date: Thu, 10 Apr 2014 11:50:28 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53466872.3040103@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> Message-ID: <20140410095028.GI43641@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From datos at tvt-datos.es Thu Apr 10 12:02:27 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Thu, 10 Apr 2014 12:02:27 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <20140410095028.GI43641@Space.Net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> Message-ID: <53466C33.1040107@tvt-datos.es> 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 at 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). From frettled at gmail.com Thu Apr 10 12:14:51 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 10 Apr 2014 12:14:51 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53466C33.1040107@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> Message-ID: 2014-04-10 12:02 GMT+02:00 Dpto. Datos Television Costa Blanca < datos at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Thu Apr 10 13:13:17 2014 From: tore at fud.no (Tore Anderson) Date: Thu, 10 Apr 2014 13:13:17 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53466C33.1040107@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> Message-ID: <53467CCD.3020506@fud.no> 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 From elvis at v4escrow.net Thu Apr 10 13:28:53 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 10 Apr 2014 13:28:53 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53467CCD.3020506@fud.no> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> Message-ID: <53468075.1070608@v4escrow.net> Hi, On 10/04/14 13:13, Tore Anderson wrote: > 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 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 -- Elvis Daniel Velea Chief Business Analyst Email: elvis at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From gert at space.net Thu Apr 10 13:30:49 2014 From: gert at space.net (Gert Doering) Date: Thu, 10 Apr 2014 13:30:49 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53466C33.1040107@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> Message-ID: <20140410113049.GM43641@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From frettled at gmail.com Thu Apr 10 13:50:57 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 10 Apr 2014 13:50:57 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <20140410113049.GM43641@Space.Net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <20140410113049.GM43641@Space.Net> Message-ID: On Thu, Apr 10, 2014 at 1:30 PM, Gert Doering 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From modonovan at btireland.net Thu Apr 10 13:36:41 2014 From: modonovan at btireland.net (Mick O'Donovan) Date: Thu, 10 Apr 2014 12:36:41 +0100 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <20140410113049.GM43641@Space.Net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <20140410113049.GM43641@Space.Net> Message-ID: <302BB2E1-D09A-4FFC-86A7-5D784F7EB3A9@btireland.net> > 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 From datos at tvt-datos.es Fri Apr 11 10:19:25 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Fri, 11 Apr 2014 10:19:25 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53468075.1070608@v4escrow.net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> Message-ID: <5347A58D.9060402@tvt-datos.es> Good morning all, >>> 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 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 at 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Fri Apr 11 11:23:57 2014 From: tore at fud.no (Tore Anderson) Date: Fri, 11 Apr 2014 11:23:57 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5347A58D.9060402@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> Message-ID: <5347B4AD.1080705@fud.no> * 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 From frettled at gmail.com Fri Apr 11 11:24:51 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 11 Apr 2014 11:24:51 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5347A58D.9060402@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> Message-ID: On Fri, Apr 11, 2014 at 10:19 AM, Dpto. Datos Television Costa Blanca < datos at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Apr 11 12:24:54 2014 From: gert at space.net (Gert Doering) Date: Fri, 11 Apr 2014 12:24:54 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: References: <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> Message-ID: <20140411102454.GN43641@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From datos at tvt-datos.es Fri Apr 11 12:37:15 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Fri, 11 Apr 2014 12:37:15 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5347B4AD.1080705@fud.no> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> <5347B4AD.1080705@fud.no> Message-ID: <5347C5DB.6080105@tvt-datos.es> 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 at 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). From sander at steffann.nl Fri Apr 11 13:44:03 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 11 Apr 2014 13:44:03 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5347C5DB.6080105@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> <5347B4AD.1080705@fud.no> <5347C5DB.6080105@tvt-datos.es> Message-ID: <87D3C015-092E-4F83-8C9B-F20A5AEDD006@steffann.nl> 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-201003-permonth-absolute-jagged(1).png. 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 From tore at fud.no Fri Apr 11 13:53:45 2014 From: tore at fud.no (Tore Anderson) Date: Fri, 11 Apr 2014 13:53:45 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5347C5DB.6080105@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> <5347B4AD.1080705@fud.no> <5347C5DB.6080105@tvt-datos.es> Message-ID: <5347D7C9.6060907@fud.no> * 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 From datos at tvt-datos.es Sat Apr 12 10:16:13 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Sat, 12 Apr 2014 10:16:13 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <87D3C015-092E-4F83-8C9B-F20A5AEDD006@steffann.nl> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> <5347B4AD.1080705@fud.no> <5347C5DB.6080105@tvt-datos.es> <87D3C015-092E-4F83-8C9B-F20A5AEDD006@steffann.nl> Message-ID: <5348F64D.2000705@tvt-datos.es> 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. 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. > 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 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 at 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). From gert at space.net Mon Apr 14 11:46:16 2014 From: gert at space.net (Gert Doering) Date: Mon, 14 Apr 2014 11:46:16 +0200 Subject: [address-policy-wg] APWG agenda for RIPE 68, first draft Message-ID: <20140414094616.GK43641@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Warsaw in the following time slots: Wednesday, May 14, 09:00 - 10:30 Wednesday, May 14, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Marco Schmidt, NCC RS - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE67 2013-03 Post-Depletion Reality Adjustment and Cleanup (consensus, policy) 2013-05 No Restrictions on End User Assignments in Intra-RIR Transfers (consensus, policy) 2013-06 PA/PI Unification IPv6 Address Space (withdrawn) - brief overview over new proposals (if any) E. On Personal Identity - for internet resources registered to natural persons, what level of identity verification does the community require from the RIPE NCC? - with (hopefully) lots of input from the Anti-Abuse WG, on what they see necessary - results will be presented to NCC services WG, as this is important for the "due dilligence" considerations of the NCC D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) (+ discussion with the group) [might be moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back G. On SHOULDs and MUSTs - RFC 2119 language in RIPE documents followup to RIPE 67, findings by Marco Schmidt and Jan Zorz F. Discussion of open policy proposals 2012-02 Policy for Inter-RIR transfers of IPv4 Address Space (which will hopefully be restarted until then) 2014-01 Abandoning the Minimum Allocation Size for IPv4 (Carsten Schiefner) 2014-02 Allow IPv4 PI transfer (Erik Bais) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From jkennedy at libertyglobal.com Mon Apr 14 13:28:54 2014 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Mon, 14 Apr 2014 11:28:54 +0000 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <87D3C015-092E-4F83-8C9B-F20A5AEDD006@steffann.nl> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> <5347B4AD.1080705@fud.no> <5347C5DB.6080105@tvt-datos.es> <87D3C015-092E-4F83-8C9B-F20A5AEDD006@steffann.nl> Message-ID: <13E63C78A6256E4A857726374FBF926E11D25B80@NLAMSPEXMB003.upcit.ds.upc.biz> 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 at ripe.net [mailto:address-policy-wg-bounces at 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 at 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-201003-permonth-absolute-jagged(1).png. 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 From hph at oslo.net Mon Apr 14 13:52:45 2014 From: hph at oslo.net (Hans Petter Holen) Date: Mon, 14 Apr 2014 14:52:45 +0300 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5347A58D.9060402@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> Message-ID: <534BCC0D.7000407@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. > > 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 at oslo.net | http://hph.oslo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From datos at tvt-datos.es Mon Apr 14 19:05:01 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Mon, 14 Apr 2014 19:05:01 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534BCC0D.7000407@oslo.net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <53466872.3040103@tvt-datos.es> <20140410095028.GI43641@Space.Net> <53466C33.1040107@tvt-datos.es> <53467CCD.3020506@fud.no> <53468075.1070608@v4escrow.net> <5347A58D.9060402@tvt-datos.es> <534BCC0D.7000407@oslo.net> Message-ID: <534C153D.4080705@tvt-datos.es> Hi Hans, El 14/04/2014 13:52, Hans Petter Holen escribi?: > 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 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 at 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Tue Apr 15 10:07:47 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 15 Apr 2014 10:07:47 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <20140409181553.GK43641@Space.Net> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> Message-ID: On Wed, Apr 9, 2014 at 8:15 PM, Gert Doering 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Tue Apr 15 10:09:50 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 15 Apr 2014 10:09:50 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <5339661b.c4e00e0a.0f77.ffff981eSMTPIN_ADDED_MISSING@mx.google.com> References: <5339661b.c4e00e0a.0f77.ffff981eSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: I am afraid that I didn't have time to review the text in-depth yet, but I agree with the general direction this is going. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From datos at tvt-datos.es Tue Apr 15 10:12:50 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Tue, 15 Apr 2014 10:12:50 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> Message-ID: <534CEA02.5000700@tvt-datos.es> Hi, El 15/04/2014 10:07, Richard Hartmann escribi?: > On Wed, Apr 9, 2014 at 8:15 PM, Gert Doering > 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 at 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Tue Apr 15 12:49:49 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 15 Apr 2014 12:49:49 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534CEA02.5000700@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Tue Apr 15 13:58:57 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 15 Apr 2014 13:58:57 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> Message-ID: <534D1F01.4070307@CC.UniVie.ac.at> 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. From datos at tvt-datos.es Tue Apr 15 17:34:46 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Tue, 15 Apr 2014 17:34:46 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534D1F01.4070307@CC.UniVie.ac.at> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> Message-ID: <534D5196.40700@tvt-datos.es> 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=_RIR_LACNIC;s=_RIR_RIPE_NCC 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 at 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). From gert at space.net Tue Apr 15 19:54:04 2014 From: gert at space.net (Gert Doering) Date: Tue, 15 Apr 2014 19:54:04 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534D5196.40700@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> Message-ID: <20140415175404.GH43641@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From jkennedy at libertyglobal.com Tue Apr 15 20:12:39 2014 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 15 Apr 2014 18:12:39 +0000 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534D5196.40700@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> Message-ID: <13E63C78A6256E4A857726374FBF926E11D263B2@NLAMSPEXMB003.upcit.ds.upc.biz> > 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 at ripe.net [mailto:address-policy-wg-bounces at 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=_RIR_LACNIC;s=_RIR_RIPE_NCC 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 at 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). From tore at fud.no Tue Apr 15 23:33:27 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 15 Apr 2014 23:33:27 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534D5196.40700@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> Message-ID: <534DA5A7.60208@fud.no> 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 From Woeber at CC.UniVie.ac.at Wed Apr 16 09:57:46 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 16 Apr 2014 09:57:46 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534D5196.40700@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> Message-ID: <534E37FA.4090205@CC.UniVie.ac.at> 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. From sander at steffann.nl Wed Apr 16 13:06:11 2014 From: sander at steffann.nl (Sander Steffann) Date: Wed, 16 Apr 2014 13:06:11 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534DA5A7.60208@fud.no> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> Message-ID: <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> 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 From richih.mailinglist at gmail.com Wed Apr 16 14:13:13 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Wed, 16 Apr 2014 14:13:13 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> Message-ID: 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.blessing at despres.co.uk Wed Apr 16 14:20:04 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 16 Apr 2014 13:20:04 +0100 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> Message-ID: On 16 April 2014 13:13, Richard Hartmann 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 From mestrada at ripe.net Thu Apr 17 13:46:18 2014 From: mestrada at ripe.net (Marisol Estrada) Date: Thu, 17 Apr 2014 13:46:18 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text" Message-ID: <534FBF0A.5010601@ripe.net> Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2013-03, "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text". In accordance with the new policy, the RIPE NCC will no longer require LIRs to complete a forecast-based documentation of need when requesting /22 IPv4 allocations, when making assignments to End Users, or when requesting approval for IPv4 transfers. Accordingly, this also means that the "Assignment Window" is no longer applicable. As a result, we have updated the following request forms and supporting notes: - IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-608 - Supporting Notes For The IPv4 First Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-609 - IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-610 - Supporting Notes for the IPv4 Additional Allocation Request Form: http://www.ripe.net/ripe/docs/ripe-611 Both the Provider Aggregatable (PA) Assignment Request Form and the Supporting Notes for Provider Aggregatable (PA) Assignment Request Form have also been removed due to this change. RIPE NCC members can still access the list of their past assignments approved by the RIPE NCC as well as their Assignment Window history, which is available in the "Archive" section of the LIR Portal. The IP Analyser functionality of the LIR Portal has been changed, as explained at: https://labs.ripe.net/Members/AlexBand/modifications-to-the-ip-analyser-to-reflect-new-policy The archived policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2013-03 The updated RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: http://www.ripe.net/ripe/docs/ripe-606 Kind regards Marisol Estrada RIPE NCC Registration Services From datos at tvt-datos.es Thu Apr 17 16:25:41 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Thu, 17 Apr 2014 16:25:41 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> Message-ID: <534FE465.7050605@tvt-datos.es> 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 at 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). From davidm at futureinquestion.net Thu Apr 17 22:02:15 2014 From: davidm at futureinquestion.net (David Monosov) Date: Thu, 17 Apr 2014 22:02:15 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) Message-ID: <53503347.5000206@futureinquestion.net> Dear address-policy-wg, With such a policy in place, IP address broker needs to offers potential IP space buyers only a marginally lower price than the cost of being a LIR for the expected duration of use of the IPv4 PI space in question (and requesting this IP space from the last /8 or realizing an inter-LIR PA transfer) in order to create a perverse incentive for IPv4 address buyers to line the pockets of IP address brokers instead of stepping up and becoming members of the RIPE NCC. This policy appears to fail the most basic economic incentive test, and will in practice create a secondary and desirable 'asset class' from which IP transfer brokers benefit considerably more than the community as a whole. To deconstruct the arguments which purportedly support this proposal: a) "Currently the policy for PA and PI space isn?t the same and people don?t understand the difference between the various types of IP Space." Ignoring that this is a superfluous argument which goes in the face of nearly two decades of policy, this appears to argue that letting PI space be sold would somehow eliminate this distinction. This, of course, is disingenuous. If this is indeed the goal, a policy should be introduced to allow PI space to be converted into PA space and assigned to a LIR - this will enable its "transferability" and eliminate many of the concerns raised above by ensuring that all holders of "transferred" IPv4 space are first rate LIRs who contribute financially toward the operation of the RIPE NCC and fall under all obligations imposed on such. b) "There is already some trade in PI space, however it is not documented or registered, which doesn?t help to keep the registry updated." This is also disingenuous, as every IPv4 PI space holder has a contract with the sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, regularly verify and update these details in cooperation with the registrant. c) "A lot of current PI space holders are more than happy to have their assignments re-assigned to other parties, but due to the current policy it is not possible. The same goes for the documentation provided to the RIPE NCC during mergers or acquisitions of infrastructure with PI space. Due to the current policy, some changes in company names are marked as mergers or acquisitions when they are actually a transfer of IP space with added documentation to make it look like an merger or acquisition of infrastructure." If a legitimate transfer has occurred as part of legitimate organizational restructuring, there is no disincentive to document it. The disincentive only exists if the registrant fears the transfer's legitimacy may be questioned, which is exactly the intention for non-transferable, end-user assigned PI space. Such transferred allocations could, and should, per current policy, be simply reclaimed. d) "We want to have an open and honest communication to the RIPE NCC from the community and we need to make sure that the registry is up to date, without having to fluff up the procedures, bend the rules and truth in communication to the RIPE NCC to be able to transfer the IP space." Alternatively, elements which "bend the rules and truth" could be identified, and, within reason, have their resources reclaimed. Certainly, such enforcement can never be perfect - but speed traps also do not catch 100% of speeding cars. With a few documented instances, this would create tremendous uncertainty and disincentive to engage in such practices from the buy side, as it will mean that any resources acquired in this manner may very suddenly get written off. e) "The goal of this policy change is to get PI space on-par with PA space in respect to the ability to transfer it." See (a). It seems very disingenuous to make PI and PA "equal for purposes of transferability" but maintain the distinction in all other aspects. To summarize, I strongly object to this policy in its current form. I concur that the mobility of IPv4 PI space toward those who value it most is desirable - on the condition that this mobility occurs as part of a wider reform to eliminate the distinction between PA and PI status of IPv4 resources. This should result in equitable burden for all resource holders toward the RIPE NCC instead of lining the pockets of IP address brokers by helping address space speculators which presently hoard IPv4 PI assignments against policy realize profits at the expense of the community. -- Respectfully yours, David Monosov From leo.vegoda at icann.org Thu Apr 17 22:49:25 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 17 Apr 2014 13:49:25 -0700 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <534FE465.7050605@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From elvis at v4escrow.net Fri Apr 18 00:59:23 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Fri, 18 Apr 2014 00:59:23 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53503347.5000206@futureinquestion.net> References: <53503347.5000206@futureinquestion.net> Message-ID: <53505CCB.40902@v4escrow.net> Hi David, On 17/04/14 22:02, David Monosov wrote: > Dear address-policy-wg, > > With such a policy in place, IP address broker needs to offers potential IP > space buyers only a marginally lower price than the cost of being a LIR for the > expected duration of use of the IPv4 PI space in question (and requesting this > IP space from the last /8 or realizing an inter-LIR PA transfer) in order to > create a perverse incentive for IPv4 address buyers to line the pockets of IP > address brokers instead of stepping up and becoming members of the RIPE NCC. > > This policy appears to fail the most basic economic incentive test, and will in > practice create a secondary and desirable 'asset class' from which IP transfer > brokers benefit considerably more than the community as a whole. There is already a market of IP addresses. Nobody will care about the color of the IP addresses once they will really need those numbers. > To deconstruct the arguments which purportedly support this proposal: > > a) "Currently the policy for PA and PI space isn?t the same and people don?t > understand the difference between the various types of IP Space." > > Ignoring that this is a superfluous argument which goes in the face of nearly > two decades of policy, this appears to argue that letting PI space be sold would > somehow eliminate this distinction. > > This, of course, is disingenuous. If this is indeed the goal, a policy should be > introduced to allow PI space to be converted into PA space and assigned to a LIR > - this will enable its "transferability" and eliminate many of the concerns > raised above by ensuring that all holders of "transferred" IPv4 space are first > rate LIRs who contribute financially toward the operation of the RIPE NCC and > fall under all obligations imposed on such. Are you saying that every holder of PI space should become an LIR before they could transfer it? Why would they pay ?3600 (1600 for the yearly membership and 2000 for the sign-up fee) to the RIPE NCC when they could just do it in a contract? Or are you saying that PI holders should just give their PI to the friendly LIR which can then convert it to PA and transfer it? Who will make the buck then? Should the PI holder retain any rights once the address is transferred to the 'friendy' LIR or will the LIR be allowed to just transfer the new allocation to whoever they want? > b) "There is already some trade in PI space, however it is not documented or > registered, which doesn?t help to keep the registry updated." > > This is also disingenuous, as every IPv4 PI space holder has a contract with the > sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, > regularly verify and update these details in cooperation with the registrant. let's think about this scenario..You are an LIR and you have 500 PI customers for which you are Sponsoring LIR, you will probably call the PI holder or send him an e-mail to verify that they still exist because at least once a year you will be paying a fee to the RIPE NCC for the maintenance of that PI. If the PI holder says that he still has the same contact details and the IP addresses are still used, what resources will you invest to verify that the holder of the address space is still the one documented in the RIPE Database? - do not forget, you (as LIR) pay ?50/year for the maintenance of the resource to the RIPE NCC and probably make (in average) ?25-50/year/resource yourself... I think that bringing in the registry/database all the PI transfers that currently happen without proper registration/update is the most important goal which this proposal will achieve. > c) "A lot of current PI space holders are more than happy to have their > assignments re-assigned to other parties, but due to the current policy it is > not possible. The same goes for the documentation provided to the RIPE NCC > during mergers or acquisitions of infrastructure with PI space. Due to the > current policy, some changes in company names are marked as mergers or > acquisitions when they are actually a transfer of IP space with added > documentation to make it look like an merger or acquisition of infrastructure." > > If a legitimate transfer has occurred as part of legitimate organizational > restructuring, there is no disincentive to document it. The disincentive only > exists if the registrant fears the transfer's legitimacy may be questioned, > which is exactly the intention for non-transferable, end-user assigned PI space. > Such transferred allocations could, and should, per current policy, be simply > reclaimed. Who will give up their address space? The numbers are now considered assets and may be worth a buck or two... Or would you rather see PI never transferable and the RIPE NCC reclaiming it when it's no longer needed? > d) "We want to have an open and honest communication to the RIPE NCC from the > community and we need to make sure that the registry is up to date, without > having to fluff up the procedures, bend the rules and truth in communication to > the RIPE NCC to be able to transfer the IP space." > > Alternatively, elements which "bend the rules and truth" could be identified, > and, within reason, have their resources reclaimed. Certainly, such enforcement > can never be perfect - but speed traps also do not catch 100% of speeding cars. Please come up with a proposal for this reclamation process; I'd really love to see it on the mailing list. > With a few documented instances, this would create tremendous uncertainty and > disincentive to engage in such practices from the buy side, as it will mean that > any resources acquired in this manner may very suddenly get written off. So, once the RIPE NCC would reclaim something that was transferred without it's approval, it should tell the whole world? What about the privacy of the communication that the RIPE NCC is so proud of? How would you document such an instance? > e) "The goal of this policy change is to get PI space on-par with PA space in > respect to the ability to transfer it." > > See (a). It seems very disingenuous to make PI and PA "equal for purposes of > transferability" but maintain the distinction in all other aspects. There will no longer be many distinction between PI and PA. The only one I can think of is that PA can be further assigned. Maybe we should come up with a policy proposal to allow PI sub-assignments and remove the differences between PA and PI in that process? I only see a problem, the same one I faced with IPv6 unification, the fee unification. > To summarize, I strongly object to this policy in its current form. > > I concur that the mobility of IPv4 PI space toward those who value it most is > desirable - on the condition that this mobility occurs as part of a wider reform > to eliminate the distinction between PA and PI status of IPv4 resources. This policy proposal is the first step, you could try and make the next step and propose a bigger change. From my experience (just last year) the community gets scared when you start talking about big changes (I was trying to unify IPv6 PA and PI, without even having all the conspiracy theory about brokers flying around my ears). These big changes will never work. > This should result in equitable burden for all resource holders toward the RIPE > NCC instead of lining the pockets of IP address brokers by helping address space > speculators which presently hoard IPv4 PI assignments against policy realize > profits at the expense of the community. IP brokers can and are already helping others to get the address space they need by brokering PA transactions. Why do you think that enabling IPv4 PI transfers will be the benefit of only the Brokers? I think this policy proposal is in the benefit of us all: - cleaner registry - all holders of address space (PA or PI) can monetize it equally ;) - remove any temptations to 'bend the rules' PS: I hope you do know that a transfer can happen without brokers having to be involved. Actually, I am under the impression that most of the transfers (in numbers of transfers and not of IPs) have been made by LIRs mutually agreeing to the transfer via the Listing Service and not via brokers/escrow. When it comes to large blocks and a lot of money, some prefer to have a broker in the middle, for the safety of both parties. > -- > Respectfully yours, > > David Monosov > Kind regards, Elvis -- Elvis Daniel Velea Chief Business Analyst Email: elvis at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From elvis at velea.eu Fri Apr 18 01:02:43 2014 From: elvis at velea.eu (Elvis Velea) Date: Fri, 18 Apr 2014 01:02:43 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> Message-ID: <53505D93.7080104@velea.eu> 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-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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidm at futureinquestion.net Fri Apr 18 02:17:19 2014 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 18 Apr 2014 02:17:19 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53505CCB.40902@v4escrow.net> References: <53503347.5000206@futureinquestion.net> <53505CCB.40902@v4escrow.net> Message-ID: <53506F0F.5080408@futureinquestion.net> Dear address-policy-wg, Elvis, On 04/18/2014 12:59 AM, Elvis Daniel Velea wrote: > Hi David, > > On 17/04/14 22:02, David Monosov wrote: >> Dear address-policy-wg, >> >> With such a policy in place, IP address broker needs to offers potential IP >> space buyers only a marginally lower price than the cost of being a LIR for the >> expected duration of use of the IPv4 PI space in question (and requesting this >> IP space from the last /8 or realizing an inter-LIR PA transfer) in order to >> create a perverse incentive for IPv4 address buyers to line the pockets of IP >> address brokers instead of stepping up and becoming members of the RIPE NCC. >> >> This policy appears to fail the most basic economic incentive test, and will in >> practice create a secondary and desirable 'asset class' from which IP transfer >> brokers benefit considerably more than the community as a whole. > There is already a market of IP addresses. Nobody will care about the color of > the IP addresses once they will really need those numbers. I concur, which is why I don't see why any IP address buyer would have a problem with registering as a LIR and becoming part of the RIPE NCC with all that entails before receiving IPv4 space of any color. >> To deconstruct the arguments which purportedly support this proposal: >> >> a) "Currently the policy for PA and PI space isn?t the same and people don?t >> understand the difference between the various types of IP Space." >> >> Ignoring that this is a superfluous argument which goes in the face of nearly >> two decades of policy, this appears to argue that letting PI space be sold would >> somehow eliminate this distinction. >> >> This, of course, is disingenuous. If this is indeed the goal, a policy should be >> introduced to allow PI space to be converted into PA space and assigned to a LIR >> - this will enable its "transferability" and eliminate many of the concerns >> raised above by ensuring that all holders of "transferred" IPv4 space are first >> rate LIRs who contribute financially toward the operation of the RIPE NCC and >> fall under all obligations imposed on such. > Are you saying that every holder of PI space should become an LIR before they > could transfer it? > Why would they pay ?3600 (1600 for the yearly membership and 2000 for the > sign-up fee) to the RIPE NCC when they could just do it in a contract? That is exactly what I am suggesting. Since getting new IPv4 PI space from the RIPE NCC is no longer possible, and since those IPv4 PI addresses were assigned specifically with the condition that they are used by a specific end user for numbering a specific infrastructure which they declared at the time of the request - there is no reason why existing IPv4 PI space assignees would suddenly find themselves in the possession of a valuable commodity to dispose of as they please when it is no longer of use to them in the original capacity of the assignment. There is no "just do it in a contract", this is explicitly against the terms set forth by both the PI assignment policies, and by the End User contract which every end user has signed. PI space transferred in this manner is in violation of the contract and is subject to revocation. There may be some lack of policing of this issue from the side of RIPE NCC, but that's just a question of time and will. The infrastructure, policy, and contractual basis are well established. > > Or are you saying that PI holders should just give their PI to the friendly LIR > which can then convert it to PA and transfer it? Who will make the buck then? > Should the PI holder retain any rights once the address is transferred to the > 'friendy' LIR or will the LIR be allowed to just transfer the new allocation to > whoever they want? >> b) "There is already some trade in PI space, however it is not documented or >> registered, which doesn?t help to keep the registry updated." >> >> This is also disingenuous, as every IPv4 PI space holder has a contract with the >> sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, >> regularly verify and update these details in cooperation with the registrant. > let's think about this scenario..You are an LIR and you have 500 PI customers > for which you are Sponsoring LIR, you will probably call the PI holder or send > him an e-mail to verify that they still exist because at least once a year you > will be paying a fee to the RIPE NCC for the maintenance of that PI. If the PI > holder says that he still has the same contact details and the IP addresses are > still used, what resources will you invest to verify that the holder of the > address space is still the one documented in the RIPE Database? > - do not forget, you (as LIR) pay ?50/year for the maintenance of the resource > to the RIPE NCC and probably make (in average) ?25-50/year/resource yourself... Let us indeed think about this scenario. 2007-01 introduced a set of contractual specifics which the end user must agree to in order to continue holding an assignment. A model contract is available at http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 If you review the items in article 4: - Terms a, b, and c specifically establish that the resources are to be used only by a specific user, for a specific purpose, and are never the property of the end user, and are non-transferable. - Term e requires specifically that the end user provides up to date information about the resource and end user. - Article 4.4 explicitly allows RIPE NCC to revoke assignments if these terms are not met. A variation of this contract including these terms is signed by every single PI holder. This means every LIR is already under the obligation to ensure compliance, and every end user is already subject to having the assigned resources revoked for violating the terms laid out in the contract. What the LIR chooses to charge in order to fulfill these obligations in overhead is completely at the discretion of the LIR. It stands to reason that as the scarcity of IPv4 addresses becomes more pressing, additional effort would be placed into auditing and resource reclamation by the RIPE NCC, and thus additional costs will be passed by LIRs to their customers to ensure on-going compliance - costs which customers will undoubtedly be willing to bear to avoid risking the loss of the assigned resource. > > I think that bringing in the registry/database all the PI transfers that > currently happen without proper registration/update is the most important goal > which this proposal will achieve. The existing contracts between the RIPE NCC, the LIR, and the End User already require this, and there is an explicit clause that enables revocation if this obligation is not met. >> c) "A lot of current PI space holders are more than happy to have their >> assignments re-assigned to other parties, but due to the current policy it is >> not possible. The same goes for the documentation provided to the RIPE NCC >> during mergers or acquisitions of infrastructure with PI space. Due to the >> current policy, some changes in company names are marked as mergers or >> acquisitions when they are actually a transfer of IP space with added >> documentation to make it look like an merger or acquisition of infrastructure." >> >> If a legitimate transfer has occurred as part of legitimate organizational >> restructuring, there is no disincentive to document it. The disincentive only >> exists if the registrant fears the transfer's legitimacy may be questioned, >> which is exactly the intention for non-transferable, end-user assigned PI space. >> Such transferred allocations could, and should, per current policy, be simply >> reclaimed. > Who will give up their address space? The numbers are now considered assets and > may be worth a buck or two... > Or would you rather see PI never transferable and the RIPE NCC reclaiming it > when it's no longer needed? Not everyone are quite as eager to throw years of policy work under a bus at the first sight of financial incentive. I have personally returned several PI assignments over the past few years under various hats. I'm positively sure I am not alone in this. >> d) "We want to have an open and honest communication to the RIPE NCC from the >> community and we need to make sure that the registry is up to date, without >> having to fluff up the procedures, bend the rules and truth in communication to >> the RIPE NCC to be able to transfer the IP space." >> >> Alternatively, elements which "bend the rules and truth" could be identified, >> and, within reason, have their resources reclaimed. Certainly, such enforcement >> can never be perfect - but speed traps also do not catch 100% of speeding cars. > Please come up with a proposal for this reclamation process; I'd really love to > see it on the mailing list. There is no need for this. The grounds for reclamation are already clearly outlined in article 4.4 of the contract signed by each end user as mentioned above. The rest is an operational matter. >> With a few documented instances, this would create tremendous uncertainty and >> disincentive to engage in such practices from the buy side, as it will mean that >> any resources acquired in this manner may very suddenly get written off. > So, once the RIPE NCC would reclaim something that was transferred without it's > approval, it should tell the whole world? What about the privacy of the > communication that the RIPE NCC is so proud of? How would you document such an > instance? Once the RIPE NCC has reclaimed something transferred without its approval, it can publish an aggregate statistics on the number of addresses revoked, perhaps as part of its annual report. This will not in any way infringe on anyone's privacy but serve as an obvious deterrent by demonstrating that this does, in fact, happen, when policy is blatantly disregarded. >> e) "The goal of this policy change is to get PI space on-par with PA space in >> respect to the ability to transfer it." >> >> See (a). It seems very disingenuous to make PI and PA "equal for purposes of >> transferability" but maintain the distinction in all other aspects. > There will no longer be many distinction between PI and PA. The only one I can > think of is that PA can be further assigned. Maybe we should come up with a > policy proposal to allow PI sub-assignments and remove the differences between > PA and PI in that process? I only see a problem, the same one I faced with IPv6 > unification, the fee unification. >> To summarize, I strongly object to this policy in its current form. >> >> I concur that the mobility of IPv4 PI space toward those who value it most is >> desirable - on the condition that this mobility occurs as part of a wider reform >> to eliminate the distinction between PA and PI status of IPv4 resources. > This policy proposal is the first step, you could try and make the next step and > propose a bigger change. From my experience (just last year) the community gets > scared when you start talking about big changes (I was trying to unify IPv6 PA > and PI, without even having all the conspiracy theory about brokers flying > around my ears). These big changes will never work. >> This should result in equitable burden for all resource holders toward the RIPE >> NCC instead of lining the pockets of IP address brokers by helping address space >> speculators which presently hoard IPv4 PI assignments against policy realize >> profits at the expense of the community. > IP brokers can and are already helping others to get the address space they need > by brokering PA transactions. Why do you think that enabling IPv4 PI transfers > will be the benefit of only the Brokers? > > I think this policy proposal is in the benefit of us all: > - cleaner registry > - all holders of address space (PA or PI) can monetize it equally ;) > - remove any temptations to 'bend the rules' > I think this policy will accomplish exactly two things: - Introduce a bureaucratic nightmare requiring the changing of all existing end user contracts, as what it proposes is a direct violation of the terms set out in article 4 of the model contract (and the contractual requirements the RIPE NCC imposed on LIRs who created their own end user contracts as part of 2007-01). - Reward those in the community who have chosen to hoard IPv4 PI assignments in instead of return them in blatant disregard of the policy they have agreed to during the initial assignment, and again upon signing the end user contract. Neither of these things is desirable. > PS: I hope you do know that a transfer can happen without brokers having to be > involved. Actually, I am under the impression that most of the transfers (in > numbers of transfers and not of IPs) have been made by LIRs mutually agreeing to > the transfer via the Listing Service and not via brokers/escrow. When it comes > to large blocks and a lot of money, some prefer to have a broker in the middle, > for the safety of both parties. >> -- >> Respectfully yours, >> >> David Monosov >> > Kind regards, > Elvis > -- > > > > Elvis Daniel Velea > > > Chief Business Analyst > > Email: elvis at 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. > -- Respectfully yours, David Monosov From elvis at v4escrow.net Fri Apr 18 02:32:40 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Fri, 18 Apr 2014 02:32:40 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53506F0F.5080408@futureinquestion.net> References: <53503347.5000206@futureinquestion.net> <53505CCB.40902@v4escrow.net> <53506F0F.5080408@futureinquestion.net> Message-ID: <535072A8.8010304@v4escrow.net> Dear David, everyone, (sorry for the top-posting, it's going to be my conclusion in this thread) what you are suggesting is to say... you want to sell your PI, pay sign-up fee and one year membership to the RIPE NCC and then you can sell/transfer it and close shop. This is already possible today... I don't think your proposed way of action would be a better alternative than the current policy proposal, it would just include an additional hop preventing data accuracy. You can talk about contracts as much as you want, these will never be enforced, nobody has the manpower and/or the tools to enforce them. Not the LIR and not even the RIPE NCC. The world is moving towards removing all the limitations imposed by policy. I don't think adding your suggested limitation will help the development of IPv4 policies. my 2 cents, Elvis PS: I fully understand your reasoning and in a perfect world, all the IPs not needed would return to the RIPE NCC for re-allocation. Unfortunately, we do not live in a perfect world :( On 18/04/14 02:17, David Monosov wrote: > Dear address-policy-wg, Elvis, > > On 04/18/2014 12:59 AM, Elvis Daniel Velea wrote: >> Hi David, >> >> On 17/04/14 22:02, David Monosov wrote: >>> Dear address-policy-wg, >>> >>> With such a policy in place, IP address broker needs to offers potential IP >>> space buyers only a marginally lower price than the cost of being a LIR for the >>> expected duration of use of the IPv4 PI space in question (and requesting this >>> IP space from the last /8 or realizing an inter-LIR PA transfer) in order to >>> create a perverse incentive for IPv4 address buyers to line the pockets of IP >>> address brokers instead of stepping up and becoming members of the RIPE NCC. >>> >>> This policy appears to fail the most basic economic incentive test, and will in >>> practice create a secondary and desirable 'asset class' from which IP transfer >>> brokers benefit considerably more than the community as a whole. >> There is already a market of IP addresses. Nobody will care about the color of >> the IP addresses once they will really need those numbers. > I concur, which is why I don't see why any IP address buyer would have a problem > with registering as a LIR and becoming part of the RIPE NCC with all that > entails before receiving IPv4 space of any color. > >>> To deconstruct the arguments which purportedly support this proposal: >>> >>> a) "Currently the policy for PA and PI space isn?t the same and people don?t >>> understand the difference between the various types of IP Space." >>> >>> Ignoring that this is a superfluous argument which goes in the face of nearly >>> two decades of policy, this appears to argue that letting PI space be sold would >>> somehow eliminate this distinction. >>> >>> This, of course, is disingenuous. If this is indeed the goal, a policy should be >>> introduced to allow PI space to be converted into PA space and assigned to a LIR >>> - this will enable its "transferability" and eliminate many of the concerns >>> raised above by ensuring that all holders of "transferred" IPv4 space are first >>> rate LIRs who contribute financially toward the operation of the RIPE NCC and >>> fall under all obligations imposed on such. >> Are you saying that every holder of PI space should become an LIR before they >> could transfer it? >> Why would they pay ?3600 (1600 for the yearly membership and 2000 for the >> sign-up fee) to the RIPE NCC when they could just do it in a contract? > That is exactly what I am suggesting. > > Since getting new IPv4 PI space from the RIPE NCC is no longer possible, and > since those IPv4 PI addresses were assigned specifically with the condition that > they are used by a specific end user for numbering a specific infrastructure > which they declared at the time of the request - there is no reason why existing > IPv4 PI space assignees would suddenly find themselves in the possession of a > valuable commodity to dispose of as they please when it is no longer of use to > them in the original capacity of the assignment. > > There is no "just do it in a contract", this is explicitly against the terms set > forth by both the PI assignment policies, and by the End User contract which > every end user has signed. PI space transferred in this manner is in violation > of the contract and is subject to revocation. There may be some lack of policing > of this issue from the side of RIPE NCC, but that's just a question of time and > will. The infrastructure, policy, and contractual basis are well established. > >> Or are you saying that PI holders should just give their PI to the friendly LIR >> which can then convert it to PA and transfer it? Who will make the buck then? >> Should the PI holder retain any rights once the address is transferred to the >> 'friendy' LIR or will the LIR be allowed to just transfer the new allocation to >> whoever they want? >>> b) "There is already some trade in PI space, however it is not documented or >>> registered, which doesn?t help to keep the registry updated." >>> >>> This is also disingenuous, as every IPv4 PI space holder has a contract with the >>> sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, >>> regularly verify and update these details in cooperation with the registrant. >> let's think about this scenario..You are an LIR and you have 500 PI customers >> for which you are Sponsoring LIR, you will probably call the PI holder or send >> him an e-mail to verify that they still exist because at least once a year you >> will be paying a fee to the RIPE NCC for the maintenance of that PI. If the PI >> holder says that he still has the same contact details and the IP addresses are >> still used, what resources will you invest to verify that the holder of the >> address space is still the one documented in the RIPE Database? >> - do not forget, you (as LIR) pay ?50/year for the maintenance of the resource >> to the RIPE NCC and probably make (in average) ?25-50/year/resource yourself... > Let us indeed think about this scenario. 2007-01 introduced a set of contractual > specifics which the end user must agree to in order to continue holding an > assignment. A model contract is available at > http://www.ripe.net/lir-services/resource-management/independent-resources/independent-assignment-request-and-maintenance-agreement-1 > > If you review the items in article 4: > > - Terms a, b, and c specifically establish that the resources are to be used > only by a specific user, for a specific purpose, and are never the property of > the end user, and are non-transferable. > > - Term e requires specifically that the end user provides up to date information > about the resource and end user. > > - Article 4.4 explicitly allows RIPE NCC to revoke assignments if these terms > are not met. > > A variation of this contract including these terms is signed by every single PI > holder. This means every LIR is already under the obligation to ensure > compliance, and every end user is already subject to having the assigned > resources revoked for violating the terms laid out in the contract. > > What the LIR chooses to charge in order to fulfill these obligations in overhead > is completely at the discretion of the LIR. It stands to reason that as the > scarcity of IPv4 addresses becomes more pressing, additional effort would be > placed into auditing and resource reclamation by the RIPE NCC, and thus > additional costs will be passed by LIRs to their customers to ensure on-going > compliance - costs which customers will undoubtedly be willing to bear to avoid > risking the loss of the assigned resource. > >> I think that bringing in the registry/database all the PI transfers that >> currently happen without proper registration/update is the most important goal >> which this proposal will achieve. > The existing contracts between the RIPE NCC, the LIR, and the End User already > require this, and there is an explicit clause that enables revocation if this > obligation is not met. > >>> c) "A lot of current PI space holders are more than happy to have their >>> assignments re-assigned to other parties, but due to the current policy it is >>> not possible. The same goes for the documentation provided to the RIPE NCC >>> during mergers or acquisitions of infrastructure with PI space. Due to the >>> current policy, some changes in company names are marked as mergers or >>> acquisitions when they are actually a transfer of IP space with added >>> documentation to make it look like an merger or acquisition of infrastructure." >>> >>> If a legitimate transfer has occurred as part of legitimate organizational >>> restructuring, there is no disincentive to document it. The disincentive only >>> exists if the registrant fears the transfer's legitimacy may be questioned, >>> which is exactly the intention for non-transferable, end-user assigned PI space. >>> Such transferred allocations could, and should, per current policy, be simply >>> reclaimed. >> Who will give up their address space? The numbers are now considered assets and >> may be worth a buck or two... >> Or would you rather see PI never transferable and the RIPE NCC reclaiming it >> when it's no longer needed? > Not everyone are quite as eager to throw years of policy work under a bus at the > first sight of financial incentive. I have personally returned several PI > assignments over the past few years under various hats. I'm positively sure I am > not alone in this. > >>> d) "We want to have an open and honest communication to the RIPE NCC from the >>> community and we need to make sure that the registry is up to date, without >>> having to fluff up the procedures, bend the rules and truth in communication to >>> the RIPE NCC to be able to transfer the IP space." >>> >>> Alternatively, elements which "bend the rules and truth" could be identified, >>> and, within reason, have their resources reclaimed. Certainly, such enforcement >>> can never be perfect - but speed traps also do not catch 100% of speeding cars. >> Please come up with a proposal for this reclamation process; I'd really love to >> see it on the mailing list. > There is no need for this. The grounds for reclamation are already clearly > outlined in article 4.4 of the contract signed by each end user as mentioned > above. The rest is an operational matter. > >>> With a few documented instances, this would create tremendous uncertainty and >>> disincentive to engage in such practices from the buy side, as it will mean that >>> any resources acquired in this manner may very suddenly get written off. >> So, once the RIPE NCC would reclaim something that was transferred without it's >> approval, it should tell the whole world? What about the privacy of the >> communication that the RIPE NCC is so proud of? How would you document such an >> instance? > Once the RIPE NCC has reclaimed something transferred without its approval, it > can publish an aggregate statistics on the number of addresses revoked, perhaps > as part of its annual report. > > This will not in any way infringe on anyone's privacy but serve as an obvious > deterrent by demonstrating that this does, in fact, happen, when policy is > blatantly disregarded. > >>> e) "The goal of this policy change is to get PI space on-par with PA space in >>> respect to the ability to transfer it." >>> >>> See (a). It seems very disingenuous to make PI and PA "equal for purposes of >>> transferability" but maintain the distinction in all other aspects. >> There will no longer be many distinction between PI and PA. The only one I can >> think of is that PA can be further assigned. Maybe we should come up with a >> policy proposal to allow PI sub-assignments and remove the differences between >> PA and PI in that process? I only see a problem, the same one I faced with IPv6 >> unification, the fee unification. >>> To summarize, I strongly object to this policy in its current form. >>> >>> I concur that the mobility of IPv4 PI space toward those who value it most is >>> desirable - on the condition that this mobility occurs as part of a wider reform >>> to eliminate the distinction between PA and PI status of IPv4 resources. >> This policy proposal is the first step, you could try and make the next step and >> propose a bigger change. From my experience (just last year) the community gets >> scared when you start talking about big changes (I was trying to unify IPv6 PA >> and PI, without even having all the conspiracy theory about brokers flying >> around my ears). These big changes will never work. >>> This should result in equitable burden for all resource holders toward the RIPE >>> NCC instead of lining the pockets of IP address brokers by helping address space >>> speculators which presently hoard IPv4 PI assignments against policy realize >>> profits at the expense of the community. >> IP brokers can and are already helping others to get the address space they need >> by brokering PA transactions. Why do you think that enabling IPv4 PI transfers >> will be the benefit of only the Brokers? >> >> I think this policy proposal is in the benefit of us all: >> - cleaner registry >> - all holders of address space (PA or PI) can monetize it equally ;) >> - remove any temptations to 'bend the rules' >> > I think this policy will accomplish exactly two things: > > - Introduce a bureaucratic nightmare requiring the changing of all existing end > user contracts, as what it proposes is a direct violation of the terms set out > in article 4 of the model contract (and the contractual requirements the RIPE > NCC imposed on LIRs who created their own end user contracts as part of 2007-01). > > - Reward those in the community who have chosen to hoard IPv4 PI assignments in > instead of return them in blatant disregard of the policy they have agreed to > during the initial assignment, and again upon signing the end user contract. > > Neither of these things is desirable. > >> PS: I hope you do know that a transfer can happen without brokers having to be >> involved. Actually, I am under the impression that most of the transfers (in >> numbers of transfers and not of IPs) have been made by LIRs mutually agreeing to >> the transfer via the Listing Service and not via brokers/escrow. When it comes >> to large blocks and a lot of money, some prefer to have a broker in the middle, >> for the safety of both parties. >>> -- >>> Respectfully yours, >>> >>> David Monosov >>> >> Kind regards, >> Elvis >> > -- > > Respectfully yours, > > David Monosov > -- Elvis Daniel Velea Chief Business Analyst Email: elvis at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From leo.vegoda at icann.org Fri Apr 18 04:43:18 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 17 Apr 2014 19:43:18 -0700 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53505D93.7080104@velea.eu> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From ebais at a2b-internet.com Fri Apr 18 12:24:53 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 18 Apr 2014 12:24:53 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53503347.5000206@futureinquestion.net> References: <53503347.5000206@futureinquestion.net> Message-ID: <003601cf5af0$76f82ae0$64e880a0$@a2b-internet.com> Hi Dave, First of all thanks for your lengthy response and let me reply on it. > With such a policy in place, IP address broker needs to offers potential IP space buyers only a marginally lower price than the cost of being a LIR for the expected duration of use of > the IPv4 PI space in question (and requesting this IP space from the last /8 or realizing an inter-LIR PA transfer) in order to create a perverse incentive for IPv4 address buyers to line > the pockets of IP address brokers instead of stepping up and becoming members of the RIPE NCC. Brokers don't own IP address. Same as that your house if you sell it, will never transfer ownership into the hands of the house broker, IP addresses are transferred between offering and receiving parties. The broker doesn't set the price, the offering party decides what the price is and has the final say if they want to agree on a bid that the receiving party is making. > This policy appears to fail the most basic economic incentive test, and will in practice create a secondary and desirable 'asset class' from which IP transfer brokers benefit considerably > more than the community as a whole. This policy isn't about economic incentives. I don't hold PI space, although I have a lot of customers that do. The policy goal is to provide a way to officially register PI transfer (which are already being done) to be correctly reflected into the registry in order to keep the registry accurate. > To deconstruct the arguments which purportedly support this proposal: > a) "Currently the policy for PA and PI space isn't the same and people don't understand the difference between the various types of IP Space." > Ignoring that this is a superfluous argument which goes in the face of nearly two decades of policy, this appears to argue that letting PI space be sold would somehow eliminate this distinction. > This, of course, is disingenuous. If this is indeed the goal, a policy should be introduced to allow PI space to be converted into PA space and assigned to a LIR > - this will enable its "transferability" and eliminate many of the concerns raised above by ensuring that all holders of "transferred" IPv4 space are first rate LIRs who contribute financially toward the operation of the RIPE NCC and fall under all obligations > imposed on such. Not all are created equal ... not everyone who has PI space or want PI space (and not PA space due to the requirement of becoming a member to that scary group of internet hippies that talk about bits and bytes or other legal reasons.. and have secret meeting with people attending like Randy Bush, yourself or Job Snijders ... ). Some entities can't, due to legal restrictions, can't become a part of a membership association ... So their only option is to either obtain PI space or ERX space. And PI space is the only of those 2 that is non-transferrable currently. Asking my customers to hand over their PI space into our LIR, would make us the owner .. Asking them to become an LIR themselves, import the PI space and convert the space to PA, is just a detour, without any added value to the parties involved .. The offering party, the receiving party, RIPE ... We are trying to make things easier .. and accurate ... > b) "There is already some trade in PI space, however it is not documented or registered, which doesn't help to keep the registry updated." > This is also disingenuous, as every IPv4 PI space holder has a contract with the sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, and should, regularly verify and update these details in cooperation with the registrant. There are a few exceptions, but can you name me 10 LIR's out of the 10.000 which have more than 10 PI objects .. all documents approved and which do regular (once every 2 years ?) checks with their customers if their PI contracts are up to date ? I think that you might need to take of your pink glasses to this world ... We both go a long way back and I have you in high regards, but your view to this is too optimistic imho. I've seen documents been signed between 2 companies as side letters because they wanted to transfer the PI space and policy didn't let them ... I've been asked by interested parties who were ready to sign on the dotted line to purchase IP space and asked me for a second pair of eyes before they did.. And people have no idea, no clue. ( No offence .. it is my personal observation ) We spend a LOT of time explaining to customers the differences between the various types of IP space if they ask us what the status is if they want to purchase of transfer IP space. > c) "A lot of current PI space holders are more than happy to have their assignments re-assigned to other parties, but due to the current policy it is not possible. The same goes for the documentation provided to the RIPE NCC during mergers or > acquisitions of infrastructure with PI space. Due to the current policy, some changes in company names are marked as mergers or acquisitions when they are actually a transfer of IP space with added documentation to make it look like an merger > or acquisition of infrastructure." > If a legitimate transfer has occurred as part of legitimate organizational restructuring, there is no disincentive to document it. The disincentive only exists if the registrant fears the transfer's legitimacy may be questioned, which is exactly the intention > for non-transferable, end-user assigned PI space. > Such transferred allocations could, and should, per current policy, be simply reclaimed. Simply reclaimed ... that doesn't happen .. as it would simply go to the pool, while there are people that are currently offering money for the space ..Either in currently non-approved sales or long term leases etc. None of them are correctly documented in the registry ... Which is the end-goal .. to have a proper registry of who the current holder and user is.. If people are not properly registered in the RIPE Registry with the space they have, they will never be able to certify their resources under RPKI for instance .. as the maintainers don't match, the legitimate holder isn't correct etc etc. The long-term goal is to have the registry correctly updated, (fair) distribution isn't a role or goal of RIPE anymore. The market will deal with that themselves. > d) "We want to have an open and honest communication to the RIPE NCC from the community and we need to make sure that the registry is up to date, without having to fluff up the procedures, bend the rules and truth in communication to the > RIPE NCC to be able to transfer the IP space." > Alternatively, elements which "bend the rules and truth" could be identified, and, within reason, have their resources reclaimed. Certainly, such enforcement can never be perfect - but speed traps also do not catch 100% of speeding cars. > With a few documented instances, this would create tremendous uncertainty and disincentive to engage in such practices from the buy side, as it will mean that any resources acquired in this manner may very suddenly get written off. The RIPE NCC and her staff isn't the internet police .. and the policies should reflect the current status ... Which is to be able to maintain a proper Internet Resource Registry. There is currently no requirement anymore to document need or documentation requirement anymore .. The idea that fair distribution is still in place is obsolete. There is currently a reservation for new LIR's that they can obtain a single /22 via the NCC, but they can't get more space. There are still some checks which the NCC will do even with this policy in place, to see if the original (legal) documentation to which the PI was provided was correct at the moment of assignment. But for the rest, the process should be fairly similar as with the current PA Transfers. > e) "The goal of this policy change is to get PI space on-par with PA space in respect to the ability to transfer it." > See (a). It seems very disingenuous to make PI and PA "equal for purposes of transferability" but maintain the distinction in all other aspects. If we would work around this via the loop-hole you suggested, import the PI space into an LIR and transfer it to PA and then transfer the space.. how would that make it different to what we are proposing ? The proposed proposal to allow PI space to be transferred will make it a lot easier. > To summarize, I strongly object to this policy in its current form. > I concur that the mobility of IPv4 PI space toward those who value it most is desirable - on the condition that this mobility occurs as part of a wider reform to eliminate the distinction between PA and PI status of IPv4 resources. > This should result in equitable burden for all resource holders toward the RIPE NCC instead of lining the pockets of IP address brokers by helping address space speculators which presently hoard IPv4 PI assignments against policy realize profits > at the expense of the community. Your missing the point Dave. People who hoarded are not brokers, brokers make a fee on a transaction ... Your so called hoarders are offering parties, but I doubt that you can show in numbers, a substantial number of hoarders as you call them, that would make a substantial amount of money which would justify not doing the policy and not allow a proper registration in the registry for those that have legitimate reasons. Regards, Erik Bais From davidm at futureinquestion.net Fri Apr 18 21:49:07 2014 From: davidm at futureinquestion.net (David Monosov) Date: Fri, 18 Apr 2014 21:49:07 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <003601cf5af0$76f82ae0$64e880a0$@a2b-internet.com> References: <53503347.5000206@futureinquestion.net> <003601cf5af0$76f82ae0$64e880a0$@a2b-internet.com> Message-ID: <535181B3.6060908@futureinquestion.net> Hi! Thank you for your extensive and thoughtful reply; I've expanded on several of these points already in my reply to Elvis, who also contributed a few thoughtful comments, but here are a few additional notes: On 04/18/2014 12:24 PM, Erik Bais wrote: > Hi Dave, > > First of all thanks for your lengthy response and let me reply on it. > >> With such a policy in place, IP address broker needs to offers potential > IP space buyers only a marginally lower price than the cost of being a LIR > for the expected duration of use of >> the IPv4 PI space in question (and requesting this IP space from the last > /8 or realizing an inter-LIR PA transfer) in order to create a perverse > incentive for IPv4 address buyers to line >> the pockets of IP address brokers instead of stepping up and becoming > members of the RIPE NCC. > > Brokers don't own IP address. Same as that your house if you sell it, will > never transfer ownership into the hands of the house broker, IP addresses > are transferred between offering and receiving parties. The broker doesn't > set the price, the offering party decides what the price is and has the > final say if they want to agree on a bid that the receiving party is making. > By changing the status of PI to transferable, an incentive is created for brokers to identify existing PI holders willing to sell assignments, and match them with the highest bidder independently of the RIPE NCC and the RIPE NCC listing service - as that service presently only deals with PA transfers between LIRs. Additionally, since neither the seller not the buyer are required, under this policy, to be LIRs, a "friendly LIR" (once again, presumably, the broker) is required to facilitate the transfer vis-a-vis the RIPE NCC, while the RIPE NCC sees nothing but added administrative burden, the cost of which is spread between paying LIRs which were no part of this transaction nor benefited from it in any way. I'm all in favor of allowing existing PI holders to become LIRs themselves and transfer the space from PI to PA status, at which point it will fall under existing rules, fees, listing structure, etc; I see no reason to create an extra "asset class" with custodial fees of 50 EUR/year (instead of 2,000 EUR/year for a LIR) and encourage PI space to be bought as a speculative investment with the RIPE NCC provided a very accurate registrant information of the buyer, and a completely fabricated infrastructure which justifies a non-existent "need". > >> This policy appears to fail the most basic economic incentive test, and > will in practice create a secondary and desirable 'asset class' from which > IP transfer brokers benefit considerably >> more than the community as a whole. > > This policy isn't about economic incentives. I don't hold PI space, although > I have a lot of customers that do. The policy goal is to provide a way to > officially register PI transfer (which are already being done) to be > correctly reflected into the registry in order to keep the registry > accurate. > There is no reason for a way to officially register a PI transfer to exist because a PI transfer is a non-existent construct. PI space, by policy, has been designed to be specifically assigned to a single end user and a specific infrastructure, and returned once this ceases to be the case. >> To deconstruct the arguments which purportedly support this proposal: > >> a) "Currently the policy for PA and PI space isn't the same and people > don't understand the difference between the various types of IP Space." > >> Ignoring that this is a superfluous argument which goes in the face of > nearly two decades of policy, this appears to argue that letting PI space be > sold would somehow eliminate this distinction. > >> This, of course, is disingenuous. If this is indeed the goal, a policy > should be introduced to allow PI space to be converted into PA space and > assigned to a LIR >> - this will enable its "transferability" and eliminate many of the > concerns raised above by ensuring that all holders of "transferred" IPv4 > space are first rate LIRs who contribute financially toward the operation of > the RIPE NCC and fall under all obligations > imposed on such. > > Not all are created equal ... not everyone who has PI space or want PI space > (and not PA space due to the requirement of becoming a member to that scary > group of internet hippies that talk about bits and bytes or other legal > reasons.. and have secret meeting with people attending like Randy Bush, > yourself or Job Snijders ... ). Some entities can't, due to legal > restrictions, can't become a part of a membership association ... So their > only option is to either obtain PI space or ERX space. > And PI space is the only of those 2 that is non-transferrable currently. > Asking my customers to hand over their PI space into our LIR, would make us > the owner .. Asking them to become an LIR themselves, import the PI space > and convert the space to PA, is just a detour, without any added value to > the parties involved .. The offering party, the receiving party, RIPE ... We > are trying to make things easier .. and accurate ... > Becoming a LIR to receive any additional IPv4 assignments, in any form, is a fair and balanced requirement which puts everyone seeking IPv4 address space on equal footing. The shortage of IPv4 space does not disproportionately affect end users, why would they enjoy a different set of rules and different price card? In fact, it would be easier to argue that ISPs (which sell services to end users) have a much stronger incentive to achieve optimal utilization of address space as it directly contributes to their revenue, whereas an end user that acquired an assignment and paid it in full has no further incentive in regards to efficient use as the end user's business outcome may have no direct relation to efficient IPv4 address space utilization. There already are exemptions carved out for organizations for which this is not an option for legal/independence reasons, and simply adding RIPE NCC direct assignees as PA transfer recipient candidates solves this problem instantly. >> b) "There is already some trade in PI space, however it is not documented > or registered, which doesn't help to keep the registry updated." > >> This is also disingenuous, as every IPv4 PI space holder has a contract > with the sponsoring LIR (and indirectly, with the RIPE NCC). This LIR can, > and should, regularly verify and update these details in cooperation with > the registrant. > > There are a few exceptions, but can you name me 10 LIR's out of the 10.000 > which have more than 10 PI objects .. all documents approved and which do > regular (once every 2 years ?) checks with their customers if their PI > contracts are up to date ? > I think that you might need to take of your pink glasses to this world ... > We both go a long way back and I have you in high regards, but your view to > this is too optimistic imho. > Seeing how we've managed to get tens of thousands of independent resource holders to sign an end user agreement, none of this seems like "mission impossible", it just requires will and focus - both of which are not currently targeted at curtailing this behavior. When 2007-01 came around, I was equally sure that the situation is hopeless, and the level of involvement it requires from both LIRs and PI holders is impossible. Yet here we are. > I've seen documents been signed between 2 companies as side letters because > they wanted to transfer the PI space and policy didn't let them ... I've > been asked by interested parties who were ready to sign on the dotted line > to purchase IP space and asked me for a second pair of eyes before they > did.. And people have no idea, no clue. ( No offence .. it is my personal > observation ) We spend a LOT of time explaining to customers the differences > between the various types of IP space if they ask us what the status is if > they want to purchase of transfer IP space. > That's perfectly fine. The answer is "no", current policy does not allow PI transfers, you do not own these resources, and you should let them be reclaimed by the RIPE NCC if they are no longer in use. As a LIR, you should know this and be able to communicate it with conviction. You may charge consulting fees in the process ;-) >> c) "A lot of current PI space holders are more than happy to have their > assignments re-assigned to other parties, but due to the current policy it > is not possible. The same goes for the documentation provided to the RIPE > NCC during mergers or >> acquisitions of infrastructure with PI space. Due to the current policy, > some changes in company names are marked as mergers or acquisitions when > they are actually a transfer of IP space with added documentation to make it > look like an merger >> or acquisition of infrastructure." > >> If a legitimate transfer has occurred as part of legitimate organizational > restructuring, there is no disincentive to document it. The disincentive > only exists if the registrant fears the transfer's legitimacy may be > questioned, which is exactly the intention >> for non-transferable, end-user assigned PI space. >> Such transferred allocations could, and should, per current policy, be > simply reclaimed. > > Simply reclaimed ... that doesn't happen .. as it would simply go to the > pool, while there are people that are currently offering money for the space > ..Either in currently non-approved sales or long term leases etc. > > None of them are correctly documented in the registry ... Which is the > end-goal .. to have a proper registry of who the current holder and user > is.. > As I mentioned in my mail to Elvis, this can be mostly rectified by creating an effective deterrent. > If people are not properly registered in the RIPE Registry with the space > they have, they will never be able to certify their resources under RPKI for > instance .. as the maintainers don't match, the legitimate holder isn't > correct etc etc. > The long-term goal is to have the registry correctly updated, (fair) > distribution isn't a role or goal of RIPE anymore. The market will deal with > that themselves. > >> d) "We want to have an open and honest communication to the RIPE NCC from > the community and we need to make sure that the registry is up to date, > without having to fluff up the procedures, bend the rules and truth in > communication to the >> RIPE NCC to be able to transfer the IP space." > >> Alternatively, elements which "bend the rules and truth" could be > identified, and, within reason, have their resources reclaimed. Certainly, > such enforcement can never be perfect - but speed traps also do not catch > 100% of speeding cars. >> With a few documented instances, this would create tremendous uncertainty > and disincentive to engage in such practices from the buy side, as it will > mean that any resources acquired in this manner may very suddenly get > written off. > > The RIPE NCC and her staff isn't the internet police .. and the policies > should reflect the current status ... Which is to be able to maintain a > proper Internet Resource Registry. > There is currently no requirement anymore to document need or documentation > requirement anymore .. The idea that fair distribution is still in place is > obsolete. There is currently a reservation for new LIR's that they can > obtain a single /22 via the NCC, but they can't get more space. There are > still some checks which the NCC will do even with this policy in place, to > see if the original (legal) documentation to which the PI was provided was > correct at the moment of assignment. > But for the rest, the process should be fairly similar as with the current > PA Transfers. > >> e) "The goal of this policy change is to get PI space on-par with PA space > in respect to the ability to transfer it." >> See (a). It seems very disingenuous to make PI and PA "equal for purposes > of transferability" but maintain the distinction in all other aspects. > > If we would work around this via the loop-hole you suggested, import the PI > space into an LIR and transfer it to PA and then transfer the space.. how > would that make it different to what we are proposing ? > The proposed proposal to allow PI space to be transferred will make it a lot > easier. > A PI->PA conversion (and subsequent transition to another LIR) will assure that anyone who receives IPv4 resources in any form from the moment the last /8 policy kicked in is a LIR, and would have received them under the same set of rules, with the same cost basis, and the same conditions and obligations. All those addresses will be eligible for listing under the same listing service, and the recipient of such a transfer would be subject to constant outreach by the RIPE NCC, as would any LIR, continuously encouraging the recipient to have an effective IPv6 transition and eventual phase-out strategy for IPv4. It will also make all space transferred in such a way sub-assignable (as it is now PA, not PI) - thus removing any remaining deterrent to inefficient use due to sub-assignment restrictions. In the process, the community benefits as the cost of operating the RIPE NCC is spread across an increased base of LIRs, and the ties between the RIPE NCC and the resources become much stronger, since for a variety of reasons its considerably more difficult to be an absentee LIR than it is to be an absentee end user. >> To summarize, I strongly object to this policy in its current form. > >> I concur that the mobility of IPv4 PI space toward those who value it most > is desirable - on the condition that this mobility occurs as part of a wider > reform to eliminate the distinction between PA and PI status of IPv4 > resources. > >> This should result in equitable burden for all resource holders toward the > RIPE NCC instead of lining the pockets of IP address brokers by helping > address space speculators which presently hoard IPv4 PI assignments against > policy realize profits >> at the expense of the community. > > Your missing the point Dave. People who hoarded are not brokers, brokers > make a fee on a transaction ... Your so called hoarders are offering > parties, but I doubt that you can show in numbers, a substantial number of > hoarders as you call them, that would make a substantial amount of money > which would justify not doing the policy and not allow a proper registration > in the registry for those that have legitimate reasons. > I don't believe there is a legitimate reason for end users to unilaterally decide to violate policy, capitalize on an assignment made to them with specific restrictions, and walk away - in the process, not contributing more than 50 EUR/year to the RIPE NCC while realizing an arbitrary amount of profit. Nor do I believe that we should encourage this behavior by suddenly accepting it in the interest of database accuracy. The database accuracy need was already addressed by 2007-01, and the lack of teeth in terms of revocation of resources which are found no longer to be compliant with the terms of the assignment is an operational matter that can be resolved by re-focusing the RIPE NCC to deal with it. For anyone who is currently a LIR, pays LIR fees, engages in policy development, and expects the community to abide by the policy this work group creates, the argument "lets change it because some elements decided to violate it anyway in the name of profit" should be outright insulting. ... and none of this deals with the fact that this policy goes completely in the face of the actual wording of every single end user contract, which as per 2007-01 must include wording that explicitly prohibits the behavior this proposal aims to enable, yet makes no mention of this fact, or any legal review of the consequences (see mail on this subject to Elvis for more detail). > Regards, > Erik Bais > > > -- Respectfully yours, David Monosov From tore at fud.no Mon Apr 21 11:34:27 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 21 Apr 2014 11:34:27 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <535181B3.6060908@futureinquestion.net> References: <53503347.5000206@futureinquestion.net> <003601cf5af0$76f82ae0$64e880a0$@a2b-internet.com> <535181B3.6060908@futureinquestion.net> Message-ID: <5354E623.6060005@fud.no> Hi David, > current policy does not allow PI transfers, you do not own these > resources, and you should let them be reclaimed by the RIPE NCC if > they are no longer in use. As a LIR, you should know this and be able > to communicate it with conviction. You may charge consulting fees in > the process ;-) Actually, that's not quite what the policy says. Perhaps I'm nitpicking, but I think that the difference is significant, even if it is small. For reference, policy says: ?All assignments are valid as long as the original criteria on which the assignment was based are still valid and the assignment is properly registered in the RIPE Database. If an assignment is made for a specific purpose and that purpose no longer exists, the assignment is no longer valid. If an assignment is based on information that turns out to be invalid, the assignment is no longer valid.? My point is that ?no longer in use? isn't the only thing that would invalidate an assignment. It might still be very much in use, but as long as it isn't used for the same purpose it originally was, then the assignment is invalid, according to policy. This is echoed by the suggested PI contract, which mandates: ?The End User shall use the assigned Independent Internet Number Resources solely for the purpose as specified in the request on the basis of which the Independent Internet Number Resources have been assigned.? These requirements are in my opinion out of touch with operational reality; networks evolve and change over time, and given enough time, pretty much all assignments made will end up being used in a different way than what the original criteria was. The PI assignment request form asked for an very detailed criteria, with a breakdown of each individual subnet in the network, and a listing of all the equipment that would be used, including the manufacturer name and model numbers. So if you in the 1990s received an assignment that you had said was for a dozen brand new Sun UltraServers, you better not have replaced those with modern x86 hardware, or you have invalidated your assignment! :-O Some NCC staffers have told me that the way they've logically "solved" this impossible requirement was to consider that whenever the criteria/purpose changed, the original assignment was returned, and a new one consisting of the same block was issued for the new purpose. Then they could just "optimise out" the middle steps where the assignment was removed and re-added. That approached worked (up until Sep 2012 anyway), but I think it would be much better if the policy didn't worry so much about the "original criteria", but rather focus on whether or not the assignment conforms to the address policy in effect at any given time. If it does, there is no reason to call it invalid. Tore From frettled at gmail.com Mon Apr 21 21:14:36 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Mon, 21 Apr 2014 21:14:36 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <5354E623.6060005@fud.no> References: <53503347.5000206@futureinquestion.net> <003601cf5af0$76f82ae0$64e880a0$@a2b-internet.com> <535181B3.6060908@futureinquestion.net> <5354E623.6060005@fud.no> Message-ID: On Mon, Apr 21, 2014 at 11:34 AM, Tore Anderson wrote: > > These requirements are in my opinion out of touch with operational > reality; networks evolve and change over time, and given enough time, > pretty much all assignments made will end up being used in a different > way than what the original criteria was. The PI assignment request form > asked for an very detailed criteria, with a breakdown of each individual > subnet in the network, and a listing of all the equipment that would be > used, including the manufacturer name and model numbers. So if you in > the 1990s received an assignment that you had said was for a dozen brand > new Sun UltraServers, you better not have replaced those with modern x86 > hardware, or you have invalidated your assignment! :-O > > Some NCC staffers have told me that the way they've logically "solved" > this impossible requirement was to consider that whenever the > criteria/purpose changed, the original assignment was returned, and a > new one consisting of the same block was issued for the new purpose. > Then they could just "optimise out" the middle steps where the > assignment was removed and re-added. That approached worked (up until > Sep 2012 anyway), but I think it would be much better if the policy > didn't worry so much about the "original criteria", but rather focus on > whether or not the assignment conforms to the address policy in effect > at any given time. If it does, there is no reason to call it invalid. > > Well said. When specifying a purpose for a use, it is quite difficult to provide something that is generic enough to last for the lifetime of operations, rather than the lifetime of something else entirely. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Tue Apr 22 14:05:34 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 22 Apr 2014 14:05:34 +0200 Subject: [address-policy-wg] 2014-01 Draft Document and Impact Analysis will be produced (Abandoning the Minimum Allocation Size for IPv4) Message-ID: Dear colleagues, The discussion period for the proposal described in 2014-01, "Abandoning the Minimum Allocation Size for IPv4" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-01 Regards Marco Schmidt Policy Development Officer RIPE NCC From leo.vegoda at icann.org Wed Apr 23 01:27:40 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 22 Apr 2014 16:27:40 -0700 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> Message-ID: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Wed Apr 23 11:53:41 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 23 Apr 2014 11:53:41 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> Message-ID: <53578DA5.3060707@schiefner.de> 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. From datos at tvt-datos.es Wed Apr 23 12:19:46 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Wed, 23 Apr 2014 12:19:46 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> Message-ID: <535793C2.3010802@tvt-datos.es> 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 at 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). From Woeber at CC.UniVie.ac.at Wed Apr 23 15:05:04 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 23 Apr 2014 15:05:04 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <535793C2.3010802@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <535793C2.3010802@tvt-datos.es> Message-ID: <5357BA80.3030705@CC.UniVie.ac.at> 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 From datos at tvt-datos.es Wed Apr 23 16:15:17 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Wed, 23 Apr 2014 16:15:17 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5357BA80.3030705@CC.UniVie.ac.at> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <535793C2.3010802@tvt-datos.es> <5357BA80.3030705@CC.UniVie.ac.at> Message-ID: <5357CAF5.7020406@tvt-datos.es> 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 at 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). From frettled at gmail.com Wed Apr 23 16:38:33 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 23 Apr 2014 16:38:33 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5357CAF5.7020406@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <535793C2.3010802@tvt-datos.es> <5357BA80.3030705@CC.UniVie.ac.at> <5357CAF5.7020406@tvt-datos.es> Message-ID: 2014-04-23 16:15 GMT+02:00 Dpto. Datos Television Costa Blanca < datos at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From datos at tvt-datos.es Wed Apr 23 17:01:53 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Wed, 23 Apr 2014 17:01:53 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <535793C2.3010802@tvt-datos.es> <5357BA80.3030705@CC.UniVie.ac.at> <5357CAF5.7020406@tvt-datos.es> Message-ID: <5357D5E1.2000508@tvt-datos.es> 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 > >: > > 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 at 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Apr 23 18:23:21 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 23 Apr 2014 18:23:21 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <53578DA5.3060707@schiefner.de> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <53578DA5.3060707@schiefner.de> Message-ID: <5357E8F9.9090100@fud.no> * 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 From tore at fud.no Wed Apr 23 18:31:12 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 23 Apr 2014 18:31:12 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5357E8F9.9090100@fud.no> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <53578DA5.3060707@schiefner.de> <5357E8F9.9090100@fud.no> Message-ID: <5357EAD0.6060903@fud.no> * 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 From ebais at a2b-internet.com Wed Apr 23 21:07:37 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 23 Apr 2014 21:07:37 +0200 Subject: [address-policy-wg] About the /22 allocation limitation In-Reply-To: <5357EAD0.6060903@fud.no> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <53578DA5.3060707@schiefner.de> <5357E8F9.9090100@fud.no> <5357EAD0.6060903@fud.no> Message-ID: <000001cf5f27$5e5b78d0$1b126a70$@a2b-internet.com> 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 at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens Tore Anderson Verzonden: woensdag 23 april 2014 18:31 Aan: Carsten Schiefner; Leo Vegoda CC: address-policy-wg at 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 From Woeber at CC.UniVie.ac.at Thu Apr 24 17:24:26 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 24 Apr 2014 17:24:26 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: References: Message-ID: <53592CAA.2090608@CC.UniVie.ac.at> A couple of observations, fwiw, and no, I'm not going to assess the role of brokers :-) In general, let me start with the statement that I support all ideas to get rid of the different shapes and colours of address blocks. And that actually includes Legacy, as they are simply PI, just a tad older... How to deal with moving address space from a PI assignment to a different party? Well, I can see 2 *substantially* different scenarios: 1) the current holder of the address block doesn't need *all of it* any longer (and wants to get money from an interested party, but that's a side issue). 2) the current holder of the address block doesn't need *any* of the addresses any longer and wants to transfer the full block, in one chunk or in smaller pieces. Nr. 1 is pretty easy, and possible already or really soon now: convert the PI block to PA, thus become an LIR, and proceed according to the rules. Nr. 2 is more tricky. First of all, there was a good reason, why the resource was tightly bound to the requester. That background and assumption is also part of the basis for the low annual fee of ?50,- per resource. Now, as soon as the original criteria are no longer in place, the resource MUST be returned. A PI holder offering the *full block* to an interested party (for money or for free) obviously matches that provision. The resource needs to get returned to the pool. So, why would we want to bend into this direction or that direction to create a special case for Nr. 2 to circumvent the existing policy? Just because some money is seen on the horizon? Which gets me to the point of *not* supporting this proposal! Wilfried. From elvis at v4escrow.net Thu Apr 24 19:41:56 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 24 Apr 2014 19:41:56 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53592CAA.2090608@CC.UniVie.ac.at> References: <53592CAA.2090608@CC.UniVie.ac.at> Message-ID: <53594CE4.7030007@v4escrow.net> Hi Wilfried, I agree with you in both scenarios you described below. However, the reality of the current world is not that simple. IP addresses have a value, whether we want to acknowledge that fact or not. Some holders of PI address space have also realized that their PI space has some value, some will do the right thing and become LIRs in order to convert the PI to PA and then transfer the space. This policy proposal does not intend to address these users, the ones that will do the right thing by becoming a member and paying their share. Some others, will just transfer the space (by making a contract/document/agreement between them and an other party) or just allow someone else to use the address space without any notification to the RIPE NCC or updates in the registry. While these are the 'bad guys' and I do not thing we should be making policy changes to encourage them, by not making a policy change the registry will suffer. Not everyone will give up on their PI space if they do not use it anymore. Especially if they receive e-mails from people that want to 'rent/lease' their space for some money. I still don't know if it's a good thing to allow PI transfers and have individuals or companies that have only been paying 50E/year to transfer (sell) their PI space for a nice profit AND keep the registry as clean and updated as possible. OR.. give the RIPE NCC a mandate to start hunting those that violate the PI policy OR.. just pretend there's no problem and accept that the registry data may get outdated with time. my 2 cents, elvis On 24/04/14 17:24, Wilfried Woeber wrote: > A couple of observations, fwiw, and no, I'm not going to assess the role > of brokers :-) > > In general, let me start with the statement that I support all ideas to > get rid of the different shapes and colours of address blocks. And that > actually includes Legacy, as they are simply PI, just a tad older... > > How to deal with moving address space from a PI assignment to a different > party? > > Well, I can see 2 *substantially* different scenarios: > > 1) the current holder of the address block doesn't need *all of it* any longer > (and wants to get money from an interested party, but that's a side issue). > > 2) the current holder of the address block doesn't need *any* of the addresses > any longer and wants to transfer the full block, in one chunk or in smaller > pieces. > > > Nr. 1 is pretty easy, and possible already or really soon now: convert the > PI block to PA, thus become an LIR, and proceed according to the rules. > > > Nr. 2 is more tricky. First of all, there was a good reason, why the resource > was tightly bound to the requester. That background and assumption is also > part of the basis for the low annual fee of ?50,- per resource. > > Now, as soon as the original criteria are no longer in place, the resource > MUST be returned. A PI holder offering the *full block* to an interested party > (for money or for free) obviously matches that provision. The resource needs > to get returned to the pool. > > So, why would we want to bend into this direction or that direction to create > a special case for Nr. 2 to circumvent the existing policy? Just because some > money is seen on the horizon? > > Which gets me to the point of *not* supporting this proposal! > > Wilfried. > -- Elvis Daniel Velea Chief Business Analyst Email: elvis at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From tore at fud.no Fri Apr 25 09:52:15 2014 From: tore at fud.no (Tore Anderson) Date: Fri, 25 Apr 2014 09:52:15 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53592CAA.2090608@CC.UniVie.ac.at> References: <53592CAA.2090608@CC.UniVie.ac.at> Message-ID: <535A142F.306@fud.no> Hi Wilfried, > How to deal with moving address space from a PI assignment to a > different party? > > Well, I can see 2 *substantially* different scenarios: > > 1) the current holder of the address block doesn't need *all of > it* any longer (and wants to get money from an interested party, > but that's a side issue). > > 2) the current holder of the address block doesn't need *any* of > the addresses any longer and wants to transfer the full block, in > one chunk or in smaller pieces. > > Nr. 1 is pretty easy, and possible already or really soon now: > convert the PI block to PA, thus become an LIR, and proceed according > to the rules. > > Nr. 2 is more tricky. Actually, I don't believe it is - your procedure #1 will work just as well for case #2 as it would for case #1. That this works is stated fairly clearly on the NCC's web site: http://www.ripe.net/lir-services/resource-management/converting-pi-to-pa So PI transfers are already possible, following this procedure: 1) The current PI holder signs up as a member and pays the first invoice. In 2014, this would cost somewhere between ?2437.50 and ?3750 depending on in which quartal it happens. 2) The PI block (or parts of it) is converted to PA. 3) The new PA block is transferred to another NCC member under ripe-606 section 5.5. [...] 6) Finally, original PI holder may optionally close his LIR to avoid any further membership fees. He'd then also have to move any remaining parts of his PI assignment into a sponsoring relationship with another LIR. What it boils down to is that we are levying a transaction fee for non-members. That might be perfectly OK in itself (APNIC does too, FWIW), but we're doing it in a really awkward and roundabout way. One benefit is that once a PI block has become PA, there is no going back, and we've ensured that all its future holders will all be members that will be participating equally in the cost-sharing model. However, there is a possible disadvantage too - by forcing the original PI holder to become a (temporary) member in the first place, we're almost inviting him to take advantage of that fact by adding the following steps to the above procedure: 4) The original PI holder requests a /22 from the ?last /8? pool. 5) The original PI holder transfers that /22 to another NCC member under ripe-606 section 5.5. Now, assuming that the hear-say about the market value of ?10/address is anywhere near correct, step #5 would net him around ~?10.240. That is almost three times the worst case ?transaction fee? from step #1. Oops! So we don't really have a functioning ?fee? that would positively fund the cost-sharing model, but an invitation to make a quick extra buck at the community's expense. > Now, as soon as the original criteria are no longer in place, the > resource MUST be returned. A PI holder offering the *full block* to > an interested party (for money or for free) obviously matches that > provision. The resource needs to get returned to the pool. I don't think you can support this claim with actual policy provisions. What policy says, is that an such an assignment is ?no longer valid?. It does *not* say what should happen to invalid assignments, but one obvious way to deal with it is to fix whatever is making it invalid, so that it no longer is. There are several other things that might make an assignment invalid too, and this page talks about how they should be fixed, not how they should be reclaimed: http://www.ripe.net/lir-services/resource-management/number-resources/invalid-assignments In this specific case, I'd say that converting PI to PA is a perfectly logical way of correcting a PI assignment that has been made invalid due to a criteria change. The PI holder could for example have started an ISP service and assigned PI blocks to his end users, which is invalid usage for PI, but it is exactly what PA is intended for. Tore From bmanning at vacation.karoshi.com Thu Apr 24 22:08:06 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 24 Apr 2014 13:08:06 -0700 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <53592CAA.2090608@CC.UniVie.ac.at> References: <53592CAA.2090608@CC.UniVie.ac.at> Message-ID: <20140424200806.GA32025@vacation.karoshi.com> On Thu, Apr 24, 2014 at 05:24:26PM +0200, Wilfried Woeber wrote: > A couple of observations, fwiw, and no, I'm not going to assess the role > of brokers :-) > > In general, let me start with the statement that I support all ideas to > get rid of the different shapes and colours of address blocks. And that > actually includes Legacy, as they are simply PI, just a tad older... > Glad to see a gradual return to the sanity of two decades ago. /bill From gert at space.net Fri Apr 25 11:56:00 2014 From: gert at space.net (Gert Doering) Date: Fri, 25 Apr 2014 11:56:00 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <20140424200806.GA32025@vacation.karoshi.com> References: <53592CAA.2090608@CC.UniVie.ac.at> <20140424200806.GA32025@vacation.karoshi.com> Message-ID: <20140425095600.GK43641@Space.Net> Hi, On Thu, Apr 24, 2014 at 01:08:06PM -0700, bmanning at vacation.karoshi.com wrote: > Glad to see a gradual return to the sanity of two decades ago. Can I have a Class A, please? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From zsako at iszt.hu Fri Apr 25 12:30:08 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 25 Apr 2014 12:30:08 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <20140425095600.GK43641@Space.Net> References: <53592CAA.2090608@CC.UniVie.ac.at> <20140424200806.GA32025@vacation.karoshi.com> <20140425095600.GK43641@Space.Net> Message-ID: <535A3930.7070107@iszt.hu> Dear Gert, > Can I have a Class A, please? You can try at the nearest bookshop: http://en.wikipedia.org/wiki/Class_A_%28novel%29 there may be a couple left, however, I fear this is not what you are looking for. :) Best regards, Janos > Gert Doering > -- NetMaster > From bmanning at vacation.karoshi.com Fri Apr 25 12:41:30 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 25 Apr 2014 03:41:30 -0700 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <20140425095600.GK43641@Space.Net> References: <53592CAA.2090608@CC.UniVie.ac.at> <20140424200806.GA32025@vacation.karoshi.com> <20140425095600.GK43641@Space.Net> Message-ID: <20140425104130.GA3060@vacation.karoshi.com> On Fri, Apr 25, 2014 at 11:56:00AM +0200, Gert Doering wrote: > Hi, > > On Thu, Apr 24, 2014 at 01:08:06PM -0700, bmanning at vacation.karoshi.com wrote: > > Glad to see a gradual return to the sanity of two decades ago. > > Can I have a Class A, please? > > Gert Doering > -- NetMaster > -- No. Classes were abolished last century. However you are certainly welcome to a /8 or its equivalent, a /32. Pick one up on your way out the door. Oh, and never come back for more 'cause thats all you'll ever need. /bill From ebais at a2b-internet.com Fri Apr 25 13:38:10 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 25 Apr 2014 13:38:10 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <20140425104130.GA3060@vacation.karoshi.com> References: <53592CAA.2090608@CC.UniVie.ac.at> <20140424200806.GA32025@vacation.karoshi.com> <20140425095600.GK43641@Space.Net> <20140425104130.GA3060@vacation.karoshi.com> Message-ID: <00c701cf607a$dcc68cb0$9653a610$@a2b-internet.com> Hi Bill, Before we are going completely off-topic, I'm pretty sure you are aware that Gert won't settle for just a /32 and never come back, as he could get it extended to a /29 these days ... On topic ... As we are still discussing the proposal, I'll discus with PDO and the WG chairs if they agree with me to extend the discussion phase with 2 weeks. Regards, Erik Bais From gert at space.net Fri Apr 25 15:11:46 2014 From: gert at space.net (Gert Doering) Date: Fri, 25 Apr 2014 15:11:46 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) In-Reply-To: <00c701cf607a$dcc68cb0$9653a610$@a2b-internet.com> References: <53592CAA.2090608@CC.UniVie.ac.at> <20140424200806.GA32025@vacation.karoshi.com> <20140425095600.GK43641@Space.Net> <20140425104130.GA3060@vacation.karoshi.com> <00c701cf607a$dcc68cb0$9653a610$@a2b-internet.com> Message-ID: <20140425131146.GQ43641@Space.Net> Hi, On Fri, Apr 25, 2014 at 01:38:10PM +0200, Erik Bais wrote: > Before we are going completely off-topic, I'm pretty sure you are aware that > Gert won't settle for just a /32 and never come back, as he could get it > extended to a /29 these days ... > > On topic ... As we are still discussing the proposal, I'll discus with PDO > and the WG chairs if they agree with me to extend the discussion phase with > 2 weeks. Please extend it to just after the RIPE meeting, so we have the discussion phase plus the "face to face" discussions to base the "how to go ahead?" discussions on. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From sandra.sendra.upv at gmail.com Fri Apr 25 17:36:33 2014 From: sandra.sendra.upv at gmail.com (Sandra Sendra) Date: Fri, 25 Apr 2014 17:36:33 +0200 Subject: [address-policy-wg] IEEE TrustCom Deadline is Approaching: May 5, 2014 Message-ID: <201404251536.s3PFaXF9010757@smtp.upv.es> [Please accept our apologies if you receive multiple copies of this email] *********************** CFP ******************************* The 13th IEEE International Conference on Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-14) http://www.greenorbs.org/TrustCom2014/ 24-26 September 2014, Beijing, China Important Dates Workshop Proposal: May 5, 2014 Submission Deadline: 11:59PM (UTC/GMT+8 hours) May 5, 2014 (This is the firm deadline) Authors Notification: June 26, 2014 Final Manuscript Due: July 20, 2014 Publications Accepted and presented papers will be included in the IEEE CPS Proceedings. Distinguished papers presented at the conference, after further revision, will be published in special issues of the following high quality international journals (pending). - Computers & Security - Elsevier (Impact factor=0.868) - Concurrency and Computation: Practice and Experience - Wiley (Impact factor=0.636) - Security and Communication Networks - Wiley (Impact factor=0.414) - Future Generation Computer Systems - Elsevier (Impact factor=1.978) - Multimedia Tools and Applications - Springer (Impact factor=0.617) - Journal of Internet Technology (Impact factor=0.508) - Journal of Computer and System Sciences - Elsevier (Impact factor=1.157) Topics Trust Track - Trust semantics, metrics and models - Trusted computing platform - Trusted network computing - Trusted operating systems - Trusted software and applications - Trust in social networks - Trust in e-commerce and e-government - Trust in mobile and wireless communications - Risk and reputation management - Survivable computer systems/networks - Miscellaneous trust issues Security Track - Network security - Computer security - Database security - Web applications security - Security policy, model and architecture - Security in social networks - Security in parallel and distributed systems - Security in mobile and wireless communications - Security in grid/cloud/pervasive computing - Authentication, authorization and accounting - Miscellaneous security issues Privacy Track - Privacy in Web-based applications and services - Privacy in database systems - Privacy in parallel and distributed systems - Privacy in grid/cloud/pervasive computing - Privacy in mobile and wireless communications - Privacy in e-commerce and e-government - Privacy in network deployment and management - Privacy and trust - Privacy and security - Privacy and anonymity - Miscellaneous privacy issues Organisation Committee General Chairs: Jiaguang Sun, Tsinghua University, China Ivan Stojmenovic, University of Ottawa, Canada Program Chair: Yunhao Liu, Tsinghua University, China Publicity Chairs: Sandra Sendra Compte, Polytechnic University of Valencia, Spain Haojin Zhu, Shanghai Jiao Tong University, China Xiaodong Lin, University of Ontario Institute of Technology, Canada Workshop Chairs: Yang Xiang, Deakin University, Australia Kouichi Sakurai, Kyushu University, Japan Publication Chair: Jemal Abawajy, Deakin University, Australia Steering and Program Committees: Please see http://www.greenorbs.org/TrustCom2014/ From mschmidt at ripe.net Wed Apr 30 10:49:56 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 30 Apr 2014 10:49:56 +0200 Subject: [address-policy-wg] RIPE 67 Address Policy WG Draft Minutes Message-ID: <5360B934.2000105@ripe.net> Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 67 have now been published: https://www.ripe.net/ripe/groups/wg/ap/minutes/ripe-67 Please let us know any corrections or amendments. Kind regards Marco Schmidt Policy Development Officer RIPE NCC From datos at tvt-datos.es Wed Apr 30 11:56:18 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Wed, 30 Apr 2014 11:56:18 +0200 Subject: [address-policy-wg] Use of the Reserved IP Pool In-Reply-To: <000001cf5f27$5e5b78d0$1b126a70$@a2b-internet.com> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <53578DA5.3060707@schiefner.de> <5357E8F9.9090100@fud.no> <5357EAD0.6060903@fud.no> <000001cf5f27$5e5b78d0$1b126a70$@a2b-internet.com> Message-ID: <5360C8C2.9030501@tvt-datos.es> 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 at ripe.net > [mailto:address-policy-wg-bounces at ripe.net] Namens Tore Anderson > Verzonden: woensdag 23 april 2014 18:31 > Aan: Carsten Schiefner; Leo Vegoda > CC: address-policy-wg at 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 at 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). From ripe-wgs.cs at schiefner.de Wed Apr 30 12:20:17 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 30 Apr 2014 12:20:17 +0200 Subject: [address-policy-wg] Use of the Reserved IP Pool In-Reply-To: <5360C8C2.9030501@tvt-datos.es> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <53578DA5.3060707@schiefner.de> <5357E8F9.9090100@fud.no> <5357EAD0.6060903@fud.no> <000001cf5f27$5e5b78d0$1b126a70$@a2b-internet.com> <5360C8C2.9030501@tvt-datos.es> Message-ID: <5360CE61.6000806@schiefner.de> 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. From datos at tvt-datos.es Wed Apr 30 12:23:19 2014 From: datos at tvt-datos.es (Dpto. Datos Television Costa Blanca) Date: Wed, 30 Apr 2014 12:23:19 +0200 Subject: [address-policy-wg] Use of the Reserved IP Pool In-Reply-To: <5360CE61.6000806@schiefner.de> References: <5343DD47.7060106@tvt-datos.es> <8DCB1D87-3683-4369-BF34-F7476FD53182@steffann.nl> <534577D7.8020300@tvt-datos.es> <20140409181553.GK43641@Space.Net> <534CEA02.5000700@tvt-datos.es> <534D1F01.4070307@CC.UniVie.ac.at> <534D5196.40700@tvt-datos.es> <534DA5A7.60208@fud.no> <39CB3184-C6F4-46A1-A3BA-6E5BA0529FD9@steffann.nl> <534FE465.7050605@tvt-datos.es> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30956@EXVPMBX100-1.exc.icann.org> <53505D93.7080104@velea.eu> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30978@EXVPMBX100-1.exc.icann.org> <5648A8908CCB564EBF46E2BC904A75B1A3BEE30A64@EXVPMBX100-1.exc.icann.org> <53578DA5.3060707@schiefner.de> <5357E8F9.9090100@fud.no> <5357EAD0.6060903@fud.no> <000001cf5f27$5e5b78d0$1b126a70$@a2b-internet.com> <5360C8C2.9030501@tvt-datos.es> <5360CE61.6000806@schiefner.de> Message-ID: <5360CF17.6050207@tvt-datos.es> 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 at 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). From mschmidt at ripe.net Wed Apr 30 15:28:17 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 30 Apr 2014 15:28:17 +0200 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) Message-ID: Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 We encourage you to review this proposal and send your comments to before 29 May 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From johan at robtex.com Wed Apr 30 18:05:59 2014 From: johan at robtex.com (Johan Boger) Date: Wed, 30 Apr 2014 19:05:59 +0300 Subject: [address-policy-wg] Support of https://www.ripe.net/ripe/policies/proposals/2014-03 Message-ID: Dear Colleagues, I hereby vote YES on the proposal linked at https://www.ripe.net/ripe/policies/proposals/2014-03 Best Regards, -- Johan Boger, Project Manager (AS48285) e: johan at robtex.com w: http://www.robtex.com l: cy.robtex -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.blessing at despres.co.uk Wed Apr 30 19:30:13 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 30 Apr 2014 18:30:13 +0100 Subject: [address-policy-wg] 2014-03 New Policy Proposal (Remove Multihoming Requirement for AS Number Assignments) In-Reply-To: <5360fbba.48c70e0a.6580.33b8SMTPIN_ADDED_MISSING@mx.google.com> References: <5360fbba.48c70e0a.6580.33b8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 30 April 2014 14:28, Marco Schmidt wrote: > https://www.ripe.net/ripe/policies/proposals/2014-03 > Other than the use cases suggested in the document (which could be achieved using private ASNs) is there a reason for this that I'm missing? With other discussions about recovering non globally routed ASNs this just seem odd J -- James Blessing 07989 039 476