Re: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Dear all, I support the general direction of this proposal. If it included v4, I would still be in favor. That being said, I am not sure about the prefix sizes listed in this proposal. According to section 5.1.2 of the new text, everyone will receive at least a /32 unless the addresses will be used for a special purpose as per section 6. In this case, allocations can be made in allocations of /48: * Operating a TLD: 1-4 * /48 * Operating an ENUM: 1-4 * /48 * Operating an IXP: 1 * /48 * Operating a DNS root server: 1 * /32 There are three concerns with this: 1) Assuming everyone will get at least a /32, why limit core internet infrastructure, i.e. TLDs, ENUMs, and IXPs to a mere /48? The combined amount of those allocations will be dwarfed by the combined amount of LIRs and End Users. 2) While there are a _lot_ of addresses with IPv6, handing a multi-homed End User who will be able to operate on a single /48 for the foreseeable future a whole /32 appears to be wasteful. Maybe that's v4 speaking through me, but still... 3) Becoming a LIR costs several thousand Euros up front and then per year. Not being a LIR and simply getting the same /32 will, under current pricing schemes, cost €50. Becoming a LIR would become an extremely stupid business move over night. This means the existing LIRs will be stuck with paying whatever price increases happen over the years. That, in turn, means LIRs will start trying to redistribute the cost. And _that_ will become ugly very quickly. I am not saying my suggested answers are perfect, but my gut feeling tells me that while the distinction between "this is PA, hand it to your customers" and "this is PI, don't you dare using it for anyone but yourself" does not make sense, there should still be a distinction between "we need a few v6 addresses" and "we need a lot v6 addresses". Two possible approaches: * Non-LIR allocations could be limited to a single aggregated equivalent of, e.g. a /40 or /41. If someone needed more, let them become a LIR. * Do away with the flat fee of €50 per Independent Number Resource and charge based on size. This would also somewhat prevent people from grabbing as much IP space as possible. As an aside, reading [1] is needlessly hard. There are several sections where text on the left-hand side does not appear on the right-hand side. New text on the right-hand side is marked in blue; disappearing text on the left-hand side is not marked in any way. This is yet another reminder of why migrating to plain text with an automated storage and diffing back-end ASAP will be a Good Thing. Richard [1] https://www.ripe.net/ripe/docs/other-documents/draft-ipv6-address-allocation...
Hi Richard, On 9/26/13 11:44 PM, Richard Hartmann wrote:
Dear all,
I support the general direction of this proposal. If it included v4, I would still be in favor.
I didn't even dare touching v4 right now even though I agree that this policy proposal is a good exercise for what should happen in the near future with v4 as well.
That being said, I am not sure about the prefix sizes listed in this proposal. According to section 5.1.2 of the new text, everyone will receive at least a /32 unless the addresses will be used for a special purpose as per section 6. In this case, allocations can be made in allocations of /48:
* Operating a TLD: 1-4 * /48 * Operating an ENUM: 1-4 * /48 * Operating an IXP: 1 * /48 * Operating a DNS root server: 1 * /32
There are three concerns with this:
1) Assuming everyone will get at least a /32, why limit core internet infrastructure, i.e. TLDs, ENUMs, and IXPs to a mere /48? The combined amount of those allocations will be dwarfed by the combined amount of LIRs and End Users.
These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits.
2) While there are a _lot_ of addresses with IPv6, handing a multi-homed End User who will be able to operate on a single /48 for the foreseeable future a whole /32 appears to be wasteful. Maybe that's v4 speaking through me, but still...
Well, someone that does not plan to make any sub-allocations or anyone that still thinks that a /48 will be large enough for the foreseeable future can request a /48. A /32 is provided by default though, so I would not see many organisations specifically requesting a /48 and not the default /32. see 5.1.2: "5.1.2 Initial Allocation Size [...] /48 allocations can be made by the RIPE NCC to End Users that do not expect to ever need more or for special purposes. Special purposes are covered in section 6 of this policy. When an organisation requests a /48 allocation, it must specifically mention in its request that it does not plan to use anything larger in the foreseeable future."
3) Becoming a LIR costs several thousand Euros up front and then per year. Not being a LIR and simply getting the same /32 will, under current pricing schemes, cost €50. Becoming a LIR would become an extremely stupid business move over night. This means the existing LIRs will be stuck with paying whatever price increases happen over the years. That, in turn, means LIRs will start trying to redistribute the cost. And _that_ will become ugly very quickly.
That was our main concern, so.. I already approached a few of the Board Members to discuss this policy proposal and at least announce them that this is coming. My idea was that while the AP-WG can not do anything about the fees (these are decided by AGM) we (the proposers) can discuss during the AGM our following idea: - if the policy proposal gets good feedback from the community, it would be a great exercise to ask the RIPE NCC (Board) to calculate how much would a /32 cost if the prices would be leveled.. - if the price can not be leveled yet, see how much would the membership fee decrease if the non-LIRs would pay double the current price (100€) or 500% more (250€), or something around that price.
I am not saying my suggested answers are perfect, but my gut feeling tells me that while the distinction between "this is PA, hand it to your customers" and "this is PI, don't you dare using it for anyone but yourself" does not make sense, there should still be a distinction between "we need a few v6 addresses" and "we need a lot v6 addresses".
I agree, and that is why someone can request a '/48' or a '/32 or larger'
Two possible approaches:
* Non-LIR allocations could be limited to a single aggregated equivalent of, e.g. a /40 or /41. If someone needed more, let them become a LIR.
I had this idea initially. But, then how do we determine how large should this allocation be? By taking an arbitrary number? What if this number is not longer the right number in 2 years?
* Do away with the flat fee of €50 per Independent Number Resource and charge based on size. This would also somewhat prevent people from grabbing as much IP space as possible.
I think this is where we should be looking at. Try to get the 'price per /32' to be equal (or almost equal) to both members and non-members. You get a block, you pay the same price for it whether you are a member or not. Maybe not immediately, maybe not in the next 2-3 years.. but this should be the goal for the future. However, I remember that 'charging per prefix size' discussion did appear in some of the previous policy proposals and if I remember correctly we were told that if the RIPE NCC were to charge based on prefix size, it may lose it's not-for-profit status that it has with the Dutch authorities. We need to be careful so that we do not affect RIPE NCC's status and activity.
As an aside, reading [1] is needlessly hard. There are several sections where text on the left-hand side does not appear on the right-hand side. New text on the right-hand side is marked in blue; disappearing text on the left-hand side is not marked in any way. This is yet another reminder of why migrating to plain text with an automated storage and diffing back-end ASAP will be a Good Thing.
I agree, but let's keep this discussion in the ncc-services-wg, please.
Richard
[1] https://www.ripe.net/ripe/docs/other-documents/draft-ipv6-address-allocation...
cheers, Elvis
On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits.
If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive.
Well, someone that does not plan to make any sub-allocations or anyone that still thinks that a /48 will be large enough for the foreseeable future can request a /48. A /32 is provided by default though, so I would not see many organisations specifically requesting a /48 and not the default /32.
see 5.1.2:
"5.1.2 Initial Allocation Size [...] /48 allocations can be made by the RIPE NCC to End Users that do not expect to ever need more or for special purposes. Special purposes are covered in section 6 of this policy. When an organisation requests a /48 allocation, it must specifically mention in its request that it does not plan to use anything larger in the foreseeable future."
True; I missed the crucial part of allowing "/48 allocations [...] not expect to ever need more". Sorry, it seems my comb hasn't been fine-toothed enough... Aside from the difference between "ever need more" and "foreseeable future", this means that End Users will need to decide between /48 and /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. As they need more than one single /48, under that policy the seem to be _forced_ to a /32. With a corporate hat on, I think it highly unlikely that anyone manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32.
That was our main concern, so.. I already approached a few of the Board Members to discuss this policy proposal and at least announce them that this is coming.
My idea was that while the AP-WG can not do anything about the fees (these are decided by AGM) we (the proposers) can discuss during the AGM our following idea:
- if the policy proposal gets good feedback from the community, it would be a great exercise to ask the RIPE NCC (Board) to calculate how much would a /32 cost if the prices would be leveled..
- if the price can not be leveled yet, see how much would the membership fee decrease if the non-LIRs would pay double the current price (100€) or 500% more (250€), or something around that price.
That's great to hear.
I had this idea initially. But, then how do we determine how large should this allocation be? By taking an arbitrary number? What if this number is not longer the right number in 2 years?
Then we change policy to adapt ;) But I see your point and I was not really happy when coming up with /40 or /41.
I think this is where we should be looking at. Try to get the 'price per /32' to be equal (or almost equal) to both members and non-members. You get a block, you pay the same price for it whether you are a member or not. Maybe not immediately, maybe not in the next 2-3 years.. but this should be the goal for the future.
If it's not done after one year at the latest, I fear that would breed dissent.
However, I remember that 'charging per prefix size' discussion did appear in some of the previous policy proposals and if I remember correctly we were told that if the RIPE NCC were to charge based on prefix size, it may lose it's not-for-profit status that it has with the Dutch authorities. We need to be careful so that we do not affect RIPE NCC's status and activity.
Good point; that makes arbitrary cut-off points (/40) appear more appealing, again.
I agree, but let's keep this discussion in the ncc-services-wg, please.
AFAIU, the general point of "this proposal is needlessly hard to read" does belong on this list. I am willing to bet that easier consumption will translate directly into more feedback. You are right that the rest of this discussion does not belong here, though. Richard
On Fri, Sep 27, 2013 at 1:45 AM, Richard Hartmann < richih.mailinglist@gmail.com> wrote:
On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits.
If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive.
I concur. And I think it's worth keeping in mind that even a /48 is a ludicrously enormously large address space. With a corporate hat on, I think it highly unlikely that anyone
manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32.
So do I, especially considering the turn of phrase, which is nearly guaranteed to instill a fear of running out somehow. Nobody should run out with a /48. I think it's somewhat sensible that a LIR should have access to a /32. :) -- Jan
Hi Jan, On 9/27/13 9:01 AM, Jan Ingvoldstad wrote:
On Fri, Sep 27, 2013 at 1:45 AM, Richard Hartmann [...]
If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive.
I concur.
noted.
And I think it's worth keeping in mind that even a /48 is a ludicrously enormously large address space.
Actually, it's not such an enormous large amount, taking into consideration that 64 bits are out of scope. You are left with 16 bits (65K networks/end sites). And let's not forget that the recommendation is to give a customer at least a /56.
With a corporate hat on, I think it highly unlikely that anyone manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32.
So do I, especially considering the turn of phrase, which is nearly guaranteed to instill a fear of running out somehow.
Nobody should run out with a /48.
I am not sure what to understand from the statement above. It is up to the company managing the address space to make sure that they have a contract in place to keep it's sub-allocated space under control.
I think it's somewhat sensible that a LIR should have access to a /32. :)
And the current policy allows even up to a /29 with no questions asked :-) cheers, elvis
These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits.
If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive.
I agree. We should propose /48 as the _minimum_ allocation for all special purposes, maybe with possible provisions for more.
Aside from the difference between "ever need more" and "foreseeable future", this means that End Users will need to decide between /48 and /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. As they need more than one single /48, under that policy the seem to be _forced_ to a /32.
With a corporate hat on, I think it highly unlikely that anyone manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32.
I agree that the either /48 with no room for expansion or /32 is too strict. I would go as far as to propose that End Users could request anything from /48 to /32 and also be limited to that. However, this may have implications on address reservations in RIPE, as was the case with LIRs being allocated a /32 but reserved a /29. So if to avoid renumbering and to encourage aggregation we end up allocating /48s, but reserving a /32 for each one, we probably will end up at the same point again. Furthermore, as the "LIR incentive", I'd restrict End User allocations to a /32. If you need more, you should become an LIR. ____________________________________ Tero Toikkanen Nebula Oy
Hi Tero, On 9/27/13 11:55 AM, Tero Toikkanen wrote:
These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits.
If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive.
I agree. We should propose /48 as the _minimum_ allocation for all special purposes, maybe with possible provisions for more.
currently the policy states that the minimum allocation is a /32 and LIRs can request up to a /29 with no questions asked, this policy proposal does not intend to change that minimum.
Aside from the difference between "ever need more" and "foreseeable future", this means that End Users will need to decide between /48 and /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. As they need more than one single /48, under that policy the seem to be _forced_ to a /32.
With a corporate hat on, I think it highly unlikely that anyone manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32.
I agree that the either /48 with no room for expansion or /32 is too strict. I would go as far as to propose that End Users could request anything from /48 to /32 and also be limited to that. However, this may have implications on address reservations in RIPE, as was the case with LIRs being allocated a /32 but reserved a /29. So if to avoid renumbering and to encourage aggregation we end up allocating /48s, but reserving a /32 for each one, we probably will end up at the same point again.
If someone is sure that they will not need more than a /48, ever, then they can request that /48. If they have any plans to make sub-allocations, then they can receive the /32 and use it for the rest of their life. Creating different levels/limits will complicate the policy again and our aim was to make it as simple as possible. - small allocations - /48 - large allocations - /32 or more
Furthermore, as the "LIR incentive", I'd restrict End User allocations to a /32. If you need more, you should become an LIR.
I don't think adding this limitation will work. If someone does not want to become an LIR, they will simply setup a new company (it costs 50€ in most of Europe) and get an other /32 on that company's name. So, I don't think that limiting the size of the allocation the End User/Sub-LIR can receive is a good idea. cheers, elvis
Hi Richard, On 9/27/13 1:45 AM, Richard Hartmann wrote:
On Fri, Sep 27, 2013 at 12:24 AM, Elvis Daniel Velea <elvis@v4escrow.net> wrote:
These were restrictions that existed in the previous version and things seemed to work well with these restrictions/sizes. I hear you and if others think the same, we could change the limits.
If /32 becomes the new default/minimum, keeping those limits seems to be counter-intuitive.
correct, let's see what the others think as well.
Well, someone that does not plan to make any sub-allocations or anyone that still thinks that a /48 will be large enough for the foreseeable future can request a /48. A /32 is provided by default though, so I would not see many organisations specifically requesting a /48 and not the default /32.
see 5.1.2:
"5.1.2 Initial Allocation Size [...] /48 allocations can be made by the RIPE NCC to End Users that do not expect to ever need more or for special purposes. Special purposes are covered in section 6 of this policy. When an organisation requests a /48 allocation, it must specifically mention in its request that it does not plan to use anything larger in the foreseeable future."
True; I missed the crucial part of allowing "/48 allocations [...] not expect to ever need more". Sorry, it seems my comb hasn't been fine-toothed enough...
Aside from the difference between "ever need more" and "foreseeable future", this means that End Users will need to decide between /48 and /32. To pick a specific example, FOSDEM will apply for IPv6 PI soon. As they need more than one single /48, under that policy the seem to be _forced_ to a /32.
Well, it's a /48 if you are sure you will never need more; otherwise, you can get the /32, as everyone else.
With a corporate hat on, I think it highly unlikely that anyone manager or sales person will be content with less than the absolute maximum they can get even if they don't need it. So save for a few corporations and maybe temporary allocations, I suspect everyone will go for a /32.
I suspect the same, I did not want to introduce arbitrary limits between /48 and /32. I think these two limits are enough and adding an other one would complicate the policy.
That was our main concern, so.. I already approached a few of the Board Members to discuss this policy proposal and at least announce them that this is coming.
My idea was that while the AP-WG can not do anything about the fees (these are decided by AGM) we (the proposers) can discuss during the AGM our following idea:
- if the policy proposal gets good feedback from the community, it would be a great exercise to ask the RIPE NCC (Board) to calculate how much would a /32 cost if the prices would be leveled..
- if the price can not be leveled yet, see how much would the membership fee decrease if the non-LIRs would pay double the current price (100€) or 500% more (250€), or something around that price.
That's great to hear.
I had this idea initially. But, then how do we determine how large should this allocation be? By taking an arbitrary number? What if this number is not longer the right number in 2 years?
Then we change policy to adapt ;)
The idea of this policy proposal is that we would like to fix it and not need to change it every year or two.
But I see your point and I was not really happy when coming up with /40 or /41.
Exactly, in the discussions with the other proposers I had also the /40 in mind. But this number is so arbitrary that it will help some and not help others. Let's not put arbitrary numbers in policies. If you need IPv6, you can get as much as you want (even if you are not an LIR). But then, the price for (each) allocation will need to be close to the price an LIR pays for the same IPv6 allocation.
I think this is where we should be looking at. Try to get the 'price per /32' to be equal (or almost equal) to both members and non-members. You get a block, you pay the same price for it whether you are a member or not. Maybe not immediately, maybe not in the next 2-3 years.. but this should be the goal for the future.
If it's not done after one year at the latest, I fear that would breed dissent.
I think that we have two options: 1. ask the board/NCC to calculate what would be the price per allocation if there would be no difference between LIRs and non-LIRs 2. start with a step-by-step approach - as we do not have that many non-LIRs using IPv6 now, I think that the increase from 50 to (arbitrary number from my mind) 500 Euro would be pretty high. The idea would be to come up with a plan that in 3-5 years the price for a /32 to be the same for members and non-members
However, I remember that 'charging per prefix size' discussion did appear in some of the previous policy proposals and if I remember correctly we were told that if the RIPE NCC were to charge based on prefix size, it may lose it's not-for-profit status that it has with the Dutch authorities. We need to be careful so that we do not affect RIPE NCC's status and activity.
Good point; that makes arbitrary cut-off points (/40) appear more appealing, again.
let's see what the NCC and the Board will say about this in the Impact Analysis.
I agree, but let's keep this discussion in the ncc-services-wg, please.
AFAIU, the general point of "this proposal is needlessly hard to read" does belong on this list. I am willing to bet that easier consumption will translate directly into more feedback.
Correct, the page could have been formatted better. I would not change it now, as we have already started the discussion. I will talk to the NCC if there is a version 2 and the page will clearly show the differences between the current policy and proposed changes.
You are right that the rest of this discussion does not belong here, though.
Richard
cheers, elvis
participants (5)
-
Elvis Daniel Velea -
Elvis Velea -
Jan Ingvoldstad -
Richard Hartmann -
Tero Toikkanen