[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21
hostmaster at uneedus.com
hostmaster at uneedus.com
Thu Jul 27 13:10:26 EDT 2017
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.
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
> 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
> types of abuse complaints are required to be processed, for example legal
> down requests. I suspect you will find very high compliance in processing
> types of abuse complaints.
> In other cases there are unwritten standards of conduct that when violated
> 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
> as well as a wide mix on level of compliance in processing TOS abuse
> 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
> abuse@ email contact. These will also have a wide range of compliance
> proportional to the strength of the contract and importance of the media
> 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
> customers are caught in the middle, and network abusers move on to new IP
> often with newly stolen credentials, with very little that well meaning
> providers can do
> to prevent re-occurrence.
More information about the ARIN-PPML