Hi, I don't see a need to do this change in the policy at the moment. consummation rate is the same as before. Even if there is a need, it could be 3x/24 or /23.why change it from /22 to /24? Arash On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:

...

On 21 Sep 2017, at 13:33, Aled Morris <aled.w.morris@googlemail.com> wrote:

On 21 September 2017 at 12:43, Marco Schmidt <mschmidt@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

Hi Carlos,

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?

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? what is the benefit of this "Alignment with other RIRs" to the RIPE community? I don't see any need for that too. Regards, Arash

Arash

...

On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote: > On 21 Sep 2017, at 13:33, Aled Morris < aled.w.morris@googlemail.com> wrote: > > On 21 September 2017 at 12:43, Marco Schmidt <mschmidt@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

Hi Carlos,

...

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 :-)

My understanding from this proposal is that it just change the allocation size but an org is still able to have/open multi LIRs, If this proposal reach consensus, someone still can open four LIRs and get the same amount of IP address as now. The difference (from technical point of view) is that we may have less entry in routing tables with an /22 allocation but with this proposal we will have for sure 4x /24 entry without gaining that much. Regards, Arash

Regards,

...

Arash

Arash

On Fri, Sep 22, 2017 at 12:34 AM, Tim Chown < tjc@ecs.soton.ac.uk> wrote: > On 21 Sep 2017, at 13:33, Aled Morris < aled.w.morris@googlemail.com> wrote: > > On 21 September 2017 at 12:43, Marco Schmidt < mschmidt@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

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/

Yes I agree with your proposal Regards, On 22/09/2017 10:21, Carlos Friaças wrote:

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, noc@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/

-- Jack Kwaoo noc More details about KWAOO can be found at: https://as24904.kwaoo.net/

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-exhaustio... 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: swmike@swm.pp.se

On Fri, 22 Sep 2017, Randy Bush wrote:

...

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?

and you believe that there will be zero desirable ipv4 destinations on the internet by then? sure does not look like it as far as i can see.

I agree.

and if a new entrant needs to reach the remaining ipv4 internet, ...?

Then they have to buy addresses in the market. I keep running into people who claim "look, RIPE is not out of IPv4 addresses, the IPv4 exhaustion is just a hype/FUD". They won't stop until RIPE is really out. If this happens in 4-5 years, I'm fine with that. That means they had 8-10 years from we actually ran out to understand. We (the RIPE community) has had a quite balanced and approach to this and enabled new entrants in the mean time. We can't stretch this out forever. The stone is bled dry, and that's just the way it is. -- Mikael Abrahamsson email: swmike@swm.pp.se

On Fri, 22 Sep 2017, Randy Bush wrote:

people will say all sorts of stupid things; funny monkeys we are. this does not mean we should use technology to teach morality lessons. it has not worked out too well when tried.

My point is that it's useless to prolong the agony. The more we do, the longer people will procrastinate, and the more painful it becomes. /22 is a good tradeoff between the different goals here. It was a good tradeoff when it was implemented, I see it still being a good tradeoff 3 years from now. -- Mikael Abrahamsson email: swmike@swm.pp.se

On 22 Sep 2017, at 05:50, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

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

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.

I’d agree with that. The proposal does no analysis of the “run rate” of consumption, or other the impact of other RIR policies. I’d like to see that presented. Looking at https://www.ripe.net/participate/policies/proposals/2017-03/, it seems that LACNIC have moved from a /22 to a /24 policy last month (so hard to measure impact yet), and ARIN are on a last /10 policy which sees applicants get a /28 to a /24, so presumably those /28’s are routed at some level; that’s been in place for some time, how is it working out? What about APNIC and AFRINIC? The current run-out projection is 2021/22, five years away. Consider where IPv6 deployment was 5 years ago. Since then we’ve gone from ~0% deployment worldwide to ~20%, and seen a wide range of ISPs and content providers deploy, and importantly the bigger CDNs now provide dual-stack by default out-of the box. Consider where we’ll be in 5 years from now. Tim PS. Seeing “more members” as a benefit is a strange advantage to add in the proposal, given these are implicitly people gaming the system?

On 22 Sep 2017, at 13:24, David Farmer <farmer@umn.edu> wrote:

On Fri, Sep 22, 2017 at 5:04 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote: ... and ARIN are on a last /10 policy which sees applicants get a /28 to a /24, so presumably those /28’s are routed at some level; that’s been in place for some time, how is it working out? ...

This ARIN policy is in section 4.10 of ARIN's NRPM;

https://www.arin.net/policy/nrpm.html#four10

Hello WG, To shed some more light on routability of prefixes longer than /24, we started an experiment when the aforementioned policy change was being discussed at ARIN. From October 2014, we started announcing 6 prefixes from ARIN’s designated block 23.128/10. There are /24, /25 and /28 prefixes, with and without IRR objects. We then measured visibility and reachability of those prefixes both on the control plane (by looking at BGP) and on the data plane (using RIPE Atlas trace routes). You can find the original paper by Emile Aben at https://labs.ripe.net/Members/emileaben/propagation-of-longer-than-24-ipv4-p... as well as a followup in 2015 https://labs.ripe.net/Members/emileaben/has-the-routability-of-longer-than-2... and finally, a more recent followup by Stephen Strowes on 10th of July 2017: https://labs.ripe.net/Members/stephen_strowes/bgp-even-more-specifics-in-201... All the best, Kaveh. ——— Kaveh Ranjbar, Chief Information Officer, RIPE NCC.

The rationale for this is to make RIR-allocated ipv4 address space string out a bit longer by raising the price and dropping the size.

did it say anything about price? i missed that? i did not think the AP WG dealt with pricing; so it would be pretty strange.

It is not convincing to state that allocating /22s instead of /24s is an abrogation of responsibility, and as a community we should step back from this sort of overly dramatic language.

in an american dictionary, 'abrogation' ranges from lack of awareness to more intentional acts. in this proposal, it was used in relation to the occasional proposal to encourage ipv4 runout to promote ipv6, which should be able to sell on it's own merits, not schadenfreude

A more sober viewpoint is that any future decision about tweaking the balance between allocation size and anticipated run-out time is not much more than an exercise in deck-chair rearrangement. It's a deck-chair rearrangement because the ship is going down and nothing can stop it.

agreed. but we can postpone the inevitable so folk have time to get in the lifeboats. and if we can, as stewards, we have a responsibility to do so.

The proposal fails to mention the windfall that will ensue for existing address holders as the baseline RIR price for IPv4 addresses will increase from around €4.70 to nearly €19.

truth is, i have not modeled what might happen to the ipv4 market.

there are quite a few people in this WG who would be happy with this sort of change, both brokers and incumbent address holders.

and they are evil so should not allowed to be happy? :)

Because of this, we also need to consider as a community what part self-interested financial motivation is going to play in terms of whether people are going to support this proposal or not, and how compatible this is with good governance of the policy-making mechanism for global resource allocation.

i am not sure that the community remains sober enough to do so without getting nasty. i would how so, but my faith wavers.

If, as this proposal suggests, we move from a minimum routable range of /24 to /25 or longer, this is a change that comes at a cost in terms of reducing the lifetime of any routing device on the internet which takes a full dfz.

indeed. but i see it as inevitable as the need to bridge becomes more and more intense. so do we want to do it in a controlled and managed fashion or chaotically? randy

* Tom Hill <tom.hill@bytemark.co.uk> [2017-09-21 16:27]:

Over half of the table is made-up of /24s; that is not a coincidence.

If any new "standard" is chosen for the minimum visible prefix size, you can bet all of those /24 announcements will start turning into a lot more /25 announcements very quickly.

"But otherwise I'm liable to hijack!", ad infinitum.

I dunno about you, but I can see a lot of operators not being too happy with a ~25% increase in the number of prefixes they're storing in TCAM.

I think getting the DFZ to lower the minimum prefix size from a /24 is nothing more than wishful thinking. I would bet that IPv4 will run out completely before that happens. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

On 21/09/17 20:22, Randy Bush wrote:

once it was /19. welcome to life.

I think the stakes are a little higher these days. -- Tom Hill Network Manager Bytemark Hosting http://www.bytemark.co.uk/ tel. +44 1904 890 890

You're correct in saying that APWG does not deal with pricing, but it's a bit jesuitical not to acknowledge that the practical impact of this policy change will be a dramatic increase in RIR-allocated ipv4 addresses.

someone wrote to me saying the same thing. but they added that the current situation has ripe selling a public good at radically below market pricing and that this has resulted in some very asocial behavior with bad long term effects.

...

but we can postpone the inevitable so folk have time to get in the lifeboats. There is no amount of time that will be enough.

yes. but v6 is slowly catching on, and we do what we can to make the internet a better place. there is no perfect. randy

a bit of history for those with short term vision 1995, and large providers were running out of ram to hold the table. sprint was the closest to the edge and falling over; but others were not far behind and could smell the coffee. these were the days where we all intimately knew each others' networks. nobody's management was gonna pay to upgrade hundreds of routers. sean had to filter to keep from crashing. others, such as asp and i, were also filtering, as much to keep the table down as to protect from idiots such as vinnie from killing us (7007 incident). so the providers who were concerned and the rirs met at the danvers ietf and agreed to only let /19s and shorter, and swamp space /24s, through if the rirs would please not allocate longer prefixes for a couple of years until routers could be upgraded. rfc 2050 was the result. eventually, like six yesrs later, customers complained enough that the filters had to be removed. when a big customer or two wanted to get to someone with a /24 in old B space, the filters fell. business wins. when v4 runout forces folk to put /28s in frnt of nats, the folk with shiny shoes will have a little chat with senior leadership, and they'll cough up the bucks to hold the routes. history repeats. like the ethernet mfrs tell us that we need to use 4g, 40g, ... instead of 10g, 100g, 1tb, ... life adds zeros. randy

How is this related to my point (assuming this was a reply to my message in the first place)? | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Fri, Sep 22, 2017 at 10:18 AM, Randy Bush <randy@psg.com> wrote:

a bit of history for those with short term vision

1995, and large providers were running out of ram to hold the table. sprint was the closest to the edge and falling over; but others were not far behind and could smell the coffee. these were the days where we all intimately knew each others' networks.

nobody's management was gonna pay to upgrade hundreds of routers. sean had to filter to keep from crashing. others, such as asp and i, were also filtering, as much to keep the table down as to protect from idiots such as vinnie from killing us (7007 incident).

so the providers who were concerned and the rirs met at the danvers ietf and agreed to only let /19s and shorter, and swamp space /24s, through if the rirs would please not allocate longer prefixes for a couple of years until routers could be upgraded. rfc 2050 was the result.

eventually, like six yesrs later, customers complained enough that the filters had to be removed. when a big customer or two wanted to get to someone with a /24 in old B space, the filters fell. business wins.

when v4 runout forces folk to put /28s in frnt of nats, the folk with shiny shoes will have a little chat with senior leadership, and they'll cough up the bucks to hold the routes. history repeats.

like the ethernet mfrs tell us that we need to use 4g, 40g, ... instead of 10g, 100g, 1tb, ... life adds zeros.

randy

I don't see TOO any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea TOO . -----Messaggio originale----- Da: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Per conto di Daniel Suchy Inviato: venerdì 22 settembre 2017 10:09 A: address-policy-wg@ripe.net Oggetto: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) Hello, /24 is de-facto standard accepted in routing tables these days and also /24 was used in large scale during PI assignments - so I don't see any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea. But I would like to keep option for asking more than /24 (up to /22 maximum, as was decided in the past) LIRs eligible for allocation, if LIR properly documents his request. From my own practice there're some LIR, where /24 is sufficient and they just become LIRs because there's no other real option to get independent addresses (old "PI") and with /22 we're just wasting limited resource. But there're also LIRs, where /22 will actively used. I don't see any problems in terms of RFC 2050 mentioned here and memory contraints, providers had to upgrade their routers in meantime anyway (at least due to IPv6 adoption). Fragmentation up to /24 is long-term reality and we had to deal with it anyway. With regards, Daniel On 09/21/2017 01:43 PM, Marco Schmidt wrote:

Dear colleagues,

A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion.

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.

You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-03/

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 RIPE Working Group Chairs, decides how to proceed with the proposal.

We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 20 October 2017.

Kind regards,

Marco Schmidt Policy Development Officer RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Check Point Le informazioni contenute in questo messaggio di posta elettronica e in ogni eventuale documento allegato sono riservate, potrebbero essere coperte dal segreto professionale e possono essere utilizzate esclusivamente dal destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio o dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o divulgazione delle informazioni negli stessi contenute, sono da considerarsi come vietate e potrebbero costituire violazione delle normative ivi applicabili. Se ricevete questo messaggio per errore Vi preghiamo di volerci avvertire immediatamente tramite posta elettronica o telefonicamente e di cancellare il presente messaggio e ogni documento ad esso allegato dal Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a proteggere la nostra rete da virus e non ci assumiamo alcuna responsabilita' in ordine a possibili virus che possano essere trasferiti con la presente mail. Grazie. ***************** The information contained in this e-mail and in any file transmitted with it is confidential and may be privileged for the sole use of the designated addressee. Any unauthorized dissemination or copying of this e-mail or its attachments, and any use or disclosure of any information contained in them, is strictly prohibited and may be illegal. If you are not the designated addressee, please notify the sender immediately by e-mail or by telephone and delete this e-mail and any file transmitted with it from your system. We make every effort to keep our network free from viruses and take no responsibility for any computer virus which might be transferred by way of this e-mail. Thank you.

On Fri, Sep 22, 2017 at 17:40 Jetten Raymond <raymond.jetten@elisa.fi> wrote:

Dear AP-WG,

I Oppose this 2017-03 proposal,

IPv6 has been around for decades, and "we" have failed to implement it in time. I see no point in rewarding laziness and yet trying to again give more time to seriously start to implement v6. The more time we are given, the more time it will take, that’s how we have done it in the past, and I don’t see the laziness go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, "again it will end", " you’ve told us that many years". Even if we only hand out a /28, we still have the basic problem, and it won't go away v4 WILL run out. Don’t make the suffering any longer.

Rgds,

Ray

+1

-----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Palumbo Flavio Sent: 22. syyskuuta 2017 11:17 To: Daniel Suchy <danny@danysek.cz>; address-policy-wg@ripe.net Subject: [address-policy-wg] R: 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

I don't see TOO any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea TOO .

-----Messaggio originale----- Da: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Per conto di Daniel Suchy Inviato: venerdì 22 settembre 2017 10:09 A: address-policy-wg@ripe.net Oggetto: Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hello, /24 is de-facto standard accepted in routing tables these days and also /24 was used in large scale during PI assignments - so I don't see any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea.

But I would like to keep option for asking more than /24 (up to /22 maximum, as was decided in the past) LIRs eligible for allocation, if LIR properly documents his request.

From my own practice there're some LIR, where /24 is sufficient and they just become LIRs because there's no other real option to get independent addresses (old "PI") and with /22 we're just wasting limited resource. But there're also LIRs, where /22 will actively used.

I don't see any problems in terms of RFC 2050 mentioned here and memory contraints, providers had to upgrade their routers in meantime anyway (at least due to IPv6 adoption). Fragmentation up to /24 is long-term reality and we had to deal with it anyway.

With regards, Daniel

...

Dear colleagues,

A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion.

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.

You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-03/

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 RIPE Working Group Chairs, decides how to proceed with the

On 09/21/2017 01:43 PM, Marco Schmidt wrote: proposal.

...

We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 20 October 2017.

Kind regards,

Marco Schmidt Policy Development Officer RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

Check Point Le informazioni contenute in questo messaggio di posta elettronica e in ogni eventuale documento allegato sono riservate, potrebbero essere coperte dal segreto professionale e possono essere utilizzate esclusivamente dal destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio o dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o divulgazione delle informazioni negli stessi contenute, sono da considerarsi come vietate e potrebbero costituire violazione delle normative ivi applicabili. Se ricevete questo messaggio per errore Vi preghiamo di volerci avvertire immediatamente tramite posta elettronica o telefonicamente e di cancellare il presente messaggio e ogni documento ad esso allegato dal Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a proteggere la nostra rete da virus e non ci assumiamo alcuna responsabilita' in ordine a possibili virus che possano essere trasferiti con la presente mail. Grazie.

*****************

The information contained in this e-mail and in any file transmitted with it is confidential and may be privileged for the sole use of the designated addressee. Any unauthorized dissemination or copying of this e-mail or its attachments, and any use or disclosure of any information contained in them, is strictly prohibited and may be illegal. If you are not the designated addressee, please notify the sender immediately by e-mail or by telephone and delete this e-mail and any file transmitted with it from your system. We make every effort to keep our network free from viruses and take no responsibility for any computer virus which might be transferred by way of this e-mail. Thank you.

-- -- Kind regards. Lu

On 22 Sep 2017, at 11:11, Daniel Suchy <danny@danysek.cz> wrote:

<snip>

Even standardisation of IPv6 was quite slow in some details - we had to wait 18 years for RFC 8200...

But that rally wasn’t a major change in any way from RFC2460, modulo the few errata that had already been applied over the years. The point of RFC 8200 was to move the core IPv6 spec to full Internet Standard status, which actually very few RFCs have. Tim

Hello Ray,

On 22 Sep 2017, at 10:40, Jetten Raymond <raymond.jetten@elisa.fi> wrote: I Oppose this 2017-03 proposal,

IPv6 has been around for decades, and "we" have failed to implement it in time. I see no point in rewarding laziness and yet trying to again give more time to seriously start to implement v6. The more time we are given, the more time it will take, that’s how we have done it in the past, and I don’t see the laziness go if not forced to. Warnings were ignored, we (v6 advocates) were laughed at, "again it will end", " you’ve told us that many years". Even if we only hand out a /28, we still have the basic problem, and it won't go away v4 WILL run out. Don’t make the suffering any longer.

I'm a co-author of the proposal... and I agree with you, in as much that postponing efforts to deploy v6 is rewarding the wrong thing. But I don't recall that being the goal of the original last /8 proposal at all. Our observations are: - in order for new entrants to deploy v6 at all, they currently need a little bit of v4 - this fact is probably not going to change between now and the currently-expected runout of the last /8 So, just like the original last /8 proposal, I believe that this is a pro-v6 proposal. All that's changed between the original last /8 proposal and now is that we now have a picture of the run-rate of the last /8. So this proposal is to give more new entrants the chance to join the v6 internet - with the bit of v4 they need to do that - instead of allowing the rest of us to externalise the cost of v4 runout even further. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland’s National Education and Research Network 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

This proposal will increase per-IP price Thus, it will promote alternatives (IPv6 !) Today at $work, there is nothing planned to get rid of IPv4. Why should we ? Buying some is less expensive than working on hybrid solution. On 22/09/2017 13:04, Jetten Raymond wrote:

I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not.

-- Jack Net/sys admin More details about KWAOO can be found at: https://as24904.kwaoo.net/

Hi Tom, Thanks a lot for the thoughts.

It's primarily because of this that I'm against 2017-03:

1. It will not serve to improve IPv6 deployment

My memory is that the original /8 policy was implemented, not to encourage/discourage IPv6 adoption among existing IPv4 holders, but because we recognised that new entrants joining the internet, even when IPv6 capable throughout, still require at least a little bit of IPv4. Best I can tell, that's still the case. So we're neutral on getting existing holders to shift, but I think this proposal is highly positive on the number of new entrants who'll be able to take this path.

2. It may go as far as to seriously impact the size of the DFZ

I don't want to dismiss the impact that RIR policies have on the DFZ (it's why we started making them, after all) but the DFZ ultimately operates on its own (very raw) consensus. Fragmented blocks do work today, down to /24 - and we have no idea how full runout will change the dynamics of already-routed blocks. So if fragmentation of the remaining /22s in the RIPE free pool may have a serious impact, then I'd suggest that we need to prepare for fragmentation, whether or not this policy is adopted. Of course, RIR policies do have an impact - but only for as long as the policies remain meaningful. Once the free pool is out, and fragmentation of existing blocks becomes the sole way to get more addresses, there's not much more we can do on this mailing list to affect the DFZ.

3. I see no benefit over the current policy

So in summary: the original last /8 was meant to get new entrants onto IPv6 by providing them a little bit of IPv4. I'd like this to continue for longer. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland’s National Education and Research Network 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

On Fri, Sep 22, 2017 at 3:28 PM, Tom Hill <tom.hill@bytemark.co.uk> wrote:

The concern was that once the minimum size is a /24, as proposed, there will be a need to permit /25 or /26 announcements to permit certain traffic engineering strategies. Not that /22s will continued to be disaggregated. Disaggregation to /24 is bad enough as it is, IMO.

"Well, actually" This just means that "certain traffic engineering strategies" will no longer be viable for new entrants. -- Jan

Hi Tom,

On 22 Sep 2017, at 14:28, Tom Hill <tom.hill@bytemark.co.uk> wrote:

On 22/09/17 14:16, Anna Wilson wrote:

...

...

1. It will not serve to improve IPv6 deployment

My memory is that the original /8 policy was implemented, not to encourage/discourage IPv6 adoption among existing IPv4 holders, but because we recognised that new entrants joining the internet, even when IPv6 capable throughout, still require at least a little bit of IPv4. Best I can tell, that's still the case.

So we're neutral on getting existing holders to shift, but I think this proposal is highly positive on the number of new entrants who'll be able to take this path.

The current 'last /8' policy is already doing what it was designed to do, as far as I can determine (and has been mentioned already).

Oh yes, it is, and without further intervention it will continue to do so for a finite amount of time, then it will stop. So the proposal is to extend that finite time.

We're now beyond the time of making the 'last /8' policy, by many years, and I believe that we should be concentrating on making improvements to IPv6 - ensuring that it's an excellent future for all - instead of slicing IPv4 thinner. Picking-up the long tail of stubborn/disinterested organisations is going to be really fun.

I agree but I don't understand why this is an either/or. This proposal doesn't stop that work. I'd gently suggest the counter: - that new entrants are most likely to support IPv6 (because very little IPv4 can be got); - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work; - reaching IPv4 runout while this is still the case will hurt those new entrants disproportionately; - and so the worst effects fall on those who are likely to be the biggest supporters of IPv6 anyway.

...

...

2. It may go as far as to seriously impact the size of the DFZ

I don't want to dismiss the impact that RIR policies have on the DFZ (it's why we started making them, after all) but the DFZ ultimately operates on its own (very raw) consensus. Fragmented blocks do work today, down to /24 - and we have no idea how full runout will change the dynamics of already-routed blocks.

The concern was that once the minimum size is a /24, as proposed, there will be a need to permit /25 or /26 announcements to permit certain traffic engineering strategies. Not that /22s will continued to be disaggregated. Disaggregation to /24 is bad enough as it is, IMO.

I take the point that the immediate pressure to deaggregate /24s could increase. And on the other side, Nick is pointing out what a small proportion of address space this proposal would affect; but nonetheless, they're both genuine points. So the problem we face with the DFZ I think is not specifically "smallest prefix in the table" but "growth of number of entries over time." Entries over time keeps going up, and RIR policies have very successfully kept that growth contained. Right now, the number of additional DFZ entries under the existing last /8 policy is between 1 and 4 times the number of applications approved under that policy. (1 if no deaggregation, 4 if deaggregated into 4x/24.) Even in the scenario of deaggregation down to /26, this would remain the case under the new proposal: 1 entry if no deaggregation, 4 if deaggregated into 4x/26 (plus possible additional 4x deaggregation of the existing last /8 blocks.) And if this is done on foot of a RIPE policy, then it's possible to manage this deaggregation in a controlled manner based on the /8 boundary. If you then fear that this deaggregation would spread to the rest of the DFZ: yes, I share this fear. In fact I think we can be very sure that this is coming, one way or another; Randy explained how based on history earlier in the thread. But in a world of run-out, I don't know how to avoid it. What I do know is that for as long as RIPE allocates IPv4 space, we can make policies which provide the routing infrastructure with some boundaries to try to manage this deaggregation. Once we hit full runout, we lose that ability. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland’s National Education and Research Network 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

Hi Tom,

On 22 Sep 2017, at 15:37, Tom Hill <tom.hill@bytemark.co.uk> wrote:

Because I don't see a way in which this policy will change anyone's behaviour, or incentivise them differently over the current policy, I don't believe it needs to be changed. If you would like, we can take IPv6 adoption out of the argument completely, and I can still be solely against it for the reason of changing the status quo on acceptable prefix sizes for no perceivable gain to anyone.

The proposal doesn't have a goal of changing anyone's behaviour or incentivising anyone. The goal is to quadruple the number of remaining IPv4 applications that RIPE NCC can fulfil. So the gain is to those three quarters of applications that would otherwise be unsuccessful.

...

So the problem we face with the DFZ I think is not specifically "smallest prefix in the table" but "growth of number of entries over time." Entries over time keeps going up, and RIR policies have very successfully kept that growth contained.

"I've deaggregated our /19 to /24s to prevent hijacks." is the problem.

Legitimate traffic engineering is not the issue here, it's the blatant disregard for the cost of TCAM across the DFZ versus the selfish/misguided security requirements of certain network operators.

The concern is that those persons will, very quickly, deaggregate to the minimum possible prefix size.

It's a fair concern; I suggest filters specific to the last /8 boundary as a way to contain the risk.

...

If you then fear that this deaggregation would spread to the rest of the DFZ: yes, I share this fear. In fact I think we can be very sure that this is coming, one way or another; Randy explained how based on history earlier in the thread.

Yes, and I pointed out to Randy in response that the stakes are hell of a lot higher than they were in 1995. Like, "we're not the butt of all jokes" higher.

I hear you. I think it even supports your point in this case- if deaggregation could spread when the stakes were lower, we may be very sure that it'll spread when the stakes are higher. I hope I was able to address that point in the surrounding paragraphs. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland’s National Education and Research Network 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

it might be wise to avoid the eternal rat-hole of what will and will not increase ipv6 deployment. whether we like it or not, and whether we excoriate the folk who have not deployed or not, history has shown that we do not know. there are no more 32-bit integers. ipv6 is horrifyingly and tragically slow to deploy. get over it. get a life. those of us who have been around a while have heard it all before. raise your hand if you remember when 3gpp was going for force global ipv6 deployment. shall i start down the list of the other things? [ remember my $dayjob deployed in 1997 and my co-worker wrote the kame stack on which many of your ipv6 implementations are based. ] the point here is simple. the ripe community has a responsibility to the human community beyond the members of this list. as a friend wrote privately I would be interested to have a person who is 16 years old reply: "I am planning to open my own internet company in 4 years; can you please save some address space for me, 'til I finish high school?" But of course, there is no such person on the RIPE mailing list.. and we are responsible to those 14 year olds. it is called stewardship. randy

...

as a friend wrote privately I would be interested to have a person who is 16 years old reply: "I am planning to open my own internet company in 4 years; can you please save some address space for me, 'til I finish high school?" But of course, there is no such person on the RIPE mailing list.. and we are responsible to those 14 year olds. If he has the money to become a RIPE LIR right out of school

he? wrong.

...

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

analogous to one's need for ipv4 reachability until the last ipv4 sites die out, if any equipment does not properly route and forward 240/4 then there will be folk who can not reach those with addresses drawn from that space. darned shame but we do need universal reachability. we do not have a good track record for addressing architectures. check out rfc 2450 when you have not eaten recently. randy

On 2017-09-22 14:58:51 CET, Tom Hill wrote:

On 22/09/17 12:11, jack _at_ k-net _dot_ pro wrote:

...

Today at $work, there is nothing planned to get rid of IPv4. Why should we ? Buying some is less expensive than working on hybrid solution.

That actually raises a good point: consider the enterprise that has enough IPv4 addresses for the next 30 years of company operation. Perhaps they manufacture really nice deck chairs, or something. They won't be buying any IPv4, because they don't need any more.

Does expensive IPv4 incentivise them to switch to IPv6? No.

Companies of this ilk exist, and in their droves. None of them contribute to this list because they don't care one jot, as long as the WWW works. Bad IPv4 connectivity needs to break their access to the WWW before IPv6 will be anywhere on the list of that company's activities.

We are getting there. Reachability of IPv4-only services is already degrading, with some(?) access carriers not operating their CGN gateways at the capacity needed for peak traffic times. Not least because they simply don't have enough IPv4 addresses to do that. Rearding the proposed policy change I don't think it will really buy us a lot more time: Those members that use the existing policy to "buy" addresses by starting new LIRs will simply start 4 times as many new LIRs. On the other hand it won't do much harm either: De-aggregating of IPv4 space will continue anyway. So I'm undecided on the proposal. Greetings, Wolfgang Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

On 22 Sep 2017, at 12:11, noc@kwaoo.net wrote:

Today at $work, there is nothing planned to get rid of IPv4. Why should we ? Buying some is less expensive than working on hybrid solution.

So what? How could a change in the current v4 address policy possibly change that behaviour? If your company can’t/won’t prepare for the inevitable, you only have yourselves to blame.

Hi,

On 22 Sep 2017, at 13:56, Anna Wilson <anna.wilson@heanet.ie> wrote:

Hi Ray,

...

On 22 Sep 2017, at 12:04, Jetten Raymond <raymond.jetten@elisa.fi> wrote:

Hi Anna,

I saw some calculations that with the current policy it would be 4-5 years, to run completely out, last /8 and returned space.

Now I don’t know if these calculations are correct, but even if they are, or not, then I would like to know how long it should last ? 10 years, 20 , 50?

I can see and understand your points, the original /8 proposal was not meant to delay v6, fully agree, but by spreading it now it will be expected to be spread out again in say 2-4 years (?) .

I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not.

I believe you are correct that people will ignore runout, regardless of whether we change the policy or not.

My concern is that the problems of ignoring runout fall disproportionately not on existing holders who do the ignoring (who have a good chance of being able to rustle up a small amount of their existing space somewhere to run their IPv6 transition equipment) but on future new entrants (who would have no existing space to shuffle.)

That's an externalised cost, and it is the very same externalised cost that I believe the original last /8 policy was intended to address. This proposal is the best way I can think to reduce that burden on new entrants.

So to answer your first question: how long should it last? My only answer to that can be "for as long as new entrants need some IPv4 in order to use IPv6; or as long as possible if we can't get that far." We land on /24 because we think it's practical today.

But it’s not really that they "need some IPv4 in order to use IPv6”. If they’re making content available, you need IPv4 whether you’re deploying dual-stack with IPv6 or not. If they’re deploying an IPv6-only access network, and using NAT64/DNS64/464XLAT to access legacy IPv4 content, then they’ll need less IPv4 if using IPv6, because a certain (growing) percentage of traffic will be native IPv6 and not NAT64’d (I see 30%-50% quoted in different scenarios, due to FB, Netflix, Google, etc). The more IPv6-cabable content out there, the less need for IPv4 addresses for a NAT64 service. So I think they really “need some IPv4 in order to access other people’s IPv4-only content". That need may drop if more NAT64 (or encapsulating equivalents) is deployed, or more content is directly IPv6-enabled or hosted on IPv6-cpable CDNs like Cloudflare, Akamai, etc. There is some use of NAT46 (SIIT DC etc), but that seems pretty rare, at least currently.

...

Therefore I still think the current policy is sufficient.

Forgive me if I misunderstand your thinking; I believe it's this: that full runout is the remaining tool we have to get existing IPv4 holders to deploy IPv6, so we should not take further actions to delay it.

It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders.

Perhaps holders might sell off some space if there’s complete RIR runout, the IPv4 price rises, and the market is the only option. So there might be a feedback loop which would generate more supply?

And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants.

So I think that's who we need to help, and why a policy change is needed.

The aim of the proposal is very well-intentioned. I’m just not convinced it will make any difference by 2021/22 when the current run-out for our region is projected. Things will have moved on significantly by then, just like they have for IPv6 between 2012 and 2017. There was effectively no IPv6 deployment 5 years ago. There’s an argument to track and follow policies implemented elsewhere, and keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 of IPv4 from which they can hand out /28 to /24. what are the current APNIC or AFRINIC policies? Tim

Best regards, Anna

-- Anna Wilson Service Desk Manager HEAnet CLG, Ireland’s National Education and Research Network 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

Hi Marco,

On 22 Sep 2017, at 15:55, Marco Schmidt <mschmidt@ripe.net> wrote:

Hello Tim,

On 2017-09-22 15:39:01 CET, Tim Chown wrote:

...

There’s an argument to track and follow policies implemented elsewhere, and keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 of IPv4 from which they can hand out /28 to /24. what are the current APNIC or AFRINIC policies?

I am happy to provide some information here.

In the AFRINIC region, in the final exhaustion phase, the minimum allocation/assignment size will be a /24, and the maximum will be a /22 per allocation/assignment. https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-ma...

In the APNIC region, the minimum allocation size for IPv4 is a /24. Each APNIC account holder is eligible to receive IPv4 allocations totalling a maximum /22 from the APNIC 103/8 IPv4 address pool (Final /8 Block) and additional allocations up to a maximum of /22 address space from the APNIC non-103/8 IPv4 address pool. https://www.apnic.net/community/policy/resources#Part-2:-IPv4-Policy

I hope this clarifies your question.

Many thanks. So my question would be whether as a community we have a goal to try to stay in sync with other RIR policies. Tim

Hi Peter, All, On Fri, 22 Sep 2017, Peter Koch wrote:

Anna, all,

On Fri, Sep 22, 2017 at 01:56:13PM +0100, Anna Wilson wrote:

...

It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders. And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants.

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. :-) Regards, Carlos Friaças

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

Hi all, I oppose this proposal. 1) If the actual routing table grows very quick, with all new lirs publishing /24 will make it over 1M routes in no-time, making mandatory to change "old" but very good routers that only can have 1M routes. Yes, I know there are a lot of /24 (370k) but if we "force" to publish /24, as they dont have anything longer, will kill it. 2) As all we know, there are a VERY HUGE difference between pre-runout LIRS and post-runout LIRS in terms of address space and, if this proposal is approved the difference will become astronomic. The ones that a this moment have full /8's without use will have at least doubled the price of their IPs, making them more richs (in terms of address space/price per ip). Again, instead of looking for a way to recover all the unused space from old LIRs or legacy we try to push more and more in the new ones. Thats my two cents. Regards, -- Daniel

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

Has this stopped any new startup from doing business or what?

--

George

Hi George, It seems like a common belief among the proponents of the various soft-landing policies that new entrants will find the lack of registry-provided IPv4 blocks to be a significant barrier to entry. We sell IPv4 blocks to new entrants quite frequently, and as has been posted on this thread, even a /22 can be extended to cover quite a few customers. Doing the math, the cost per Ipv4 address per customer served (using non-Belgium CGN) turns out to be less significant than most other costs that companies have to incorporate into their plans. If an address costs $15 and it serves 30 customers, the new entrant is spending $.5 per customer for a network component that is intrinsic to the ability to provide service. My guess is that this cost is far less than hardware or even advertising costs per-customer. And ARIN never has had to worry about fixing their final /8 policy to counter attempts to game the system via serial new LIR applications, as in RIPE. ARIN does not have to impose a moratorium on transfers of a certain class of addresses, as in APNIC. In retrospect, I think the ARIN policy was far-sighted and quite effective. I have heard no voices bemoaning the situation here from my perspective as a broker. Finally I wanted to mention that should RIPE implement this policy, address prices would not double, the relation between this policy and pricing is very tenuous. It’s certainly not like the IPv4 market price has a mathematical relationship to the RIPE entrance fee divided by the allocation size for new entries. Now it’s 2000 Euros and you get 1024 addresses. There is no relationship between those numbers that yields a current price ($15) and the current price has risen over the last two years while the RIPE fees and allocation size has not changed. I am against the policy as written, I think the better route would be to reach complete exhaust everywhere and a enable a global transfer market without “classes” of addresses. Regards, Mike

Hello, I don't think that there is anyone whom would not be able to justify /22. So I think that there should not be any need for justification. Simply because it would be one more meaningless paper, nothing more. Secondly, for me having more specific routes than /24 doesn't seems seem as the right solution for IPv4. More specific routes means more routes in table, so more resources spent on legacy protocol. As for the core of the proposal - droping maximal allocation size from /22 to /24: I don't think that keeping PA pool longer than needed is good for future of an Internet. Maybe it would be better to transfer more space in PI IX pool, drop the restrictions on that pool which prevents to use it for CGN and let the PA space run flat. Long story short, I'm aginst the 2017-03 policy as it is written right now. Best Regards, Martin Hunek Dne pátek 22. září 2017 10:09:28 CEST, Daniel Suchy napsal(a):

Hello, /24 is de-facto standard accepted in routing tables these days and also /24 was used in large scale during PI assignments - so I don't see any problem in reduction of initial (minimal) IPv4 allocation. So i support this idea.

But I would like to keep option for asking more than /24 (up to /22 maximum, as was decided in the past) LIRs eligible for allocation, if LIR properly documents his request.

From my own practice there're some LIR, where /24 is sufficient and they just become LIRs because there's no other real option to get independent addresses (old "PI") and with /22 we're just wasting limited resource. But there're also LIRs, where /22 will actively used.

I don't see any problems in terms of RFC 2050 mentioned here and memory contraints, providers had to upgrade their routers in meantime anyway (at least due to IPv6 adoption). Fragmentation up to /24 is long-term reality and we had to deal with it anyway.

With regards, Daniel

On 09/21/2017 01:43 PM, Marco Schmidt wrote:

...

Dear colleagues,

A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion.

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.

You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-03/

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 RIPE Working Group Chairs, decides how to proceed with the proposal.

We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 20 October 2017.

Kind regards,

Marco Schmidt Policy Development Officer RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

I totally agree with Riccardo, I oppose to this policy as it could cause visibility/performance issues as lot of ISPs are filtering /24s. In my opinion, this problem will never be solved unless using IPv4 will become financially unattractive: I can't see why LIRs owning tons of /16s should start using IPv6. To me, an equal and fair solution would be to make RIPE annual fee dependant on currently owned IPv4 allocations. It's pretty obvious that the majority of LIRs owns more than just a /22 and won't never approve that. Br Il 24/09/2017 11:48, Riccardo Gori ha scritto:

Dear all,

I started as an ISP early 2015 and I still consider myself a new entrant. 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.

For Ipv6 RIPE NCC is doing its best with training and is really appreciated 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 while this 2017-03 proposal aims to last as longer as possible with IPv4. 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.

I don't see even any reason to save more address space than the current policies does 'casue we have "trasfert policies" for almost any kind of IP resource and if there are some restrictions on new allocation there are more flexible for legacy space. Today you can simply choose to go RIPE or market as your feeling to get IPv4/6 if needed.

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.

I see this policy as: - an obstacle to IPv6 - a clear side effect of market price rise on IPv4 - a disincentive to route aggregation

That's why I oppose this policy kind regards Riccardo

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

On Sat, 7 Oct 2017, Riccardo Gori wrote:

Hi Carlos,

Hi Riccardo, All,

sorry for the late reply I was out for work.

I'll reply only to your question "> Fix IPv6 rate adoption by policy? " Carlos, this policy proposal aims to fix IPv4 rate depletion... so why don't use a policy for "rate adoption"? do you see any difference?

Yes, i see a clear difference. The RIPE community can approve/adopt a policy that has some impact on IPv4 rate depletion in the NCC's service Area. How can the RIPE community "enforce" adoption of any new technology? I really don't know. I would certainly prioritize that policy proposal if i had an answer to that question :-) If someone has an answer, i will contribute for such a proposal. Unfortunately, adoption is entirely different from depletion. Depletion is caused by high usage. The need to encourage the adoption of a technology results from low usage.

Rest is personal opinion and from my point of view any conservative policy will only last the pain longer.

Markets are already in place. The "pain" will survive the total exhaustion point in this region, unfortunately. And this is obviously a personal opinion, but you will also see an increased usage of CGN -- which 2017-03 also is NOT addressing. Thanks, Carlos

thank you regards Riccardo

Il 24/09/2017 15:09, Carlos Friaças ha scritto:

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

--

Ing. Riccardo Gori e-mail: rgori@wirem.net Italia: +39 339 89 25 947 España: +34 660 11 59 89 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 [logoWirem_4cm_conR.jpg]

WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285

-------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------

On Thu, Sep 28, 2017, at 13:21, Carlos Friaças wrote:

...

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

The issue is not with what it's in the proposal, the issue is the consequences, direct or indirect.

...

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 a simplist (almost childish) answer to a more complex issue. Even if we start with only the "out-of-region" issue, we will quickly get into the needs-based check, which I have been explained several times by several people that it can no longer work in RIPE-land. There is also the issue of what should happen with those not respecting the policies. Right now we seem to be in a situation where we have laws but no police. Should we continue on that direction (more laws, still no police) or should we just remove the root cause for breaking the law (removing the law may also be an option - even if not really the best) ?

It's a valid viewpoint. I would also agree with "less lax", but that would be a different proposal.

I would support such a proposal, but I doubt that it will have the expected effect in the short-medium term.

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. :-)

So I'll wait a "better" v2.0 .... or v3.0, or v4.0 ...... :) -- Radu-Adrian FEURDEAN

Hi. Agreed with Yury. I oppose this proposal too. Отправлено из AquaMail для Андроида http://www.aqua-mail.com NTX NOC <noc@ntx.ru> 6 октября 2017 г. 8:23:00 ПП написал:

Greetings!

I Oppose this proposal. Minimum routing block is /24 and new LIR will be too difficult to build network in different locations. Most new LIR are small companies. For other half of the companies - they will have to route a lot of small block as 24, routing table will grow high. Nothing useful in this case. I wish this allocation should be greater, les say /21 as in apnic.

If everybody force IPv6 - then better to distribute IPv4 and go to v6 With current rate of Ipv4 distribution ipv4 will be enough for many years. And we should take in mind that time to time RIPE get Ips back to reserve pool from the closed companies and etc.

For people who always care about IPv4 reserved the answer is next - there big Ipv4 reserved space "for future use" according RFC, my opinion that people should look in that direction. I support it too.

NTX NOC Yury Bogdanov

On 21.09.2017 14:43, Marco Schmidt wrote:

...

Dear colleagues,

A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space", is now available for discussion.

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.

You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-03/

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 RIPE Working Group Chairs, decides how to proceed with the proposal.

We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 20 October 2017.

Kind regards,

Marco Schmidt Policy Development Officer RIPE NCC

Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum