[address-policy-wg] LACNIC Inter-RIR Transfer Policy Implemented
Dear colleagues, Yesterday, LACNIC announced that they have implemented their inter-RIR transfer policy: https://www.lacnic.net/4711/2/lacnic/lacnic-starts-processing-inter-rir-transfers This means that IPv4 addresses can now be transferred between organisations in the RIPE NCC and LACNIC regions (IPv6 and AS Numbers are excluded from LACNIC's inter-RIR transfer policy). You can find more information on inter-RIR transfers on our website: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/inter-rir-transfers It's worth noting that an inter-RIR transfer request should always start with the offering party via the "source" RIR that the resources are currently registered with. Kind regards, Nikolas Pediaditis Registration Services & Policy Development Manager RIPE NCC
[address-policy-wg] New AS Number Blocks Allocated to the RIPE NCC
Dear colleagues, On 1 April 2020, the RIPE NCC received the following AS Number blocks from IANA: 210332-211355 211356-212379 212380-213403 You may want to update your records accordingly. All allocations of AS Numbers made by IANA to RIRs are listed here: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml Kind regards, Nikolas Pediaditis Registration Services & Policy Development Manager RIPE NCC
Re: [address-policy-wg] A list of actions during quarantine
Dear Töma, Thank you for your question and my apologies for the delayed reply. We de-register resources in accordance with "Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources”: https://www.ripe.net/publications/docs/ripe-716#b The steps we take with regards to de-registration and quarantine are also described in: https://www.ripe.net/manage-ips-and-asns/resource-management/quarantine-for-returned-internet-number-resources The resources are held in quarantine long enough to allow interested parties to notice the de-registration and remove potential blacklisting records. Furthermore, we only re-use address space that is not routed. We'd like to note that in April 2018, we finished allocating IPv4 blocks from the previously-unused 185.0.0.0/8. https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations Since then, we issued more than 9,000 /22 IPv4 allocations - all of them were from address blocks that were already issued in the past and then de-registered and re-used. Sometimes we receive questions about incorrect geo-location for such address blocks (which are still pointing to the previous resource holders). In a few recent cases, we have seen reports about newly issued blocks being blacklisted. When requested, we contact relevant blacklisting providers to clarify the situation about resources being re-used and ask them to remove existing listings related to previous resource holders. We are currently reviewing our procedures to see if we could pro-actively provide blacklisting providers with information on address blocks returned to our free pools. This could help to reduce the possibility of re-issued blocks being blacklisted. Please also note that RIPE Policy Proposal 2019-08 is currently open and (if accepted) will require the creation of ROAs for all unallocated and unassigned address space under our control.: https://www.ripe.net/participate/policies/proposals/2019-08 If you have any questions, please let me know. Kind regards, Nikolas Pediaditis Registration Services and Policy Development Manager RIPE NCC > On 26 Nov 2019, at 16:47, Töma Gavrichenkov wrote: > > Peace, > > There's a page[1] on the NCC web site which says: > > "When we recover IPv4 addresses, we hold on to them for a quarantine > period. During this time, we take a number of actions that help to > make it clear the addresses are no longer associated with their > previous holder and should be considered as “new” address space." > > Is the particular list of actions applied to an IPv4 prefix outlined > somewhere? Is it only prevention of routing, or e.g. trash cans like > Spamhaus are contacted too? > > [1] https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works > > -- > Töma >
Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
Dear Nick, all, On 29 May 2019, at 15:41, Nick Hilliard wrote: > Could the NCC provide any stats on how many /22s have been assigned under the > IXP assignment policy? Since September 2012, when the current IXP assignment policy came into effect, the RIPE NCC has issued 1x /22 and 3x /23 assignments to IXPs. Prior to this policy becoming active we had received specific requests from IXPs (for IP blocks not restricted to be used exclusively for their peering LANs). From these requests: - 23 were approved with a size of /23 - 1 with a size of /23,/24 - 9 with a size of /22 - 1 with a size of /23,/23,/24 Finally please note that, as some IXPs are also LIRs, they can use parts of their IPv4 allocations for their peering LANs (i.e. referring to some IP blocks larger than a /22 that have been mentioned in this thread). These are not considered as direct IXP assignments. I hope this helps. Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC > On 29 May 2019, at 15:41, Nick Hilliard wrote: > > Denis Fondras wrote on 29/05/2019 14:11: >> On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote: >>> This proposal aims to increase the reserved IPv4 pool for IXPs to a >>> /15 and finetune assignment criteria. >>> You can find the full proposal at: >>> https://www.ripe.net/participate/policies/proposals/2019-05 >> Just because of "It no longer provides for IXPs that need more than a >> /23 of IPv4 space" I am against this proposal. > > Could the NCC provide any stats on how many /22s have been assigned under the > IXP assignment policy? > > /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory > suggests there are about 20 IXPs worldwide which are larger than 256 > connected parties. > > Nick > > > smime.p7s Description: S/MIME cryptographic signature
Re: [address-policy-wg] Application for AS number
Dear Aled, Gert, all, Please allow me to provide some clarification. I can confirm that the RIPE NCC does take future deployments into account and AS Numbers can be assigned in advance. Regarding this specific case, there was a miscommunication that we have now clarified directly in the request (which is still ongoing). Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC > On 7 May 2019, at 14:30, Gert Doering wrote: > > Hi, > > On Tue, May 07, 2019 at 01:18:14PM +0100, Aled Morris via address-policy-wg > wrote: >> I'm in the process of helping a startup ISP get RIPE membership and >> resources and have hit against a little bit of poor wording in the AS >> guidelines RIPE-679, specifically: >> >> *A network must be multihomed in order to qualify for an AS Number.* >> >> The application for an AS number has been delayed because the NCC analyst >> working on the ticket is claiming the ISP has to be *already multihomed* >> before an AS can be issued. >> >> This interpretation doesn't make any sense to me. Surely the intention *to >> become multihomed* should be the requirement for obtaining an AS number? > > Speaking as WG participant and long time LIR contact, this sounds funny > indeed. And none of my AS requests so far have been for networks that > were *already* multihomed (because, well, how can you be without an > AS number...). > > >> I don't even see how you can be properly multihomed if you don't have an AS >> number. Are we supposed to implement some kind of NAT multihoming first? >> >> Can we look to change the wording in RIPE-679 to make this clear? > > Now, speaking as WG chair, we can just toss the ball at Marco/Andrea > from the NCC RS department and ask them to comment on this, and whether > this is an issue of policy wording, misunderstanding, or possibly > miscommunication (language barriers...). > > We can also spend some time at the next meeting to discuss this in > the WG meeting - that's what our time is for, have face to face chats > to clarify intentions, interpretations, and possibly ways forward... > > Gert Doering >-- multi-hatted individual > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 smime.p7s Description: S/MIME cryptographic signature
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Dear Carlos, Radu-Adrian, all, Following your questions, I have some numbers and other information that might be useful. 1. Currently, there will be 977,408 IPv4 addresses remaining in our free pool once we are no longer able to allocate contiguous /22s. This number excludes prefixes that are smaller than a /24 and those prefixes that have been reserved for IXP assignments or temporary assignments. It might also be slightly larger by then, due to addresses that are recovered in the meantime. 2. Over the past three years, we have recovered the following amounts of IPv4 addresses: 2016: 83,712 2017: 106,368 2018: 53,824 Once an IPv4 allocation or assignment has been de-registered from its holder, it is added to the RIPE NCC’s free pool (after a quarantine period). It is then available to be allocated to another organisation. There are no specific periods of time for recovering IPv4 addresses from resource holders. This can happen at any point and for multiple reasons, all of which are unpredictable. For this reason, any predictions we could make about the number of addresses we expect to recover in the future would be highly unreliable. 3. We have assigned the following amounts of IPv4 addresses as temporary assignments over the past three years: 2016: 205,568 2017: 188,928 2018: 162,048 (Note that these figures represent the sum of all temporary assignments made in that year.) Temporary assignments are made from a /13 that has been reserved for this purpose. When a temporary assignment is returned, it is added back to this pool. Finally, I would like to clarify that IPv4 allocations and temporary assignments come from two separate pools - neither influences the other. I hope this helps. Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC > On 8 Feb 2019, at 14:32, Radu-Adrian FEURDEAN > wrote: > > On Fri, Feb 8, 2019, at 09:43, Carlos Friaças wrote: >>> The second, I would rewrite into "What is the amount of recovered space >>> every year? When does recovery happens (all year or specific period of >>> the year) ?". >> >> That's really for the NCC's Registration Services Dept. to answer, i think >> :-) > > Exactly ! > >>> Plus estimations for the future if any. >> >> Oh, that will be a hard exercise. > > They (the NCC) are pretty good at this kind of stuff. > >>> However there are some questions on what does the NCC do *before* getting >>> there. >>> >>> Let's remember there still are temporary allocations. How much space do >>> they usually take out of the /13 reserved for them ? Should be move >>> temporary allocations to standard pool (and merge their pool into the >>> main one) ? If yes, when ? Now ? When there are no more /22 in the >>> regular pool (preventing the switch to /24 for a few months) ? when >>> there is only /xx (/13 suggested) free space in the regular pool ? Do >>> we need a policy for that of is it just "NCC bookkeeping stuff" ? >> >> I would say: Don't touch that /13. Keep it simple :-) > > That may get some people angry. A /13 is 512 /22s (5-6 weeks worth of > allocations at current rate) or 2048 /24s (I expect that to be more than 6 > months worth with the current proposal). That is beginning to be a little too > much. > > Let's remember that with the current proposal, the price of a /24 via > "additional LIR" will be pretty much in line with the market one (unless the > market prices spike within one year). That will definitely reduce the LIR > creation and in consequence the allocation rate. > > As for users of temporary allocations, there's the "conference" guys that > should be kicked a little bit to do more IPv6 and less IPv4 (last years > CiscoLive Barcelona was a pretty big fail for this matter - I understand they > finally fixed it this year). > >>> There's the quarantine (returned/recovered blocks) : what happens when >>> there's not a single /22 in the "free" pool, but there is space in the >>> "Reserved pool" (quarantine + temp allocations). >> >> Imho, that's a different pool. > > It's different, but after a few months address blocks go from quarantine pool > to the allocation pool. Reason to get some people angry. > >>> and half against (the "let's end the IPv4 madness" stuff). >> >> Please see my previous e-mail. Unfortunately IPv4 *usage* is not going >> away anytime soon... :( > > No, it's not going away, but we should to everything necessary to move from a > stance "IPv6 guys area savage geeks, the normal is IPv4" to one of &quo
Re: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"
Hi Tore, The answer to your question is No - for a transfer from APNIC to RIPE there is no need to provide a usage plan. But I would like to briefly explain this answer. There is no requirement in APNIC’s inter-RIR transfer policy for the counterpart RIR to adhere to needs-based policies: https://www.apnic.net/policy/resources#8.2. Inter-RIR IPv4 address transfers This is in contrast with ARIN’s inter-RIR transfer policy: https://www.arin.net/policy/nrpm.html#eight4 Therefore, as policies stand at the moment in all three RIRs, the needs-based evaluation is only for transfers from ARIN to the RIPE NCC. > but given the above quote as well as the phrasing in section IV of ripe-651 You are right and thank you for noticing this. The wording in section IV of ripe-651 was incorrect and gave the wrong impression. We updated section IV of the document to ensure it accurately reflects the policy text. The updated document will be published shortly and will be ripe-656. Kind regards, Nikolas Pediaditis RIPE NCC Registration Services > On 01 Oct 2015, at 11:33, Tore Anderson <t...@fud.no> wrote: > > * Nikolas Pediaditis <nikolas.pediadi...@ripe.net> > >> The moratorium that the APNIC EC had set for inter-RIR transfers with >> the RIPE NCC has been officially lifted as of early September and it >> was announced during APNIC 40. >> >> The transcript of the APNIC 40 AMM session is available at: >> https://conference.apnic.net/data/40/10-Sept-AMM.txt >> >> Here is the quotation with regard to this matter: >> >> "Inter-RIR transfer policy: it was one of the items which the >> Executive Council decided previously. We had a moratorium for the >> inter-RIR transfer with RIPE NCC, but at this time in the Executive >> Council meeting on Monday, we decided to resolve to lift -- that >> means discontinue -- the temporary moratorium on the inter-RIR >> transfers with RIPE NCC. That is the reaction that RIPE NCC recently >> set the new inter-RIR transfer policy to require the recipient of the >> transfer from the other RIR region which has the demonstrated need >> policy. So that helped us to lift this moratorium. So now you can >> transfer the IPv4 address, if you need it, with someone in the RIPE >> NCC region." >> >> There is also the video version available (at 58:38): >> https://conference.apnic.net/40/program#sessions/amm >> >> Therefore inter-RIR transfers of IPv4 and ASNs are possible between >> resource holders in the APNIC and RIPE regions. Both RIRs will be >> cooperating in accordance with their policies. > > Nicholas, > > Thank you for the update. I hope you can clarify one thing for me, > which I find the APNIC and RIPE communites' policies to be crystal > clear about, but given the above quote as well as the phrasing in > section IV of ripe-651 I am not so sure about the actual implementation. > > It's a simple yes or no question: If there is a transfer from the APNIC > region to the RIPE region, will the RIPE region recipient required to > «provide a plan to the RIPE NCC for the use of at least 50% of the > transferred resources within 5 years»? > > Tore > >
Re: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"
Hi Erik, The moratorium that the APNIC EC had set for inter-RIR transfers with the RIPE NCC has been officially lifted as of early September and it was announced during APNIC 40. The transcript of the APNIC 40 AMM session is available at: https://conference.apnic.net/data/40/10-Sept-AMM.txt Here is the quotation with regard to this matter: "Inter-RIR transfer policy: it was one of the items which the Executive Council decided previously. We had a moratorium for the inter-RIR transfer with RIPE NCC, but at this time in the Executive Council meeting on Monday, we decided to resolve to lift -- that means discontinue -- the temporary moratorium on the inter-RIR transfers with RIPE NCC. That is the reaction that RIPE NCC recently set the new inter-RIR transfer policy to require the recipient of the transfer from the other RIR region which has the demonstrated need policy. So that helped us to lift this moratorium. So now you can transfer the IPv4 address, if you need it, with someone in the RIPE NCC region." There is also the video version available (at 58:38): https://conference.apnic.net/40/program#sessions/amm Therefore inter-RIR transfers of IPv4 and ASNs are possible between resource holders in the APNIC and RIPE regions. Both RIRs will be cooperating in accordance with their policies. Kind regards, Nikolas Pediaditis RIPE NCC Registration Services > On 30 Sep 2015, at 23:50, Erik Bais - A2B Internet <eb...@a2b-internet.com> > wrote: > > 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 > <eb...@a2b-internet.com> 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 >>> <nikolas.pediadi...@ripe.net> 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 >>> >>
[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://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
