From andrea at ripe.net Mon Mar 3 10:32:19 2014 From: andrea at ripe.net (Andrea Cima) Date: Mon, 03 Mar 2014 10:32:19 +0100 Subject: [address-policy-wg] New AS Number Blocks allocated to the RIPE NCC Message-ID: <53144C23.5050203@ripe.net> Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA in February 2014. 200192-201215 201216-202239 You may want to update your records accordingly. Best regards, Andrea Cima Registration Services Manager RIPE NCC From elvis at v4escrow.net Tue Mar 4 01:25:35 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 04 Mar 2014 01:25:35 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space Message-ID: <53151D7F.6010006@v4escrow.net> Hi everyone, I'd like to restart the discussion that was taking place on the mailing list before the RIPE Meeting in Athens. The discussion happened on the mailing list and in Athens and moved to a discussion on whether we should permit PI transfers through policy -> I understand that Erik Bais is working on a policy proposal that would include PI transfers. However, the discussion on ASSIGNED PI to ALLOCATED PA status change for address space given and used by the LIR has been stopped and I would like to restart it. My opinion is that I don't think a policy is needed for these changes to be performed by the RIPE NCC at the request of the LIR. Changes from ALLOCATED PI to ALLOCATED PA have been done in the past; plus - Tore has also pointed out some precedent where ASSIGNED PIs have been changed to ALLOCATED PAs. By keeping the artificial limit of PI used by LIRs the registry is suffering as any assignments made within that PI block are not properly recorded in the registry/RIPE Database. By looking back at the feedback received from lots of people in the community (and I counted at least 20 people responding to Andrea's e-mail) I have the feeling that this should have been already implemented. Therefore, I'm curious: - should we restart the discussion? - was the minimum limit of the prefix size the only reason why it hasn't yet been implemented? (some were saying any prefix, some were saying min /22) - or was it already implemented and I missed the announcement? 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 v4escrow.net Tue Mar 4 02:50:52 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 04 Mar 2014 02:50:52 +0100 Subject: [address-policy-wg] IPv6 PA/PI - restarting discussion after failed 2013-06 proposal Message-ID: <5315317C.90308@v4escrow.net> Hi everyone, 2013-06 has failed to become policy and we all understand that it presented such big changes that it became too complex. I would like to restart that discussion and see what are the problems/failures of the IPv6 policies (both PI and PA) and come up with a proposal to fix these problems. I'd like to start with the first 4 problems that I have noticed: #1. In IPv4 a PI user can connect a customer to it's network or allow a customer to use a dedicated server using one IP address. This limitation had been extended to up to a /29 (in case redundant connections were offered - ie:VRRP) but most of the cases I have encountered were using either a /32 or a /30. Currently, the IPv6 policy states that the minimum a customer should use is a /64. And because the minimum per customer is a /64, when someone would actually use IPv6 PI for a customer, it would make an assignment of a subnet and violate the policy. I've heard of people using /128s for the servers of their customers and sharing the same vlan amongst multiple customers in the same /64. Others are just requesting a/48 PI and expect never to come back for more (therefore, could not care less about policies). Others just know that the RIPE NCC has no way to see if they sub-assign parts of the /48 PI, so they just request a /48 PI, promise never to sub-assign and later on, forget about the promise. Therefore, I propose that the first change we make to the IPv6 PI policy is that where a /64 could be used per customer (regardless of the service offered to that customer) only if it is registered properly in the RIPE Database. The change would allow PI users to sub-assign in IPv6, but only small (?) amounts of space and only if they actually register the assignment. #2. Second problem I've noticed is the fact that LIRs can receive /32s (and up to /29s) only by asking. On the other hand, if you do not want to become a RIPE NCC member or just can not, you are forced to use IPv6 - a /48. Additionally, this IPv6 PI can only be used for your own infrastructure and not to provide any service (other than SaaS) to your customers without violating the policy (see problem statement #1). One could request more than a /48 but it would need to demonstrate that it has two or more sites that have different routing policies or demonstrate that it has a need for more than 65K subnets. I would like to introduce the IPv6 PI ALLOCATION. This time, the PI allocation could be made to the PI user and the user could actually make assignments from it. The PI allocation would be just as large as the PA Allocation and the price for it would be no less than 50% of the membership fee (Off course, the fees can only be voted upon at the GM and the example is just purely theoretical). This would introduce that 'additional registry' which we never knew how to name during the discussions of 2013-06 and would allow PI users to request/receive a /29 from which they could make assignments. Everyone will say that /32 or /29 will become the new /48. Well, that may be true, on the other hand, it may be the price that could keep the number of large PI Allocations low. Additionally, we could add an arbitrary limit. For example, say that you can request an IPv6 PI Allocation only if you already have x hundred customers that will receive an assignment from you immediately. #3. Minimum assignment size The policy says that the minimum assignment size is a /64. However, the RIPE Database does not enforce this rule and I have seen /128s registered. for example: inet6num: 2001:b70:f000::/112 inet6num: 2001:820:0:1:1::1000/116 inet6num: 2a01:2f0f:ffff:ffff:100:1000::1/128 There are over 700 inet6num objects registered which are below a /64. If we take the policy literally, all these assignments currently violate the policy. Therefore, I think we should either change/remove the minimum assignment size or have the RIPE Database block the creation of any IPv6 assignment smaller than a /64. #4. fix utilisation and hd-ratio vs assignment size While the HD-ratio is being calculated in terms of /56s, the policy says (at point 5.4.1.) that the minimum assignment that can be made is a /64. Furthermore, as you can see above, /128s can be registered in the RIPE Database as well. If we will continue allowing the registration of less than /56 assignments, it will be difficult to almost impossible to the IPRAs to actually calculate what is the HD-ratio of an IPv6 allocation. While now it is too early to see additional IPv6 allocation requests, if we keep doing things as we've been doing for the past years, we will end up in a few years with a huge mess in the registry and the impossibility to calculate the HD-ratio without applying random procedures. A very simple and quick fix would be to say that if any prefix is registered, the whole /56 that includes the prefix is in use. But then, we may see people registering/using /128s from different /56s just to reach the HD-ratio for an additional allocation. Would that still be considered an efficient usage? An other option would be to change the HD-ratio calculation to the actual number of IP addresses used and consider all the IP addresses from an assignment used if correctly registered in the RIPE Database. Once we have worked out whether these 4 issues are indeed flaws in the policy or not and whether we want them fixed or not, I would like to hear your opinion in what else should be modified in the IPv6 policies. I will then collect all the feedback, probably present it at the next RIPE Meeting, and start to discuss an other approach/policy proposal to achieve what 2013-06 failed to achieve. 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 ripe-wgs.cs at schiefner.de Tue Mar 4 09:30:27 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 04 Mar 2014 09:30:27 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <53151D7F.6010006@v4escrow.net> References: <53151D7F.6010006@v4escrow.net> Message-ID: <53158F23.50402@schiefner.de> Elvis, all - this is being worked on as we speak. A little more patience, please - if I may ask. I am confident - at least I hope - that something presentable will be ready for the upcoming RIPE meeting in Warsaw. Best regards, -C. On 04.03.2014 01:25, Elvis Daniel Velea wrote: > Hi everyone, > > I'd like to restart the discussion that was taking place on the mailing > list before the RIPE Meeting in Athens. > > The discussion happened on the mailing list and in Athens and moved to a > discussion on whether we should permit PI transfers through policy -> I > understand that Erik Bais is working on a policy proposal that would > include PI transfers. However, the discussion on ASSIGNED PI to > ALLOCATED PA status change for address space given and used by the LIR > has been stopped and I would like to restart it. > > My opinion is that I don't think a policy is needed for these changes to > be performed by the RIPE NCC at the request of the LIR. Changes from > ALLOCATED PI to ALLOCATED PA have been done in the past; plus - Tore has > also pointed out some precedent where ASSIGNED PIs have been changed to > ALLOCATED PAs. > > By keeping the artificial limit of PI used by LIRs the registry is > suffering as any assignments made within that PI block are not properly > recorded in the registry/RIPE Database. > > By looking back at the feedback received from lots of people in the > community (and I counted at least 20 people responding to Andrea's > e-mail) I have the feeling that this should have been already implemented. > > Therefore, I'm curious: > - should we restart the discussion? > - was the minimum limit of the prefix size the only reason why it hasn't > yet been implemented? (some were saying any prefix, some were saying min > /22) > - or was it already implemented and I missed the announcement? > > 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. From tore at fud.no Tue Mar 4 13:16:19 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 04 Mar 2014 13:16:19 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <53151D7F.6010006@v4escrow.net> References: <53151D7F.6010006@v4escrow.net> Message-ID: <5315C413.1020808@fud.no> * Elvis Daniel Velea > Tore has also pointed out some precedent where ASSIGNED PIs have been > changed to ALLOCATED PAs. Small correction here, I only noted that there exist some ALLOCATED PA in the database that are smaller than the minimum allocation size. I do not know how that came to be, so I don't know if they were ASSIGNED PI before. My point was that the minimum allocation size doesn't appear to be a hard limit on what is the minimum ALLOCATED PA object that is allowed to exist in the registry; but rather it should be considered the minimum allocation size the RIPE NCC is willing to issue[1] new at any given time. A PI->PA conversion isn't a "new issue" in that way, hence there's no real reason to apply the minimum allocation size, IMHO. As those mini-assignments are already in the registry, it doesn't hurt aggregation either. In any case, it would appear to me that the community is simply waiting for someone (perhaps you and/or Erik?) to care enough to actually submit a formal policy proposal to allow for such conversions. The NCC indicated that they felt clear policy was needed. [1] This is irrelevant today in any case: min-size == max-size == /22. Tore From elvis at v4escrow.net Tue Mar 4 14:04:08 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 04 Mar 2014 14:04:08 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <5315C413.1020808@fud.no> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> Message-ID: <5315CF48.7070209@v4escrow.net> Hi Tore, On 04/03/14 13:16, Tore Anderson wrote: > * Elvis Daniel Velea > >> Tore has also pointed out some precedent where ASSIGNED PIs have been >> changed to ALLOCATED PAs. > Small correction here, I only noted that there exist some ALLOCATED PA > in the database that are smaller than the minimum allocation size. I do > not know how that came to be, so I don't know if they were ASSIGNED PI > before. thanks for the correction. I was under the impression that you had remarked PI to PA conversions. I've only now checked the history of the blocks you have mentioned and these have always been ALLOCATED PA (with an allocation size lower than the minimum). > > My point was that the minimum allocation size doesn't appear to be a > hard limit on what is the minimum ALLOCATED PA object that is allowed to > exist in the registry; but rather it should be considered the minimum > allocation size the RIPE NCC is willing to issue[1] new at any given > time. A PI->PA conversion isn't a "new issue" in that way, hence there's > no real reason to apply the minimum allocation size, IMHO. As those > mini-assignments are already in the registry, it doesn't hurt > aggregation either. I understand and agree with you. However, let's not forget that the RIPE NCC has made in the past PI assignments of even a /29. > In any case, it would appear to me that the community is simply waiting > for someone (perhaps you and/or Erik?) to care enough to actually submit > a formal policy proposal to allow for such conversions. The NCC > indicated that they felt clear policy was needed. I see. I was under a different impression, that the community was waiting for a policy proposal from Erik which would enable PI transfers. Erik, are you working on a proposal that would (also) enable status changes? Do you need help with it? 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 lutz at iks-jena.de Tue Mar 4 09:42:17 2014 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 4 Mar 2014 08:42:17 +0000 (UTC) Subject: [address-policy-wg] Post Ident / Post Brief References: <20140225230334.GC16279@srv03.cluenet.de> Message-ID: * Daniel Roesen wrote: > But a German copying his/her personal ID is certainly violating the law. Ack. > BTW, this is only true for personal ID card (Personalausweis) and > possibly passport, but not for e.g. driving license as far as I'm aware. You are right. > in the first place. This is a fundamental data protection principle in > german law (which again, NCC doesn't have to abide to as far as I > understand - IANAL): > > Datenschutz beginnt mit Datenvermeidung > (data protection starts with preventing collection of data) It's also the common baseground for international data protection regulations. OTOH the Law Enforcement Agencies and Intellectual Property Lobbyists (at least at ICANN) are very very keen about collecting as accurate information as possible about everybody. The LEAs do know, that they do not have a chance against organized crime with this procedure. Organized crime does found and operate LIRs as well as registrars themself. So when dealing with such counterparts you are lost anyway. To summarize the point: I do understand the pressure RIPE NCC has to deal with. But they (and we all) have to fight those interests. There is not benefit in trading privacy for sercurity. From lutz at iks-jena.de Tue Mar 4 09:47:56 2014 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 4 Mar 2014 08:47:56 +0000 (UTC) Subject: [address-policy-wg] Post Ident / Post Brief References: <530DD219.6010001@CC.UniVie.ac.at> Message-ID: * Wilfried Woeber wrote: > I am wondering how German Citizens are dealing with the fact that *many* > Hotels and other accomodation businesses *require* to take a copy of an > official ID Document, in many cases due to local regulations to establish > and track identity of travellers? I do clearly state that they are allowed to check the id card, but not to copy it or store it away. Even in USA I did not have any problems with it (despite immigration services at LAX). Oh, there is one exeption. I asked the German Bundestag (which take your ID card away if you enter the buildings) how they fullfil this (new) law, because I was invited to a working group there. It took a week for a formal response claiming that the German Bundestag is not covered by the audience of this law. Brilliant! > Or is this law only applicable to German Citizens being physically present > in Germany? No. From erik at bais.name Wed Mar 19 17:17:57 2014 From: erik at bais.name (Erik Bais) Date: Wed, 19 Mar 2014 16:17:57 +0000 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <5315CF48.7070209@v4escrow.net> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> <5315CF48.7070209@v4escrow.net> Message-ID: <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> Hi Elvis & Tore, In any case, it would appear to me that the community is simply waiting for someone (perhaps you and/or Erik?) to care enough to actually submit a formal policy proposal to allow for such conversions. The NCC indicated that they felt clear policy was needed. I see. I was under a different impression, that the community was waiting for a policy proposal from Erik which would enable PI transfers. Erik, are you working on a proposal that would (also) enable status changes? Do you need help with it? The policy that I?m working on currently is the one to enable PI transfers. I was under the impression that there was enough support for the LIR Infrastructure PI to PA change that there wasn?t additional policy needed after the discussion in Athens. Regards, Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Wed Mar 19 17:55:24 2014 From: elvis at velea.eu (Elvis Velea) Date: Wed, 19 Mar 2014 18:55:24 +0200 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> <5315CF48.7070209@v4escrow.net> <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> Message-ID: <5329CBFC.9070803@velea.eu> Hi Erik, On 19/03/14 18:17, Erik Bais wrote: > > Hi Elvis & Tore, > [...] > > > I was under the impression that there was enough support for the LIR > Infrastructure PI to PA change that there wasn?t additional policy > needed after the discussion in Athens. > Maybe someone from the NCC can tell us if they are waiting for the community to make a policy proposal or whether they are implementing/accepting PI to PA conversions for PI registered as LIR infrastructure. > > Regards, > > Erik Bais > Kind regards, Elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Wed Mar 19 19:20:39 2014 From: gert at space.net (Gert Doering) Date: Wed, 19 Mar 2014 19:20:39 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> <5315CF48.7070209@v4escrow.net> <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> Message-ID: <20140319182039.GE43641@Space.Net> Hi, On Wed, Mar 19, 2014 at 04:17:57PM +0000, Erik Bais wrote: > I was under the impression that there was enough support for the LIR Infrastructure PI to PA change that there wasn?t additional policy needed after the discussion in Athens. Right. What I understood was that the NCC is having second thoughts here regarding minimum allocation size, and is waiting for the policy proposal to get rid of the formal minimum allocation size before going forward with the PI-to-PA-change. So for the change itself, no extra policy is needed. 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 andrea at ripe.net Thu Mar 20 14:51:36 2014 From: andrea at ripe.net (Andrea Cima) Date: Thu, 20 Mar 2014 14:51:36 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <5329CBFC.9070803@velea.eu> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> <5315CF48.7070209@v4escrow.net> <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> <5329CBFC.9070803@velea.eu> Message-ID: <532AF268.3030008@ripe.net> Hi Elvis, On 19/3/14 5:55 PM, Elvis Velea wrote: > Hi Erik, > > On 19/03/14 18:17, Erik Bais wrote: >> >> Hi Elvis & Tore, >> > [...] >> >> >> I was under the impression that there was enough support for the LIR >> Infrastructure PI to PA change that there wasn?t additional policy >> needed after the discussion in Athens. >> > Maybe someone from the NCC can tell us if they are waiting for the > community to make a policy proposal or whether they are > implementing/accepting PI to PA conversions for PI registered as LIR > infrastructure. Indeed there is no need for a policy proposal in order to allow for a status change from 'ASSIGNED PI' to 'ALLOCATED PA'. This will apply to IP blocks equal or larger than the minimum allocation size and assigned to an LIR's infrastructure. The procedure is being finalised and I am confident it will be published and announced next week. I hope this clarifies. Regards, Andrea Cima RIPE NCC >> Regards, >> >> Erik Bais >> > Kind regards, > Elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Thu Mar 20 16:03:40 2014 From: elvis at velea.eu (Elvis Velea) Date: Thu, 20 Mar 2014 17:03:40 +0200 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <532AF268.3030008@ripe.net> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> <5315CF48.7070209@v4escrow.net> <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> <5329CBFC.9070803@velea.eu> <532AF268.3030008@ripe.net> Message-ID: <532B034C.7020309@velea.eu> Hi Andrea, On 20/03/14 15:51, Andrea Cima wrote: > > Hi Elvis, [...] >> Maybe someone from the NCC can tell us if they are waiting for the >> community to make a policy proposal or whether they are >> implementing/accepting PI to PA conversions for PI registered as LIR >> infrastructure. > > Indeed there is no need for a policy proposal in order to allow for a > status change from 'ASSIGNED PI' to 'ALLOCATED PA'. This will apply to > IP blocks equal or larger than the minimum allocation size and > assigned to an LIR's infrastructure. The procedure is being finalised > and I am confident it will be published and announced next week. > thank you for clarifying the situation. Looking forward to the announcement :-) > > I hope this clarifies. It does. I feel that I am the only one that was confused and anxious to hear something :-) > Regards, > > Andrea Cima > RIPE NCC > Kind regards, Elvis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs.cs at schiefner.de Thu Mar 20 16:50:19 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 20 Mar 2014 16:50:19 +0100 Subject: [address-policy-wg] Changing the Status of PI Address Space In-Reply-To: <20140319182039.GE43641@Space.Net> References: <53151D7F.6010006@v4escrow.net> <5315C413.1020808@fud.no> <5315CF48.7070209@v4escrow.net> <862A73D42343AE49B2FC3C32FDDFE91CB478FE10@E2010-MBX04.exchange2010.nl> <20140319182039.GE43641@Space.Net> Message-ID: <532B0E3B.2020306@schiefner.de> All, On 19.03.2014 19:20, Gert Doering wrote: > On Wed, Mar 19, 2014 at 04:17:57PM +0000, Erik Bais wrote: >> I was under the impression that there was enough support for the >> LIR Infrastructure PI to PA change that there wasn?t additional >> policy needed after the discussion in Athens. > > Right. What I understood was that the NCC is having second > thoughts here regarding minimum allocation size, and is waiting for > the policy proposal to get rid of the formal minimum allocation > size before going forward with the PI-to-PA-change. So for the > change itself, no extra policy is needed. the proposal has been handed to the NCC earlier this week and is currently in the making of getting ready for publication. Best, -C. From andrea at ripe.net Mon Mar 24 13:01:28 2014 From: andrea at ripe.net (Andrea Cima) Date: Mon, 24 Mar 2014 13:01:28 +0100 Subject: [address-policy-wg] Converting PI assignments to PA allocations for LIRs Message-ID: <53301E98.9050404@ripe.net> Dear colleagues, At RIPE 66, we informed the Address Policy Working Group that an increasing number of members were asking to change the status of their inetnum objects from ?ASSIGNED PI? to ?ALLOCATED PA?. After RIPE 66, the discussion continued on this mailing list. Here, a lot of support was expressed for allowing LIRs to change the status of their resources, provided they are correctly registered with the RIPE NCC to the same legal entity that is registered as an LIR. Based on this input, we have now published the procedure to allow assignments to be converted: https://www.ripe.net/lir-services/resource-management/converting-pi-to-pa Kind regards, Andrea Cima Registration Services Manager RIPE NCC From mschmidt at ripe.net Mon Mar 24 14:18:44 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 24 Mar 2014 14:18:44 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Message-ID: Dear colleagues, A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-01 We encourage you to review this proposal and send your comments to before 22 April 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From rhe at nosc.ja.net Mon Mar 24 15:05:48 2014 From: rhe at nosc.ja.net (Rob Evans) Date: Mon, 24 Mar 2014 14:05:48 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Message-ID: <20140324140547.GA6900@nosc.ja.net> > http://www.ripe.net/ripe/policies/proposals/2014-01 Overall I think this is a good thing, but I wonder if there is a reason for leaving 5.4 (minimum sub-allocation size) as-is? If we open the door to transfer prefixes smaller than a /24, should sub-allocation of them be prevented? The routing side of me, of course, might consider the alternative of clamping the transfers at /24 too, but perhaps that should just be left for consenting adults to negotiate between themselves. Cheers, Rob From elvis at velea.eu Mon Mar 24 15:12:31 2014 From: elvis at velea.eu (Elvis Velea) Date: Mon, 24 Mar 2014 16:12:31 +0200 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140324140547.GA6900@nosc.ja.net> References: <20140324140547.GA6900@nosc.ja.net> Message-ID: <53303D4F.7070204@velea.eu> Hi Rob, I was just about to make the same comments :) I support the proposal although I would have proposed a minimum /24 (as it is in the other regions). However, leaving the decision in the hands of the operators sounds good as well. cheers, elvis On 24/03/14 16:05, Rob Evans wrote: >> http://www.ripe.net/ripe/policies/proposals/2014-01 > Overall I think this is a good thing, but I wonder if there is a reason > for leaving 5.4 (minimum sub-allocation size) as-is? > > If we open the door to transfer prefixes smaller than a /24, should > sub-allocation of them be prevented? > > The routing side of me, of course, might consider the alternative of > clamping the transfers at /24 too, but perhaps that should just be left > for consenting adults to negotiate between themselves. > > Cheers, > Rob > From scottleibrand at gmail.com Mon Mar 24 19:24:31 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 24 Mar 2014 11:24:31 -0700 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53303D4F.7070204@velea.eu> References: <20140324140547.GA6900@nosc.ja.net> <53303D4F.7070204@velea.eu> Message-ID: Would this proposal allow end users to request the transfer of a single IPv4 /32? Or is that prevented by RIPE requiring parties to a transfer to be LIRs? I am less worried about LIRs doing something stupid, but if it were allowed, I would guess that some end users would attempt to use /32 transfers the same way they use phone number portability. IMO it might be better to preserve some sort of minimum transfer size. Dropping it to a /24 (or farther) would make sense to me. Going all the way to /32 seems unnecessary and a bit risky, unless there are other good safeguards in place to ensure that any entities transferring a /32 are really in a position to route it themselves, and aren't just trying to impose the routing externality on the rest of the global table (and blaming someone else when their IPv4 /32 announcement isn't accepted everywhere). -Scott On Mon, Mar 24, 2014 at 7:12 AM, Elvis Velea wrote: > Hi Rob, > > I was just about to make the same comments :) > > I support the proposal although I would have proposed a minimum /24 (as it > is in the other regions). > > However, leaving the decision in the hands of the operators sounds good as > well. > > cheers, > elvis > > > On 24/03/14 16:05, Rob Evans wrote: > >> http://www.ripe.net/ripe/policies/proposals/2014-01 >>> >> Overall I think this is a good thing, but I wonder if there is a reason >> for leaving 5.4 (minimum sub-allocation size) as-is? >> >> If we open the door to transfer prefixes smaller than a /24, should >> sub-allocation of them be prevented? >> >> The routing side of me, of course, might consider the alternative of >> clamping the transfers at /24 too, but perhaps that should just be left >> for consenting adults to negotiate between themselves. >> >> Cheers, >> Rob >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Mar 24 19:29:18 2014 From: gert at space.net (Gert Doering) Date: Mon, 24 Mar 2014 19:29:18 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: References: <20140324140547.GA6900@nosc.ja.net> <53303D4F.7070204@velea.eu> Message-ID: <20140324182918.GE43641@Space.Net> Hi, On Mon, Mar 24, 2014 at 11:24:31AM -0700, Scott Leibrand wrote: > Would this proposal allow end users to request the transfer of a single > IPv4 /32? Technically, yes, if a) we permit PI transfers (proposal in the works), and b) the RIPE NCC has given out a /32 PI. End users reciving PA space have no transfer rights whatsoever, that space can only transfered by the PA holder (= the LIR). 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 marty at akamai.com Mon Mar 24 19:33:46 2014 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 24 Mar 2014 14:33:46 -0400 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140324182918.GE43641@Space.Net> References: <20140324140547.GA6900@nosc.ja.net> <53303D4F.7070204@velea.eu> <20140324182918.GE43641@Space.Net> Message-ID: <2D706553-DAA8-4989-B8D8-E03DE61CFAC3@akamai.com> On Mar 24, 2014, at 2:29 PM, Gert Doering wrote: > Hi, > > On Mon, Mar 24, 2014 at 11:24:31AM -0700, Scott Leibrand wrote: >> Would this proposal allow end users to request the transfer of a single >> IPv4 /32? > > Technically, yes, if a) we permit PI transfers (proposal in the works), > and b) the RIPE NCC has given out a /32 PI. > > End users reciving PA space have no transfer rights whatsoever, that space > can only transfered by the PA holder (= the LIR). > I'm generally in support of this proposal as-is, at this time. Best, -M< From tore at fud.no Mon Mar 24 19:38:02 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 24 Mar 2014 19:38:02 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140324140547.GA6900@nosc.ja.net> References: <20140324140547.GA6900@nosc.ja.net> Message-ID: <53307B8A.3010403@fud.no> * Rob Evans >> http://www.ripe.net/ripe/policies/proposals/2014-01 > > Overall I think this is a good thing, +1 > but I wonder if there is a reason for leaving 5.4 (minimum > sub-allocation size) as-is? > > If we open the door to transfer prefixes smaller than a /24, should > sub-allocation of them be prevented? I think not, that would not be consistent. Maybe it's just an oversight by the proposal's author to not have removed that particular paragraph? > The routing side of me, of course, might consider the alternative of > clamping the transfers at /24 too, but perhaps that should just be left > for consenting adults to negotiate between themselves. I say the latter. The current de-facto routing limit of /24 isn't something borne out of our address policies, it's a limit the routing community has come up with all on its own. So if we're putting in /24 in the policy we're not really ?clamping? anything, rather just documenting today's operational reality (which could possibly change, in turn making policy outdated). Besides, it's only ALLOCATED PA and SUB-ALLOCATED PA inetnums that are have a minimum size of >= /24 anyway. inetnums with status ASSIGNED PI? can be /29, ASSIGNED PA?, as well as route objects? can be any length up to and including /32. Sky isn't falling yet though. :-) [1] http://www.ripe.net/ripe/docs/ripe-555#longest-prefix-tables [2] whois -T inetnum -x 185.47.43.255/32 [3] whois -T route -x 185.47.43.255/32 In the end I think the operators is perfectly capable of figuring out what's the minimum size route advertisement they're willing to accept without RIPE address policy instructing them (or pretending to, anyway). Perhaps the ability to recycle infrastructure PI assignments as PA could even be considered a small incentive for some operators to migrate some of their infrastructure to IPv6, thus freeing up precious IPv4 resources that can be then assigned to revenue-generating customers - alongside an IPv6 assignment of course... :-) Tore From scottleibrand at gmail.com Mon Mar 24 19:43:59 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 24 Mar 2014 11:43:59 -0700 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140324182918.GE43641@Space.Net> References: <20140324140547.GA6900@nosc.ja.net> <53303D4F.7070204@velea.eu> <20140324182918.GE43641@Space.Net> Message-ID: On Mon, Mar 24, 2014 at 11:29 AM, Gert Doering wrote: > Hi, > > On Mon, Mar 24, 2014 at 11:24:31AM -0700, Scott Leibrand wrote: > > Would this proposal allow end users to request the transfer of a single > > IPv4 /32? > > Technically, yes, if a) we permit PI transfers (proposal in the works), > and b) the RIPE NCC has given out a /32 PI. > If RIPE NCC has given out a /32 of PI, I'm fine with it being transferable. I'm more concerned about lots of people attempting to carve out and transfer (to end users) IPV4 /32s from larger blocks. Thanks, Scott > > End users reciving PA space have no transfer rights whatsoever, that space > can only transfered by the PA holder (= the LIR). > > 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 -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Mon Mar 24 22:44:21 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 24 Mar 2014 22:44:21 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy Message-ID: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Hi, As you might know, we are currently working on a policy proposal to allow the transfer of PI space. One of the topics that I would like some input (prior to sending out the proposal itself) it the following: In the current draft, I?ve phrased one of the ?rules? for the PI transfer as follows: - Assignments smaller than the minimal allocation size, can?t be split into smaller assignments, but can be re-assigned as a complete assignment. My reasoning is that it would disallow cutting up small assignments into even smaller assignments. So in the current situation a /23 PI assignment is smaller than the minimal allocation size, however assigned in the past by the RIPE NCC. With the above stated ?rule? in the proposal, it would not be allowed to split up a PI assignment into 2 PI assignments of a /24 .. or 4 PI assignments of a /25, but it would be allowed to do a complete re-assignments as a /23. With the current new proposal 2014-1 put forward today, the question that we discussed last week (myself, Marco and Andrea ) is that if we would put this forward, that this might need to be re-phrased. The question that I have is, would the community prefer a transfer policy proposal for PI with or without the above stated rule or limitation in freedom in transfers of PI. The goal of the PI transfer policy proposal is to have it similar as the current Transfer policy for PA space. Let?s hear it. Regards Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Mar 25 00:10:59 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 08:10:59 +0900 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Message-ID: > - Assignments smaller than the minimal allocation size, can't be split > into smaller assignments, but can be re-assigned as a complete > assignment. it's before brekkie and only one cuppa, so i am a little slow. it might help if you explained why. randy From turchanyi.geza at gmail.com Tue Mar 25 02:18:10 2014 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 25 Mar 2014 02:18:10 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Message-ID: H? Randy, On Tue, Mar 25, 2014 at 12:10 AM, Randy Bush wrote: > > - Assignments smaller than the minimal allocation size, can't be split > > into smaller assignments, but can be re-assigned as a complete > > assignment. > > it's before brekkie and only one cuppa, so i am a little slow. it might > help if you explained why. > > randy > Just not to create more junks in the routing table... -- if I may repeat my wellknown argument. (I am also slow, btw) Best, Geza -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Mar 25 02:24:50 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 10:24:50 +0900 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Message-ID: >>> - Assignments smaller than the minimal allocation size, can't be split >>> into smaller assignments, but can be re-assigned as a complete >>> assignment. >> it's before brekkie and only one cuppa, so i am a little slow. it might >> help if you explained why. > Just not to create more junks in the routing table... -- if I may repeat > my wellknown argument. (I am also slow, btw) then it should say so fwiw, persoally i gave up this battle years ago. and i suspect there will be serious fragmentation as we go down the run-out path. randy From tore at fud.no Tue Mar 25 04:12:04 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 25 Mar 2014 04:12:04 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Message-ID: <5330F404.3090701@fud.no> * Erik Bais > - Assignments smaller than the minimal allocation size, can?t be > split into smaller assignments, but can be re-assigned as a complete > assignment. > > My reasoning is that it would disallow cutting up small assignments into > even smaller assignments. That is would be somewhat illogical IMHO. Assignments and allocations are two different things. The minimum allocation size has never been applied to assignments, so why start now? We've never had a minimum assignment size, at least not in recent years. > The question that I have is, would the community prefer a transfer > policy proposal for PI with or without the above stated rule or > limitation in freedom in transfers of PI. Without. I am not at all concerned about the routing table here. There is nothing in policy nor in the RIPE database software that prevents people from adding /32 route objects and attempting to advertise them into the DFZ. There are at the moment 3888 route objects in the database with that are /25 or longer, but the routing community seem to be able to ignore them just fine. I don't see how "nano-PI" would be any different, the routing community won't have any difficulty ignoring those either. After all, a router couldn't care less if a route is from an inetnum with status "ASSIGNED PA" or "ASSIGNED PI". Or to put it another way, we don't need policy to forbid every bad idea under the sun. Let the routing community decide how they want to deal with this one. Tore From randy at psg.com Tue Mar 25 07:48:30 2014 From: randy at psg.com (Randy Bush) Date: Tue, 25 Mar 2014 15:48:30 +0900 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <5330F404.3090701@fud.no> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <5330F404.3090701@fud.no> Message-ID: >> My reasoning is that it would disallow cutting up small assignments >> into even smaller assignments. > > That is would be somewhat illogical IMHO. Assignments and allocations > are two different things. The minimum allocation size has never been > applied to assignments, so why start now? We've never had a minimum > assignment size, at least not in recent years. is that the pink integers or the red ones? From turchanyi.geza at gmail.com Tue Mar 25 08:56:35 2014 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Tue, 25 Mar 2014 08:56:35 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <5330F404.3090701@fud.no> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <5330F404.3090701@fud.no> Message-ID: Hello Tore, May I interpret your words this way: Policy making and routing are two very separated, distinct actions?! While I fully understand the attitude of the routing community, I would encourage people raise their voices against bad policy making. Thanks, Geza On Tue, Mar 25, 2014 at 4:12 AM, Tore Anderson wrote: > * Erik Bais > > > - Assignments smaller than the minimal allocation size, can't be > > split into smaller assignments, but can be re-assigned as a complete > > assignment. > > > > My reasoning is that it would disallow cutting up small assignments into > > even smaller assignments. > > That is would be somewhat illogical IMHO. Assignments and allocations > are two different things. The minimum allocation size has never been > applied to assignments, so why start now? We've never had a minimum > assignment size, at least not in recent years. > > > The question that I have is, would the community prefer a transfer > > policy proposal for PI with or without the above stated rule or > > limitation in freedom in transfers of PI. > > Without. > > I am not at all concerned about the routing table here. There is nothing > in policy nor in the RIPE database software that prevents people from > adding /32 route objects and attempting to advertise them into the DFZ. > There are at the moment 3888 route objects in the database with that are > /25 or longer, but the routing community seem to be able to ignore them > just fine. I don't see how "nano-PI" would be any different, the routing > community won't have any difficulty ignoring those either. After all, a > router couldn't care less if a route is from an inetnum with status > "ASSIGNED PA" or "ASSIGNED PI". > > Or to put it another way, we don't need policy to forbid every bad idea > under the sun. Let the routing community decide how they want to deal > with this one. > > Tore > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Mar 25 09:07:00 2014 From: gert at space.net (Gert Doering) Date: Tue, 25 Mar 2014 09:07:00 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <5330F404.3090701@fud.no> Message-ID: <20140325080700.GJ43641@Space.Net> Hi, On Tue, Mar 25, 2014 at 08:56:35AM +0100, Turchanyi Geza wrote: > While I fully understand the attitude of the routing community, I would > encourage people raise their voices against bad policy making. "light policy that does not try to solve problems other people are fully qualified to handle themselves" is not "bad policy making". 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 elvis at velea.eu Tue Mar 25 09:27:54 2014 From: elvis at velea.eu (Elvis Velea) Date: Tue, 25 Mar 2014 10:27:54 +0200 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Message-ID: <53313E0A.2050200@velea.eu> Hi Erik, I, personally, would put the /24 limit in policy. Anything lower than a /24 can no longer be split by the RIPE NCC and must be transferred in one block. cheers, elvis On 24/03/14 23:44, Erik Bais wrote: > > Hi, > > As you might know, we are currently working on a policy proposal to > allow the transfer of PI space. > > One of the topics that I would like some input (prior to sending out > the proposal itself) it the following: > > In the current draft, I've phrased one of the 'rules' for the PI > transfer as follows: > > -Assignments smaller than the minimal allocation size, can't be split > into smaller assignments, but can be re-assigned as a complete > assignment. > > My reasoning is that it would disallow cutting up small assignments > into even smaller assignments. > > So in the current situation a /23 PI assignment is smaller than the > minimal allocation size, however assigned in the past by the RIPE NCC. > > With the above stated 'rule' in the proposal, it would not be allowed > to split up a PI assignment into 2 PI assignments of a /24 .. or 4 PI > assignments of a /25, but it would be allowed to do a complete > re-assignments as a /23. > > With the current new proposal 2014-1 put forward today, the question > that we discussed last week (myself, Marco and Andrea ) is that if we > would put this forward, that this might need to be re-phrased. > > The question that I have is, would the community prefer a transfer > policy proposal for PI with or without the above stated rule or > limitation in freedom in transfers of PI. > > The goal of the PI transfer policy proposal is to have it similar as > the current Transfer policy for PA space. > > Let's hear it. > > > Regards > > Erik Bais > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue Mar 25 09:57:34 2014 From: gert at space.net (Gert Doering) Date: Tue, 25 Mar 2014 09:57:34 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <53313E0A.2050200@velea.eu> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> Message-ID: <20140325085734.GM43641@Space.Net> Hi, On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote: > I, personally, would put the /24 limit in policy. Anything lower than a > /24 can no longer be split by the RIPE NCC and must be transferred in > one block. Why? 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 job at instituut.net Tue Mar 25 09:56:28 2014 From: job at instituut.net (Job Snijders) Date: Tue, 25 Mar 2014 09:56:28 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <53313E0A.2050200@velea.eu> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> Message-ID: <20140325085628.GB4468@Eleanor.local> On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote: > Hi Erik, > > I, personally, would put the /24 limit in policy. Anything lower than a /24 > can no longer be split by the RIPE NCC and must be transferred in one block. That seems like an arbitrairy limit. What is so magic about /24? I can think of a few use-cases where globally unique ip space (and proper registration in a database) are useful, but global routability is not expected. Kind regards, Job From tore at fud.no Tue Mar 25 12:22:48 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 25 Mar 2014 12:22:48 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <5330F404.3090701@fud.no> Message-ID: <53316708.2000604@fud.no> * Turchanyi Geza > May I interpret your words this way: Policy making and routing are two > very separated, distinct actions?! Not as a general statement, although in this specific case I suppose you could say that - the prefix length threshold of what's considered routable globally or not simply isn't going to be decided by the RIPE Address Policy Working Group, even if we pretend to make decision... We could make a policy that demanded ?every network operator in the RIPE region MUST accept all routes up to and including /32s from all of their peers and upstreams?. Or we could make a policy that stated ?every network operator in the RIPE region MUST reject all routes with prefix lengths longer than or equal to the minimum allocation size of /22?. Neither would have any effect out in the real world; the operators would continue to decide for themselves what they are willing to accept, just as they do today. We might as well try to outlaw the moon. That said, there are cases where a policy mandated minimum allocation size makes perfect sense and have a positive impact on routing. This is most apparent in IPv6, where every LIR is basically forced to accept a absolutely ridiculous amount of addresses no matter their actual perceived need. This prevents LIRs from underestimating their need (easy if you're used to IPv4), asking for too small blocks, and as a result having to return to the NCC for new and distinct allocations a few years down the line. The same was true for IPv4 allocations too before run-out, but to a lesser extent. > While I fully understand the attitude of the routing community, I would > encourage people raise their voices against bad policy making. ?If it ain't broken, don't fix it? We don't currently have a minimum assignment size in policy (neither for PI or PA), nor do we have a minimum size of route objects. It's not broken. We don't need to fix it. Tore From elvis at velea.eu Tue Mar 25 13:17:26 2014 From: elvis at velea.eu (Elvis Velea) Date: Tue, 25 Mar 2014 14:17:26 +0200 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <20140325085734.GM43641@Space.Net> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> Message-ID: <533173D6.8060002@velea.eu> Hi, On 25/03/14 10:57, Gert Doering wrote: > Hi, > > On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote: >> I, personally, would put the /24 limit in policy. Anything lower than a >> /24 can no longer be split by the RIPE NCC and must be transferred in >> one block. > Why? First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit for Inter-RIR transfers and I do hope that our region will eventually have an Inter-RIR transfer policy compatible with theirs .. so, for consistency with the others. Secondly, because most of the routing is done by filtering at the /24 level and even though not all the IPv4 space is used on the internet and publicly advertised, it seems to be the limit already adopted by most of the ISPs. Thirdly, setting up reverse dns for blocks lower than /24 requires that any minor changes for reverse dns would need to involve the RIPE NCC. Lastly, allowing any level of fragmentation could lead to an exploding IPv4 routing table (now at almost 500k routes). I'm not saying that adding an (arbitrary) transfer limit like the /24 would stop the routing table growth. There might be other reasons as well.. It's just a feeling that limiting at /24 is the right thing to do. On the other hand, while writing this e-mail I've been having second thoughts on each of the paragraphs and reasons :-) cheers, elvis From tore at fud.no Tue Mar 25 14:23:22 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 25 Mar 2014 14:23:22 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <533173D6.8060002@velea.eu> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> <533173D6.8060002@velea.eu> Message-ID: <5331834A.5070704@fud.no> * Elvis Velea > First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit > for Inter-RIR transfers and I do hope that our region will eventually > have an Inter-RIR transfer policy compatible with theirs .. so, for > consistency with the others. The Inter-RIR transfer policy to be could simply say that if the other RIR has a minimum size limitation (or any other limitation really), then that limitation applies for transfers to/from that RIR, could it not? Seems to me that the fewer rules and restrictions we put in place in our end, the smaller the risk of any irreconcilable incompatibilities with other the other RIRs' policies. > Secondly, because most of the routing is done by filtering at the /24 > level and even though not all the IPv4 space is used on the internet and > publicly advertised, it seems to be the limit already adopted by most of > the ISPs. That is happening completely independent of RIPE address policy today and the practice will in all likelihood continue tomorrow too, regardless of what policy we might pass. > Thirdly, setting up reverse dns for blocks lower than /24 requires that > any minor changes for reverse dns would need to involve the RIPE NCC. The same is true for assignments smaller than /24 today, which already exist; we didn't have a minimum PI assignment size, so the NCC has issued quite a few >=/25s already. If those >=/25 PI assignments issued by the NCC aren't a problem today, I don't see why transferred >=/25 PI assignments should be one tomorrow. > Lastly, allowing any level of fragmentation could lead to an exploding > IPv4 routing table (now at almost 500k routes). I'm not saying that > adding an (arbitrary) transfer limit like the /24 would stop the routing > table growth. See my response to your ?secondly?... Also I think that concerns over an ?exploding? routing table are unfounded in reality. I mean we've only had 233 transfers _in total_ so far, and that's only of blocks that the recipient could reasonably expect to route on the internet. How many people are we seriously expecting to want to transfer these mostly useless >=/25 PI assignments to themselves? Anyone at all? I seriously doubt that those weirdos are numerous enough to worry about in the the slightest... Tore From tore at fud.no Tue Mar 25 14:25:36 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 25 Mar 2014 14:25:36 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <5331834A.5070704@fud.no> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> <533173D6.8060002@velea.eu> <5331834A.5070704@fud.no> Message-ID: <533183D0.2080401@fud.no> * Tore Anderson > we've only had 233 transfers _in total_ so far Correction: 265 Cut'n'paste mistake, apologies. Tore From gert at space.net Tue Mar 25 14:26:39 2014 From: gert at space.net (Gert Doering) Date: Tue, 25 Mar 2014 14:26:39 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <533173D6.8060002@velea.eu> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> <533173D6.8060002@velea.eu> Message-ID: <20140325132639.GV43641@Space.Net> Hi, On Tue, Mar 25, 2014 at 02:17:26PM +0200, Elvis Velea wrote: > On 25/03/14 10:57, Gert Doering wrote: > > On Tue, Mar 25, 2014 at 10:27:54AM +0200, Elvis Velea wrote: > >> I, personally, would put the /24 limit in policy. Anything lower than a > >> /24 can no longer be split by the RIPE NCC and must be transferred in > >> one block. > > Why? > First of all, because the other RIRs (APNIC&ARIN) also have a /24 limit > for Inter-RIR transfers and I do hope that our region will eventually > have an Inter-RIR transfer policy compatible with theirs .. so, for > consistency with the others. I don't see this as particularily desirable, follow the other regions "because they do it this way". Look there, learn from them, but make our own decisions. > Secondly, because most of the routing is done by filtering at the /24 > level and even though not all the IPv4 space is used on the internet and > publicly advertised, it seems to be the limit already adopted by most of > the ISPs. So this should limit the amount of what people *want* to transfer automatically, without putting it into the policy, no? It's commonly known that announcing a /25 won't work, so why would you transfer one, if not "for internal use"? > Thirdly, setting up reverse dns for blocks lower than /24 requires that > any minor changes for reverse dns would need to involve the RIPE NCC. That's indeed quite a strong argument for not *wanting* to transfer anything smaller, but would it need to go into the policy document? (My personal feeling is "nobody would want to transfer smaller blocks anyway, so we don't need to codify it", but it certainly needs to be discussed and agreed-upon...) > Lastly, allowing any level of fragmentation could lead to an exploding > IPv4 routing table (now at almost 500k routes). I'm not saying that > adding an (arbitrary) transfer limit like the /24 would stop the routing > table growth. It wouldn't... there's about 16 million /24s out there, so even limiting at /24 won't stop the explosion if people really start announcing everything up to the limit... > There might be other reasons as well.. It's just a feeling that limiting > at /24 is the right thing to do. On the other hand, while writing this > e-mail I've been having second thoughts on each of the paragraphs and > reasons :-) It's good to have the arguments out, so we can think through them - thanks! Gert Doering -- no hats -- 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 mschmidt at ripe.net Tue Mar 25 15:36:47 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 25 Mar 2014 15:36:47 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <533173D6.8060002@velea.eu> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> <533173D6.8060002@velea.eu> Message-ID: <5331947F.9000102@ripe.net> Dear Elvis, all, On 25/03/14 13:17, Elvis Velea wrote: > Thirdly, setting up reverse dns for blocks lower than /24 requires > that any minor changes for reverse dns would need to involve the RIPE > NCC. We would just like to offer a little clarification regarding this point: Since December 2010, the RIPE NCC is no longer involved in reverse DNS of blocks smaller than a /24. Our Global Information Infrastructure (GII) department confirms that this is now handled automatically for RIPE Database users. Details on how to set up reverse delegation can be found here: http://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-delegation Kind regards, Marco Schmidt Policy Development Officer RIPE NCC From Piotr.Strzyzewski at polsl.pl Tue Mar 25 15:40:20 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Tue, 25 Mar 2014 15:40:20 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> Message-ID: <20140325144020.GK19555@hydra.ck.polsl.pl> On Mon, Mar 24, 2014 at 10:44:21PM +0100, Erik Bais wrote: Dear Erik > In the current draft, I?ve phrased one of the ?rules? for the PI transfer as > follows: > > > - Assignments smaller than the minimal allocation size, can?t be > split into smaller assignments, but can be re-assigned as a complete > assignment. [cut] > The question that I have is, would the community prefer a transfer policy > proposal for PI with or without the above stated rule or limitation in > freedom in transfers of PI. I would prefer not to have this put into policy text. I don't think we have any effective tools to enforce it. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From sander at steffann.nl Tue Mar 25 16:16:54 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 25 Mar 2014 16:16:54 +0100 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <5331947F.9000102@ripe.net> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> <533173D6.8060002@velea.eu> <5331947F.9000102@ripe.net> Message-ID: <43C74BF3-1C22-47A7-A30B-4A00C9798447@steffann.nl> Hi Marco, > Since December 2010, the RIPE NCC is no longer involved in reverse DNS of blocks smaller than a /24. This wording can be a bit misleading. I suspect you mean 'Since December 2010, the RIPE NCC does not have to perform any manual actions to provide reverse DNS of blocks smaller than a /24 as this is now fully automated.' I hope I understood you correctly :) Sander From nigel at titley.com Tue Mar 25 18:25:24 2014 From: nigel at titley.com (Nigel Titley) Date: Tue, 25 Mar 2014 17:25:24 +0000 Subject: [address-policy-wg] A question Message-ID: <5331BC04.1020401@titley.com> Anyone care to cast an opinion on the following question: The company I work for is about to split off one of its country operations into a separate company. There are various blocks in use from various allocations to the parent company. Is it permissible to split a PA block and transfer part of it to the new company in order to avoid having to renumber the customers? My reading of the transfer policy is that it is possible (if reprehensible), but I thought I'd just like to check with the great and the good to see what opinion is. Nigel From elvis at velea.eu Tue Mar 25 18:35:27 2014 From: elvis at velea.eu (Elvis Velea) Date: Tue, 25 Mar 2014 19:35:27 +0200 Subject: [address-policy-wg] Input request for the PI Transfer policy In-Reply-To: <20140325132639.GV43641@Space.Net> References: <00a701cf47aa$403dad30$c0b90790$@a2b-internet.com> <53313E0A.2050200@velea.eu> <20140325085734.GM43641@Space.Net> <533173D6.8060002@velea.eu> <20140325132639.GV43641@Space.Net> Message-ID: <5331BE5F.8020108@velea.eu> Hi Gert, On 25/03/14 15:26, Gert Doering wrote: [...] > There might be other reasons as well.. It's just a feeling that limiting > at /24 is the right thing to do. On the other hand, while writing this > e-mail I've been having second thoughts on each of the paragraphs and > reasons :-) > It's good to have the arguments out, so we can think through them - thanks! I tried to play the devil's advocate role this time. As said, even when writing all my con's I realized these aren't too strong. As you already know, I'm in favor of not adding any limitations in policy. I was just trying to voice all the possible con's. > > Gert Doering > -- no hats cheers, elvis -- blue hat to protect against the sun :-) From elvis at v4escrow.net Tue Mar 25 19:52:21 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 25 Mar 2014 20:52:21 +0200 Subject: [address-policy-wg] A question In-Reply-To: <5331BC04.1020401@titley.com> References: <5331BC04.1020401@titley.com> Message-ID: <5331D065.5040402@v4escrow.net> Hi Nigel, As far as I understand from the policy, you can transfer a block that contains customer assignments. The size of the block that you would transfer can not be (currently) smaller than a /22. So, I would say that you have two options: - first - where you use the transfer policy and transfer parts of an allocation to an other LIR (even if it's yours, in a different country). In this case, the IPs transferred can not be again transferred for two years to an other LIR. - second - where you sell to a separate company (parts of) your infrastructure (and maybe associated customers) and then you would use the Mergers and Acquisitions procedure. In this case, the transfer policy would not be used and the IPs transferred to the new company could then be again transferred using the transfer policy. cheers, elvis On 25/03/14 19:25, Nigel Titley wrote: > Anyone care to cast an opinion on the following question: > > The company I work for is about to split off one of its country > operations into a separate company. There are various blocks in use from > various allocations to the parent company. Is it permissible to split a > PA block and transfer part of it to the new company in order to avoid > having to renumber the customers? My reading of the transfer policy is > that it is possible (if reprehensible), but I thought I'd just like to > check with the great and the good to see what opinion is. > > Nigel > > -- 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 Woeber at CC.UniVie.ac.at Wed Mar 26 05:14:16 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 26 Mar 2014 12:14:16 +0800 Subject: [address-policy-wg] A question In-Reply-To: <5331D065.5040402@v4escrow.net> References: <5331BC04.1020401@titley.com> <5331D065.5040402@v4escrow.net> Message-ID: <53325418.2070302@CC.UniVie.ac.at> ...and, depending on what the distribution of customer assignments across the overall address space looks like, you may be able to use the suballocation mechanism. Admittedly, I have never used that or did any in-depth analysis of the possibilities. Just a hint to maybe also look at. I may be fully off-track, too. Regards, Wilfried. Elvis Daniel Velea wrote: > > Hi Nigel, > > As far as I understand from the policy, you can transfer a block that > contains customer assignments. The size of the block that you would > transfer can not be (currently) smaller than a /22. > > So, I would say that you have two options: > - first - where you use the transfer policy and transfer parts of an > allocation to an other LIR (even if it's yours, in a different country). > In this case, the IPs transferred can not be again transferred for two > years to an other LIR. > - second - where you sell to a separate company (parts of) your > infrastructure (and maybe associated customers) and then you would use > the Mergers and Acquisitions procedure. In this case, the transfer > policy would not be used and the IPs transferred to the new company > could then be again transferred using the transfer policy. > > cheers, > elvis > > On 25/03/14 19:25, Nigel Titley wrote: > >>Anyone care to cast an opinion on the following question: >> >>The company I work for is about to split off one of its country >>operations into a separate company. There are various blocks in use from >>various allocations to the parent company. Is it permissible to split a >>PA block and transfer part of it to the new company in order to avoid >>having to renumber the customers? My reading of the transfer policy is >>that it is possible (if reprehensible), but I thought I'd just like to >>check with the great and the good to see what opinion is. >> >>Nigel >> >> >> > > > -- > > > > 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. > From h.lu at anytimechinese.com Wed Mar 26 07:07:52 2014 From: h.lu at anytimechinese.com (Lu Heng) Date: Wed, 26 Mar 2014 14:07:52 +0800 Subject: [address-policy-wg] address-policy-wg Digest, Vol 31, Issue 15 In-Reply-To: References: Message-ID: Hi Nigel: My suggestion was keep block in one piece and lease the block to the local companies(if legal requires). because put it back in one piece later on might be a problem and if there is no real transaction involved, less specific block are always better than smaller block for routing reasons. my two cents. On Wed, Mar 26, 2014 at 2:52 AM, wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. A question (Nigel Titley) > 2. Re: Input request for the PI Transfer policy (Elvis Velea) > 3. Re: A question (Elvis Daniel Velea) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Mar 2014 17:25:24 +0000 > From: Nigel Titley > Subject: [address-policy-wg] A question > To: address-policy-wg at ripe.net > Message-ID: <5331BC04.1020401 at titley.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Anyone care to cast an opinion on the following question: > > The company I work for is about to split off one of its country > operations into a separate company. There are various blocks in use from > various allocations to the parent company. Is it permissible to split a > PA block and transfer part of it to the new company in order to avoid > having to renumber the customers? My reading of the transfer policy is > that it is possible (if reprehensible), but I thought I'd just like to > check with the great and the good to see what opinion is. > > Nigel > > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 Mar 2014 19:35:27 +0200 > From: Elvis Velea > Subject: Re: [address-policy-wg] Input request for the PI Transfer > policy > To: Gert Doering > Cc: address-policy-wg at ripe.net > Message-ID: <5331BE5F.8020108 at velea.eu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Gert, > > > On 25/03/14 15:26, Gert Doering wrote: > > [...] >> There might be other reasons as well.. It's just a feeling that limiting >> at /24 is the right thing to do. On the other hand, while writing this >> e-mail I've been having second thoughts on each of the paragraphs and >> reasons :-) >> It's good to have the arguments out, so we can think through them - thanks! > I tried to play the devil's advocate role this time. As said, even when > writing all my con's I realized these aren't too strong. > > As you already know, I'm in favor of not adding any limitations in > policy. I was just trying to voice all the possible con's. > >> >> Gert Doering >> -- no hats > cheers, > elvis > -- blue hat to protect against the sun :-) > > > > > ------------------------------ > > Message: 3 > Date: Tue, 25 Mar 2014 20:52:21 +0200 > From: Elvis Daniel Velea > Subject: Re: [address-policy-wg] A question > To: address-policy-wg at ripe.net > Message-ID: <5331D065.5040402 at v4escrow.net> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nigel, > > As far as I understand from the policy, you can transfer a block that > contains customer assignments. The size of the block that you would > transfer can not be (currently) smaller than a /22. > > So, I would say that you have two options: > - first - where you use the transfer policy and transfer parts of an > allocation to an other LIR (even if it's yours, in a different country). > In this case, the IPs transferred can not be again transferred for two > years to an other LIR. > - second - where you sell to a separate company (parts of) your > infrastructure (and maybe associated customers) and then you would use > the Mergers and Acquisitions procedure. In this case, the transfer > policy would not be used and the IPs transferred to the new company > could then be again transferred using the transfer policy. > > cheers, > elvis > > On 25/03/14 19:25, Nigel Titley wrote: >> Anyone care to cast an opinion on the following question: >> >> The company I work for is about to split off one of its country >> operations into a separate company. There are various blocks in use from >> various allocations to the parent company. Is it permissible to split a >> PA block and transfer part of it to the new company in order to avoid >> having to renumber the customers? My reading of the transfer policy is >> that it is possible (if reprehensible), but I thought I'd just like to >> check with the great and the good to see what opinion is. >> >> Nigel >> >> > > > -- > > > > 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: https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20140325/9e229147/attachment.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: logo.png > Type: image/png > Size: 5043 bytes > Desc: not available > Url : https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20140325/9e229147/attachment.png > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: 1.png > Type: image/png > Size: 11971 bytes > Desc: not available > Url : https://www.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20140325/9e229147/attachment-0001.png > > End of address-policy-wg Digest, Vol 31, Issue 15 > ************************************************* -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From tore at fud.no Wed Mar 26 08:22:33 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 26 Mar 2014 08:22:33 +0100 Subject: [address-policy-wg] A question In-Reply-To: <53325418.2070302@CC.UniVie.ac.at> References: <5331BC04.1020401@titley.com> <5331D065.5040402@v4escrow.net> <53325418.2070302@CC.UniVie.ac.at> Message-ID: <53328039.8060608@fud.no> * Wilfried Woeber > ...and, depending on what the distribution of customer assignments > across the overall address space looks like, you may be able to use > the suballocation mechanism. > > Admittedly, I have never used that or did any in-depth analysis of > the possibilities. Just a hint to maybe also look at. I may be fully > off-track, too. I think both you and Elvis are spot-on. There are even more options than the three already mentioned... 4) If the assignments in question are made to the new spun off company's own infrastructure (which may include separate end-users or customers if they're single-address such as the DHCP pool of a broadband ISP, cf. ripe-606 section 6.2), then the old company/LIR may simply delegate the blocks to the new company by registering completely standard ASSIGNED PA inetnums. In this case there are no minimum size limits to worry about (sub-allocations are limited at /24, transfers at /22 as Elvis noted). 5) In the case that #4 doesn't work because the customers of the new company have specific (non-pooled) assignments, the new company could simply contract the old company to provide the registry services directly for them. In other words that the old company will continue to maintain the assignments in the database for each individual (non-pooled) customer of the new company. This option would obviously require a tight working relationship between the new and old companies, as every time the new company lands a new customer, they the old company must register the associated assignment. Those two options, as well as the sub-allocation option, have the added benefit that they're cheaper for the new company, as it doesn't have to become an LIR on its own and pay the NCC membership fee. In any case, Nigel's problem statement is very similar to the one presented by Sascha Pollok in Athens as the rationale for 2013-05: https://ripe67.ripe.net/archives/video/32/ http://www.ripe.net/ripe/policies/proposals/2013-05 Considering that 2013-05 blitzed through the PDP with hardly any opposition, I'd say that Nigel's worry that moving around the addresses in the manner described is considered "reprehensible" is completely unfounded; "totally OK" would be more accurate, I think. Tore From elvis at v4escrow.net Wed Mar 26 08:57:53 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 26 Mar 2014 09:57:53 +0200 Subject: [address-policy-wg] A question In-Reply-To: <53328039.8060608@fud.no> References: <5331BC04.1020401@titley.com> <5331D065.5040402@v4escrow.net> <53325418.2070302@CC.UniVie.ac.at> <53328039.8060608@fud.no> Message-ID: <53328881.4050308@v4escrow.net> ... and there's always the LIR-PARTITIONED option which almost nobody uses. btw, regarding the two options I presented earlier, If you do not have any intention in further transferring the space within two years, I would recommend using the transfer procedure. I recommend using the transfer policy because the RIPE NCC has updated their process for mergers and acquisitions and it's now (from my experience) painfully long and difficult (if you do not fit perfectly in their script). cheers, elvis On 26/03/14 09:22, Tore Anderson wrote: > * Wilfried Woeber > >> ...and, depending on what the distribution of customer assignments >> across the overall address space looks like, you may be able to use >> the suballocation mechanism. >> >> Admittedly, I have never used that or did any in-depth analysis of >> the possibilities. Just a hint to maybe also look at. I may be fully >> off-track, too. > I think both you and Elvis are spot-on. > > There are even more options than the three already mentioned... > > 4) If the assignments in question are made to the new spun off company's > own infrastructure (which may include separate end-users or customers if > they're single-address such as the DHCP pool of a broadband ISP, cf. > ripe-606 section 6.2), then the old company/LIR may simply delegate the > blocks to the new company by registering completely standard ASSIGNED PA > inetnums. In this case there are no minimum size limits to worry about > (sub-allocations are limited at /24, transfers at /22 as Elvis noted). > > 5) In the case that #4 doesn't work because the customers of the new > company have specific (non-pooled) assignments, the new company could > simply contract the old company to provide the registry services > directly for them. In other words that the old company will continue to > maintain the assignments in the database for each individual > (non-pooled) customer of the new company. This option would obviously > require a tight working relationship between the new and old companies, > as every time the new company lands a new customer, they the old company > must register the associated assignment. > > Those two options, as well as the sub-allocation option, have the added > benefit that they're cheaper for the new company, as it doesn't have to > become an LIR on its own and pay the NCC membership fee. > > In any case, Nigel's problem statement is very similar to the one > presented by Sascha Pollok in Athens as the rationale for 2013-05: > > https://ripe67.ripe.net/archives/video/32/ > http://www.ripe.net/ripe/policies/proposals/2013-05 > > Considering that 2013-05 blitzed through the PDP with hardly any > opposition, I'd say that Nigel's worry that moving around the addresses > in the manner described is considered "reprehensible" is completely > unfounded; "totally OK" would be more accurate, I think. > > Tore > -- 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 ripe-wgs.cs at schiefner.de Thu Mar 27 07:52:47 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 27 Mar 2014 07:52:47 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53307B8A.3010403@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> Message-ID: <5333CABF.1070609@schiefner.de> Rob, Tore, all - first of all, my apologies for a delayed response; I am currently attending the ICANN 49 meeting in Singapore which sucks up quite a bit of my attention span. ;-) On 24.03.2014 19:38, Tore Anderson wrote: > * Rob Evans >> but I wonder if there is a reason for leaving 5.4 (minimum >> sub-allocation size) as-is? >> >> If we open the door to transfer prefixes smaller than a /24, should >> sub-allocation of them be prevented? > > I think not, that would not be consistent. Maybe it's just an oversight > by the proposal's author to not have removed that particular paragraph? No, not really. I feel this being only loosely coupled at best. My proposal enables the transfer of allocations of *all* sizes and the conversion of PI assignments of *all* sizes into allocations. Whether sub-allocations can be made from *all* these (new) allocations or "just" from those being at least a /24 appears as a separate question to me. Even more so, as the the sub-allocation mechanism has been applied or used very rarely only so far. And having the "one thing at a time" principle in mind: if this impossibility is of concern to the community, then this should maybe be handled by a separate policy (modification) proposal. Best, -C. From ripe-wgs.cs at schiefner.de Thu Mar 27 08:34:36 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 27 Mar 2014 08:34:36 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333CABF.1070609@schiefner.de> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> Message-ID: <5333D48C.6010401@schiefner.de> On 27.03.2014 07:52, Carsten Schiefner wrote: > Whether sub-allocations can be made from *all* these (new) allocations > or "just" from those being at least a /24 appears as a separate question > to me. Even more so, as the the sub-allocation mechanism has been > applied or used very rarely only so far. "... according to figures I have received from the RIPE NCC wrt. this." I should have added here. Best, -C. From tore at fud.no Thu Mar 27 09:34:20 2014 From: tore at fud.no (Tore Anderson) Date: Thu, 27 Mar 2014 09:34:20 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333CABF.1070609@schiefner.de> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> Message-ID: <5333E28C.6030906@fud.no> * Carsten Schiefner > No, not really. I feel this being only loosely coupled at best. My > proposal enables the transfer of allocations of *all* sizes and the > conversion of PI assignments of *all* sizes into allocations. > > Whether sub-allocations can be made from *all* these (new) > allocations or "just" from those being at least a /24 appears as a > separate question to me. Even more so, as the the sub-allocation > mechanism has been applied or used very rarely only so far. > > And having the "one thing at a time" principle in mind: if this > impossibility is of concern to the community, then this should maybe > be handled by a separate policy (modification) proposal. Hi Carsten, 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?). So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome). Just my ?.02...your proposal, your call. ;) Tore From elvis at v4escrow.net Thu Mar 27 09:36:58 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 27 Mar 2014 10:36:58 +0200 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333E28C.6030906@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> Message-ID: <5333E32A.4060709@v4escrow.net> On 27/03/14 10:34, Tore Anderson wrote: > * Carsten Schiefner > >> No, not really. I feel this being only loosely coupled at best. My >> proposal enables the transfer of allocations of *all* sizes and the >> conversion of PI assignments of *all* sizes into allocations. >> >> Whether sub-allocations can be made from *all* these (new) >> allocations or "just" from those being at least a /24 appears as a >> separate question to me. Even more so, as the the sub-allocation >> mechanism has been applied or used very rarely only so far. >> >> And having the "one thing at a time" principle in mind: if this >> impossibility is of concern to the community, then this should maybe >> be handled by a separate policy (modification) proposal. > Hi Carsten, > > 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. > > +1 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 ripe-wgs.cs at schiefner.de Thu Mar 27 10:07:53 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 27 Mar 2014 10:07:53 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333E28C.6030906@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> Message-ID: <5333EA69.7020403@schiefner.de> Hi Tore, all - 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. ;-) > So I'd ask you to consider removing that paragraph as well before going > to review phase. Note that since we're still in the discussion phase, > doing so doesn't have to slow down the progress of the proposal, you can > go straight to review with updated proposal (modifications at a later > stage are much more cumbersome). True - although it doesn't seem to be me moving it straight to the review phase, but the WG (Co-)Chair(s) - i.e. Gert and/or Sander. Cheers, -C. From jkennedy at libertyglobal.com Thu Mar 27 10:53:10 2014 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Thu, 27 Mar 2014 09:53:10 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333E28C.6030906@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> Message-ID: <13E63C78A6256E4A857726374FBF926E11D0E76F@NLAMSPEXMB003.upcit.ds.upc.biz> > 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?). +1 If we're removing the min allocation size parameter it would be inconsistent to have a limitation on sub-allocation. I doubt there'd be many uses for a sub-allocation smaller than /24, but as Tore outlined there doesn't seem much benefit of having this constraint. We should aim towards less arbitrary restrictions in policy. Rgds, James -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: 27 March 2014 09:34 To: Carsten Schiefner; Rob Evans Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) * Carsten Schiefner > No, not really. I feel this being only loosely coupled at best. My > proposal enables the transfer of allocations of *all* sizes and the > conversion of PI assignments of *all* sizes into allocations. > > Whether sub-allocations can be made from *all* these (new) allocations > or "just" from those being at least a /24 appears as a separate > question to me. Even more so, as the the sub-allocation mechanism has > been applied or used very rarely only so far. > > And having the "one thing at a time" principle in mind: if this > impossibility is of concern to the community, then this should maybe > be handled by a separate policy (modification) proposal. Hi Carsten, 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?). So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome). Just my ?.02...your proposal, your call. ;) Tore From gert at space.net Thu Mar 27 10:56:12 2014 From: gert at space.net (Gert Doering) Date: Thu, 27 Mar 2014 10:56:12 +0100 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: <20140327095612.GN43641@Space.Net> Hi, On Thu, Mar 27, 2014 at 10:07:53AM +0100, Carsten Schiefner wrote: > True - although it doesn't seem to be me moving it straight to the > review phase, but the WG (Co-)Chair(s) - i.e. Gert and/or Sander. Well, at the end of discussion phase, you, sander and me conspire to decide what to do next - "more discussion", "go forward as is" or "change text and go forward". You're the proposer, so you have a say in this ;-) 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 jkennedy at libertyglobal.com Thu Mar 27 10:10:10 2014 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Thu, 27 Mar 2014 09:10:10 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333E28C.6030906@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> Message-ID: <13E63C78A6256E4A857726374FBF926E11D0E6AF@NLAMSPEXMB003.upcit.ds.upc.biz> > 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?). +1 If we're removing the min allocation size parameter it would be inconsistent to have a limitation on sub-allocation. I doubt there'd be many uses for a sub-allocation smaller than /24, but as Tore outline there doesn't seem much benefit of having this constraint. We should aim towards less arbitrary restrictions in policy. Rgds, James -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Tore Anderson Sent: 27 March 2014 09:34 To: Carsten Schiefner; Rob Evans Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) * Carsten Schiefner > No, not really. I feel this being only loosely coupled at best. My > proposal enables the transfer of allocations of *all* sizes and the > conversion of PI assignments of *all* sizes into allocations. > > Whether sub-allocations can be made from *all* these (new) allocations > or "just" from those being at least a /24 appears as a separate > question to me. Even more so, as the the sub-allocation mechanism has > been applied or used very rarely only so far. > > And having the "one thing at a time" principle in mind: if this > impossibility is of concern to the community, then this should maybe > be handled by a separate policy (modification) proposal. Hi Carsten, 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?). So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome). Just my ?.02...your proposal, your call. ;) Tore From zsako at iszt.hu Thu Mar 27 14:56:52 2014 From: zsako at iszt.hu (Janos Zsako) Date: Thu, 27 Mar 2014 14:56:52 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5333E28C.6030906@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> Message-ID: <53342E24.7000702@iszt.hu> Dear all, > 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 Well, technically speaking this is obviously feasible. However, as I pointed it out on the DSN WG mailing list, in case of transfers, where the "buyer" normally does not wish to have any further business relationship with the "seller" once the transfer is completed, this solution may be unattractive. The fact that the "seller" has to provide appropriate DNS services (i.e. in accordance with BCP20/RFC2317) to the "buyer" for an _indefinite_ period of time, is probably one more deterrent to transferring such a small amount of addresses. As the remark above was related to sub-allocations (not yet covered by the proposed policy), I feel the obligation to provide appropriate DNS service is less of a problem, as the sub-allocating LIR will have a tight relationship with the other LIR, since the former will remain responsible for the address space anyway. > 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?). Indeed, the two stated reasons for needing a minimum sub-allocation size are not convincing at all. At the same time, I agree with Carsten that this issue is orthogonal to the minimum allocation problem: we could simply drop the minimum sub-allocation size requirement without affecting the minimum allocation size in any way. Also, dropping the minimum allocation size requirement does not necessarily imply that we have to ignore the minimum sub-allocation size. BTW: dropping the minimum allocation size for NCC allocations is in a way already approved in case of free address pool exhaustion (see last paragraph of 5.1: "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."). > So I'd ask you to consider removing that paragraph as well before going > to review phase. Note that since we're still in the discussion phase, > doing so doesn't have to slow down the progress of the proposal, you can > go straight to review with updated proposal (modifications at a later > stage are much more cumbersome). I think this is a sensible approach. As far as the 2014-01 policy is concerned, as I pointed out above, its first part (5.1) is already approved: if we remove that sentence, this has an influence only on the transfers (part 2 of the proposal, 5.5 of ripe-606). I think the main argument against allowing transfers smaller than /22 is most probably the fear from fragmentation and routing table explosion. This does not affect certification significantly (not more than it affects routing), as the number of Subscribers will not increase (the receiving party - or "buyer" as I called them above - has to be an LIR already), just the number of allocations signed. The main argument in favour of dropping this barrier in my view is that probably such transfers will happen anyway and it would be good to be able to keep the registry records accurate. Therefore, I support this proposal (with or without involving the minimum sub-allocation size as well). Best regards, Janos > Just my ?.02...your proposal, your call. ;) > > Tore > > From tore at fud.no Thu Mar 27 20:26:29 2014 From: tore at fud.no (Tore Anderson) Date: Thu, 27 Mar 2014 20:26:29 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53342E24.7000702@iszt.hu> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> Message-ID: <53347B65.5010606@fud.no> Hi Janos, >> 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 > > Well, technically speaking this is obviously feasible. However, as I > pointed it out on the DSN WG mailing list, in case of transfers, > where the "buyer" normally does not wish to have any further > business relationship with the "seller" once the transfer is > completed, this solution may be unattractive. The fact that the > "seller" has to provide appropriate DNS services (i.e. in accordance > with BCP20/RFC2317) to the "buyer" for an _indefinite_ period of > time, is probably one more deterrent to transferring such a small > amount of addresses. I think it would be reasonable to expect that if 2014-01 passes, the NCC will respond by allowing direct classless delegation of PA blocks, just like is already done for PI. If so, what you're describing here shouldn't be a problem. Tore From poty at iiat.ru Fri Mar 28 09:33:00 2014 From: poty at iiat.ru (poty at iiat.ru) Date: Fri, 28 Mar 2014 12:33:00 +0400 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Message-ID: <07824FF8A4954B438144406BC0D91D031B0D32@CMAIL.office.iiat> Hello, There would be always the difference between PI distribution and PA. As pointed by Janos - there is always contractual relationship between a PI user and a LIR or RIR, who covers some "side" mechanic. In case of PA it is more like selling - after an address block transfer the only responsible party is the new "owner". Regards, Vladislav >> 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 > > Well, technically speaking this is obviously feasible. However, as I > pointed it out on the DSN WG mailing list, in case of transfers, where > the "buyer" normally does not wish to have any further business > relationship with the "seller" once the transfer is completed, this > solution may be unattractive. The fact that the "seller" has to > provide appropriate DNS services (i.e. in accordance with > BCP20/RFC2317) to the "buyer" for an _indefinite_ period of time, is > probably one more deterrent to transferring such a small amount of > addresses. I think it would be reasonable to expect that if 2014-01 passes, the NCC will respond by allowing direct classless delegation of PA blocks, just like is already done for PI. If so, what you're describing here shouldn't be a problem. Tore From zsako at iszt.hu Fri Mar 28 11:08:41 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 28 Mar 2014 11:08:41 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53347B65.5010606@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> Message-ID: <53354A29.2070002@iszt.hu> Dear Tore, >> Well, technically speaking this is obviously feasible. However, as I >> pointed it out on the DSN WG mailing list, in case of transfers, >> where the "buyer" normally does not wish to have any further >> business relationship with the "seller" once the transfer is >> completed, this solution may be unattractive. The fact that the >> "seller" has to provide appropriate DNS services (i.e. in accordance >> with BCP20/RFC2317) to the "buyer" for an _indefinite_ period of >> time, is probably one more deterrent to transferring such a small >> amount of addresses. > > I think it would be reasonable to expect that if 2014-01 passes, the NCC > will respond by allowing direct classless delegation of PA blocks, just > like is already done for PI. If so, what you're describing here > shouldn't be a problem. I think you refer to the following statement from the LIR handbook: "The RIPE NCC will directly reverse delegate to zones smaller than /24 which are Provider Independent (PI) and do not originate from an LIR's PA allocation. If this applies or questions arise, please contact: ripe-dbm at ripe.net" However, I think this is not an administrative question (i.e. the question is not whether the NCC allows it or not). In case of PI, the "surrounding" address space is also managed by the RIPE NCC, so they do have the possibility to set up a scheme similar to the one specified in BCP20/RFC2317. In case of a transfer out of an LIR allocation, the "surrounding" space is allocated to the "selling" LIR, so they are the ones who _can_ set up the reverse delegation. Alternatively, the transfer policy could require that in such a case the "surrounding" /24 has to be delegated to the RIPE NCC, who will manage this address space in a neutral way for an indefinite period of time. This would, however, have an impact on RIPE NCC operations, and I do not think I would support such a proposal. Best regards, Janos > Tore > > From tore at fud.no Fri Mar 28 12:49:04 2014 From: tore at fud.no (Tore Anderson) Date: Fri, 28 Mar 2014 12:49:04 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53354A29.2070002@iszt.hu> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> Message-ID: <533561B0.1070004@fud.no> Hi Janos, > I think you refer to the following statement from the LIR handbook: > "The RIPE NCC will directly reverse delegate to zones smaller than /24 > which are Provider Independent (PI) and do not originate from an LIR's PA > allocation. If this applies or questions arise, please contact: > ripe-dbm at ripe.net" Yes, exactly. Also see: http://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-delegation > However, I think this is not an administrative question (i.e. the question > is not whether the NCC allows it or not). > > In case of PI, the "surrounding" address space is also managed by the > RIPE NCC, so they do have the possibility to set up a scheme similar to > the one specified in BCP20/RFC2317. > > In case of a transfer out of an LIR allocation, the "surrounding" space > is allocated to the "selling" LIR, so they are the ones who _can_ set up > the reverse delegation. > > Alternatively, the transfer policy could require that in such a case the > "surrounding" /24 has to be delegated to the RIPE NCC, who will manage > this address space in a neutral way for an indefinite period of time. > This would, however, have an impact on RIPE NCC operations, and I do not > think I would support such a proposal. Maybe I am being dense, but I am really struggling to understand your concern. After all the surrounding address space is already delegated to the RIPE NCC's name servers, which then sub-delegate based on the domain objects the resource holder inserts into the database. So I don't see how this proposal would have an impact on RIPE NCC operations in this regard (beyond the one-time job of permitting classless delegation for PA space in the same way as for PI). Let me try to explain my understanding of things by example... 185.47.43.0/24 is part of an ALLOCATED PA delegation from the RIPE NCC to my LIR. When it comes to reverse DNS, the allocation chain goes like this, starting from the root: . NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine) [The NS records for "40.47.185.in-addr.arpa." happens to be there because I've inserted the corresponding object into the RIPE database and it's based on those objects the RIPE NCC generates the "185.in-addr.arpa" zone.] Let's now assume that you and I agree that 185.47.43.128/25 should be transferred to your LIR. I would then expect that the delegation chain would part ways in the 185.in-addr.arpa sone, like so for my /25: . NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 0-127.43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine) ..and like so for your /25: . NS [a-m].root-servers.net. in-addr.arpa. NS [a-f].in-addr-servers.arpa. 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) 128-255.43.47.185.in-addr.arpa. NS ns*.iszt.hu (yours) [As before, we would of course both need to insert appropriate domain objects into the RIPE database for the final delegation to our own authoritative name servers to show up in the 185.in-addr.arpa zone.] Even though I would be the "selling" LIR here, I do not understand why I would be required to play a part in delegating reverse DNS for the /25 you "bought" for an infinite period of time (or any period of time at all for that matter). What am I missing here? Tore From sander at steffann.nl Fri Mar 28 14:05:27 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Mar 2014 14:05:27 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53354A29.2070002@iszt.hu> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> Message-ID: <17865D4E-2AE7-49A1-9679-33813470DA7F@steffann.nl> Hi Janos, > In case of PI, the "surrounding" address space is also managed by the > RIPE NCC, so they do have the possibility to set up a scheme similar to > the one specified in BCP20/RFC2317. > > In case of a transfer out of an LIR allocation, the "surrounding" space > is allocated to the "selling" LIR, so they are the ones who _can_ set up > the reverse delegation. Euhm, no... For example: if an LIR has a /21 and permanently transfers a /25 to another organisation then the resulting situation would be: - The LIR now has multiple smaller allocations: a /22, /23, /24 and /25. So the reverse delegation would be for 7x /24 and the /25 would be delegated according to BCP20/RFC2317 - The other organisation would have a /25 and get BCP20/RFC2317stuff too Once a /25 is transferred the original allocation changes and the NCC cannot delegate the reverse for the whole /24 that contains the /25 to the LIR. It's not the LIR's address space anymore. Cheers, Sander From zsako at iszt.hu Fri Mar 28 14:59:51 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 28 Mar 2014 14:59:51 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <533561B0.1070004@fud.no> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> <533561B0.1070004@fud.no> Message-ID: <53358057.8030701@iszt.hu> Dear Tore, >> Alternatively, the transfer policy could require that in such a case the >> "surrounding" /24 has to be delegated to the RIPE NCC, who will manage >> this address space in a neutral way for an indefinite period of time. >> This would, however, have an impact on RIPE NCC operations, and I do not >> think I would support such a proposal. > > Maybe I am being dense, but I am really struggling to understand your > concern. After all the surrounding address space is already delegated to > the RIPE NCC's name servers, which then sub-delegate based on the domain > objects the resource holder inserts into the database. So I don't see > how this proposal would have an impact on RIPE NCC operations in this > regard (beyond the one-time job of permitting classless delegation for > PA space in the same way as for PI). > > Let me try to explain my understanding of things by example... Thank you for the detailed example. I now understand what you are saying. The problem is that this does not work with allocations larger than a /16. In this case the /16 is usually already delegated to the LIR. An analogy with your example would be that 47.185.in-addr.arpa is already delegated to you. In this case the NCC could not insert the 0-127.43.47.185.in-addr.arpa delegation in the 185.in-addr.arpa zone. I see two solutions to this: - the NCC "revokes" the /16 delegation and replaces it with 255 /24 delegations, and two /25 delegations - you delegate 43.47.185.in-addr.arpa back to the NCC Neither of them is appropriate in my view. By the way, as I pointed it out on the DNS WG list, I think this obligation to provide appropriate DNS services for an indefinite time is not necessarily specific to address space smaller than a /24, as any transfer smaller than a /16 out of an allocation of at least a /16 has a somewhat similar problem. Best regards, Janos > 185.47.43.0/24 is part of an ALLOCATED PA delegation from the RIPE NCC > to my LIR. When it comes to reverse DNS, the allocation chain goes like > this, starting from the root: > > . NS [a-m].root-servers.net. > in-addr.arpa. NS [a-f].in-addr-servers.arpa. > 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) > 43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine) > > [The NS records for "40.47.185.in-addr.arpa." happens to be there > because I've inserted the corresponding object into the RIPE database > and it's based on those objects the RIPE NCC generates the > "185.in-addr.arpa" zone.] > > Let's now assume that you and I agree that 185.47.43.128/25 should be > transferred to your LIR. I would then expect that the delegation chain > would part ways in the 185.in-addr.arpa sone, like so for my /25: > > . NS [a-m].root-servers.net. > in-addr.arpa. NS [a-f].in-addr-servers.arpa. > 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) > 0-127.43.47.185.in-addr.arpa. NS ns-{foo,bar,baz}.linpro.net. (mine) > > ..and like so for your /25: > > . NS [a-m].root-servers.net. > in-addr.arpa. NS [a-f].in-addr-servers.arpa. > 185.in-addr.arpa. NS pri.authdns.ripe.net. (+slaves) > 128-255.43.47.185.in-addr.arpa. NS ns*.iszt.hu (yours) > > [As before, we would of course both need to insert appropriate domain > objects into the RIPE database for the final delegation to our own > authoritative name servers to show up in the 185.in-addr.arpa zone.] > > Even though I would be the "selling" LIR here, I do not understand why I > would be required to play a part in delegating reverse DNS for the /25 > you "bought" for an infinite period of time (or any period of time at > all for that matter). What am I missing here? > > Tore > > From gert at space.net Fri Mar 28 15:04:50 2014 From: gert at space.net (Gert Doering) Date: Fri, 28 Mar 2014 15:04:50 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53358057.8030701@iszt.hu> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> <533561B0.1070004@fud.no> <53358057.8030701@iszt.hu> Message-ID: <20140328140450.GS43641@Space.Net> Hi, On Fri, Mar 28, 2014 at 02:59:51PM +0100, Janos Zsako wrote: > The problem is that this does not work with allocations larger than > a /16. In this case the /16 is usually already delegated to the LIR. > > An analogy with your example would be that 47.185.in-addr.arpa is already > delegated to you. > > In this case the NCC could not insert the 0-127.43.47.185.in-addr.arpa > delegation in the 185.in-addr.arpa zone. > > I see two solutions to this: > > - the NCC "revokes" the /16 delegation and replaces it with 255 /24 > delegations, and two /25 delegations > - you delegate 43.47.185.in-addr.arpa back to the NCC > > Neither of them is appropriate in my view. If you have a /16, and transfer-away part of that /16, you no longer have a /16. ... and if you do not have the full /16, the NCC will not delegate DNS at that byte boundary to you. That's how it is today, ask anyone who just has a /17... So I find this *quite* clear - "give up your /16, and lose DNS authority on that part of the tree". Might not be convenient, but it's logical and consistent with "regular" allocations smaller than a /16. 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 zsako at iszt.hu Fri Mar 28 15:07:49 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 28 Mar 2014 15:07:49 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <17865D4E-2AE7-49A1-9679-33813470DA7F@steffann.nl> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> <17865D4E-2AE7-49A1-9679-33813470DA7F@steffann.nl> Message-ID: <53358235.9060602@iszt.hu> Dear Sander, >> In case of PI, the "surrounding" address space is also managed by the >> RIPE NCC, so they do have the possibility to set up a scheme similar to >> the one specified in BCP20/RFC2317. >> >> In case of a transfer out of an LIR allocation, the "surrounding" space >> is allocated to the "selling" LIR, so they are the ones who _can_ set up >> the reverse delegation. > > Euhm, no... For example: if an LIR has a /21 and permanently transfers a /25 to another organisation then the resulting situation would be: > - The LIR now has multiple smaller allocations: a /22, /23, /24 and /25. So the reverse delegation would be for 7x /24 and the /25 would be delegated according to BCP20/RFC2317 > - The other organisation would have a /25 and get BCP20/RFC2317stuff too > > Once a /25 is transferred the original allocation changes and the NCC cannot delegate the reverse for the whole /24 that contains the /25 to the LIR. It's not the LIR's address space anymore. You are right. Basically what you are saying, the NCC would not approve the transfer as long as the above is not solved. I am wondering whether this is (or should be) enforced in case of transfers out of a /16 allocation. Best regards, Janos > Cheers, > Sander > > From sander at steffann.nl Fri Mar 28 15:09:37 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Mar 2014 15:09:37 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53358057.8030701@iszt.hu> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> <533561B0.1070004@fud.no> <53358057.8030701@iszt.hu> Message-ID: Hi, > I see two solutions to this: > > - the NCC "revokes" the /16 delegation and replaces it with 255 /24 > delegations, and two /25 delegations > - you delegate 43.47.185.in-addr.arpa back to the NCC > > Neither of them is appropriate in my view. I think the first one is appropriate. If the NCC doesn't allocate the whole /16 to one organisation they cannot create a reverse delegation for it to that single organisation. They can't delegate reverse DNS to an organisation that doesn't hold that address space... So the technically correct solution is to do what you suggest first. It isn't pretty, and it would make address holders think twice before carving out a small portion of their address space to sell, but that might be a good thing :) I'll leave that for the the WG to discuss :) Cheers, Sander From sander at steffann.nl Fri Mar 28 15:13:45 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Mar 2014 15:13:45 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <53358235.9060602@iszt.hu> References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> <17865D4E-2AE7-49A1-9679-33813470DA7F@steffann.nl> <53358235.9060602@iszt.hu> Message-ID: Hi, >> Once a /25 is transferred the original allocation changes and the NCC cannot delegate the reverse for the whole /24 that contains the /25 to the LIR. It's not the LIR's address space anymore. > > You are right. Basically what you are saying, the NCC would not approve > the transfer as long as the above is not solved. That would seem appropriate to me. I'm not sure what the current procedures for this are at the moment, but the end result should be like that, yes. > I am wondering whether this is (or should be) enforced in case of transfers > out of a /16 allocation. Why not? It is an issue for any delegation that is not on a multiple of 8 bits (/8, /16 and /24). We currently already have reverse tree delegations of multiple /24s for those that have an allocation from a /17 to a /25. That isn't new. The only new part would be to re-organise some parts of the tree before transferring the corresponding address space. Cheers, Sander From sandrabrown at ipv4marketgroup.com Fri Mar 28 16:21:18 2014 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Fri, 28 Mar 2014 08:21:18 -0700 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the MinimumAllocation Size for IPv4) Message-ID: <20140328082118.ec289651d84890fcbef5f195936e1217.9b802babe5.wbe@email17.secureserver.net> Hello -- I am neither for nor against the policy. I do have some statistics from our business that may be relevant to the decision. Between May of 2012 when we saw the first small transaction, and today, we have received exactly 50 requests for transfers of LESS than a /22 within the RIPE region. One of these was for only 1 IP, but the most common request would be for a /24. My opinion is that this shows there is some demand for an allocation size smaller than a /22. The requests came from all over Europe, but the countries most represented would be Poland, the UK, the Netherlands, Italy, and the Ukraine, for whatever reason. Many countries are represented at least once. Best Regards, Sandra Brown IPv4 Market Group From zsako at iszt.hu Fri Mar 28 16:55:28 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 28 Mar 2014 16:55:28 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: References: <20140324140547.GA6900@nosc.ja.net> <53307B8A.3010403@fud.no> <5333CABF.1070609@schiefner.de> <5333E28C.6030906@fud.no> <53342E24.7000702@iszt.hu> <53347B65.5010606@fud.no> <53354A29.2070002@iszt.hu> <17865D4E-2AE7-49A1-9679-33813470DA7F@steffann.nl> <53358235.9060602@iszt.hu> Message-ID: <53359B70.3030609@iszt.hu> Dear all, >> I am wondering whether this is (or should be) enforced in case of transfers >> out of a /16 allocation. > > Why not? It is an issue for any delegation that is not on a multiple of 8 bits (/8, /16 and /24). We currently already have reverse tree delegations of multiple /24s for those that have an allocation from a /17 to a /25. That isn't new. The only new part would be to re-organise some parts of the tree before transferring the corresponding address space. Just out of curiosity I checked the transfers that resulted in the split of a /16. It seems it is already part of the procedures to revoke the reverse delegation upon transfer. Out of 19 such transfers only 3, mostly older ones, did still have the delegation. Best regards, Janos > Cheers, > Sander > > From lists-ripe at c4inet.net Fri Mar 28 17:41:44 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 28 Mar 2014 16:41:44 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140324132312.56C3D4E9A5@mail.c4inet.net> References: <20140324132312.56C3D4E9A5@mail.c4inet.net> Message-ID: <20140328164144.GA76384@cilantro.c4inet.net> All, On Mon, Mar 24, 2014 at 02:18:44PM +0100, Marco Schmidt wrote: >You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-01 > >We encourage you to review this proposal and send your comments to I don't think this proposal takes into account operational reality. The fact of the matter is, that there is a lower limit to what allocation size is operationally useful to a LIR (unless the routing community is prepared to accept /32s in the DFZ). Add to that the extra complexity of reverse delegating References: <20140324132312.56C3D4E9A5@mail.c4inet.net> <20140328164144.GA76384@cilantro.c4inet.net> Message-ID: <20140328171319.GA43641@Space.Net> Hi, On Fri, Mar 28, 2014 at 04:41:44PM +0000, Sascha Luck wrote: > I do not want to go back to the not-so-long-ago days of having to > concoct fiction in order to get a useful amount of resources out of the > NCC. You won't, just request IPv6. For IPv4, it will be slightly hard, for the foreseeable future, to achieve that. IOW, I have no idea what you are trying to tell us here...? gert, speaking for himself -- 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 lists-ripe at c4inet.net Fri Mar 28 19:23:58 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 28 Mar 2014 18:23:58 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140328171319.GA43641@Space.Net> References: <20140324132312.56C3D4E9A5@mail.c4inet.net> <20140328164144.GA76384@cilantro.c4inet.net> <20140328171319.GA43641@Space.Net> Message-ID: <20140328182358.GB76384@cilantro.c4inet.net> On Fri, Mar 28, 2014 at 06:13:19PM +0100, Gert Doering wrote: >You won't, just request IPv6. For IPv4, it will be slightly hard, for >the foreseeable future, to achieve that. > >IOW, I have no idea what you are trying to tell us here...? What I'm trying to tell you here is that abolition of any min-alloc size will again require demonstration of "need" in order to get a useful (ie. routeable) allocation (with all that this entails). Another good question is whether under final-/8 rules, if you can only justify, say a /29, this will be the last request considered? rgds, Sascha Luck From zsako at iszt.hu Fri Mar 28 19:58:44 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 28 Mar 2014 19:58:44 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140328182358.GB76384@cilantro.c4inet.net> References: <20140324132312.56C3D4E9A5@mail.c4inet.net> <20140328164144.GA76384@cilantro.c4inet.net> <20140328171319.GA43641@Space.Net> <20140328182358.GB76384@cilantro.c4inet.net> Message-ID: <5335C664.6070305@iszt.hu> Dear Sacha, > What I'm trying to tell you here is that abolition of any min-alloc size > will again require demonstration of "need" in order to get a useful (ie. > routeable) allocation (with all that this entails). Another good question is whether under final-/8 rules, if you can only > justify, say a /29, this will be the last request considered? I think there is a misunderstanding here. This policy (2014-01) does not change the rest of the text of 5.1. It still says: 1. The size of the allocation made will be exactly one /22. Best regards, Janos > rgds, > Sascha Luck > > From lists-ripe at c4inet.net Fri Mar 28 20:22:59 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 28 Mar 2014 19:22:59 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5335C664.6070305@iszt.hu> References: <20140324132312.56C3D4E9A5@mail.c4inet.net> <20140328164144.GA76384@cilantro.c4inet.net> <20140328171319.GA43641@Space.Net> <20140328182358.GB76384@cilantro.c4inet.net> <5335C664.6070305@iszt.hu> Message-ID: <20140328192259.GC76384@cilantro.c4inet.net> On Fri, Mar 28, 2014 at 07:58:44PM +0100, Janos Zsako wrote: >I think there is a misunderstanding here. >This policy (2014-01) does not change the rest of the text of 5.1. >It still says: >1. The size of the allocation made will be exactly one /22. You're right, it does. My bad. That actually removes the main reason to be unhappy with the proposal; the reverse DNS issue is not strong enough to sustain an objection on. Thanks for clarifying this, Sascha Luck From gert at space.net Sat Mar 29 17:44:21 2014 From: gert at space.net (Gert Doering) Date: Sat, 29 Mar 2014 17:44:21 +0100 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140328182358.GB76384@cilantro.c4inet.net> References: <20140324132312.56C3D4E9A5@mail.c4inet.net> <20140328164144.GA76384@cilantro.c4inet.net> <20140328171319.GA43641@Space.Net> <20140328182358.GB76384@cilantro.c4inet.net> Message-ID: <20140329164421.GH43641@Space.Net> Hi, On Fri, Mar 28, 2014 at 06:23:58PM +0000, Sascha Luck wrote: > On Fri, Mar 28, 2014 at 06:13:19PM +0100, Gert Doering wrote: > >You won't, just request IPv6. For IPv4, it will be slightly hard, for > >the foreseeable future, to achieve that. > > > >IOW, I have no idea what you are trying to tell us here...? > > What I'm trying to tell you here is that abolition of any min-alloc size > will again require demonstration of "need" in order to get a useful (ie. > routeable) allocation (with all that this entails). The proposal at hand is not affecting "last /8" policy, and as such, has no influence on routability of allocations handed out by the RIPE NCC. > Another good question is whether under final-/8 rules, if you can only > justify, say a /29, this will be the last request considered? Justification of a single IP address will give you your last-/8-/22, if you had none before. There is no granularity in last-/8 allocations, it's "a single piece of standard-size fits all". 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 lists-ripe at c4inet.net Sat Mar 29 20:17:52 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sat, 29 Mar 2014 19:17:52 +0000 Subject: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <20140329164421.GH43641@Space.Net> References: <20140324132312.56C3D4E9A5@mail.c4inet.net> <20140328164144.GA76384@cilantro.c4inet.net> <20140328171319.GA43641@Space.Net> <20140328182358.GB76384@cilantro.c4inet.net> <20140329164421.GH43641@Space.Net> Message-ID: <20140329191752.GA81073@cilantro.c4inet.net> On Sat, Mar 29, 2014 at 05:44:21PM +0100, Gert Doering wrote: >The proposal at hand is not affecting "last /8" policy, and as such, >has no influence on routability of allocations handed out by the RIPE NCC. Yep, Janos already pointed out that I missed the bit where 2014-01 doesn't change the "last /8" allocation size. D-oh. >> Another good question is whether under final-/8 rules, if you can only >> justify, say a /29, this will be the last request considered? >Justification of a single IP address will give you your last-/8-/22, if >you had none before. There is no granularity in last-/8 allocations, it's >"a single piece of standard-size fits all". yep, as above. rgds, Sascha Luck From mschmidt at ripe.net Mon Mar 31 14:52:36 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 31 Mar 2014 14:52:36 +0200 Subject: [address-policy-wg] 2014-02 New Policy Proposal (Allow IPv4 PI transfer) Message-ID: Dear colleagues, A proposed change to RIPE Document ripe-606, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 We encourage you to review this proposal and send your comments to before 29 April 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC