<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>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.</p>
<p>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?<br>
</p>
<div class="moz-cite-prefix">On 4/19/2020 11:33 AM, Fernando
Frediani wrote:<br>
</div>
<blockquote type="cite"
cite="mid:cf4672c8-f5a2-7715-5c96-aea17a415046@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 19/04/2020 05:07, Owen DeLong
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2E7A4FD7-8E4D-42E2-9B20-0C56C73D2AF7@delong.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<br>
<div>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.</div>
</blockquote>
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 !<br>
<p>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.<br>
</p>
<p><clip></p>
<blockquote type="cite"
cite="mid:2E7A4FD7-8E4D-42E2-9B20-0C56C73D2AF7@delong.com">
<div class=""><br class="">
</div>
<div class="">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</div>
<div class="">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</div>
<div class="">reason.</div>
</blockquote>
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>"<br>
<p>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.</p>
<p>Regards<br>
Fernando<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<pre class="moz-signature" cols="80">--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
</pre>
</body>
</html>