<div dir="ltr"><div>6RD is a red herring, ARIN-2010-2 capped justifications for transition technology (6RD) at /24, in 6.5.3.1. </div><div><br></div><div>6.5.3.1. Subsequent Allocations for Transition<br>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.<br></div><div><br></div><div>Thanks</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 27, 2024 at 3:00 PM Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well that looks like an area of policy that needs to be tightened. <br>
<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
-- <br>
Mark Andrews<br>
<br>
> On 28 Jun 2024, at 05:19, William Herrin <<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>> wrote:<br>
> <br>
> On Thu, Jun 27, 2024 at 12:14 PM Mark Andrews <<a href="mailto:marka@isc.org" target="_blank">marka@isc.org</a>> wrote:<br>
>> I would argue that it is not needed for 6rd as you can pack<br>
>> things much denser with proper 6rd parameter management.<br>
> <br>
> Hi Mark,<br>
> <br>
> Of course it isn't needed for 6rd. That's not the question. The<br>
> question is: does such use technically justify addresses under current<br>
> ARIN policy? The answer, as I understand it, is: yes. If I happen to<br>
> have a couple dozen disjoint IPv4 allocations and I want to simplify<br>
> my 6rd deployment by throwing addresses at it, I have met the<br>
> requirements for an ARIN IPv6 allocation that throws 32 bits at 6rd.<br>
> <br>
> Regards,<br>
> Bill Herrin<br>
> <br>
> -- <br>
> William Herrin<br>
> <a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a><br>
> <a href="https://bill.herrin.us/" rel="noreferrer" target="_blank">https://bill.herrin.us/</a><br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer               <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota   <br>2218 University Ave SE        Phone: 612-626-0815<br>Minneapolis, MN 55414-3029   Cell: 612-812-9952<br>=============================================== </div></div>