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

Mon Jul 24 14:58:41 EDT 2017

> On Jul 21, 2017, at 00:09 , theone at uneedus.com wrote:
> 
> As for discussion of SWIP for /48's, some have suggested since these are the recommended minimum assignment for an end site, /48 should not trigger SWIP unless independently routed.  Others believe all /48's be SWIP'ed. Thus the two main ideas for this proposal currently are:
> 
> 1) SWIP all independently routed (in the GRT) networks regardless of size but in actual fact they must be at least a /48 to be in the GRT, and all other assignments greater than a /48.  This is the "b)" language using /47 from the other day.

As I demonstrated in my previous post, the GRT is not entirely as restrictive as stated, so I would say that your option 1 would be better (and more accurately) restated as:

1) SWIP all independently announced networks regardless of size and all assignments shorter than /48 (i.e. /0../47).

This is the option which I currently support.

> 2) SWIP every /48 regardless of routing, smaller are exempt.  This is the "/48 or more" language. Since the standard site size is /48, this catches a lot of small sites that are not independently routed but avoids setting the policy based on routing.  If this is chosen many ISP's are likely to choose giving out /52 or less instead of /48's.  As pointed out by others, a major cable ISP in the US already gives out only a /60 with their prefix delegation server.  Although like the mobile networks, they do have a current valid argument against SWIP, since these are not "static”.

So far, I saw opposition to 1) favoring 2) only from Bill Herrin and generally good support for 1) otherwise. However, I admit this is not the result of a careful or detailed review of every message specifically for this determination, so I may have missed something along the way.

> Now that we want to change the bus administrative network to v6 for lack of v4 static assignments from the contract wireless provider, we run into the ARIN 100% SWIP registration requirement of /64 or more in NRPM 6.5.5.1. as v6 does not use NAT.  The policy of /64 or more is what I seek to change, to allow smaller v6 networks, like these busses to avoid a SWIP requirement.  Switching the same size network with the same number of hosts from v4 to v6 should not change the SWIP requirement, but current policy does. This is where the debate is, where to draw that line.

The reality is that the over-arching /48 containing all of the bus /64s could be SWIPd as a single block to the bus company and would be a completely legitimate solution to this issue. I suspect that the IPv4 aggregate containing the static IPv4 addresses for all the busses was also SWIPd previously (or at least should have been under policy). As such,
I’m not sure this is the ideal example for your argument.

> The thing to remember is that currently a /48, according to the 2.15 of the NRPM is the recommended value for every end site, residential or commercial.  Current ARIN policy would allow the transit agency to receive a /36 and assign each bus a /48. I have suggested they instead obtain a single end user /48 from either ARIN or a /48 assignment from a /32 block already controlled by state government for their bus use to avoid renumbering during contract provider changes, and use a /60 on each bus. Either saves money over getting a /36 from ARIN.

Yes, but the bus isn’t necessarily technically considered a separate end site (or at least not necessarily one that has to be SWIPd). For example, a major corporation that is numbering a variety of end-sites on multiple corporate campuses around the world can qualify for nx/48 as an aggregate, let’s say /40 for convenience here. (some value >128 and less than 256 end sites). Said corporation would not need to SWIP each and every campus. The corporation is not considered an LIR, but an end-user (unless they choose to be an LIR for reasons of their own) and as such could register the entire /40 as a single block to Corporate HQ without issue and without being required to make any more specific SWIPs. Similarly, the bus company could register their aggregate IPv6 address block (/48, /36, /32, or whatever) to an appropriate headquarters address and be done. There is no need to register the assignments to the individual busses.

In fact, if the busses become independently routed, this policy proposal would, in fact, increase the registration requirement from what it is today rather than decrease it.

> As far as public disclosure of CPNI, the size of an organization does not matter.  In the example discussed here of that 69.0.0.0/29 block we have been talking of, unless AT&T has written permission from that customer, they have committed a CPNI violation by simply publishing the name and address of that customer in SWIP, and AT&T could in theory be fined for that disclosure, even though ARIN policy requires the information be disclosed in SWIP. If the FCC in fact takes action is a different story. The usefulness of this SWIP record is also in doubt, as staff at that location, even if contacted might be unable to deal with an "owned" box.
> It is better to have tech records with the contact info of actual technicians.

I think you will find that the AT&T TOS cover this disclosure if you read them carefully. I could be wrong and IANAL, but most ISPs I’ve dealt with definitely include language covering the SWIP requirement somehow in their contracts and/or TOS. YMMV.

Owen

> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> On Thu, 20 Jul 2017, Chris James wrote:
> 
>> Well I think in the bus example you would swip to the overall authority.
>> But seriously this conversation has gone in so many different directions do
>> any of us remember the original point?
>> 
>> My vote as it applies to v6: Non-residential allocations of greater than or
>> equal to a /48.
>> 
>> If you as an ISP choose to allocate a /48 to a residential customer - then
>> have fun. But this does not affect the purpose of the policy as most use it
>> these days which is abuse management. Also as I understand it, there is an
>> exception to the CPNI as it applies to business customers as long as they
>> have an account manager and adequate language in the contract. How many of
>> the smaller ISPs have a customer deserving of a /48 or better that does not
>> have a larger account or spend? If a customer requests a large enough block
>> from us, regardless of v4 vs v6, they agree via email/ticketing/contract
>> that their business information will be made public. This is not difficult
>> to put in your signed agreements with your business customers thus making
>> the CPNI argument invalid.
>> 
>> -Chris
>> 
>> 
>> 
>> On Thu, Jul 20, 2017 at 2:28 PM, <hostmaster at uneedus.com> wrote:
>> 
>>> My transit bus example is another example of SWIP difficulty.  Very hard
>>> to provide a street address to SWIP a bus when it is mobile 16 hours a day.
>>> 
>>> Current policy says SWIP every /64 or more, which is every network in v6.
>>> 
>>> I did a check here, and in v4, only 1% of customers have more than 8 ip's,
>>> and these customers are colocation customers who have a bunch of SSL
>>> sites.  These are grandfathered. New customers are told to use 1 IPv4
>>> address and SNI or better yet, IPv6, as we do not have the money to buy
>>> more V4.  We would rather use our v4 inventory for access customers.
>>> 
>>> Yes, it is just a few pieces of information for SWIP.  However, we do not
>>> have clerical staff to do it, because except for the SSL colocates, there
>>> never has been v4 SWIP's required here. Why should the policy state that
>>> just because we give each customer an assignment of v6, we must SWIP that
>>> same small customer that did not require SWIP in v4? (Welcome to IPv6, now
>>> fill out this form.....) Also noted is that the SWIP registration details
>>> without written permission might get us in trouble with the FCC over CPNI.
>>> As a WISP that has licensed microwave links, we do pay attention to Uncle
>>> Charlie.
>>> 
>>> Albert Erdmann
>>> Network Administrator
>>> Paradise On Line Inc.
>>> 
>>> On Thu, 20 Jul 2017, Chris James wrote:
>>> 
>>> @Paul - The API key is to email it.
>>>> 
>>>> @Owen - Very difficult when you have dynamic ranges, and vps/container
>>>> platforms spanning tens of thousands of instances across these dynamic
>>>> ranges.
>>>> 
>>>> 
>>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary <pmcnary at cameron.net> wrote:
>>>> 
>>>> Owen
>>>>> 
>>>>> The reassignment policy page says IPv6 has to be done vi API.
>>>>> Is that something else that is incorrect on the web site?
>>>>> 
>>>>> Paul
>>>>> 
>>>>> 
>>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote:
>>>>> 
>>>>> How can it be overly difficult to fill out an email template with your
>>>>>> customers’
>>>>>> Name, Address, Phone Number?
>>>>>> 
>>>>>> Really?
>>>>>> 
>>>>>> Owen
>>>>>> 
>>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans <Pallieter at pallieter.org
>>>>>>> 
>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> ARIN could quantify and require rules for when to SWIP, but in the
>>>>>>> end, there are going to be exceptions needed if the rules are to be
>>>>>>> strictly followed. Many will not separately SWIP a separately routed
>>>>>>> sub-block if it is too difficult or pointless to gather and share that
>>>>>>> data back upstream to ARIN.
>>>>>>> 
>>>>>>> Thus a more fuzzy rule to require a best-effort and to add a
>>>>>>> rule-based reason (preferably both a carrot and a stick) for block
>>>>>>> owners to do their best to provide (only) useful data. In order to do
>>>>>>> that, one needs to look back at why that data is needed. For a block
>>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech
>>>>>>> and abuse contact requests down to those that are probably more likely
>>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce
>>>>>>> request-handling workload higher up and overall). But for that to
>>>>>>> work, those tech/abuse contact requests need to be actually handled,
>>>>>>> otherwise, it is better to leave them with the block owner.
>>>>>>> 
>>>>>>> In the end, the contact details should be as close to the "person"
>>>>>>> that is actually capable to both handle (think: volume/languages/etc)
>>>>>>> and act (think: authority) on the tech/abuse requests.
>>>>>>> 
>>>>>>> eBrain
>>>>>>> Innovative Internet Ideas
>>>>>>> 
>>>>>>> Pallieter Koopmans
>>>>>>> Managing Director
>>>>>>> 
>>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET)
>>>>>>> Skype: PallieterKoopmans
>>>>>>> _______________________________________________
>>>>>>> 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.
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> 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.
>>>>> 
>>>> 
>>>> --
>>>> This e-mail message may contain confidential or legally privileged
>>>> information and is intended only for the use of the intended recipient(s).
>>>> Any unauthorized disclosure, dissemination, distribution, copying or the
>>>> taking of any action in reliance on the information herein is prohibited.
>>>> E-mails are not secure and cannot be guaranteed to be error free as they
>>>> can be intercepted, amended, or contain viruses. Anyone who communicates
>>>> with us by e-mail is deemed to have accepted these risks. This company is
>>>> not responsible for errors or omissions in this message and denies any
>>>> responsibility for any damage arising from the use of e-mail. Any opinion
>>>> and other statement contained in this message and any attachment are
>>>> solely
>>>> those of the author and do not necessarily represent those of the company.
>>>> 
>>> 
>>> _______________________________________________
>>> 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.
>>> 
>> 
>> -- 
>> This e-mail message may contain confidential or legally privileged
>> information and is intended only for the use of the intended recipient(s).
>> Any unauthorized disclosure, dissemination, distribution, copying or the
>> taking of any action in reliance on the information herein is prohibited.
>> E-mails are not secure and cannot be guaranteed to be error free as they
>> can be intercepted, amended, or contain viruses. Anyone who communicates
>> with us by e-mail is deemed to have accepted these risks. This company is
>> not responsible for errors or omissions in this message and denies any
>> responsibility for any damage arising from the use of e-mail. Any opinion
>> and other statement contained in this message and any attachment are solely
>> those of the author and do not necessarily represent those of the company.
> _______________________________________________
> 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.