<div dir="auto">If LIR and end-user effectively becomes one and the same: what's that mean for someone at home asking for a PIA /24 v4 block?</div><div dir="auto"><br></div><div dir="auto">For v6, I see no problem of course. But v4? Would we want a seperate ISP/End-user policy per-AFI?</div><div><br clear="all"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Sent from my iPhone</div></div></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, 27 Jun 2026 at 2:09 AM, Eric C. Landgraf <<a href="mailto:echarlie@vt.edu">echarlie@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like to see the LIR and end-user provisions nearly merged. A<br>
large university like my own organization happens to sit in that grey<br>
area where it looks like an LIR or an end-user, depending on the<br>
meterstick you use. I would much prefer that organizations just have to<br>
justify how much space they intend to use, and justify that they should<br>
get space---obviously your average home-user doesn't need PI space.<br>
<br>
There are still many ambiguities for large campuses starting on their<br>
IPv6 journey: what is a "serving site" and how to create a reasonable<br>
network plan that allows aggregation. We don't need them also asking "Am<br>
I an LIR?"<br>
<br>
Eric C. Landgraf<br>
Virginia Tech<br>
<br>
On Jun 25 14:46, William Herrin wrote:<br>
> Howdy,<br>
> <br>
> I didn't see any feedback on the draft policy rewriting section 6.5,<br>
> so I want to step back and solicit your opinions on what ARIN's IPv6<br>
> policies should become. I'm going to ask some questions and break them<br>
> into separate message threads so that they can be followed separately<br>
> according to your interest.<br>
> <br>
> <br>
> The question for this thread is: Should we attempt to merge ISP and<br>
> end-user IPv6 address allocation policy?<br>
> <br>
> <br>
> Traditionally, long ago when the InterNIC Hostmaster ran IPv4 address<br>
> allocation, there was no distinction between ISPs and end users. If<br>
> you wanted IP addresses, you got them. If you wanted a lot of IP<br>
> addresses you had to explain why. Being an ISP was a good reason.<br>
> There were a number of other good reasons. There was no specific<br>
> category for ISPs.<br>
> <br>
> Around the time the InterNIC was divided up into ICANN and the RIRs,<br>
> there was another important event in Internet history: the EGP routing<br>
> table crisis. With the sudden public interest in the Internet in the<br>
> mid-'90s and the corresponding explosive growth, we nearly exhausted<br>
> the capacity of the backbone routing table. Through a heroic effort of<br>
> the standards bodies and the software and hardware developers at the<br>
> router vendors, we replaced Classful routing with CIDR and EGP with<br>
> BGP, averting the crisis with literally weeks to spare.<br>
> <br>
> Coming out of the crisis, the smart people in the know said: Never<br>
> again. We're going to give large IP address blocks to ISPs who will<br>
> consume one slot in the BGP table. To the maximum extent practical,<br>
> end users aren't going to have their own routes in the BGP table.<br>
> <br>
> This division between haves and have-nots was embedded deeply into<br>
> every RIR's address allocation policy.<br>
> <br>
> The last quarter century has been a slow but steady retreat from that<br>
> position. Efficient use of /19 became /20 and then dragged all the way<br>
> back to the original class C, /24 limit where we are today. No one<br>
> ever developed a satisfactory replacement for BGP multihoming, not<br>
> even with IPv6. And slicing a /24 out of ISP space for an end-user to<br>
> multihome turns out to have problems if you don't also disaggregate<br>
> the entire larger block in BGP. Which is a bad thing. So BGP<br>
> multihoming has become re-recognized as a proper reason for end users<br>
> to have their own IP addresses from ARIN. Even the ARIN fee schedule<br>
> and membership rights have been unified. The major remaining vestige<br>
> of the original division between ISP and end-user is the requirement<br>
> for ISPs to report their customer registrations with SWIP and their<br>
> ability to record those registrations as in-use. End-users<br>
> theoretically don't have downstream customer registrations to report<br>
> or record.<br>
> <br>
> This presents an opportunity. As we look at replacing the thick<br>
> language in the IPv6 policies, we can try to make the policy uniform:<br>
> the same fair policy for everybody, end users and ISPs both.<br>
> <br>
> What do you think? Would you like to take a stab at it, or do you<br>
> prefer that the ISP/end user division stay where it is? Your views are<br>
> respectfully requested.<br>
> <br>
> Regards,<br>
> Bill Herrin<br>
> _______________________________________________<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" target="_blank">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" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
_______________________________________________<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" target="_blank">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" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div><span><span style="display:none"><img src="https://mailtrack.io/trace/mail/9919c18d5054ae5edae48ddb4c6e86ec3091d41e.png?u=2153471&isAddon=1" alt="9919c18d5054ae5edae48ddb4c6e86ec3091d41e"></span></span>