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

[Richard J Letts]

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

As an example we assign /48's to school districts, colleges, and universities in the State of Washington. 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.
We do not advertise separate routing for most of these /48 -- I do not want any linkage between SWIP and routing.
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.

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.