[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
hostmaster at uneedus.com
hostmaster at uneedus.com
Sat Jul 15 21:18:42 EDT 2017
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
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
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.
Paradise On Line Inc.
On Sat, 15 Jul 2017, Paul McNary wrote:
> 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.
> could, would have access and ability to harvest proprietary information
> 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
> available in such a public accessible database as whois. They could count my
> harvest their names, addresses and even contact phone numbers. I do not see
> as being good. I would not even like my SMB businesses to have public
> 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
> is the smallest allocation to be announced. I have also have heard /48. So in
> 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.
> smaller than that, I don't want to publicly advertise.
> Why would we want the ability to give the competition the tools to analyze
> 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
> 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.
>> 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.
>> 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:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML