We have a number of IP ranges assigned to us from ARIN. As we are a service provider, we have to report which customers are assigned which subnets to ARIN. There’s a couple of different ways of doing this, we’ve used all of them at one point or another:

1) RWhois – This requires that you run a WHOIS server, and ARIN redirects any WHOIS requests they get to your IP space. The downside here is it’s yet another public service to maintain, and it’s something that we don’t have a lot of experience running.
2) SWIP via email – This is what we were using up until recently. You send specially formatted requests to a certain email address, and they are parsed and converted into SWIP records. The downside here is that error detection is complicated and delayed. Your only real option here is to monitor the email address that errors were sent to, and try to pull information from that. Error reports are delayed by at least a couple minutes, which makes debugging tedious. In addition, you can’t report IPv6 reassignments this way.
3) SWIP via REST – This is the way we’re currently reporting this information, and seems like the way to go moving forward. You get instant error reports, and the ability to control things a bit more then you can via email. The only downside is this process is slightly more complicated, and there’s not a whole lot of information outside of their documentation.

The very first issue I encountered is the content type sent with the requests. I was using text/xml, which was leading to cryptic 404 errors. It was only after working with their tech services that we determined you need to use application/xml. This probably isn’t the best error code to return, and was very confusing.

There are two main ways of dealing with this sync process:

1) Every X hours, dump a list of all the reassignments ARIN knows about, and compare them to all the networks we know about.
2) Every time a subnet is added/modified/removed, send ARIN the updated information.

For various reasons relating to how our existing code works, we went with option #1 (ARIN requires that you notify them of changes within 7 days, so a couple hour delay is no big deal). ARIN’s API doesn’t really seem to be designed to be used this way. For example, there is no easy way to get a list of all the reassignments associated with a specific subnet. There is a workaround, but it’s kinda hacky. I’d love to see some API methods designed for retrieving this information in the future (not ones limited to 256 networks).

So, our overall process looks like this:

For each direct allocation from ARIN
	Request a reassignment report
	Delay until that report has been created.  Convert the report from XLS to CSV, then load the CSV.
	For each subnet that *we* know about in this direct allocation, check that it exists within the reassignment report
		If it exists and the information doesn't match, delete the reallocation and mark it to be re-added later
		If it doesn't exist, mark it to be added later

	Delete any subnet that exists in the reassignment report, but doesn't exist in our database

For each subnet that needs to be added
	Determine if we need to create a 'recipient customer' or if we should reassign to the customer's ORGID
		Create an individual customer entry for each subnet if necessary

	Create the reallocation, linking it either to the customer or ORGID

So, the “hack” here is requesting the reassignment report, then having to download and convert it. It seems largely unnecessary to have this be an Excel spreadsheet, rather then just a CSV file or raw XML data.

While not a hack, it’s important that all the subnets get deleted before you try to create any new ones. If you don’t do this, you can run into conflicts depending on what changes have happened (for example, if two /29’s were deleted and one /28 was created out of them, you will receive errors if you delete one /29 then try to create the /28). It’s much simpler to do this in two stages then to try and sort out the conflicts.

The other annoyance is creating a recipient customer for each subnet. We do this because it’s important to us that the location reported for each subnet actually matches the data center that it’s located in. The reason being that various GeoIP providers rely on this information being accurate. If you create an organization for each of your customers, there is no way to specify the subnets are in different data centers. This also means there’s no way to query ARIN for all the subnets associated with a specific customer.

Some of our customers want their contact information associated with their subnets. This is generally so they can respond to abuse complaints directly, without having to relay them through us. I’m still somewhat unsure if our process for this is correct, but it seems to work. We ask the customer to register an organization with ARIN (if they’re located in the US), or create a POC entry with ARIN. If they create an organization, we just assign all their subnets to that. If they can only create a POC (because they’re located outside the US), we create the ‘recipient organization’ via the API, then assign all their subnets to that ORGID. This lets them log into ARIN’s site and modify the organization or contact information, which means we don’t have to implement an interface to that. The problem here is that the location information for GeoIP is no longer correct. This hasn’t been a concern yet, but will be something we have to implement in the future.