<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 18, 2020, at 22:20 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" class="">fhfrediani@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">On 19/04/2020 01:38, David Farmer
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAN-Dau04Pw8F2QcmiwBFhe-qF6LOBk0pSbCgteXx+k9hTq0tQA@mail.gmail.com" class="">
<meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">I support this policy as written, as I said
previously, I recommend a couple of changes, but I won't
repeat the details of those changes here.
<div class=""><br class="">
</div>
<div class="">Regarding the current discussion of /48 assignments to
residential customers, that is the architecture as defined
by the IETF, and ARIN policy MUST NOT create situations
where its necessary or that incentivizes ISPs to make
assignments longer than /48. Further, this policy is at
least minimally consistent with the IPv6 architecture, and
/48 IPv6 assignments, when considering a 3X-Small ISP, with
a /24 of IPv4 and a /40 of IPv6, both address families will
reasonably support 250 or fewer customers.</div>
</div>
</div>
</blockquote><p class="">Can you please quote exactly where IETF defines that way ? <br class="">
</p><p class="">RFC6177 in its abstract says: "<i class="">RFC 3177 argued that in IPv6,
end sites should be assigned /48 blocks in most cases. The
Regional Internet Registries (RIRs) adopted that recommendation
in 2002, but began reconsidering the policy in 2005. This
document obsoletes the RFC 3177 recommendations on the
assignment of IPv6 address space to end sites. The exact choice
of how much address space to assign end sites is an issue for
the operational community. The IETF's role in this case is
limited to providing guidance on IPv6 architectural and
operational considerations.</i>"<br class="">
</p>
...<br class="">
"<i class="">This document reviews the architectural and operational
considerations of end site assignments as well as the motivations
behind the original recommendations in RFC 3177. Moreover, this
document clarifies that a one-size-fits-all recommendation of /48
is not nuanced enough for the broad range of end sites and is no
longer recommended as a single default.</i>”</div></div></blockquote><div><br class=""></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><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" cite="mid:CAN-Dau04Pw8F2QcmiwBFhe-qF6LOBk0pSbCgteXx+k9hTq0tQA@mail.gmail.com" class=""><div dir="ltr" class=""><div dir="ltr" class="">
<div class="">The number of customers and the size of IPv6 customer
assignments actually deployed in reality are outside the
scope and control of ARIN, the other RIRs, and even the
IETF. It is solely in the scope and control of the ISP
deploying a network. Furthermore, RFC 6177 recognizes longer
end-site assignments between /48 and /64 could be
reasonable.</div>
</div>
</div>
</blockquote><p class="">Recognizes as an exception and it clearly states that is not the
recommendation anymore, talks about all the issues and why it was
reviewed and mentions that if someone justify can get it, so as an
exception.<br class=""></p></div></div></blockquote><div>It recognizes LONGER assignments as an exception, yes. It does not clearly state that /48 is no longer the recommendation.</div><div><br class=""></div><div>Specifically:</div><div><pre style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px;" class="">Moreover, this document clarifies that a one-size-fits-all
recommendation of /48 is not nuanced enough for the broad range of
end sites and is no longer recommended as a single default.</pre><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Recognizes that perhaps there are some end sites where a /48 does not necessarily make sense. At the time of writing, IIRC, the major target of this was cell phones.</div><div class=""><br class=""></div><div class="">Residential end users remained controversial throughout the discussion and there was never a consensus reached (one of the main reasons 6177 uses so much weasel wording) for longer prefix assignments to residential end sites.</div></div><blockquote type="cite" class=""><div class=""><div class=""><p class="">Given all above I cannot agree and have the same view that /48 to
residential customers indistinctly is a normal thing and that RIRs
should necessarily adapt to allow ISPs to make these assignments
the way is being suggested in this discussion.</p></div></div></blockquote>I’m sorry, I cannot parse your actual intent from this statement. Can you try rewording it?</div><div><br class=""></div><div>Section 2 basically states that if you ignore the goals of automated hierarchy, you can fudge home sites down to /56 and still meat the remaining goals. It narrowly interprets RFC3177 and ignores any use cases not previously documented in that RFC.</div><div><br class=""></div><div>Section 4.1 all but admits that any site using RFC3056 addressing and sparse allocation (also recommended back then and still good practice today) would potentially be negatively impacted by longer assignments.</div><div><br class=""></div><div>Section 5 is worth a read, tooo.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><span style="font-size: 13.333333015441895px;" class="">- Although a /64 can (in theory) address an almost unlimited</span></div><pre class="newpage" style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px; break-before: page;"> number of devices, sites should be given sufficient address
space to be able to lay out subnets as appropriate, and not be
forced to use address conservation techniques such as using
bridging. Whether or not bridging is an appropriate choice is
an end site matter.
- assigning a longer prefix to an end site, compared with the
existing prefixes the end site already has assigned to it, is
likely to increase operational costs and complexity for the end
site, with insufficient benefit to anyone.</pre><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px; break-before: page;"> - the operational considerations of managing and delegating the
reverse DNS tree under ip6.arpa on nibble versus non-nibble
boundaries should be given adequate consideration.
</pre></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Admittedly, these don’t argue specifically for /48 (except possibly the middle one when it comes to customers moving from ISPs that do give out /48s to ISPs that don’t).</div><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><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div></body></html>