[arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 4.2.3.7.1

[hostmaster at uneedus.com]

I learned a lot about the feelings of the community regarding the 
requirement to SWIP 8 IPs or more when I proposed 2017-5.  My intent was 
originally to change the policy for IPv6 SWIP registration from EVERY 
network to those who had more than 16 networks, or more than a /60.  As 
part of that, I proposed changing IPv4 policy to match from the current 8 
or more IPs to more than 16 IPs.  When the proposal hit the list, there 
was near unity that everyone with 8 or more IPv4 needs to SWIP their 
addresses and provide contact information.  My response was to eliminate 
all IPv4 bits from my draft policy, and it passed, changing the standard 
to more than a /48 for swip unless it is advertised differently.

Now 2 years later, because of pointlessness or otherwise, a proposal to 
eliminate ANY means of contact for these networks is now being discussed, 
and many now agree with the idea. I think that is wrong, even if emails to 
a SWIP contact are generally ignored.

While I agree that end user contacts would be pointless for this purpose, 
generally these contacts should not be end user contacts, but instead 
should be the people who are responsible for IT management for that 
network.  It might be a central IT contact in a business with many 
branches, or in smaller orgs might simply be the ISP contacts, as many 
ISP's do offer managed services along with connectivity.

Personally I would tell the Camera, A/C and other vendors that I will give 
them an internal IPv4 address, and a port forward to their box, or if they 
MUST have a static IP, it will have to be an IPv6 address.  After all, I 
have plenty of those to offer :).  At some point, that will be all that is 
available.

Our policy should be based on best practices, and that means a contact 
means for every block with 8 or more IPv4 addresses.  ISPs need to educate 
their customers to the fact that this contact needs to be a technical 
person that is able to deal with abuse, and not a contact in purchasing. A 
cost avoidance model should not be allowed either, or they should not be 
shocked when the circult is turned down by the ISP for abuse.

If those here still think we should get rid of the contacts for 8 or more 
addresses, instead lets consider changing the standard to /24 like it was 
in the past.  The language proposed would allow ANY size network get by 
without anything other than a simple, providing no contact information. 
The ideal process is still to have the abuse complaint land on the desk of 
the person closest to the problem.  Clearly once you get to a /24, you 
should be required to register your addresses.

Albert Erdmann
Network Administrator
Paradise On Line Inc.


On Mon, 28 Jan 2019, Adam Thompson wrote:

> I agree with Christopher and Larry that in most cases it's going to be pointless, but if it's pointless, the better question becomes: why SWIP it in the first place?
>
> I don't disagree with either of your specific points, but this is something I've pondered for a very long time:  the point of delegation, historically (in my memory, anyway) was to delegate authority and responsibility.  The only reason most of us (AFAIK) are normally looking at WHOIS data for an IP address in the first place, is because we're about to send email to the listed contact because of some bad action or other by that IP.  So if that contact is a priori useless... what was the point of having that data recorded in the first place?
>
> If the proposal was to remove the requirement for reassignment and/or reallocation to end customers completely, in cases where the delegating entity has sound reason to believe the customer is not capable of being "responsible" for the block, and the delegating entity feels they can better be "responsible" (I'm not going to attempt to define that term right now, sorry!) then, yeah, I think that would be a worthwhile change.  Reversing the onus of proof in the previous sentence would be much easier for ISPs, I'm not sure if it's a good idea or not.  Even lobotomizing simple reassignments to contain names *only* might be a useful change.
>
> Any of what I've suggested acknowledges the uselessness of the data commonly found in /29s, /28s, etc.; the existing proposal, however, does not appear to do so, instead ratifying the entire now-broken concept.
>
> Would there be broad community support for a more radical change (e.g., see above) than what was originally proposed?  I think I would support such a change, and I guess most ISPs would...?  What realistic downside is there that I'm just not thinking of right now?
>
> Adam Thompson
> Consultant, Infrastructure Services
> MERLINÂ Â Â Â Â 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athompson at merlin.mb.ca
> www.merlin.mb.ca
>
> -----Original Message-----
> From: Christopher E. Altland <caltland at mctvohio.com>
> Sent: Monday, January 28, 2019 1:07 PM
> To: Larry Ash <lar at mwtcorp.net>; Adam Thompson <athompson at merlin.mb.ca>; 'Marilson Mapa' <marilson.mapa at gmail.com>; hostmaster at uneedus.com
> Cc: ARIN-PPML List <arin-ppml at arin.net>
> Subject: RE: [arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 4.2.3.7.1
>
> I support this proposal.
>
> Almost all end users with /29 or larger in our network would not understand what you were contacting them about.    We get all of the complaints and will follow up with the end user to get it resolved.   I kind of feel that is what they are paying use to do.
>
>
> Christopher
> --
> Christopher Altland
> Network Engineer | MCTV
> caltland at MCTVOhio.com | www.MCTVOhio.com
> 814 Cable Ct. NW  Massillon, OH 44647
>
>
>
>
>
> -----Original Message-----
> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Larry Ash
> Sent: Monday, January 28, 2019 1:50 PM
> To: Adam Thompson <athompson at merlin.mb.ca>; 'Marilson Mapa' <marilson.mapa at gmail.com>; hostmaster at uneedus.com
> Cc: ARIN-PPML List <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 4.2.3.7.1
>
> On Mon, 28 Jan 2019 16:47:34 +0000
>  Adam Thompson <athompson at merlin.mb.ca> wrote:
>> I would phrase it in far less colourful language, and my motivations are almost entirely opposite, but with the same end result:
>> I don’t like this proposal.
>> If I have a /29 or larger, and it’s sending spam or doing anything
>> else anti-social, I want to know about it.  Relaxing the reassignment
>> requirements (whether that’s in fact or in appearance only) will guarantee that nearly all ISPs will do the minimum possible, specifically not include any relevant contact info for me.
>> From at least this one tiny piece of the community, no this proposal does not have support right now.
>> -Adam
>
> Of the /29 we have reassigned not a single one will respond to a message from any one of you. None of them have internal IT resources. Many have equipment that we manage and couldn't do anything anyway. Others have local computer stores that take care of their stuff. The customer pays every time they call with a question. They ignore every plea until it impacts their service.
> I know because I have blocked several of them to stop attacks when we were contacted as the customer's ISP and after several attempts to deal with the problem without affecting service.
>
> In a perfect world most of these companies would not have these addresses but when corporate demands two or three ip's for the firewall and the heating contractor demands an IP for the heating/cooling system and the security company demands an IP for maintenance of the security system and remote access to the cameras an ISP either assigns the address or the customer goes elsewhere.
>
> At the same time, several times a day the phone rings and a person claims to be from Microsoft or some other well known IT company claiming that if the person called doesn't do the following bad things will happen. Hopefully by now every person in the country as been trained to just hang up.
>
> I think that direct contact to end users expecting solutions to technical problems is delusional.
>
> I support the proposal and feel that any contact information should be limited to those that would have the technical ability to do something no matter the size of reassignment.
>
> Larry Ash
> Mountain West Technologies
> Casper Wyoming
>
>>
>>
>> Adam Thompson
>> Consultant, Infrastructure Services
>> [1DE92D93]
>> 100 - 135 Innovation Drive
>> Winnipeg, MB, R3T 6A8
>> (204) 977-6824 or 1-800-430-6404 (MB only)
>> athompson at merlin.mb.ca<mailto:athompson at merlin.mb.ca>
>> www.merlin.mb.ca<http://www.merlin.mb.ca/>
>>
>> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Marilson Mapa
>> Sent: Sunday, January 27, 2019 1:43 AM
>> To: hostmaster at uneedus.com
>> Cc: ARIN-PPML List <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2018-6: Clarify
>> Reassignment Requirements in 4.2.3.7.1
>>
>> The elimination of any reasonable means of contact in the event of
>> abuse it is an aberration and characterizes at least complicity with
>> unlawful acts. The ISPs need to stop hiding and protect spammers and scammers. 500 billion spam and scam a day are not enough? What is the new goal? A trillion?
>> You, ISPs, RIRs, and Registrars represent GGM21C, the Great Global
>> Mafia of the 21st Century. We know that people's personal and financial
>> data are worth gold these days. Creating ISPs and inventing scammers to
>> steal data is a problem for authorities. Not to prohibit a spammer, or
>> scammer, from continuing to send his trash after being reported, is also a criminal attitude of sociopaths who abound in that environment. This is the rule with the complicity of RIRs, Registrars and ICANN. But the discomfort that complaints bring to ISPs is being eliminated through policies such as the EU GDPR and re-ordering in RIRs.
>> The threat of arresting the Facebook owner or billionaire fines such
>> as that imposed by the EU on Google will not be enough to force an
>> ethical stance on the part of the Mafia. The answer to this criminal behavior will come in the worst way: politicians, under pressure from society, will say how free internet should be "free." Then do not complain.
>> This policy intends to hide and protect a customer regardless of their behavior.
>> Marilson
>>
>> Em sáb, 26 de jan de 2019 às 23:18, <hostmaster at uneedus.com<mailto:hostmaster at uneedus.com>> escreveu:
>> Looking at this, I am a NO as it is currently written.
>>
>> This section deals with /29 or more IPv4 addresses, or stated another
>> way,
>> 8 or more addresses.  Someone who is running such a network in today's
>> IPv4 exhausted world needs to have a means to contact them directly in
>> the event of abuse from their network.  The reassign-simple does not
>> provide for this, unless you consider postal mail a reasonable means
>> of contact for abuse reports.  I have ALWAYS directed abuse reports by
>> either email or telephone, as a letter is not fast enough for an ongoing abuse problem.
>>
>> As for the current ISP impact in regard to this policy as it currently
>> exists before amendment, the greatest majority of ISP customers, both
>> Business and Residential only have a single IPv4 address or less
>> (CGnat) and therefore are exempt from this policy. Only larger
>> networks with multiple hosts are likely to have 8 or more IPv4
>> addresses and subject to this policy.  Those with a /29 or more are
>> very likely a very small amount of the total ISP customers, but are
>> also the ones with multiple hosts that would be more likely to be
>> compromised compared those who just have machines behind a NAT router
>> that cannot accept inbound traffic without a router that is programmed
>> to allow it. I doubt this policy change will have much change at most
>> ISP's, since the customer base it addresses is very small.
>>
>> I would also suggest the residential exemption be eliminated for /29
>> or more, as nearly all residential IPv4 use today is NAT, rather than
>> public
>> IPv4 address assignment for each host.  We have talked of the problem
>> of spammers on this list using such /29 or more of residential space,
>> that are protected by the current privacy rules for residental
>> customers, and their abuse reports being ignored by their upstream.
>>
>> Looking at the differences between the Detailed and Simple reassign
>> templates, I do see one thing that would merit a change.  It is that
>> the 2 fields that are most often used for abuse reporting (telephone
>> and email) are missing from the simple reassignment, and fields that
>> are rarely used for abuse reporting (mailing address) are instead
>> present.  This is a decision that I would like to see changed.
>>
>> I would have no problem with a template change to reassign simple to
>> only have Name, Contact Email and Telephone number, and omitting all
>> the mailing address fields.  If that change were made, I would have no
>> problem with the proposal, as then the Simple Reassignment will at
>> least provide me with a reasonable means of contact in the event of
>> abuse from that network.
>>
>> Eliminating the requirement for a Detailed Assignment, without
>> changing the fields contained in a Simple Assignment will have the
>> effect of eliminating the abuse contacts for that network.  I think
>> that would be wrong.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>>
>> On Fri, 25 Jan 2019, Alyssa Moore wrote:
>>
>>> Helloooo PPML,
>>>
>>> It's been a couple weeks since there's been any action here, but it's
>>> time to shake off the winter and think about some policy! Woo!
>>>
>>> This proposal has to do with clarifying the language and requirements
>>> around reassignments. Please take a look and let your AC know if you
>>> think we're on the right track or not.
>>>
>>> Cheers,
>>> AM
>>>
>>> On Tue, Nov 20, 2018 at 3:55 PM ARIN <info at arin.net<mailto:info at arin.net>> wrote:
>>>
>>>> On 15 November 2018 the ARIN Advisory Council (AC) accepted
>>>> "ARIN-prop-258: Clarify Reassignment Requirements in 4.2.3.7.1" as a
>>>> Draft Policy.
>>>>
>>>> Draft Policy ARIN-2018-6 is below and can be found at:
>>>> https://www.arin.net/policy/proposals/2018_6.html
>>>>
>>>> You are encouraged to discuss all Draft Policies on PPML. The AC
>>>> will evaluate the discussion in order to assess the conformance of
>>>> this draft policy with ARIN's Principles of Internet number resource
>>>> policy as stated in the Policy Development Process (PDP).
>>>> Specifically, these principles are:
>>>>
>>>> * Enabling Fair and Impartial Number Resource Administration
>>>> * Technically Sound
>>>> * Supported by the Community
>>>>
>>>> The PDP can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Draft Policies and Proposals under discussion can be found at:
>>>> https://www.arin.net/policy/proposals/index.html
>>>>
>>>> Regards,
>>>>
>>>> Sean Hopkins
>>>> Policy Analyst
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>>
>>>> Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in
>>>> 4.2.3.7.1
>>>>
>>>> Problem Statement:
>>>>
>>>> Current NRMP section “Reassignment and Reallocation Information” is
>>>> being interpreted by some organizations to require a “detailed
>>>> reassignment” for all customers.  Under the current reassignment
>>>> schema, only a “detailed reassignment or reallocation” contains
>>>> fields for “organizational information”.
>>>>
>>>> This policy intends to simplify the reassignment requirements by
>>>> noting that only a customer’s name is required.  Thus a “simple reassignment”
>>>> can be used for most reassignments.
>>>>
>>>> Policy Statement:
>>>>
>>>> Replace section 4.2.3.7.1 with the following:
>>>>
>>>> 4.2.3.7.1. Reassignment and Reallocation Information
>>>>
>>>> Each IPv4 reassignment or reallocation containing a /29 or more
>>>> addresses shall be registered via a directory services system which
>>>> meets the standards set forth in section 3.2.
>>>>
>>>> Reassignment registrations must include each customer name, except
>>>> where specifically exempted by this policy.  Reassignment
>>>> registrations shall only include point of contact (POC) information
>>>> if either: (1) requested by the customer; or (2) the reassigned
>>>> block is intended to be routed and announced outside of the provider's network.
>>>>
>>>> Reallocation registrations must contain the customer’s organization
>>>> name and appropriate point of contact (POC) information.
>>>>
>>>> Comments:
>>>>
>>>> Timetable for implementation: immediate
>>>> _______________________________________________
>>>> ARIN-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:
>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
>>>>
>>> _______________________________________________
>> ARIN-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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.
>
> Larry Ash
> Mountain West Technologies
> 123 W 1st St.
> Casper, WY 82601
> Office 307 233-8387
> _______________________________________________
> ARIN-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:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>