Two New Policy Implementations Coming – What it Means for You and Your SWIP Automation

Two New Policy Implementations Coming – What it Means for You and Your SWIP Automation

We would like to bring your attention to some implications of two new policies and how they may impact you, your downstream customers, and your automated SWIP* scripts. The changes to our systems required by these  policies will be deployed during our next release cycle, scheduled for the week of 30 March 2020, as previously announced.

The Policies

The two policies that will be covered are “POC Notification and Validation Upon Reassignment or Reallocation” and “Disallow Third-party Organization Record Creation.” Both policies moved through the Policy Development Process, gained support from the community, and were adopted by the Board in June of 2019. Combined, they define how a Point of Contact (POC) and an Organization Identifier (Org ID) can be created in ARIN’s public Whois database as well as who is permitted to create such records. Both policies directly impact both Internet Service Providers (ISPs) and their downstream customers. The policies will also enhance the accuracy of ARIN’s public Whois.

How Do These Policies Impact Me?

As an ISP, you would typically reassign IP addresses to your customers using either SWIP or a distributed service which meets the standards outlined in the Number Resource Policy Manual. If you perform a SWIP, you would use either ARIN Online functionality (SWIP EZ), RESTful API/Reg-RWS, or email-based templates. Furthermore, you would have the ability to SWIP using a method of either Reallocation, Detailed Reassignment, or Simple Reassignment.

So, what’s changing you ask? With the implementation of these two new policies, ISPs will no longer be able to create POCs or Org IDs for their downstream customers when using the Detailed Reassignment or Reallocation methods of SWIP. The policies establish that POCs and Org IDs shall only be created by the individual or entity represented by the organization.

If an ISP wishes to SWIP to a downstream customer using the Detailed Reassignment or Reallocation methods, then the downstream customer will need to provide the Org ID to whom the SWIP should be made, and that Org ID is required to have at least one validated POC.

Reallocations are used when the downstream customer is an ISP organization that needs to further reassign/reallocate to their downstream customers. Detailed Reassignment is used when your downstream customer is an End-User organization that will be managing their own Reverse DNS (rDNS) or needs/wants to manage their own abuse reports.

Simple Reassignment is used when the downstream customer will not be managing their own rDNS nor will they manage their own abuse reports. Since the introduction of Simple Reassignments, it is no longer necessary for third-parties (such as upstream ISPs) to create organization records for another entity (such as their customers).

As an End-User or downstream ISP receiving a reassignment or reallocation of IP addresses from an upstream ISP, you will need to provide your Org ID to your ISP. This will require that a representative from your organization establish at least one POC and an Org ID with ARIN. Once an Org ID has been created with ARIN, you would provide that to your upstream ISP. They will then be able to reassign IP addresses to your organization.

How Will This Impact My Automation?

If your organization’s internal sales/IMAP systems “automagically” generate and submit reassignments via SWIP, you will need to make changes to your system to pass (rather than create) an Org ID if you are using either the Detailed Reassignment or Reallocate methods to SWIP. You will not be able to use the Detailed Reassignment or Reallocation methods to create a POC and Org ID for your downstream customers beginning the week of 30 March 2020.

If you are using Simple Reassignment, no changes on your side will be required.

If you frequently use the Detailed Reassignment or Reallocate method to SWIP and you use RESTful to submit your SWIP requests, we would like to offer you the ability to test your updated code. We will be providing a test system 27 February  through 26 March and would encourage you to make use of the test system to ensure your SWIPs are able to be processed when the new policies are implemented the week of 30 March 2020. If you are interested in participating in the testing phase, please provide us with your contact information and we will contact you to remind you when the test system is available.

If your organization/systems make use of email-based SWIP templates, ARIN is able to provide you with samples of the updated templates, version 5.3. These new email-based templates no longer contain the soon to be obsolete fields for creating POCs and Org IDs. In addition, we have posted example “rejection” emails that you will receive if the submitted SWIP doesn’t meet the policy guidelines. Please use the following URL for access to the email-based templates and sample “rejection” emails.

Testing is a very important component of this new policy implementation. Based on today’s SWIPs, about 50 percent of the Detailed Reassignment and Reallocation requests submitted create POCs and Org IDs. After the policy implementation the week of 30 March 2020, all of these SWIPs will fail to process.

How It Will Help Whois Accuracy

Implementation of these policies will provide additional privacy and security to the Internet community and help alleviate inaccuracy in ARIN’s public Whois database. These policies will ensure that POCs and Org IDs are requested by an authorized representative of the organization through an explicit request to ARIN.  Many entities find that multiple POCs and Org IDs are routinely created in their name during the SWIP process. Many times, the creation of these records created via SWIP are not accurate and cause confusion to the organization, staff  and the Internet community as a whole.

How Can I Prepare for These Changes?

To try out the reassignment and reallocation changes in ARIN Online, access the OT&E server at https://account-swip.ote.arin.net/public/login  and navigate to IP Addresses > Reassign Addresses to begin testing.

To test RESTful calls using the OT&E server, modify your RESTful commands to use the URL reg-swip.ote.arin.net  in place of reg.arin.net. Documentation for RESTful commands can be found here: https://www.arin.net/resources/manage/regrws/

If you have any questions about this policy and how it might impact you or your organization, please submit an Ask ARIN ticket through your ARIN Online account, or give our Registration Services Team a call at 703.227.0660. Registration Services is available between 7:00 am and 7:00 pm EST, Monday through Friday.

*SWIP stands for the Shared Whois Project, but is used to refer to a reallocation or reassignment to a downstream customer or organization.

Post written by:

A photo of Lisa Liedel
Lisa Liedel
Director of Registration Services

Lisa joined ARIN in March 2007 and is responsible for the day-to-day activities for the Resource Analysts and Paralegal, management of all registration related requests for Internet number resources (IPv4, IPv6 and ASNs), the maintenance of registration records, and general customer support. You’re likely to see Lisa at our ARIN Public Policy and Members Meetings.

Recent blogs categorized under: Tips


Sign up to receive the latest news about ARIN and the most pressing issues facing the Internet community.

SIGN ME UP →

IPv6 •  Business Case for IPv6 •  Internet Governance •  Public Policy •  Elections •  ARIN Bits •  Fellowship Program •  Grant Program •  RPKI •  Caribbean •  Outreach •  Training •  Updates •  IPv4 •  Security •  Data Accuracy •  Tips •  Customer Feedback •  IRR

 

Connect with us on LinkedIn!