<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-15">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Carlos,<br>
<br>
sorry for the late reply I was out for work.<br>
<br>
I'll reply only to your question "> Fix IPv6 rate adoption by
policy? "<br>
Carlos, this policy proposal aims to fix IPv4 rate depletion... so
why don't use a policy for "rate adoption"? do you see any
difference?<br>
Rest is personal opinion and from my point of view any conservative
policy will only last the pain longer.<br>
<br>
thank you<br>
regards<br>
Riccardo<br>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Il 24/09/2017 15:09, Carlos Fria�as ha
scritto:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LRH.2.21.1709241302060.26069@gauntlet.corp.fccn.pt">
<br>
Hi Riccardo, All,
<br>
<br>
Thanks for your input.
<br>
<br>
Please see inline.
<br>
<br>
<br>
On Sun, 24 Sep 2017, Riccardo Gori wrote:
<br>
<br>
<blockquote type="cite">Dear all,
<br>
<br>
I started as an ISP early 2015 and I still consider myself a new
entrant.
<br>
</blockquote>
<br>
That's not my definition for "new entrant". Strictly i consider a
new entrant as an organization which doesn't own any IPv4 or IPv6
address space. Loosely, it can be a new LIR (before getting its
/22 and an IPv6 block under current policy)...
<br>
<br>
But, luckly the community approved a policy for the last /8 long
before 2015. If that didn't happen, your only solution would have
been to rely on the market.
<br>
<br>
</blockquote>
<blockquote type="cite"
cite="mid:alpine.LRH.2.21.1709241302060.26069@gauntlet.corp.fccn.pt">
<br>
<blockquote type="cite">In the last 2 years I heard about a couple
of time "no more IPv4 policies let's go over and think how to
fix/help IPv6 rate adoption" but today we are still here
complaining what's the best way to last longer with the agony.
<br>
</blockquote>
<br>
Is "no more IPv4 policies" written in stone somewhere? :-)
<br>
<br>
Fix IPv6 rate adoption by policy?
<br>
Let's call our countries' telecom regulators, and ask for a policy
that prohibits IPv4 usage from day X onwards? -- i don't think
so...........
<br>
<br>
<br>
<blockquote type="cite">For Ipv6 RIPE NCC is doing its best with
training and is really appreciated
<br>
</blockquote>
<br>
+1 on that!
<br>
<br>
<br>
<blockquote type="cite">and I learned here that we tend to not mix
IPv4/6 policies but I really expected incentives from the
cummunity not obstacles. The "IPv6 Requirement for Receiving
Space from the Final /8" was abandoned 23/10/2014 by the
adoption of 2014-04 proposal
<br>
</blockquote>
<br>
Looking back now, was that a good decision...?
<br>
<br>
<br>
<blockquote type="cite">while this 2017-03 proposal aims to last
as longer as possible with IPv4.
<br>
</blockquote>
<br>
Should we tweak it, and make it more "stricter", in a way the
address space is (automatically?) returned if it's not being used
in v4/v6 translation mechanisms...? (and do we have means to check
that?)
<br>
<br>
<br>
<br>
<blockquote type="cite">Looks to me that we are trying to save
future generation from ice melting saving oil tanks instead of
working on research and incentives to clean energies.
<br>
</blockquote>
<br>
Incentives cost money -- taxpayers' or consumers' money (or both!)
<br>
<br>
<br>
<blockquote type="cite">I don't see even any reason to save more
address space than the current policies does 'casue we have
"trasfert policies"
<br>
</blockquote>
<br>
Transfers of last /8 slices are still allowed after 24 months --
should that possibility end...? (2017-03 v1.0 doesn't address
transfers)
<br>
<br>
<br>
<blockquote type="cite">for almost any kind of IP resource and if
there are some restrictions on new allocation there are more
flexible for legacy space.
<br>
</blockquote>
<br>
The RIPE community (through the NCC) only provides services to
legacy space holders (and there was a proprosal for that...
2012-07).
<br>
The RIPE community is not able to design policies regarding
address space which was distributed before the NCC's creation.
<br>
<br>
<br>
<br>
<blockquote type="cite">Today you can simply choose to go RIPE or
market as your feeling to get IPv4/6 if needed.
<br>
</blockquote>
<br>
If the choice is going to the "market" (and if you are in strict
sense a new entrant), the "market" will not advocate you should
use/deploy IPv6.
<br>
On the other hand, if the choice is becoming a LIR, you will get
that... :-)
<br>
<br>
<br>
<br>
<blockquote type="cite">My small router deals today with more than
2.5 million routes (2 full routing tables and some IX) and it
really takes time to backup and even routing performance are
affected by volume of routes. I think we should propote IPv6 for
route aggregation ability.
<br>
</blockquote>
<br>
There is also de-aggregation in IPv6-land. :-(
<br>
(<a class="moz-txt-link-freetext" href="http://www.cidr-report.org/v6/as2.0/">http://www.cidr-report.org/v6/as2.0/</a>)
<br>
People will mess up routing as the rest of the world lets them...
<br>
<br>
<br>
<blockquote type="cite">I see this policy as:
<br>
- an obstacle to IPv6
<br>
</blockquote>
<br>
That was not the goal. The goal was to extend v4 availability for
some more time, thus making life easier for IPv6 deployments that
will still need to talk with the v4 world.
<br>
<br>
<br>
<blockquote type="cite">- a clear side effect of market price rise
on IPv4
<br>
</blockquote>
<br>
This proposal is not about the "market". a /24 can cost X, Y or Z
over time. The only way we can keep "affordability" for new
entrants is by defining what they get from the NCC, not from any
3rd party.
<br>
<br>
<br>
<br>
<blockquote type="cite">- a disincentive to route aggregation
<br>
</blockquote>
<br>
I don't agree. /22s (and bigger chunks) are already being
announced as /24s. What we consider is that keeping the
"affordability" for new entrants is a bigger priority than keeping
the DFZ on 683k (today) instead of 725k, 750k or even 800k routes.
I know 800k routes looks insane, but two years ago 683k would have
been equally insane :-))
<br>
<br>
ps: On 24-09-2015 (two years ago), 572876 routes
<br>
<a class="moz-txt-link-freetext" href="https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/">https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/</a>
<br>
<br>
<br>
Thanks!
<br>
<br>
<br>
Best Regards,
<br>
Carlos Fria�as
<br>
<br>
<br>
<blockquote type="cite">That's why I oppose this policy
<br>
kind regards
<br>
Riccardo
<br>
<br>
--
<br>
Riccardo Gori
<br>
<br>
</blockquote>
</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>
Italia: +39 339 89 25 947
Espa�a: +34 660 11 59 89
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="http://www.wirem.net/assets/components/wirem/images/logoWirem_4cm_conR.jpg"
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>