<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";}
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.EstiloCorreo20
{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;}
--></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'>Hi Chris,<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 guess you missed this at the end of my previous email:<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 style='font-size:12.0pt;mso-fareast-language:EN-US'><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><span lang=EN-US style='font-size:12.0pt;mso-fareast-language:EN-US'> I need to update 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'><o:p> </o:p></span></p><div><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 19/4/20 21:32, "ARIN-PPML en nombre de Chris Woodfield" <<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> en nombre de <a href="mailto:chris@semihuman.com">chris@semihuman.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><p class=MsoNormal style='margin-left:35.4pt'>I’ll admit to having skimmed some of this thread, so apologies in advance if I've missed prior discussion of the point below.<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'>The guidance against assigning /48s by default described in RFC6177 made sense at the time, particularly for an individual residential subscriber site, given the assumption that a residential site would rarely, if ever, have a second layer of L3 forwarding beyond the broadband router - that is, each /64 within the customer’s allocation would be attached to the edge gateway (i.e. multiple VLANs, WiFi SSIDs with L3 separation, etc.) In that world, allowing 65K unique /64s gateways to exist on a home broadband router was rightly seen as unnecessarily wasteful, regardless of sparse addressing design patterns. As is, even the 256 /64 prefixes in the /56 I can route to my broadband edge device seems like overkill, and I’d like to think I’m much savvier than the typical residential subscriber :)<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'>That said, RFC8273, published 6 years after 6177, now recommends that instead of assigning individual /128s to hosts within a shared /64, prefix delegation should be utilized instead to assign a /64 *per host* by default within an IPv6 network. This practice unlocks the ability for any end host to become a downstream “virtual” L3 router, allowing individually addressed software components to be uniquely addressed within a host (obvious candidates here would be virtual machines and docker containers, but also individual servers or clients living on the host), all numbered from a /64 with a known physical* location for policy/security purposes.<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'>Given this recommendation, I believe it absolutely makes sense now to standardize as best practice the default assignment of a /48 to even residential subscribers, given that IETF-codified best practices now recommend exactly that two-layer routing model that the lack of which provided the original justification for RFC6177. <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'>(Side note: Happy to work with any interested parties on a new RFC re-codifying the recommendations from RFC3177, informed by 8273, and obsoleting 6177 given the above).<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'>Thanks,<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'>-Chris<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'>*Yes, I’m aware the host itself could be virtual as well. Turtles all the way down, folks.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'><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'>On Apr 19, 2020, at 10:28 AM, John Santos <<a href="mailto:john@egh.com">john@egh.com</a>> wrote:<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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'>Policy should not prohibit doing what many regard as best practice. Just because SOME ISPs might find a /48 unnecessarily large doesn't mean that ALL will, or that the recommendation of a /48 is always WRONG and that nano-ISPs should be punished (financially) for doing so.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'>There is obviously a huge scaling issue with fees, when a giant ISP is paying less than a penny per year for addresses and a very small ISP is paying close to a dollar per year, but I don't think we can fix that with policy. But we can make it less worse by allowing the tiniest ISPs to allocate what they need and not orders of magnitude more than they need at exponentially larger cost.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'>Is there any way to ensure that an ISP requesting a /40 has fewer than 250 customers, so they can assign each a /48 in order to be eligible for the smallest allocation at commensurate cost with a /24 of IPv4?<o:p></o:p></p><div><p class=MsoNormal style='margin-left:35.4pt'>On 4/19/2020 11:33 AM, Fernando Frediani wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:35.4pt'>On 19/04/2020 05:07, 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'>Right… IETF designed a good architecture and then came under pressure from a bunch of people with an IPv4 mindset and given the modern state of the IETF decided to just punt on the whole thing rather than waste more time on an argument where people were determined to do what they were going to do anyway. RFC 6177 is more of a cop-out than a legitimate standards document.<o:p></o:p></p></div></blockquote><p class=MsoNormal style='margin-left:35.4pt'>We cannot just choose the RFCs we will follow from those we like and disregard those which we don't. Imagine if vendors start to do the same !<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'>Since it correctly (in my view) does putting that /48 for residential customers should be treated as an exception therefore no RIRs should have to adapt their policies to it. If ISPs assign /48 to these customers in exceptional basis (not as default) then they would have less or none of of the problems discussed here.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'><clip><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'>There’s absolutely noting in RFC6177 that says /48s should not be given out to residential customers. It punts it to the operational community and says it really shouldn’t<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>be up to the IETF. That’s generally true, but that does come with a responsibility that the operational community doesn’t arbitrarily create negative impacts without good<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:35.4pt'>reason.<o:p></o:p></p></div></blockquote><p class=MsoNormal style='margin-left:35.4pt'>One of the main points of the document, if not the most, is that /48 is no longer the default and not recommended as well. Therefore if it still possible to assign to a residential customer it should then be considered an exception not a normal thing as the others.<br>Let me quote an important part of it within section 2: "<i>Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.</i>"<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'>Furthermore at the time of the write of the document it also mentions: "Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE [RIPE-ENDSITE] have revised the end site assignment policy to encourage the assignment of smaller (i.e., /56) blocks to end sites.". Although some of these might have been retired in their manuals it is possible to notice the spirit of the change RFC6177 brings, and is still valid.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:35.4pt'>Regards<br>Fernando<o:p></o:p></p><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><pre style='margin-left:35.4pt'>-- <o:p></o:p></pre><pre style='margin-left:35.4pt'>John Santos<o:p></o:p></pre><pre style='margin-left:35.4pt'>Evans Griffiths & Hart, Inc.<o:p></o:p></pre><pre style='margin-left:35.4pt'>781-861-0670 ext 539<o:p></o:p></pre></div><p class=MsoNormal style='margin-left:35.4pt'>_______________________________________________<br>ARIN-PPML<br>You are receiving this message because you are subscribed to<br>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>Unsubscribe or manage your mailing list subscription at:<br><a href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>Please contact info@arin.net if you experience any issues.<o:p></o:p></p></div></blockquote></div><p class=MsoNormal style='margin-left:35.4pt'><o:p> </o:p></p></div></div></div><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>