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

Tue Jul 18 17:13:36 EDT 2017

On Tue, Jul 18, 2017 at 4:24 PM Owen DeLong <owen at delong.com> wrote:

>
> > On Jul 17, 2017, at 16:36 , John Curran <jcurran at arin.net> wrote:
> >
> > Albert -
> >
> >  We’ll research into these questions and report back shortly.
> >
> > Thanks!
> > /John
> >
> >> On 17 Jul 2017, at 2:53 PM, hostmaster at 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.
>
+1
Even heavy users of IPv6 for years such as my organization are just now
realizing that we wished we had opted for for a /27 instead of a /32 now.
Even though we are mostly dual stacked everywhere we are just now seeing
the potential of being able to allocate IPv6 addressing in a more
meaningful way, and with all the research taking place with robots, drones,
driverless vehicles, bio-engineering, aerospace, etc… etc… we really may
have to go back to the well.

> >> 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.
>
>
We do have our IPv6 assignment in SWIP, not sure what percentage of folks
do, but it is useful information.

> 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 <daveid at 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:farmer at umn.edu
> >>> Networking & Telecommunication Services
> >>> Office of Information Technology
> >>> University of Minnesota
> >>> 2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
> >>> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> >>> ===============================================
> >>>
> >> _______________________________________________
> >> 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.
> >
> > _______________________________________________
> > 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.
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170718/95ec3cb8/attachment.htm>