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

[hostmaster at uneedus.com]

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.