Hello
This is probably targeted to John and the ARIN staff
I was reading some articles today. Under the current net privacy rules
and proposed
net neutrality rule making goes through or even if not, we are not
allowed to put
customer data in a publicly accessible data base. I don't think we are
even allowed
to provide that information to a third party without our customer's
written opt-in.
You can only get the IP "address holder's" information because of the
contract we
have with ARIN where we give up that right of privacy. So you can make
us give you
that information but you can not force us to break the law, if the end
user doesn't have a
contract with ARIN. Even if we would SWIP a current /24 and their
information is
disclosed to a third party (ie ARIN) and the end user doesn't have a
contract with
ARIN, I think we are in violation of the Internet privacy rules as they
are and have been.
John, can you and the ARIN staff get a written clarification from FCC
about this.
It basically guts the privacy rule making if SWIP is performed on a customer
who does not give written approval.
What am I missing? The WISPA lawyers say we are still required to follow the
Internet policy rule making.
Thank you
Take care
Paul McNary
McNary Computer Services
[email protected]
On 7/15/2017 8:18 PM, [email protected] wrote:
Harvesting of customer data is something that has not really been
addressed in the ARIN region, because it has not been an issue for
most customers or ISP's.
Currently it seems that in IPv4 land that 95% to 99% of ISP customers
only have a single IPv4 address. Thus, SWIP in v4 is not done, except
single entries to mark the use of the total blocks for assignment
purposes. Since individual addresses are not SWIP'ed, the customer
privacy/proprietary information is not an issue for the greatest
majority of total customers.
In IPv6 the current standard provides for 100% SWIP of all
assignments. This a big leak of proprietary information and a lot of
work, as even with residential privacy, the zip code of each customer
must be publically reported which can give competitors lots of inside
information.
I advocate changing the policy such that those 95% to 99% of customers
with a single v4 address are still treated the same in regard to SWIP
if I happen to add IPv6 to their service. There is a lot of ISP labor
needed to create the SWIP records, and for what purpose, allowing my
competitors to identify and grab my customers? I know who my customers
are, so SWIP does not help me at all with my own customers.
I also note that an ARIN staff report noted when the NRPM was being
changed to SWIP requirement of /64 that a database problem might
result if in fact all those v6 assignments were entered in the
database and called for a 6-9 month leadtime. Other drafts discussed
here have addressed the verification of POC's, which I understand is
currently in the upper 600,000's. If all these extra POC records are
in fact added due to SWIP requirements, 10 million POC's or more could
be reached if all non-residential records are required to be added.
The biggest cost of all is adding hundreds of millions of privacy
protected SWIP residential records for each customer, which contacts
will be a duplicate of the upstream record except for the customer zip
code, an information leak. This effort I do not think is a benefit to
the community, except maybe the subset of geolocation and advertising
providers, and whatever contractor is hired to increase ARIN's
database storage to contain these duplicate records.
In reality, if a customer is abusing, it is unlikely they will stop
just because they are notified using the SWIP data. Instead, the
complaint will 99% of the time will go to the ISP, the exact entity
that would be contacted if there was NO SWIP record for individual
customers at all. The ISP will make the decision as to if to cut off
the customer, warn them or do nothing. Contacting the ISP instead of
the Customer seems to work best.
The line needs to be placed somewhere. I, along with many others
discussing this on PPML agree that the current standard of /64 needs
to change. Being able to have up to a /56 of v6 without SWIP and its
associated costs to the ISP seems to have consensus. It also seems to
be consensus that /48's need to be SWIP'ed. Since it has been noted
that ARIN does not control routing, I agree that routing should not be
part of the policy, and like v4, a static value be chosen. We should
also consider that the policy at /64 may have a big cost to ARIN when
the providers actually start doing 100% v6 registration to expand the
database if the current policy is kept.
I think the current consensus of "more than a /56" or stated another
way "/55 or more" is a good compromise, as these smaller assignments
cannot be independently routed so no routed networks escape SWIP,
something that is desireable. Those operators that choose to give out
/48's to everyone would SWIP all customers. Those operators that
choose to not SWIP everyone could give out /56's and many might make
this choice in part based on the cost of SWIP to the ISP. While the
recomendation in the NRPM is /48, and calculations of network size can
be based on that number, nothing requires that a specific operator
follow it.
A operator could have a sparse assignment plan of reserving a /48 for
each customer, but only assigning a /56 of that /48 unless that full
/48 is requested by the customer. This is similar to the sparse
assignment plan of ARIN, leaving space for each v6 allocation to
expand without having to assign a new block. When initial allocations
were changed from /35 to /32 is an example of this in action. This
policy could also leave room for growth without further allocations if
a future policy changes the suggested allocation from /48, to a
smaller value such as /56.
I started off with a proposal to allow /60 and /64 to avoid SWIP and
its costs. The consensus thus far would add /56 to that list. Maybe
the community wants to consider adding /52 to that list, or even /48
if it is not independently routed.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Sat, 15 Jul 2017, Paul McNary wrote:
Hello
My concern is where the magic boundary will occur. If the swip
boundary includes the
recommended /XX for residential customers and small business. I could
see where the
whois database could be abused by harvesting our customer
information. Competitors
could, would have access and ability to harvest proprietary
information concerning
our ISP business. We would have to limit our end user details to the
area which will
not be swip'ed to protect our business. That might not be the proper
way to utilize IPv6.
Current guidance has been to assign a /56 to even residential
customers and some have
recommended a /48 as the minimum assignment. I don't want my customer
information
available in such a public accessible database as whois. They could
count my subscribers,
harvest their names, addresses and even contact phone numbers. I do
not see this
as being good. I would not even like my SMB businesses to have public
information
unless they ask for it. I would prefer that the boundary be greater
than /48. With /48
not being swip'ed or /56 even that is the minimum end user allocation.
If I understand correctly (many times I do not) RFC/common agreement
that a /32
is the smallest allocation to be announced. I have also have heard
/48. So in my
case if it can't be BGP public routable, I don't want to swip it.
What ever my BGP
routers can publicly advertise, my BGP gateway, will be assigned to
us. Everything
smaller than that, I don't want to publicly advertise.
Why would we want the ability to give the competition the tools to
analyze our
business with a publicly available tool (ie whois). I also don't
think that if ARIN
will not provide an allocation size it shouldn't be swip'ed. So if
ARIN wants to directly
provide /56 to end users, then I will rethink my thought process.
Anything smaller than
a minimum ARIN allocation, should not have to be swip'ed or under
their control.
Am I not understanding this correctly?
Thank you
Paul McNary
McNary Computer Services
[email protected]
On 7/15/2017 12:42 PM, Scott Leibrand wrote:
On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <[email protected]
<mailto:[email protected]>> wrote:
On Sat, Jul 15, 2017 at 8:52 AM, John Curran <[email protected]
<mailto:[email protected]>> wrote:
Such a separation doesn’t preclude the community from adopting
policy which
references the present or future state of routing (note, for
example, the use of
“multihoming” criteria in several portions of the NRPM), but
folks are reminded
that in Internet number resource policy we should only be
specifying how the
ARIN registry is to be administered, not how things are to be
routed, since the
latter is up to each ISP.
Hi John,
In the interests of clarifying your remarks:
ARIN does not set or even recommend routing policy. Participants
in the ARIN policy process routinely consider industry routing
practices, IETF recommendations, etc. when suggesting ARIN address
management policy and ARIN routinely enacts such policy.
Right?
That is true, but I think John is making a stronger point, which
I'll make here: It's perfectly fine for ARIN policy to be contingent
on (applied differently depending on) how a particular block is
(going to be) routed. So if we think it's the right thing to do, we
could require in the NRPM that all blocks in the global routing
system be SWIP'ed. But we *can't* enforce such a requirement by
saying, for example, that ISPs can't accept a block until it's
SWIP'ed. We can only issue guidelines on what should be SWIP'ed and
make ARIN services (like allocation of additional blocks) contingent
on whether such a policy is followed. If an enforced
SWIP-before-routing rule is desired by the ISPs that participate in
the global routing system, then they'll have to do so voluntarily by
refusing to accept the announcement of non-SWIP'ed blocks.
-Scott
_______________________________________________
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.
