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

[Paul McNary]

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
pmcnary at cameron.net

On 7/15/2017 8:18 PM, hostmaster at uneedus.com 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
>> pmcnary at cameron.net
>>
>>
>>
>> On 7/15/2017 12:42 PM, Scott Leibrand wrote:
>>> On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <bill at herrin.us 
>>> <mailto:bill at herrin.us>> wrote:
>>>
>>>     On Sat, Jul 15, 2017 at 8:52 AM, John Curran <jcurran at arin.net
>>>     <mailto:jcurran at arin.net>> 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 (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>>