<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On Jan 5, 2023, at 08:45, David Conrad <drc@virtualized.org> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On Jan 4, 2023, at 5:18 PM, William Herrin <bill@herrin.us> wrote:<div><blockquote type="cite"><div><div>On Wed, Jan 4, 2023 at 5:10 PM David Conrad <drc@virtualized.org> wrote:<br><blockquote type="cite">On Jan 4, 2023, at 2:32 PM, William Herrin <bill@herrin.us> wrote:<br><blockquote type="cite">However, since /48 is also the minimum Internet routable size,</blockquote>Sorry, what?  Out of 172,457 IPv6 prefixes seen at AMSIX (according to routeviews) on 2023-01-01, counts of prefixes longer than 48:</blockquote>Sorry, I didn't realize I'd be called out for insufficient pedantry.<br></div></div></blockquote><div><br></div>You’re aware you’re on the Internet, right?</div><div><br><blockquote type="cite"><div><div>The minimum IPv6 size _ubiquitously accepted_ into folks' Internet BGP<br>tables is /48. As with IPv4's /24 boundary, some folks accept longer<br>prefixes. As with IPv4, -some- is not enough.<br></div></div></blockquote></div><br><div>“Ubiquitous".  Like /24 in IPv4 was ubiquitous until Sprint (the 800 lbs gorilla at the time) started filtering at /19? The point being that arbitrary boundaries are overly simplistic: there aren’t hard rules here, only local policy.  But you know this.</div></div></div></blockquote><div><br></div>SPRINT’s attempt to filter at /19 lasted, what, a few months before they were forced to back down?</div><div><br></div><div>The /24 arbitrary boundary has pretty well stood the test of time as, I suspect, will the /48.</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br></div><div>Anyhow, back to the original question:</div><div><br><div><span style="caret-color: rgb(0, 0, 0);">On Wed, Jan 4, 2023 at 11:52 AM Fernando Frediani <</span><a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a><span style="caret-color: rgb(0, 0, 0);">> wrote:</span><br style="caret-color: rgb(0, 0, 0);"></div><blockquote type="cite"><p style="caret-color: rgb(0, 0, 0);">I always found a bit strange (not only in ARIN) to have this distinction between ISP and End-user. In practice things should not differ much. Only thing that would possible remain slightly different are the details of justifications that must be provided and the size of the block to be allocated.</p></blockquote>In practice, ISPs tend to grow much more and more quickly than end user networks.<br><blockquote type="cite"><p style="caret-color: rgb(0, 0, 0);">Another thing that I wanted to understand better is the reasoning to allocate a significant smaller IPv6 block to a said end-user organization given it is not so scarce resource. At least a /40 should be minimal default for an end-user (not a /48) and a /32 for any size of ISP. </p></blockquote>You might want to look at RFC 6177.<br></div></div></div></blockquote><div><br></div>I think a /48 per site is a perfectly reasonable basis for assignments. There may be sties that need more, but they are likely to be few and far between and there are procedures to take care of them. Note: Many end users are multiple sites. An end site is defined (IIRC from what I wrote when authoring the ARIN policies that are still in effect to the best of my knowledge):</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>A single building or structure or a single tenant in a multi-tenant building or structure.</div><div><br></div><div>If that’s not the exact correct wording, it’s close and mirrors the intended meaning.</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><blockquote type="cite"><p style="caret-color: rgb(0, 0, 0);">For now my personal impression is to create some artificial scarcity in order to have different levels of Service Category.</p></blockquote></div><div>Never attribute to malice what can be more easily explained by inertia.</div></div></div></blockquote><div><br></div>I once had this discussion with John Brzowski of Comcast. His excuse was “If we gave everyone /48s, the way our network is structured, we’d have to ask ARIN for a /12. He felt this was a reason not to. I wondered why. I never got an answer.</div><div><br></div><div>So I would say never attribute to malice that which can be easily explained by lack of imagination.</div><div><br></div><div>Owen</div><br></body></html>