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

[Tony Hain]

Richard J Letts wrote:

> I believe we should SWIP for /48.
> I believe we may SWIP for /56 or longer if the Service provider deems it
> useful.

Effectively, length is irrelevant. SWIP to the responsible & responsive
network operator.

> 
> As an example we assign /48's to school districts, 

So you believe in forced-renumbering ... You SHOULD be assigning blocks to
school districts sufficient that they can reassign a /48 to each school.

> colleges, and universities in
> the State of Washington.

A college/university is a service provider to their student clients. They
SHOULD be assigned blocks large enough to reassign a /48 to each of their
customers, as any other service provider. 

>  I want each of them to have their own SWIP
> records so any issues with traffic originating from the site can get
addressed
> by the local network administrators before they get escalated up to me as
> the WA-K20 NOC manager.

I agree that this is the appropriate use of SWIP, but it has absolutely
nothing to do with prefix length.

> We do not advertise separate routing for most of these /48 -- I do not
want
> any linkage between SWIP and routing.

While the unadvertised case is a local call, I assume you would want the
ability to find contact info for a prefix that was independently routed in
the global table.?.?.

> Stating SWIP is not required for /48 leaves me open to them asking me not
to
> SWIP (for some reason), and it is absolutely not the same as /32 SWIP in
v4.

So establish a firm policy that for DMCA and any other jurisdictionally
appropriate legal tracking; all assignments are published, period. Length
has nothing to do with it. While I agree that it is often handy to have a
3rd party policy to resolve local political issues, in this case DMCA is
useful, and avoids the need to have overly restrictive ARIN policy that
impacts everyone else.

Tony


> 
> Thank you
> 
> Richard Letts
> Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP,
> PWAVE, WRN
> 
> > -----Original Message-----
> > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of
> > hostmaster at uneedus.com
> > Sent: Thursday, July 27, 2017 10:10 AM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of
> > Assignment Registration requirements between IPv4 and IPv6 - updated
> > 2017-07-21
> >
> > I agree that we need to act on THIS draft, and not load up the
> > discussion with other issues that this draft is not intended to
> > address.  The one question regarding SWIP/WHOIS policy in general I
> > have moved to another thread since it is unrelated to this draft.
> >
> > This draft is about changing the Assignment Registration rules to
> > allow minimum static assigments of IPv6 space to be made most of the
> > time without triggering a SWIP requirement.  Current policy is
> > effectively 100% registration, which is not true for the same customer
using
> IPv4.
> >
> > After discussing changing the standard from /64 to /60 or /56, we
> > appear to have agreed that the end user site minimum assignment should
> > be /48, and that operators should not be assigning less.
> >
> > The last draft has language that I understood to have the effect of:
> >
> > *  /47 or more MUST SWIP, as these sizes are larger than an end user.
> >
> > * Any size that is separately routed, which under most routing
> > policies would be a /48 or larger, shall also SWIP.  This also leaves
> > the decision as to what level is routed to others, as this is not an
ARIN
> decision.
> >
> > *  Otherwise SWIP is not required for a /48, as this size is the basic
> > end user or site assignment, similar to demanding /32 SWIP's in v4.
> >
> > There has also been some discussion that the current draft language
> > does not reflect the above concepts, and suggesting changes. These are
in
> scope.
> > However problems with SWIP, WHOIS, abuse, etc are not in scope for
> > this draft, and are not helpful in deciding what we need to have in
> > this draft.  If there are others that seek to fix these other issues,
> > lets have them propose a different draft to do so, rather than trying to
> insert that here into this one.
> >
> > Albert Erdmann
> > Network Administrator
> > Paradise On Line Inc.
> >
> >
> > On Thu, 27 Jul 2017, Jason Schiller wrote:
> > >
> > > three points:
> > > 1. This proposal is not trying to address the problem of how ISPs
> > > handle abuse.
> > >
> > > If that is a problem the community wants to tackle, lets define the
> > > problem and propose policy in a DIFFERENT proposal
> > >
> > > 2. I do not believe the suggested changes impact how ISPs handle
abuse.
> > >
> > > How ISPs handle abuse is orthogonal  to this proposal.
> > >
> > > 3. How ISPs handle abuse is complicated and opaque and requires more
> > > nuance and clarity about what is actually required for compliance.
> > >
> > >
> > > As is said before compliance tends to be very good when it is either
> > > required, or beneficial to the organization.
> > >
> > >
> > > If an organization is trying in good faith, to follow ARIN rules,
> > > then they will try to keep SWIP information for their networks
> > > accurate, as well as for their down stream customers.
> > >
> > > There is no ARIN requirement that a provider need to process or
> > > respond to abuse complaints on their network space, nor that they
> > > take action on downstream customers who fail to process  abuse
> complaints.
> > >
> > > In some cases their are particular legal rules in particular
> > > countries that some types of abuse complaints are required to be
> > > processed, for example legal take down requests. I suspect you will
> > > find very high compliance in processing these types of abuse
complaints.
> > >
> > > In other cases there are unwritten standards of conduct that when
> > > violated results in a TOS agreement violation leading to loss of
> > > service.  I suspect you will find a wide mix in terms of what is
> > > permitted under various TOS (although generally it is expected that
> > > the requirements are at least as strict for down stream
> > > customers)
> > > as well as a wide mix on level of compliance in processing TOS abuse
> > > complaints.
> > >
> > > In yet other cases, media agreements will contractually require DMCA
> > > violations to be processed.  These are often completed by a
> > > pre-defined process and not through
> > > abuse@ email contact.   These will also have a wide range of
compliance
> > > directly
> > > proportional to the strength of the contract and importance of the
> > > media agreement.
> > >
> > > In yet other cases there is an unwritten standard of conduct that
> > > when violated results in being published on a black list.  This also
> > > has a wide mix in terms of what is needed to be added and removed
> > > from the blacklist.  Furthermore there is a wide mix of
> > > corresponding behavior by blacklisted organizations from
> > > aggressively cleaning up black listed space and maintain a positive
> > > reputation (and usable IP space for its customers), to organizations
that
> do not engage black listers.
> > > Often times innocent customers are caught in the middle, and network
> > > abusers move on to new IP space often with newly stolen credentials,
> > > with very little that well meaning providers can do to prevent
> > > re-occurrence.
> > _______________________________________________
> > 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.