<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Eric - </div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The distinction between LIR and End-User remains only for the purposes of justifying allocations. After ARIN harmonized the fee structure a few years ago, everyone pays the same regardless of how they got their allocation (this was different under the prior
schedules.) </div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I would agree that merging those justification criteria is a worthy goal as a policy objective but wanted to note that it won’t have a material impact on the financial result. Your email doesn’t state fees as an objective, but I think the history and impact
are worth noting for the conversation. </div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Doug</div>
<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="ms-outlook-mobile-signature">
<div class="MsoNormal">--</div>
<div class="MsoNormal">Douglas J. Camin</div>
<div class="MsoNormal">doug@dougcamin.com</div>
</div>
<div id="mail-editor-reference-message-container">
<div class="ms-outlook-mobile-reference-message skipProofing">
<meta name="Generator" content="Microsoft Exchange Server">
</div>
<div style="padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;">
<div class="ms-outlook-mobile-reference-message skipProofing" style="text-align: left; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>ARIN-PPML <arin-ppml-bounces@arin.net> on behalf of Eric C. Landgraf <echarlie@vt.edu><br>
<b>Date: </b>Friday, June 26, 2026 at 4:40 PM<br>
<b>To: </b>arin-ppml@arin.net <arin-ppml@arin.net><br>
<b>Subject: </b>Re: [arin-ppml] IPv6 policy: merge ISP and end-user?<br>
<br>
</div>
</div>
<div class="PlainText" style="font-size: 11pt;">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 (ARIN-PPML@arin.net).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" data-outlook-id="50c9ddf4-627e-4ad6-9925-5140bf4908a1">
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=05%7C02%7C%7C65e40d7327cf4bda7b6508ded3c315b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639181032004840007%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P3eZoB%2Bw00RHgJEqXnHr6NbLBFhvEEvunF8i8Sny0h4%3D&reserved=0</a><br>
> Please contact info@arin.net 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 (ARIN-PPML@arin.net).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" data-outlook-id="89193286-0435-4a15-bd2c-19670e83607e">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=05%7C02%7C%7C65e40d7327cf4bda7b6508ded3c315b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639181032004856457%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WJ0gyoYQ%2BoH9Hr55TLuW64xlgdYXIZG%2BEnTuoRgSpvc%3D&reserved=0</a><br>
Please contact info@arin.net if you experience any issues.<br>
</div>
</div>
</body>
</html>