ISC has done some research on this issue. It appears when we received AS 38568 from APNIC it was entered into our internal database with a typo, as AS 35868. The node was turned up with this error, and has run unnoticed ever since. It is important to note there was no RIR mistake in this particular case. The entries in the RIPE database came from scripts we run on the database that generate routing registry objects. ISC is actively working to resolve this issue, and this should disappear soon. We apologize to all for this particular problem, and thank Renesys for bringing it to our attention.
Bonjour, Y’all! ASN Split Personalities
Remember when the telephone company came to your house to hook up your phone and gave you a new phone number? This new number was how your friends and family were going to contact you. You counted on the telephone company to ensure that someone hadn’t already been issued that number, because if they had, various problems would ensue. What would happen when your mom tried to call your number if it was also assigned to someone else? Could you directly call the other party to work out the problem? Well, in the BGP realm, something similar has been happening with autonomous system numbers (ASNs).
Organizations need an ASN to run BGP and route on the Internet. They are each assigned globally unique ASN(s) by their local Regional Internet Registry (RIR), who get them from IANA. A few weeks ago, the NANOG folks noticed that AS1712 had been registered by two different organizations (in France and Texas) that were both using the number to announce their separate network prefixes. ARIN issued a statement conveying that they were aware of the problem and were working to resolve it. We took a look at the data and found that AS1712 isn’t the only dually-assigned ASN out there. In fact, even a root server didn’t escape unscathed.
First let me introduce myself: I’m Doug Madory, the newest member of the Renesys team. I came to Hanover, NH to do grad school and after a two-year stint as a medical center ISO, I jumped at the chance to be part of the cool work that goes on at Renesys. As part of my initiation here, I was handed the task to see if I could find any other examples of dually-assigned ASNs in the various RIRs — particularly ones that are currently in use. This isn’t as easy as it sounds, but we will get to that in a moment.
Knowing how to direct packets from an Internet café in Singapore to a network in Buenos Aires is what the Internet routers do. BGP is the protocol Internet routers use to communicate changes in routes from one autonomous system (an organization on the Internet) to another. Each autonomous system is assigned a unique number, its ASN.
These ASNs are primarily used to avoid routing loops (i.e. you shouldn’t be learning about your networks from your AS neighbors!). This is called loop detection and operates correctly only if ASNs are unique. No two RIRs are supposed to give out the same IP addresses or the same ASNs, otherwise we’ll have bedlam — but this has happened!
In November 2009, it was noted in a NANOG list discussion, AS1712 has been doubly assigned to both a Texas-based organization by ARIN and an organization in Paris, France by RIPE. They were simultaneously using their ASN to announce their respective network prefixes to the world.
0in 5.4pt 0in 5.4pt;mso-border-insideh:none;mso-border-insidev:none'>
$ whois -h whois.ripe.net AS1712 ... % Information related to 'AS1712' aut-num: AS1712 as-name: FR-RENATER-ENST descr: Ecole Nationale Superieure des Telecommunications, descr: Paris, France.
$ whois -h whois.arin.net AS1712 ... OrgName: Twilight Communications OrgID: TWILI Address: 1674 Kosik Ln City: Wallis StateProv: TX PostalCode: 77485 Country: US ASNumber: 1712 ASName: TWLT ASHandle: AS1712
According to IANA, AS1712 is to be assigned by ARIN, not RIPE. However, according to RIPE’s records it appears that many AS numbers in the 1700′s were assigned by RIPE in 1993 and therefore AS1712 could have been assigned by RIPE in the swamp days before ARIN even existed.
AS 1712 isn’t the only case of this…
Other doubly-assigned ASNs in the 17XX range include:
- AS1708 (RIPE: Renater, ARIN: Abacus, San Francisco, CA)
- AS1715 (RIPE: Renater, ARIN: Harrier Hawk Management LLC, NY, NY)
- AS1716 (RIPE: Renater, ARIN: Critical Data Network, San Diego, CA)
- AS1723 (RIPE: Renater, ARIN: Twilight Communications, TX)
ARIN believes that they have worked to fix the problem on the 17XX range, but doubly-assigned ASNs are not limited to the 1700′s as evidenced by:
- AS3745 (RIPE: Volkswagen, ARIN: Perot Systems, Auburn Hills, MI)
- AS35868 (RIPE: Internet Software Consortium, ARIN: Logix3).
In each of these examples, ASNs are both registered and are actively announcing prefixes for different organizations. We have alerted those responsible for these networks of the mix-up. What is fascinating is: why didn’t someone check when the duplicate assignment was made? Anyone can query the databases of the five RIRs from the Linux command line in the following way:
$ whois -h whois.arin.net AS1712 $ whois -h whois.ripe.net AS1712 $ whois -h whois.afrinic.net AS1712 $ whois -h whois.apnic.net AS1712 $ whois -h whois.lacnic.net AS1712
In the last example from above, AS35868 is a particularly interesting case:
- Logix3, a Florida company, was assigned AS35868 by ARIN in 2005
- Logix3 originates their own prefix, globally visible via AS35868, since 24 June 2006.
- AS38568 was assigned by APNIC to ISC (“ISC-SUV1″) in 2006.
- ISC started advertising 18.104.22.168/24 via AS35868 on 23 May 2007 via Fiji’s University of the South Pacific, in order to host Fiji’s local copy of the F-root server.
- AS35868 first appeared in RIPE as ISC on 29 September 2009.
However this gets cleared up, we strongly suspect that the local transit for the Fiji F-root will have to change. (Its address won’t, fortunately.) Since we don’t have a peer in Fiji, so we can’t confirm that 22.214.171.124/24 (F-root block) is anycasted there. Anybody in Fiji want to peer with us?
Despite the fact that verification services are readily available, neither the RIRs, the companies who received the duplicated ASNs, nor their providers seems to have checked if the ASN was assigned before making and accepting the ASN assignment. When an organization is assigned an ASN, it still needs to check to verify that this ASN hasn’t already been assigned. One can’t assume that the ASN handed to you by an RIR is unique because their databases aren’t perfect.
But don’t blame the RIRs, rooting out duplicate ASNs across RIRs is non-trivial. To identify duplicate ASNs, one cannot simply look for the same ASN in two RIRs. Some RIRs, like ARIN, try to list many of the ASNs in other RIRs as a pointer to them. Also, some large organizations may legitimately have the same ASN in two RIRs announcing different networks, for example, AS33771 (Safaricom) is listed in both AFRINIC and RIPE, but it probably does so because it announces network prefixes in the two continents (126.96.36.199/20 in Kenya and 188.8.131.52/16 in England). It doesn’t help that the RIRs are not consistent in their naming conventions, for example, AS109 is “ciscosystems” in ARIN and “cisco-eu-109″ in RIPE. So an effective automated ASN duplication detection tool is unlikely.
Lastly, businesses merge, acquire others or sometimes change their names without updating the records in the RIRs, for example AS3955 is Wang in ARIN and Getronics in RIPE, but Wang and Getronics are the same company. In fact, AS3955 also routes network prefixes (such as 184.108.40.206/16) for a third organization named, Compucom Systems. Compucom bought Getronics in 2007. AS32528 is Ross Labs in ARIN and Abbott Labs in RIPE. Ross and Abbott merged in 1964. Who has the capacity to keep up with every change to a business’s name?
Like everything on the Internet, nothing is ever easy, even something seemingly so trivial as assigning unique ASNs. The moral of the story is that, going forward, all parties involved in the assignment process would do well take some simple steps to verify the uniqueness of their new ASN because it gets very difficult to identify duplicates and fix the error after the fact. And we want to avoid more ASN split personalities who think they are in Paris — both Texas and France!!
À bientôt, pardner!
AS38568/AS35868 is a typo in the IRR portion of the RIPE db. It's *not* an RIR level mistake the way the Renater ASN's were. The APNIC database correctly points toward the ARIN record for 35868 and correctly lists 38568 for ISC. Likewise, ARIN correctly points to APNIC for 38568 and displays their record for 35868. The RIPE record for 35868 also correctly points to ARIN -- the bit that says ISC for 35868 is the IRR object - not the assignment record. Yes it's confusing. From the RIPE entry for 35868: remarks: You may find aut-num objects for AS Numbers remarks: within this block in the RIPE Database where a remarks: routing policy is published in the RIPE Database You are correct about the typ0 in the route announcement of 220.127.116.11 -- someone at ISC should go fix that. Your article is also a bit misleading about the repercussions of double assigning an ASN. Double assigning IP addresses/hijacking address space - depending on the announcement, traffic will be redirected causing an outage. ASN's that are used in more than one place, where the advertised IP addresses are different - only results in the 2 affected networks not being able to reach each other - because loop detection prevents them accepting routes with their ASN in the path.** However, unrelated ASN's will listen to both routes, thus they will continue to receive traffic from the majority of the internet (depending on ASN's involved of course). In this example, Logix and ISC in Fiji probably can't talk to each other --- This can account for why no one noticed/complained. I'm surprised it isn't more common. **If they are both endsites, and both have default routes, they will probably *can* reach each other.