<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear Ingrid,<br>
<br>
thank you for you help<br>
<br>
<div class="moz-cite-prefix">Il 20/04/2016 12:09, Ingrid Wijte ha
scritto:<br>
</div>
<blockquote cite="mid:57175545.1060205@ripe.net" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Dear Riccardo, <br class="">
<font class="" color="#5856d6"><br class="">
</font>(I am responding on behalf of Andrea, who is currently
traveling). <br class="">
<font class="" color="#5856d6"><br class="">
</font>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. <br
class="">
<font class="" color="#5856d6"><br class="">
</font>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
<meta http-equiv="content-type" content="text/html; charset=utf-8">
states that RIPE NCC members can request a one time /22 allocation
(1,024 <span onclick="javascript:goto_glossary_definition(1)"
onmouseout="javascript:hide_glossary_definition_popup(this, 1)"
onmouseover="javascript:show_glossary_definition_popup(this, 1)"
class="highlightedGlossaryTerm">IPv4</span> addresses). </blockquote>
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.<br>
<blockquote cite="mid:57175545.1060205@ripe.net" type="cite">
<div class=""> I hope this helps.<br>
</div>
</blockquote>
<br>
thank you for your help<br>
Riccardo<br>
<blockquote cite="mid:57175545.1060205@ripe.net" type="cite">
<div class=""> <br>
Best regards,<br>
<br>
Ingrid Wijte<br>
Assistant Manager Registration Services<br class="">
</div>
RIPE NCC<br>
<br>
<div class="moz-cite-prefix">On 20/04/2016 11:53, Riccardo Gori
wrote:<br>
</div>
<blockquote cite="mid:5717518E.70409@wirem.net" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
Hi Roger,<br>
<br>
<div class="moz-cite-prefix">Il 20/04/2016 11:00, Roger
Jørgensen ha scritto:<br>
</div>
<blockquote
cite="mid:CAKFn1SF_2tNy+ZU4ETSYF5BZKFwyL47s3dZwA40X5kNV-AKhRw@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Apr 20, 2016 at 1:17 AM, Hans Petter Holen <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:hph@oslo.net"><hph@oslo.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 16.04.2016 12.29, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:remco.vanmook@gmail.com">remco.vanmook@gmail.com</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">I looked up the policy proposal at
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ripe.net/participate/policies/proposals/2010-02">https://www.ripe.net/participate/policies/proposals/2010-02</a>
" This proposal describes how the RIPE NCC should distribute IPv4 address
space from the final /8 address block it receives from the IANA."
</pre>
</blockquote>
<pre wrap="">Not the best wording back there it seems...
</pre>
<blockquote type="cite">
<pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations">https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations</a>
* 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
</pre>
</blockquote>
<pre wrap="">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...</pre>
</blockquote>
<br>
Are you sure? I mean, when 185/8 has been reiceved from IANA:<br>
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?<br>
I am serius since I wasn't here at that time and I don't really
know what happened.<br>
Andrea, can you help me understand what happened to available
pool is any when 185/8 was reiceved by IANA?<br>
please understand I signed up 01/2015, when exacly took place
the first allocation made under "last /8" policy?<br>
any help would be appreciated<br>
thanks<br>
Riccardo<br>
<br>
<blockquote
cite="mid:CAKFn1SF_2tNy+ZU4ETSYF5BZKFwyL47s3dZwA40X5kNV-AKhRw@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Tracing the policy text trough the versions - This text was first removed
between
* RIPE 599 published on 20 December 2013
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations">https://www.ripe.net/publications/docs/ripe-599#Use-last-for-PA-Allocations</a>
and
* RIPE 604 - published on 4 Feb 2014:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ripe.net/publications/docs/ripe-604">https://www.ripe.net/publications/docs/ripe-604</a>
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).
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">and no reference to the last /8.
So I can easily understand the confusion.
</pre>
</blockquote>
<pre wrap="">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?)
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<pre>Ing. Riccardo Gori
e-mail: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:rgori@wirem.net">rgori@wirem.net</a>
Mobile: +39 339 8925947
Mobile: +34 602 009 437
Profile: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://it.linkedin.com/in/riccardo-gori-74201943">https://it.linkedin.com/in/riccardo-gori-74201943</a>
</pre>
<img src="cid:part9.07040202.08010102@wirem.net" width="200">
<pre>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 <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:info@wirem.net">info@wirem.net</a>
Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------
</pre>
</div>
</blockquote>
<br>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<pre>Ing. Riccardo Gori
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:rgori@wirem.net">rgori@wirem.net</a>
Mobile: +39 339 8925947
Mobile: +34 602 009 437
Profile: <a class="moz-txt-link-freetext" href="https://it.linkedin.com/in/riccardo-gori-74201943">https://it.linkedin.com/in/riccardo-gori-74201943</a>
</pre>
<img src="cid:part11.03010407.00070405@wirem.net" width="200">
<pre>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 <a class="moz-txt-link-abbreviated" href="mailto:info@wirem.net">info@wirem.net</a>
Thank you
WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC)
--------------------------------------------------------------------
</pre>
</div>
</body>
</html>