From apwg at c4inet.net Tue Sep 1 00:18:19 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 31 Aug 2015 23:18:19 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E4C581.9060605@inex.ie> References: <55E4C581.9060605@inex.ie> Message-ID: <20150831221819.GA64445@cilantro.c4inet.net> On Mon, Aug 31, 2015 at 10:22:09PM +0100, Nick Hilliard wrote: >first of all, a large thank-you for handling this policy aggregation. This >will make things a lot easier for organisations to understand how RIPE >transfer policy works. Although policy reworking like this is completely >thankless, it's important to do. I support this statement. And thank you for diffing/summarising this big document as well. >"Resources are excluded from transfers when RIPE Policies mandate their >return to the RIPE NCC.": this is completely new text. approve. [...] >all policies: "Resources are excluded from transfers when RIPE Policies >mandate their return to the RIPE NCC". Mmm. I'd be careful about >inserting something like this. Can you explain the intention and the >meaning of this clause? Can't have it both ways ;p As for myself, I would like to see some clarification on this myself. >asn transfer policy: added "scarce resources ... cannot be transferred by >the resource holder within 24 months". I don't disagree with this, nor >with the genericisation of this transfer restriction. I do (disagree). IMO this should be a separate policy change, not something to be hidden in a huge re-work. Generally I would prefer if this re-work would only aggregate the transfer policies and any material changes, in particular, restrictions, would be left to later proposals. It will also speed the approval of the proposal if there were no potentially contentious changes. As it stands I'll have to, provisionally, declare opposition to this proposal pending a more careful re-read to find any other little landmines that may be hidden in there. rgds, Sascha Luck From tore at fud.no Tue Sep 1 00:25:16 2015 From: tore at fud.no (Tore Anderson) Date: Tue, 1 Sep 2015 00:25:16 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E4C581.9060605@inex.ie> References: <55E4C581.9060605@inex.ie> Message-ID: <20150901002516.6fa5974c@envy.fud.no> * Nick Hilliard > first of all, a large thank-you for handling this policy aggregation. This > will make things a lot easier for organisations to understand how RIPE > transfer policy works. Although policy reworking like this is completely > thankless, it's important to do. Hear hear. > all policies: removed statement about publishing stats on non-approved > transfers. Whoa, what's going on here? Not ok. I might be to blame for this one. Let me elaborate: 2012-05, which introduced this requirement, said the following: ?Recording when address transfers were denied on the basis of needs evaluation (without identifying the block or the proposed recipient) is also important, because it facilitates greater awareness of the impact of RIPE NCC?s application of needs assessment policies on the transfer market.? However, needs assessment for IPv4 transfers (which was the only type allowed at the time) was removed by 2013-03. Thus I considered the requirement to be defunct policy as the NCC no longer would have any reason to not approve of transfers, but I didn't get around to remove it as part of 2013-03. That has irked me since, so I suggested to Erik that maybe he could clean it away in his transfer unification proposal instead. That said, I now realise that since 2014-12 and 2014-13 passed there might again be requests for IPv6/ASN transfers that the NCC might not approve of, making 2015-04's removal of the publishing requirement an actual change to effective policy. In light of that I suppose my suggestion might have been a bad one. My apologies, Erik. Tore From elvis at velea.eu Tue Sep 1 00:32:57 2015 From: elvis at velea.eu (Elvis Daniel Velea) Date: Tue, 01 Sep 2015 01:32:57 +0300 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E4C581.9060605@inex.ie> References: <55E4C581.9060605@inex.ie> Message-ID: <55E4D619.9070508@velea.eu> wow Nick, thanks for the diff. I have not had time to carefully ready all the documents, so, this reply is only to your comments. I'll send an other e-mail If I find anything else worth mentioning once I get the time to compare all the current policy documents to the new policy proposal. On 01/09/15 00:22, Nick Hilliard wrote: >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-04 > first of all, a large thank-you for handling this policy aggregation. This > will make things a lot easier for organisations to understand how RIPE > transfer policy works. Although policy reworking like this is completely > thankless, it's important to do. big thanks, Erik > I've gone down through the new policy and compared it against the old. As > expected, there is plenty of optimisation going on, but optimisation means > changes and changes mean that we need to understand what's been changed. > > Enumerating some of the changes: > > "Resources are excluded from transfers when RIPE Policies mandate their > return to the RIPE NCC.": this is completely new text. approve. I would like this to be clarified. I don't recall having any policies mandating a return of a resource to the RIPE NCC. > > ipv6 transfer policy: added "Transfers must be reflected in the RIPE > Database. Transfers can be on a permanent or non-permanent basis.". approve. +1 > > ipv6 transfer policy: removed "The block that is to be re-allocated must > not be smaller than the minimum allocation size at the time of > re-allocation". for the record, this is an interesting consequence of > section 2.1, paragraph 3. I.e. no point in repeating policy that already > exists. ok > > asn transfer policy: added "scarce resources ... cannot be transferred by > the resource holder within 24 months". I don't disagree with this, nor > with the genericisation of this transfer restriction. I do not disagree with this change. I would, as Sacha said, prefer to discuss it in a separate policy proposal. > all policies: the tightening of the policy text in section 2.1 concerning > who's currently responsible for the resource ("the original resource holder > ... policies are applied") is good. > > asn + ipv6 policies: added statement that ripe policies apply for the > duration of transfer and during the transfer process itself - to align with > the ipv4 policy. This is good, but other RIRs may claim that their > policies apply during the transfer process. Would it be worth discussing > at a higher level whether there should be a global policy for which RIR > policy applies during the transfer process? I also believe that as long as a resource is registered in a registry's db, that registry's policy must apply. > > all policies: "Resources are excluded from transfers when RIPE Policies > mandate their return to the RIPE NCC". Mmm. I'd be careful about > inserting something like this. Can you explain the intention and the > meaning of this clause? same as above.. I'd like this to be explained. > > all policies: removed statement about publishing stats on non-approved > transfers. Whoa, what's going on here? Not ok. IMHO, aggregated stats should still exist for non-approved transfers. > Nick > > regards, elvis From nick at inex.ie Tue Sep 1 10:22:26 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 1 Sep 2015 09:22:26 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <55E56042.6050001@inex.ie> > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2015-04 one more issue: > The rules for Internet number resource transfers (including legacy > resources) to and from the RIPE NCC service region (often referred to as > inter-RIR transfers) It's good that this policy specifically includes legacy resources. It would be useful to clarify in the policy whether inbound transfers of legacy resources are subject to regular RIPE community number resource policies or the "RIPE NCC Services to Legacy Internet Resource Holders" policy. My reading would be the latter, but as it's unstated, there is a potential ambiguity here which has the potential of causing future problems. Nick From mschmidt at ripe.net Tue Sep 1 12:02:53 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 01 Sep 2015 12:02:53 +0200 Subject: [address-policy-wg] Update on Inter-RIR Transfer Implementation Message-ID: <55E577CD.2090703@ripe.net> Dear colleagues, We wanted to update you on our implementation of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". We have made good progress so far on what has been one of the most substantial policy changes ever implemented by the RIPE NCC. Most of the updates to our internal processes and software have been finalised, as have the processes that require interaction with the other RIRs. During the implementation we encountered some additional complexity in the transfer process. To compensate for this, we are developing additional software automation to ensure the quality of registration data is maintained. We now therefore expect the implementation to be finished before the end of September. The policy implementation status has been updated accordingly, and you can find this here: https://www.ripe.net/manage-ips-and-asns/resource-management/policy-implementation-status We will send another announcement once the implementation has been completed. Kind regards Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Tue Sep 1 20:31:27 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 1 Sep 2015 19:31:27 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <20150831221819.GA64445@cilantro.c4inet.net> References: <55E4C581.9060605@inex.ie> <20150831221819.GA64445@cilantro.c4inet.net> Message-ID: <55E5EEFF.9020507@inex.ie> On 31/08/2015 23:18, Sascha Luck [ml] wrote: > Can't have it both ways ;p As for myself, I would like to see > some clarification on this myself. have cake, eat cake. As you point out, I changed my mind mid-email. It happens. >> asn transfer policy: added "scarce resources ... cannot be transferred by >> the resource holder within 24 months". I don't disagree with this, nor >> with the genericisation of this transfer restriction. > > I do (disagree). IMO this should be a separate policy change, not > something to be hidden in a huge re-work. The only thing that's changing is that asn16s are now be included in the 24m restriction. IPv4 addresses are already there. Nick From erik at bais.name Tue Sep 1 23:52:33 2015 From: erik at bais.name (Erik Bais) Date: Tue, 1 Sep 2015 21:52:33 +0000 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <862A73D42343AE49B2FC3C32FDDFE91C0161234EFF@E2010-MBX04.exchange2010.nl> Hi James, > Couple of questions/comments... > From 1.0 > Shouldn't the scope be explicit as to what is/isn't included It states what is included ... are you missing anything specific ? > From 2.1 > "Transfers can be on a permanent or non-permanent basis." > How is this going to be recorded and managed within the context of > reflecting it being a non-permanent transfer? That is taken directly from the current policy text and it is managed by the RIPE NCC. I must admit that I haven't seen non-permanent transfers myself (yet), so I would have to ask the NCC on how they are exposing that if at all publicly. The text itself isn't different to what there is already there. > From 2.2 > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit ASNs)" > Rather than "such as" this needs to be a definitive list of what is > classed as a restricted resource The part between the round brackets was put there as the current examples to what are the almost depleted resources. As IPv4 isn't completely depleted yet ( due to the final /8 policy ) and neither are 16-bit ASN's.. That implies that other resources like IPv6 or 32-bit ASN's are not restrictive by a 24 month transfer restriction as there is no logical requirement that we could find to put it in the policy. > From 3.1 > Again a list of conditions or references to policies that impose restrictions needed You mean other than what is currently in the proposed text ? Currently all resources that we have are possible to be transferred ... > From 4.0 > M&A process is mentioned, should there be other references to this? > Especially as M&A (as I understand it) allows 2.2 to be overridden An M&A is not a transfer ... a M&A is a change in a business where one company or service offering with assets/resources are going from one company to another company. That can be in the same company ( Look at companies like IBM or Philips or GE for instance that are splitting off services to a new business unit .. or buying competing companies and incorporating that into their own business / service..) Sometimes there are stocks being sold, however there are more ways of M&A's within today's business. Typical the goal of M&A's are not the (number) resources, but other services/assets/added value that would create the value ... And with a transfer, the goal is getting or selling the specified resource. Also the M&A is a business (operational) process.. and transfers are a policy. > General > - As this is about transfers should this also cover returning > resources to ripe NCC so all types of transfers be included The text is pretty clear imho on what it covers.. any number resource to and from the RIPE NCC service region ... Both TO and FROM the RIPE region ... > - broadly support the unification of transfer policy into a single > document, just things bits are missing or muddy I hope that we made a good start here :) Erik Bais From ebais at a2b-internet.com Wed Sep 2 00:37:22 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 2 Sep 2015 00:37:22 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E4C581.9060605@inex.ie> References: <55E4C581.9060605@inex.ie> Message-ID: <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> Hi Nick, >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2015-04 >first of all, a large thank-you for handling this policy aggregation. Let's see if we can get it across the room :) And thank you for the diff ... I'm a bit behind on my mail replies, but let's get started on the discussion here... > This will make things a lot easier for organisations to understand how RIPE > transfer policy works. Although policy reworking like this is completely > thankless, it's important to do. As stated earlier, I made some of the mess in the current policy text, and I said I would make a proposal to clean it up. The current text was required to get the current policies in place .. and most of the transfer procedures are currently (almost) the same for all resources.. That was done intentionally when I made the policies, in order to be able to make this clean-up easier ... > I've gone down through the new policy and compared it against the old. As > expected, there is plenty of optimisation going on, but optimisation means > changes and changes mean that we need to understand what's been changed. > Enumerating some of the changes: > "Resources are excluded from transfers when RIPE Policies mandate their > return to the RIPE NCC.": this is completely new text. approve. To clarify here ... although all types of number resources can be transferred.. ( AS, IPv4, IPv6 ) there are some specific resources ( like v4 for IXP usage ) are not allowed to be transferred and MUST be returned.. https://www.ripe.net/publications/docs/ripe-649#61 So in itself it is a more specific statement in the intent of the policy, this new policy isn't going to change the transfer options if the current policy states that it must be returned.. > ipv6 transfer policy: added "Transfers must be reflected in the RIPE > Database. Transfers can be on a permanent or non-permanent basis.". approve. > ipv6 transfer policy: removed "The block that is to be re-allocated must > not be smaller than the minimum allocation size at the time of > re-allocation". for the record, this is an interesting consequence of > section 2.1, paragraph 3. I.e. no point in repeating policy that already > exists. > asn transfer policy: added "scarce resources ... cannot be transferred by > the resource holder within 24 months". I don't disagree with this, nor > with the genericisation of this transfer restriction. I also addressed this in the email of James. And it was also discussed during the AS transfer policy in the room at the AP-WG. The transfer policy time restriction is for scarce resources .. ( like IPv4 and 16-bits ASN's.) and not for IPv6 or 32-bit ASn's. > all policies: the tightening of the policy text in section 2.1 concerning > who's currently responsible for the resource ("the original resource holder > ... policies are applied") is good. > asn + ipv6 policies: added statement that ripe policies apply for the > duration of transfer and during the transfer process itself - to align with > the ipv4 policy. This is good, but other RIRs may claim that their > policies apply during the transfer process. Would it be worth discussing > at a higher level whether there should be a global policy for which RIR > policy applies during the transfer process? When dealing with the Inter RIR-policy, one should look at both RIR sides for the inter RIR policy in both regions. I must admit that I tried to keep the current inter RIR policy text the same as it already was, to avoid any possible delay of the current policy or other RIR board freaking out over a specific word that might change the policy in their view.. or the impact. I'm just pointing in that respect to the statement of the APNIC board to single handed freeze any transfers up front between APNIC and RIPE, just to look at the possible policy impact.. > all policies: "Resources are excluded from transfers when RIPE Policies > mandate their return to the RIPE NCC". Mmm. I'd be careful about > inserting something like this. Can you explain the intention and the > meaning of this clause? The reason to include this was to be extra careful .. Yes we can transfer everything ... unless policy states it otherwise. So this policy document doesn't override things as implemented for Internet Exchange reservations ... https://www.ripe.net/publications/docs/ripe-649#61 > all policies: removed statement about publishing stats on non-approved > transfers. Whoa, what's going on here? Not ok. There is no need .. from what I've understood, the RIPE NCC didn't had any situation after the post depletion policy text clean-up (http://www.ripe.net/ripe/policies/proposals/2013-03) that transfers could be denied .. And if there is no situation to not approve transfers, why publish the number that is not going to change ? If documents for transfers are not approved, they are not denied transferred, the tickets will not be processed because the paperwork isn't correct. Btw.. did you see that nr. 4.0 will also implement if a new field in the transfer statistics ... - Whether it was a transfer or merger/acquisition As it will also make a slight change in the transfer restrictions .. as it closes the 'loophole' to have transfers now also restricted after M&A's and not only after allocation by RIPE NCC or transfers. The point 2.2 wording ( cannot be transferred by the resource holder within 24 months from the date the resource was received. ) is the cause of that.. and as such the statistics should reflect that info. Hence that update there.. Regards, Erik Bais From apwg at c4inet.net Wed Sep 2 15:02:11 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 2 Sep 2015 14:02:11 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> Message-ID: <20150902130211.GB64445@cilantro.c4inet.net> On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote: >To clarify here ... although all types of number resources can >be transferred.. ( AS, IPv4, IPv6 ) there are some specific >resources ( like v4 for IXP usage ) are not allowed to be >transferred and MUST be returned.. >https://www.ripe.net/publications/docs/ripe-649#61 > >So in itself it is a more specific statement in the intent of >the policy, this new policy isn't going to change the transfer >options if the current policy states that it must be returned.. OK, didn't actually know this restriction existed. >I also addressed this in the email of James. And it was also >discussed during the AS transfer policy in the room at the >AP-WG. The transfer policy time restriction is for scarce >resources .. ( like IPv4 and 16-bits ASN's.) and not for IPv6 or >32-bit ASn's. A holding period for ASN16 is a material change in assignment policy and should be in a separate proposal, not hidden in a (in itself valuable) transfer policy aggregation proposal. >Btw.. did you see that nr. 4.0 will also implement if a new >field in the transfer statistics ... > >- Whether it was a transfer or merger/acquisition > >As it will also make a slight change in the transfer >restrictions .. as it closes the 'loophole' to have transfers >now also restricted after M&A's and not only after allocation by >RIPE NCC or transfers. What is this supposed to mean? The 24-month timer resets if a resource is acquired by M&A? Pretty substantial change IMO. Again, this should be subject to a separate proposal. And perhaps a membership vote as it materially affects the M&A procedure. People, the RIPE community should not make policy like the US House of Representatives - by this I mean hiding your wish list in marginally related legislation in the hope that it will go unnoticed. This proposal is a much needed aggregation of scattered policy items and a laudable effort by the author. It is ill served by trying to make changes to policy at the same time. As a result, I will oppose 2015-04 until I am satisfied that there is no material change in policy contained within, and am looking forward to discuss such changes on their own merits. rgds, Sascha Luck From apwg at c4inet.net Wed Sep 2 15:40:49 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 2 Sep 2015 14:40:49 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> Message-ID: <20150902134049.GC64445@cilantro.c4inet.net> On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote: >To clarify here ... although all types of number resources can >be transferred.. ( AS, IPv4, IPv6 ) there are some specific >resources ( like v4 for IXP usage ) are not allowed to be >transferred and MUST be returned.. >https://www.ripe.net/publications/docs/ripe-649#61 Hmm. -649 s6.1 doesn't actually say that IXP PI must be returned and can't be transferred. At most it could be read as implied by "A /16 will be held in reserve for exclusive use by Internet Exchange Points" Even if interpreted restrictively, this would still allow transfers to other IXPs... May I suggest, though, that this statement: "Resources are excluded from transfers when RIPE Policies mandate their return to the RIPE NCC." be moved to s2.2 "Transfer Restrictions"? IMO it's a more logical place to find it if one were looking to find out whether a resource is eligible for transfer. rgds, Sascha Luck From nick at inex.ie Wed Sep 2 15:48:07 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 2 Sep 2015 14:48:07 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <20150902134049.GC64445@cilantro.c4inet.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> Message-ID: <55E6FE17.9020000@inex.ie> On 02/09/2015 14:40, Sascha Luck [ml] wrote: > Hmm. -649 s6.1 doesn't actually say that IXP PI must be returned and can't > be transferred. 649 section 6.1 says: -- This space will be used to run an IXP peering LAN; other uses are forbidden. -- i.e. if you're planning to transfer the address space to some other organisation, I'm reading this as meaning that it must either be another IXP as defined in "IPv6 Address Space for Internet Exchange Points", or else it will default back to the RIPE NCC. Nick From apwg at c4inet.net Wed Sep 2 15:55:54 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Wed, 2 Sep 2015 14:55:54 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E6FE17.9020000@inex.ie> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> <55E6FE17.9020000@inex.ie> Message-ID: <20150902135554.GD64445@cilantro.c4inet.net> On Wed, Sep 02, 2015 at 02:48:07PM +0100, Nick Hilliard wrote: >649 section 6.1 says: > >-- >This space will be used to run an IXP peering LAN; other uses are forbidden. >-- I actually read that as "This space *as assigned to this end-user*[...]" Does IXP space come out of a separate pool from any other ipv4? That section could maybe do with de-ambiguisation if only to protect the space for IXPs rgds, Sascha Luck From nick at inex.ie Wed Sep 2 16:27:06 2015 From: nick at inex.ie (Nick Hilliard) Date: Wed, 2 Sep 2015 15:27:06 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <20150902135554.GD64445@cilantro.c4inet.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> <55E6FE17.9020000@inex.ie> <20150902135554.GD64445@cilantro.c4inet.net> Message-ID: <55E7073A.4000908@inex.ie> On 02/09/2015 14:55, Sascha Luck [ml] wrote: > Does IXP space come out of a separate pool from any other ipv4? from what I understand, it comes out of a dedicated /16. RIPE NCC will be able to confirm whether this is a contiguous /16 or not. Nick From ebais at a2b-internet.com Thu Sep 3 14:36:12 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 3 Sep 2015 14:36:12 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <20150902130211.GB64445@cilantro.c4inet.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> Message-ID: <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> Hi Sascha, > On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote: >>To clarify here ... although all types of number resources can >>be transferred.. ( AS, IPv4, IPv6 ) there are some specific >>resources ( like v4 for IXP usage ) are not allowed to be >>transferred and MUST be returned.. >>https://www.ripe.net/publications/docs/ripe-649#61 > OK, didn't actually know this restriction existed. We learn something new from each other every day :) >>I also addressed this in the email of James. And it was also >>discussed during the AS transfer policy in the room at the >>AP-WG. The transfer policy time restriction is for scarce >>resources .. ( like IPv4 and 16-bits ASN's.) and not for IPv6 or >>32-bit ASn's. >A holding period for ASN16 is a material change in assignment >policy and should be in a separate proposal, not hidden in a (in >itself valuable) transfer policy aggregation proposal. Yes it is a change to the actual wording of the actual transfer policy for ASN's, it was stated in Amsterdam during the AP WG policy discussion that leaving out transfer restrictions in the policy for ASn's was a bit too far and it was suggested ( at the mic ) to look at almost depleted or scarce resources to have transfer restrictions as we currently have in policy for IPv4. By taking the wording as we have in front of us, it points out what it means, the intention is clear ... and it will leave the policy by itself accurate if 16 bit AS numbers have depleted .. without having to go over a re-writing of the policy here ... Both IPv6 and AS numbers have in the current policy no transfer restrictions ... I don't see a benefit to (have it) introduce for IPv6, but after the discussion in Amsterdam in the room, a restriction for 16-bit ASn's was desired. And that is also why it is currently here. This is not a 180 degree change of direction as it would make it more in line with other number resources .. 16-bit AS is in a similar state as IPv4.. it's gone.. get over it .. move on .. IPv6 is the new way, same as with 32-bit ASN's.. no restrictions.. >Btw.. did you see that nr. 4.0 will also implement if a new >field in the transfer statistics ... > >- Whether it was a transfer or merger/acquisition > >As it will also make a slight change in the transfer >restrictions .. as it closes the 'loophole' to have transfers >now also restricted after M&A's and not only after allocation by >RIPE NCC or transfers. > What is this supposed to mean? The 24-month timer resets if a > resource is acquired by M&A? > Pretty substantial change IMO. Again, this should be subject to a > separate proposal. And perhaps a membership vote as it > materially affects the M&A procedure. I don't think we have to re-hash all discussions as done in Elvis his proposal, which was viewed by the community as required and not strict enough as it didn't included M&A's.. Doing a membership vote would make it less open as it is just member that would vote on how to proceed here.. and it would only apply to PA space.. as member don't vote on PI resources ... So what would the impact be ... Is anything going to change based on the proposal in order to make do a M&A. - No. Will it give a more transparent view on resources changing holder ? Yes.. Will it remove the loophole of speculators, buying resources via M&A and transferring those directly ? Yes. ( This is currently possible and not in line with the original intent of the transfer policy restrictions of the initial IPv4 transfer policy AND the amendment to that by 2015-01.. ) Business that have a legitimate reason for performing a M&A, can still do so. The only restriction is that they can't re-transfer ( same as with new LIR now can't with the newly allocated /22's ... ) within 24 months. > People, the RIPE community should not make policy like the US > House of Representatives - by this I mean hiding your wish list > in marginally related legislation in the hope that it will go > unnoticed. > This proposal is a much needed aggregation of scattered policy > items and a laudable effort by the author. > It is ill served by trying to make changes to policy at the same > time. I think that by clearly pointing it out, during the discussion as it was not questioned during the initial reviews, it shows that it was not the intention of hiding anything ... The fact that people may not understand what they are reading because they don't have the complete overview of all policy implication changes is something that we can avoid ... It is not the intention of misleading people or trying to hide anything.. it is the other way around .. as I specifically pointed out to think about something that was missed. By clearly pointing out what certain text actually means and creating an 'Ahh ha' reflex ... 'Is that what the result is ... '. It means that people learned something they didn't knew before.. or just realized something that they missed.. Just like that you didn't knew that there are still specific usages for IPv4 for which IP space is specifically reserved (in the final /8) that are specifically excluded from the transfers .. as they MUST be returned.. >As a result, I will oppose 2015-04 until I am satisfied that > there is no material change in policy contained within, and am > looking forward to discuss such changes on their own merits. I hope I gave some additional insight in the actual changes and my reasoning behind it and as this is a policy that will create a general document across all resources ( hopefully for a long time to come..) it will have some changes and I hope that the document will reflect the intention of the community from all discussions that we already had in the past on the topics. Regards, Erik Bais From ebais at a2b-internet.com Thu Sep 3 14:41:09 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 3 Sep 2015 14:41:09 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <20150902134049.GC64445@cilantro.c4inet.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> Message-ID: <009201d0e645$d45bc3e0$7d134ba0$@a2b-internet.com> Hi Sascha, > May I suggest, though, that this statement: > "Resources are excluded from transfers when RIPE Policies mandate > their return to the RIPE NCC." > be moved to s2.2 "Transfer Restrictions"? IMO it's a more logical > place to find it if one were looking to find out whether a > resource is eligible for transfer. I see your point and I think that we need to have a look if that wouldn't just be re-stating what is already in the policy earlier.. Erik Bais From ebais at a2b-internet.com Thu Sep 3 14:58:54 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 3 Sep 2015 14:58:54 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E7073A.4000908@inex.ie> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> <55E6FE17.9020000@inex.ie> <20150902135554.GD64445@cilantro.c4inet.net> <55E7073A.4000908@inex.ie> Message-ID: <009901d0e648$5107e4d0$f317ae70$@a2b-internet.com> >From what I see, it looks like it is in the following range .. cat delegated-ripencc-extended-latest | grep '|185.1.' | grep '|256|' resulting in the following info : http://pastebin.com/3SHQsKxi Missing 'only' the following result : ripencc|PL|ipv4|185.1.10.0|512|20130403|assigned ripencc||ipv4|185.1.39.0|256||reserved It would be my wild guess that we are talking about the 185.1.x.y range :) Erik Bais -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Nick Hilliard Verzonden: woensdag 2 september 2015 16:27 Aan: Sascha Luck [ml] CC: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) On 02/09/2015 14:55, Sascha Luck [ml] wrote: > Does IXP space come out of a separate pool from any other ipv4? from what I understand, it comes out of a dedicated /16. RIPE NCC will be able to confirm whether this is a contiguous /16 or not. Nick From andrea at ripe.net Thu Sep 3 15:17:47 2015 From: andrea at ripe.net (Andrea Cima) Date: Thu, 3 Sep 2015 15:17:47 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <55E7073A.4000908@inex.ie> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> <55E6FE17.9020000@inex.ie> <20150902135554.GD64445@cilantro.c4inet.net> <55E7073A.4000908@inex.ie> Message-ID: <55E8487B.6050405@ripe.net> Hi Nick, On 02/09/2015 16:27, Nick Hilliard wrote: > On 02/09/2015 14:55, Sascha Luck [ml] wrote: >> Does IXP space come out of a separate pool from any other ipv4? > from what I understand, it comes out of a dedicated /16. RIPE NCC will be > able to confirm whether this is a contiguous /16 or not. 185.1.0.0/16 is the /16 reserved for IXP assignments. However, according to the RIPE-649: "/IP space returned by IXPs will be added to the reserved pool maintained for IXP use/" [1]. This means that we will also make new IXP assignments from an IP block different than 185.1.0.0/16, when re-using the "IP space returned by IXPs". [1] https://www.ripe.net/publications/docs/ripe-649#61 I hope this clarifies Andrea Cima RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Thu Sep 3 19:09:01 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 3 Sep 2015 18:09:01 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> Message-ID: <20150903170901.GE64445@cilantro.c4inet.net> On Thu, Sep 03, 2015 at 02:36:12PM +0200, Erik Bais wrote: >>A holding period for ASN16 is a material change in assignment >>policy and should be in a separate proposal, not hidden in a (in >>itself valuable) transfer policy aggregation proposal. >ASN's, it was stated in Amsterdam during the AP WG policy discussion that >leaving out transfer restrictions in the policy for ASn's was a bit too far >and it was suggested ( at the mic ) to look at almost depleted or scarce >resources to have transfer restrictions as we currently have in policy for >IPv4. By taking the wording as we have in front of us, it points out what >it means, the intention is clear ... and it will leave the policy by itself >accurate if 16 bit AS numbers have depleted .. without having to go over a >re-writing of the policy here ... Just because it was stated at the meeting doesn't mean it shouldn't be discussed here. I can't be the only one who wasn't there and doesn't know what was said there. >Both IPv6 and AS numbers have in the current policy no transfer >restrictions ... I don't see a benefit to (have it) introduce >for IPv6, but after the discussion in Amsterdam in the room, a >restriction for 16-bit ASn's was desired. And that is also why >it is currently here. This is not a 180 degree change of >direction as it would make it more in line with other number >resources .. 16-bit AS is in a similar state as IPv4.. it's >gone.. get over it .. move on .. IPv6 is the new way, same as >with 32-bit ASN's.. no restrictions.. I've not even a problem with the change, in fact I didn't register that ASNs were even transferrable until I re-read -638 just now. As for that, I think ASN(16) *should* be transferred a) only together with IP resources b) if uninterrupted routeability is required. I'm not hung up on this though, it won't affect my non-/support either way. >I don't think we have to re-hash all discussions as done in >Elvis his proposal, which was viewed by the community as >required and not strict enough as it didn't included M&A's.. That's not what I remember. I remember a few people shouting very loudly and repeatedly and no discussion as it was off-topic for that proposal. And now we don't need an actually discussion? Mind, if yelling loudly is how you get policy made in the RIPE community, rest assured I can yell VERY loudly. I can, in fact, even automate the yelling if need be. >Is anything going to change based on the proposal in order to >make do a M&A. - No. I have to, reluctantly, agree with you here but it took me a while to find the relevant text in the NCC documentation. I would sleep easier though if it was clearly spelled out in this proposal that M&A are governed by ripe-648 and not by this transfer policy. ripe-648 doesn't say this clearly either but implies it in ss. 2.0 and 3.0 >Will it remove the loophole of speculators, buying resources via >M&A and transferring those directly ? Yes. ( This is currently >possible and not in line with the original intent of the >transfer policy restrictions of the initial IPv4 transfer policy >AND the amendment to that by 2015-01.. ) It still allows someone to amass "more than their fair /22" by buying other businesses but this is something outside the purview of RIPE policy and should certainly remain so. >Business that have a legitimate reason for performing a M&A, can >still do so. The only restriction is that they can't re-transfer >( same as with new LIR now can't with the newly allocated /22's >... ) within 24 months. Just for the record, it is neither up to the NCC nor the RIPE community to decide whether a merger or an acquisition is "legitimate". >I think that by clearly pointing it out, during the discussion >as it was not questioned during the initial reviews, it shows >that it was not the intention of hiding anything ... The fact >that people may not understand what they are reading because >they don't have the complete overview of all policy implication >changes is something that we can avoid ... It is not the >intention of misleading people or trying to hide anything.. it >is the other way around .. as I specifically pointed out to >think about something that was missed. IMO, it's too easy to just look at it as a much needed and necessary aggregation of transfer policy in one document (and I hope the whole community agrees that we owe you some beer for going through the effort) and ignore the actual *changes* to the policies... >By clearly pointing out what certain text actually means and >creating an 'Ahh ha' reflex ... 'Is that what the result is ... >'. It means that people learned something they didn't knew >before.. or just realized something that they missed.. Just >like that you didn't knew that there are still specific usages >for IPv4 for which IP space is specifically reserved (in the >final /8) that are specifically excluded from the transfers .. >as they MUST be returned.. And, as it happens, the policy isn't actually very clear on this (except in the specific case of an IXP getting a larger assignment!) and may require more careful ring-fencing of the IXP pool. >I hope I gave some additional insight in the actual changes and >my reasoning behind it and as this is a policy that will create >a general document across all resources ( hopefully for a long >time to come..) it will have some changes and I hope that the >document will reflect the intention of the community from all >discussions that we already had in the past on the topics. Granted, but I'd prefer it in the future if such an aggregation would not incorporate any material changes to the policies involved (should then also pass quickly and without much debate) and any changes would then be processed in a separate proposal. I guess you realised this, as those changes are actually in the rationale *against* this proposal ;) That said, I now see no reason not to support the proposal with the addition of the statement that M&A procedure is not affected by this. rgds, Sascha Luck From apwg at c4inet.net Thu Sep 3 19:23:47 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 3 Sep 2015 18:23:47 +0100 Subject: [address-policy-wg] IXP assignments and transfers In-Reply-To: <55E8487B.6050405@ripe.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902134049.GC64445@cilantro.c4inet.net> <55E6FE17.9020000@inex.ie> <20150902135554.GD64445@cilantro.c4inet.net> <55E7073A.4000908@inex.ie> <55E8487B.6050405@ripe.net> Message-ID: <20150903172347.GF64445@cilantro.c4inet.net> On Thu, Sep 03, 2015 at 03:17:47PM +0200, Andrea Cima wrote: >185.1.0.0/16 is the /16 reserved for IXP assignments. > >However, according to the RIPE-649: "/IP space returned by IXPs will >be added to the reserved pool maintained for IXP use/" [1]. This means >that we will also make new IXP assignments from an IP block different >than 185.1.0.0/16, when re-using the "IP space returned by IXPs". > >[1] https://www.ripe.net/publications/docs/ripe-649#61 > >I hope this clarifies Thanks for the clarification, Andrea. This would support the interpretation that any assignment out of this pool is for IXP use only. -649 doesn't, though, explicitly require an IXP to return that space except in the specific case of getting a larger assignment. With all the horses biting each other over the empty cribbage like we've seen recently, it may be a good idea to state this requirement more explicitly in order to ring-fence the pool. Full disclosure: I was tangentially involved in winding up an IXP not long ago, and it was not clear to me until now that the assignment could not be transferred (even to another IXP). rgds, Sascha Luck From nick at inex.ie Thu Sep 3 19:38:46 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 3 Sep 2015 18:38:46 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <20150903170901.GE64445@cilantro.c4inet.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> <20150903170901.GE64445@cilantro.c4inet.net> Message-ID: <55E885A6.6030708@inex.ie> On 03/09/2015 18:09, Sascha Luck [ml] wrote: > Mind, if yelling loudly is how you get policy made in the RIPE > community, rest assured I can yell VERY loudly. I can, in fact, > even automate the yelling if need be. please don't: rfc7282 works much better. Nick From ggm at apnic.net Thu Sep 3 19:59:26 2015 From: ggm at apnic.net (George Michaelson) Date: Thu, 3 Sep 2015 14:59:26 -0300 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <422a56635575401b9ebad3b7ce26dccc@NXMDA2.org.apnic.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> <20150903170901.GE64445@cilantro.c4inet.net> <422a56635575401b9ebad3b7ce26dccc@NXMDA2.org.apnic.net> Message-ID: Purely as a point of information, I think its worth remembering that 32 bit ASN cannot be used in currently specified BGP4 in communities, because its a 32 bit field defined as two 16 bit halves. I believe there is work afoot in IETF to fix this. I don't have concrete details. Therefore there *is* a quality in 16 bit ASN which may be divorced from its association with specific V4 or V6 resources and which makes it a desirable thing, in itself, for some people: If you are in the business of doing TE in BGP with communities, you can't do it with 32 bit ASN. You have to use other mechanisms. On that basis, Should you permit transfers of ASN, you might wish to permit transfers of ASN independently of any associated routable IP address space: people who already have space but need a 16 bit ASN may wish to acquire one. I'm not an asset holder in the RIPE region, and I am staff at another RIR, so I stress this is purely informational. I'm not trying to directly advocate for or against ASN transfers. -George On 3 September 2015 at 14:38, Nick Hilliard wrote: > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > Mind, if yelling loudly is how you get policy made in the RIPE > > community, rest assured I can yell VERY loudly. I can, in fact, > > even automate the yelling if need be. > > please don't: rfc7282 works much better. > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Thu Sep 3 20:49:12 2015 From: nick at inex.ie (Nick Hilliard) Date: Thu, 3 Sep 2015 19:49:12 +0100 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> <20150903170901.GE64445@cilantro.c4inet.net> <422a56635575401b9ebad3b7ce26dccc@NXMDA2.org.apnic.net> Message-ID: <55E89628.60307@inex.ie> This has come up several times before. There is support for asn32s in bgp extended communities: you need the "Transitive Four-Octet AS-Specific Extended Community" values from here: http://www.iana.org/assignments/bgp-extended-communities ... and you need to hope that this is supported on your router software. And everyone else's that you plan to talk to. This can work in some situations where you have tight control over the entire management plane of everywhere you plan to export these communities to, but the internet at large is going to have a lot more difficulty with it. As you point out, you can only support 16b:32b or 32b:16b style communities with the current community mechanism, not 32b:32b communities. The latter will require implementation of draft-ietf-idr-wide-bgp-communities. So if you have any requirement for 32b:32b communities, you're out of luck. Nick On 03/09/2015 18:59, George Michaelson wrote: > Purely as a point of information, I think its worth remembering that 32 bit > ASN cannot be used in currently specified BGP4 in communities, because its > a 32 bit field defined as two 16 bit halves. I believe there is work afoot > in IETF to fix this. I don't have concrete details. > > Therefore there *is* a quality in 16 bit ASN which may be divorced from its > association with specific V4 or V6 resources and which makes it a desirable > thing, in itself, for some people: If you are in the business of doing TE > in BGP with communities, you can't do it with 32 bit ASN. You have to use > other mechanisms. > > On that basis, Should you permit transfers of ASN, you might wish to permit > transfers of ASN independently of any associated routable IP address space: > people who already have space but need a 16 bit ASN may wish to acquire one. > > I'm not an asset holder in the RIPE region, and I am staff at another RIR, > so I stress this is purely informational. I'm not trying to directly > advocate for or against ASN transfers. > > -George > > On 3 September 2015 at 14:38, Nick Hilliard > wrote: > > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > Mind, if yelling loudly is how you get policy made in the RIPE > > community, rest assured I can yell VERY loudly. I can, in fact, > > even automate the yelling if need be. > > please don't: rfc7282 works much better. > > Nick > From ggm at apnic.net Thu Sep 3 21:22:55 2015 From: ggm at apnic.net (George Michaelson) Date: Thu, 3 Sep 2015 16:22:55 -0300 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: <320e22990d1c4614856bf75725db4148@NXMDA2.org.apnic.net> References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> <20150903170901.GE64445@cilantro.c4inet.net> <422a56635575401b9ebad3b7ce26dccc@NXMDA2.org.apnic.net> <320e22990d1c4614856bf75725db4148@NXMDA2.org.apnic.net> Message-ID: Right. I mussed up some details. The substance remains: if you are exposed to economics which depends on the use of communities for TE, and cannot influence external agents you do BGP with to support extended communities, then you may decide you need a 16bit ASN, and so they have inherent value to you, distinct from any other resources potentially in transfer. You aren't looking to acquire active IPv4, or IPv6, you are looking to acquire a 16 bit ASN as a thing in itself. -G On 3 September 2015 at 15:49, Nick Hilliard wrote: > This has come up several times before. There is support for asn32s in bgp > extended communities: you need the "Transitive Four-Octet AS-Specific > Extended Community" values from here: > > http://www.iana.org/assignments/bgp-extended-communities > > ... and you need to hope that this is supported on your router software. > And everyone else's that you plan to talk to. > > This can work in some situations where you have tight control over the > entire management plane of everywhere you plan to export these communities > to, but the internet at large is going to have a lot more difficulty with > it. > > As you point out, you can only support 16b:32b or 32b:16b style communities > with the current community mechanism, not 32b:32b communities. The latter > will require implementation of draft-ietf-idr-wide-bgp-communities. > > So if you have any requirement for 32b:32b communities, you're out of luck. > > Nick > > On 03/09/2015 18:59, George Michaelson wrote: > > Purely as a point of information, I think its worth remembering that 32 > bit > > ASN cannot be used in currently specified BGP4 in communities, because > its > > a 32 bit field defined as two 16 bit halves. I believe there is work > afoot > > in IETF to fix this. I don't have concrete details. > > > > Therefore there *is* a quality in 16 bit ASN which may be divorced from > its > > association with specific V4 or V6 resources and which makes it a > desirable > > thing, in itself, for some people: If you are in the business of doing TE > > in BGP with communities, you can't do it with 32 bit ASN. You have to use > > other mechanisms. > > > > On that basis, Should you permit transfers of ASN, you might wish to > permit > > transfers of ASN independently of any associated routable IP address > space: > > people who already have space but need a 16 bit ASN may wish to acquire > one. > > > > I'm not an asset holder in the RIPE region, and I am staff at another > RIR, > > so I stress this is purely informational. I'm not trying to directly > > advocate for or against ASN transfers. > > > > -George > > > > On 3 September 2015 at 14:38, Nick Hilliard > > wrote: > > > > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > > Mind, if yelling loudly is how you get policy made in the RIPE > > > community, rest assured I can yell VERY loudly. I can, in fact, > > > even automate the yelling if need be. > > > > please don't: rfc7282 works much better. > > > > Nick > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Thu Sep 3 23:46:10 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Thu, 3 Sep 2015 23:46:10 +0200 Subject: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) In-Reply-To: References: <55E4C581.9060605@inex.ie> <002f01d0e506$cbd89e40$6389dac0$@a2b-internet.com> <20150902130211.GB64445@cilantro.c4inet.net> <009101d0e645$233cbf60$69b63e20$@a2b-internet.com> <20150903170901.GE64445@cilantro.c4inet.net> <422a56635575401b9ebad3b7ce26dccc@NXMDA2.org.apnic.net> <320e22990d1c4614856bf75725db4148@NXMDA2.org.apnic.net> Message-ID: Hi George, AS number can be transferred in the RIPE region. https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/asn As 16-bit AS numbers are close to being depleted and to avoid speculations, it was suggested during the discussion to fix the fact that there are no transfer restrictions ( like a 24 month waiting period) in the proposal for at least the 16-bit AS numbers. So it is possible to transfer a 16-bit AS number, but for the second transfer, you need to wait 24 months. This proposal is introducing that specific part, which will bring it at the same level as IPv4. The other scarce number resource ... The reason why 'scarce resource' was used in the proposal and NOT depleted, comes from the experience that policy makers have in LACNIC, where a transfer policy was writted about a depleted resource ... But as LACNIC is still handing out /22's similar as RIPE is to new LIR's ... Technically, it is not depleted .. As they still have it ... So there the specific transfer policy couldn't be activated ... Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 3 sep. 2015 om 21:22 heeft George Michaelson het volgende geschreven: > > Right. I mussed up some details. The substance remains: if you are exposed to economics which depends on the use of communities for TE, and cannot influence external agents you do BGP with to support extended communities, then you may decide you need a 16bit ASN, and so they have inherent value to you, distinct from any other resources potentially in transfer. You aren't looking to acquire active IPv4, or IPv6, you are looking to acquire a 16 bit ASN as a thing in itself. > > -G > >> On 3 September 2015 at 15:49, Nick Hilliard wrote: >> This has come up several times before. There is support for asn32s in bgp >> extended communities: you need the "Transitive Four-Octet AS-Specific >> Extended Community" values from here: >> >> http://www.iana.org/assignments/bgp-extended-communities >> >> ... and you need to hope that this is supported on your router software. >> And everyone else's that you plan to talk to. >> >> This can work in some situations where you have tight control over the >> entire management plane of everywhere you plan to export these communities >> to, but the internet at large is going to have a lot more difficulty with it. >> >> As you point out, you can only support 16b:32b or 32b:16b style communities >> with the current community mechanism, not 32b:32b communities. The latter >> will require implementation of draft-ietf-idr-wide-bgp-communities. >> >> So if you have any requirement for 32b:32b communities, you're out of luck. >> >> Nick >> >> On 03/09/2015 18:59, George Michaelson wrote: >> > Purely as a point of information, I think its worth remembering that 32 bit >> > ASN cannot be used in currently specified BGP4 in communities, because its >> > a 32 bit field defined as two 16 bit halves. I believe there is work afoot >> > in IETF to fix this. I don't have concrete details. >> > >> > Therefore there *is* a quality in 16 bit ASN which may be divorced from its >> > association with specific V4 or V6 resources and which makes it a desirable >> > thing, in itself, for some people: If you are in the business of doing TE >> > in BGP with communities, you can't do it with 32 bit ASN. You have to use >> > other mechanisms. >> > >> > On that basis, Should you permit transfers of ASN, you might wish to permit >> > transfers of ASN independently of any associated routable IP address space: >> > people who already have space but need a 16 bit ASN may wish to acquire one. >> > >> > I'm not an asset holder in the RIPE region, and I am staff at another RIR, >> > so I stress this is purely informational. I'm not trying to directly >> > advocate for or against ASN transfers. >> > >> > -George >> > >> > On 3 September 2015 at 14:38, Nick Hilliard > > > wrote: >> > >> > On 03/09/2015 18:09, Sascha Luck [ml] wrote: >> > > Mind, if yelling loudly is how you get policy made in the RIPE >> > > community, rest assured I can yell VERY loudly. I can, in fact, >> > > even automate the yelling if need be. >> > >> > please don't: rfc7282 works much better. >> > >> > Nick >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 09:17:04 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 09:17:04 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP Message-ID: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Hello everybody, Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Before submitting the proposal we would like to have some community feedback on several aspects : 1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool 2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail) 3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ??? We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month. The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :) Regards, -- Radu-Adrian FEURDEAN fr.ccs From swmike at swm.pp.se Mon Sep 14 09:33:58 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 14 Sep 2015 09:33:58 +0200 (CEST) Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: On Mon, 14 Sep 2015, Radu-Adrian FEURDEAN wrote: > Hello everybody, > > Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 > allocation policy ( > https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Interesting presentation. There are some points there I was no aware of. I would be interested in getting an educated guess what would happen if we went with the following policy: You get /20 to /24 depending on need/want instead of /22 for everybody. This would apply until we have last-/10 where we then go to /22-/24 depending on need/want. We would treat recovered pool the same as last /8, it's just treated as "addresses" so /10 is "/10 worth of adresses". My goal is still to have IPv4 addresses according to this policy by 2020. -- Mikael Abrahamsson email: swmike at swm.pp.se From aleksbulgakov at gmail.com Mon Sep 14 09:36:22 2015 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Mon, 14 Sep 2015 10:36:22 +0300 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: Hi to all. 2015-01 has been approved to prevent IPv4 exhaustion (Elvis was an author). And you suggest to allocate additional blocks now. As told some stuffs from the IPRA, here is the conflict, isn't it? This case community has to cancel 2015-01. 14 ????. 2015 ?. 10:17 ???????????? "Radu-Adrian FEURDEAN" < ripe-wgs at radu-adrian.feurdean.net> ???????: > Hello everybody, > > Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 > allocation policy ( > https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) > > Before submitting the proposal we would like to have some community > feedback on several aspects : > > 1. Separate pools or single pool > a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per > LIR) and a "recovered space pool" containing all space received from > IANA as "recovered and redistributed space" (for extra allocations) - > APNIC-like separation of pools > b. treat all addressing space available for allocation as a single > pool > > 2. Conditions for allocation the first /22. > - none (keep the situation as it is today - our preferred option) > - something else (please detail) > > 3. Further allocation(s) (after the first /22) > 3.1 introduce some minimum delay after the last allocation : 12 months > (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less > ? None ? > 3.1.1 Does that mean one can get a new allocation every X months > (LACNIC-style) while the stock lasts ? > 3.2 Allocation size : /22 ? /23 ? variable depending on how much is > available at the time of allocation, max /22, min /24 (which does imply > a little more policy text in order to detail this) ? > 3.3 Additional conditions > 3.3.1 "LIR did not perform an outbound transfer" (do you think it > would make sense to have this condition for the first allocation too) > ? > 3.3.2 Other conditions ??? > > We (me and Elvis) would like to hear your opinion (on the list or in > private) on those subjects in order to be able to submit a (we hope > stable) policy proposal before the end of the month. > > The arguments for each change in the policy will come at that moment > (with the policy itself), and yes, we do have arguments for each option > presented here :) > > Regards, > -- > Radu-Adrian FEURDEAN > fr.ccs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Sep 14 09:51:01 2015 From: gert at space.net (Gert Doering) Date: Mon, 14 Sep 2015 09:51:01 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <20150914075101.GK84167@Space.Net> Hi, On Mon, Sep 14, 2015 at 10:36:22AM +0300, Aleksey Bulgakov wrote: > 2015-01 has been approved to prevent IPv4 exhaustion Mostly to prevent policy abuse. IPv4 exhaustion is inevitable. 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 tore at fud.no Mon Sep 14 10:03:16 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 14 Sep 2015 10:03:16 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> * "Radu-Adrian FEURDEAN" > 1. Separate pools or single pool > a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per > LIR) and a "recovered space pool" containing all space received from > IANA as "recovered and redistributed space" (for extra allocations) - > APNIC-like separation of pools > b. treat all addressing space available for allocation as a single > pool B. KISS. > 2. Conditions for allocation the first /22. > - none (keep the situation as it is today - our preferred option) > - something else (please detail) Maintain the status quo. > 3. Further allocation(s) (after the first /22) > 3.1 introduce some minimum delay after the last allocation : 12 months > (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less > ? None ? > 3.1.1 Does that mean one can get a new allocation every X months > (LACNIC-style) while the stock lasts ? > 3.2 Allocation size : /22 ? /23 ? variable depending on how much is > available at the time of allocation, max /22, min /24 (which does imply > a little more policy text in order to detail this) ? > 3.3 Additional conditions > 3.3.1 "LIR did not perform an outbound transfer" (do you think it > would make sense to have this condition for the first allocation too) > ? > 3.3.2 Other conditions ??? None of the above. My preference is to maintain the status quo - no additional allocations. I do not quite see why we should change the ?last /8? policy which in my view has been quite successful (except for the abuse that 2015-01 hopefully helps shut down). If it ain't broke, don't fix it? Unless we interpret ?broke? to mean ?exhausted?. If so, c'est la vie. Tore From richih.mailinglist at gmail.com Mon Sep 14 10:14:39 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 14 Sep 2015 10:14:39 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN wrote: > 1. Separate pools or single pool > a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per > LIR) and a "recovered space pool" containing all space received from > IANA as "recovered and redistributed space" (for extra allocations) - > APNIC-like separation of pools > b. treat all addressing space available for allocation as a single > pool The only reason I can see is to keep the unused, continuous blocks in 185.0.0.0/8 if we ever need them for something else and thus try to get rid of the recovered pool first. > 2. Conditions for allocation the first /22. > - none (keep the situation as it is today - our preferred option) > - something else (please detail) "First"? This already implies a change afaict. > 3. Further allocation(s) (after the first /22) > 3.1 introduce some minimum delay after the last allocation : 12 months > (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less > ? None ? > 3.1.1 Does that mean one can get a new allocation every X months > (LACNIC-style) while the stock lasts ? > 3.2 Allocation size : /22 ? /23 ? variable depending on how much is > available at the time of allocation, max /22, min /24 (which does imply > a little more policy text in order to detail this) ? > 3.3 Additional conditions > 3.3.1 "LIR did not perform an outbound transfer" (do you think it > would make sense to have this condition for the first allocation too) > ? > 3.3.2 Other conditions ??? Why change it? This means that everyone will optimize for the maximum size in whatever way they can. And that's without the "I only got /n+1, while foo got /n, that's unfair" and the much-beloved "/n is not enough; let's increase to /n-1 as we already did once" (once==the proposal in this thread). If people want to get something longer than a /22, that might be a valid use case, but I am not convinced there will be enough to merit a pdp for this. Point in case: I helped an entity to become a LIR as they needed one /24. Within two months, they had an actual, valid use case for a second /24. If I had gotten them a /24 instead of a /22, we would then have had to jump through the hoops again. That's why a flat "no need, just /22" policy makes it simpler; even if it's wasteful in some cases. Richard From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 10:41:44 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 10:41:44 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> Message-ID: <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote: > > b. treat all addressing space available for allocation as a single pool > B. KISS. > > > 2. Conditions for allocation the first /22. > Maintain the status quo. Point taken. > > 3. Further allocation(s) (after the first /22) > None of the above. My preference is to maintain the status quo - no > additional allocations. I do not quite see why we should change the > ?last /8? policy which in my view has been quite successful (except for > the abuse that 2015-01 hopefully helps shut down). > > If it ain't broke, don't fix it? > > Unless we interpret ?broke? to mean ?exhausted?. If so, c'est la vie. I take "broken" as "painful and far enough from exhaustion", so in need of a fix. Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and RIPE still has more than 0.98 of a /8 available (more likely 0.99). From richih.mailinglist at gmail.com Mon Sep 14 10:54:49 2015 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 14 Sep 2015 10:54:49 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> Message-ID: On Mon, Sep 14, 2015 at 10:41 AM, Radu-Adrian FEURDEAN wrote: > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and > RIPE still has more than 0.98 of a /8 available (more likely 0.99). Is this a problem? > I take "broken" as "painful and far enough from exhaustion", so in need > of a fix. So you will need two policy changes: One to increase run-out speed and one to decrease it again. Or would you introduce another run-out mechanism for "last /8+n" within that proposal? Very much unconvinced, Richard From phessler at theapt.org Mon Sep 14 10:51:26 2015 From: phessler at theapt.org (Peter Hessler) Date: Mon, 14 Sep 2015 10:51:26 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> Message-ID: <20150914085126.GX10728@gir.theapt.org> On 2015 Sep 14 (Mon) at 10:41:44 +0200 (+0200), Radu-Adrian FEURDEAN wrote: :On Mon, Sep 14, 2015, at 10:03, Tore Anderson wrote: :> > 3. Further allocation(s) (after the first /22) :> None of the above. My preference is to maintain the status quo - no :> additional allocations. I do not quite see why we should change the :> ??last /8?? policy which in my view has been quite successful (except for :> the abuse that 2015-01 hopefully helps shut down). :> :> If it ain't broke, don't fix it? :> :> Unless we interpret ??broke?? to mean ??exhausted??. If so, c'est la vie. : :I take "broken" as "painful and far enough from exhaustion", so in need :of a fix. :Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and :RIPE still has more than 0.98 of a /8 available (more likely 0.99). : At my previous company, we joined RIPE as a LIR specifically because there was no other way to get our own IPv4 address space. As a smaller orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ to provide serivces to our users. I support the existing policy, and are very concerned with any proposal that would encourage faster exhaustion of the IPv4 space. I respectfully disagree with the assertion that the existing last /8 policy is painful for everyone.e From tore at fud.no Mon Sep 14 11:09:21 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 14 Sep 2015 11:09:21 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> Message-ID: <20150914110921.1741de54@echo.ms.redpill-linpro.com> * "Radu-Adrian FEURDEAN" > > > 3. Further allocation(s) (after the first /22) > > None of the above. My preference is to maintain the status quo - no > > additional allocations. I do not quite see why we should change the > > ?last /8? policy which in my view has been quite successful (except for > > the abuse that 2015-01 hopefully helps shut down). > > > > If it ain't broke, don't fix it? > > > > Unless we interpret ?broke? to mean ?exhausted?. If so, c'est la vie. > > I take "broken" as "painful and far enough from exhaustion", so in need > of a fix. Is there any urgency in getting closer to full exhaustion (i.e., no remaining austerity pool)? Is full exhaustion somehow less painful than the current status quo? I guess we can look at the ARIN region, as they'll reach that point in the coming weeks. If that situation turns out to benefit their community somehow (like increasing the IPv6 deployment rate), I'm willing to be persuaded that we should open the floodgates and get rid of our austerity pool ASAP. I'm sceptical this will be the case, though. > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and > RIPE still has more than 0.98 of a /8 available (more likely 0.99). And those three years we've delegated just shy of a /9: http://www.potaroo.net/tools/ipv4/plotend.png Also, keep in mind that the IANA IPv4 Recovered Address Space pool, which so far has provided the majority (~4M) of the "new" IPv4 addresses added to the austerity pool since the "last /8" policy was implemented, has pretty much dried up. There are currently only 163,481 addresses remaining in that pool earmarked to be delegated to the NCC. In summary I don't think that we can open the faucet any more than it currently is if we want to be able to give IPv4 for new entrants in 2020. Tore From stolpe at resilans.se Mon Sep 14 11:12:59 2015 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 14 Sep 2015 11:12:59 +0200 (CEST) Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: On Mon, 14 Sep 2015, Radu-Adrian FEURDEAN wrote: > Hello everybody, > > Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 > allocation policy ( > https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) > > Before submitting the proposal we would like to have some community > feedback on several aspects : > > 1. Separate pools or single pool > a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per > LIR) and a "recovered space pool" containing all space received from > IANA as "recovered and redistributed space" (for extra allocations) - > APNIC-like separation of pools > b. treat all addressing space available for allocation as a single > pool This is the only part I find - and always found - a bit strange. I guess it does probably not make a lot of differense in practice, anyone knows the actual size of the "recovered pool"? As the policy was written, once we hit the "last /8" stage there was no going back. Even if we for some reason would recover a lot more or start delegating E class or whaterver. I think it would be more logical to define the "last /8" as the actual last /8 (185/8). People sometimes ask us whether to return unused address space to the RIPE NCC and we always tell them not to because the free pool has become a black hole. But as/if the recovered pool is probably comparatively small, it is not a big issue. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 11:13:46 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 11:13:46 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <1442222026.121613.382886833.5306776F@webmail.messagingengine.com> On Mon, Sep 14, 2015, at 09:36, Aleksey Bulgakov wrote: > Hi to all. > > 2015-01 has been approved to prevent IPv4 exhaustion (Elvis was an Hello, More to prevent abuse. Today we "celebrate" 3 years into exhaustion and the only thing that can be done is make sure things are less painful until we get rid of the "need for IPv4" by having a fully workable IPv6 Internet (for the moment we don't). > author). And you suggest to allocate additional blocks now. As told some > stuffs from the IPRA, here is the conflict, isn't it? I'm not a broker and not in the transfer business (not at all for now, and if I ever will, it's highly unlikely for me to be on anything other than the receiving side). So I don't see any conflict. Regards, -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 11:38:10 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 11:38:10 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <20150914110921.1741de54@echo.ms.redpill-linpro.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> <20150914110921.1741de54@echo.ms.redpill-linpro.com> Message-ID: <1442223490.126477.382900809.2A6FDD92@webmail.messagingengine.com> On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote: > * "Radu-Adrian FEURDEAN" > > I take "broken" as "painful and far enough from exhaustion", so in need > > of a fix. > > Is there any urgency in getting closer to full exhaustion (i.e., no > remaining austerity pool)? Is full exhaustion somehow less painful than > the current status quo? > > I guess we can look at the ARIN region, as they'll reach that point in > the coming weeks. If that situation turns out to benefit their > community somehow (like increasing the IPv6 deployment rate), I'm > willing to be persuaded that we should open the floodgates and get rid > of our austerity pool ASAP. I'm sceptical this will be the case, though. I do think that it will push towards more serious IPv6 deployment (beyond "get the /29 or /32, announce it into the GRT, deployment successful"). > > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and > > RIPE still has more than 0.98 of a /8 available (more likely 0.99). > > And those three years we've delegated just shy of a /9: Which makes the "austerity pool" (I would rather call it "waste pool") available for about 5-6 more years. > implemented, has pretty much dried up. There are currently only 163,481 > addresses remaining in that pool earmarked to be delegated to the NCC. I am fully aware of that. > In summary I don't think that we can open the faucet any more than it > currently is if we want to be able to give IPv4 for new entrants in > 2020. If needed, we can revise things in another 3 years. -- Radu-Adrian FEURDEAN fr.ccs From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 12:14:06 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 12:14:06 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <1442225646.133891.382930633.4DBF71F9@webmail.messagingengine.com> On Mon, Sep 14, 2015, at 09:33, Mikael Abrahamsson wrote: > I would be interested in getting an educated guess what would happen if > we went with the following policy: > > You get /20 to /24 depending on need/want instead of /22 for everybody. > > This would apply until we have last-/10 where we then go to /22-/24 > depending on need/want. We would treat recovered pool the same as last > /8, it's just treated as "addresses" so /10 is "/10 worth of adresses". Point taken and thanks for the feedback. Good to see some people looking at more than /22 in one shot. > My goal is still to have IPv4 addresses according to this policy by 2020. :) -- Radu-Adrian FEURDEAN fr.ccs From arash_mpc at parsun.com Mon Sep 14 12:16:58 2015 From: arash_mpc at parsun.com (Arash Naderpour) Date: Mon, 14 Sep 2015 20:16:58 +1000 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <011801d0eed6$7fc25a80$7f470f80$@parsun.com> Hi, 1. separate pool and APNIC-like distribution of additional blocks from recoved space pool 2. no conditions for first /22 allocation, the goal is distribution of resources and I can't see any benefit by adding this restriction 3.3.1 I don't think this one is a fair one: "LIR did not perform an outbound transfer" I'm also thinking to prepare a proposal to remove current 24month transfer wait period (or adjust it), IPs should be transferred easily for a better utilization and really like to see the community feedback on your proposal. Regards, Arash Naderpour -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Radu-Adrian FEURDEAN Sent: Monday, September 14, 2015 5:17 PM To: address-policy-wg at ripe.net Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP Hello everybody, Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Before submitting the proposal we would like to have some community feedback on several aspects : 1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool 2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail) 3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ??? We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month. The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :) Regards, -- Radu-Adrian FEURDEAN fr.ccs From tore at fud.no Mon Sep 14 12:33:17 2015 From: tore at fud.no (Tore Anderson) Date: Mon, 14 Sep 2015 12:33:17 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442223490.126477.382900809.2A6FDD92@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> <20150914110921.1741de54@echo.ms.redpill-linpro.com> <1442223490.126477.382900809.2A6FDD92@webmail.messagingengine.com> Message-ID: <20150914123317.34ff5433@echo.ms.redpill-linpro.com> * "Radu-Adrian FEURDEAN" > On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote: > > Is there any urgency in getting closer to full exhaustion (i.e., no > > remaining austerity pool)? Is full exhaustion somehow less painful than > > the current status quo? > > > > I guess we can look at the ARIN region, as they'll reach that point in > > the coming weeks. If that situation turns out to benefit their > > community somehow (like increasing the IPv6 deployment rate), I'm > > willing to be persuaded that we should open the floodgates and get rid > > of our austerity pool ASAP. I'm sceptical this will be the case, though. > > I do think that it will push towards more serious IPv6 deployment > (beyond "get the /29 or /32, announce it into the GRT, deployment > successful"). If your goal is to get rid of the IPv4 austerity pool as quickly as possible, that could be accomplished much more quickly and efficiently than creating a "side pool" with associated rules for allocation. Some possibilities: * Re-instate additional allocations with "needs basis" and it'll be gone in a few weeks * Return everything to IANA and decline further allocations from the Recovery pool * Divide it up equally between all members and allocate everything at once * Divide it up between all members based on the current amount of IPv4 addresses held and allocate everything at once * Divide it up equally between all members holding a five-star RIPENess rating and allocate it all at once * Auction it all off to the highest bidder(s), use proceeds to reduce membership fees, give a cash return to members, or donate it to charity IFF it could be demonstrated clearly that it would help further IPv6 deployment, I'd be willing to be persuaded into supporting a policy proposal which leads to the rapid depletion of the austerity pool, thus bringing us in line with ARIN. Regarding the side pool idea specifically, an interesting post appeared today on APNIC's policy list, which had the following to say about their side pool: ?2. Status of IANA Recovered pool (non-103) - Will run out in next 7 months+ - IANA may allocate additional space in every 6 months - This pool will repeatedly ?run-out? as IANA delegates more space and it is distributed by APNIC? http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/09/msg00025.html I don't think duplicating this in our region would be helpful at all. > > > Reminder, we are 3 years (precisely) into the "last /8 IPocalypse", and > > > RIPE still has more than 0.98 of a /8 available (more likely 0.99). > > > > And those three years we've delegated just shy of a /9: > > Which makes the "austerity pool" (I would rather call it "waste pool") > available for about 5-6 more years. In my opinion that would the optimal outcome, and precisely the reason why I do not support creating a side austerity pool or changing the allocation criteria for the main austerity pool at this point in time. Tore From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 12:38:14 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 12:38:14 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <20150914085126.GX10728@gir.theapt.org> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> <20150914085126.GX10728@gir.theapt.org> Message-ID: <1442227094.138878.382951593.7209D970@webmail.messagingengine.com> On Mon, Sep 14, 2015, at 10:51, Peter Hessler wrote: > At my previous company, we joined RIPE as a LIR specifically because > there was no other way to get our own IPv4 address space. As a smaller > orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ > to provide serivces to our users. This is pretty much the situation at my present company. > I support the existing policy, and are very concerned with any proposal > that would encourage faster exhaustion of the IPv4 space. > > I respectfully disagree with the assertion that the existing last /8 > policy is painful for everyone.e It depends : if you need more than a /22 it is (very) painful, if you don't - it's not. And don't forget that some people are still arguing that the last /8 policy is to be used as a workaround until IPv6 becomes a useful option. Unfortunately, with the current stocks of available addresses, for a lot of people it doesn't work this way. -- Radu-Adrian FEURDEAN fr.ccs From sander at steffann.nl Mon Sep 14 13:17:59 2015 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Sep 2015 13:17:59 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: Hi, > 3. Further allocation(s) (after the first /22) > 3.1 introduce some minimum delay after the last allocation : 12 months > (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less > ? None ? > 3.1.1 Does that mean one can get a new allocation every X months > (LACNIC-style) while the stock lasts ? While I like this idea, please do realise that a /8 has 16384 /22s in it. RIPE NCC has more than 12000 LIRs at the moment. Many of those would already qualify for an additional allocation based on this. That could drain the pool in a very short time... > 3.2 Allocation size : /22 ? /23 ? variable depending on how much is > available at the time of allocation, max /22, min /24 (which does imply > a little more policy text in order to detail this) ? Re-introducing different allocation sizes would also mean going back to a needs-based system. I'm not sure we want to add that overhead/bureaucracy again. A lot of people were quite happy with 2013-03. Changing the size to a /24 for further allocations would extend the lifetime of the pool, but on the other hand I'm not sure if handing them a /24 every x months will really help many LIRs, and the routing overhead will be a lot more interesting... So while I am happy to see work being done on this, I am still a bit cautious. But I'd love to be shown wrong :) Cheers, Sander From phessler at theapt.org Mon Sep 14 13:49:30 2015 From: phessler at theapt.org (Peter Hessler) Date: Mon, 14 Sep 2015 13:49:30 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442227094.138878.382951593.7209D970@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914100316.6a5d6aac@echo.ms.redpill-linpro.com> <1442220104.114973.382863025.7DBD64AD@webmail.messagingengine.com> <20150914085126.GX10728@gir.theapt.org> <1442227094.138878.382951593.7209D970@webmail.messagingengine.com> Message-ID: <20150914114930.GY10728@gir.theapt.org> On 2015 Sep 14 (Mon) at 12:38:14 +0200 (+0200), Radu-Adrian FEURDEAN wrote: :On Mon, Sep 14, 2015, at 10:51, Peter Hessler wrote: : :> At my previous company, we joined RIPE as a LIR specifically because :> there was no other way to get our own IPv4 address space. As a smaller :> orginazation, we NEEDED to get our own IPv4 space to be multi-homed _and_ :> to provide serivces to our users. : :This is pretty much the situation at my present company. : We had zero IPs. And needed ANY, to provide services. Even eight would have been (barely) enough in an emergency. Obviously, RIPE doesn't want to be giving out /29s to everyone that needs to have their own space. Does your service require substantially more than 1024 IPv4 addresses? This adjustment would punish those that only need one, to handle cases where people want more. :> I support the existing policy, and are very concerned with any proposal :> that would encourage faster exhaustion of the IPv4 space. :> :> I respectfully disagree with the assertion that the existing last /8 :> policy is painful for everyone.e : :It depends : if you need more than a /22 it is (very) painful, if you :don't - it's not. Since I was in that situation before, I am very concerned about the smaller players. For each /20 handed out, that is 4 small players that are denied. This, imho, would be a serious disservice to the community at large. :And don't forget that some people are still arguing that the last /8 :policy is to be used as a workaround until IPv6 becomes a useful option. :Unfortunately, with the current stocks of available addresses, for a lot :of people it doesn't work this way. : :-- :Radu-Adrian FEURDEAN :fr.ccs From apwg at c4inet.net Mon Sep 14 15:09:09 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 14 Sep 2015 14:09:09 +0100 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <20150914130909.GG64445@cilantro.c4inet.net> On Mon, Sep 14, 2015 at 09:17:04AM +0200, Radu-Adrian FEURDEAN wrote: >Before submitting the proposal we would like to have some community >feedback on several aspects : My thoughts: 1) anything that increases the bureaucracy required to deal with the NCC for a first allocation is a non-goer. 2) I could live with giving a LIR which has only received an "austerity /22" another shot after a certain time, but I'd couple it with some proof of ipv6 deployment (beyond just advertising a /32) 3) The edge case of a LIR not needing the full /22 can be handled by the transfer market. If you still think you don't need the other three /24s after 24 months, sell them. rgds, Sascha Luck From ripe-wgs.cs at schiefner.de Mon Sep 14 15:32:47 2015 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 14 Sep 2015 15:32:47 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> Message-ID: <55F6CC7F.4030603@schiefner.de> Richard, all - On 14.09.2015 10:14, Richard Hartmann wrote: > On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN > wrote: > >> 1. Separate pools or single pool >> a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per >> LIR) and a "recovered space pool" containing all space received from >> IANA as "recovered and redistributed space" (for extra allocations) - >> APNIC-like separation of pools >> b. treat all addressing space available for allocation as a single >> pool > > The only reason I can see is to keep the unused, continuous blocks in > 185.0.0.0/8 if we ever need them for something else and thus try to > get rid of the recovered pool first. how about combining this by treating all addresses equal in a single pool, but advising the NCC to hand out recovered addresses first unless there are specific, yet-to-be-defined reasons that they rather need to come from the 185/8 heap? Cheers, -C. From ripe-wgs at radu-adrian.feurdean.net Mon Sep 14 15:49:24 2015 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 14 Sep 2015 15:49:24 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <20150914130909.GG64445@cilantro.c4inet.net> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914130909.GG64445@cilantro.c4inet.net> Message-ID: <1442238564.179861.383108945.60FF6BFB@webmail.messagingengine.com> On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote: > 1) anything that increases the bureaucracy required to deal with > the NCC for a first allocation is a non-goer. > > 2) I could live with giving a LIR which has only received an > "austerity /22" another shot after a certain time, but I'd couple > it with some proof of ipv6 deployment (beyond just advertising a > /32) If you have some ideas of how to reliably determine "real ipv6 deployment" *AND* write down that criteria in a policy-friendly way, you're welcome (want to be part of the proposal ? - ok). -- Radu-Adrian FEURDEAN fr.ccs From apwg at c4inet.net Mon Sep 14 16:39:14 2015 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 14 Sep 2015 15:39:14 +0100 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <1442238564.179861.383108945.60FF6BFB@webmail.messagingengine.com> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914130909.GG64445@cilantro.c4inet.net> <1442238564.179861.383108945.60FF6BFB@webmail.messagingengine.com> Message-ID: <20150914143914.GH64445@cilantro.c4inet.net> On Mon, Sep 14, 2015 at 03:49:24PM +0200, Radu-Adrian FEURDEAN wrote: >On Mon, Sep 14, 2015, at 15:09, Sascha Luck [ml] wrote: > >If you have some ideas of how to reliably determine "real ipv6 >deployment" *AND* write down that criteria in a policy-friendly way, >you're welcome (want to be part of the proposal ? - ok). I know that it's not likely we could come up with something that is 100% reliable. I was thinking along the lines of a statement in the allocation request like: "We have deployed IPv6 to our customers and we are using $technology to do it." combined with a mini-audit focusing on ipv6 assignments. I know this could be gamed but it may serve as a gentle nudge in the direction of at least making *some* effort towards ipv6 deployment. rgds, Sascha Luck From millnert at gmail.com Tue Sep 15 19:38:02 2015 From: millnert at gmail.com (Martin Millnert) Date: Tue, 15 Sep 2015 19:38:02 +0200 Subject: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP In-Reply-To: <20150914075101.GK84167@Space.Net> References: <1442215024.1227599.382798945.78B2D4BD@webmail.messagingengine.com> <20150914075101.GK84167@Space.Net> Message-ID: <1442338682.17251.41.camel@gmail.com> On Mon, 2015-09-14 at 09:51 +0200, Gert Doering wrote: > IPv4 exhaustion is inevitable. s/is inevitable/has already occured/g IPv4 is by any practical standard; bankrupt. /M - almost out of popcorns From ebais at a2b-internet.com Wed Sep 16 10:46:36 2015 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 16 Sep 2015 10:46:36 +0200 Subject: [address-policy-wg] Discussion phase .. 2015-04 New Policy Proposal (RIPE Resource Transfer Policies) Message-ID: <007c01d0f05c$35e3e690$a1abb3b0$@a2b-internet.com> Dear all, The initial discussion phase of the proposal has passed .. however I would like to extend it to allow some additional time for people to provide insight or feedback and questions to the end of next week ( Sept. 25 2015 ). I?ll work with the NCC in the timing to see if we can get the Impact Analyses done before the Bucharest RIPE meeting. So if you have not read the proposal, please have a look at it.. If you have additional insight or questions about it, please let me know. Quick short link to the proposal : https://www.ripe.net/participate/policies/proposals/2015-04 Regards, Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Wed Sep 16 14:15:26 2015 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 16 Sep 2015 14:15:26 +0200 Subject: [address-policy-wg] 2015-04 Discussion Period extended until 25 September 2015 (RIPE Resource Transfer Policies) Message-ID: Dear colleagues, The Discussion Period for the proposal 2015-04, "RIPE Resource Transfer Policies" has been extended until 25 September 2015. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. The proposer asked to provide additional feedback or questions. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this policy proposal and send your comments to . Regards, Marco Schmidt Policy Development Officer RIPE NCC From gert at space.net Tue Sep 29 17:03:34 2015 From: gert at space.net (Gert Doering) Date: Tue, 29 Sep 2015 17:03:34 +0200 Subject: [address-policy-wg] Consensus reached on 2015-03 (Assessment Criteria for IPv6 Initial Allocation Size) In-Reply-To: <20150830131025.GA13615@Space.Net> References: <20150830131025.GA13615@Space.Net> Message-ID: <20150929150334.GA42716@Space.Net> Dear AP WG, The last call period for proposal 2015-03 (Assessment Criteria for IPv6 Initial Allocation Size) has ended. In this phase no new feedback has been sent to the working group and the working group chairs have therefore concluded that the consensus as previously announced (see below) still stands. We ask the RIPE NCC to go ahead and implement this policy. Cheers, Your working group chairs Gert & Sander On Sun, Aug 30, 2015 at 03:10:25PM +0200, Gert Doering wrote: > Dear AP WG, > > On Thu, Jul 09, 2015 at 02:19:35PM +0200, Marco Schmidt wrote: > [..] > > The draft document for version 2.0 of the policy proposal 2015-03, > > "Assessment Criteria for IPv6 Initial Allocation Size", has now been > > published, along with an impact analysis conducted by the RIPE NCC. > > We encourage you to read the draft document text and send any comments > > to address-policy-wg at ripe.net before 7 August 2015. > > the review phase for 2015-03 has ended (actually, quite a while ago, > but it's vacation time... apologies). > > There was a bit of discussion and thoughtful contemplations about this > proposal (and I have to say, very friendly and very constructive discussion, > which I appreciate :-) ). If a clear opinion was voiced regarding the > proposal itself, it was always supportive. > > So, I declare we have consensus, and move 2015-03 to Last Call. Marco > will send the formal announcement for that in the next days. > > For reference, a list of people that voiced support or opposition (or > something else) in the previous review phase is appended below. This is > what I have based my decision on. > > If you disagree with my interpretation of what has been said and the > conclusion I have drawn from it, please let us know. > > Gert Doering, > Address Policy WG Chair > > > Review Phase for V2.0, starting Jul 09, 2015 > > Support: > > Shahin Gharghi > Carsten Brueckner > Tore Anderson > (notes that subsequent allocations are not covered) > Andre Keller > (notes disagreement with the assumptions in the impact analysis > regarding routing table growth, but supports proposal) > Annette Suedmeyer > (plans to submit a follow-up proposal covering subsequent allocations) > Silvia Hagen > (some thoughts about "we should not be looking at IPv6 with mostly > conservation in our minds", and questions about interpretation) > John Collins > > Comments, Clarification: > > Mathew Newton / Marco Schmidt > (side clarification about the evaluation to be done by the NCC) > > Tore Anderson / Mathew Newton / Sander Steffann / Jens 'Opteamax' > (side discussion about subsequent allocations, returning of the > initial /29 and asking for a larger *initial* allocation) > > Jens 'Opteamax' / Tore Anderson > (side discussion about size of the reservation done enclosing the > initial allocation) > > Silvia Hagen / Gert Doering / Sascha Luck / Mathew Newton / Marco Schmidt > (side discussion about conservation, maths, and finding the right > balance between "too liberal" and "too conservative") > > Opposing voices: > > - > -- > 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 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nikolas.pediaditis at ripe.net Wed Sep 30 16:51:28 2015 From: nikolas.pediaditis at ripe.net (Nikolas Pediaditis) Date: Wed, 30 Sep 2015 16:51:28 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources" Message-ID: <512FCD12-5A16-4D19-ABE9-517C3D394FA5@ripe.net> Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". In accordance with the new policy, Internet number resources can be transferred between resource holders in the RIPE NCC service region and resource holders in the service regions of other Regional Internet Registries (RIRs). Inter-RIR transfers are possible between RIRs with compatible policies. Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR transfers with the RIPE NCC: - IPv4 addresses can be transferred to/from the ARIN service region - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service region The main web page on inter-RIR transfers with the supporting documentation and all related information to get you started can be found at: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/inter-rir-transfers The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2014-05 The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is available at: https://www.ripe.net/publications/docs/ripe-644 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services From David.Huberman at microsoft.com Wed Sep 30 16:56:00 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 30 Sep 2015 14:56:00 +0000 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources" In-Reply-To: <512FCD12-5A16-4D19-ABE9-517C3D394FA5@ripe.net> References: <512FCD12-5A16-4D19-ABE9-517C3D394FA5@ripe.net> Message-ID: Excellent news!!! Very well done, everybody. The ability to move IPv4 addresses in and out of RIPE, APNIC, and ARIN, is a critical bootstrap phase as we transition to dual stack everywhere. David David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On > Behalf Of Nikolas Pediaditis > Sent: Wednesday, September 30, 2015 7:51 AM > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy > for Inter-RIR Transfers of Internet Resources" > > Dear colleagues, > > We are pleased to announce that we have implemented the policy proposal > 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". > > In accordance with the new policy, Internet number resources can be > transferred between resource holders in the RIPE NCC service region and > resource holders in the service regions of other Regional Internet Registries > (RIRs). > > Inter-RIR transfers are possible between RIRs with compatible policies. > Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR > transfers with the RIPE NCC: > > - IPv4 addresses can be transferred to/from the ARIN service region > - IPv4 addresses and AS Numbers can be transferred to/from the APNIC > service region > > The main web page on inter-RIR transfers with the supporting > documentation and all related information to get you started can be found > at: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ri > pe.net%2fmanage-ips-and-asns%2fresource-transfers-and- > mergers%2ftransfers%2finter-rir- > transfers&data=01%7c01%7cDAVID.HUBERMAN%40microsoft.com%7c7ef84 > 8bdd618470718bb08d2c9a6e46d%7c72f988bf86f141af91ab2d7cd011db47%7c > 1&sdata=wky1RPnrMWvZ3ikSN5FE3lSrbHBQheoMMK6%2fIfXMSCE%3d > > The archived policy proposal can be found at: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ri > pe.net%2fparticipate%2fpolicies%2fproposals%2f2014- > 05&data=01%7c01%7cDAVID.HUBERMAN%40microsoft.com%7c7ef848bdd61 > 8470718bb08d2c9a6e46d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata > =LCENhZGXlNnjmbj%2bXRdVxSa9N6Zedqxg3vx3xexJ708%3d > > The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is > available at: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ri > pe.net%2fpublications%2fdocs%2fripe- > 644&data=01%7c01%7cDAVID.HUBERMAN%40microsoft.com%7c7ef848bdd6 > 18470718bb08d2c9a6e46d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat > a=sxLYNLmEx3UnwEQKWqT1bQA0lBcGBmO1QiY6HvkAsrk%3d > > > Kind regards, > > Nikolas Pediaditis > RIPE NCC Registration Services From ebais at a2b-internet.com Wed Sep 30 21:05:04 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Wed, 30 Sep 2015 21:05:04 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources" In-Reply-To: <512FCD12-5A16-4D19-ABE9-517C3D394FA5@ripe.net> References: <512FCD12-5A16-4D19-ABE9-517C3D394FA5@ripe.net> Message-ID: Hi Nikolas, Thank you for the work and this update. Could you or Marco perhaps provide a quick update on what the current status is in the inter-rir transfer status between APNIC and RIPE region, after the APNIC exec-board announced that it would hold transfers until further notice earlier this year ... Regards, Erik Bais Verstuurd vanaf mijn iPad > Op 30 sep. 2015 om 16:51 heeft Nikolas Pediaditis het volgende geschreven: > > Dear colleagues, > > We are pleased to announce that we have implemented the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". > > In accordance with the new policy, Internet number resources can be transferred between resource holders in the RIPE NCC service region and resource holders in the service regions of other Regional Internet Registries (RIRs). > > Inter-RIR transfers are possible between RIRs with compatible policies. Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR transfers with the RIPE NCC: > > - IPv4 addresses can be transferred to/from the ARIN service region > - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service region > > The main web page on inter-RIR transfers with the supporting documentation and all related information to get you started can be found at: > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/inter-rir-transfers > > The archived policy proposal can be found at: > https://www.ripe.net/participate/policies/proposals/2014-05 > > The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is available at: > https://www.ripe.net/publications/docs/ripe-644 > > > Kind regards, > > Nikolas Pediaditis > RIPE NCC Registration Services > From ebais at a2b-internet.com Wed Sep 30 23:50:32 2015 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Wed, 30 Sep 2015 23:50:32 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources" In-Reply-To: References: <512FCD12-5A16-4D19-ABE9-517C3D394FA5@ripe.net> Message-ID: <7CBB6B02-0135-4BF1-B098-054F3184E88E@a2b-internet.com> I had to look it up in the Apricot APNIC archive of 2015, but the actual bit that I am referring to is the following : http://youtu.be/2iKK_8iJU6E where Andrea Chima from RIPE NCC is explaining the inter-RIR transfer policy on stage ( around 1:17 ) ... And Paul Wilson from APNIC is starting at 1:24 upto 1:35 at the mic on the topic. Regards, Erik Bais > Op 30 sep. 2015 om 21:05 heeft Erik Bais - A2B Internet het volgende geschreven: > > Hi Nikolas, > > Thank you for the work and this update. > > Could you or Marco perhaps provide a quick update on what the current status is in the inter-rir transfer status between APNIC and RIPE region, after the APNIC exec-board announced that it would hold transfers until further notice earlier this year ... > > Regards, > Erik Bais > > Verstuurd vanaf mijn iPad > >> Op 30 sep. 2015 om 16:51 heeft Nikolas Pediaditis het volgende geschreven: >> >> Dear colleagues, >> >> We are pleased to announce that we have implemented the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". >> >> In accordance with the new policy, Internet number resources can be transferred between resource holders in the RIPE NCC service region and resource holders in the service regions of other Regional Internet Registries (RIRs). >> >> Inter-RIR transfers are possible between RIRs with compatible policies. Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR transfers with the RIPE NCC: >> >> - IPv4 addresses can be transferred to/from the ARIN service region >> - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service region >> >> The main web page on inter-RIR transfers with the supporting documentation and all related information to get you started can be found at: >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/inter-rir-transfers >> >> The archived policy proposal can be found at: >> https://www.ripe.net/participate/policies/proposals/2014-05 >> >> The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is available at: >> https://www.ripe.net/publications/docs/ripe-644 >> >> >> Kind regards, >> >> Nikolas Pediaditis >> RIPE NCC Registration Services > -------------- next part -------------- An HTML attachment was scrubbed... URL: