[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

David Farmer farmer at umn.edu
Fri Jul 14 17:57:35 EDT 2017


Rather than base it on the criteria of business vs. residential customer,
how about simply basing it on the criteria, is the assignment intended to
be or is used within the global routing system or not, or if the customer
requests their assignment be SWIPed.  Most residential assignments be they
/56 or /48 won't be in the global routing system, neither will many
business assignments either, after that then an assignment is only SWIPed
if the customer requests it.

My reasoning for wanting to have /48s SWIPed isn't based on business vs
residential customer type, which has a fuzzy definition sometimes anyway.
Its that /48s might appear in the routing table. So just make that the
criteria in the first place, if we are not going to based it on a specific
size like we did in IPv4.  Also, then any policy violations become easily
apparent. If an ISP doesn't SWIP some of there business customers, how are
you going to know anyway?  However, if a route is in the route table and
there is no SWIP that is fairly self apparent.

Thanks.

On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain <alh-ietf at tndh.net> wrote:

> Bill,
>
>
>
> To avoid the situation of Owen being a lone voice, I have to echo his
> point that it is insane that people persist with IPv4-think and extreme
> conservation. Allocations longer than a /48 to a residence ensure that
> automated topology configuration can’t happen, because /52’s won’t happen
> and /56’s are too long for random consumer plug-n-play. Therefore a policy
> that /48’s must be swiped ensures that we maintain single subnet consumer
> networks. A policy that says /48’s might be swiped (will in a business and
> not in a non-residential case) does not reinforce the braindead notion that
> longer than /48 has some special meaning beyond the need to kill off a
> generation of those with the ‘addresses are a scarce resource’ mindset.
>
>
>
> Tony
>
>
>
>
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *William
> Herrin
> *Sent:* Thursday, July 13, 2017 3:12 PM
> *To:* Owen DeLong
> *Cc:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of
> Assignment Registration requirements between IPv4 and IPv6
>
>
>
> On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong <owen at delong.com> wrote:
>
> Consensus hasn’t yet been reached. I agree that there is significant
> support for “shorter than /56” actually (not /56 itself). Nonetheless, I
> don’t believe that shorter than /56 is the ideal place to put the boundary.
>
>
>
> Hi Owen,
>
>
>
> I think you're an outlier here. I see consensus that /48 should be swiped
> and /56 should not. If there's debate that /52 or /49 should also not be
> swiped or that a some more subtle criteria should determine what's swiped,
> it's not exactly chewing up bandwidth on the mailing list.
>
>
>
> Regards,
>
> Bill Herrin
>
>
>
>
>
> --
>
> William Herrin ................ herrin at dirtside.com  bill at herrin.us
> Dirtside Systems ......... Web: <http://www.dirtside.com/>
>
> _______________________________________________
> 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:
> http://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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170714/c4b52f7d/attachment.htm>


More information about the ARIN-PPML mailing list