<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Based on William’s logic below, I would advocate for 49.<div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 19, 2017, at 8:05 PM, William Herrin <<a href="mailto:bill@herrin.us" class="">bill@herrin.us</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Mon, Jun 19, 2017 at 1:37 PM, David R Huberman <span dir="ltr" class=""><<a href="mailto:daveid@panix.com" target="_blank" class="">daveid@panix.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Based on comments so far, most agree that a /48 should be SWIP'ed since it is routable on the internet, and since so far the majority seems to think that /56 is small enough to not require SWIP, this leaves 7 choices of /49 to /55 to set the limit for SWIP in the Draft.<br class="">
</blockquote>
<br class=""></span>
I think that when we consider SWIP boundaries, we should take into account strictly technical considerations, and not arbitrary ones. I think the argument for requiring a /48 or larger to be SWIPed is well-grounded in network engineering practices. I'm not sure I understand the technical argument for anything smaller than a /48 being mandatory.<br class=""></blockquote><div class=""><br class=""></div><div class="">Hi David,</div><div class=""><br class=""></div><div class="">The obvious technical argument against Nibble "or larger" is that it encourages assignment on non-niblle boundaries. If /56 requires SWIP, the ISP has reason to assign /57 instead of /56. That makes IPv6 assignment as messy as IPv4. If instead /55 requires SWIP, the likely ISP default value becomes /56, a good nibble-boundary choice. A policy which starts requiring SWIP at Nibble+1 implicitly encourages the ISP to set their default assignment size at a nibble boundary which is well-grounded in network engineering practices</div><div class=""><br class=""></div><div class="">So first and foremost it is technologically correct to set the SWIP boundary to start at "larger than Nibble" or "Nibble+1 or larger." </div><div class=""><br class=""></div><div class="">Since "larger than /48" and "/47 or larger" are ruled out by /48's independent routability (also a technical consideration) and /64 is ruled out for preventing the intended end-user IPv6 routing ability (also a technical consideration), that leaves "larger than" /52, /56 and /60 as the only -technically reasonable- options. </div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Bill Herrin</div><div class=""><br class=""></div><div class=""><br class=""></div></div>-- <br class=""><div class="gmail_signature">William Herrin ................ <a href="mailto:herrin@dirtside.com" target="_blank" class="">herrin@dirtside.com</a> <a href="mailto:bill@herrin.us" target="_blank" class="">bill@herrin.us</a><br class="">Dirtside Systems ......... Web: <<a href="http://www.dirtside.com/" target="_blank" class="">http://www.dirtside.com/</a>></div>
</div></div>
_______________________________________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.</div></blockquote></div><br class=""></div></body></html>