Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion. Remco Sent from my HTC ----- Reply message ----- From: "Radu-Adrian FEURDEAN" <ripe-wgs@radu-adrian.feurdean.net> To: "Randy Bush" <randy@psg.com>, "Marco Schmidt" <mschmidt@ripe.net> Cc: "RIPE address policy WG" <address-policy-wg@ripe.net> Subject: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision) Date: Sat, Apr 16, 2016 11:53 On Thu, Apr 14, 2016, at 19:24, Randy Bush wrote:
the purpose of the single last /8 allocation was to allow NEW ENTRY.
The *single* "last /8" (185.0.0.0/8) is still reserved to what most people consider new entry. Further allocations would be from recovered space, which can also serve "new entry". Did you actually read the new text ?
pigs coming back to the trough every 18 months is not new anything.
No, it's not. It'a actually commonplace in the other RIRs. -- Radu-Adrian FEURDEAN fr.ccs
Hi Hans, good morning list, I think there is no confusion. section 5.3 https://www.ripe.net/publications/docs/ripe-649 [...] 5.3 Address Recycling Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. [...] What is you understanding of "not be returned to the IANA but re-issued by the RIPE NCC itself" ? In my understanding this does not talks about any space RECEIVED from IANA's Recovered IPv4 Pool Recovered space reiceved from IANA comes from a global policy ratified by RIRs in September 2012 Maybe Andrea Cima can clarify RIPE NCC understanding about this, Andrea could you please give us RIPE NCC understading? On the other hand it's easy to say that all the available pool can fall under the same policy in section 5.1. but it's clear that when last /8 was thought was to allow new entrants as well as existing LIRs develop IPv6 and keep fairness on the market. Sorry for repeating myself but please note that policy 2014-04 (https://www.ripe.net/participate/policies/proposals/2014-04) removed IPv6 requirement to obtain last /22 IPv4 allocation. We have no IPv6 incentives but t-shirts! Gert, Sander (Chairs): may I ask you to give me/us your opinion about absence of IPv6 incetives in our policies don't you think we are missing something? regards Riccardo Il 20/04/2016 01:17, Hans Petter Holen ha scritto:
On 16.04.2016 12.29, remco.vanmook@gmail.com wrote:
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion.
I looked up the policy proposal at https://www.ripe.net/participate/policies/proposals/2010-02
" This proposal describes how the RIPE NCC should distribute IPv4 address space from the final /8 address block it receives from the IANA."
Reading the rest of the proposal I fully understand the confusion and find it hard to read your interpretation into the proposal.
The updated policy after this proposal can be found in RIPE 509 https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-al... * The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA.
It does not discuss the event where RIPE NCC gets more address space and could allocate from - which would strictly speaking not be allocation from the last /8
Tracing the policy text trough the versions - This text was first removed between * RIPE 599 published on 20 December 2013 https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocationsa... * RIPE 604 - published on 4 Feb 2014: https://www.ripe.net/publications/docs/ripe-604
Where the text was changed to:
1. The size of the allocation made will be exactly one /22. 2. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
and no reference to the last /8.
So I can easily understand the confusion.
-- Hans Petter Holen Mobile +47 45 06 60 54 |hph@oslo.net |http://hph.oslo.net
-- 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) --------------------------------------------------------------------
On 20/04/16 08:37, Riccardo Gori wrote:
I think there is no confusion. section 5.3 https://www.ripe.net/publications/docs/ripe-649
Yes - I agree that there should be no confusion on the current policy text. I commented on Remcos statement: On 16.04.2016 12.29, remco.vanmook@gmail.com wrote:
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion. And as far as I has been able to establish it was not that clear - to me - from the text in the original proposal. So while it is clear today - it was not clear to me that it was "from day one" - as Remco stated.
As far as I can see the language you refer to was introduced in RIPE 530 on 21 Oct 2011. https://www.ripe.net/publications/docs/ripe-530 The reason I point out this is that we should not use the past as an argument for the future - but have an open discussion on whats best for the future. And if we refer to the past it should
[...] 5.3 Address Recycling Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. [...]
What is you understanding of "not be returned to the IANA but re-issued by the RIPE NCC itself" ?
Address space recovered by the RIPE NCC and not returned to IANA. The other two categories is address space from IANA and the last /8. My understanding is that the current practice under curent policy is to threat all 3 categories the same. From RIPE 530 on 21 Oct 21 going forward. Hans Petter
On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen <hph@oslo.net> wrote:
On 16.04.2016 12.29, remco.vanmook@gmail.com wrote:
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion.
It was a name for the point in time when it would be activated, and it would stay there until there was no IPv4 left to hand out.
I looked up the policy proposal at https://www.ripe.net/participate/policies/proposals/2010-02
" This proposal describes how the RIPE NCC should distribute IPv4 address space from the final /8 address block it receives from the IANA."
Not the best wording back there it seems...
Reading the rest of the proposal I fully understand the confusion and find it hard to read your interpretation into the proposal.
The updated policy after this proposal can be found in RIPE 509 https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-al... * The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA.
It does not discuss the event where RIPE NCC gets more address space and could allocate from - which would strictly speaking not be allocation from the last /8
somewhere along the way, I think, but haven't found it yet, it was said that this policy would get activated when they got the last /8 from IANA, that was the intention. Whatever happend after _that_ point in time, would be covered by that policy. That part was to cover what you mention next...
Tracing the policy text trough the versions - This text was first removed between * RIPE 599 published on 20 December 2013 https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations and * RIPE 604 - published on 4 Feb 2014: https://www.ripe.net/publications/docs/ripe-604
Where the text was changed to:
The size of the allocation made will be exactly one /22. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof).
The side story behind this is probably related to that it was assumed that IANA would get some address space back, address space they again could redistribute to the LIR. When slized up it would at some point not be possible to hand out /22's, only smaller blocks that could add upto a /22. All that would be addresses covered by "the last /8 policy", the runout policy.
and no reference to the last /8.
So I can easily understand the confusion.
The intention was that once the policy was activated it would be there for all future until there was no IPv4 left. It was just called "the last /8 policy" since that's how it started out, the activation point. (I can't find referenced to all of this but it is somewhere in the archives, and guess Geert or you can find it all? Wonder if it might be somewhere in the IETF space or so this was discussed to?) -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Hi Roger, Il 20/04/2016 11:00, Roger Jørgensen ha scritto:
On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen <hph@oslo.net> wrote:
On 16.04.2016 12.29, remco.vanmook@gmail.com wrote:
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion. It was a name for the point in time when it would be activated, and it would stay there until there was no IPv4 left to hand out.
I looked up the policy proposal at https://www.ripe.net/participate/policies/proposals/2010-02
" This proposal describes how the RIPE NCC should distribute IPv4 address space from the final /8 address block it receives from the IANA." Not the best wording back there it seems...
Reading the rest of the proposal I fully understand the confusion and find it hard to read your interpretation into the proposal.
The updated policy after this proposal can be found in RIPE 509 https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-al... * The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA.
It does not discuss the event where RIPE NCC gets more address space and could allocate from - which would strictly speaking not be allocation from the last /8 somewhere along the way, I think, but haven't found it yet, it was said that this policy would get activated when they got the last /8 from IANA, that was the intention. Whatever happend after _that_ point in time, would be covered by that policy. That part was to cover what you mention next...
Are you sure? I mean, when 185/8 has been reiceved from IANA: There was some space around left on the free pool and it has been allocated under the same "last /8 policy" from that moment or followed its own old path? I am serius since I wasn't here at that time and I don't really know what happened. Andrea, can you help me understand what happened to available pool is any when 185/8 was reiceved by IANA? please understand I signed up 01/2015, when exacly took place the first allocation made under "last /8" policy? any help would be appreciated thanks Riccardo
Tracing the policy text trough the versions - This text was first removed between * RIPE 599 published on 20 December 2013 https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations and * RIPE 604 - published on 4 Feb 2014: https://www.ripe.net/publications/docs/ripe-604
Where the text was changed to:
The size of the allocation made will be exactly one /22. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). The side story behind this is probably related to that it was assumed that IANA would get some address space back, address space they again could redistribute to the LIR. When slized up it would at some point not be possible to hand out /22's, only smaller blocks that could add upto a /22. All that would be addresses covered by "the last /8 policy", the runout policy.
and no reference to the last /8.
So I can easily understand the confusion. The intention was that once the policy was activated it would be there for all future until there was no IPv4 left. It was just called "the last /8 policy" since that's how it started out, the activation point.
(I can't find referenced to all of this but it is somewhere in the archives, and guess Geert or you can find it all? Wonder if it might be somewhere in the IETF space or so this was discussed to?)
-- 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) --------------------------------------------------------------------
Dear Riccardo, (I am responding on behalf of Andrea, who is currently traveling). We just wanted to confirm that Hans Petter and Roger are correct. The policy text you quoted was designed to allow address space to be returned to IANA. It does not refer to the way that the RIPE NCC should allocate from our available IPv4 pool. With the current policy, the RIPE NCC does not distinguish between address space in our available IPv4 pool on the basis of where it came from. We are currently allocating from 185/8 mainly for simplicity, and to allow a long quarantine period for returned address space. The RIPE NCC started to allocate from 185/8 on 14 September 2012, when we could no longer satisfy a request for address space without touching 185/8. That moment triggered section 5.1 that states that RIPE NCC members can request a one time /22 allocation (1,024 IPv4 addresses). I hope this helps. Best regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC On 20/04/2016 11:53, Riccardo Gori wrote:
Hi Roger,
Il 20/04/2016 11:00, Roger Jørgensen ha scritto:
On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen<hph@oslo.net> wrote:
On 16.04.2016 12.29,remco.vanmook@gmail.com wrote:
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion. It was a name for the point in time when it would be activated, and it would stay there until there was no IPv4 left to hand out.
I looked up the policy proposal at https://www.ripe.net/participate/policies/proposals/2010-02
" This proposal describes how the RIPE NCC should distribute IPv4 address space from the final /8 address block it receives from the IANA." Not the best wording back there it seems...
Reading the rest of the proposal I fully understand the confusion and find it hard to read your interpretation into the proposal.
The updated policy after this proposal can be found in RIPE 509 https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-al... * The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA.
It does not discuss the event where RIPE NCC gets more address space and could allocate from - which would strictly speaking not be allocation from the last /8 somewhere along the way, I think, but haven't found it yet, it was said that this policy would get activated when they got the last /8 from IANA, that was the intention. Whatever happend after _that_ point in time, would be covered by that policy. That part was to cover what you mention next...
Are you sure? I mean, when 185/8 has been reiceved from IANA: There was some space around left on the free pool and it has been allocated under the same "last /8 policy" from that moment or followed its own old path? I am serius since I wasn't here at that time and I don't really know what happened. Andrea, can you help me understand what happened to available pool is any when 185/8 was reiceved by IANA? please understand I signed up 01/2015, when exacly took place the first allocation made under "last /8" policy? any help would be appreciated thanks Riccardo
Tracing the policy text trough the versions - This text was first removed between * RIPE 599 published on 20 December 2013 https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations and * RIPE 604 - published on 4 Feb 2014: https://www.ripe.net/publications/docs/ripe-604
Where the text was changed to:
The size of the allocation made will be exactly one /22. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). The side story behind this is probably related to that it was assumed that IANA would get some address space back, address space they again could redistribute to the LIR. When slized up it would at some point not be possible to hand out /22's, only smaller blocks that could add upto a /22. All that would be addresses covered by "the last /8 policy", the runout policy.
and no reference to the last /8.
So I can easily understand the confusion. The intention was that once the policy was activated it would be there for all future until there was no IPv4 left. It was just called "the last /8 policy" since that's how it started out, the activation point.
(I can't find referenced to all of this but it is somewhere in the archives, and guess Geert or you can find it all? Wonder if it might be somewhere in the IETF space or so this was discussed to?)
-- 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 toinfo@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
Dear Ingrid, thank you for you help Il 20/04/2016 12:09, Ingrid Wijte ha scritto:
Dear Riccardo,
(I am responding on behalf of Andrea, who is currently traveling).
We just wanted to confirm that Hans Petter and Roger are correct. The policy text you quoted was designed to allow address space to be returned to IANA. It does not refer to the way that the RIPE NCC should allocate from our available IPv4 pool.
With the current policy, the RIPE NCC does not distinguish between address space in our available IPv4 pool on the basis of where it came from. We are currently allocating from 185/8 mainly for simplicity, and to allow a long quarantine period for returned address space. The RIPE NCC started to allocate from 185/8 on 14 September 2012, when we could no longer satisfy a request for address space without touching 185/8. That moment triggered section 5.1 that states that RIPE NCC members can request a one time /22 allocation (1,024 IPv4 addresses). Thank you, I'll try to understand as best as possibile how it worked/works but I am quite new so I don't know very well history things. I hope this helps.
thank you for your help Riccardo
Best regards,
Ingrid Wijte Assistant Manager Registration Services RIPE NCC
On 20/04/2016 11:53, Riccardo Gori wrote:
Hi Roger,
Il 20/04/2016 11:00, Roger Jørgensen ha scritto:
On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen<hph@oslo.net> wrote:
On 16.04.2016 12.29,remco.vanmook@gmail.com wrote:
This confusion has been haunting the final /8 policy from day one - it was never about what to do with specifically 185/8, but what to do with all future allocations from the moment we needed to start allocating out of it. The policy text itself was never limited to a single /8, nor was that limitation any part of the discussion. It was a name for the point in time when it would be activated, and it would stay there until there was no IPv4 left to hand out.
I looked up the policy proposal at https://www.ripe.net/participate/policies/proposals/2010-02
" This proposal describes how the RIPE NCC should distribute IPv4 address space from the final /8 address block it receives from the IANA." Not the best wording back there it seems...
Reading the rest of the proposal I fully understand the confusion and find it hard to read your interpretation into the proposal.
The updated policy after this proposal can be found in RIPE 509 https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-al... * The following policies come into effect as soon as RIPE NCC is required to make allocations from the final /8 it receives from the IANA.
It does not discuss the event where RIPE NCC gets more address space and could allocate from - which would strictly speaking not be allocation from the last /8 somewhere along the way, I think, but haven't found it yet, it was said that this policy would get activated when they got the last /8 from IANA, that was the intention. Whatever happend after _that_ point in time, would be covered by that policy. That part was to cover what you mention next...
Are you sure? I mean, when 185/8 has been reiceved from IANA: There was some space around left on the free pool and it has been allocated under the same "last /8 policy" from that moment or followed its own old path? I am serius since I wasn't here at that time and I don't really know what happened. Andrea, can you help me understand what happened to available pool is any when 185/8 was reiceved by IANA? please understand I signed up 01/2015, when exacly took place the first allocation made under "last /8" policy? any help would be appreciated thanks Riccardo
Tracing the policy text trough the versions - This text was first removed between * RIPE 599 published on 20 December 2013 https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations and * RIPE 604 - published on 4 Feb 2014: https://www.ripe.net/publications/docs/ripe-604
Where the text was changed to:
The size of the allocation made will be exactly one /22. The sum of all allocations made to a single LIR by the RIPE NCC after the 14th of September 2012 is limited to a maximum of 1024 IPv4 addresses (a single /22 or the equivalent thereof). The side story behind this is probably related to that it was assumed that IANA would get some address space back, address space they again could redistribute to the LIR. When slized up it would at some point not be possible to hand out /22's, only smaller blocks that could add upto a /22. All that would be addresses covered by "the last /8 policy", the runout policy.
and no reference to the last /8.
So I can easily understand the confusion. The intention was that once the policy was activated it would be there for all future until there was no IPv4 left. It was just called "the last /8 policy" since that's how it started out, the activation point.
(I can't find referenced to all of this but it is somewhere in the archives, and guess Geert or you can find it all? Wonder if it might be somewhere in the IETF space or so this was discussed to?)
-- 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 toinfo@wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) --------------------------------------------------------------------
-- 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) --------------------------------------------------------------------
On 20 Apr 2016, at 10:53, Riccardo Gori wrote:
Andrea, can you help me understand what happened to available pool is any when 185/8 was reiceved by IANA?
I think this may be the wrong question. IIRC, the triggering of the "last /8" policy (as it has usually been known) did not coincide with receipt of 185/8 from (NB: not "by") IANA by RIPE NCC, but rather with the first allocation by RIPE NCC from 185/8. As Roger Jørgensen has explained, once the policy was triggered, it was to apply to all subsequent allocations. Best regards, Niall O'Reilly
But Niall, I have to admit that these two statement at point 5.3 confuses me a bit: [...] 5.3 Address Recycling Any address space that is returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1. This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself. [...] sorry but maybe this feeds the confusion about last /8 appling only to 185/8 or the whole RIPE available pool thank you for you opinion Riccardo Il 20/04/2016 12:50, Niall O'Reilly ha scritto:
On 20 Apr 2016, at 10:53, Riccardo Gori wrote:
Andrea, can you help me understand what happened to available pool is any when 185/8 was reiceved by IANA?
I think this may be the wrong question.
IIRC, the triggering of the "last /8" policy (as it has usually been known) did not coincide with receipt of 185/8 from (NB: not "by") IANA by RIPE NCC, but rather with the first allocation by RIPE NCC from 185/8.
As Roger Jørgensen has explained, once the policy was triggered, it was to apply to all subsequent allocations.
Best regards, Niall O'Reilly
-- 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) --------------------------------------------------------------------
Hi, On Wed, Apr 20, 2016 at 01:14:16PM +0200, Riccardo Gori wrote:
sorry but maybe this feeds the confusion about last /8 appling only to 185/8 or the whole RIPE available pool
There was confusion about this in the past, so the NCC consulted the working group, we discussed it here on the list, and the conclusion was "as soon as the /8 kicks in, it will affect everything in the RIPE NCC free pool, period" - no going back to the older policy (should the pool grow over a /8), no "different policies for different /8s". I thought we even did a PDP on this, but cannot find it - so maybe someone else with better googling fu can find the discussion. 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
Hi Gert, Il 20/04/2016 13:22, Gert Doering ha scritto:
Hi,
sorry but maybe this feeds the confusion about last /8 appling only to 185/8 or the whole RIPE available pool There was confusion about this in the past, so the NCC consulted the working group, we discussed it here on the list, and the conclusion was "as soon as the /8 kicks in, it will affect everything in the RIPE NCC free pool,
On Wed, Apr 20, 2016 at 01:14:16PM +0200, Riccardo Gori wrote: period" - no going back to the older policy (should the pool grow over a /8), no "different policies for different /8s".
I thought we even did a PDP on this, but cannot find it - so maybe someone else with better googling fu can find the discussion.
Gert Doering APWG chair
thank you for the explanation, as said and known I wan't here at that time Riccardo -- 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) --------------------------------------------------------------------
On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote:
IIRC, the triggering of the "last /8" policy (as it has usually been known) did not coincide with receipt of 185/8 from (NB: not "by") IANA by RIPE NCC, but rather with the first allocation by RIPE NCC from 185/8.
185/8 received from IANA on feb. 2011 185/8 went "in use" (and the policy started) on sept 2012
As Roger Jørgensen has explained, once the policy was triggered, it was to apply to all subsequent allocations.
However, in the meantime some events happened: - recovered space issue - space returned to IANA 2012-05 to 2014-04 and gradually returned starting 2014-05 - 2013-03 - no need checking - 2014-04 - no ipv6 requirement - still keeping a high (~= /8) level of "somehow available space" - policy abuse, pushing to limits and general change in "who is a LIR" (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and more of them, corporate LIRs or simply "just want my damn ASN and /24" LIRs) I hope everybody does realize how this proposal came to life.
On Wed, Apr 20, 2016 at 10:43 PM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote: <snip>
As Roger Jørgensen has explained, once the policy was triggered, it was to apply to all subsequent allocations.
However, in the meantime some events happened: - recovered space issue - space returned to IANA 2012-05 to 2014-04 and gradually returned starting 2014-05
already known, space would be returned, and redistributed, it would still be covered by the policy since it would cover all allocation after that point in time.
- 2013-03 - no need checking - 2014-04 - no ipv6 requirement
adjustment, as we do with all policy. Maybe we should make it harder to get IPv4 space? ... but how would that help on the part we really need, more IPv6? Also it might over time make the RIR registry incomplete and full of error, that will hurt the Internet way more than the current gaming actual harm... as sad as that is... :-(
- still keeping a high (~= /8) level of "somehow available space"
as said earlier, it does not matter, the policy was there to safeguard some space for future startups. We are just lucky that the space has grown due to return and reallocation!
- policy abuse, pushing to limits and general change in "who is a LIR" (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and more of them, corporate LIRs or simply "just want my damn ASN and /24" LIRs)
... and here we are again back at the core, the abuse/gaming the system to get more address space. The only real solution to this is to deploy IPv6. Handing out more address space than /22 is not a solution because there will always be a need for more. There is no upper limit and we just run out way faster, and as said over and over again, that will ruin the point with this policy - safeguard some space for the future startups. I am happy with giving RIPE NCC power to turn down request from obvious fake company... however that has it's own problem and not all of them are solvable by this working group, some might not be solvable at all.
I hope everybody does realize how this proposal came to life.
giving out more space to those that ask for it is not a good solution with the future in mind. However if everyone want to be greedy here and now and say screw the future (sorry the language)... -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
On Wed, Apr 20, 2016 at 10:43 PM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
On Wed, Apr 20, 2016, at 12:50, Niall O'Reilly wrote: <snip>
As Roger Jørgensen has explained, once the policy was triggered, it was to apply to all subsequent allocations.
However, in the meantime some events happened: - recovered space issue - space returned to IANA 2012-05 to 2014-04 and gradually returned starting 2014-05 already known, space would be returned, and redistributed, it would still be covered by the policy since it would cover all allocation after that point in time.
- 2013-03 - no need checking - 2014-04 - no ipv6 requirement adjustment, as we do with all policy. Maybe we should make it harder to get IPv4 space? ... but how would that help on the part we really need, more IPv6? Also it might over time make the RIR registry incomplete and full of error, that will hurt the Internet way more than the current gaming actual harm... as sad as that is... :-(
- still keeping a high (~= /8) level of "somehow available space" as said earlier, it does not matter, the policy was there to safeguard some space for future startups. We are just lucky that the space has grown due to return and reallocation! Are you sure that we all here are saving space for new entrants? or
Hi Roger, Il 21/04/2016 08:40, Roger Jørgensen ha scritto: there can be someone saving economic value of its allocations? Everyone of us should be aware that when a resource is exhausted there's no more value in it. I would know all allocations holded by pleople to figure how much everyone is philanthropic Please understand I am not referring to anyone in particoular can be all of us me included or nobody And again remeber I am not for fast depletion.
- policy abuse, pushing to limits and general change in "who is a LIR" (get-to-transfer, multi-LIR/company, out-of-continent LIRs - more and more of them, corporate LIRs or simply "just want my damn ASN and /24" LIRs) ... and here we are again back at the core, the abuse/gaming the system to get more address space. The only real solution to this is to deploy IPv6. Handing out more address space than /22 is not a solution because there will always be a need for more. There is no upper limit and we just run out way faster, and as said over and over again, that will ruin the point with this policy - safeguard some space for the future startups.
I am happy with giving RIPE NCC power to turn down request from obvious fake company... however that has it's own problem and not all of them are solvable by this working group, some might not be solvable at all.
I hope everybody does realize how this proposal came to life. giving out more space to those that ask for it is not a good solution with the future in mind. However if everyone want to be greedy here and now and say screw the future (sorry the language)...
-- 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) --------------------------------------------------------------------
participants (8)
-
Gert Doering -
Hans Petter Holen -
Ingrid Wijte -
Niall O'Reilly -
Radu-Adrian FEURDEAN -
remco.vanmook＠gmail.com -
Riccardo Gori -
Roger Jørgensen