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

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

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

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

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

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

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

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

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

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 ?

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.

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 ?

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

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

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