We're doing /56 to customers. /60 if they want dynamic. Yes they get less space if they want to change their ip.<div><br></div><div>I like Jason's suggestion. </div><div><br></div><div>Leave /29 alone.</div><div><br>Aaron</div><div><br></div><div><br>On Wednesday, May 31, 2017, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">WRT IPv6 can we solve this by requiring all fixed IPv6 customers <div>(still allowing residential privacy) to SWIP, and allow dynamic </div><div>customers up to (and including) /56 to only SWIP the parent </div><div>block to the residential market?</div><div><br></div><div>We would need someone to come up with a usable definition</div><div>of fixed and dynamic...</div><div><br></div><div>Any statically routed network is considered fixed.</div><div><br></div><div>Any network announced by a customer to a provider</div><div>via a routing protocol is considered fixed.</div><div><br></div><div>Any network provided by a provider to a customer</div><div>with the expectation that the address will not change</div><div>is considered fixed (even if dynamic mechanisms are</div><div>used to provide the address) </div><div>[excluding re-terminations and divestitures]</div><div><br></div><div><div>Any network with a customer specified ip6.arpa address<br></div></div><div>is considered fixed.</div><div><br></div><div>Only networks provided by a dynamic mechanism such as<br>DHCPv6 with a sufficiently short lease such as 1 year or less</div><div>and no customer expectation that the address will persist if</div><div>the lease times out may be considered dynamic. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 30, 2017 at 9:41 AM, William Herrin <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','bill@herrin.us');" target="_blank">bill@herrin.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','oroberts@bell.ca');" target="_blank">oroberts@bell.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical.<br>
<br>
Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos.<br>
<br>
With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped.<br>
<br>
That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage.<br></blockquote><div><br></div></span><div>Howdy,<br><br></div><div>I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO.<br><br></div><div>Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong.<br></div></div><br></div><span><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Bill Herrin<br><br clear="all"></div><div class="gmail_extra"><br>-- <br><div data-smartmail="gmail_signature">William Herrin ................ <a href="javascript:_e(%7B%7D,'cvml','herrin@dirtside.com');" target="_blank">herrin@dirtside.com</a> <a href="javascript:_e(%7B%7D,'cvml','bill@herrin.us');" target="_blank">bill@herrin.us</a><br>Dirtside Systems ......... Web: <<a href="http://www.dirtside.com/" target="_blank">http://www.dirtside.com/</a>></div>
</div></span></div>
<br>______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="javascript:_e(%7B%7D,'cvml','ARIN-PPML@arin.net');" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="javascript:_e(%7B%7D,'cvml','info@arin.net');" target="_blank">info@arin.net</a> if you experience any issues.<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">______________________________<wbr>_________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="javascript:_e(%7B%7D,'cvml','jschiller@google.com');" target="_blank">jschiller@<wbr>google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>
</blockquote></div>