For the record, I would be happy if this policy stopped at changing the
100% SWIP requirement for v6 assignments to allowing /56 and smaller to
not have to SWIP. However, if the community agrees, I have no issues with
taking additional actions in this draft, up to and including elimination
of v6 SWIP.
Of course, as with any discussion of SWIP, there have been suggestions
that SWIP in v6 has outlived its usefulness in IP address management and
should be eliminated, and others that have suggested language that limited
the use of V6 SWIP to only those networks that are independently routed
from the main block.
I asked for some facts regarding the actual amounts of assignments, and if
anyone had reached the 75% assignment level and had returned for more. I
found the reassignment rate is 8.5%, and that noone has returned for more
after exhausting their initial allocation of IPv6.
I suggest that nearly everyone who has a allocation of v6 is using it in
some form or another. The people with their head in the sand, and
thinking v4 will be fine forever have likely not even have obtained a v6
allocation and are not counted in these stats.
The proposal "b)" from the other day with the language requiring SWIP for
all independently routable blocks of any size, and all blocks /47 or
larger is the best idea between the "leave it alone" camp on one side, and
the "Dump v6 SWIP" camp on the other.
ARIN staff has already identified possible database issues if the current
policy of registering every /64 or more is actually done. The only thing
that has prevented this issue is the low 8.5% registration rate identified
during my information request.
For small networks, which according to the standards may be up to a /48 of
assignment, generally unless they have their own routing, any abuse issues
are going to be addressed to the holder of the main block anyway, so
absence of SWIP does not matter. For those who have their own routes,
SWIP is needed and this proposal states that independently routed blocks
must appear in SWIP.
While I am not opposed to v6 SWIP elimination, those who state this is too
soon do have a point. The Proposal "b)" is a good middle ground,
retaining SWIP assignment records for those networks that need it because
of independent routing, and eliminating the requirement for those networks
up to a /48 that do not have independent routing. This also reduces the
number of required SWIP records, taking pressure of unneeded growth of the
SWIP database.
In the discussion of the CPNI rules of the FCC, and residential privacy
provided for in the NRPM, I would like to suggest that ISP's also be able
to withhold the City State and Zip Fields in SWIP reporting. This is
especially true if a 9 digit zip code is used, as these can be assigned to
a single addresss, totally unmasking the residental customer. All 3
elements are part of a complete address, which has been identified as
protected CPNI by the FCC, and we should be permitted to do this if
our lawyer so advises, without fear of ARIN sanctions.
Also discussed was limitations of using rDNS in abuse tracking. I admit
that the SOA record often has invalid data. If it does, I use the
contacts for the Domain Registration associated with the rDNS assigned to
the IP address. This often gets me a contact, even when SWIP has no data.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Tue, 18 Jul 2017, Owen DeLong wrote:
On Jul 17, 2017, at 16:36 , John Curran <[email protected]> wrote:
Albert -
We’ll research into these questions and report back shortly.
Thanks!
/John
On 17 Jul 2017, at 2:53 PM, [email protected] wrote:
Just a couple of questions regarding the carrots and the sticks for the ARIN
staff:
Other than those who came back to change their initial /35 to a /32, how many
ARIN customers have come back for another allocation of IPv6 space because they
used the first one to the extent the rules require, which I think is 75% of /48
block assignments.
Not many…. Yet. I know a few years ago, I filed the first such application (or
at least so said RSHD at the time) on behalf of my employer at the time (HE)
which requested (and received) a subsequent /24 to augment their existing /32
which was, in fact, more than 75% utilized.
And, how many customers have received a first allocation of IPv6?
Divide, and I can find out what percentage came back for more.
The problem with this theory is that IPv6 is just getting started and the vast
majority of ARIN customers that have received an initial IPv6 allocation or
assignment haven’t yet achieved full IPv6 deployment even to the point of
parity with their IPv4 deployment. As such, measurements to date will be badly
skewed to the low side of future reality.
What I would like to know is my gut feeling correct, which is that after
receiving an allocation of IPv6, nearly nobody ever returns to the well for
more, or at least not like it was back in the IPv4 days when ARIN had IPv4
address space to allocate, and thus there are no sticks?
Your gut is definitely correct to date. However, prior performance does not
predict future results. It’s true that a lot fewer organizations are likely to
come back for additional IPv6 blocks and all will certainly come back less
frequently than in IPv4. Nearly nobody is probably true today. It will probably
remain less than “most” for the foreseeable future, but I don’t think “nearly
nobody” is a permanent state.
Another bit of info I would like to know if possible: what percentage of
customers with a v6 allocation has actually put any of their assignments into
SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every
allocation should be there.
Again, this isn’t necessarily going to yield accurate results. Many providers
use RWHOIS as an alternative to SWIP. Many end users receive a /48 and it is
directly registered by ARIN, so nothing to SWIP. There are also other
situations (dynamic assignments, etc.) that are legitimately unlikely to result
in SWIP.
The answers are useful to determine as far as the documenting the assignment
for ARIN, how useful SWIP is for that purpose.
I have a /48 from 2 upstreams. Only one is registered. The other ISP does not
appear to have ANY SWIP entries, even though I have set up the network with
static v6 for at least a dozen customers, each of which received a /48.
If that is the case, then that ISP is, indeed, in violation of ARIN policy and
a fraud/abuse report to ARIN would not be out of order.
Another "proxy" for to consider in deciding to SWIP or not might be the
delegation of the reverse DNS for the allocated block. If there is a delegation, this is
another way to find the technical contact other than SWIP if there is a problem.
Not really reliable. In reality, there’s only one POC in the SOA and most
providers in my experience populate that POC entry with meaningless unusable
addresses.
Owen
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 17 Jul 2017, David Farmer wrote:
On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman <[email protected]> wrote:
Can you define voluntary?
Is the voluntary choice to record a reassignment
up to the USP?
Or does the choice belong to the end-user?
I think that's a business decision the two parties make together. I think
an ISP can choose to SWIP whatever it wants, and should do so with the
consent of the end-user. I think an end-user should be able to demand a
SWIP entry, and the ISP should generally comply.
And if the ISP doesn't comply with the user's demand, can one of their
recourses be to appeal to ARIN? Obviously, in a healthy market another,
and maybe more effective, option is to get another ISP. However, not all
markets are healthy and too frequently users have only one realistic option
for an ISP, especially in rural areas.
I think it is important that if a user requests a SWIP from an ISP, and
they not given the SWIP, this should be at very least a technical violation
of ARIN policy. Is ARIN going to revoke an ISP's address space because of
a single complaint from a user in this regard, of course not, but I would
expect ARIN to intercede with an ISP on behalf of the user. However, if
there are repeated issues, especially large numbers of them, and if there
are other policy violations too, then I would expect harsher actions by
ARIN eventually.
Thanks
--
===============================================
David Farmer Email:[email protected]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
