Hi, On Fri, May 20, 2011 at 01:15:15PM +0200, Daniel Stolpe wrote:

When every LIR has had their /22, there might still be address space available, right? I interpret 1 a and b as we will have a deadlock then because the same LIR can never receive another allocation.

Well... - this is the whole *point* of the "last /8" policy - to give people that want to start a business "with Internet things!" a few years in the future the chance to get a few IPv4 addresses to run their NAT64 boxes (and whatever other migration technologies need IPv4 addresses) on. (IPv4 will still run out, though, and nothing we can do will change that). - and this part is not being discussed at all by the policy proposal here - this is to clarify that the "last /8" policy will *stay* in effect after it became active, even if some address space is returned and the NCC ends up having again more than a /8 available. While this interpretation is in line with the current policy documents, it's not explicitely written in the documents, and this proposal attempts to clarify this. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi, On Sun, May 22, 2011 at 04:33:37PM +0200, Marcin Kuczera wrote:

...

- this is the whole *point* of the "last /8" policy - to give people that want to start a business "with Internet things!" a few years in the future the chance to get a few IPv4 addresses to run their NAT64 boxes (and whatever other migration technologies need IPv4 addresses) on.

(IPv4 will still run out, though, and nothing we can do will change that).

well, how about opening new LIR, getting IPv6 + IPv4 and merging that LIR with other LIR... Then the OTHER LIR will have more than single /22 from the last /8....

Yes, you can certainly do that. Or you can buy another company that has IPv4 addresses left. Both come with a certain price tag. Or you can deploy IPv6. At some point in time, spending heaps of money to get another small bit of IPv4 addresses is just not worth the effort anymore. And there is nothing in the address policy area that we can do to magically make IPv4 last forever. But this whole discussion is completely out of scope for the policy proposal at hand - it does not install a "last /8" policy (we already have that), just clarifies some conditions. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi Roger, The decision to give returned address space back to IANA is outside the scope of (this?) allocation policy. The text in this policy however explicitly leaves room for space to be returned to IANA, instead of just stating that any and all returned space MUST be placed into the "final /8 pool", which would have been a valid interpretation had the phrase you quote below not been present - that would block all options to return space to IANA, which would be bad to have in policy. Hence the 'the below is only valid for space we already decided is not going back to IANA'. Thank you for supporting the policy proposal. Best Remco On 22-05-11 19:14, "Roger Jørgensen" <rogerj@gmail.com> wrote:

Hmm are we really sure we want to have this part in here? "This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself."

I do see the point of it yes, but what if a huge block are returned, one that could go back to IANA and be reused for something that all can benefit from? ... and we have no idea what it can be since we can't predict the future.

Do we change the policy again at that point or when thing change?

other than that, support this policy. It do make it pretty clear on how IPv4 are handled in the near-comming future.

This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

Hi Daniel, If you allow me to summarize: it is your opinion that the community is better off with the RIPE NCC not handing out address space it has available? I would have to politely disagree. I agree that aggregation is a concern as well as filtering, but given that we're appending this address space to the end of the final /8 in allocation terms, this space would only be (re)allocated after we've run out of the final /8; that is, after some 16,000 /22s have been handed out. What the default free zone will look like is anybody's guess, but I've got a pint saying that handing out /22s from other /8s is unlikely to make it a lot worse, even more so for the assorted snippets of address space that come after that. If people run filters based on RIPE documents (or any other source for that matter), they're well advised to have a procedure in place to keep those filters up to date. Best, Remco On 23-05-11 11:41, "Daniel Suchy" <danny@danysek.cz> wrote:

Hello, one thing should be considered here - this proposal in section 3b states, that minimum allocation sizes for the relevant /8 blocks will be updated if necessary.

There're a lot of ranges with /21 longest prefix now. Some people have filters in accordance to (currently) RIPE-510 document. This may be source of some operational troubles, if longest prefixes will be changed frequently - as filters will have to be updated in some networks. There's no such requirement these days (only new prefixes need to be added).

I'll rather see no changes in terms of "allowing" longer prefixes in other subnets. Changes here will more likely help some people deaggregate their prefixes in global table and only few prefixes will be announced rightly. Aggregation should be one of major goals, and even RIPE cannot enforce it, it at least should help here (and RIPE-510 is helpfull). This proposal goes against this goal sometimes, I think.

Last /8 provides quite huge number of /22 to cover future requests long-term. I think, that returned space should be reserved/used for covering potential request for more than 1024 IP addresses in one block - as we cannot imagine future these days, and someone can have good reasons to obtain larger address space... and if will be some addresses available, I don't see any reason to reject the request.

Due similar reasons - I don't support section 4 of new proposal (multiple allocations up to an equivalent of a /22). This will also cause changes in RIPE-510 and this will simplify address space deaggregation for many "bad guys".

So, instead of applying "last /8 policy" to returned space, reserving returned space as we have reserved /16 from last /8 seems to be better option for me (and potentially serve assignments like /21). Current policies used for reusing returned space are sufficient and these can be applied anytime.

Last /8 should be applied ONLY to last /8. And aggregation should be always keeped in mind, when some change in address policy is proposed.

I don't support this proposal and I suggest changes in it mentioned above.

With regards, Daniel

On 05/20/2011 12:11 PM, Emilio Madaio wrote:

...

Dear Colleagues,

A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion.

You can find the full proposal at:

http://www.ripe.net/ripe/policies/proposals/2011-03/

We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 17 June 2011.

Regards

Emilio Madaio Policy Development Officer RIPE NCC

This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

Hi Daniel, The beginning of article 5.6 in the current policy reads as follows (emphasis mine): "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space WILL ONLY BE DONE as follows:" This means the current allocation policy is out of the window at that point, and might as well not even exist. There is no point in time where the two separate pieces of allocation policy are both being executed. So, only a single /22 per LIR, no exceptions. This is the currently accepted final /8 policy. If you feel strongly about changing that, I would suggest you write a policy proposal. This proposal only means to clarify what happens to address space that is returned to the RIPE NCC after that point, and makes sure we have allocation policy in place for all the address space that the RIPE NCC holds. Having a policy in place that provides the ability to hand out all currently held address space, along with an upper limit that is lower than the most common minimum allocation size, will have an impact on the minimum allocation size for those blocks. If the chairs feel otherwise, and think this policy proposal means to re-evaluate the text of the current final /8 policy, I will withdraw it immediately, as is my discretion as the author. Best regards, Remco On 23-05-11 12:25, "Daniel Suchy" <danny@danysek.cz> wrote:

On 05/23/2011 12:01 PM, Remco Van Mook wrote:

...

If you allow me to summarize: it is your opinion that the community is better off with the RIPE NCC not handing out address space it has available? I would have to politely disagree. RIPE NCC can handle returned address space in similar way, as it does today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE NCC can (=has other space than last /8)? Normal allocations with standard policy can be processed, instead of carving last /8. There're still other limitations in place - like 6/3month address plans etc. Reserve in last /8 is - in my oppinion - large enough. There's no reason to apply last /8 policy to other address space - this will really only hold available addresses in RIPE NCC without being really used (as last /8 policy is very restrictive).

...

I agree that aggregation is a concern as well as filtering, but given that we're appending this address space to the end of the final /8 in allocation terms, this space would only be (re)allocated after we've run out of the final /8; that is, after some 16,000 /22s have been handed out. What the default free zone will look like is anybody's guess, but I've got a pint saying that handing out /22s from other /8s is unlikely to make it a lot worse, even more so for the assorted snippets of address space that come after that. Based on current numbers of current/new members of RIPE NCC, this will hapen sometimes after 12-18 years? If this will hapen really. In last /8, there's only one /22 per LIR, so it's quite easy calculation. Also I assume, that some LIRs will not apply for their last /22.

...

If people run filters based on RIPE documents (or any other source for that matter), they're well advised to have a procedure in place to keep those filters up to date. That's not argument for making these these things harder compared to current convetions.

With regards, Daniel

This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

Hi, On Mon, May 23, 2011 at 12:34:55PM +0100, Remco Van Mook wrote:

If the chairs feel otherwise, and think this policy proposal means to re-evaluate the text of the current final /8 policy, I will withdraw it immediately, as is my discretion as the author.

I read your text as "clarification of the current policy documents, and not changing the existing last /8 policy". Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

I don't want to change policy for last /8, and I aggree with it. Current policy can be read by several ways. We're just playing with words - current policy doesn't force making single /22 allocations from other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to allocate something from 185.0.0.0/8, you can do only do this and this..." in my eyes. Section 5.6 talks just about the last /8 and this is quite clear description. Last /8 is single address block. If some address space is returned, then I don't see any reasonable argument, why not (re)allocate more than /22 to someone else, if someone needs new addresses and meets other criteria. Final decision is still on RIPE NCC - and I think they can better analyse particular case in time of real occurrence - compared to general "what-if" proposals. Maybe we can serve only new LIRs in that case, that's limitation which should be accepted - that's question. This will make startups easier - well, IPv6 is solution, but until will be IPv6 adopted by large networks/content providers having large IPv4 allocations already - these aren't under pressure, if we're talking about IPv6 migration. Even small starting ISPs will need IPv4... why restrict allocations to new networks, if there's space other than from last /8 available? Just because they came too late...? This kind of restriction/regulation will more likely support grey market - people will be trying other ways to "sell" their existing allocations to someone, who needs them (and of course, they'll find policy-conforming way). Reserve in last /8 is quite enough to cover future requirements for very long term and there's no need to block address usage in other /8 managed by RIPE NCC. Your proposal simply creates additional blocked and efectivelly unused address space in other /8 just due to the policy. RIPE NCC is here for address distribution to end users. I'm just using arguments of Remco now - addresses should be used, not reserved for something surreal. Daniel On 05/23/2011 01:34 PM, Remco Van Mook wrote:

Hi Daniel,

The beginning of article 5.6 in the current policy reads as follows (emphasis mine):

"The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space WILL ONLY BE DONE as follows:"

This means the current allocation policy is out of the window at that point, and might as well not even exist. There is no point in time where the two separate pieces of allocation policy are both being executed. So, only a single /22 per LIR, no exceptions. This is the currently accepted final /8 policy. If you feel strongly about changing that, I would suggest you write a policy proposal.

This proposal only means to clarify what happens to address space that is returned to the RIPE NCC after that point, and makes sure we have allocation policy in place for all the address space that the RIPE NCC holds. Having a policy in place that provides the ability to hand out all currently held address space, along with an upper limit that is lower than the most common minimum allocation size, will have an impact on the minimum allocation size for those blocks.

If the chairs feel otherwise, and think this policy proposal means to re-evaluate the text of the current final /8 policy, I will withdraw it immediately, as is my discretion as the author.

Best regards,

Remco

On 23-05-11 12:25, "Daniel Suchy" <danny@danysek.cz> wrote:

...

On 05/23/2011 12:01 PM, Remco Van Mook wrote:

...

If you allow me to summarize: it is your opinion that the community is better off with the RIPE NCC not handing out address space it has available? I would have to politely disagree. RIPE NCC can handle returned address space in similar way, as it does today, I mentioned that. Why not to assign /21, /20 to someone, if RIPE NCC can (=has other space than last /8)? Normal allocations with standard policy can be processed, instead of carving last /8. There're still other limitations in place - like 6/3month address plans etc. Reserve in last /8 is - in my oppinion - large enough. There's no reason to apply last /8 policy to other address space - this will really only hold available addresses in RIPE NCC without being really used (as last /8 policy is very restrictive).

...

I agree that aggregation is a concern as well as filtering, but given that we're appending this address space to the end of the final /8 in allocation terms, this space would only be (re)allocated after we've run out of the final /8; that is, after some 16,000 /22s have been handed out. What the default free zone will look like is anybody's guess, but I've got a pint saying that handing out /22s from other /8s is unlikely to make it a lot worse, even more so for the assorted snippets of address space that come after that. Based on current numbers of current/new members of RIPE NCC, this will hapen sometimes after 12-18 years? If this will hapen really. In last /8, there's only one /22 per LIR, so it's quite easy calculation. Also I assume, that some LIRs will not apply for their last /22.

...

If people run filters based on RIPE documents (or any other source for that matter), they're well advised to have a procedure in place to keep those filters up to date. That's not argument for making these these things harder compared to current convetions.

With regards, Daniel

This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.

Hi, On 05/23/2011 03:10 PM, Sander Steffann wrote:

...

Current policy can be read by several ways. We're just playing with words - current policy doesn't force making single /22 allocations from other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to allocate something from 185.0.0.0/8, you can do only do this and this..." in my eyes. Section 5.6 talks just about the last /8 and this is quite clear description. Last /8 is single address block.

That is not what it says. The text is: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:"

It says, 'the distribution of IPv4 address space' in general. Once the RIPE NCC has to allocate addresses from the last /8, then from that point in time the distribution "will only be done as follows", which is specified in the "1. Allocations for LIRs from the last /8" and "2. Unforeseen circumstances" sections. The text is pretty clear that I think.

Article name is: "Use of last /8 for PA Allocations" - that doesn't mean other /8... it's all only about last /8.

...

If some address space is returned, then I don't see any reasonable argument, why not (re)allocate more than /22 to someone else, if someone needs new addresses and meets other criteria.

Because the current policy specifies that this is not possible. That can be changed by proposing a different policy of course. Current policy keeps this question open. And new proposal is similar - if some article is named "use of last /8" (5.6), it cannot influence other /8's - or this article name doesn't make sense. Last /8 is only one and policy had to be clear.

...

Final decision is still on RIPE NCC

The RIPE NCC can only decide what we (the community) tell them to decide. They follow the policies we set here on this mailing list.

And I don't see any argument, why tie RIPE NCC hands by applying this policy to other /8's. Current procedures can be used without any problem anytime - even in future on returned address space. If no addresses are available except last /8, allocations are simply proceeded in accordance to section 5.6, if there's some other address space available, standard procedure can be applied. Daniel

Dear Daniel,

On 05/23/2011 03:10 PM, Sander Steffann wrote:

...

...

Current policy can be read by several ways. We're just playing with words - current policy doesn't force making single /22 allocations from other blocks than 185.0.0.0/8 (last /8) - it just says "if you have to allocate something from 185.0.0.0/8, you can do only do this and this..." in my eyes. Section 5.6 talks just about the last /8 and this is quite clear description. Last /8 is single address block. That is not what it says. The text is: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:"

It says, 'the distribution of IPv4 address space' in general. Once the RIPE NCC has to allocate addresses from the last /8, then from that point in time the distribution "will only be done as follows", which is specified in the "1. Allocations for LIRs from the last /8" and "2. Unforeseen circumstances" sections. The text is pretty clear that I think.

Article name is: "Use of last /8 for PA Allocations" - that doesn't mean other /8... it's all only about last /8.

I am afraid the text of ripe-509 is very clear: "The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA. From then on the distribution of IPv4 address space will only be done as follows:" This says two things: 1. These policies do not have to be applied as long as the RIPE NCC has other available addresses than the last /8 2. Once these policies have been triggered, there is no way back (see "From then on...").

And I don't see any argument, why tie RIPE NCC hands by applying this policy to other /8's. Current procedures can be used without any problem anytime - even in future on returned address space. If no addresses are available except last /8, allocations are simply proceeded in accordance to section 5.6, if there's some other address space available, standard procedure can be applied.

The current policies do not allow this. You may want to submit a new proposal. I personally do not think it would be wise to allocate returned addresses in accordance with policies applicable before the last /8, if we already started to allocate from the last /8 (i.e. I do not think it would be wise to have two sets of policies, both live at the same time, one applicable to the last /8 and an other one to the returned address space). For the record, I support the "Post-depletion IPv4 address recycling" policy. Best regards, Janos

Hi, On Mon, May 23, 2011 at 06:06:28PM +0200, Daniel Suchy wrote:

Then article name isn't clear. As it doesn't apply these days, it doesn't matter, but in future this may confuse someone, as last /8 is only one.

To clear up this confusion, we have the policy propsal 2011-03 (this one) on the table. That's the point. [..]

...

From database point of view, there will be two sets of policies on single /8 - in future on all except 185.0.0.0/8 (the last one). One "historic" (for allocations made before some not-yet-known date) and some "current" for new allocations after that magic date - with real influence to RIPE-510 (operational impact I mentioned already). Current system is very clear in terms of each new /8 usage, proposed change will introduce new uncertainty to other exising /8.

minimum allocation sizes for certain /8 have changed in the past, for example when the minimum allocation size was reduced to a /21, and people have adapted their filters accordingly. Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Am Tue, 24 May 2011 08:13:54 +0200 schrieb Roger Jørgensen <rogerj@gmail.com>:

On Mon, May 23, 2011 at 2:47 PM, Daniel Suchy <danny@danysek.cz> wrote: <snip>

...

I think you might missed the same fine point I did... RIPE NCC can still return addresses to IANA and those addresses will not fall in under the /8 rule?

If IANA in such a case redistributes resources to the RIR, e.g. RIPE NCC, they will fall under the /8 policy as it is right now. BTW, I do support the proposal. Regards, Andreas -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund

Hi, On Mon, May 23, 2011 at 02:43:16PM +0200, Daniel Stolpe wrote:

I guess this depends on what we want to happen. If we think it's about time to "act now" on IPv6 this is probably the right thing. As I wrote earlier, once we enter the "final /8 stage" any remaning and/or returned IPv4 space will be locked. That means it will be complete meningless to return any space to the RIPE NCC and we will surely see quite a bit of black market tradning instead.

Thanks for the clarification - yes, this could be one of the possible side effects. On the other hand, it is not completely unreasonable to assume that "returning to the RIPE NCC for free" is not going to happen as long as there is paying customers to receive the address space - and if there is no longer a market, there might not be that much demand from the RIPE NCC either... I don't know what the future brings regarding IPv4 - but I can only strongly urge everybody to accept the fact that the IPv4 supply at all RIRs is running out, and investigate alternatives.

So Daniel has got a point but as Gert pointed out it might be outside the scope of this proposal.

Well. The current "last /8" policy does not really take this situation into account, and so the RIPE NCC decided how to handle that situation *should* it happen (by not going back to the old policy). At the last meeting, there was no opposition against that interpretation of the policy, but it was felt that this should be written down, to make it very explicit - and this is what Remco is proposing. If we indeed want something else to happen, a new policy proposal should be brought forward to actually change the current text to make it only apply to "addresses specifically from the last /8" - but beware, this will cause more unhappiness, and more concerns about *unfairness*. Just assume that someone generous will return a /16, and there are 5 large DSL or cable ISPs that all can document a need for at least a /12 in the next 3 months... ... so who will get the /16? What about the 20 smaller ISPs that only want a /20 each? As soon as we're down to managing the scraps, *any* policy is likely to cause major feelings of unfairness... Gert Doering -- APWG chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

On 24.05.11 09:21, Marcin Kuczera wrote:

however, if it touches returned all address space kind (PI/PA) and we don't really know what is going to happen - maybe it is reasonable to postopne the policy start point to let's say - 50 or 60% of last /8 usage ?

what "problem" should postponing solve? I support the proposal like it is. best regards, Wolfgang -- Wolfgang Tremmel e-mail: wolfgang.tremmel@de-cix.net DE-CIX Management GmbH Phone: +49 69 1730 902-26 Lindleystr. 12, 60314 Frankfurt Mobile: +49 171 8600 816 Geschaeftsfuehrer Harald A. Summa Fax: +49 69 4056 2716 Registergericht AG Koeln, HRB 51135 http://www.de-cix.net Zentrale: Lichtstr. 43i, 50825 Koeln

...

...

however, if it touches returned all address space kind (PI/PA) and we don't really know what is going to happen - maybe it is reasonable to postopne the policy start point to let's say - 50 or 60% of last /8 usage ?

what "problem" should postponing solve? I support the proposal like it is.

i.e. if some company still need /24 PI for their purposes (non ISP company), after 2011-03 start, there will be no way to get PI any more (except from black market).

Noting first that this eventuality will also occur if 2011-03 is not adopted. I think that this idea is in effect a no-op, because even if implementation of 2011-03 is postponed, any returned address space will still not be reallocated using old policies. I guess the intent of the suggestion though is to expand the scope of 2011-03 from one of clarification to one of reopening old allocation policies. Quite apart from the author's stated reluctance to expand the scope in any way, this would lead to a state, of unknown duration, where old allocation policies are attempted to be fulfilled with a run rate that is vastly smaller than demand, in parallel with the rationing procedures that are already set. This is a situation that is explicitly avoided both by the current wording of RIPE-509 and by the proposed changes of 2011-03. It is not a small change. What we have with RIPE-509, and what 2011-03 does not damage imo, is a plan to deal with runout in as clear and fair a manner as we can muster at this point. There is a moment at which the rules change for everyone; there is no question of some subsequently getting served with policies that cannot possibly be applied to all. We all feel the temptation to try to squeeze a little more out of the old way, to try to redistribute what scraps we can find in some manner that will stave off the consequences of runout for a few more people for a little longer. But we've already optimised pretty much all the slack we can out of this; any further changes must undermine clarity and fairness. We should resist the temptation to try to optimise to an infinitesimal degree for the sake of a few scraps. And, frankly, we should take every opportunity remaining to expand the meagre pool of IPv4 addresses we leave to our children. I support 2011-03 with the wording proposed by its author. Best regards, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9

Hi,

2. It's not explicitly defined because it all depends on the address space returned. As I already indicated in another email, the long term effect of this is likely to be that all /8s managed by the RIPE NCC will have a minimum allocation size of a /22; and if we then run out of /22s or larger and need to hand out multiple smaller blocks (moving to clause 4) a few additional /8s might get *really* unlucky. But that will only happen when we're scraping the RIPE NCC barrel.

If we reach that point people can be glad they get *any* addresses. It's either this or no IPv4 addresses at all. They might hit prefix-length filters, but still, at least they have a chance to try something. - Sander

Hi, Am 26.05.2011 um 10:52 schrieb Remco Van Mook:

Hi Sascha,

On 26-05-11 08:38, "Sascha Lenz" <slz@baycix.de> wrote:

...

Although i like to raise a little concern about the vague point 4 - Insufficient address space : Do we really want to tell the hostmasters/IPRAs to allocate 2x /25, 4x /26 8x /27 ... and so on to LIRs in the end?

Indeed that's what we tell them to, although it's not going to be quite so dramatic as you think. Point 4 is there to ensure that, even though the current final /8 policy explicitly states a single /22, RIPE NCC is not going to get stuck with a pile of /23s and smaller at the end of it all.

I don't think it will be dramatic at all, otherwise i wouldn't support the proposal ;-) I just wasn't 100% sure that this wording is "what we want". [...]

that people will likely be happy to take anyway. I don't know what the current RIPE NCC stockpile of /25s and smaller is, but I think it's unlikely that at the point where we have to start using these for allocations, it's going to have a dramatic impact on the routing table (as I think it'll be a shambles at that point anyway).

I'm actually satisfied with the point that we shouldn't see much of that just because there shouldn't be much of this sub-/24 fragmentation anyways. (But only the NCC can tell). I was a bit blinded by the PI situation where we seem to have this kind of fragmentation, but due to the allocation policy for PA space this shouldn't be the case in the "PA /8s" in the first place. So now i'd rather say this wording is a non-issue, nevermind.

The final dozen or so LIRs to ever get IPv4 space from the RIPE NCC are going to have to deal with a mixed blessing.

*sigh* Let's create a "Secret End-of-IPv4 WG" and announce "IPv4 rapture day" for 01.04.2012 or something :-> -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect