Hello. We do not agree with this proposal. Sooner or later RIPE IPv4 address space will run out. Moving from /22 to /24 will not change that, which is the essence of the question, but doing so will create more fragmentation (BGP, smaller LIRS, cost unfairness between members...). In practical terms, we believe this will also boost IP broker market (the smaller the blocks, the stronger IP brokers will get). Current policy is a good compromise: it focus on allocating to LIRs that assign and use address space ...until no more allocation can be done. Best Regards.

Hello Francis and Jim,

We do not agree with this proposal.

Sooner or later RIPE IPv4 address space will run out. Moving from /22 to /24 will not change that, which is the essence of the question, but doing so will create more fragmentation (BGP, smaller LIRS, cost unfairness between members...).

In practical terms, we believe this will also boost IP broker market (the smaller the blocks, the stronger IP brokers will get).

Current policy is a good compromise: it focus on allocating to LIRs that assign and use address space ...until no more allocation can be done.

It seems you misunderstand the proposal. This policy agrees with you that /22s should be allocated until RIPE NCC runs out. It is about what happens afterwards. We create a waiting list with either /22 or /24 allocation size. - Choosing /22 means that the waiting list is unmanageable and therefore (mostly) useless. - Choosing /24 means that the waiting list is manageable and a bit less useless. We're not suggesting to change the allocation size now, only for the waiting list. Cheers, Sander

Hi Jim,

A policy to deal with whatever /24s the NCC might find stuffed down the back of the sofa will be more bother than its worth. Unless someone can provide compelling arguments -- ie there’s still a lot of v4 for the NCC to allocate -- I just don’t see the point. Sorry.

How much of this hypothetical /24 space does the NCC hold anyway? How long might it last?

It's more about that the NCC does with returned address space. The current pools will indeed run out very quickly, no point trying to extend those. The usefulness of this policy can be seen in https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14. When we use the returned space in /22 chunks there is not much point in having a waiting list. If we use /24 there is. That's all :) Sander

Hi Daniel,

But how tenable is it both in principle and in 'Internet governance' terms for the NCC to collect fragmentlets of IPv4 and just sit on them?

Not very!

So we need a policy to allocate them in a useful manner.

The question before us is: What is the minimum useful allocation? Nothing else.

You are much better at summarising than I am :) Andrea Cima has shown us at RIPE76 that /22 is not useful, and /24 is just about useful. Cheers, Sander

On 4 Feb 2019, at 13:58, Daniel Karrenberg <dfk@ripe.net> wrote:

The question before us is: What is the minimum useful allocation?

Well yes Daniel. But how long does that discussion last? Perhaps 5-10 years from now we’ll be debating policies on how the NCC allocates /30s or /31s of v4. :-) Even if the NCC is left with fragments of v4, it may well be impractical to allocate them. Kind of like how the final reserves in a mine or an oil well get left in the ground because it’s not financially viable to extract them.

On 4 Feb 2019, at 14:20, garry@nethinks.com wrote:

...

But how long does that discussion last? Perhaps 5-10 years from now we’ll be debating policies on how the NCC allocates /30s or /31s of v4. :-)

No, because (hopefully) the prefix filters on the v4 Internet will never EVER allow anything smaller than a /24 to be routed on the open Internet ...

That may well be true Garry. But just think of all the fine dinners and exotic travel that can be had as we talk and talk and talk about IPv4 allocation policy for ever more useless allocation units of ever smaller amounts of v4 space at the NCC. We can't allow reality to intrude on those sorts of policy discussions. :-)

* Jim Reid

I’m not convinced there’s any point in having a waiting list or maintaining an expensive bureauracy to oversee the dregs of the dregs of v4. IMO, once the NCC is unable to allocate /22s to new LIRs, it’s game over. v4 is finally exhausted. Get over it.

That's a fair point of view, but that's not what current policy actually says, so you'd need to change the policy to get that in any case. Should be a simple proposal: Any returned/reclaimed IPv4 space should simply be passed on to the IANA Recovered IPv4 Pool, and the NCC should say «no thanks» to any further allocations from the IANA (or instantly return them if declining them outright is not possible). At least we'd be finally free of the multi-LIR abusers and their bitching about having to pay their invoices on members-discuss that way... Tore

On 2019 Feb 05 (Tue) at 08:53:21 +0100 (+0100), garry@nethinks.com wrote: :That is an option. But in order to not punish late entries to the :market, it should also include a fixed timeframe when EVERYBODY has to :stop using v4 (at least on the public Internet) ... I don't see any :technical reason why providers all over the world still aren't able (or :willing) to do v6 ... of course I know you can't force customers to :provide services on v6 (or even to use v6 - I believe of our customers, :maybe 1% actively use v6, and another few percent use it unknowingly :) ). :From our point of view, we could drop external v4 pretty quickly if it :weren't required to reach (or be reached) by v4-only users/services ... Then come back when you have a solution to force GitHub, Twitter, Amazon, and a lot more, to launch an IPv6 version of their website. -- Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel as if he is in control.

Hi, please see inline. On Tue, 5 Feb 2019, garry@nethinks.com wrote:

That is an option. But in order to not punish late entries to the market,

Some "late entries" are/will not be market driven. Some companies/organisations could only be searching for a way to become independent from their ISPs/suppliers, and the only way they can do that (IPv4-wise) is to become a LIR and get their own chunk. I also hope that by doing so, they will also be flooded with information about IPv6.

it should also include a fixed timeframe when EVERYBODY has to stop using v4 (at least on the public Internet) ...

A flag day won't work. There are simply too many networks.

I don't see any technical reason why providers all over the world still aren't able (or willing) to do v6 ... of course I know you can't force customers to provide services on v6 (or even to use v6 -

Yes, that's the main point. People use what they know it works, and they need to be comfortable about what they are using/managing. If all networks in the world were run by 10 or 100 people, then yes, an agreed change would be possible. However, that's not the case, so co-existence for a long period is unavoidable.

I believe of our customers, maybe 1% actively use v6, and another few percent use it unknowingly :) ).

Yes, people should be using IPv6 unknowingly (in a transparent way), but it's useful that network managers and sysadmins know about it :-)

From our point of view, we could drop external v4 pretty quickly if it weren't required to reach (or be reached) by v4-only users/services ...

That's everyone's case, i'm afraid :-)) I've been deploying and advocating IPv6 since 2001. Others have been doing it for a longer period. Within this timespan, i have only read about *one* organisation which publicly expressed plans to scrap IPv4 from their network/services, but they have dropped that in the meanwhile... IPv6 will not happen by decree, it is happenning, slowly, due to need and a vision for Internet's growth (imho). Best Regards, Carlos

-garry

--

Garry Glendown * Professional Services & Solutions

NETHINKS GmbH | Bahnhofstraße 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown@nethinks.com Geschäftsführer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546

PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32

Hi Raymond,

I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , and I agree with the arguments opposing the proposal.

2017-03 was a different kind of proposal. At that time the choice was between handing out /22 or handing out /24 to all new LIRs. While I did think back then that this was a good idea I understood the reasons against that proposal. LIRs that would get a /22 under the old policy would then get a /24, making things worse for those LIRs. It would also delay the moment that the NCC would hit the bottom by a very long time, therefore potentially giving the impression that IPv4 was still available. Your concluding argument for that proposal was "A /22 is not even enough, let alone a /24 to yet connect to the "dark ages of the IPv4 internet", not now and unfortunately not in the future either...". And at the time that was a valid argument, because of those LIRs that otherwise would get a /22. For this proposal the circumstances have changed though. Now the choice is between giving the new LIRs that come after the /22s have run out a /24 or nothing at all. The analysis from the NCC has shown that if we make a waiting list with /22s the queue will grow indefinitely, which means that the vast majority of the LIRs will never get anything at all. With a /24 allocation size the waiting list becomes manageable and more predictable. I don't think that choosing to give them nothing when we could have given them a /24 is a reasonable argument at the point in time when we have already run out of /22s... Cheers, Sander

Hi Raymond,

To make it more clear what I mean, a /24 will not be enough to connect a say /29 IPv6 to the v4 world, a /22 ( or any range of addresses up to a /22 in size ) is not enough either. Therefore I support the current policy, and am against the new proposal.

Can you please explain how you see that? This proposal only deals with the situation *after* the current policy becomes useless... Cheers, Sander

Hi Raymond,

The current policy does not become useless:

"In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request." is in the current proposal.

Ok, that will extend the lifetime of the /22 policy with a little bit (causing a large amount of fragments to end up in the routing table), and *then* it becomes useless... How do you see the policy after that, when there is a waiting list? Keep pushing lots of fragments to the last LIRs? Cheers, Sander

Hi Sander,

Please look at the presentation I linked to and Daniel's comment.

Looking at it right now. But I'm still not convinced that it is a good idea.

...

Please stop trying to conserve any more IPv4 addresses, IPv4 has reached a dead-end, let it die peacefully.

This is not about conserving IPv4 addresses.

Maybe not directly, but when the waiting list get incredibly long, it would mean that if you get into queue late you won't probably get any address. That what I'm talking here, a total exhaustion of IPv4. When giving out /24, there is higher chance that more subjects would get IPv4 pool, so it would last bit longer as the result. I would rather see policy about when we reach situation where there is no longer /22 to distribute than move all returned IPv4 pools after that into IXP reserved pool. Than no waiting list would be needed. But I'm pretty sure that such a policy would not pass as well. Martin

Sander Steffann wrote at 2019-02-04 16:02:

Hello working group,

The first comments I got back on this proposal all seemed to miss the point of it. Let me explicitly state what this policy is NOT about: - it is NOT about conserving IPv4 addresses - it is NOT about postponing the runout date - it is NOT about extending the lifetime of IPv4

It's purpose is solely about: - dealing with the returned address space the NCC will get over the years

Under the current policy: - the waiting list will grow indefinitely - the allocations given out will consist of tiny fragments - it will therefore not be of any practical use

This proposal proposes: - keeping /22 until we run out of /22s - give out /24s only after that - this helps to keep the waiting list manageable [1] - declare everything smaller (longer prefix) than a /24 unusable - this helps against people getting unusable dust

[1]: see https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14

Please forget about previous attempts to change allocation sizes. Those were about changing the current allocation policy. This proposal only looks forward to what to do after the current policy becomes unusable. Please focus on that.

Cheers, Sander

Just another point for discussion: what to do when this /24-only policy is in effect and RIPE NCC happens to recover a large chunk (e.g. /16 or more) and is able to hand-out multiple /22's again?

On Tue, Feb 5, 2019 at 11:16 AM Sander Steffann <sander@steffann.nl> wrote:

Hi Michiel,

...

Just another point for discussion: what to do when this /24-only policy is in effect and RIPE NCC happens to recover a large chunk (e.g. /16 or more) and is able to hand-out multiple /22's again?

The policy explicitly states that once the waiting list policy is in effect the old policy is removed. So the large block would be used to process requests from the waiting list.

Yup, and also: a /16 isn't a large chunk in comparison to the waiting list. It's only 256x /24 blocks. If I read the graphs right, it would be gone in less than a month. -- Jan

On Tue, 5 Feb 2019, Tore Anderson wrote:

* Marco Schmidt

...

A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion.

This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges.

I support this proposal. Some random thoughts about it:

Hi, Some comments inline:

- It is good to have the policy explicitly say there is a waiting list. Current policy says nothing about this. If the NCC would simply close allocation tickets with «sorry, fresh out, try later», that could encourage LIRs to spam repeated allocation requests in the hope that theirs was the first request to be received after an IPv4 fragment was returned to the allocation pool.

Yes, and that "randomness" would be everything except "fair".

- I don't quite believe that the waiting list would grow indefinitely (regardless of the allocation size being /22 or /24). Keep in mind that only new and IPv4-less LIRs would be able to join the waiting list. Once it is known that simply joining the NCC won't guarantee a /22, but that you'd have to wait for one with no certainty as to how long, I expect that the sign-up rate of new LIRs will drop dramatically (and by extension the amount of LIRs queuing up in the waiting list).

If getting a /24 is still cheaper than getting a /24 from "the market", people will queue up, because there will be still a bit of profit... On a personal viewpoint, i also hope newcomers come to the RIPE NCC for IPv4, so they can be flooded with information about IPv6 :-)

- It seems reasonable to lower the allocation unit to the de facto smallest usable on the public Internet at a point in time when we can no longer allocate /22s (which are already pretty small). Otherwise recovered /23 and /24 fragments (e.g., PI assignments) will just end up rotting away in the NCC inventory, which serves no good purpose at all.

Yes, growing up the NCC's IPv4 inventory will serve noone, except if a policy is accepted in the future to re-open IPv4 distribution, when the inventory reaches some level. I clearly prefer to see /24s distributed to those who want them.

- It seems reasonable to trigger this policy at precisely at a watershed moment like the policy aims to do (unlike 2017-03, which would have changed the rules in the middle of the game).

As you may have noticed i was also one of the co-authors of 2017-03, and that one was withdrawn. But the current proposal is not 2017-03, and i feel this is needed especially after getting input from the NCC about the amount of address space they are getting back -- due to several reasons.

- The authors should clarify how this new policy interacts with the /16 set aside in «5.2 Unforeseen circumstances». In which order does the 5.2 and 5.1bis policies get triggered?

I wouldn't touch that. Would let the NCC decide what are "unforeseen circumstances" or wait for a new, different, policy proposal. We might tackle this issue at v2.0, but i would like to keep changes at a minimum, in this proposal's scope. Best Regards, Carlos

Tore

This uncertainty will certainly also discourage LIRs from signing up as member just to get IPv4 - regardless of the economics. Say, if you need IPv4 to deliver a project due in six months, then getting it from the market will be the only way that would give you sufficient certainty that you can deliver on time.

Depending on the project, AFAIK temporary allocations are/will still be possible. Uros

On 5 Feb 2019, at 12:25, Alexey Galaev <alex@vpsville.ru> wrote:

Let check how many IPv4 not announce by BGP

IP addresses can be used without them being routed on the public Internet. It’s also possible to make BGP announcements that tell lies. It’s not feasible for an RIR to recover address space from an LIR (unless the LIR voluntarily hands it over), assuming there was a suitable policy in place. Which there isn’t.

return 250.0.0.0/8 to the free pool

That’s not going to help either. [Assuming we knew for sure there’s absolutely nothing deployed today that won’t fail or misbehave if that ~40 year old reserved address range was brought into use.] Activating 250/8 would just postpone the exhaustion point by a few months. And then we’d be back to where we are today. No matter what we do to conserve or reclaim IPv4 addresses, there simply isn’t enough of them. Our planet has 7-8 billion people and there are only 4 billion IPv4 addresses.

Oh my! I kept revising this and introduced crap while doing so. For clarity: On 06/02/2019 10:39, Daniel Karrenberg wrote:

... Specifically why not just say "This polixy into effect on September 1st 2019"?

"This policy comes into effect om Spetember 1st 2019."

... Would (4) and (5) above do the trick?

Would (4a) and (4b) above do the trick? Daniel

On Wed, Feb 6, 2019, at 11:19, Jim Reid wrote:

The question here I think is what should be the trigger event. And then what happens to the remaining v4 addresses that fell down the back of the sofa, slipped through the cracks in the floorboards and ended up in a disused basement behind a locked door that has a “beware of the leopard” sign.

Well OK. That’s two questions. :-)

Concerning the trigger, it seems pretty clear : Cannot allocate a single /22. The second, I would rewrite into "What is the amount of recovered space every year? When does recovery happens (all year or specific period of the year) ?". Plus estimations for the future if any. However there are some questions on what does the NCC do *before* getting there. Let's remember there still are temporary allocations. How much space do they usually take out of the /13 reserved for them ? Should be move temporary allocations to standard pool (and merge their pool into the main one) ? If yes, when ? Now ? When there are no more /22 in the regular pool (preventing the switch to /24 for a few months) ? when there is only /xx (/13 suggested) free space in the regular pool ? Do we need a policy for that of is it just "NCC bookkeeping stuff" ? There's the quarantine (returned/recovered blocks) : what happens when there's not a single /22 in the "free" pool, but there is space in the "Reserved pool" (quarantine + temp allocations).

How much v4 space would the NCC be holding once it’s no longer got /22s to allocate?

That’s three questions. :-)

That's about 10 questions. An answer before the impact analysis (I'm confident this will at least reach "impact analysis") would be greatly appreciated. I will be able to give an opinion based on the answers to those questions. For the moment I'm half for (because the waiting list is something that will be needed at some point in the future), and half against (the "let's end the IPv4 madness" stuff). Regards, -- Radu-Adrian FEURDEAN

On Fri, Feb 8, 2019, at 09:43, Carlos Friaças wrote:

...

The second, I would rewrite into "What is the amount of recovered space every year? When does recovery happens (all year or specific period of the year) ?".

That's really for the NCC's Registration Services Dept. to answer, i think :-)

Exactly !

...

Plus estimations for the future if any.

Oh, that will be a hard exercise.

They (the NCC) are pretty good at this kind of stuff.

...

However there are some questions on what does the NCC do *before* getting there.

Let's remember there still are temporary allocations. How much space do they usually take out of the /13 reserved for them ? Should be move temporary allocations to standard pool (and merge their pool into the main one) ? If yes, when ? Now ? When there are no more /22 in the regular pool (preventing the switch to /24 for a few months) ? when there is only /xx (/13 suggested) free space in the regular pool ? Do we need a policy for that of is it just "NCC bookkeeping stuff" ?

I would say: Don't touch that /13. Keep it simple :-)

That may get some people angry. A /13 is 512 /22s (5-6 weeks worth of allocations at current rate) or 2048 /24s (I expect that to be more than 6 months worth with the current proposal). That is beginning to be a little too much. Let's remember that with the current proposal, the price of a /24 via "additional LIR" will be pretty much in line with the market one (unless the market prices spike within one year). That will definitely reduce the LIR creation and in consequence the allocation rate. As for users of temporary allocations, there's the "conference" guys that should be kicked a little bit to do more IPv6 and less IPv4 (last years CiscoLive Barcelona was a pretty big fail for this matter - I understand they finally fixed it this year).

...

There's the quarantine (returned/recovered blocks) : what happens when there's not a single /22 in the "free" pool, but there is space in the "Reserved pool" (quarantine + temp allocations).

Imho, that's a different pool.

It's different, but after a few months address blocks go from quarantine pool to the allocation pool. Reason to get some people angry.

...

and half against (the "let's end the IPv4 madness" stuff).

Please see my previous e-mail. Unfortunately IPv4 *usage* is not going away anytime soon... :(

No, it's not going away, but we should to everything necessary to move from a stance "IPv6 guys area savage geeks, the normal is IPv4" to one of "IPv4 is outdated retrograde stuff, IPv6 is normal". As long as "you can still get your tiny piece of IPv4" I don't think the general mindset will change. Then we could get to a situation similar with one we had with current policy : almost 3 years into the "last /8" we had more than a /8 available for a few months. I wouldn't like something similar to happen again. I would like to have the waiting list "populated" permanently starting from 2021 (even late 2020). -- Radu-Adrian FEURDEAN

Moin, am 08.02.2019 um 17:24 schrieb Nikolas Pediaditis:

Following your questions, I have some numbers and other information that might be useful.

1. Currently, there will be 977,408 IPv4 addresses remaining in our free pool once we are no longer able to allocate contiguous /22s. This number excludes prefixes that are smaller than a /24 and those prefixes that have been reserved for IXP assignments or temporary assignments. It might also be slightly larger by then, due to addresses that are recovered in the meantime.

2. Over the past three years, we have recovered the following amounts of IPv4 addresses:

2016: 83,712 2017: 106,368 2018: 53,824

Thank you, Nikolas, for the figures. So we're still talking about ~3.8k _new_ LIRs that end up with a /22 worth of addresses in /24s or /23s before 2019-02 would kick in and prolongate the infirmity of IPv4. 3.8k new LIRs that happily can consider starting a business based on IPv4, a legacy technology, and ignore the facts. As Carlos Friaças pointed out on 08.02.2019 at 09:15:

The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market).

Let's put this into perspective: "I see 757979 IPv4 prefixes. This is 238 fewer prefixes than 6 hours ago and 1051 more than a week ago. 57.04% of prefixes are /24. There are 63602 unique originating ASNs. 47266 of these ASNs originate IPv4 only" (Source: https://twitter.com/bgp4_table/status/1097420515206152192) With still about 75% ASNs being IPv4 only, there's definitively no point in prolonging the availability of fresh IPv4 space by reducing the hand-out rate. "IPv4 is over", I hear — so let's be brave and stick to that statement. Regards, -kai

Hi Denis, Do you think that most of those "new" LIRs are in fact a new players? As long as we are allowed to transfer those addresses, we cannot be sure about that. Also life isn't fair. There are LIRs with large legacy IPv4 blocks, which could sustain a few dosents LIRs in current policy, but hay, that's the way it is. They got their pools fairly/legaly as well as we are getting it now. Other way of looking at it would be that we all should have possibility to get a same oportunity to get a large pool. But in that case it would be unfair to have 185/8 policy and we would have reached total depletion long time ago. So what is really fair and what is not? Unability to getting IPv4 from RIPE doesn't mean unability to get IPv4 conectivity. But it push the new player to start with IPv6 and get the v4 as a service. It would make v4 as something extra what you are forced to pay extra, perfect mindset to abadon it eventually. So once again, a faster we run out of IPv4 - a better. Martin Dne pondělí 18. února 2019 13:04:52 CET, Denis Fondras napsal(a):

On Mon, Feb 18, 2019 at 12:53:27PM +0100, Kai 'wusel' Siering wrote:

...

3.8k new LIRs that happily can consider starting a business based on IPv4, a legacy technology, and ignore the facts.

I find this unfair. This is not "starters" who are ignoring the fact but those already in business (I look at you AWS among many hosters and ISP). Starters are only requesting IPv4 to reach ~80% of the Internet.

Denis

Hello, On Mon, 18 Feb 2019, Martin Hun?k wrote: (...)

Unability to getting IPv4 from RIPE doesn't mean unability to get IPv4 conectivity.

Nor (some) IPv4 addresses, which can be obtained from "the market".

But it push the new player to start with IPv6 and get the v4 as a service.

Please go back and read why "You must deploy IPv6 in order to receive IPv4" (unfortunately) didn't stick...

It would make v4 as something extra what you are forced to pay extra, perfect mindset to abadon it eventually.

Nice plan, but there is just a very tiny detail... 75%-80% of the Internet is IPv4-only.

So once again, a faster we run out of IPv4 - a better.

We have "run out of IPv4" (in a context of Internet's growth) since some years now... but people are still able to use it, and a lot of people/companies are NOT deploying IPv6 because they don't *need* it today. RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely.

Martin

Best Regards, Carlos

Hi, On Tue, 19 Feb 2019, Dominik Nowacki wrote:

Dear Colleagues, We do not support this proposal.

RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely.

ARIN style never-ending queue that basically means you will never get the addressees you request at this stage is synonymous with a complete and permanent run out of IPv4 to me.

That's what 2019-02 is about: We're in scarcity-mode since 2012. "What you request" and "What you need" are completely irrelevant. When the pool reaches 0 for the 1st time, people will still get /22s *when* some addresses are made available. Changing that into /24s will allow more people to get a minimum of IPv4 eventually at some point (smaller lifeboats, but 4x more lifeboats...) When the *need* for a /24 arises, and a company is still in a bad queue position, the answer is obvious: get it from the market! It would be really easy if IPv6 deployment would solve it, but one is only able to control one's infrastructure, there is absolutely no ability in dictacting what (and if when) 3rd party networks are going to deploy. That depends on their judgement and of course, budget :-)

You can also observed that, for example, US where they observe a ?complete and permanent run out of IPv4? has more IPv6 traffic, according to Google, already than say UK where the national ISP, BT, and majority of alternative ISP supports IPv6 for ages already, out of the box.

It's not only traffic volume that matters. The number of networks and how much IPv6 is within each network is also very important.

No access to V4 - better incentive to have eyeballs on V6 (and granted, some CGNAT probably too).

We might not like CGNAT, but noone can stop anybody to use it... :/

More eyeballs on V6 makes an incentive for content providers to make more services available on V6.

As i see it, content is the easy bit... Regards, Carlos

That?s my take on it.

With Kind Regards,  Dominik Nowacki    Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. 

On 19 Feb 2019, at 08:08, Carlos Friaças via address-policy-wg <address-policy-wg@ripe.net> wrote:

RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely.

Hi, just a small reaction to what you have written (in line). Dne středa 6. února 2019 10:39:24 CET, Daniel Karrenberg napsal(a):

After reading and thinking I arrive at the following principles:

a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses as long as it has blocks that are useful to route packets.

Note: As an individual I would very much like to just stop with this silliness. However I do not think this is tenable for us as a community.

No problem here. I would be one of them, but I know that there won't be consensus.

b) Once the pool decreases below that threshold the RIPE NCC has to maintain a waiting list in order to establish a sequence in case space becomes availble. Reason: see (a)

I also agree with that.

c) It is not tenable for the RIPE NCC to require the first LIR on the waiting list to wait for more address space than a minimal usfeful block to accumulate.

Here it starts. I would say get such a LIR what you have got (to /22 of course). Even by means of multiple /24s. But not blocks smaller than /24, as it would be useless. Maybe let them decide if they would like to wait for whole /22 where there would be less then 4x /24 (in that one case).

d) The length of the waiting list and other practicalities should be secondary considerations after these principles above. For instance, the RIPE NCC can always recover the costs incurred by the process from those using it.

No dispute here.

1) Motivate the choice for /24 in terms of being the smallest block useful to route packets considering current routing practice.

Also no issue here. Motivate yes, require no. Keep /22 possibility so the complete runout of IPv4 won't be postponed.

2) Explicitly mention the non-goals of the policy as discussed.

I think that those were discused here in the list. I don't think that it should be written in the policy itself.

3) Keep in mind our good experience with using concrete dates for policy changes. Consider to make the change on a specific date. This is more predictable than an event sometime in the future. "Run Out Fairly" worked pretty well. Specifically why not just say "This polixy into effect on September 1st 2019"?

You cannot be sure where it would happen.

4) The policy could be made more adaptable to future scenarios. This would prevent more ad-hoc policy changes which are a pain and do not look very professional to the world outside RIPE. Maybe the policy could be 'parameterised' so that the community can decide to change parameters rather than re-write the policy text.

Sure, add there the waiting list if needed, but do not change the /22. This way it will be consistent.

4a) Consider the possibility that future routing practice may change the longest useful routing prefix away from a /24 as Randy alluded to. This should be a parameter.

I'm strongly agains that. Let's keep there explicitly /24 as the longest routable prefix. Allowing a longer one would give a signal to other RIRs that it is fine with us. That would bring yet another deagregation so more junk in routing tables. I'm not sure that we would all agree on changing our BGP filters to allow that. And if so, someone whom will be given such small pool would have problem with reachability.

4b) Consider the possibility, however unlikely, that the RIPE NCC receives a significant amount of address space to re-distribute. Would this policy still be supported by the community in this event? Should the allocation size be a parameter that can increase above the <smallest usable prefix> either by community choice or automatically if a certain pool size is exceeded?

If you keep there /22 and /24 as an option, than there would be no problem.

4c) What happens down the road when IPv4 really becomes legacy? Can we make the policy applicable even then? Would (4) and (5) above do the trick?

Then it would be wise to pass a policy that would say that. Like: "IPv4 is considered to be a legacy protocol. RIPE would not provide any allocation/ assignment of IPv4 resources." Or what ever.

5) Maybe mention explicitly that one has to be a LIR in good standing to be on the waiting list.

More LIRs on the list means smaller chance that anyone would get an address pool. So let them wait there, it just as easely may work as a motivation torward IPv6. Like: "Just look at that list! IPv4 is gone for good." Martin

On 06.02.2019 12:32, Denis Fondras wrote:

...

If you keep there /22 and /24 as an option, than there would be no problem. No please, don't let LIR choose. This will only complicate management of resources.

It's a simple flag, "/24 sufficienct: yes/no".

In a FIFO, a LIR asking for /22 would delay a LIR who only needs a /24.

Yes, that would be the case. Since that second LIR won't have the slightest idea when it would receive IPv4 anyway, I fail to seen an issue with that. On the contrary, it emphasis the fact that IPv4 is over. Regards, -kai

and then you were presented with the simple flag, "250 GB sufficient: yes/no"

What would you choose?

My bet is that you would choose "no" and request 1 TB. --

Slight difference: we're talking about a scarce resource here, which - depending on your choice - might or might not be available. So the choice is rather: 1) packs of 250GB, 500GB or 1TB up to a total of 1TB (packs might not be available at the same time) 2) 1TB in on pack of 1TB Though, thinking about the billing, RIPE has to (or should) define how to do the billing based on the number of resources ... currently, billing is per resource, not sure if this will be kept if due to availability issues this would remain (in essence, increasing the price for LIRs that have to take multiple /24 instead of one /22) or whether they would still receive their initial fragmented /22 amount of IPs included as "first resource" ... -garry -- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstraße 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown@nethinks.com Geschäftsführer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32  

That's  one thing. The other: what's the amount of recovered space becoming available for redistribution by the RIPE NCC within which timeframe? I've read in some document that RIRs might receive a tenth of IANA's recovered space every 6 months, thus the inital waiting time for a /22 or /24 will be up to 6 months anyway? If e. g. IANA is down to a /17, this makes a /21 for RIPE for that six month period. I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 to eight new LIRs, since a /24 is basically useless anyway. Especially if you have to wait 6 or more months for it. (Of course, /22 (in up to /24 slices) will mean a much longer waiting time, which makes  IPv6 just more interessting. Or IPv4 brokers.) Why is a /24 useless? It's routable on the internet and fully usable. Yes, you can't aggregate it to form larger blocks, but considering the number of /24 already present in the global routing table (many/most of which are de-aggregated prefixes, presumably for multi-homed purposes), if anybody decides to filter them generally would cause major problems ...

...

Though, thinking about the billing, RIPE has to (or should) define how to do the billing based on the number of resources ... currently, billing is per resource, not sure if this will be kept if due to availability issues this would remain (in essence, increasing the price for LIRs that have to take multiple /24 instead of one /22) or whether they would still receive their initial fragmented /22 amount of IPs included as "first resource" ...

IIRC, billing discussions are out of scope for the APWG. Besides, billing is not per resource currently, is it?

True. Just thought I'd throw it in there as "fairness" was mentioned earlier. From the last time I looked at the RIPE bill we were charged for every network block we have - with the same yearly recurring price per resource no matter if it's the /16, /19 or a /24 ... (formerly, this had been a one-time assignment fee, but in order to allow for easier recovery of unused IPs, RIPE changed this some time back ...) According to the 2019 billing scheme, this is still unchanged, though I reckon it does not apply to PA space: "The separate charge of EUR 50 per Independent Number resource assignment will be continued. Independent number resources are: IPv4 and IPv6 PI assignments; Anycasting assignments; IPv4 and IPv6 IXP assignments;" So fragmenting the /22 into /24s would not be of consequence to an LIR anyway, at least not financially. So strike my argument about that part. -garry

On Wed, Feb 6, 2019 at 3:16 PM Kai 'wusel' Siering <wusel+ml@uu.org> wrote:

On 06.02.2019 14:36, garry@nethinks.com wrote:

...

...

[…] I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 to eight new LIRs, since a /24 is basically useless anyway. Especially if you have to wait 6 or more months for it. (Of course, /22 (in up to /24 slices) will mean a much longer waiting time, which makes IPv6 just more interessting. Or IPv4 brokers.) Why is a /24 useless?

Sorry for beeing too brief here: From my perspective, becoming an LIR implies the intend to provide service a lot of customers, and I don't see how a single /24 would suffice there. That's what I meant with "basically useless" (from a business point of view).

In that case, IPv4 is "basically useless" from a business point of view. But that statement is provably false. Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers. Additionally, a lot of connectivity services can be provided via NAT. And so on. This line of argument is not fruitful, sorry. Please abandon it. -- Jan

Hi, Please see inline. On Wed, 6 Feb 2019, Taras Heichenko wrote:

...

On Feb 6, 2019, at 16:24, Jan Ingvoldstad <frettled@gmail.com> wrote:

In that case, IPv4 is "basically useless" from a business point of view.

But that statement is provably false.

Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers.

Additionally, a lot of connectivity services can be provided via NAT.

And so on.

If I am right we talk about resources that can be obtained by new LIR. If a LIR already has some IPv4 block it cannot claim to get some other block from RIPE NCC according to the policy. And what does the LIR status give to the LIR? It gives possibility to get IP addresses. So a LIR is been registering to obtain IPs. Anything else?

And keep it. And access NCC services like certification (RPKI), training, ...

So a new LIR must pay $1400 annually to have ghostly possibility to obtain IPv4 addresses. May be. Later. After years (multiply by $1400).

Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-)

It has not these addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?).

My interpretation is that you could. Currently, a /22 per LIR account...

What are we talking about? Show me please use case for participant of the waitlist. Who is he/she?

Potentially ORGs that wish to be independent (IPv4 addressing wise) from their transit providers, also allowing them to peer at IXPs, ... The easy part is IPv6, which doesn't involve any waiting list -- it's just a matter of becoming a LIR or getting service from one. :-)) Cheers, Carlos

-- Best regards

Taras Heichenko tasic@hostmaster.ua

On Thu, 7 Feb 2019, Taras Heichenko wrote: (...)

All that you added is derived from "obtain IPs". Of course you are right but until you get IPs you do not need AS, RPKI and so on. Training may be useful without IPs but you can find a way to go to training without LIR status.

Yes, but addresses can also be obtained from "the market", and maintenance will be required anyway... Oh, and you can get IPv6 addressing also! (...)

...

Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-)

You must obtain IPs at first. All your answer is built on assumption that organization already has some IPs. Of course in this case it will pay annual fee for all service. But we talk about new LIR. I came to RIPE NCC to get IPs. RIPE NCC is telling me: We put you in waitlist and may be later you will get /24. But to get to the waitlist I must pay now 1400 (of course euros not $ as I mistype in previous letter). I pay 1400 euros annually for the right to be in the waitlist.

Sounds a bit expensive, yes, i agree. Stock market futures come to mind. But if you can't get space immediately from the NCC, some brokers will certainly help you (for their right price...), and you can associate the space you buy with your new fresh LIR -- and still be on the waitlist (if i'm not wrong)!

...

...

It has not these addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?).

My interpretation is that you could. Currently, a /22 per LIR account...

I hope someone who take decision will answer. Would new LIR have right on the block from RIPE NCC if it had bought some IPv4 from the market?

Even if the answer now is "No.", i believe that could eventually be changed by a new policy proposal into "Yes.". If this is the case i would support such proposal. Regards, Carlos

On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: (...)

I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 to eight new LIRs, since a /24 is basically useless anyway.

I really don't agree with the former. The spirit of 2019-02 is precisely that a /24 is the minimum usable allocation, mostly due to global routability. An ORG/LIR might get a second /24 if needed (through a new LIR account), but it needs to go back into the queue... (if there is any at some point). (...)

IIRC, billing discussions are out of scope for the APWG. Besides, billing is not per resource currently, is it?

Here we are 200% in agreement :-) Cheers, Carlos

Regards, -kai

Reply inline. Dne středa 6. února 2019 14:35:22 CET, Daniel Karrenberg napsal(a):

On 06/02/2019 11:23, Martin Huněk wrote:

...

Maybe let them decide if they would like to wait for whole /22 where there would be less then 4x /24 (in that one case).

That is where the implementation would become very complicated since it needs to be perceived as 'fair'. I see no good reason for this complication.

Not necessary. Simple question would do: "We have got 3x /24 right now or /22 in 3 months. Do you want to get them right away or do you want to wait for whole /22?". RIPE NCC knows where next prefixes would leave 6 months quarantine, so at least a first few LIRs on the list would know where to expect IPv4 prefixes. It could be seen as a complication of process, but it is important to mention that we are talking about one LIR per each batch of returned IP space. And even that could be automated trough LIR portal.

...

... Keep /22 possibility so the complete runout of IPv4 won't be postponed.

See above. I do not see the point about 'complete runout'. We *have* run out already. This is about the very very tail end.

What I'm afraid of is pressure for further deaggregation of those last /24s. Even now in the mailing list there was opinion that just one /24 is useless because you can't assign from it to another entity. Not talking about fact that if you have same amount of LIR on waiting list when everybody wants 4x more, the waiting list is 4x longer time-wise. Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to go for IPv6. If you have /22 you can do that, if you could have /22 but you have chosen /24 (now instead of waiting for /22) - you could have done that and if there won't be enough IPv4 for you that would be just a fact and there would be nothing to do about it. So there won't be such pressure for further deaggregation. At least if IANA won't distribute to RIRs smaller prefixes anyway. And just why is such deaggregation problem for me? Because we would be spending even more RAM and computation effort on "walking dead" IPv4. And if we start to allow such deaggregation we would end up on single /32 in our routing table. At least for now we all know that if we try to announce /25+ we would have reachability issues. Let's keep it that way. Martin

Hi, (reply inline) Dne čtvrtek 7. února 2019 9:40:25 CET jste napsal(a):

Hi, (please see inline)

On Wed, 6 Feb 2019, Martin Hun?k wrote:

...

What I'm afraid of is pressure for further deaggregation of those last /24s. Even now in the mailing list there was opinion that just one /24 is useless because you can't assign from it to another entity. Not talking about fact that if you have same amount of LIR on waiting list when everybody wants 4x more, the waiting list is 4x longer time-wise. Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to go for IPv6.

Or go to "the IPv4 market".

Also a possibility, but it would cost additional money.

IPv4 is NOT "walking dead". It's the Internet's dominant protocol version, whether we like it or not!

How many orgs have gone public about plans to completely drop IPv4?

IPv4 has a serious limitation about "future growth", which IPv6 doesn't have. But people are making (a lot of?) money pushing IPv4 numbers from hand to hand, so it is hard for me (at this point, from a research & education network background!) to see how IPv4 will stop being the dominant version...

Yes it is still dominant, no dispute here. But as well we (theoretically) buried it long time ago. That's why the "walking dead" thing. Point is that with up to /32 in routing tables we would be investing RAM on IPv4 instead of for IPv6 deployment (if not done already). And yes, there is quite a lot of money in IPv4. In hypothetical IPv6-only world, IP brokers would starve to death. :-) Regards, Martin

On Wed, 6 Feb 2019, Daniel Karrenberg wrote: (...)

...

... Keep /22 possibility so the complete runout of IPv4 won't be postponed.

See above. I do not see the point about 'complete runout'. We *have* run out already. This is about the very very tail end.

Allow me to disagree. People are still getting IPv4 addresses from the NCC. "Declaring runout" is not exactly the same as stopping handing out IPv4 addresses. Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. The "reversion" won't happen if there is a policy in place stating RIPE NCC will not allocate any more IPv4 addresses -- who wants to propose that? I don't. Disclaimer: I have been advocating and deploying IPv6 since ~2001. I just think reducing by decree/policy the ability of people to use/deploy IPv4 is not the correct way to go. Cheers, Carlos

Daniel

Dear Jim, all, I would just like to provide some clarification regarding your point below. On 07/02/2019 11:14, Jim Reid wrote:

...

On 7 Feb 2019, at 07:59, Carlos Friaças via address-policy-wg <address-policy-wg@ripe.net> wrote:

Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. How is that possible? Once the pools reach zero, there are no more addresses to hand out.

An RIR can't conjure up IPv4 address space out of thin air. If it was able to do that, we could just continue forever with business as usual and allocate v4 until the heat death of the universe.

Besides, there’s no mechanism or policy for the NCC to recover addresses from LIRs that don’t pay their bills. If such mechanisms or policies existed, they’d be unworkable. There’s no way of knowing for sure that those addresses weren’t being used. So if they were reclaimed, the addresses couldn’t be allocated to someone else.

Section 9.0 of the IPv4 policy states that an LIR may be closed if it does not pay money it owes to the RIPE NCC. The policy also states that the RIPE NCC takes on responsibility for the address space of LIRs that are closed: https://www.ripe.net/publications/docs/ripe-708#9 Based on the policy, we have existing procedures to de-register IPv4 address space and re-issue the addresses. Our procedure in these cases includes announcement checks and a quarantine period to minimise routablity issues for future resource holders. In fact, many of the allocations we are currently making have gone through such a recycling process. We expect that we will continue to receive IPv4 addresses due to LIR closures and other reasons for some time after the current IPv4 pool has been exhausted. Kind regards, Marco Schmidt Policy Officer RIPE NCC

On Thu, 7 Feb 2019, Jim Reid wrote:

...

On 7 Feb 2019, at 07:59, Carlos Friaças via address-policy-wg <address-policy-wg@ripe.net> wrote:

Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible.

How is that possible? Once the pools reach zero, there are no more addresses to hand out.

At that point in the timeline, YES. zero means zero.

An RIR can't conjure up IPv4 address space out of thin air. If it was able to do that, we could just continue forever with business as usual and allocate v4 until the heat death of the universe.

Yes, that's correct. But a set of foreseeable events might pour down -some- IPv4 space, growing the stock from zero. The NCC registration services tell us they are getting addresses back *every* year (yes, that was a surprise for me too). Even if that doesn't happen during a full year, it doesn't mean it won't happen in subsequent years. If i didn't get it wrong, that depends on a variety of factors. Of course the "yearly recovered numbering assets" are not enough to cope with all the demand -- that's when the waiting list might be useful...

Besides, there?s no mechanism or policy for the NCC to recover addresses from LIRs that don?t pay their bills.

I think you are wrong. Apart from the financial side, if a LIR doesn't comply with policies (falsified data, and so on...) there is a service termination process and resources go back into the pool after some time -- please someone at the NCC, tell me if i got it wrong.

If such mechanisms or policies existed, they?d be unworkable. There?s no way of knowing for sure that those addresses weren?t being used.

Bad luck. Rules breaking means revokation... The higher risk (as i see it) goes to new recipients of the space, after some quarentine.

So if they were reclaimed, the addresses couldn?t be allocated to someone else.

I think the NCC and current policy might disagree -- please tell me if i'm wrong. Best Regards, Carlos

On 06/02/2019 11:40, Jim Reid wrote:

...

On 6 Feb 2019, at 09:39, Daniel Karrenberg <dfk@ripe.net> wrote:

d) The length of the waiting list and other practicalities should be secondary considerations after these principles above. For instance, the RIPE NCC can always recover the costs incurred by the process from those using it.

That could be awkward Daniel. For instance fair and equitable treatment. Or raising barriers to entry. Then there are the overheads of all that extra bean counting. Passing these costs along is all very well, but why go to the trouble of creating them in the first place?

This would also be the start of a slippery slope. Once the NCC introduces hypothecated fees for specific services, it’ll have to do that for everything it does. Which would lead to the membership micromanaging budgets and declining to pay for the stuff they don’t want/support.

Apologies for being unclear. I did not propose a specific fee. Just the normal LIR fee that covers all NCC services. It should more than pay for a process that can be highly automated. Daniel

On Thu, 7 Feb 2019, Peter Hessler wrote: (...)

4) While there is a belief The Internet(tm) should just up and migrate to IPv6, that is unrealistic. E.g. Twitter, Amazon, Reddit, Github, and *many* home/business ISPs around the world do not even IPv6. Whinging about it in policy groups doesn't change that *fact*. (...)

What can we, as a community, do which has not been already tried...? Will it be just a matter of sitting and waiting that people deploying/managing networks & services for those companies are replaced by other people with a different view about IPv6 (or their companies' needs)?

From the *extremely* small list above, Github was recently bought from Microsoft right...? Maybe by talking with the right folks...

Regards, Carlos

Hi,

I oppose this proposal, unless at least RIPE NCC will charge members based on how much IPv4 space they have.

Sorry, membership fee structure is out of scope there. The NCC members decided years ago to adopt a membership-based-fee instead of a resource-based-fee. It's not up to this working group to decide on that. Cheers, Sander

Dear Daniel, All, On Thu, 7 Feb 2019, Daniel Suchy wrote:

Hello,

On 2/7/19 1:17 PM, Servereasy via address-policy-wg wrote:

...

I oppose this proposal, unless at least RIPE NCC will charge members based on how much IPv4 space they have. I find that this will be the only way to really boost IPv6 adoption.

this is problem maily due to law and related taxes. Such diversification was here and this changed few years back.

Exactly! And apart from that, RIPE NCC also distributes other numbering resources apart from IPv4 addresses, and has a broader set of services. :-)

I think only one reason, which will really boost IPv6 adoption is real exhaustion of IPv4 pool within our (RIPE) region.

Please, that is leading nowhere. I also would like to see a stronger IPv6 adoption, and reach the point where IPv6 packets become dominant (i.e. >50%) and at a later stage reach a point where IPv4 routers/services/everything could be disconnected because they weren't useful anymore. Imho, it doesn't help to repeat to exhaustion that IPv4 is legacy. That's not the way people are doing IPv4-only today will feel they *need* to deploy IPv6. Please let us focus on reality: IPv6 adoption depends on a multitude of scenarios. For ORGs that already have their own fair share of IPv4 addresses (suitable for their needs) IPv6 will always be "low priority". For those ORGs, IPv4 exhaustion can be *irrelevant* -- it doesn't affect *them*, only 3rd parties are impacted. Their IPv4 addresses will still be usable (and useful).

2019-02 proposal is just delay this (and allowing more newcomers to start their bussiness), nothing else.

No. That's completely not the idea. The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market). I would happilly include a "you have prove the NCC you have deployed IPv6"-type clause on this proposal's v2.0, but i'm 99,9% sure that would be a problem for a lot of people. :-( This way, if newcomers just become a LIR and grab a /24, they can become independent (routing policy-wise, etc...) from their upstream(s) -- and i openly expect their engagement/exposure with the NCC will improve their knowledge about IPv6, and their future willingness to deploy it. ;-) I hope this helps you understand my motivation to have kickstarted this 2019-02 work jointly with Sander. Best Regards, Carlos

- Daniel

On Fri, 8 Feb 2019, Daniel Suchy wrote:

Hello,

Hello again,

On 2/8/19 9:15 AM, Carlos Friaças via address-policy-wg wrote:

...

...

I think only one reason, which will really boost IPv6 adoption is real exhaustion of IPv4 pool within our (RIPE) region. I also would like to see a stronger IPv6 adoption, and reach the point where IPv6 packets become dominant (i.e. >50%) and at a later stage reach a point where IPv4 routers/services/everything could be disconnected because they weren't useful anymore.

Since there're happy-eyeball RFC implementations, it's somewhat harder to perform such measurments. But I think IPv6 adoption was boosted in regions, where IPv4 pool dried.

It's difficult to measure accurately, and even harder to establish a cause/effect link from IPv4 dried pools. :-( Google is currently measuring (globally) around 25%, from 15% 2 years ago, and from 5% 4 years ago. I also read that as a "boost", yes :-) But unfortunately it's still a bit away from 50%... and we must not forget that Google is only one (big) content provider. There is still a lot of IPv4-only content around, and access to it naturally measures at 0%.

...

...

2019-02 proposal is just delay this (and allowing more newcomers to start their bussiness), nothing else. The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market).

Yes, I understand this purpose and to be clear - I'm not against this proposal (that means, I support it). /24 allocations for newcomers are also used within ARIN region (since 2015 depletetion), so this cannot be any problem with such limitation within our (RIPE) region.

Thank You! Regards, Carlos

- Daniel

I can't speak to a public version of the slides that went to the ARIN Board of Trustees, John Curran will have to do that. However, this section of ARIN policy was the subject of the Policy Experience Report at the previous ARIN meeting and that is public.

From the ARIN 42 meeting report;

Transcript; https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcr... Youtube; https://www.youtube.com/watch?v=MJHgs4wWO58 Presentation; https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/swee... Hope that helps. On Fri, Feb 8, 2019 at 9:09 AM Carlos Friaças via address-policy-wg < address-policy-wg@ripe.net> wrote:

From the minutes:

"The President presented a slide deck to the Board with details of the issue."

I guess that slide deck is not public...?

Carlos

On Fri, 8 Feb 2019, Radu-Adrian FEURDEAN wrote:

...

Meanwhile, in ARIN-Land:

https://www.mail-archive.com/nanog@nanog.org/msg98840.html Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy

-- Radu-Adrian FEURDEAN

-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================