[arin-ppml] IPv6 policy: merge ISP and end-user?

[John W. O'Brien]

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 (ARIN-PPML at arin.net).
>> 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 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://urldefense.com/v3/__https://lists.arin.net/mailman/listinfo/arin-ppml__;!!IBzWLUs!TAwWfTcXKgl7Wm6AcFxSMyMSnE8vZwgptJ_8PxNCKmENBut4mqROUdU43ASvA81XeNh5x3eyU2jKxTy2HGk$
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260628/5ac446df/attachment.sig>