We're doing /56 to customers. /60 if they want dynamic. Yes they get less space if they want to change their ip.
I like Jason's suggestion. Leave /29 alone. Aaron On Wednesday, May 31, 2017, Jason Schiller <[email protected]> wrote: > WRT IPv6 can we solve this by requiring all fixed IPv6 customers > (still allowing residential privacy) to SWIP, and allow dynamic > customers up to (and including) /56 to only SWIP the parent > block to the residential market? > > We would need someone to come up with a usable definition > of fixed and dynamic... > > Any statically routed network is considered fixed. > > Any network announced by a customer to a provider > via a routing protocol is considered fixed. > > Any network provided by a provider to a customer > with the expectation that the address will not change > is considered fixed (even if dynamic mechanisms are > used to provide the address) > [excluding re-terminations and divestitures] > > Any network with a customer specified ip6.arpa address > is considered fixed. > > Only networks provided by a dynamic mechanism such as > DHCPv6 with a sufficiently short lease such as 1 year or less > and no customer expectation that the address will persist if > the lease times out may be considered dynamic. > > On Tue, May 30, 2017 at 9:41 AM, William Herrin <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> Hello all, >>> >>> I am avidly following this discussion and based on my daily observances >>> (daily swips /subnets ), I would say Andy is closest to being practical. >>> >>> 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. >>> >>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that >>> requests a /56 OR LARGER NETWORK assignment be swiped. >>> >>> That would still leave /60 to /64 assignments as minimum assignment or >>> for dynamic usage for either residential or other usage. >>> >> >> Howdy, >> >> 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. >> >> 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. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin ................ [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> >> Dirtside Systems ......... Web: <http://www.dirtside.com/> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');> if you experience any >> issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>|571-266-0006 > >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
