2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
Dear colleagues, A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions: - These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 15 June 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC
Thank you Marco. Dear colleagues, Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this. The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations. We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes: - All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL'; - Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated; - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it; - Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively); - DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space. And, outside of policy but enforceable as business rules following from this policy proposal: - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22 - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22 Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes. Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session. Kind regards, Remco van Mook (no hats)
On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-03
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 15 June 2016.
Regards
Marco Schmidt Policy Development Officer RIPE NCC
Hello all,
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
Will current 'ALLOCATED PA' be changed to 'ALLOCATED FINAL' ? Denis
On 17 May 2016, at 14:33 , Denis Fondras <ripe@liopen.fr> wrote:
Hello all,
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
Will current 'ALLOCATED PA' be changed to 'ALLOCATED FINAL' ?
For allocations handed out after 'final /8' came into effect, yes. Remco
On 17 May 2016 at 13:08, Remco van Mook <remco.vanmook@gmail.com> wrote:
Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.
So this includes LIR's who already have (through acquisition of other companies) multiple /22 from the last /8 That kinda sucks... In general I can see the point *but* please can we just stack the deckchairs neatly on the side and get into the boats... J -- James Blessing 07989 039 476
On 17 May 2016, at 14:44 , boggits <boggits@gmail.com> wrote:
On 17 May 2016 at 13:08, Remco van Mook <remco.vanmook@gmail.com <mailto:remco.vanmook@gmail.com>> wrote:
Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.
So this includes LIR's who already have (through acquisition of other companies) multiple /22 from the last /8
It doesn't apply retroactively - so if you have already merged LIRs and are currently holding multiple /22s form the final /8 you're fine. It does stop future cases though. Remco
On Tue, May 17, 2016 at 02:46:02PM +0200, Remco van Mook wrote:
It doesn't apply retroactively - so if you have already merged LIRs and are currently holding multiple /22s form the final /8 you're fine. It does stop future cases though.
So it puts new entrants at a competitive disadvantage to existing LIRs? I'm sure that will look just *great* in court. rgds, Sascha Luck
On 17 May 2016, at 14:52, Sascha Luck [ml] <apwg@c4inet.net> wrote:
So it puts new entrants at a competitive disadvantage to existing LIRs?
It has been that way ever since SRI first started doling out Class A, B and C blocks in the 1980s. No matter what the prevailing policy might be, new LIRs are by definition going to be disadvantaged because the NCC and the RIR system more generally has a far smaller (and almost empty) pool of IPv4 address space to allocate from. Get over it. We can’t conjure up an infinite supply of IPv4 space to give everyone at least as much as they think they need. The only question now is to decide what’s the best or least worst to share that pain of distributing what’s left.
On Tue, May 17, 2016, at 14:46, Remco van Mook wrote:
So this includes LIR's who already have (through acquisition of other companies) multiple /22 from the last /8
It doesn't apply retroactively - so if you have already merged LIRs and are currently holding multiple /22s form the final /8 you're fine. It does stop future cases though.
This is not exactly my reading of the new 5.1.5. If a LIR already holds several /22 and stays the way it is, OK, it stays the same. However, if a LIR, holding several "last /22" *today* acquires another LIR having a "last /22" and proceeds to a merger, in my reading it is supposed to loose the equivalent of "last /8 space" it already has. And I this cannot stop me thinking about the incitation of keeping as many LIRs as possible alive. You can always buy another company and keep the LIR, and this will be exactly what will happen if this policy gets implemented. This is basically a first (err, or is it a second) step to transforming RIPE NCC to a profitable "for profit" company. And if it will not be RIPE NCC getting the profits, it will be the "old LIRs" getting all the benefits (one single membership fee instead of several). I can see a hat there.... Otherwise: - still no incitation to deploy IPv6. Zero. Nada. a.k.a. "IPv4 is good, please go to the market; IPv6 really is irrelevant". - I don't get the point for the "reverse delegation restriction". BTW, how do you define "another party" ? - see the arguments for 2015-05 (I suppose this proposal is just the counter-reaction to that one), what you say is just dust in new entrants' eyes : "you have a /22 to start, but nothing more to live". It also misses the point of what is a "new entrant" today : i.e. not always someone prepared to do the "registry" job - "registry" like the "R" in LIR. Circumvention : keep up with multiple LIRs, for NCC's profit. But after all, I can also understand the very high possibility that this proposal is only a bad joke (even it we're May 15th, not April 1st). Just in case it's not clear, I'm completely against. -- Radu-Adrian FEURDEAN fr.ccs
Radu-Adrian, can you please clarify and substantiate this part of your response?
This is basically a first (err, or is it a second) step to transforming RIPE NCC to a profitable "for profit" company. And if it will not be RIPE NCC getting the profits, it will be the "old LIRs" getting all the benefits (one single membership fee instead of several). I can see a hat there....
Kind regards, Remco
Remco, As you may know, the "multiple LIRs" is for the moment least expensive way of getting around the "one /22" restriction. Combined withe the removal of "need checking", this very much looks like selling /22 to anybody willing to pay a sign-up and at least one year of membership. This may not have been intentional, but it looks to me as a first step to "turning commercial". With your proposal, while the idea was to discourage the "multiple LIR" practice, I have very serious doubts that it will happen this way. Given the current market price (which is only the most important show-stopper, but not the only one), with your proposal it would take about 5 years of membership to get at a similar level. With all that money going to the NCC. IF the NCC really whishes to keep its not-for-profit status, this will result in reduced membership, one reduced membership for older LIRs, but several memberships for the LIRs in "desperate need" (mostly small new ones). And of course, it would look more like a business of "leasing IPv4 blocks". ... and you DO have a NCC hat. I hope it does clarify my previous e-mail. On Wed, May 18, 2016, at 00:24, Remco van Mook wrote:
Radu-Adrian, can you please clarify and substantiate this part of your response?
This is basically a first (err, or is it a second) step to transforming RIPE NCC to a profitable "for profit" company. And if it will not be RIPE NCC getting the profits, it will be the "old LIRs" getting all the benefits (one single membership fee instead of several). I can see a hat there....
-- Radu-Adrian FEURDEAN fr.ccs
On Sun, May 22, 2016 at 12:45 PM, Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:
Remco,
As you may know, the "multiple LIRs" is for the moment least expensive way of getting around the "one /22" restriction. Combined withe the removal of "need checking", this very much looks like selling /22 to anybody willing to pay a sign-up and at least one year of membership.
This may not have been intentional, but it looks to me as a first step to "turning commercial".
With your proposal, while the idea was to discourage the "multiple LIR" practice, I have very serious doubts that it will happen this way. Given the current market price (which is only the most important show-stopper, but not the only one), with your proposal it would take about 5 years of membership to get at a similar level. With all that money going to the NCC. IF the NCC really whishes to keep its not-for-profit status, this will result in reduced membership, one reduced membership for older LIRs, but several memberships for the LIRs in "desperate need" (mostly small new ones).
I don't find your response clarifying in the least. You seem to be confused about what constitutes non-profit and what constitutes for-profit or "commercial". Making _a_ profit does not automatically make you a for-profit/commercial enterprise. -- Jan
On Sun, May 22, 2016, at 13:02, Jan Ingvoldstad wrote:
You seem to be confused about what constitutes non-profit and what constitutes for-profit or "commercial". Making _a_ profit does not automatically make you a for-profit/commercial enterprise.
Investment fund would probably be more appropriate. So is it possible to have a non-profit investment fund ? For me "non-profit" means not actively seeking profit; target being a zero end-of year result.
On Sun, May 22, 2016 at 2:52 PM, Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:
On Sun, May 22, 2016, at 13:02, Jan Ingvoldstad wrote:
You seem to be confused about what constitutes non-profit and what constitutes for-profit or "commercial". Making _a_ profit does not automatically make you a for-profit/commercial enterprise.
Investment fund would probably be more appropriate. So is it possible to have a non-profit investment fund ? For me "non-profit" means not actively seeking profit; target being a zero end-of year result.
I see no evidence that the RIPE NCC is "actively seeking profit" in any reasonable sense of that phrase. Could you please take that rhetoric out by the barn, shoot it, and bury it in a deep grave, so we don't have to see it anymore? -- Jan
Hi, On Sun, May 22, 2016 at 02:52:08PM +0200, Radu-Adrian FEURDEAN wrote:
Investment fund would probably be more appropriate. So is it possible to have a non-profit investment fund ? For me "non-profit" means not actively seeking profit; target being a zero end-of year result.
And this is what the NCC is doing - target being a zero result. There is money on the bank accounts, with the goal of being enough to sustain the NCC for somewhat over a year in case something catastrophic happens. If that money were to grow significantly, the NCC would have to pay taxes, which we all do not want - which is why the surplus was refunded last year. (All of this is more a matter for the membership meeting, though, where detailed financial numbers are presented) Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
* Radu-Adrian FEURDEAN
As you may know, the "multiple LIRs" is for the moment least expensive way of getting around the "one /22" restriction. Combined withe the removal of "need checking", this very much looks like selling /22 to anybody willing to pay a sign-up and at least one year of membership.
I've attempted to explain to you before[1] why this line of reasoning makes no sense, but I'll try again in case you missed it the first time around. The RIPE NCC has always been automatically handing out minimum-sized initial IPv4 allocations to new members. This you can see already in ripe-136, which dates all the way back from 1996: «The first allocation will be made automatically by the RIPE NCC, generally upon receipt of the first assignment request from the local IR. Because there is no information about the rate at which a new IR will make address assignments, the size of the first allocation is always a /19 (8092 addresses).» "Need checking" was only used whenever the new LIR requested an initial allocation *larger* than the minimum allocation size, something the policy was later updated to allow for. (Figuring out exactly when that happened is an exercise left for the reader.) When the «last /8» policy was implemented, the possibility to request larger-than-minimal initial allocations was removed, so the procedure for receiving an initial allocation essentially reverted back to what it was in 1996: the initial allocation is a fixed size prefix that is given automatically to any new LIR requesting it. In short: today's practise of automatically giving minimum-sized allocation to new LIRs is something the RIPE NCC has been doing since its inception, and it's all in accordance with the RIPE community's policies. If you're going to continue to accuse the NCC of «selling IPv4», then you'll have to claim that that's something they've *always* done, and furthermore that they're currently «selling IPv6» in exactly the same way. Or, even better, you can stop making this nonsensical accusation. Tore [1] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-May/011215.ht...
W dniu 2016-05-17 o 14:08, Remco van Mook pisze:
- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);
Dear Remco and All @ APWG It should be clearly written that the policy proposal is not retroactive. With the current text the intention is not clear. Best regards Tomasz Śląski pl.skonet
Hello, I disagree with the proposal. Any such proposal would cause issues with ability of smaller players merging into larger ones, effectively blocking them becoming competitive to the long established LIRs, effectively giving an unfair advantage to the big players. Kind Regards, Dominik Clouvider Limited From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Remco van Mook Sent: 17 May 2016 13:08 To: Marco Schmidt <mschmidt@ripe.net> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy) Thank you Marco. Dear colleagues, Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this. The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations. We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes: - All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL'; - Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated; - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it; - Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively); - DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space. And, outside of policy but enforceable as business rules following from this policy proposal: - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22 - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22 Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes. Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session. Kind regards, Remco van Mook (no hats) On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt@ripe.net<mailto:mschmidt@ripe.net>> wrote: Dear colleagues, A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions: - These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net<mailto:address-policy-wg@ripe.net>> before 15 June 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC
I disagree with the proposal too. That's another one bad policy example. 1) small companies will be very hard to join ipv4. 2) unfair play between big and small IPv4 owners. 3) in final that will not change current IPv4 distribution from last /8 significantly. Any policy should help people to use global Ipv4 space effectively for progress, but I can't see anything in this one policity that would help. If the policy reason is just to make all Ipv4 management/getting harder - may be just close giving IPv4 and that all? The policy should make the world simple but not harder. I talk a lot of with new small companies who want to start with IPv4. They say bad about too much RIPE rules and police. For beginners it's too hard to join all this, and this policy make it harder. Yuri@IP4market On 17.05.2016 15:58, Dominik Nowacki wrote:
Hello,
I disagree with the proposal.
Any such proposal would cause issues with ability of smaller players merging into larger ones, effectively blocking them becoming competitive to the long established LIRs, effectively giving an unfair advantage to the big players.
Kind Regards,
Dominik
Clouvider Limited
*From:*address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] *On Behalf Of *Remco van Mook *Sent:* 17 May 2016 13:08 *To:* Marco Schmidt <mschmidt@ripe.net> *Cc:* address-policy-wg@ripe.net *Subject:* Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
Thank you Marco.
Dear colleagues,
Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.
The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.
We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:
- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
- Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it;
- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);
- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.
And, outside of policy but enforceable as business rules following from this policy proposal:
- No RPKI for any 'ALLOCATED FINAL' blocks over a single /22
- No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22
Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.
Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.
Kind regards,
Remco van Mook
(no hats)
On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt@ripe.net <mailto:mschmidt@ripe.net>> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-03
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>> before 15 June 2016.
Regards
Marco Schmidt Policy Development Officer RIPE NCC
Dear Remco, For a few months now, we have been talking on how to give some supplementary IP’s to LIR’s and now you are proposing a policy to retrieve back some already allocated IP space? Even if we are in the afterlife of IPv4, you cannot force the return of /22’s from the last /8 after a merger or acquisition. How do will RIPE plan to deal with the already transferred /22’s from the /8, or the already sub allocated IP spaces? There are many LIR’s that announce more than 1 /22’s from the /8, we should try to focus on the abuse and not dramatically change a policy that almost works. At this moment I have no idea how but maybe we should implement an anti-abuse policy with full powered department that can deal with ‘creative interpretations’? I really do understand your good intention here but instead of fixing the ‘creative interpretations’ it will cause more and more issues. I am against this proposal as it is unfair, and some or maybe of us do not agree with retroactively policies, we already know how the work from our governments :) Thanks, -- Bogdan-Stefan Rotariu Sent with Airmail On 17 May 2016 at 15:09:14, Remco van Mook (remco.vanmook@gmail.com) wrote: Thank you Marco. Dear colleagues, Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this. The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations. We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes: - All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL'; - Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated; - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it; - Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively); - DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space. And, outside of policy but enforceable as business rules following from this policy proposal: - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22 - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22 Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes. Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session. Kind regards, Remco van Mook (no hats) On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt@ripe.net> wrote: Dear colleagues, A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion. The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions: - These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 15 June 2016. Regards Marco Schmidt Policy Development Officer RIPE NCC
On 17 May 2016, at 13:08, Remco van Mook <remco.vanmook@gmail.com> wrote:
The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.
...
Let's hear your thoughts.
I broadly agree with Nick’s position. The clarifying part of 2016-03 should be put into a separate proposal. ie The current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA. This tweak is just good housekeeping and should be non-controversial. I hope that a new proposal along those lines would get consensus and be quickly adopted since it’s clarifying some unintended confusion in the current policy text. While I am sort of in agreement with some of the other aspects of 2016-03, these should go into into another proposal because those ideas may well run into troubled waters. It would be a pity if the above clarification got held up because of the likely squabbling over 2016-03’s suggestions on transfers and return of space. It would be better if those two different strands didn’t have to share the same fate. They’re orthogonal to each other too. Consider this a “meh” on 2016-03. I don’t support the proposal but I don’t object to it either.
Dears, I oppose to the current policy proposal as written. It does not mean that a second version would not be acceptable but this one has a few major problems: On 5/17/16 3:08 PM, Remco van Mook wrote:
Thank you Marco.
Dear colleagues,
Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this.
The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations.
This is true. However, it creates several problems and fixes only one. The fix - allocations from 'last /8' can not be transferred any longer (once this proposal is accepted and becomes policy).
We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes:
- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';
All allocations (as in all those that were allocated since 2012?) or only the ones that are going to be allocated once this proposal becomes policy?
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated; I would agree with the 'no transfer' ban but do not agree with the no sub-allocation. If someone wants to 'sub-allocate', they can easily create assignments. This can not be enforced except if we forbid the creation of sub-allocated PA objects using business rules. But even if we use business rules, that will only block the creation of sub-allocation blocks to the LIRs that really want to follow every word of the policy, the abusers will continue to abuse. - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it; What if an LIR has already received a transfer of a 'last-/8' block. They have paid for it and the RIPE NCC has approved the transfer. Requesting those back would lead to the NCC being sued over and over again.
- Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively); If you want this not to be applied retroactively, it must be very clear in the policy proposal. It looks like it would not apply retroactively
- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space. How can the NCC enforce this? Why should 'ALLOCATED FINAL' IPv4 blocks have specific rules regarding reverse delegation but not the rest? Will
As we have discussed privately, you do not intend for this policy proposal to apply retroactively. If that is the case, then you need to figure out a solution for those that will have 2 or more 'last-/8' blocks before this proposal becomes policy. That is why I believe a second version is needed as this one is not clear. the way this proposal is worded but it's not very clear. this not be confusing?
And, outside of policy but enforceable as business rules following from this policy proposal: - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22 - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22
Just like with reverse delegation, I oppose to having 'special' rules for the routing of 'ALLOCATED FINAL' blocks. Additionally, and this is the reason I mainly oppose, if this proposal would become policy it would force every single small company that needs IPv4 addresses for its operations to hire someone to handle the communication with the RIPE NCC, the routing and the reverse delegation for their 'last-/8 allocation'. Currently most customers of LIRs are redirected to the RIPE NCC (to become LIRs and get a /22) if they need (a few) IP addresses. This policy proposal forbids the LIR to manage the address space of the small - newly created - LIR (their customer). We currently manage and maintain the address space of several customers of ours (LIRs). This policy proposal aims to request each of our customers to hire their own IT team because an other entity can not manage their 'last-/8' allocation (but it's ok for the other allocations they hold). Forbidding routing/reverse dns to be managed by the large ISP or a consultant is one of the big problems of this proposal. Also, this can be easily worked around and I doubt the NCC can even enforce this rule.
Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.
Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session.
NEWTEXT: 5.1.5: An allocation marked "ALLOCATED FINAL" is valid as long as it remains with the LIR it was allocated to. If an LIR, due to mergers, acquisitions or other means gains additional allocations marked "ALLOCATED FINAL", all but the equivalent of a single /22 will be de-registered by the RIPE NCC within 180 days. Let's take the following example: LIR A receives their 'last-/8' allocation in 2014. In 2015 it transfers (transfer or merger) an other 'last-/8' allocation. In 2016Q2 this policy proposal is approved and the RIPE NCC updates the RIPE Database objects. Now they have two 'ALLOCATED FINAL' blocks. In 2016Q4 they want to transfer a non-last-/8 allocation, will they be forced to return one of the two ALLOCATED FINAL blocks? If not, why? If yes, how long do you think it will take until the NCC is taken to court? NEWTEXT: 5.4: [...] Sub-allocations cannot be made from allocations with a status of "ALLOCATED FINAL". The meanings of the various "status:" attribute values are described in Section 7.0. Why? What would be the difference between a Sub-allocation and an Assignment in this case? Are we really adding stuff in the policy that works against the registration goal? NEWTEXT 3.0: [...] For "ALLOCATED FINAL" IPv4 address space, authority may not be delegated to another party, and the reverse delegation will be limited to a total of a /22 of IPv4 address space. How can this be enforced? Since when is the community or the NCC getting involved in how someone manages their network and/or reverse delegation? Again, how long do you think it will take before the RIPE NCC is taken to court for implementing a policy proposal that forces new (small) LIRs (or even older, bigger ones) to cancel their contracts with their ISP or consultants for the management of their resources/LIR?
Kind regards,
Remco van Mook (no hats)
Regards, Elvis (wearing a fedora while writing this reply)
On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt@ripe.net <mailto:mschmidt@ripe.net>> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-03
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net <mailto:address-policy-wg@ripe.net>> before 15 June 2016.
Regards
Marco Schmidt Policy Development Officer RIPE NCC
Hi Remco,
Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8').
The proposal claim to «explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA». But is current policy really ambigous in this regard? IIRC this was already fixed in 2011-03.
The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6.
Actually, that particular clause was removed by 2014-04.
- All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL';
Okay, whatever, although I am far from certain that this cosmetic change is worth the risk/trouble (breaking tools etc).
- Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated;
With regards to transfers, do we have data that show that this is still a problem that needs fixing after 2015-01 was passed? With regards to sub-allocations, I fail to understand what problem are you trying to solve? Isn't delegating resources downstream towards end-users (i.e., making assignments or sub-allocations) essentially the whole point of operating an LIR? Stopping LIRs from doing "LIR stuff" seems ill advised to me - or what am I missing here?
- Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it; - Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively);
The proposal needs guidance to the NCC as to which specific /22 the NCC should de-register. The oldest? The least-assigned?
- DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space.
Uhm. Why? And how exactly would this be enforced?
And, outside of policy but enforceable as business rules following from this policy proposal: - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22 - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22
Okay, so it's good this is not mentioned in the actual proposed new policy text (even though it says otherwise in the summary), because these suggestions makes absolutely zero sense to me. Why would we try to prevent operators from accurately describing their routing policies in the RIPE database and publish corresponding ROAs?
Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes.
I'm quite willing to discuss a policy proposal that focuses on the first part of this. That is, ensure that a single LIR can only hold a single "final" /22 and stopping creative hoarding. However, such a proposal would also need to provide some discussion and preferably hard data that shows that 2015-01 isn't working. The extra limitations, however, make this propsal a non-starter for me. You claim that they're workable "if you're using the space the way it was intended", but I highly doubt that it was ever the intention of the RIPE community that an LIR shouldn't be allowed to perform standard LIR tasks with its final /22 like delegating reverse DNS, creating sub-allocations, ROAs, route objects, etc. If on the other hand those restrictions were only meant to impact "hoader LIRs" with >1 final /22, then it seems to me that the mandatory de-registration is sufficient as it will automatically implement all of the proposed restrictions (and more) for the excessive /22s, while leaving "legitimate" final /22s alone. (I don't see any text in the actual proposal that implements the «if you no longer need it [..], you have to return the excess» requirement you described above, by the way.) Tore
I do not support this proposal as long as this is not cleared :
With regards to sub-allocations, I fail to understand what problem are you trying to solve? Isn't delegating resources downstream towards end-users (i.e., making assignments or sub-allocations) essentially the whole point of operating an LIR? Stopping LIRs from doing "LIR stuff" seems ill advised to me - or what am I missing here?
However I support the spirit of this proposal where allocation from RIPE and usage of IPv4 should be made harder. If IPv4 requires more work than IPv6 then perhaps we will see an increase in IPv6 usage (or I might be naive)
The proposal needs guidance to the NCC as to which specific /22 the NCC should de-register. The oldest? The least-assigned?
I don't think so. LIR might be free to give back any /22 it suits better. Denis
Like the curate's egg, this proposal is good in parts. Here's the good part:
- Explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA
The rest of the proposal is - like the rest of the curate's egg - best deposited in the compost bin. Specifically, it will not deal with the problem that the RIPE NCC was set up to do, namely to ensure accurate registration of resources. On the contrary, it will encourage black-market transfer of /22s and probably a proliferation of one-allocation-per-shelf-company allocations, because paying €1400 per annum for 1024 addresses is still a cheaper option in the medium term than buying addresses outright on the market (1024/€1400 = €0.73 per address per annum). At this stage, APWG is being trolled with "let's change the last /8 policy" proposals. It's clear that there isn't consensus on 2015-05 and that there won't be any consensus on this proposal either, so I'd politely like to ask the chairs to do two things: 1. declare their opinion on whether 2015-05 reached consensus 2. use the bunfight which is inevitably going to happen in Copenhagen to allow them to exercise more restraint about what sort of proposals hit the mailing list in future so that we don't spend years wasting time squabbling about the dregs sitting at the bottom of the ipv4 allocation barrel. (ap-wg chairs: for the record, this is a "I object" email). Nick
On 17 May 2016, at 14:01, Nick Hilliard <nick@foobar.org> wrote:
so that we don't spend years wasting time squabbling about the dregs sitting at the bottom of the ipv4 allocation barrel.
However... our mission, if we choose to accept it, could be to waste time squabbling over these last dregs policy proposals until long after the IPv4 pool has gone. :-)
Hi, On Tue, May 17, 2016 at 02:01:17PM +0100, Nick Hilliard wrote:
I'd politely like to ask the chairs to do two things:
1. declare their opinion on whether 2015-05 reached consensus
Right now, we have no consensus to move forward. We're currently discussing with the proposers what to do next - extend the discussion phase (to formally include the RIPE72 AP WG meeting), or withdraw.
2. use the bunfight which is inevitably going to happen in Copenhagen to allow them to exercise more restraint about what sort of proposals hit the mailing list in future so that we don't spend years wasting time squabbling about the dregs sitting at the bottom of the ipv4 allocation barrel.
I'm hearing you, and we think this discussion is indeed necessary (to be held on wednesday about 09:30-10:30) to see whether there is general WG consensus to move towards a more liberal (2015-05-ish), strict (2016-03-ish), or "leave it as it is!" last /8 policy. And then, decide what to do with upcoming policy proposals. Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
ALLOCATED FINAL: This address space has been allocated to an LIR and no assignments made from it are portable. What does it mean "are portable"? 2016-05-17 16:38 GMT+03:00 Gert Doering <gert@space.net>:
Hi,
On Tue, May 17, 2016 at 02:01:17PM +0100, Nick Hilliard wrote:
I'd politely like to ask the chairs to do two things:
1. declare their opinion on whether 2015-05 reached consensus
Right now, we have no consensus to move forward. We're currently discussing with the proposers what to do next - extend the discussion phase (to formally include the RIPE72 AP WG meeting), or withdraw.
2. use the bunfight which is inevitably going to happen in Copenhagen to allow them to exercise more restraint about what sort of proposals hit the mailing list in future so that we don't spend years wasting time squabbling about the dregs sitting at the bottom of the ipv4 allocation barrel.
I'm hearing you, and we think this discussion is indeed necessary (to be held on wednesday about 09:30-10:30) to see whether there is general WG consensus to move towards a more liberal (2015-05-ish), strict (2016-03-ish), or "leave it as it is!" last /8 policy. And then, decide what to do with upcoming policy proposals.
Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
-- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29
Hi, I’m late to the party but I note that according to the RIPE NCC website, the good Mr. van Mook has not yet been kind enough to revoke the policy proposal yet, so allow me to say... On 17/05/2016, 14:01, "address-policy-wg on behalf of Nick Hilliard" <address-policy-wg-bounces@ripe.net on behalf of nick@foobar.org> wrote:
Specifically, it will not deal with the problem that the RIPE NCC was set up to do, namely to ensure accurate registration of resources.
.. that I agree with Nick's sentence, and object to the proposal. Whilst I understand the motive (and it’s a bloody good troll), I specifically object to a proposal which might ask or require an LIR to return in-use resources, which were previously correctly and in good faith, assigned in accordance with policy and procedures. Andy
On Tue, May 17, 2016 at 02:05:26PM +0200, Marco Schmidt wrote:
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party
I would like to see a statement from NCC Legal on the legality of any of these proposals with particular emphasis on EU "barrier to entry" legislation. rgds, Sascha Luck
Hello, I firmly oppose this policy proposal for the following reasons : * Interference with routing I always understood RIPE NCC must not consider routing issues as legitimate (when justificating address space requests was a thing), the counterpart could be implicit. De-agregating a /22 is legitimate in many cases, especially when it's your only available block. Restricting route objects or RPKI will lead to *weaken routing's security* and *reduce the registry's quality*. It would also make it impossible to mitigate BGP hijacking if a legitimate announce cannot counter a more specific illegitimate one. * Not concise enough The proposal actually means "Every /8 PA is now a PI". Such policy should be written in its simpliest form, which in this case is an 8 words sentence. * Not adressing the multi-LIR issue If such proposal AND the re-authorization of multiple LIR account per member both gets to pass, it would almost feel legitimate to create multiple LIRs in order to be allowed to secure our networks by de-agregating some critical prefixes off it. Encouraging the waste of address space seems incompatible with the community's best interests. * Unclear non-transferability There are two kinds of possible transfers : - The legitimate one is Mergure and Acquisition, which reflects real network and business events. - The crook's one is the listing service, used to get profits off privatizing the public domain. Only the second one should be banned, or mergure and acquisitions won't be properly reflected into the registry. * Unfairness to new entrants The issue regarding new entrants with legitimate needs for more than a /22 beeing unable to compete against incubents, who never had to justify their dispendious tendancies regarding ERXs and over /16 PAs, could be considered as unlawfull to some market authorities. Considering these 4 major points (and the pedantic one), I would hope for immediate dismissal of the proposal. Best regards, -- Jérôme Nicolle +33 6 19 31 27 14
Hi Jerome,
On 17 May 2016, at 16:26 , Jérôme Nicolle <jerome@ceriz.fr> wrote:
Hello,
I firmly oppose this policy proposal for the following reasons :
I will try to address your objections below:
* Interference with routing
I always understood RIPE NCC must not consider routing issues as legitimate (when justificating address space requests was a thing), the counterpart could be implicit.
De-agregating a /22 is legitimate in many cases, especially when it's your only available block. Restricting route objects or RPKI will lead to *weaken routing's security* and *reduce the registry's quality*.
It would also make it impossible to mitigate BGP hijacking if a legitimate announce cannot counter a more specific illegitimate one.
It does not interfere with routing. It specifically states 'up to a total of a /22 of IPv4 space'. It doesn't say it's supposed to be a single block. How you want to carve up that /22 is up to you.
* Not concise enough
The proposal actually means "Every /8 PA is now a PI". Such policy should be written in its simpliest form, which in this case is an 8 words sentence.
No, it doesn't mean "every /8 PA is now a PI". There are some broad similarities with the old PI policy. The concept of "PI" no longer exists in current IPv4 allocation policy except for transfers; an attempt to revive IPv4 PI failed.
* Not adressing the multi-LIR issue
If such proposal AND the re-authorization of multiple LIR account per member both gets to pass, it would almost feel legitimate to create multiple LIRs in order to be allowed to secure our networks by de-agregating some critical prefixes off it.
Encouraging the waste of address space seems incompatible with the community's best interests.
I don't see how this wastes address space any more than current policy. I also don't see how you'd need multiple LIRs to 'de-aggregate some critical prefixes'. On top of that, conservation went out the window with the acceptance of 2013-03.
* Unclear non-transferability
There are two kinds of possible transfers :
- The legitimate one is Mergure and Acquisition, which reflects real network and business events. - The crook's one is the listing service, used to get profits off privatizing the public domain.
Only the second one should be banned, or mergure and acquisitions won't be properly reflected into the registry.
I explicitly didn't want to express any opinions on what kind of transfers ought to be allowed. If regular transfers get banned, going through the M&A process - especially with empty shell companies - is trivial; which is why I'm proposing that it doesn't matter how you ended up with those extra blocks; you can't have more than 1. Right now, it doesn't matter how big or how small your organisation is, or how many address space you need, you get a /22. Once. However, the exception crept in that if you acquire or merge with other companies, this limitation does not currently apply. However practical, this exception needs to be contained if you want to effectively limit the marketability of these blocks.
* Unfairness to new entrants
The issue regarding new entrants with legitimate needs for more than a /22 beeing unable to compete against incubents, who never had to justify their dispendious tendancies regarding ERXs and over /16 PAs, could be considered as unlawfull to some market authorities.
Legitimate need or not, setting up new LIRs or shell companies to become LIRs in order to gain extra address space to me is pretty obvious exploitation of a loophole in policy. It's like tax avoidance - it's not illegal but did you really open up a business in Panama for legitimate reasons? If you think this is unfair, every bit of needs based allocation policy (RFC 2050 and onwards) in the last 20 years has been unfair, and the fact that it's now down to just /22s is more or less irrelevant. No market authorities I'm aware of have objected to allocation policy during the past 2 decades. It's actually the other way around. Right now, we're all aware of creative interpretation of the current IPv4 allocation policy. If we don't try to address this behaviour, it would be very easy to assume that the community is approving of it. And that is a stick that new entrants a couple of years from now will use against us. Kind regards, Remco
On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
What really amaze me. We are using tons of time here in ag-wg talking over IPv4 while there is not half that activity over in IPv6-wg. I take that as a statement that everyone know everything there is to know about IPv6, there are nothing more to discuss or learn, no questions to ask, we are all using it so very few people are left behind in IPv4 land... soon to be isolated island not able to talk with anyone. ... is that how it is? Why aren't all of you with HUGE and MAJOR problem (sorry for the caps) with lack of IPv4 address over in IPv6-wg bombing us with question on how to get out of your current trouble? Asking all kind of stupid and newbie questions? I'm very sure there are tons of people standing in line to help you out. https://www.ripe.net/participate/ripe/wg/ipv6 PS 1 : chairs - I object to this policy and the other one trying to sort a problem that can't be sorted in IPv4 land, only IPv6 can. PS 2 : Nick Hillard summarized it very well here: <start copy> Like the curate's egg, this proposal is good in parts. Here's the good part:
- Explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA <end copy>
-- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
On 17 May 2016, at 19:12, Roger Jørgensen <rogerj@gmail.com> wrote:
What really amaze me. We are using tons of time here in ag-wg talking over IPv4 while there is not half that activity over in IPv6-wg.
Indeed. It’s like the old joke about politics in academia: the bickering and in-fighting is so acrimonious because the stakes are so low. Mind you, IPv6 address allocation policy is such a no-brainer it doesn’t need much work. Perhaps we can keep discussions on IPv4 allocation policies going until after the heat death of the universe. :-)
5.1.4. All allocations will be marked in the RIPE database as ‘ALLOCATED FINAL’ Does it mean that all IPs from the 185./8 will be markead as ‘ALLOCATED FINAL’ or I am wrong? 2016-05-17 21:12 GMT+03:00 Roger Jørgensen <rogerj@gmail.com>:
On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
What really amaze me. We are using tons of time here in ag-wg talking over IPv4 while there is not half that activity over in IPv6-wg.
I take that as a statement that everyone know everything there is to know about IPv6, there are nothing more to discuss or learn, no questions to ask, we are all using it so very few people are left behind in IPv4 land... soon to be isolated island not able to talk with anyone.
... is that how it is?
Why aren't all of you with HUGE and MAJOR problem (sorry for the caps) with lack of IPv4 address over in IPv6-wg bombing us with question on how to get out of your current trouble? Asking all kind of stupid and newbie questions? I'm very sure there are tons of people standing in line to help you out.
https://www.ripe.net/participate/ripe/wg/ipv6
PS 1 : chairs - I object to this policy and the other one trying to sort a problem that can't be sorted in IPv4 land, only IPv6 can.
PS 2 : Nick Hillard summarized it very well here: <start copy> Like the curate's egg, this proposal is good in parts. Here's the good part:
- Explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA <end copy>
--
Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
-- ---------- Best regards, Aleksey Bulgakov Tel.: +7 (926)690-87-29
On Tue, May 17, 2016, at 20:12, Roger Jørgensen wrote:
Why aren't all of you with HUGE and MAJOR problem (sorry for the caps) with lack of IPv4 address over in IPv6-wg bombing us with question on how to get out of your current trouble?
Most probably because some of us did our part in IPv6 deployment to the extent we are allowed to do by our management, but the problem is elsewhere. In my precise case: - left $JOB[-3] in an "5 stars-ready" state 4 years ago (there was no 5th star at that time), and it's still 5 stars at this day. 4 "on-net" offices fully dual-staked. IPv6 on auto-pilot since about one year. - left $JOB[-1] with 5 stars. Auto-pilot until recently (when it almost crashed). - $JOB[0] (current) : pretty successful deployment for residential, pretty *UN*-successful on pro (some customers accept getting IPv6 by default, some don't, some others insert their v4-only equipment), almost complete failure on corporate ("no time to waste on this"). NOC is dual-stacked, rest of the company office staff (~90%) - no plans for the next 5-10 years. Still no change in the need for v4 address space. And don't tell me about CGN, address market is almost a better choice. So, what questions would you like me to bomb ipv6-wg with ?
Il 17/05/2016 20:12, Roger Jørgensen ha scritto:
On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion. What really amaze me. We are using tons of time here in ag-wg talking over IPv4 while there is not half that activity over in IPv6-wg.
I take that as a statement that everyone know everything there is to know about IPv6, there are nothing more to discuss or learn, no questions to ask, we are all using it so very few people are left behind in IPv4 land... soon to be isolated island not able to talk with anyone.
... is that how it is?
Why aren't all of you with HUGE and MAJOR problem (sorry for the caps) with lack of IPv4 address over in IPv6-wg bombing us with question on how to get out of your current trouble? Asking all kind of stupid and newbie questions? I'm very sure there are tons of people standing in line to help you out.
https://www.ripe.net/participate/ripe/wg/ipv6 Thank you for focusing all of us on it.
PS 1 : chairs - I object to this policy and the other one trying to sort a problem that can't be sorted in IPv4 land, only IPv6 can.
PS 2 : Nick Hillard summarized it very well here: <start copy> Like the curate's egg, this proposal is good in parts. Here's the good part:
- Explicitly state that the current IPv4 allocation policy applies to all available IPv4 address space held by the RIPE NCC that has not been reserved or marked to be returned to IANA <end copy>
-- Ing. Riccardo Gori e-mail: rgori@wirem.net Mobile: +39 339 8925947 Mobile: +34 602 009 437 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
The only provision in the list of 4 items below which I would support is the first one: "These allocation[s] are not transferable" In the case that these addresses are no longer used or needed, they have to be returned to "Last /8" Pool at the RIPE NCC. Number 2 - is a non-starter for me, because it is easily circumvented and difficult to check and to enforce. Number 3 - has already been commented on, as contradicting the model and mode of operation of an LIR. Number 4 - I don't get, neither what the intention is, nor the mechanism to manage that. Wilfried On 2016-05-17 14:05, Marco Schmidt wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-03
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 15 June 2016.
Regards
Marco Schmidt Policy Development Officer RIPE NCC
On Tue, May 17, 2016 at 2:05 PM, Marco Schmidt <mschmidt@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" is now available for discussion.
The goal of this proposal is to limit IPv4 from the remaining address pool to one /22 per LIR (regardless of how it was received). These “final /22” allocations will receive a separate status with several restrictions:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible - Reverse delegation authority can not delegated to another party
You can find the full proposal at:
https://www.ripe.net/participate/policies/proposals/2016-03 <snip>
Hi all, Based on the extended discussion on the other proposal on the table and that we are supposed to work together toward consensus I got a few questions to the community regarding this proposal. Since this proposal opened the door on introducing restriction on an IPv4 block I'll follow that up... 1.) what sort of restriction are we willing to put on address space? How and where, and in what direction can we think of restriction? On where it be used? On how it can be used, and what type of restriction? You have to publish IPv6 for any services/things using this address space? 2.) the second part of the question, please do not mix it up with the first one, how can restriction be implemented and enforced? Do we have to introduce "need based requests" again? RPKI? Withdraw? Just - if we're following the path of restriction, what tools do we have available? -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
On Sat, May 21, 2016 at 09:55:31AM +0200, Roger Jørgensen wrote:
1.) what sort of restriction are we willing to put on address space? How and where, and in what direction can we think of restriction? On where it be used? On how it can be used, and what type of restriction? You have to publish IPv6 for any services/things using this address space?
As long as there is space available on the IPv4 market, there is no need to change the "no more than one /22 per LIR" rule. Keep the remaining RIR pool for new entrants. Once the market is dry, we can relax the rule. Speaking of IPv6, I can't see what more we can do. We provide address without justification, we provide tools, documentation and training for free. Many of us, as a community, are ready to help people not confident to kickstart. When you ask why IPv6 is not deployed : - no need : then you'll pay your need for IPv4 at the market price - not enough information or support : if you need help, the community can help. - no support from transit provider or equipement vendor : unfortunately, it will be hard for RIPE to bring willing IPv6 provider in your area or pay for your gear if you can't afford the right provider.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear all, On 17/05/2016 14:05, Marco Schmidt wrote:
- These allocation are not transferrable - LIRs may only retain one final /22 following a merger or acquisition - Sub-allocations are not possible
These would be correct if applied to End Users, unfortunately your proposition is applying to LIRs. So as I understand it, 2016-03 results in making a LIR's dimension void, e.g. to assimilate a LIR to an End User. So I oppose this proposal. As I already explained some time ago, a fair "last /8" policy evolution should tend to apply abuse control on End Users and let LIRs make an independant job correctly : there is no point in having LIRs limited in distributing IP ressources to new born ops, and the new born ops shall not be forced to become LIRs to exists. Best regards, S. Vallerot - -- http://www.opdop.fr - mutualiser et interconnecter en coopérative Opdop - Société Coopérative d'Interêt Collectif sous forme de SARL sur IRC réseau geeknode #opdop - tél: 0950 31 54 74, 06 86 38 38 68 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAldZMRAACgkQJBGsD8mtnRFRxQD9GU7d+khzmyPkw2LD4cZGw8aK xCkq9A/WlrHPStVCmngA/206953O/oEOn91DEZ0l4+YO1Q5X5X8vhz4PO62XiIdJ =JQRL -----END PGP SIGNATURE-----
These would be correct if applied to End Users, unfortunately your proposition is applying to LIRs.
So as I understand it, 2016-03 results in making a LIR's dimension void, e.g. to assimilate a LIR to an End User.
So I oppose this proposal.
I fully agree with you but it seems some think that prefixes from last-/8 is not intended to be used and distributed as we used to. Which I can comprehend, because as LIR we need to understand and make our end-users understand there is no IPv4 available anymore. Is there an official statement on this point ? Can LIR from the last-/8 distribute addresses to customers or only use it on CGN ?
Hi, On Thu, Jun 09, 2016 at 11:43:09AM +0200, Denis Fondras wrote:
Is there an official statement on this point ? Can LIR from the last-/8 distribute addresses to customers or only use it on CGN ?
Policy is clear on that: you can use the addresses any way you want. *BUT*: do not come back later and ask for more if you used them carelessly - thus, it may be generally a good idea to use the last scraps of IPv4 to enable communication between your IPv6 customer base and those folks out there that still have no IPv6. So it's sort of implied that the intended usage is "for IPv6<->IPv4 gatewaying" (or to dual-stack your mail and DNS servers, etc. etc.), but policy doesn't formally say so. Gert Doering -- APWG chair -- have you enabled 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 (0)89/32356-444 USt-IdNr.: DE813185279
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 09/06/2016 11:43, Denis Fondras wrote:
I fully agree with you but it seems some think that prefixes from last-/8 is not intended to be used and distributed as we used to. Which I can comprehend,
I agree with this : remaining IPs are not intended to be used as we used to. But they are still meant to be distributed to end users, aren't they ? Best regards, Sylvain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAldezhgACgkQJBGsD8mtnRGuaAEAm9Z8unbCXbXSIpw+9pxG2ce9 lBFdNK+hp572a3zmuIQA/1ibyaANpmeapUtLCmRp6ioSTt8YW5TbdQvQohM+D7NR =+T7o -----END PGP SIGNATURE-----
On 13 June 2016 at 16:15, Sylvain Vallerot <sylvain.vallerot@opdop.net> wrote:
I agree with this : remaining IPs are not intended to be used as we used to.
But they are still meant to be distributed to end users, aren't they ?
RIPE-649 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Section 5.1 Allocations made by the RIPE NCC to LIRs ... 3. The LIR must confirm it will make assignment(s) from the allocation. ... It doesn't say who these assignments are to, they could be to the LIR itself for their own use (as it will be in the case of end-users who have become LIRs purely to obtain some "psuedo-PI" address space.) Aled
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Aled, dear all, On 13/06/2016 17:29, Aled Morris wrote:
On 13 June 2016 at 16:15, Sylvain Vallerot <sylvain.vallerot@opdop.net <mailto:sylvain.vallerot@opdop.net>> wrote:
I agree with this : remaining IPs are not intended to be used as we used to. But they are still meant to be distributed to end users, aren't they ?
RIPE-649 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Section 5.1 Allocations made by the RIPE NCC to LIRs 3. The LIR must confirm it will make assignment(s) from the allocation. ...
It doesn't say who these assignments are to, they could be to the LIR itself for their own use (as it will be in the case of end-users who have become LIRs purely to obtain some "psuedo-PI" address space.)
LIRs being (quite likely) End Users, this is fine. But we definitely cannot assume that all End Users are LIRs, nor make a policy take it for granted. Put in another words we cannot have a policy say that an End User needs to be a LIR to have a chance to get access to the ressource. Allowing future End Users to have a tiny bit of IPv4 to bootstrap means allowing *End Users*, not just those that are LIRs. Right ? I would appreciate a confirmation from the "sitting-ones" that my understanding of the spirit of the last /8 policy is correct on this point because I sometimes doubt it when reading things like proposal 2013-03. Best regards, Sylvain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlde1AMACgkQJBGsD8mtnRHH4gD/duowiNMLW8a1E1SRuYj3UgBK QczJw7sdCw4bGICrmvEA/AjXyqIkX0xBBxk91zTgbIbVvqsVlEaPBZ/F9bygbaki =ZT3L -----END PGP SIGNATURE-----
On Thu, Jun 9, 2016 at 11:04 AM, Sylvain Vallerot < sylvain.vallerot@opdop.net> wrote:
These would be correct if applied to End Users, unfortunately your proposition is applying to LIRs.
So as I understand it, 2016-03 results in making a LIR's dimension void, e.g. to assimilate a LIR to an End User.
Several (and I would say many) LIRs _are_ end users, and the distinction between LIR and end users is not, as far as I have understood past and current policy, not intended to be watertight. In other words, it's fine for a LIR to be an end user, and in principle, it seems sensible that policy acknowledges that, but avoids making unnecessary limitations that interfere with that.
So I oppose this proposal.
As I already explained some time ago, a fair "last /8" policy evolution should tend to apply abuse control on End Users and let LIRs make an independant job correctly : there is no point in having LIRs limited in distributing IP ressources to new born ops, and the new born ops shall not be forced to become LIRs to exists.
This has already happened. There has been a huge amount of new LIRs registered in order to acquire a share of the remaining pool. Your arguments do not seem to be arguments against 2016-03, but against current policy. If you want to change current policy, you should do as the authors of 2015-05 and 2016-03: gather support, make a proposal yourself. Please note that I'm not flagging any preference for or against the policy proposal. I think it's a bit too much like deck chair rearrangement, and my feelings for it are more "meh" than anything else, at least for now. :) -- Jan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, dear Jan, On 09/06/2016 17:23, Jan Ingvoldstad wrote:
In other words, it's fine for a LIR to be an end user, and in principle, it seems sensible that policy acknowledges that, but avoids making unnecessary limitations that interfere with that.
I agree that a lot of LIRs are End Users. But the important point is that most End Users, however, are *not* LIRs which really means we cannot take the ones for the others. So, if the meaning of "last /8" policy is to let End Users have a minimal vital access to the ressource, then we must really write "End User" when we think "End User". Which leads to a very different wording (and meaning) of the policy that is to be obeyed by a LIR. Best regards, Sylvain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAldez/kACgkQJBGsD8mtnREZFgD+INALGOduxHzQ+4hX51fLXey8 3Ys5t8DDJNe448pWbK8A/i+Sfudir5dprT0LXKQSONFN9KYgond3sKSWW8Ki06pF =gta2 -----END PGP SIGNATURE-----
participants (24)
-
"Tomasz Śląski @ KEBAB"
-
Aled Morris
-
Aleksey Bulgakov
-
Andy Davidson
-
Bogdan-Stefan Rotariu
-
boggits
-
Denis Fondras
-
Dominik Nowacki
-
Elvis Daniel Velea
-
Gert Doering
-
Jan Ingvoldstad
-
Jim Reid
-
Jérôme Nicolle
-
Marco Schmidt
-
Nick Hilliard
-
Radu-Adrian FEURDEAN
-
Remco van Mook
-
Riccardo Gori
-
Roger Jørgensen
-
Sascha Luck [ml]
-
Staff
-
Sylvain Vallerot
-
Tore Anderson
-
Wilfried Woeber