mornin' leo

...

- the address space MUST be returned to the NCC as clean or cleaner than when it was loaned out

This is a nice idea. Do you have a practical proposal for implementation?

depends on if/how you mess it up. and if you can not describe this to the ncc reg folk, they should not give you the space. camper saying" if you pack it in, pack it out randy

...

for a research experiment, we wanted eight or a dozen routable, i.e. /24, prefixes which we would announce from various places in the topology. each /24 would have one pingable address, let's assume .42.

This is a tough nut.

I can totally see what you do, and understand what space you need, and for which times.

OTOH, I can totally see the NCC being worried about people claiming "experiments! and I need a review!" and running their ISP for a year on temporary space - and with the argument "I want a dozen routable /24s", you can get quite some ISP work done.

the current policy requires description, documentation, ... already. this point merely adds to the spec to allow the ncc to issue frags if a block is not needed.

have you enabled IPv6 on something today...?

nope randy

I'm not convinced that we should "today", provide IPv4 temporary assignments, neither for conferences or experiments. A conference can perfectly survive today with a single IPv4 public address (or very few of them) from the ISP providing the link (even if running BGP), using 464XLAT, so the participants get dual-stack in the same way they are used to (private IPv4 addresses) and they also have global IPv6 addresses. This can be made with pure open source in a VM (if the provider doesn't have a NAT64, it can be also in the VM, in addition to the CLAT support, both using Jool, or other choices), etc. It is very well proven. Now, regarding to experiments, I don't think we should keep doing IPv4 experiments anymore and in the case it is really needed, I think it should be possible to obtain the required addresses from the DCs where the experiment will be co-located. So, in short, I think if work is done, it makes more sense to send this policy to "historic", at least deprecating the IPv4 part. I'm happy to work on that with a proposal, which seems to be very simple to do. Regards, Jordi @jordipalet El 27/1/22 15:45, "address-policy-wg en nombre de Angela Dall'Ara" <address-policy-wg-bounces@ripe.net en nombre de adallara@ripe.net> escribió: Hi Gert, Randy and Leo, Thank you for dedicating attention and time to ripe-587, as this policy became more topical since the IPv4 run-out. The requests for temporary assignments are always evaluated by the RIPE NCC on a case-by-case basis, and the current text of the policy presents some challenging aspects for the approval. Requests related to conferences and events generally include a documentation that can easily show the utilisation of the addresses and the time of the assignment. Sometimes there is some time pressure due to last-minute submissions and there were few occasions when organisers would have preferred more than the policy limit of two months, but overall this part of the policy is sufficiently clear for the RIPE NCC. The requests for research and testing are posing challenges for the approval against the required address utilisation (50%) stated in the policy, when this cannot be reached due to the nature of the research/experiment/test. We also receive requests where the temporary assignment purpose appears to be part of a standard network setup as the test/experiment/research is motivated with the need of configuring and testing a protocol or a feature that is new to the requester's network while being already widely used in other ones. Many of these requests come from the requester's interpretation of the policy. While the policy cannot cover all cases, a review of the technical requirements, time limits and address utilisation would be beneficial to facilitate the RIPE NCC’s assessment of different requests. Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer On 26/01/2022 18:32, Gert Doering wrote: > Hi, > > On Tue, Jan 25, 2022 at 09:33:40AM -0800, Randy Bush wrote: >> ok, i did it again, tried to fit a square peg in a round hole. while >> the immediate problem is past, thanks to the ncc reg folk, i fear that >> we could benefit from thinking a bit more about $subject. >> >> for a research experiment, we wanted eight or a dozen routable, i.e. >> /24, prefixes which we would announce from various places in the >> topology. each /24 would have one pingable address, let's assume .42. > This is a tough nut. > > I can totally see what you do, and understand what space you need, and > for which times. > > OTOH, I can totally see the NCC being worried about people claiming > "experiments! and I need a review!" and running their ISP for a year > on temporary space - and with the argument "I want a dozen routable > /24s", you can get quite some ISP work done. > > [..] >> i am considering a policy proposal in this space; but want to learn what >> others see and think, and to see if it is worth the time and effort. > I want research and conferences and all these things to be possible, > with temporary address space, and policies to be fairly liberal for > "those good things". > > The NCC needs checklist-able items to say "this is okay" and "that is > way too much space, you do not need a /16 for 6 months to run a > conference with 1000 attendees for a week. > > How to codify this? Dunno. > > Marco, Angela - what's your take on this ("feedback from RS" time)? > > Gert Doering > -- 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 ********************************************** 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.

Given that there seem to be people that actually get work done in their research, using IPv4 because not all vantage points have IPv6 yet, and that the existance of this policy seems to do little harm, I'd strongly object to such a proposal.

This is not the place and time to go on an anti-IPv4 crusade.

+many Cheers, Sander

Dear apWG members, Hope this email finds you in good health. Please see my comments below, inline... Le jeudi 27 janvier 2022, JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg@ripe.net> a écrit :

I'm not convinced that we should "today", provide IPv4 temporary assignments, neither for conferences or experiments.

Hi Jordi, Thanks for your email, brother! ...imho, maybe you should, if you consider a Tech conference where you try to teach your attendees how to build a transitional network based on the 464XLAT approach... ;-)

A conference can perfectly survive today with a single IPv4 public address (or very few of them) from the ISP providing the link (even if running BGP), using 464XLAT, so the participants get dual-stack in the same way they are used to (private IPv4 addresses) and they also have global IPv6 addresses.

...sure, but please see the usecase presented above.

This can be made with pure open source in a VM (if the provider doesn't have a NAT64, it can be also in the VM, in addition to the CLAT support, both using Jool, or other choices), etc. It is very well proven.

Jordi, maybe this is a good case for a BCOP? :-/

Now, regarding to experiments, I don't think we should keep doing IPv4 experiments anymore and in the case it is really needed, I think it should be possible to obtain the required addresses from the DCs where the experiment will be co-located.

...i'm understanding the above as: *we* should not keep *supporting* IPv4 experiments anymore within this RIR. That's not a PoV i actually want to support, brother.

So, in short, I think if work is done, it makes more sense to send this policy to "historic", at least deprecating the IPv4 part.

...imho, the RIPE-587 appears to be really useful... It covers almost all the situations which may occur in regard to temporary INRs. Sure, there are things/aspects to improve but i'm not sure to understand why the specific request for experiment shared by Randy can not be handled through it :-/ Please, someone to explain it to me :'-( ~°~ " For longer term projects and research purposes, the number resources may be issued on a temporary basis for a period of up to six calendar months, or one month longer than the expected life of the project/research/experiment, whichever is shorter. In the case where an End User requires number resources for research purposes, and where the research project details are made public upon registration of the number resources by the RIPE NCC, and where the End User commits to making public the results of their research project free of charge and free from disclosure constraints, then the requested number resources may be issued for a period of up to one calendar year. At the RIPE NCC's discretion renewal of the registration of the resources may be possible in exceptional circumstances on receipt of a new request that details continuation of the End User's requirements during the extended period. Should this request be denied by the RIPE NCC, an appeal may be made using the RIPE NCC Conflict Arbitration " https://www.ripe.net/publications/docs/ripe-587#:~:text=For%20longer%20term,... ~•~

I'm happy to work on that with a proposal, which seems to be very simple to do.

If there is interesting details to improve i'm also a taker. Given that it recalls me that i promised to work on the similar DPP (Draft Policy Proposal) within the AfriNIC's service region :-) Blessed new year 2022! ...one year less, under the era of LORD's Grace! Shalom, --sb.

Regards, Jordi @jordipalet

El 27/1/22 15:45, "address-policy-wg en nombre de Angela Dall'Ara" < address-policy-wg-bounces@ripe.net en nombre de adallara@ripe.net> escribió:

Hi Gert, Randy and Leo,

Thank you for dedicating attention and time to ripe-587, as this policy became more topical since the IPv4 run-out.

The requests for temporary assignments are always evaluated by the RIPE NCC on a case-by-case basis, and the current text of the policy presents some challenging aspects for the approval.

Requests related to conferences and events generally include a documentation that can easily show the utilisation of the addresses and the time of the assignment. Sometimes there is some time pressure due to last-minute submissions and there were few occasions when organisers would have preferred more than the policy limit of two months, but overall this part of the policy is sufficiently clear for the RIPE NCC.

The requests for research and testing are posing challenges for the approval against the required address utilisation (50%) stated in the policy, when this cannot be reached due to the nature of the research/experiment/test.

We also receive requests where the temporary assignment purpose appears to be part of a standard network setup as the test/experiment/research is motivated with the need of configuring and testing a protocol or a feature that is new to the requester's network while being already widely used in other ones. Many of these requests come from the requester's interpretation of the policy.

While the policy cannot cover all cases, a review of the technical requirements, time limits and address utilisation would be beneficial to facilitate the RIPE NCC’s assessment of different requests.

Kind regards, Angela

-- Angela Dall'Ara RIPE NCC Policy Officer

On 26/01/2022 18:32, Gert Doering wrote: > Hi, > [...] >

-- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

Hi Marcus, I don't think any RIR is in a position to reserve space for a conference/event with thousands of participants bringing their own multiple devices and allowing public addresses for each one. Even many ISPs will not be able to do that! With 464XLAT you don't really need that, and the effect "for the participant devices" is the same as having NAT or CGN, with the advantage that they will also get global IPv6 addresses (as many as they want for every device if they deliver /64 per host as per RFC8273). In section 3.4 (IPv4 Pool Size Considerations) of https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/ (which has been already submitted to the IESG for publication), you can find a simple calculation that demonstrates that a /22 (IPv4) can server, for example, over 275.000 subscribers (devices in a conference), in the worst case. Saludos, Jordi @jordipalet El 7/3/22 12:32, "address-policy-wg en nombre de Marcus Stoegbauer" <address-policy-wg-bounces@ripe.net en nombre de marcus@grmpf.org> escribió: Apologies for the late reply, I'm just catching up with my mailing lists.. On 27 Jan 2022, at 16:44, JORDI PALET MARTINEZ via address-policy-wg wrote: > I'm not convinced that we should "today", provide IPv4 temporary assignments, neither for conferences or experiments. > > A conference can perfectly survive today with a single IPv4 public address (or very few of them) from the ISP providing the link (even if running BGP), using 464XLAT, so the participants get dual-stack in the same way they are used to (private IPv4 addresses) and they also have global IPv6 addresses. This can be made with pure open source in a VM (if the provider doesn't have a NAT64, it can be also in the VM, in addition to the CLAT support, both using Jool, or other choices), etc. It is very well proven. A conference is not a very well defined term. I agree with your assessment for conferences like RIPE meetings, NOGs and so on. However, also events like Chaos Communication Congresses (https://events.ccc.de/congress/2019/wiki/index.php/Main_Page as an example) have the word conference in it. And those are events with >15,000 users, stretching over almost a week, where each participant is bringing multiple devices. Here you won't simply use one or even a handful of public IPv4 addresses for translation, but rather want a public IPv4 address per device. In short: I still see a need, also for shorter temporary assignments for conferences like this. Marcus-- 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 ********************************************** 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.

Dear APWG, Here is an overview of the requests for temporary IPv4 assignments we have received over the past five years. Since 1 January 2017, we received 275 requests in total. 56 of these were approved (43 for conferences/events and 13 for research/tests/experiments). Looking at this closer: - Before IPv4 “run-out”: we received 171 requests over a period of 35 months, from 1 January 2017 to 24 November 2019. 38 of these requests were approved (33 for conferences/events and 5 for research/tests/experiments). There was an average of 4.9 requests per month and an approval rate of 22.2%. - After IPv4 "run-out": we received a total of 104 requests over a period of 26 months, from 25 November 2019 until today, 4 February 2022. 18 of these requests were approved (10 for conferences/events and 8 for research/tests/experiments). There was an average of 4 requests per month and an approval rate of 17.3%. One request is still ongoing. Of the 85 requests that were rejected, 6 were for conferences and 79 were for research/tests/experiments. Reasons for rejection of the 6 requests for conferences and events: - 1 was cancelled by the requester for administrative reasons - 1 duplicate request - 2 cancelled conferences/events - 2 undocumented conferences/events Reasons for rejections of the 79 requests for research/tests/experiments: - 6 were for network migrations to IPv6 or renumbering due to failover, DDoS attack, etc - 8 were not adequately documented - 18 were for testing on the requestor’s own network (CGNAT, BGP, Anycast, NAT,...) - 47 were due to the requestor seeking to extend their network (new customers, services, data centers, etc) The total number of requests hasn’t really changed after IPv4 "run-out". We can see that COVID-19 impacted the number of requests for conferences/events. These are generally well documented and usually approved. In these cases, the 50% utilisation requirement in the policy helps define the assignment’s size. On the other hand, this requirement, as well as the maximum time limit of one year, can interfere with the approval of requests for research/tests/experiments that are properly documented and within the policy’s scope. The number of rejected requests for research/tests/experiments has increased recently, as the majority were to perform testing or migration in the requester's network or to temporarily extend it. We see that initial applications and objections after rejection often refer to the current text of the policy, which leaves room for different interpretations about the scope of testing. Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer On 28/01/2022 12:59, JORDI PALET MARTINEZ via address-policy-wg wrote:

That look to me as a good approach.

That will be a good way to handle "really needed" IPv4 experiments, which I don't think are relevant anymore, but I'm happy to support if there are good and needed cases considering the good of the overall community.

The negative part is the overhead of the panel selection, etc.

In any case, I'm still for not having temporary delegations of IPv4 for conference, I don't think there is a excuse for that today.

May be the NCC can tell us, in the last 10 years or so, how many IPv4 temporary assignments have been provided for both, conferences, experiments, and "other" cases (if there have been)?

Regards, Jordi @jordipalet

El 28/1/22 12:21, "address-policy-wg en nombre de Daniel Karrenberg" <address-policy-wg-bounces@ripe.net en nombre de dfk@ripe.net> escribió:

I have the strong suspicion that this is another example of trying to codify special/corner cases. Doing this takes disproportionate amounts of energy and causes an ever increasing amount of undesired side effects.

<shields up>

How about giving the RIPE NCC discretion to make sensible decisions about the corner case ‘scientific experiment’ after getting advice from a panel of scientists? Or delegating the decisions to such a panel?

This way we could avoid spending energy on codification and avoid the undesired side effects. We would just need to find a couple of credible people to review the requests. I expect this to be less work than codification and re-codification …

Daniel

--

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

********************************************** 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.

On 28 Jan 2022, at 11:20, Daniel Karrenberg <dfk@ripe.net> wrote:

How about giving the RIPE NCC discretion to make sensible decisions about the corner case ‘scientific experiment’ after getting advice from a panel of scientists? Or delegating the decisions to such a panel?

This would be a pragmatic, common sense solution. However I fear it would open up a new rat-hole for yet more shed-painting. Says me mixing my metaphors... There would be endless discussion on how this panel of experts gets chosen and who’s eligible or not, how they’re accountable (and to whom), who gets to choose, what the appeals process should be and how that’s invoked, etc, etc. Which brings us back to the point you made yesterday Daniel: huge amounts of effort for very little reward. I hope a pragmatic, common sense solution can be found. If not, I think we should just freeze the current policy on v4 and reject any further proposals unless there is a unanimous community consensus to reopen that can of worms. IMO v4 is done. Get over it.

Hi, On Thu, Feb 03, 2022 at 08:40:10AM +0100, Eliot Lear via address-policy-wg wrote:

I like the idea of the NCC (specifically RIPE Labs) just allocating to themselves a small block of v4 and another of v6 for experiments, and then delegating portions or the whole of the block for bounded experiments, keeping the paperwork and process to a minimum. Also, RIPE could perhaps extort a good talk out of the researchers once the results are published ;-)

"The policy is too complicated, just circumvent it" is not the way we try to handle policy in RIPE land. If it is so, we try to fix the policy (or the process). That said, there is no way the RIPE NCC could assign a reasonably *big* block of IPv4 - to have multiple /24s available for routing - to itself under current policy anyway. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Thu, Feb 03, 2022 at 11:36:53AM +0100, Eliot Lear wrote:

...

On Thu, Feb 03, 2022 at 08:40:10AM +0100, Eliot Lear via address-policy-wg wrote:

...

I like the idea of the NCC (specifically RIPE Labs) just allocating to themselves a small block of v4 and another of v6 for experiments, and then delegating portions or the whole of the block for bounded experiments, keeping the paperwork and process to a minimum. Also, RIPE could perhaps extort a good talk out of the researchers once the results are published ;-)

"The policy is too complicated, just circumvent it" is not the way we try to handle policy in RIPE land. If it is so, we try to fix the policy (or the process).

First, it???s not clear to me that this is a stretch from existing RIPE policies, but perhaps you could explain the gap.

"The NCC allocating to itself" is very clearly governed by RIPE policies today, and is a special case with extra checks and measures. So, if "the NCC gives address to experiments, according to the temporary address policy" is too complicated, suggesting "the NCC allocates to itself, and then can use that freely without all that paperwork" is something I'd interpret as "circumventing the policy".

But otherwise, I agree I could have stated that better. I was aiming at a policy that empowers the NCC to provide such temporary or research allocations as they deem appropriate so long as they don???t impact address space or routing table growth or otherwise risk security of others.

That is what we have, the current "Temporary Internet Number Assignment Policy", ripe.net/publications/docs/ripe-526 - it does that, but as Randy noticed, it has clauses in there that are hard to fulfill for routing experiments ("50% usage" in 3.3). I *do* like the suggestion Daniel Karrenberg made how to tackle this - give the NCC more liberty how to handle "experiments" by consulting, if needed, with an expert panel. I do see the issue in defining "expert", but maybe this could be made sufficiently lightweight - "ask for a volunteer group of individuals that have had hands-on experience with BGP routing for <n> years" (because, I think, that's really the crucial part here, to differenciate from other setups that can do the 50% just fine, or use RFC1918 space instead). I'd volunteer, I'm good at not-liking things :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

I *do* like the suggestion Daniel Karrenberg made how to tackle this - give the NCC more liberty how to handle "experiments" by consulting, if needed, with an expert panel. I do see the issue in defining "expert", but maybe this could be made sufficiently lightweight - "ask for a volunteer group of individuals that have had hands-on experience with BGP routing for <n> years" (because, I think, that's really the crucial part here, to differenciate from other setups that can do the 50% just fine, or use RFC1918 space instead).

you are a (new) LIR applying for IP space. you submit an addressing plan. the ncc convenes a volunteer panel of your competitors to evaluate that plan. oops! tragically, research is competitive, and the ideas are the protein. [ fyi, i admit to being just a shill here. it was reg services who asked for help on the issue. ] randy

erik,

I think that the time for the temp assignment to be made, stretched to 1 year or more, will become an issue for the NCC to work with.

the current policy allows the ncc to go up to a year

Not only of the point that Gert made, but also because it will make the life of the IPRA's must harder with the time that we add..

actually, it is the reg folk who raised these issues to me

As we can also expect more requests to be made, if the policy would be changed ...

this statement might benefit from some explanation

As this is for research .. have you considered working with other research networks that hold large amount of numbers because they were NIR's before RIPE was setup ?

i can not speak for other researchers. but when my work can be done with existing allocations we use them, of course. we have done this a lot. in the particular case i hit, the nature of the experiment required space directly delegated from the ncc. randy