From doug at dougcamin.com Wed Jul 1 07:54:33 2026 From: doug at dougcamin.com (Douglas Camin) Date: Wed, 1 Jul 2026 11:54:33 +0000 Subject: [arin-ppml] IPv6 policy: merge ISP and end-user? In-Reply-To: <20260626203946.rswljxvtnusvf6tu@bicycle> References: <20260626203946.rswljxvtnusvf6tu@bicycle> Message-ID: Eric - 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.) 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. Doug -- Douglas J. Camin doug at dougcamin.com From: ARIN-PPML on behalf of Eric C. Landgraf Date: Friday, June 26, 2026 at 4:40?PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] IPv6 policy: merge ISP and end-user? I would like to see the LIR and end-user provisions nearly merged. A large university like my own organization happens to sit in that grey area where it looks like an LIR or an end-user, depending on the meterstick you use. I would much prefer that organizations just have to justify how much space they intend to use, and justify that they should get space---obviously your average home-user doesn't need PI space. There are still many ambiguities for large campuses starting on their IPv6 journey: what is a "serving site" and how to create a reasonable network plan that allows aggregation. We don't need them also asking "Am I an LIR?" Eric C. Landgraf Virginia Tech On Jun 25 14:46, William Herrin wrote: > Howdy, > > I didn't see any feedback on the draft policy rewriting section 6.5, > so I want to step back and solicit your opinions on what ARIN's IPv6 > policies should become. I'm going to ask some questions and break them > into separate message threads so that they can be followed separately > according to your interest. > > > The question for this thread is: Should we attempt to merge ISP and > end-user IPv6 address allocation policy? > > > Traditionally, long ago when the InterNIC Hostmaster ran IPv4 address > allocation, there was no distinction between ISPs and end users. If > you wanted IP addresses, you got them. If you wanted a lot of IP > addresses you had to explain why. Being an ISP was a good reason. > There were a number of other good reasons. There was no specific > category for ISPs. > > Around the time the InterNIC was divided up into ICANN and the RIRs, > there was another important event in Internet history: the EGP routing > table crisis. With the sudden public interest in the Internet in the > mid-'90s and the corresponding explosive growth, we nearly exhausted > the capacity of the backbone routing table. Through a heroic effort of > the standards bodies and the software and hardware developers at the > router vendors, we replaced Classful routing with CIDR and EGP with > BGP, averting the crisis with literally weeks to spare. > > Coming out of the crisis, the smart people in the know said: Never > again. We're going to give large IP address blocks to ISPs who will > consume one slot in the BGP table. To the maximum extent practical, > end users aren't going to have their own routes in the BGP table. > > This division between haves and have-nots was embedded deeply into > every RIR's address allocation policy. > > The last quarter century has been a slow but steady retreat from that > position. Efficient use of /19 became /20 and then dragged all the way > back to the original class C, /24 limit where we are today. No one > ever developed a satisfactory replacement for BGP multihoming, not > even with IPv6. And slicing a /24 out of ISP space for an end-user to > multihome turns out to have problems if you don't also disaggregate > the entire larger block in BGP. Which is a bad thing. So BGP > multihoming has become re-recognized as a proper reason for end users > to have their own IP addresses from ARIN. Even the ARIN fee schedule > and membership rights have been unified. The major remaining vestige > of the original division between ISP and end-user is the requirement > for ISPs to report their customer registrations with SWIP and their > ability to record those registrations as in-use. End-users > theoretically don't have downstream customer registrations to report > or record. > > This presents an opportunity. As we look at replacing the thick > language in the IPv6 policies, we can try to make the policy uniform: > the same fair policy for everybody, end users and ISPs both. > > What do you think? Would you like to take a stab at it, or do you > prefer that the ISP/end user division stay where it is? Your views are > respectfully requested. > > Regards, > Bill Herrin > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > 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 > Please contact info at arin.net if you experience any issues. _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: 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 Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: