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

Wed Jul 26 15:43:55 EDT 2017

> On Jul 26, 2017, at 08:34 , hostmaster at uneedus.com wrote:
> 
> Im sure glad that /32's of static IPv4 are not subject to SWIP, and that SWIP does not require GPS info.
> 
> If it did, we would be in trouble, as our GPS tracking only updates every 300 seconds or 5 minutes, and we would need a T1 of bandwidth just to keep the SWIP updated, and for what purpose?  In all cases the only place that will address abuse is our NOC.

If your GPS updates every 5 minutes, then that’s a $GPGGA and possibly a $GPRMC sentence every 300 seconds.

In general, each of these sentences is under 80 characters (usually around 64 characters IIRC). Conservatively using 80 characters, we have 80*8=640 bits every 300 seconds.

This leaves 1,572,224 bits per second on a T1 for protocol overhead.

OTOH, if you’re talking about the SWIP template size (reassign simple is all that this really calls for), then that’s a bit larger, weighing in at 463*8 = 3,704 bits without any data added to the basic template. Let’s assume another an average of 40 characters (probably closer to 20, but let’s again be conservative) for each of the 12 fields giving us an additional 480*8=3,804 bits for a total of 7,508 bits. Adding EMAIL message size overhead and TCP/IP overhead, let’s call it an even 16Kbits per SWIP. (that’s pretty high overhead, I think) At that rate (16kbb per 300 seconds, A T1 requirement means you need to support 28,800 busses in your system.

As such, 1,000 busses or less actually fit on a DS0 with room to spare.

> Right now, all 500+ busses use a static IPv4 address, that is assigned by the Major wireless provider.  They are NOT in a block reserved for us. They are scattered around several blocks of addresses of the provider, some of which they appear to be leasing from another party, and those SWIP records list the leasing company.  None of them have a SWIP to us, our provider has to forward the reports to us, sometimes thru the leasing co.

While there may be people willing to SWIP GPS coordinates, I would argue this is the exception rather than the rule and constantly updating SWIP to reflect the location of a mobile element rather than simply SWIPing it to a headquarters location is illogical in the extreme.

> As we move to v6, I am hoping the policy will change from 100% SWIP to a level not requiring it.  This is because our provider insists the current ARIN rule requires a street address for each bus.  I think I will point them to the thread that states the site address is not required in SWIP, and we can use the ADMIN address, or better yet wait for the policy to change and let them forward reports just like they do in v4.  In any case, my guess is that nearly no abuse will happen on v6 for lack of customer abuse, and we will continue to receive a couple of reports a month on the new contract dynamic addresses, if they at the provider can even figure out who to send them to, as in the future the addresses for v4 might be CGnat, and they would have to figure out who did it.

The provider is mistaken. The current ARIN rule requires a street address for each customer delegation in excess of a /64. If he delegates a /48 to the bus company (or even a /32 or a /24 or whatever), then he only needs to SWIP the address of the bus company on that particular block and he has fulfilled his ARIN obligations. (This is my personal opinion and not an official statement from ARIN staff or the AC, however, I’m sure one of those entities will correct me quickly and publicly if I am wrong).

I’ve worked for and with a number of ISPs and end users and dealt with many ARIN allocations and assignments as well as many reallocations and reassignments to downstream customers. I assure you that SWIPing individual busses even if each bus got an IPv4 /24 would be considered illogical by virtually anyone involved in the process and that SWIPing an aggregate block to the bus company would make much more sense.

If each bus gets a random IPv6 static assignment individually and they can’t be aggregated, then, they would have to be SWIP’d individually, but they could still be SWIP’d to the address and name of the bus company without requiring the current location of the individual bus in question.

Owen

> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> 
> On Wed, 26 Jul 2017, Roberts, Orin wrote:
> 
>> Ref: Geolocation and SWIPs
>> 
>> I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera in remote park.
>> 
>> “A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same”.
>> 
>> Is this in ARIN’s policy? “The SWIP data is not required to be the service address”
>> 
>> 
>> 
>> 
>> [cid:image001.jpg at 01C9B448.7DFDA670]
>> 
>> 
>> 
>> Orin Roberts - JNCIA, CCNA, ITILv3
>> IP PROVISIONING
>> Bell Canada
>> 
>> ' 905.614.9338 |  • oroberts at bell.ca<http://www.bell.ca/>
>> 
>> 
>> 
>> On 7/24/2017 1:31 PM, Owen DeLong wrote:
>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com<mailto: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.
>> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same.
>> 
>> [rest trimmed because we are in agreement on that part]
>> 
>> Owen
>> 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<mailto: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<mailto: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<tel:%2B31-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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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.