> On Apr 13, 2020, at 08:55 , Andrew Dul <andrew....@quark.net> wrote: > > David, Thanks for your comments. > > On 3/26/2020 4:08 PM, David Farmer wrote: >> I support this policy as written. >> >> However, I recommend a minor editorial change and a small change to the >> policy; >> >> 1. I would prefer to not use "smaller" or "less" when referring to /24 or >> longer prefixes, such use is somewhat ambiguous, this has been discussed >> many times on PPML. > Noted. >> >> 2. I really like the idea of automatically increasing the IPv6 allocation to >> /36 when the IPv4 allocation increases beyond /24. How about also >> automatically increasing the IPv6 allocation to /32 when the IPv4 allocation >> increases beyond /22? > The goal of this policy is to create IPv6 allocation sizes such that a > current IPv4 organization which is currently 3X-small can obtain an IPv6 > allocation without their fees going up. Today this issue only occurs with > 3x-small. If we were to implement this other change I believe this would > cause the text to move beyond the current problem statement. >
I don’t entirely agree. The goal of the /36 policy was very similar to the goal here for /40s. Prior to the implementation of the /36 policy, the situation was similar. As such, I do think it makes sense to extend the auto-bump language up to /32 as part of this policy. TBH, the only reason it isn’t already there for /36s IMHO is that we didn’t think of it at the time. > I will also like to note, that this issue could also be remedied by the board > adopting a small change to the fee schedule such that the 3x-small IPv6 > holdings do not force a change in category for 3x-small organizations. This > would cause 3x-small organization's fees to be primarily determined by their > IPv4 holdings not their IPv6 holdings. > Yep… And I hope they’ll finally do something about this, but let’s see what happens. I think this policy proposal is a good backstop to that. > While the community doesn't have purview over fees we have input into that > process. If this is something that we would strongly like to prefer as a > solution to this problem. We can make this as a strong suggestion to the > board for their consideration. > I believe this has been communicated to the board on more than one occasion. Owen > Andrew > > > >> >> Thanks >> >> On Tue, Mar 24, 2020 at 12:22 PM ARIN <i...@arin.net <mailto:i...@arin.net>> >> wrote: >> Draft Policy ARIN-2020-3: IPv6 Nano-allocations >> >> Problem Statement: >> >> ARIN's fee structure provides a graduated system wherein organizations >> pay based on the amount of number resources they consume. >> >> In the case of the very smallest ISPs, if a 3X-Small ISP (with a /24 or >> smaller of IPv4) gets the present minimal-sized IPv6 allocation (a /36), >> its annual fees will double from $250 to $500/year. >> >> According to a Policy Experience Report presented by Registration >> Services to the AC at its annual workshop in January 2020, this >> represents a disincentive to IPv6 adoption with a substantial fraction >> of so-situated ISPs saying "no thanks" and abandoning their request for >> IPv6 number resources when informed of the impact on their annual fees. >> >> This can be addressed by rewriting subsection 6.5.2(b). Initial >> Allocation Size to allow allocation of a /40 to only the smallest ISPs >> upon request, and adding a new clause 6.5.2(g) to cause an automatic >> upgrade to at least a /36 in the case where the ISP is no longer 3X-Small. >> >> Reserving /40s only for organizations initially expanding into IPv6 from >> an initial sliver of IPv4 space will help to narrowly address the >> problem observed by Registration Services while avoiding unintended >> consequences by accidentally giving a discount for undersized allocations. >> >> Policy Statement: >> >> Replace the current 6.5.2(b) with the following: >> >> b. In no case shall an LIR receive smaller than a /32 unless they >> specifically request a /36 or /40. >> >> In order to be eligible for a /40, an ISP must meet the following >> requirements: >> * Hold IPv4 direct allocations totaling a /24 or less (to include zero) >> * Hold IPv4 reassignments/reallocations totaling a /22 or less (to >> include zero) >> >> In no case shall an ISP receive more than a /16 initial allocation. >> >> Add 6.5.2(g) as follows: >> >> g. An LIR that requests a smaller /36 or /40 allocation is entitled to >> expand the allocation to any nibble aligned size up to /32 at any time >> without renumbering or additional justification. /40 allocations shall >> be automatically upgraded to /36 if at any time said LIR's IPv4 direct >> allocations exceed a /24. Expansions up to and including a /32 are not >> considered subsequent allocations, however any expansions beyond /32 are >> considered subsequent allocations and must conform to section 6.5.3. >> Downgrades of any IPv6 allocation to less than a /36 are not permitted >> regardless of the ISP's current or former IPv4 number resource holdings. >> >> Comments: >> >> The intent of this policy proposal is to make IPv6 adoption at the very >> bottom end expense-neutral for the ISP and revenue-neutral for ARIN. The >> author looks forward to a future era wherein IPv6 is the dominant >> technology and IPv4 is well in decline and considered optional leading >> the Community to conclude that sunsetting this policy is prudent in the >> interests of avoiding an incentive to request undersized IPv6 allocations. >> >> Timetable for implementation: Immediate >> >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net >> <mailto:ARIN-PPML@arin.net>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> <https://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any >> issues. >> >> >> -- >> =============================================== >> David Farmer Email:far...@umn.edu >> <mailto:email%3afar...@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 >> =============================================== >> >> >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net >> <mailto:ARIN-PPML@arin.net>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> <https://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact i...@arin.net <mailto:i...@arin.net> if you experience any >> issues. > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
