<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Cuerpo en alfa";
panose-1:2 2 6 3 5 4 5 2 3 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML con formato previo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.HTMLconformatoprevioCar
{mso-style-name:"HTML con formato previo Car";
mso-style-priority:99;
mso-style-link:"HTML con formato previo";
font-family:"Consolas",serif;}
span.EstiloCorreo22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:457456270;
mso-list-type:hybrid;
mso-list-template-ids:-1282390930 67764247 67764249 67764251 67764239 67764249 67764251 67764239 67764249 67764251;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1629357034;
mso-list-type:hybrid;
mso-list-template-ids:-85435994 67764241 67764249 67764251 67764239 67764249 67764251 67764239 67764249 67764251;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style></head><body lang=ES link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>Many management departments of ISPs make the numbers about the right prefix for customers, not according to technical reasons, but to:<o:p></o:p></span></p><ol style='margin-top:0cm' start=1 type=1><li class=MsoListParagraph style='margin-left:0cm;mso-list:l1 level1 lfo1'><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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 …<o:p></o:p></span></li><li class=MsoListParagraph style='margin-left:0cm;mso-list:l1 level1 lfo1'><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>I want to make sure that the “cost” of each customer prefix is as lower as I can.<o:p></o:p></span></li></ol><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>I think we should do this:<o:p></o:p></span></p><ol style='margin-top:0cm' start=1 type=a><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo2'><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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.<o:p></o:p></span></li></ol><p class=MsoListParagraph><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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.<o:p></o:p></span></p><ol style='margin-top:0cm' start=2 type=a><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo2'><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>The fee structure for IPv4, needs to be “disconnected” from the IPv6 one. IPv4 must become more expensive. IPv6 must become cheaper.<o:p></o:p></span></li><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo2'><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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.<o:p></o:p></span></li></ol><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language: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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>Each /3 has </span><span lang=EN-US style='font-size:12.0pt;color:black'>35.184.372.088.832 /48’s.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>Assuming that we are so terrible with the utilization of IPv6, that we waste 50% of it, we have only </span><span lang=EN-US style='font-size:12.0pt;color:black'>17.592.186.044.416 /48’s</span><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>Assuming that in the earth we can get 2^35 inhabitants (</span><span lang=EN-US style='font-size:12.0pt;color:black'>34.359.738.368).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>Assuming that each person lives 100 years and we don’t recover the IPv6 space when they are buried.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>If we give each person a /48, then we have sufficient number of them for the next 51.200 years.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>If we give each person 4 /48’s, then we have sufficient number of them only for the next 12.800 years.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>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).<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>See </span><a href="https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02"><span lang=EN-US>https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02</span></a><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'>. I need to update it!</span><span lang=EN-US><o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;color:black'>Regards,<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'>Jordi<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'>@jordipalet<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=EN-US style='font-size:12.0pt;color:black;mso-fareast-language:EN-US'><o:p> </o:p></span></p></div><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'><o:p> </o:p></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">arin-ppml-bounces@arin.net</a> en nombre de <a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> escribió:<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>On 18/04/2020 05:26, Owen DeLong wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-left:35.4pt'>... <o:p></o:p></p><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></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.<o:p></o:p></p></div></blockquote><p class=MsoNormal style='margin-left:35.4pt'>Thankfully it is not !<br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></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.<o:p></o:p></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><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></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.<o:p></o:p></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.<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>So… we have a circumstance of competing tradeoffs in policy:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></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<o:p></o:p></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<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><span class=apple-tab-span> </span>job of following in my observation).<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></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.<o:p></o:p></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.<o:p></o:p></p><p style='margin-left:35.4pt'>Fernando<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div><p class=MsoNormal style='margin-left:35.4pt'><br><br><o:p></o:p></p><pre style='margin-left:35.4pt'>_______________________________________________<o:p></o:p></pre><pre style='margin-left:35.4pt'>ARIN-PPML<o:p></o:p></pre><pre style='margin-left:35.4pt'>You are receiving this message because you are subscribed to<o:p></o:p></pre><pre style='margin-left:35.4pt'>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<o:p></o:p></pre><pre style='margin-left:35.4pt'>Unsubscribe or manage your mailing list subscription at:<o:p></o:p></pre><pre style='margin-left:35.4pt'><a href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><o:p></o:p></pre><pre style='margin-left:35.4pt'>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<o:p></o:p></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. <o:p></o:p></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>
</body></html>