> On Jul 17, 2017, at 16:36 , John Curran <jcur...@arin.net> wrote: > > Albert - > > We’ll research into these questions and report back shortly. > > Thanks! > /John > >> On 17 Jul 2017, at 2:53 PM, hostmas...@uneedus.com wrote: >> >> Just a couple of questions regarding the carrots and the sticks for the ARIN >> staff: >> >> Other than those who came back to change their initial /35 to a /32, how >> many ARIN customers have come back for another allocation of IPv6 space >> because they used the first one to the extent the rules require, which I >> think is 75% of /48 block assignments.
Not many…. Yet. I know a few years ago, I filed the first such application (or at least so said RSHD at the time) on behalf of my employer at the time (HE) which requested (and received) a subsequent /24 to augment their existing /32 which was, in fact, more than 75% utilized. >> And, how many customers have received a first allocation of IPv6? >> >> Divide, and I can find out what percentage came back for more. The problem with this theory is that IPv6 is just getting started and the vast majority of ARIN customers that have received an initial IPv6 allocation or assignment haven’t yet achieved full IPv6 deployment even to the point of parity with their IPv4 deployment. As such, measurements to date will be badly skewed to the low side of future reality. >> What I would like to know is my gut feeling correct, which is that after >> receiving an allocation of IPv6, nearly nobody ever returns to the well for >> more, or at least not like it was back in the IPv4 days when ARIN had IPv4 >> address space to allocate, and thus there are no sticks? Your gut is definitely correct to date. However, prior performance does not predict future results. It’s true that a lot fewer organizations are likely to come back for additional IPv6 blocks and all will certainly come back less frequently than in IPv4. Nearly nobody is probably true today. It will probably remain less than “most” for the foreseeable future, but I don’t think “nearly nobody” is a permanent state. >> Another bit of info I would like to know if possible: what percentage of >> customers with a v6 allocation has actually put any of their assignments >> into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every >> allocation should be there. Again, this isn’t necessarily going to yield accurate results. Many providers use RWHOIS as an alternative to SWIP. Many end users receive a /48 and it is directly registered by ARIN, so nothing to SWIP. There are also other situations (dynamic assignments, etc.) that are legitimately unlikely to result in SWIP. >> The answers are useful to determine as far as the documenting the assignment >> for ARIN, how useful SWIP is for that purpose. >> >> I have a /48 from 2 upstreams. Only one is registered. The other ISP does >> not appear to have ANY SWIP entries, even though I have set up the network >> with static v6 for at least a dozen customers, each of which received a /48. If that is the case, then that ISP is, indeed, in violation of ARIN policy and a fraud/abuse report to ARIN would not be out of order. >> Another "proxy" for to consider in deciding to SWIP or not might be the >> delegation of the reverse DNS for the allocated block. If there is a >> delegation, this is another way to find the technical contact other than >> SWIP if there is a problem. Not really reliable. In reality, there’s only one POC in the SOA and most providers in my experience populate that POC entry with meaningless unusable addresses. Owen >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Mon, 17 Jul 2017, David Farmer wrote: >> >>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman <dav...@panix.com> wrote: >>> >>>> >>>> Can you define voluntary? >>>>> >>>>> Is the voluntary choice to record a reassignment >>>>> up to the USP? >>>>> >>>>> Or does the choice belong to the end-user? >>>>> >>>> >>>> I think that's a business decision the two parties make together. I think >>>> an ISP can choose to SWIP whatever it wants, and should do so with the >>>> consent of the end-user. I think an end-user should be able to demand a >>>> SWIP entry, and the ISP should generally comply. >>>> >>> >>> And if the ISP doesn't comply with the user's demand, can one of their >>> recourses be to appeal to ARIN? Obviously, in a healthy market another, >>> and maybe more effective, option is to get another ISP. However, not all >>> markets are healthy and too frequently users have only one realistic option >>> for an ISP, especially in rural areas. >>> >>> I think it is important that if a user requests a SWIP from an ISP, and >>> they not given the SWIP, this should be at very least a technical violation >>> of ARIN policy. Is ARIN going to revoke an ISP's address space because of >>> a single complaint from a user in this regard, of course not, but I would >>> expect ARIN to intercede with an ISP on behalf of the user. However, if >>> there are repeated issues, especially large numbers of them, and if there >>> are other policy violations too, then I would expect harsher actions by >>> ARIN eventually. >>> >>> Thanks >>> >>> -- >>> =============================================== >>> David Farmer Email:far...@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 >>> =============================================== >>> >> _______________________________________________ >> 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: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. > > _______________________________________________ > 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: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. _______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
