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

[hostmaster at uneedus.com]

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.
>
>