I agree with Eric.
On 2026-06-26 16:39, Eric C. Landgraf wrote:
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 ([email protected]). Unsubscribe or manage your mailing list subscription at: https://urldefense.com/v3/__https://lists.arin.net/mailman/listinfo/arin-ppml__;!!IBzWLUs!TAwWfTcXKgl7Wm6AcFxSMyMSnE8vZwgptJ_8PxNCKmENBut4mqROUdU43ASvA81XeNh5x3eyU2jKxTy2HGk$ Please contact [email protected] if you experience any issues._______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://urldefense.com/v3/__https://lists.arin.net/mailman/listinfo/arin-ppml__;!!IBzWLUs!TAwWfTcXKgl7Wm6AcFxSMyMSnE8vZwgptJ_8PxNCKmENBut4mqROUdU43ASvA81XeNh5x3eyU2jKxTy2HGk$ Please contact [email protected] if you experience any issues.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
