<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><style>/*<![CDATA[*/p.MsoNormal, li.MsoNormal, div.MsoNormal {
margin: 0.0cm;
font-size: 11.0pt;
font-family: Calibri , sans-serif;
}
a:link, span.MsoHyperlink {
color: blue;
text-decoration: underline;
}
pre {
margin: 0.0cm;
font-size: 10.0pt;
font-family: "Courier New";
}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top: 0.0cm;
margin-right: 0.0cm;
margin-bottom: 0.0cm;
margin-left: 36.0pt;
font-size: 11.0pt;
font-family: Calibri , sans-serif;
}
span.apple-tab-span {
}
span.HTMLconformatoprevioCar {
font-family: Consolas , serif;
}
span.EstiloCorreo22 {
font-family: Calibri , sans-serif;
color: windowtext;
}
*.MsoChpDefault {
font-size: 10.0pt;
}
div.WordSection1 {
page: WordSection1;
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
* {
}
ol {
margin-bottom: 0.0cm;
}
ul {
margin-bottom: 0.0cm;
}
/*]]>*/</style></div><div>hi/bonjour,<br></div><div><br data-mce-bogus="1"></div><div>+1 with @JORDI [..] strategy, increase IPV4 cost (even if there is a black market of opportunities effect of those can deal) and have an affordable price for IPV6. That could be fix for a "transition period" of 3 or 5 years to manage ROI of investors. <br></div><div><br data-mce-bogus="1"></div><div>sorry if my sharing is out of the box, i'm new and don't really know all exchanges rules<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>regards and stay safe at home from people under lockdown program<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>regards from Guadeloupe, French caribbean<br data-mce-bogus="1"></div><div><br></div><div data-marker="__SIG_PRE__"><div><div>-- <br><strong>Betty FAUSTA— CEO IPEOS I-Solutions</strong><br>Mobile: +590 690 497 309<br>Twitter/Instagram: @betfau<br><br>www.ipeos.com | www.ipeos.net<br>Sales: +590 590 <strong>228</strong> 020 - info@ipeos.com - Fax (0)972 337 124<br>Hotline: +590 590 <strong>227</strong> 217 - https://support.ipeos.com</div><div><a href="https://docmail.apps-ipeos.com/" rel="nofollow noopener noreferrer nofollow noopener noreferrer" target="_blank">Découvrez la messagerie collaborative par IPEOS </a><br></div></div></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>De: </b>"JORDI PALET MARTINEZ via ARIN-PPML" <arin-ppml@arin.net><br><b>À: </b>arin-ppml@arin.net<br><b>Envoyé: </b>Dimanche 19 Avril 2020 05:16:12<br><b>Objet: </b>Re: [arin-ppml] Draft Policy ARIN-2020-3: IPv6 Nano-allocations<br></div><div><br></div><div data-marker="__QUOTED_TEXT__"><div><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">LACNIC and AFRINIC have similar problems in the fee structure that doesn’t incentivize the right deployment of IPv6. I’ve already made proposals to the relevant boards to change that (it is not a matter of policies in those cases).</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">Many management departments of ISPs make the numbers about the right prefix for customers, not according to technical reasons, but to:</span></p><ol style="margin-top:0cm" type="1" start="1"><li class="MsoListParagraph" style="margin-left:0cm"><span style="font-size:12pt" lang="EN-US">By default, I get a /32 without justification (in all the other RIRs), done, this must work for any number of customers. Even if I give them a single /64 …</span></li><li class="MsoListParagraph" style="margin-left:0cm"><span style="font-size:12pt" lang="EN-US">I want to make sure that the “cost” of each customer prefix is as lower as I can.</span></li></ol><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">I think we should do this:</span></p><ol style="margin-top:0cm" type="a" start="1"><li class="MsoListParagraph" style="margin-left:0cm"><span style="font-size:12pt" lang="EN-US">The cost of “every” /48 out of a /40 must be proportional to the cost of “every” /48 out of a /40, /36, /32 and so on. It makes a lot of sense that as larger is the block that you get from ARIN, the proportional cost of each /48 gets cheaper and cheaper. You can do the same “proportionality” with each /128, /64, /56, or whatever. It is not related to the size of the prefix you provide, just having some symmetry.</span></li></ol><p class="MsoListParagraph"><span style="font-size:12pt" lang="EN-US">Right one in ARIN, if you assume that you’re using a /48 for each customer you pay for each /48 out of each /40, 0,97656 USD, out of a /36 0,12207 USD, in the case of the /32 0,01526, and in the case of the /28 0,00191 USD. I think the “jump” in between each category and the following ones is not good, especially for the smaller ISPs.</span></p><ol style="margin-top:0cm" type="a" start="2"><li class="MsoListParagraph" style="margin-left:0cm"><span style="font-size:12pt" lang="EN-US">The fee structure for IPv4, needs to be “disconnected” from the IPv6 one. IPv4 must become more expensive. IPv6 must become cheaper.</span></li><li class="MsoListParagraph" style="margin-left:0cm"><span style="font-size:12pt" lang="EN-US">If an ISP is doing a right addressing plan and provides the justification for it, even if it is providing /48 to every customer (including residential customer) that should be supported. In fact, I always tell my customers, you must go for /48 and make persistent prefixes to customers (unless they move to a different location). RIPE-690 provides explanations for that.</span></li></ol><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">However, the problem is probably better resolved by the board, making a better fee structure than by a policy. Policy may help to facilitate the usage of /48, but if we also change the fee structure it will be much logic.</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">The case about $CABLECO it is clearly a *<b>BAD</b>* designed addressing plan. I still see lots of people doing *<b>terribly bad</b>* addressing plans with IPv6, and there is no need for that. You can still provide a /48 for each customer, even for millions of customers, and still not *<b>waste</b>* a lot of addresses and no require a complex interior routing setup. Many documents and trainings do a really really bad work in that. I’ve started several months ago, to write a BCOP for telling people how this can be done correctly, but I’d not the sufficient time/tranquility to finish it. Hopefully I can do it soon (happy to get in touch, in private, with other people that is interested in contributing to it).</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">I believe it is rare the case where an ISP may need /16, but because they need to justify it, and I’m sure ARIN will be stricter with a justification for a /16 or /20 than for a /32, I think this restriction should not be put in place. If there is a single case, we must support it, otherwise, we are asking that ISP to provide customers a smaller block that what he will like to do.</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">Giving each “human” (not household) a /48 is perfectly valid. There is no IPv6 scarcity. I’ve done this numbers several times, here is one more.</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">Each /3 has </span><span style="font-size:12pt;color:black" lang="EN-US">35.184.372.088.832 /48’s.</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">Assuming that we are so terrible with the utilization of IPv6, that we waste 50% of it, we have only </span><span style="font-size:12pt;color:black" lang="EN-US">17.592.186.044.416 /48’s</span><span style="font-size:12pt" lang="EN-US">.</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">Assuming that in the earth we can get 2^35 inhabitants (</span><span style="font-size:12pt;color:black" lang="EN-US">34.359.738.368).</span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US">Assuming that each person lives 100 years and we don’t recover the IPv6 space when they are buried.</span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US">If we give each person a /48, then we have sufficient number of them for the next 51.200 years.</span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US">If we give each person 4 /48’s, then we have sufficient number of them only for the next 12.800 years.</span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US">If we start using the other 7/8 of the addressing space, then we have IPv6 for the next 409.600 or 102.400 years (depending on if we provide a single /48 or 4 of them).</span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US">I know those figures look an exaggeration, but they are just numbers. The issue here is that we need to understand that the next big “problem” in Internet is not the number of addresses (even if addressing plans need to be done in such way that they are not wasteful), but may other issues to come.</span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US">See </span><a href="https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02" target="_blank" rel="nofollow noopener noreferrer"><span lang="EN-US">https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02</span></a><span style="font-size:12pt" lang="EN-US">. I need to update it!</span><span lang="EN-US"></span></p><div><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt;color:black" lang="EN-US">Regards,</span></p><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:12pt;color:black" lang="EN-US">Jordi</span></p><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:12pt;color:black" lang="EN-US">@jordipalet</span></p><p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:12pt;color:black" lang="EN-US"> </span></p></div><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><p class="MsoNormal"><span style="font-size:12pt" lang="EN-US"> </span></p><div><div><p class="MsoNormal" style="margin-left:35.4pt">El 18/4/20 10:42, "ARIN-PPML en nombre de Fernando Frediani" <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank" rel="nofollow noopener noreferrer">arin-ppml-bounces@arin.net</a> en nombre de <a href="mailto:fhfrediani@gmail.com" target="_blank" rel="nofollow noopener noreferrer">fhfrediani@gmail.com</a>> escribió:</p></div></div><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt">On 18/04/2020 05:26, Owen DeLong wrote:</p></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal" style="margin-left:35.4pt">... </p><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt">Admittedly, /48s for everyone still isn’t gaining as much traction as we’d like due to a combination of IPv4-think at some ISPs and other reasons I have trouble understanding.</p></div></blockquote><p class="MsoNormal" style="margin-left:35.4pt">Thankfully it is not !<br><br></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt">E.G. I once had a discussion with the IPv6 project manager for a major $CABLECO about why they were sticking it to their residential customers with a maximum /60 instead of a /48. His answer perplexed me… He said that the problem was that if they gave out /48s to all their customers the way their network is structured, they’d need a /12. Now I realize that policy only allows ARIN to give out a /16 at a time, but I’m quite certain this particular organization could easily qualify for 16 /16s without any issue whatsoever. When I pointed this out, he just walked away shaking his head.</p></div></blockquote><p class="MsoNormal" style="margin-left:35.4pt">And he is right. I still fail to understand from where this idea of giving residential customers a /48 came from. And this is not thinking with IPv4's mind really.<br><br></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt">Now I realize a /12 sounds like a ridiculous amount of space, but if you think about it, this is an organization that has several /8s worth of IPv4, so it’s not actually all that far fetched. Also, I seriously doubt that there are anywhere near 100 organizations with the number of customers this $CABLECO has. There are 512 /12s in 2000::/3 which is just the first 1/8th of IPv6 address space designated as GUA (Global Unicast Addresses). The math works. We have the address space to do this and give everyone /48s without any issue of running out.</p></div></blockquote><p style="margin-left:35.4pt">Well, I hear this every time I talk against this "/48 for all" idea. And I don't think because of this justification 'we have plenty so let's give them' should be broadly and always applied. Give people whatever is reasonable for their usage, but not a tremendous exaggeration. And a /48 for a residential customer is an exaggeration that will hardly ever be used. If one day this changes we can adapt to the new scenario.</p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt">So… we have a circumstance of competing tradeoffs in policy:</p></div><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt"><span class="apple-tab-span"> </span>1.<span class="apple-tab-span"> </span>We don’t want policy to create perverse incentives to not give /48s to customers. That’s one of the reasons</p></div><div><p class="MsoNormal" style="margin-left:35.4pt"><span class="apple-tab-span"> </span>for the particular wording of the PAU text in the IPv6 ISP policy (which staff doesn’t do a particularly good</p></div><div><p class="MsoNormal" style="margin-left:35.4pt"><span class="apple-tab-span"> </span>job of following in my observation).</p></div><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><div><p class="MsoNormal" style="margin-left:35.4pt"><span class="apple-tab-span"> </span>2.<span class="apple-tab-span"> </span>We don’t want to create economic disincentives to IPv6 deployment.</p></div></blockquote><p style="margin-left:35.4pt">I can see the intents of this proposal specially for point 2 and perhaps there are adjustments to be done, but certainly not with the idea of giving /48 everywhere in mind.</p><p style="margin-left:35.4pt">Fernando</p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><p class="MsoNormal" style="margin-left:35.4pt"> </p><div><p class="MsoNormal" style="margin-left:35.4pt"> </p></div><p class="MsoNormal" style="margin-left:35.4pt"><br><br></p><pre style="margin-left:35.4pt">_______________________________________________</pre><pre style="margin-left:35.4pt">ARIN-PPML</pre><pre style="margin-left:35.4pt">You are receiving this message because you are subscribed to</pre><pre style="margin-left:35.4pt">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" rel="nofollow noopener noreferrer">ARIN-PPML@arin.net</a>).</pre><pre style="margin-left:35.4pt">Unsubscribe or manage your mailing list subscription at:</pre><pre style="margin-left:35.4pt"><a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank" rel="nofollow noopener noreferrer">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br data-mce-bogus="1"></pre><pre style="margin-left:35.4pt">Please contact <a href="mailto:info@arin.net" target="_blank" rel="nofollow noopener noreferrer">info@arin.net</a> if you experience any issues.</pre></blockquote><p class="MsoNormal" style="margin-left:35.4pt">_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact info@arin.net if you experience any issues. </p></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.<br>
<br>
<br>_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<br>Unsubscribe or manage your mailing list subscription at:<br>https://lists.arin.net/mailman/listinfo/arin-ppml<br>Please contact info@arin.net if you experience any issues.<br></div></div></body></html>