[arin-ppml] Draft Policy ARIN-2024-8: Restrict the Largest Initial IPv6 Allocation to /20

[David Farmer]

Sorry, that was  ARIN-2010-12.

On Thu, Jun 27, 2024 at 3:41 PM David Farmer <farmer at umn.edu> wrote:

> 6RD is a red herring, ARIN-2010-2 capped justifications for transition
> technology (6RD) at /24, in 6.5.3.1.
>
> 6.5.3.1. Subsequent Allocations for Transition
> Subsequent allocations will also be considered for deployments that cannot
> be accommodated by, nor were accounted for, under the initial allocation.
> Justification for the subsequent subnet size will be based on the plan and
> technology provided with a /24 being the maximum allowed for a transition
> technology. Justification for transitional allocations will be reviewed
> every 3 years and reclaimed if they are no longer in use for transitional
> purposes. All such allocations for transitional technology will be made
> from a block designated for this purpose.
>
> Thanks
>
> On Thu, Jun 27, 2024 at 3:00 PM Mark Andrews <marka at isc.org> wrote:
>
>> Well that looks like an area of policy that needs to be tightened.
>>
>> I dislike IETF’s advice to use 32 bits with /64s and 6rd as there is an
>> incredible amount of wastage.  For /48s its insane wastage.
>>
>> Even with the disjointed GUA IPv4 address assignments ISPs tend to only
>> have addresses in a few /8s.  6rd can be trivially configured to have a
>> prefix per /8 using 24 bits rather than 32 bits and there would be a small
>> multiple if /24s of IPv6 space used rather than a /16.   Yes the border
>> router would have a slightly more complex configuration if you have
>> multiple pops in multiple /8s using it.
>>
>> If you are not using GUAs then you don’t need to use 32 bits as there is
>> no benefit in making it that big as it can’t simplify anything.  10/8 24
>> bits is the biggest you would go. 100.64/10 is 22 bits.  These are maximum
>> sizes.  You need different IPv6 prefixes per instance anyway.
>>
>> --
>> Mark Andrews
>>
>> > On 28 Jun 2024, at 05:19, William Herrin <bill at herrin.us> wrote:
>> >
>> > On Thu, Jun 27, 2024 at 12:14 PM Mark Andrews <marka at isc.org> wrote:
>> >> I would argue that it is not needed for 6rd as you can pack
>> >> things much denser with proper 6rd parameter management.
>> >
>> > Hi Mark,
>> >
>> > Of course it isn't needed for 6rd. That's not the question. The
>> > question is: does such use technically justify addresses under current
>> > ARIN policy? The answer, as I understand it, is: yes. If I happen to
>> > have a couple dozen disjoint IPv4 allocations and I want to simplify
>> > my 6rd deployment by throwing addresses at it, I have met the
>> > requirements for an ARIN IPv6 allocation that throws 32 bits at 6rd.
>> >
>> > Regards,
>> > Bill Herrin
>> >
>> > --
>> > William Herrin
>> > bill at herrin.us
>> > https://bill.herrin.us/
>>
>> _______________________________________________
>> 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://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240627/38d03497/attachment.htm>