After seeing the vast majority of commenters agreeing to /56, I am
changing my vote from any level stated to more than a /56.
As the author of the Draft, I have been following the comments. With my
vote, /56 has 11 votes. There are also 2 people who are in agreement with
any of the expressed levels.
A /48 is the minimum size routable on the internet, so I have counted the
comment below as "more than a /52", making two votes for /52. Other votes
are two people for /60, and one for changing it to /61, a non nibble
boundary. Everyone seems to agree that any /48 should be SWIP'ed, as this
size can be individually routed.
Therefore, I am in favor of changing the "/60" in the draft to a "/56".
There has been some comments about SWIP, and abuse contacts. I note that:
1) The main block holder will always be the POC for anything not in SWIP.
2) If for example, a /48 block is assigned to a dhcpv6 server for prefix
delegation of /56's to dynamic users, this block is still required to be
registered in SWIP, as /48 is larger than /56. However this is just one
record for the entire pool, not one per EVERY customer as is the current
SWIP requirement of /64 or more, and the policy I seek to change.
3) Customers receiving an assignment larger than a /56 will also be
required to be SWIP'ed. This does not change at all.
The only thing that really changes is that small network customers, that
currently receive just a single IPv4 address, will be able to receive a
/56, /60 or /64 address block of v6 for their use without an individual
SWIP requirement, exactly as they can now receive a single IPv4 assignment
without an individual SWIP. With v4, only the dynamic pool of v4 addresses
is required to be SWIP'ed, not the individual small customer. I seek to
do the same for v6.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Tue, 6 Jun 2017, Paul McNary wrote:
I think the SWIP requirement should be the same as what is routable internet
wide.
/24 for IPV4 and whatever for IPV6. Anything less is the /24 holder's problem
to deal with.
If it is public routable then require SWIP otherwise let the routable holder
manage it.
Blacklists deal with it that way. Every had a /25 that the other associated
/25 had spammers on it?
Lots of fun! :-)
Now if the blacklist characters would work with the smaller IP ranges that
would be great, but will they?
Paul McNary
pmcn...@cameron.net
On 6/6/2017 3:10 PM, Roberts, Orin wrote:
/???Since we require SWIP for IPv4 /24s???///
ARIN also currently requires a SWIP for an IPv4 /29 , which makes ???/60"
a more applicable reference point; unless the intent is to minimize or
eliminate SWIPs for IPv6 (ISPs won???t mind).
Orin
*From:*ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *William
Herrin
*Sent:* June-06-17 3:04 PM
*To:* Leif Sawyer
*Cc:* arin-ppml@arin.net
*Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of
Assignment Registration requirements between IPv4 and IPv6
On Tue, Jun 6, 2017 at 2:30 PM, Leif Sawyer <lsaw...@gci.com
<mailto:lsaw...@gci.com>> wrote:
The boundaries at /60, /56, and /48 have all been discussed. If
one is more favorable than
the other, and you would like to see the proposal edited to use
that one, we will certainly
take that under advisory.
Hi Leif,
IMHO, IPv6 /48 = IPv4 /24. Since we require SWIP for IPv4 /24s, we should
require it for IPv6 /48s.
I'd be comfortable with "more than a /56" and "more than a /60." I prefer
"more than a /56."
I would oppose "/60 or more" or "/56 or more" because I believe that would
encourage ISPs to engage in unhealthy assignment practices to avoid SWIP
reporting, such as assigning /64s, /61s and /57s.
Regards,
Bill Herrin
--
William Herrin ................ her...@dirtside.com
<mailto:her...@dirtside.com> b...@herrin.us <mailto:b...@herrin.us>
Dirtside Systems ......... Web: <http://www.dirtside.com/>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.