Dyn’s chief scientist, Jim Cowie, gave an interesting presentation last week at RIPE 70 around some of the potential routing issues that can emerge from IPv4 address transfers. Given the steady increase in IPv4 transfers in the APNIC region, I thought it was a presentation worth sharing.
Jim used some recent examples of transfers in the RIPE region from Romania to the Middle East to illustrate how accidental mistakes from the previous user of a transferred address block could lead to significant problems for the acquirer when they start using the block.
Jim highlighted the essential need for clean routability as part of any transferred block in his first example. Romanian company, Netserv Consult, transferred a /17 to Iranian telco, Mobile Communication Company of Iran, in October 2014. The Iranian mobile operator began announcing the prefix immediately. However, Level 3 Inc had been announcing some specific prefixes within the range since 2012 (a few /21s) which triggered plenty of problems for consumers of services using the address range.
The situation got worse as the Iranians began to announce more specific prefixes to take control of their newly-acquired /17, only for Level 3 to do the same in what turned out to be an arm wrestle. Adding more confusion is the fact that other specific prefixes in the block are still being announced out of Romania, and we achieve a situation where multiple prefixes in the range are being announced in both Iran and Romania. Messy!
The second example showed that accidental errors from the previous user of an IPv4 range can have big impacts on the new user of the address block, long after the transfer has taken place. Jim described how a previous ‘owner’ of a block – which had been transferred to another organization – accidentally re-announced the space… inadvertently creating a route hijack.
His recommendations for those considering an address transfer? Do your homework on the routing history of the prefix on offer, and drill down into the specifics. Set up routing alarms on the new block to alert you to any clashes. And make sure you have the technical contacts of the organization transferring the block… just in case a mistake occurs and you need a quick resolution.
As an aside: Jim’s presentation also picked up on some of the IPv4 transfer trends which the RIPE Labs team has been investigating recently. If you’re interested to find out what’s been happening in the transfer market in the RIPE region, I recommend this excellent post which digs into the details.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.