Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
Greetings, After reading your message, i had to go search if i expressed an opinion on 2023-04 or not. It seems i did (back in September), but perhaps i wasn't 100% clear about my opposition to this proposal. So in order to make it clear for the co-chairs, i do oppose this proposal, on the grounds that the quality of publicly available registration data is likely to decrease if this proposal is approved. Best Regards, Carlos On Fri, 5 Apr 2024, denis walker wrote: Colleagues I am not surprised this policy proposal (2023-04) has gone to last call. I expected this from the start, no matter what anyone said. And I won't be surprised when it is approved. I used to wonder why no one would even talk about bringing the RIPE Database into the modern world. Why continue to use an ancient, broken tool that is barely fit for purpose? It is quite obvious now. Playing on the complexity and difficulties with using the database allows people to justify changing the purpose and the rules, to make it more convenient. That is simpler and cheaper than fixing the tool. It is easy for a small vocal group to sell 'simple and cheap' to a silent majority. Convenience is easier to do than right. But it may have consequences. The proposers have assured us all that this proposal is about nothing more than introducing this optional, minor, inconsequential feature that changes nothing. They have argued that the RIPE NCC has "repeatedly" verified their claim that this proposal changes nothing 'of significance'. This is based on the RIPE NCC legal team's confusing impact analysis and the comments made once and referred to once by the RIPE NCC Registration Services through messages passed on by the policy officer. The legal team declined to clarify the confusing wording of their impact analysis. No one from Registration Services was willing to discuss the claims that they have been wrongly applying the policy for a number of years, or the reason why and when they stopped correctly applying the policy. I thought RIPE NCC staff were being encouraged to be more involved in community discussions? It has been said and confirmed recently by several people from the community that we no longer understand what some of the registration data in the RIPE Database means, why it is there and why we have these rules about it. This is despite the actual, current wording of these rules having been written into a version of the policy published in October 2003 that was authored by some people who are still leading members of this community, and at the time were RIPE NCC staff. The infamous line being removed by this proposal was a re-wording of earlier rules introduced in address policy with a long list of early authors, again including some people who are still leading members of this community. I asked if any one of these community leaders would offer some background information to the community on this, now poorly understood, registration data and the rules governing it. That may have helped with our current understanding. If we actually understood the data and rules that we are about to change, we might have more confidence in doing so. But nothing was said on this background. Europol has expressed serious concerns about these changes. They have stated that it takes time for them to consult with national LEAs, the EU commision and other partners. If someone had informed them earlier of the changes being considered that may affect them, they may have had sufficient time to do these consultations. Or perhaps they would have been able to express their deep concerns at an early stage, before the minds of the vocal few were made up. I did suggest early on in the discussion that the RIPE NCC contacts stakeholders of the RIPE Database and invite them to join the discussion. I was quickly told by other community members on the mailing list that this was not part of the policy development process. [Maybe it should be...] It is extraordinary that we have now reached a position where the convenience of a handful of vocal operators in this community is considered so important that we must proceed with all haste to introduce this optional, minor, inconsequential feature that changes nothing, without delay. That is without even a delay to allow Europol to complete it's consultations and report back to the working group. I saw references recently on the ripe.net website and LinkedIn about some productive meeting between the RIPE NCC and some internet governance groups. I hope the attitude of the technical community over this proposal won't undermine those meeting achievements. A technical community that clearly has not watched John Curran's keynote speech at NANOG that covers this very situation involving internet governance, the technical community and civil society. I would advise you all to watch it: https://www.youtube.com/watch?v=U1Ip39Qv-Zk You may question my comments about the vocal few. But the details of the who and how many are
Re: [address-policy-wg] 2023-04 The bigger picture
Greetings Denis, All, Yes, it was a very long message :-) Well, maybe not, if we keep in mind the time you have worked and thought about and around the RIPE database. I obviously don't agree with everything you wrote, while i can agree with most of it. 2023-04 seems a bad idea to me, but at least it doesn't prevent anyone to keep on the registration of their assignments if they wish to do so. This proposal sounds like a "less effort for everyone" proposal, and for me, even if it's unintended, a way to increase opacity. Is it enough for a public registry to have just the association between address space and its direct members? -- i don't believe so. Some LIRs are not registering their assignments (violating current policy, right?), so we change/update the policy to make their lack of action as part of the policy? It sounds very wrong to increase compliance levels artificially by changing the rules. I see "arguments opposing the proposal" = none. I would like to disagree. The quality of publicly available registration data is likely to decrease if this proposal goes through. Regards, Carlos On Mon, 25 Sep 2023, denis walker wrote: Colleagues I want to look at the bigger picture here. I apologise again for another long email. There are many issues here that this community has ignored for too long. So I hope some of you will at least read through to the end, think about what I say and comment...maybe even support the general idea... Although this has been a discussion with only a handful of people it has raised some interesting points. Many followers may have missed the significance of some of these points or perhaps not thought deeply about them. These include (in no particular order): -Different registration requirements for IPv4 and IPv6 -Differences in the way IPv4 and IPv6 have been allocated and assigned over time -Block size (fixed or random) -Retro fitting of features -Different levels of adherence to policy by resource holders -Voluntary nature of supplying some details -No consistent approach to supplied data -Confusion for some resource holders about what data to publish -Effort required to maintain data in the RIPE Database -Volatility of some fast changing data -Privacy -Customer confidentiality -Public interest -Public registry -Registering public networks -Addresses defined as free text (sometimes including name) This is a lot of issues wrapped around one policy proposal. This proposal will not address all, or even most, of these issues. I don't believe this is the right way forward. But what is the root problem here and how can we address it? There are also some other points to consider. At recent RIPE Meetings some prominent members of this community have told me in the strongest possible terms that there is no way in hell that they are going to list any of their customer's details in the public RIPE Database. No matter what any policy says. Commercial confidentiality seems to be a very sensitive issue for some resource holders. Of course this is a valid concern. But it needs to be balanced. Policy needs consensus, but when we have a consensus all resource holders must follow it. That is the only way a self regulating industry can work. Another reason of concern is the alignment of handling both IPv4 and IPv6 registrations in the RIPE Database. Where we have two systems that are managed in different ways, there are of course two ways they can be aligned. We can dumb down the IPv4 data to the level of IPv6. Or we can raise the IPv6 data to the level of IPv4. Everyone is focused on the dumbing down option. No one has even considered moving in the other direction. I have never understood why the IPv6 registration policy was not written with the same requirements in mind as the IPv4 in the first instance. Maybe at the time the automation options available then were not as extensive as they are today. Computer power and bandwidth were certainly not comparable to what they are today. Changes to the RIPE Database data model, interfaces, technology and design would make it possible to raise the level of IPv6 information available in the public registry to the same level as IPv4. At the heart of this issue is a public registry. But what is that in 2023? What does it mean? What should be in it? Who is it for? How do we achieve a three way balance between commercial sensitivity, public need and privacy? These are the sort of questions I was hoping the RIPE Database Requirements Task Force would answer when they started their work. The end result was a little disappointing. They didn't answer any of these questions. They focussed most of their attention looking backwards. Many of us know the history. We want to know how to move forwards. These types of proposals are not the right way forward. So where should we be heading? I believe we need a new Task Force to do what I thought the last one would do. To determine the business requirements for the RIPE Database as
Re: [address-policy-wg] 2023-02 Extended Review Phase (Minimum Size for IPv4 Temporary Assignments)
Greetings, I would like to express my support for 2023-02. While i don't see it as a big priority, it makes sense for me to write in these proposed changes. Regards, Carlos On Wed, 24 May 2023, Tore Anderson wrote: On Tue, 2023-05-09 at 16:31 +0200, Angela Dall'Ara wrote: The policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now in the extended Review Phase in an updated version. Following up on the feedback received, the wording was simplified without changing the proposal content. This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24, while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. Seems sensible to me. Support. Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)
Greetings, I would like to express my support to this proposal, as it aims to extend the usability of the IXP reserved pool, without any impact on operations of new IXPs. Regards, CArlos On Wed, 24 May 2023, Tore Anderson wrote: On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: The policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now in the extended Discussion Phase. This proposal modifies the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. I believe this proposal is a step in the right direction, so I support advancing it to the review phase. Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
On Wed, 26 Apr 2023, Gert Doering wrote: "not *really* operating as IXP" is usually open for long discussions... Agree. I won't go there, as i don't want to draft a new proposal :-))) Cheers, Carlos gert -- 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 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments)
Hi, I also support this proposal, after reading the NCC's impact analysis. I was a bit surprised to see there is a /13 reserved for temporary assignments, and only a /15 for IXPs (just read also 2023-01...). I would also like to add a +1 to what Cynthia wrote, even if this will require a version 2.0 of this proposal. Regards, Carlos On Tue, 11 Apr 2023, Cynthia Revström via address-policy-wg wrote: I support the policy proposal. However, I would prefer to see the second paragraph of the proposed article 3.3 reworded. Currently it's just one really long sentence and it was a bit difficult for me to read. I'm pretty sure that I got the point but I think it should be improved and disambiguated a bit. -Cynthia On Mon, 3 Apr 2023, 11:04 Angela Dall'Ara, wrote: Dear colleagues, Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", is now in the Review Phase. This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24, while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2023-02 https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysis And the draft documents at: https://www.ripe.net/participate/policies/proposals/2023-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg@ripe.net before 2 May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
Hi All, I would like to express my support to this proposal. It doesn't seem to tackle recovering IXP assignments made to orgs which are not really operating as IXPs, but is definitely a step in a positive direction. Best Regards, Carlos On Mon, 6 Mar 2023, Angela Dall'Ara wrote: Dear colleagues, RIPE policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion again. The goal of this proposal is to reduce the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. Following the last round of discussion, this proposal has been updated and it is now at version 2.0. The main difference from version 1.0 is that IXPs are not required to implement the exchange of IPv4 routing information over IPv6 before requesting an assignment larger than a /24. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01 As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 4 April 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
Re: [address-policy-wg] policy compliance dashboard
Hi, What's the main idea for this "policy compliance dashboard"? Something that any LIR can click a button or go to a menu on the LIRPortal and see a list of inconsistencies from the RIPE NCC's point of view...? Can it be some kind of on-demand/self-service ARC (Assisted Registry Check), without requiring a NCC staff member (registration services) live support? Regards, Carlos On Thu, 14 May 2020, Michele Neylon - Blacknight wrote: Lack of response to who? The NCC? What benefit is this meant to bring? I'd assume the NCC would already know about members who aren't paying their bills or otherwise in breach of contractual obligations. Members who "care" will probably deal with issues and those who don't care won't start caring, so I'm struggling to see what value this brings Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com https://blacknight.blog / http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, R93 X265,Ireland Company No.: 370845 On 13/05/2020, 10:41, "address-policy-wg on behalf of JORDI PALET MARTINEZ via address-policy-wg" wrote: After my comment in the Addressing Policy meeting, I decided to go ahead with this email, maybe it can a provocation for some inputs in the open mic ... Note that this text is from my AFRINIC proposal (to make it quick now), so disregard parts that may not correctly matches the RIPE NCC situation and may be some of the things are already done here. Text: * "The Policy Compliance Dashboard? shows to each member its status of policy compliance, collected by means of a periodical review, automated as much as possible. The dashboard will show all possible details to match the policies and RSA, such as: * Contractual obligations (such as status of payments or documents). * Lack of response from the member. * Unused or unannounced resources (where mandatory). * Unavailable or outdated Whois information. * Lack of maintenance of the reverse delegation. * Forbidden sub-assignments (from PI assignments). * Unauthorized transfers. * Tracking of repeated and/or continued policy violations. The dashboard automation will need to be accommodated along policies evolves thru the PDP, in order to display new details. The dashboard will automatically send notifications of the status of compliance to members, after each review or dashboard update. Reminders will be periodically sent in case of any lack of compliance. In this case, warnings will be also sent to the staff. * I've also the feeling that it may be more appropriate for Services WG, so copied as well. Any thoughts? Regards, Jordi @jordipalet ** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [address-policy-wg] Policy Proposal Implemented: 2019-06 "Multiple Editorial Changes in IPv6 Policy"
Greetings, We have come a long way since "You need to have 200 customers in order to receive an IPv6 allocation from the RIPE NCC". Well done everyone! Regards, Carlos On Thu, 30 Apr 2020, Petrit Hasani wrote: Dear colleagues, We are pleased to announce that we have implemented RIPE Policy Proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy". This proposal aimed to remove obsoleted text and simplify the IPv6 policy. LIRs will no longer need to submit a request to the RIPE NCC to create IPv6 end site assignments larger than /48. The LIR will, however, need to justify such assignments should there be a RIPE NCC audit or when making a subsequent allocation request. The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2019-06 The RIPE Document, "IPv6 Address Allocation and Assignment Policy" is available at: https://www.ripe.net/publications/docs/ripe-738 Kind regards, -- Petrit Hasani Policy Officer RIPE NCC
Re: [address-policy-wg] 2019-06 Extended Review Period has ended (Multiple Editorial Changes in IPv6 Policy)
Hi, Also, my support. Good housekeeping :-) Regards, Carlos On Mon, 10 Feb 2020, Piotr Strzyzewski via address-policy-wg wrote: On Mon, Feb 10, 2020 at 10:20:54AM -0800, Randy Bush wrote: And if you do agree with the policy moving forward, please let it know in the Last Call phase as well, as it is easier for us as Chairs to call consensus or not, if we have some response. I support this going forward. /me 2 +1 Piotr -- Piotr Strzy?ewski
Re: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy)
Hi, +1 support. Regards, Carlos -- Forwarded message -- Date: Tue, 8 Oct 2019 16:51:14 From: Nick Hilliard To: Sander Steffann Cc: RIPE Address Policy Working Group Subject: Re: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) Sander Steffann wrote on 08/10/2019 15:01: A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 Policy" is now available for discussion. This proposal aims to remove obsoleted text and simplify the IPv6 policy. I think this is a sensible update. Support. agreed - this looks like a good idea, and thanks to Jordi for doing some housekeeping in this area. Nick
Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call
I also support this proposal. Cheers, Carlos On Fri, 4 Oct 2019, Andy Davidson wrote: Still support this proposal.
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
Hi Nick, All, On Tue, 23 Jul 2019, Nick Hilliard wrote: Carlos Friaças wrote on 23/07/2019 22:03: "e.g. geographic association" -- really...?? Yep, really. https://www.nro.net/wp-content/uploads/comp-pol-2018v2.pdf Nice to have that written down (i.e. in a document, referring to an actual policy). However... how far is that (the geographic association bit) from operational reality...? see Section 1.3.4 - Out of region Use. + also: https://afrinic.net/policy/manual 5.4.6.2 AFRINIC resources are for AFRINIC service region and any use outside the region should be solely in support of connectivity back to the AFRINIC region. "in support of connectivity back to region" Really sounds like a joke. Everything will fit... Anyway, nothing about that on the other four regions.? :-) Cheers, Carlos Nick
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
Disclaimer: i'm not deeply interested in transfers, that's not what the org i work for usually does... :) (please see inline) On Mon, 22 Jul 2019, Jim Reid wrote: On 22 Jul 2019, at 14:26, Piotr Strzyzewski via address-policy-wg wrote: IMHO, this is not the case here. Let's try not to fall in the false dilemma here. I'm sorry Piotr, I strongly disagree. The idea that was being proposed imposes retroactive conditions on legacy address holders. Which is very wrong. Policies should never be imposed retroactively. I also don't really like the idea/concept. However, it may be argued that when a transfer happens, the "new owner" doesn't have the same rights than the legacy resource holder, because it didn't receive the space from the original source. But even with that, i still think a new proposal "converting" the status is not something favourable to a legacy resource holder. Plus, i still think the status shouldn't even be allowed to change... (but i know i'm most likely alone on that one...) If implemented, the suggested policy will discourage legacy holders from co-operating with the NCC, It has the same effect on coooperation with ARIN/AFRINIC/APNIC/LACNIC ? Which in turn encourages "creative" solutions to get around that hypothetical problem and therefore bring about new ways to undermine the integrity of the NCC database. Well, looking at the other 4 regions' status on this topic, probably the most creative solution is to push the transfer through the RIPE NCC... :-)) Regards, Carlos I fail to see what the false dichotomy is. Or could be.
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
"e.g. geographic association" -- really...?? Cheers, Carlos On Mon, 22 Jul 2019, Nick Hilliard wrote: Piotr Strzyzewski via address-policy-wg wrote on 22/07/2019 14:26: IMHO, this is not the case here. Let's try not to fall in the false dilemma here. there's no false dichotomy. Non legacy address space falls under various policies e.g. geographic association and being subject to high RIR costs. These policies are what causes legacy address space to cost more than RIR address space on the address market. If a legacy block is threatened with being converted from something more valuable to something less valuable, then people will avoid the RIR transfer route and we'll end up with less accurate registry info. Nick
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
On Wed, 17 Jul 2019, Sascha Luck [ml] wrote: (...) Leaving the inherent silliness of "owning" or "administering" integers aside: I own my car because "somebody, someday" told me (after money changing hands, of course) "this is yours". The same applies to the computer I'm writing this on. If you'd like to change this you're welcome to try and take them off me and see how far you get ;) Hi Sascha, All. If someone tries to hijack your car or your computer, jurisdiction should be clear, and you will know *where* to present a report. That, unfortunately has no paralell for IP addressing -- well, maybe except in the LACNIC region where they have WARP (Warning Advice and Reporting Point). I don't know how many people are aware about WARP's existence, i just found out about it quite recently :-) However, pushing for a conversion from legacy to "RIR system" looks very delicate. Not sure that legally it can be forced (probably in some countries the regulator may be able to do something, but I wouldn't count on that). As for "do it for you own good", while this may not work today, some day everybody would better get into the RPKI bandwagon, at which point the RIRs would be in a strong position to "kindly" ask holders to convert the legacy resources to "RIR system". If the will id there, which is an entirely different issue. I don't think the RIRs should get into the business of extortion any more than into theft. Nothing good can conceivably come off that. Afaik access to the certification service (RPKI) is voluntary and is already available for legacy holders that engage with the RIR system (see ripe-724, republished yesterday from ripe-674 and ripe-615). Regards, Carlos rgds, Sascha Luck
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
Hi Jordi, All,
I was doing some googling and easily found the references on
ARIN/LACNIC/AFRINIC websites...
https://www.lacnic.net/1022/2/lacnic/legacy-resources
"Transferred legacy resources will no longer be considered as such"
https://www.arin.net/resources/guide/legacy/services/
"When legacy number resources are transferred to another organization
through a specified transfer (NRPM 8.3 and 8.4), the recipient organization
is required to sign an RSA/LRSA, and the resources being transferred will
not retain their legacy status."
https://afrinic.net/resources/transfers
"Applicable to Transfer Recipient Transferred IPv4 legacy resources will
no longer be regarded as legacy resources."
However, regarding APNIC, from what i read on
https://www.apnic.net/community/policy/resources#8.3.-Transfer-of-Historical-Internet-resources
it is not 100% clear to me that the transferred blocks lose their
legacy/historical status.
Can you list which policy proposals within each RIR that resulted in the
above...?
...so we may have some clue about the timeline of such changes -- which
may have been passed under the legacy holders radar...
Additionally, maybe someone involved with transfers on a daily basis can
comment if a block with legacy status has less/equal/more value than
non-legacy blocks???
Cheers,
Carlos
On Tue, 16 Jul 2019, Michiel Klaver via address-policy-wg wrote:
Hi Jordi,
Maybe you can provide any documentation available from the other RIRs about
their rationale why they implemented this kind of policy? Maybe they have
some strong arguments we are missing here?
Gert Doering wrote at 2019-07-16 10:46:
Hi,
On Tue, Jul 16, 2019 at 10:29:28AM +0200, JORDI PALET MARTINEZ via
address-policy-wg wrote:
Again, please consider, if it is good that we are the only RIR not doing
so. I don't think that's good.
If this is the main argument ("I changed this in all the other RIRs,
and now *you* are the only ones stubbornly refusing to follow my
all-the-others-are-doing-this argument") - it's a somewhat weak one.
You have failed to bring forward any reason for changing things, except
"it is unfair that there is a difference"
(without detailing what exactly the unfairness would be, who would
be disadvantaged by this, exactly, and why they would be affected
positively by this proposal) - and
"all the other RIRs have changed this!"
which is both not very compelling.
I could also not see anyone speak up in a supportive way, so I'd consider
this "sufficiently discussed, and no support to go for a formal proposal".
Gert Doering
-- APWG chair
Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
Hi, Disclaimer: the organization i work for is a LIR and has legacy resources (both self-owned and sponsored). From a personal perspective, i would have preferred that no status changes are possible at all. However, some years ago, i did let that personal preference fall, in order to achieve a greater good, which was enabling RIPE NCC services to Legacy Resource Holders (proposal 2012-07, from aug/2012 to oct/2013). The bit i (still) don't like in the status change is "rewriting history". If it was pre-RIR, then it should remain pre-RIR. Because changing it can have some future (and unforeseen) implications. But the possibility of status change was included anyway in the proposal, as long as the holder agrees, in the process to regulate how RIPE NCC provides services to LRHs (which was, honestly, needed). From the financial point of view, if the status is kept, EUR 50 per legacy block per year need to be payed (and the sucessive NCC boards have not changed the value since), and if the status is changed then the resources are binded to RIPE community policies, which might translate as integration in a LIR... so no extra EUR per year are payed. The possible pitfall with changing the status is if the LIR violates RIPE policies (more than once), and then the *former* legacy block can be de-registered... My understanding (and i'm not a lawyer, so i won't risk any comments about liability) is that the RIPE NCC can't force anything to a Legacy Resource Holder, outside the established contract for services provision. That one, also states the possibility for the RIPE NCC to stop providing said services -- but this doesn't mean de-registering. In practice, it means no access to the Certification service. Not sure about reverse DNS, though... To sum up, i agree with Gert... and as i see it, the only thing RIPE NCC (and or the community) can do about legacy space is stop providing services -- but not, perhaps the most important one: registration in the whois database. Cheers, Carlos On Sun, 14 Jul 2019, Erik Bais wrote: Hi Jordy, Legacy resources don?t fall under the contractual obligations that we as a community have setup. Financial or policy, unless decided/afreed upon by legacy resources themselves. That is described in the policy document RIPE NCC services for legacy resource holders. ( https://www.ripe.net/publications/docs/ripe-639 ) If you would view the RIPE NCC as a holder of IP space, that provides resources when a membership is present. If a member would not pay, the resources could be revoked. Legacy holders didn?t receive the resources from RIPE NCC and their resources can?t be revoked. As the RIPE NCC isn?t the top holder of the resource. If legacy is handed back, it would ( should ) go to IANA .. With the legacy services policy it was decided that the historic rights of legacy holders are honored and only if they decide that they want to include themselves in the community and services, it is possible. But only by their own decision. Stripping the legacy resource status after a transfer, would change the holder of the resource from the seller to the rir instead of the seller to the buyer. The RIPE NCC is providing an administrative service to maintain an accurate registry, also including Legacy resources.. Changing the legal status of legacy resources by force, will open up the RIPE NCC for liability charges and due to its monopoly in the RIPE region, that is not a good plan ... and knowing some Legacy holders, that is going to be a huge no-go. Your last email stated that non-legacy holder to non-legacy holder transfers are outside the system .. if we regard the RIPE policies inside the system ... non-legacy resources are ?IN?the system.. because you would say that they would be PI holders or RIPE NCC members ( LIR?s ) ... Legacy holder can be outside ( no contract ) the rir status .. or by their own choice inside the system .. Hope this explains a bit. Regards, Erik Bais Verstuurd vanaf mijn iPhone Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg het volgende geschreven: Hi Gert, If the received of the transfer is already bound by contracts with RIPE, he is the one that will "convert" the resources to non-legacy accepting that transfer. Of course, transfers from non-legacy holders to non-legacy holders are outside of the system. Regards, Jordi @jordipalet El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" escribió: Hi, On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions. Repeat with me: there is no contract of any sort that the RIPE community can use to make
Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
On Tue, 4 Jun 2019, Gert Doering wrote: (...) Now, regarding the "monitoring" bit - since we're all mostly well-behaved here, :-))) describing the limitations and requirements upfront and only acting in cases where the NCC is informed about misuse works fairly well In this specific case would you call the NCC "the police", or would you classify who informs the NCC as "the police"...? :-) in practice (though some people in the anti-abuse community might not agree with me here). Yes, it seems you are way too optimistic, most of the times... :-))) Cheers, Carlos Gert Doering -- APWG chair -- 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
Re: [address-policy-wg] Agenda for APWG meeting in Reykjavik
Hi, Just a small note: 2019-03 is not about "anti-spam", it's about "hijacks". (if some people are not able to abide by the RIR/registry work, then why they need to be part of it?) As far as we authors have been told, the doubt was really between the anti-abuse WG and the routing WG. In fact, as similar proposals are at the table already at LACNIC (see LAC-2019-05) and ARIN (more or less, see prop-266), this might be touched (i hope) during the PDO's presentation. :-) Best Regards, Carlos On Thu, 9 May 2019, Randy Bush wrote: perhaps, as it is, imiho, more address policy than anti-spam, the anti-abuse wg proposal 2019-03 https://www.ripe.net/participate/policies/proposals/2019-03 would be worth a bit of consideration as address policy? randy
Re: [address-policy-wg] PA ??? life after death
On Tue, 12 Mar 2019, Maxim A Piskunov wrote: Hello, Gert, Community. Hi, IPv4 - it's not outdated, exact about IPv4 we are talking. Not about IPv6. And we discuss way to continue support and effective use IPv4 while IPv4 will be not needed anymore. Yes, IPv4 is still the dominant Internet Protocol version. And while we still need IPv4 I wake up members to solve issues: 1. End-user should have independence of LIR 2. Independence of LIR may be obtained by conversion PA to PI and passing addresses to end-user. (/24 or greatest). 3. Even end-user using address from PA and address block /24 or greatest, we should change policy to allow conversion PA to PI for allocated to end-user's addresses if LIR placed under deregistration procedure. Independence of LIR can be obtained by an end-user by... becoming a LIR itself...! Community, please support my proposals. It's not as simple as that... :-) The process is defined here... https://www.ripe.net/publications/docs/ripe-710 As of today, there are 3 proposals on the table: https://www.ripe.net/participate/policies/current-proposals/ 2018-06 RIPE NCC IRR Database Non-Authoritative Route Object Clean-up 2019-01 Clarification of Definition for "ASSIGNED PA" 2019-02 Reducing IPv4 Allocations to a /24 Regards, Carlos >I don't think anything built by Cisco in the last 10 years falls into the >"IPv4 in hardware, IPv6 in software" category anymore. Maybe even 15 years. > >Instead of spreading outdated information, better spend the time working >with those vendors that still ship broken implementations, or take your >money elsewhere.
Re: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")
Dear colleagues, After reading the Impact Analysis, i wish to express my support to 2019-01. Best Regards, Carlos Friaças On Mon, 11 Mar 2019, Marco Schmidt wrote: Dear colleagues, Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review Phase. This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. The RIPE NCC has prepared an impact analysis to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 9 April 2019. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Re: [address-policy-wg] IPv6 PI justification requirements
On Wed, 27 Feb 2019, Kai 'wusel' Siering wrote: Am 26.02.2019 um 23:13 schrieb Cynthia Revström: I have also been informed that this might be a rather unique case in regards to having multiple physical locations requiring PI space. It's not ? been there myself, and got really annoyed by the way the NCC entered spanish-inquisition-mode (like asking for physical location of DCs used, IMHO NOTB, and upstream mail contacts, again NOTB). That was pre-GDPR, these days I'd follow up with "provide legal statement under GDPR that allows you to ask this question, and process any answer". Hrmpft. Hi, I fail to understand how a DC location could in any way be related to a GDPR violation. I also don't understand how asking for upstream mail contacts (i.e. professional ones, that any ASN should in theory have published, role or individual shouldn't make a difference) can violate GDPR. I guess "purpose" for asking is quite easy to understand -- checking if an upstream really exists at that point in time, which may be part of the process. Cheers, Carlos -kai
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Hi, On Tue, 19 Feb 2019, Dominik Nowacki wrote: Dear Colleagues, We do not support this proposal. RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. ARIN style never-ending queue that basically means you will never get the addressees you request at this stage is synonymous with a complete and permanent run out of IPv4 to me. That's what 2019-02 is about: We're in scarcity-mode since 2012. "What you request" and "What you need" are completely irrelevant. When the pool reaches 0 for the 1st time, people will still get /22s *when* some addresses are made available. Changing that into /24s will allow more people to get a minimum of IPv4 eventually at some point (smaller lifeboats, but 4x more lifeboats...) When the *need* for a /24 arises, and a company is still in a bad queue position, the answer is obvious: get it from the market! It would be really easy if IPv6 deployment would solve it, but one is only able to control one's infrastructure, there is absolutely no ability in dictacting what (and if when) 3rd party networks are going to deploy. That depends on their judgement and of course, budget :-) You can also observed that, for example, US where they observe a ?complete and permanent run out of IPv4? has more IPv6 traffic, according to Google, already than say UK where the national ISP, BT, and majority of alternative ISP supports IPv6 for ages already, out of the box. It's not only traffic volume that matters. The number of networks and how much IPv6 is within each network is also very important. No access to V4 - better incentive to have eyeballs on V6 (and granted, some CGNAT probably too). We might not like CGNAT, but noone can stop anybody to use it... :/ More eyeballs on V6 makes an incentive for content providers to make more services available on V6. As i see it, content is the easy bit... Regards, Carlos That?s my take on it. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. On 19 Feb 2019, at 08:08, Carlos Friaças via address-policy-wg wrote: RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely.
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Hello, On Mon, 18 Feb 2019, Martin Hun?k wrote: (...) Unability to getting IPv4 from RIPE doesn't mean unability to get IPv4 conectivity. Nor (some) IPv4 addresses, which can be obtained from "the market". But it push the new player to start with IPv6 and get the v4 as a service. Please go back and read why "You must deploy IPv6 in order to receive IPv4" (unfortunately) didn't stick... It would make v4 as something extra what you are forced to pay extra, perfect mindset to abadon it eventually. Nice plan, but there is just a very tiny detail... 75%-80% of the Internet is IPv4-only. So once again, a faster we run out of IPv4 - a better. We have "run out of IPv4" (in a context of Internet's growth) since some years now... but people are still able to use it, and a lot of people/companies are NOT deploying IPv6 because they don't *need* it today. RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. Martin Best Regards, Carlos
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Thanks! I think i already got some bits :-)) 2019-02 (currently) doesn't address transfers in any way, though. Cheers, Carlos On Fri, 8 Feb 2019, David Farmer wrote: I can't speak to a public version of the slides that went to the ARIN Board of Trustees, John Curran will have to do that. However, this section of ARIN policy was the subject of the Policy Experience Report at the previous ARIN meeting and that is public. From the ARIN 42 meeting report; Transcript; https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5 Youtube; https://www.youtube.com/watch?v=MJHgs4wWO58 Presentation; https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf Hope that helps. On Fri, Feb 8, 2019 at 9:09 AM Carlos Friaças via address-policy-wg wrote: From the minutes: "The President presented a slide deck to the Board with details of the issue." I guess that slide deck is not public...? Carlos On Fri, 8 Feb 2019, Radu-Adrian FEURDEAN wrote: > Meanwhile, in ARIN-Land: > > https://www.mail-archive.com/nanog@nanog.org/msg98840.html > Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy > > -- > Radu-Adrian FEURDEAN > -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
From the minutes: "The President presented a slide deck to the Board with details of the issue." I guess that slide deck is not public...? Carlos On Fri, 8 Feb 2019, Radu-Adrian FEURDEAN wrote: Meanwhile, in ARIN-Land: https://www.mail-archive.com/nanog@nanog.org/msg98840.html Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Fri, 8 Feb 2019, Daniel Suchy wrote: Hello, Hello again, On 2/8/19 9:15 AM, Carlos Friaças via address-policy-wg wrote: I think only one reason, which will really boost IPv6 adoption is real exhaustion of IPv4 pool within our (RIPE) region. I also would like to see a stronger IPv6 adoption, and reach the point where IPv6 packets become dominant (i.e. >50%) and at a later stage reach a point where IPv4 routers/services/everything could be disconnected because they weren't useful anymore. Since there're happy-eyeball RFC implementations, it's somewhat harder to perform such measurments. But I think IPv6 adoption was boosted in regions, where IPv4 pool dried. It's difficult to measure accurately, and even harder to establish a cause/effect link from IPv4 dried pools. :-( Google is currently measuring (globally) around 25%, from 15% 2 years ago, and from 5% 4 years ago. I also read that as a "boost", yes :-) But unfortunately it's still a bit away from 50%... and we must not forget that Google is only one (big) content provider. There is still a lot of IPv4-only content around, and access to it naturally measures at 0%. 2019-02 proposal is just delay this (and allowing more newcomers to start their bussiness), nothing else. The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market). Yes, I understand this purpose and to be clear - I'm not against this proposal (that means, I support it). /24 allocations for newcomers are also used within ARIN region (since 2015 depletetion), so this cannot be any problem with such limitation within our (RIPE) region. Thank You! Regards, Carlos - Daniel
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Hi Radu-Adrian, All, On Thu, 7 Feb 2019, Radu-Adrian FEURDEAN wrote: On Wed, Feb 6, 2019, at 11:19, Jim Reid wrote: The question here I think is what should be the trigger event. And then what happens to the remaining v4 addresses that fell down the back of the sofa, slipped through the cracks in the floorboards and ended up in a disused basement behind a locked door that has a ?beware of the leopard? sign. Well OK. That?s two questions. :-) Concerning the trigger, it seems pretty clear : Cannot allocate a single /22. 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 :-) Plus estimations for the future if any. Oh, that will be a hard exercise. 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 :-) 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. How much v4 space would the NCC be holding once it?s no longer got /22s to allocate? That?s three questions. :-) That's about 10 questions. An answer before the impact analysis (I'm confident this will at least reach "impact analysis") would be greatly appreciated. I will be able to give an opinion based on the answers to those questions. For the moment I'm half for (because the waiting list is something that will be needed at some point in the future), Fully agree :-) 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... :( Regards, Carlos Regards, -- Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Dear Daniel, All, On Thu, 7 Feb 2019, Daniel Suchy wrote: Hello, On 2/7/19 1:17 PM, Servereasy via address-policy-wg wrote: I oppose this proposal, unless at least RIPE NCC will charge members based on how much IPv4 space they have. I find that this will be the only way to really boost IPv6 adoption. this is problem maily due to law and related taxes. Such diversification was here and this changed few years back. Exactly! And apart from that, RIPE NCC also distributes other numbering resources apart from IPv4 addresses, and has a broader set of services. :-) I think only one reason, which will really boost IPv6 adoption is real exhaustion of IPv4 pool within our (RIPE) region. Please, that is leading nowhere. I also would like to see a stronger IPv6 adoption, and reach the point where IPv6 packets become dominant (i.e. >50%) and at a later stage reach a point where IPv4 routers/services/everything could be disconnected because they weren't useful anymore. Imho, it doesn't help to repeat to exhaustion that IPv4 is legacy. That's not the way people are doing IPv4-only today will feel they *need* to deploy IPv6. Please let us focus on reality: IPv6 adoption depends on a multitude of scenarios. For ORGs that already have their own fair share of IPv4 addresses (suitable for their needs) IPv6 will always be "low priority". For those ORGs, IPv4 exhaustion can be *irrelevant* -- it doesn't affect *them*, only 3rd parties are impacted. Their IPv4 addresses will still be usable (and useful). 2019-02 proposal is just delay this (and allowing more newcomers to start their bussiness), nothing else. No. That's completely not the idea. The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market). I would happilly include a "you have prove the NCC you have deployed IPv6"-type clause on this proposal's v2.0, but i'm 99,9% sure that would be a problem for a lot of people. :-( This way, if newcomers just become a LIR and grab a /24, they can become independent (routing policy-wise, etc...) from their upstream(s) -- and i openly expect their engagement/exposure with the NCC will improve their knowledge about IPv6, and their future willingness to deploy it. ;-) I hope this helps you understand my motivation to have kickstarted this 2019-02 work jointly with Sander. Best Regards, Carlos - Daniel
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Thu, 7 Feb 2019, Taras Heichenko wrote: (...) All that you added is derived from "obtain IPs". Of course you are right but until you get IPs you do not need AS, RPKI and so on. Training may be useful without IPs but you can find a way to go to training without LIR status. Yes, but addresses can also be obtained from "the market", and maintenance will be required anyway... Oh, and you can get IPv6 addressing also! (...) Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-) You must obtain IPs at first. All your answer is built on assumption that organization already has some IPs. Of course in this case it will pay annual fee for all service. But we talk about new LIR. I came to RIPE NCC to get IPs. RIPE NCC is telling me: We put you in waitlist and may be later you will get /24. But to get to the waitlist I must pay now 1400 (of course euros not $ as I mistype in previous letter). I pay 1400 euros annually for the right to be in the waitlist. Sounds a bit expensive, yes, i agree. Stock market futures come to mind. But if you can't get space immediately from the NCC, some brokers will certainly help you (for their right price...), and you can associate the space you buy with your new fresh LIR -- and still be on the waitlist (if i'm not wrong)! It has not these addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?). My interpretation is that you could. Currently, a /22 per LIR account... I hope someone who take decision will answer. Would new LIR have right on the block from RIPE NCC if it had bought some IPv4 from the market? Even if the answer now is "No.", i believe that could eventually be changed by a new policy proposal into "Yes.". If this is the case i would support such proposal. Regards, Carlos
Re: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion?
On Thu, 7 Feb 2019, Jim Reid wrote: On 7 Feb 2019, at 07:59, Carlos Friaças via address-policy-wg wrote: Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. How is that possible? Once the pools reach zero, there are no more addresses to hand out. At that point in the timeline, YES. zero means zero. An RIR can't conjure up IPv4 address space out of thin air. If it was able to do that, we could just continue forever with business as usual and allocate v4 until the heat death of the universe. Yes, that's correct. But a set of foreseeable events might pour down -some- IPv4 space, growing the stock from zero. The NCC registration services tell us they are getting addresses back *every* year (yes, that was a surprise for me too). Even if that doesn't happen during a full year, it doesn't mean it won't happen in subsequent years. If i didn't get it wrong, that depends on a variety of factors. Of course the "yearly recovered numbering assets" are not enough to cope with all the demand -- that's when the waiting list might be useful... Besides, there?s no mechanism or policy for the NCC to recover addresses from LIRs that don?t pay their bills. I think you are wrong. Apart from the financial side, if a LIR doesn't comply with policies (falsified data, and so on...) there is a service termination process and resources go back into the pool after some time -- please someone at the NCC, tell me if i got it wrong. If such mechanisms or policies existed, they?d be unworkable. There?s no way of knowing for sure that those addresses weren?t being used. Bad luck. Rules breaking means revokation... The higher risk (as i see it) goes to new recipients of the space, after some quarentine. So if they were reclaimed, the addresses couldn?t be allocated to someone else. I think the NCC and current policy might disagree -- please tell me if i'm wrong. Best Regards, Carlos
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Thu, 7 Feb 2019, Peter Hessler wrote: (...) 4) While there is a belief The Internet(tm) should just up and migrate to IPv6, that is unrealistic. E.g. Twitter, Amazon, Reddit, Github, and *many* home/business ISPs around the world do not even IPv6. Whinging about it in policy groups doesn't change that *fact*. (...) What can we, as a community, do which has not been already tried...? Will it be just a matter of sitting and waiting that people deploying/managing networks & services for those companies are replaced by other people with a different view about IPv6 (or their companies' needs)? From the *extremely* small list above, Github was recently bought from Microsoft right...? Maybe by talking with the right folks... Regards, Carlos
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Hi, (please see inline) On Wed, 6 Feb 2019, Martin Hun?k wrote: What I'm afraid of is pressure for further deaggregation of those last /24s. Even now in the mailing list there was opinion that just one /24 is useless because you can't assign from it to another entity. Not talking about fact that if you have same amount of LIR on waiting list when everybody wants 4x more, the waiting list is 4x longer time-wise. Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to go for IPv6. Or go to "the IPv4 market". If you have /22 you can do that, if you could have /22 but you have chosen /24 (now instead of waiting for /22) - you could have done that and if there won't be enough IPv4 for you that would be just a fact and there would be nothing to do about it. So there won't be such pressure for further deaggregation. At least if IANA won't distribute to RIRs smaller prefixes anyway. And just why is such deaggregation problem for me? Because we would be spending even more RAM and computation effort on "walking dead" IPv4. And if we start to allow such deaggregation we would end up on single /32 in our routing table. At least for now we all know that if we try to announce /25+ we would have reachability issues. Let's keep it that way. I agree global routability must remain at /24. IPv4 is NOT "walking dead". It's the Internet's dominant protocol version, whether we like it or not! How many orgs have gone public about plans to completely drop IPv4? IPv4 has a serious limitation about "future growth", which IPv6 doesn't have. But people are making (a lot of?) money pushing IPv4 numbers from hand to hand, so it is hard for me (at this point, from a research & education network background!) to see how IPv4 will stop being the dominant version... Cheers, Carlos Martin
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Hi, Please see inline. On Wed, 6 Feb 2019, Taras Heichenko wrote: On Feb 6, 2019, at 16:24, Jan Ingvoldstad wrote: In that case, IPv4 is "basically useless" from a business point of view. But that statement is provably false. Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers. Additionally, a lot of connectivity services can be provided via NAT. And so on. If I am right we talk about resources that can be obtained by new LIR. If a LIR already has some IPv4 block it cannot claim to get some other block from RIPE NCC according to the policy. And what does the LIR status give to the LIR? It gives possibility to get IP addresses. So a LIR is been registering to obtain IPs. Anything else? And keep it. And access NCC services like certification (RPKI), training, ... So a new LIR must pay $1400 annually to have ghostly possibility to obtain IPv4 addresses. May be. Later. After years (multiply by $1400). Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-) It has not these addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?). My interpretation is that you could. Currently, a /22 per LIR account... What are we talking about? Show me please use case for participant of the waitlist. Who is he/she? Potentially ORGs that wish to be independent (IPv4 addressing wise) from their transit providers, also allowing them to peer at IXPs, ... The easy part is IPv6, which doesn't involve any waiting list -- it's just a matter of becoming a LIR or getting service from one. :-)) Cheers, Carlos -- Best regards Taras Heichenko ta...@hostmaster.ua
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: On 06.02.2019 14:36, ga...@nethinks.com wrote: [?] I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 to eight new LIRs, since a /24 is basically useless anyway. Especially if you have to wait 6 or more months for it. (Of course, /22 (in up to /24 slices) will mean a much longer waiting time, which makes IPv6 just more interessting. Or IPv4 brokers.) Why is a /24 useless? Sorry for beeing too brief here: From my perspective, becoming an LIR implies the intend to provide service a lot of customers, and I don't see how a single /24 would suffice there. That's what I meant with "basically useless" (from a business point of view). An organisation can still use the /22 (or a /24) to become independent in terms of addressing from transit suppliers... According to the 2019 billing scheme, this is still unchanged, though I reckon it does not apply to PA space: "The separate charge of EUR 50 per Independent Number resource assignment will be continued. Independent number resources are: IPv4 and IPv6 PI assignments; Anycasting assignments; IPv4 and IPv6 IXP assignments;" So fragmenting the /22 into /24s would not be of consequence to an LIR anyway, at least not financially. So strike my argument about that part. Well, I'd like to debate whether a charge per /24 block held (so a /16 counts as 256 blocks) even for PA would "encourage" to return unnused space, but I doubt this is the place nor would this be approved by the GM anyway ;) Yup :-) Cheers, Carlos -kai
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Wed, 6 Feb 2019, Daniel Karrenberg wrote: (...) ... Keep /22 possibility so the complete runout of IPv4 won't be postponed. See above. I do not see the point about 'complete runout'. We *have* run out already. This is about the very very tail end. Allow me to disagree. People are still getting IPv4 addresses from the NCC. "Declaring runout" is not exactly the same as stopping handing out IPv4 addresses. Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. The "reversion" won't happen if there is a policy in place stating RIPE NCC will not allocate any more IPv4 addresses -- who wants to propose that? I don't. Disclaimer: I have been advocating and deploying IPv6 since ~2001. I just think reducing by decree/policy the ability of people to use/deploy IPv4 is not the correct way to go. Cheers, Carlos Daniel
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: (...) I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 to eight new LIRs, since a /24 is basically useless anyway. I really don't agree with the former. The spirit of 2019-02 is precisely that a /24 is the minimum usable allocation, mostly due to global routability. An ORG/LIR might get a second /24 if needed (through a new LIR account), but it needs to go back into the queue... (if there is any at some point). (...) IIRC, billing discussions are out of scope for the APWG. Besides, billing is not per resource currently, is it? Here we are 200% in agreement :-) Cheers, Carlos Regards, -kai
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd)
On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: (...) I know some company can have multiple entity to buy extra range. Some company is cheap to register like in UK. Maybe use company UBO registry obligation in EU can fight that ? RIPE Region does cover more than just EU (EU28 or EU27 doesn't matter here). Precisely. As i understand it, any company in the world just needs to declare that has infrastructure within the RIPE NCC service region in order to access RIPE NCC services. I didn't check, but i've heard this doesn't work in the same way on the other four RIRs... I think changes to this can be addressed through the PDP, but someone has to issue the proposal for this to happen. Cheers, Carlos Regards, -kai
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Forward didn't work, so trying "Reply". :-) Carlos On Mon, 4 Feb 2019, Marco Schmidt wrote: Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer
[address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd)
I was unaware about this list limitation, but hope this helps... :-) Regards, Carlos = Date: Tue, 5 Feb 2019 18:18:45 From: Michael Kafka To: address-policy-wg@ripe.net Subject: [address-policy-wg] New on this list, cannot reply to old topic Hi everyone, I'd like to join the discussion here on the list but I just registered so I can't reply to the existing topic and I don't want to start a new thread. For the sake of a clean thread, can someone please reply to: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Thanks, MiKa -- Forwarded message -- Date: Mon, 4 Feb 2019 12:04:26 From: Marco Schmidt To: "address-policy-wg@ripe.net" Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Tue, 5 Feb 2019, Alexey Galaev wrote: Hello. Hello, I strongly oppose this proposal. Why there are no proposal with increasing IPv4 Allocations to /19, for example? Everyone is free to submit any proposal, following the PDP. 2019-02 is not about adjustements to the past. It's mainly about clarifying rules for the upcoming "waiting list age". If a proposal to move from /22 to /19 is accepted, the "waiting list age" will arrive a lot sooner... :-) Why many years ago new LIRs get /19 for free, but today we need to reduce new members? It wasn't "for free". Existing (and new LIRs) received allocations based on needs they were able to demonstrate. That was the current policy, before Sept/2012. Let check how many IPv4 not announce by BGP Allocations (present, past or future) don't depend on the criteria of global routing visibility. Company X and company Z might want to communicate over a private channel without using private addressing space. The keyword here is "uniqueness". or return 250.0.0.0/8 to the free pool. You mean 240.0.0.0/4? (i.e. 16x /8s) I've asked that question myself. The answer from knowledgeable people didn't really change anything :-) Cheers, Carlos BR, Alexey Galaev +7 985 3608004, http://vpsville.ru http://cloudville.ru - ? - ??: "Marco Schmidt" : "address-policy-wg" : ???, 4 ??? 2019 ? 15:04:26 : [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Mon, 4 Feb 2019, Jetten Raymond wrote: Hi, Hi Raymond, I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , and I agree with the arguments opposing the proposal. It's really not the same proposal, although i'm the common link between 2019-02 and 2017-03. Maybe the title could be more explicit about the moment when the proposed changes would kick in. Which specific opposing arguments (to 2019-02) do you agree with? Each one has a written counter-argument/mitigation. Can you please point out which ones do you think are not valid? Best Regards, Carlos Rgds, Ray -Original Message- From: address-policy-wg On Behalf Of Marco Schmidt Sent: 4. helmikuuta 2019 14:04 To: address-policy-wg@ripe.net Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Tue, 5 Feb 2019, Uros Gaber wrote: This uncertainty will certainly also discourage LIRs from signing up as member just to get IPv4 - regardless of the economics. Say, if you need IPv4 to deliver a project due in six months, then getting it from the market will be the only way that would give you sufficient certainty that you can deliver on time. Depending on the project, AFAIK temporary allocations are/will still be possible. Yes... people do lease ip address space... Carlos Uros
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
Hi, please see inline. On Tue, 5 Feb 2019, ga...@nethinks.com wrote: That is an option. But in order to not punish late entries to the market, Some "late entries" are/will not be market driven. Some companies/organisations could only be searching for a way to become independent from their ISPs/suppliers, and the only way they can do that (IPv4-wise) is to become a LIR and get their own chunk. I also hope that by doing so, they will also be flooded with information about IPv6. it should also include a fixed timeframe when EVERYBODY has to stop using v4 (at least on the public Internet) ... A flag day won't work. There are simply too many networks. I don't see any technical reason why providers all over the world still aren't able (or willing) to do v6 ... of course I know you can't force customers to provide services on v6 (or even to use v6 - Yes, that's the main point. People use what they know it works, and they need to be comfortable about what they are using/managing. If all networks in the world were run by 10 or 100 people, then yes, an agreed change would be possible. However, that's not the case, so co-existence for a long period is unavoidable. I believe of our customers, maybe 1% actively use v6, and another few percent use it unknowingly :) ). Yes, people should be using IPv6 unknowingly (in a transparent way), but it's useful that network managers and sysadmins know about it :-) From our point of view, we could drop external v4 pretty quickly if it weren't required to reach (or be reached) by v4-only users/services ... That's everyone's case, i'm afraid :-)) I've been deploying and advocating IPv6 since 2001. Others have been doing it for a longer period. Within this timespan, i have only read about *one* organisation which publicly expressed plans to scrap IPv4 from their network/services, but they have dropped that in the meanwhile... IPv6 will not happen by decree, it is happenning, slowly, due to need and a vision for Internet's growth (imho). Best Regards, Carlos -garry -- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstraße 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glend...@nethinks.com Geschäftsführer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32
Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
On Tue, 5 Feb 2019, Tore Anderson wrote: * Marco Schmidt A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. I support this proposal. Some random thoughts about it: Hi, Some comments inline: - It is good to have the policy explicitly say there is a waiting list. Current policy says nothing about this. If the NCC would simply close allocation tickets with «sorry, fresh out, try later», that could encourage LIRs to spam repeated allocation requests in the hope that theirs was the first request to be received after an IPv4 fragment was returned to the allocation pool. Yes, and that "randomness" would be everything except "fair". - I don't quite believe that the waiting list would grow indefinitely (regardless of the allocation size being /22 or /24). Keep in mind that only new and IPv4-less LIRs would be able to join the waiting list. Once it is known that simply joining the NCC won't guarantee a /22, but that you'd have to wait for one with no certainty as to how long, I expect that the sign-up rate of new LIRs will drop dramatically (and by extension the amount of LIRs queuing up in the waiting list). If getting a /24 is still cheaper than getting a /24 from "the market", people will queue up, because there will be still a bit of profit... On a personal viewpoint, i also hope newcomers come to the RIPE NCC for IPv4, so they can be flooded with information about IPv6 :-) - It seems reasonable to lower the allocation unit to the de facto smallest usable on the public Internet at a point in time when we can no longer allocate /22s (which are already pretty small). Otherwise recovered /23 and /24 fragments (e.g., PI assignments) will just end up rotting away in the NCC inventory, which serves no good purpose at all. Yes, growing up the NCC's IPv4 inventory will serve noone, except if a policy is accepted in the future to re-open IPv4 distribution, when the inventory reaches some level. I clearly prefer to see /24s distributed to those who want them. - It seems reasonable to trigger this policy at precisely at a watershed moment like the policy aims to do (unlike 2017-03, which would have changed the rules in the middle of the game). As you may have noticed i was also one of the co-authors of 2017-03, and that one was withdrawn. But the current proposal is not 2017-03, and i feel this is needed especially after getting input from the NCC about the amount of address space they are getting back -- due to several reasons. - The authors should clarify how this new policy interacts with the /16 set aside in «5.2 Unforeseen circumstances». In which order does the 5.2 and 5.1bis policies get triggered? I wouldn't touch that. Would let the NCC decide what are "unforeseen circumstances" or wait for a new, different, policy proposal. We might tackle this issue at v2.0, but i would like to keep changes at a minimum, in this proposal's scope. Best Regards, Carlos Tore
Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) (fwd)
Greetings, Jordi, thanks for this work (and the diffchecker really helps!) :-) This seems to be the simplest approach (organisation=LIR). I don't believe we should keep the less explicit wording on the policy, thus i support this proposal. Best Regards, Carlos Friaças (pt.rccn) -- Forwarded message -- Date: Mon, 19 Mar 2018 17:05:18 From: JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg@ripe.net> Reply-To: JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) Thanks Gert! Further, having no inputs removes all the fun of the PDP! In case you missed previous emails, to make it easier for you to comment, I've prepared an on-line diff so you can easily track the proposed changes: https://www.diffchecker.com/2mGPoRbo Also, the complete text of the proposal is here: https://www.ripe.net/participate/policies/proposals/2018-01 Now folks don't have any excuse to not comment ;-) Regards, Jordi -Mensaje original- De: address-policy-wg <address-policy-wg-boun...@ripe.net> en nombre de Gert Doering <g...@space.net> Fecha: lunes, 19 de marzo de 2018, 16:48 Para: Marco Schmidt <mschm...@ripe.net> CC: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-01 New Policy Proposal (Organisation-LIR Clarification in IPv6 Policy) Dear AP WG, On Thu, Feb 22, 2018 at 03:34:25PM +0100, Marco Schmidt wrote: > A new RIPE Policy proposal, 2018-01, "Organisation-LIR Clarification in IPv6 Policy" is now available for discussion. This policy proposal was prompted by the discussion at the last RIPE meeting, where the NCC brought up the issue that the IPv6 allocation policy talks about "organization" without ever defining what that is - "one LIR account", "one legal organization" (which can hold multiple LIR accounts), etc. Jordi volunteered to clean up the text, and here's the proposed changes - but without some feedback from *you*, we can't clean this up. [..] > We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 23 March 2018. Thus: feedback please. Like - "the text matches the original intent as I have always understood the policy, and we should go there" - "this is not my understanding of the original policy, because ..." - "never touch a working policy!" - "I do not see this as a big problem, but the new text works for me" Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: 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 ** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: [address-policy-wg] IXP peering lan reachability
Hi, On Tue, 24 Oct 2017, Nick Hilliard wrote: Gert Doering wrote: The *absence* of the route is a very strong indicator that no other services than directly peering-related are sitting on that network, no? or that the holder is squatting the space, or that it's being used for connectivity which is unrelated to the standard DFZ (e.g. l3vpn p2p addressing), or that it's just not being used at that time, or... By all means, the RIPE NCC should flag things as a problem if it sees server farms configured on an assigned ixp range, or sees traceroutes ending up in residential customer, or whatever, but the presence or absence of a prefix in the dfz, per se, does not mean anything. I understand it as a simple clue. Clues sometimes lead nowhere... Btw, is the NCC already monitoring this address space's usage somehow? (i may have missed this bit from Andrea's presentation, i didn't catch it from the beginning). Or we are simply relying on stat.ripe.net, atlas, and the like...? Cheers, Carlos Nick
Re: [address-policy-wg] IXP peering lan reachability
On Tue, 24 Oct 2017, Nick Hilliard wrote: (...) I'd politely suggest that this is an area that the RIPE NCC should not get involved in, especially from the point of view of implicitly issuing recommended practice by implying that there is a problem with doing this. The IXP associations are better placed to gather consensus for creating best practices, and there is no general consensus in the IXP community on this issue. As regards using this as a metric for determining whether an ixp address assignment is being used for legitimate purposes, I'd suggest that this is of only marginal use at best. By all means run a port scan to see if there is any obvious mis-use (e.g. services listening on www/smtp/etc), but the presence or absence of the route in the dfz doesn't mean anything one way or another. Nick CTO, INEX +1. I only have some doubts about running (regular) portscans. Cheers, Carlos
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
On Thu, 28 Sep 2017, Radu-Adrian FEURDEAN wrote:
Hi All,
Hi,
Thanks for your input!
I oppose this proposal. My reasons, or at least most of them, have
explained by other people during the last week:
- maintaining a lack of incentive for IPv6 deployment ("still have some
IPv4")
The proposal tries to remain neutral about that. But you are not alone on
this point.
- forcing desegregation, as if the problem is not bad enough already,
and possibility to make things even worse (by creating new pretext for
"longer than /24 in GRT").
Any prefix can be split into /24s and still remain globally routable.
Going beyond /24 is really not in this proposal. A new proposal would be
needed for that...
I would also add some other reasons:
- community's duty/responsibility for future generations : apart what
it has already been discussed (get v4 on the market, get it from
upstream, or even "really need to get v4 ?"), we are representing here
the RIP*E* community, with limited geographical scope. However, the
policy is quite lax at the moment concerning the out-of-region use of
resources, basically allowing an out-of-region entity to get resources
with a sole promise to use *some* of them in-continent.
If you disagree with the current "lax" status, why not build a new
proposal? We don't need to address everything with just one proposal...
- this brings us to the next point : with RIPE region being for the
moment the second-richest RIR (v4-wise) and the lax rules regarding
out-of-region use, I would not like RIPE NCC to become the world's
"last resort" registry for v4 resources (or any other resources for
that matter).
It's a valid viewpoint. I would also agree with "less lax", but that would
be a different proposal.
And if I were to agree with the proposal (which is not the case right
now), I would say that some thresholds should be used. Like /10 or /11
available for /23 allocations and /12 available for /24. Under no
circumstance /24 now.
I can also agree with that, but it's just a matter of sizing it. If v2.0,
v3.0, v4.0, ... is eventually approved/adopted, it may be that there isn't
a /12 to do this anymore...
So, we really didn't focus in the task of establishing
barriers/boundaries. But we might consider this for v2.0, if it helps. :-)
Best Regards,
Carlos Friaças
--
Radu-Adrian FEURDEAN
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi George, All, On Tue, 26 Sep 2017, George Giannousopoulos wrote: Hello all, I see pros and cons for both accepting this proposal and rejecting it. One thing I'm curious about.. ARIN has run out of IPv4 space.. They had this... https://www.arin.net/policy/nrpm.html#four10 == 4.10 Dedicated IPv4 block to facilitate IPv6 Deployment When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous /10 IPv4 block will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications. This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block. In order to receive an allocation or assignment under this policy: 1. the applicant may not have received resources under this policy in the preceding six months; 2. previous allocations/assignments under this policy must continue to meet the justification requirements of this policy; 3. previous allocations/assignments under this policy must meet the utilization requirements of end user assignments; 4. the applicant must demonstrate that no other allocations or assignments will meet this need; 5. on subsequent allocation under this policy, ARIN staff may require applicants to renumber out of previously allocated / assigned space under this policy in order to minimize non-contiguous allocations. == Has this stopped any new startup from doing business or what? Would like to read about that, in the 1st person. Are new startups getting info about IPv6 when they solve (partially or totally) their issues by buying or renting IPv4 address space? -- if they build entirely/exclusively on IPv4, the global pit is getting deeper... (i.e. we know that when a new entrant becomes a LIR, he is going to hear about IPv6...) Thanks, Carlos -- George
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Rene, Much appreciated! The projected dates you mentioned are very useful! Best Regards, Carlos Friaças On Tue, 26 Sep 2017, Rene Wilhelm wrote: Hi Carlos, All, On 9/23/17 1:02 AM, Carlos Friaças wrote: [...] do we know how many LIRs eligible under the current policy have not yet asked for a final /22? -Peter Thanks for that question! Looking at the alloclist from today, and filtering for RegIDs, i can count: 16354 (hmmm... # on https://labs.ripe.net/statistics is 16825, seems i'm mising something...) But anyway... the number of IPv4 /22s is 15391. From that number: 195 in Sept/2012 after the runout date. 595 in Q4/2012 (runout was in september) 1854 in 2013 2441 in 2014 3178 in 2015 3258 in 2016 2429 in 2017, so far. So, 13950 /22s between Q4/2012 and today, hence i would say your answer is around 2404 LIRs (16354-13950). ps: Someone at the NCC might have looked deeply into this, or not. :-) We last looked at this in detail at the start of the year, when we reached the 15000 LIRs milestone.See the RIPElabs article at https://labs.ripe.net/Members/wilhelm/15-000-local-internet-registries Redoing that analysis today, I find 4075 LIRs which do not have a final /22 allocation.3598 of these were established before 14 Sep 2012. The average allocation rate in the last 1.5 years was 9.1 /22s per day. At this rate the original last /8 (185/8) will be fully allocated in about 9 months, in June 2018.The rest of the currently available IPv4 space would last until January 2021. Occasional reclaims and deregistrations of IPv4 space of the size we've seen in the recent past could postpone full runout with a few more months, until July 2021. Best regards, -- Rene
Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
On Mon, 25 Sep 2017, Arash Naderpour wrote: Hi Daniel, Hi, you still pay only *membership* fee. It's not a per-IP cost, even if it can look like that. Old resource holders pays similar fee independently from number of IP addresses they hold. RIPE NCC members can change this charging scheme, right? It was not like this always... You are correct: RIPE NCC members. This group is not a perfect match with the community that discusses and builds up policies :-) One of goals is *conservation*, and initial assignment of /24 helps with that - and not each new LIR really needs /22. There're lot of organisationss having single /24 (old PI allocations) from the past and they're still happy with that. These were allocated to end users, are routed and also nobody concerned about routing table size. Since posibility of PI alocations was ceased, new organisations have to become "full LIR" - and then you receive /22, automatically - even you don't need it. We're simply wasting limited addres space here - just because something "simplified" and "automated". An org will not be limited to /24 even with this proposal; they can open additional LIRs to get more. Yes, 2017-03 v1.0 doesn't try to limit that -- if i understood correctly, some people disagree, and think it should. Or register a new business if RIPE NCC bans multi LIR again. I guess only the RIPE NCC GA can do that, not RIPE NCC itself. It is not easy to say that we are wasting limited address space by allocating /22, the ones need less than an /22 can transfer their free blocks to others who are in need (even new entrants) in need, or not (if they are only trying to stockpile for later...) after two years or lease them immediately. Yes... that's current policy, and 2017-03 doesn't touch that. Maybe there are some LIRs don?t fully utilize their /22 as soon as they receive the allocation, but what about the ones got their allocations before last /8 policy, are they all fully used? Of course not. The actual wasting was done somewhere else years ago, and nobody cares about that now. There is also the issue with "refurbished" address space... apart from the issue that IPv4 address space now has value, so creating a new rule/policy to "extract" it frow its current owners is quite inimaginable... :-) Regards, Carlos Friaças Regards, Arash
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi Riccardo, All, Thanks for your input. Please see inline. On Sun, 24 Sep 2017, Riccardo Gori wrote: Dear all, I started as an ISP early 2015 and I still consider myself a new entrant. That's not my definition for "new entrant". Strictly i consider a new entrant as an organization which doesn't own any IPv4 or IPv6 address space. Loosely, it can be a new LIR (before getting its /22 and an IPv6 block under current policy)... But, luckly the community approved a policy for the last /8 long before 2015. If that didn't happen, your only solution would have been to rely on the market. In the last 2 years I heard about a couple of time "no more IPv4 policies let's go over and think how to fix/help IPv6 rate adoption" but today we are still here complaining what's the best way to last longer with the agony. Is "no more IPv4 policies" written in stone somewhere? :-) Fix IPv6 rate adoption by policy? Let's call our countries' telecom regulators, and ask for a policy that prohibits IPv4 usage from day X onwards? -- i don't think so... For Ipv6 RIPE NCC is doing its best with training and is really appreciated +1 on that! and I learned here that we tend to not mix IPv4/6 policies but I really expected incentives from the cummunity not obstacles. The "IPv6 Requirement for Receiving Space from the Final /8" was abandoned 23/10/2014 by the adoption of 2014-04 proposal Looking back now, was that a good decision...? while this 2017-03 proposal aims to last as longer as possible with IPv4. Should we tweak it, and make it more "stricter", in a way the address space is (automatically?) returned if it's not being used in v4/v6 translation mechanisms...? (and do we have means to check that?) Looks to me that we are trying to save future generation from ice melting saving oil tanks instead of working on research and incentives to clean energies. Incentives cost money -- taxpayers' or consumers' money (or both!) I don't see even any reason to save more address space than the current policies does 'casue we have "trasfert policies" Transfers of last /8 slices are still allowed after 24 months -- should that possibility end...? (2017-03 v1.0 doesn't address transfers) for almost any kind of IP resource and if there are some restrictions on new allocation there are more flexible for legacy space. The RIPE community (through the NCC) only provides services to legacy space holders (and there was a proprosal for that... 2012-07). The RIPE community is not able to design policies regarding address space which was distributed before the NCC's creation. Today you can simply choose to go RIPE or market as your feeling to get IPv4/6 if needed. If the choice is going to the "market" (and if you are in strict sense a new entrant), the "market" will not advocate you should use/deploy IPv6. On the other hand, if the choice is becoming a LIR, you will get that... :-) My small router deals today with more than 2.5 million routes (2 full routing tables and some IX) and it really takes time to backup and even routing performance are affected by volume of routes. I think we should propote IPv6 for route aggregation ability. There is also de-aggregation in IPv6-land. :-( (http://www.cidr-report.org/v6/as2.0/) People will mess up routing as the rest of the world lets them... I see this policy as: - an obstacle to IPv6 That was not the goal. The goal was to extend v4 availability for some more time, thus making life easier for IPv6 deployments that will still need to talk with the v4 world. - a clear side effect of market price rise on IPv4 This proposal is not about the "market". a /24 can cost X, Y or Z over time. The only way we can keep "affordability" for new entrants is by defining what they get from the NCC, not from any 3rd party. - a disincentive to route aggregation I don't agree. /22s (and bigger chunks) are already being announced as /24s. What we consider is that keeping the "affordability" for new entrants is a bigger priority than keeping the DFZ on 683k (today) instead of 725k, 750k or even 800k routes. I know 800k routes looks insane, but two years ago 683k would have been equally insane :-)) ps: On 24-09-2015 (two years ago), 572876 routes https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/ Thanks! Best Regards, Carlos Friaças That's why I oppose this policy kind regards Riccardo -- Riccardo Gori
Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi, On Sat, 23 Sep 2017, Nick Hilliard wrote: Willy MANGA wrote: So again, why do they rely on v4 (only) ? I really want to understand hurdles on european continent. I hope this time, it will be clearer :) same reason as in africa: for most organisations it's too much work with too little return. Or in any other part of the world... Many humans will only react after a crisis hits, even if the cost of that is higher overall. Exactly! Cheers, Carlos Nick
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi, On Sat, 23 Sep 2017, Kai 'wusel' Siering wrote: (...) Where does this 'responsibily' end? Don't know, but still feel we should try for the coming years. When will be "well, the IPv4 well dried out back in 2011; It didn't completely (even today), but the RIPE NCC service region entered "scarcity-mode" in Sept'2012. it's now just done, you're simply too late" a 'responsible' answer? If not 2020/2021 (as based on current prediction), how about 2022? 2030? 2080? If two years of more v6 deployment help, there is some benefit. If it's 10 more years, great. v6 deployment is slow -- that we know. When do we distribute 240/4 among the RIRs as "really last /8s"? I made that question myself during an ICANN meeting (the only i attended) 10 years ago. The answer was something about operating systems' stacks. I wasn't fully convinced, but a large majority of internet plumbers seems to buy it... Seriously, this is ridiculous. IPv4 is done. For expanding the Internet, sure. There is however, a tiny annoying bit: IPv4 is still the dominant Internet Protocol version in terms of usage :/ "get over it. get a life." And deploy IPv6. Been there, done that. Sometimes i see some of it going back to IPv4-only, though :( And the biggest issue, we can't really force 3rd parties do deploy it. If some of those 3rd parties don't need to grow their infrastructures, the "incentive" to deploy IPv6 is really small :/ Actually a common tune[1] a decade before today already ;) I actually was in the room when that happenned! :-)) On 26th Oct'2007 [1][2]. [1] https://www.ripe.net/participate/meetings/ripe-meetings/ripe-55 [2] https://www.ripe.net/participate/meetings/ripe-meetings/ripe-55/attendee-list Thanks for your input. Cheers, Carlos Regards, -kai [1] https://www.youtube.com/watch?v=_y36fG2Oba0
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Hi, <2017-03 co-author hat on> "Access" is not the aim of this policy proposal. Afaik, there was already a proposal which had some common points with what is described below, and it didn't get anywhere then. Regards, Carlos Friaças On Fri, 22 Sep 2017, n...@kwaoo.net wrote: Maybe the right path is to find some way to allocate those addresses to real new entrants only Perhaps limitations like only one allocation: - per LIR - per legal entity - per physical person - per "network", "activity" or whatever, & based on how you should have your own resources Anything that can allow the RIPE to say : "nope, you're obviously trying to get more stuff from us, you got your part, we deny this allocation" This way, the last ressources' purpose will be filled properly, and not scavenged by greedy guys Regards, On 22/09/2017 09:04, Carlos Friaças wrote: This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for new entrants in this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs, and we can then count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space. -- Jack Net/sys admin More details about KWAOO can be found at: https://as24904.kwaoo.net/
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
On Fri, 22 Sep 2017, Arash Naderpour wrote: Hi Carlos, Hi, This proposal is not aimed at preventing the complete runout. That will happen. This proposal aims to preserve some tiny resources for new entrants in this community, by trying to extend the time period until the runout occurs. We cannot "measure" its benefits until the runout occurs, and we can then count how many new entrants did get a tiny portion of (new, never used before) IPv4 address space. The current policy without this change is doing the same, preserving tiny resources (/22) for new entrants. You are saying that there are some benefit and we cannot measure them now, but lets do it, am I right? I'm saying there is an obvious benefit: accomodate more new entrants. Because an org is able to have/open multiple LIRs, the real new entrants number is not really easy to calculate :-) Even if there is a need, it could be 3x/24 or /23.why change it from /22 to /24? Yes, a /23+/24 or a /23 would be a step in the right direction. If, at global level, a /25 or a /26 was acceptable (routing-wise), then that would be even better. I would also like to draw your attention to the last section about "Alignment with other RIRs": LACNIC already has this in place. ARIN has something, which isn't really exactly the same, but the main goal is very similar. :-) Still unanswered, why /24 not a /23+/24 or a /23? Going to a /24 will potentially accomodate more new entrants than a /23 or a /23+/24, and definitely more than the currently /22. A /25 or a /26 are not feasible as of today. Not sure if it will ever be. what is the benefit of this "Alignment with other RIRs" to the RIPE community? I don't see any need for that too. Just to let everyone know we are not "innovating" nothing here. Different communities already took this step towards extending the period where "new entrants" are able to get some IPv4 address space. Regards, Carlos Friaças Regards, Arash Arash On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown <t...@ecs.soton.ac.uk> wrote: > On 21 Sep 2017, at 13:33, Aled Morris <aled.w.mor...@googlemail.com> wrote: > > On 21 September 2017 at 12:43, Marco Schmidt <mschm...@ripe.net> wrote: > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? There?s http://www.potaroo.net/tools/ipv4/. Tim
Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
On Fri, 22 Sep 2017, Aleksey Bulgakov wrote: Hi. Hi, I think it would be better to allocate /19 or bigger. It helps to go to IPv6 and the problem of IPv4 is resolved automatically. I'm really not sure about that. It won't solve any new entrant's case. I'm working around IPv6 since 2001. Anna and Randy probably since before that. We have deployed IPv6. It didn't enable us to completely get rid of IPv4 within our networks. That also didn't solve any issue for 3rd party networks -- they all still need IPv4 addresses. I don't really understand why the NCC tries to prolong the life of the dead patient by means of restrictions such as 2015-01, 2017-03 and others. Please note 2017-03 is not approved yet. Please also note that the NCC is not authoring this proposal. There was a presentation about this issue in Budapest at RIPE 72. Randy talked about building a new proposal then, and it took some months to put it together. :-) It seems the NCC wants to earn money due to the IPs become more expensive. I don't really think this is the case. The main goal here is to preserve a minimal chunk of space for new entrants. And today, a /24 is the "minimal acceptable" size for that. So I oppose this proposal. Noted. Regards, Carlos Friaças 22 ???2017 ?.7:50 "Mikael Abrahamsson" <swm...@swm.pp.se> ???: On Thu, 21 Sep 2017, Tim Chown wrote: At the current run-rate, do we know what is the expected expiry of the free pool in RIPE's hands? There?s http://www.potaroo.net/tools/ipv4/. There is also: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? To me it looks like things are going according to plan, and I don't see any need to change anything. -- Mikael Abrahamsson email: swm...@swm.pp.se
