Origin ASN for Anycasted Services
There is a new draft from the IETF GROW working group that attempts to standardize how Anycasted services manage their routing announcements. The draft can be found at:
Before commenting directly on the draft a review of how ISC operates the F-Root Anycast network is in order.
ISC maintains ASN 3557 which is used to originate the F-Root prefixes at every node. This provides a consistent origin ASN for the F-Root announcements, and prevents us from tripping reports like Team Cymru's inconsistent-origin ASN report. Rather than allow people to BGP peer directly with ASN 3557, ISC provisions an ASN per Anycast site, the local ASN in our parlance, which sits between AS 3557 and the peers at that location. In addition the local ASN announces the management prefix(es) for that location so that the only routes coming from ASN 3557 are the F-Root service prefixes.
Because of this configuration it's possible to identify an ISC Anycast node by the penultimate ASN. For instance an AS-Path ending in 30132 3557 indicates the Amsterdam local node. To cross reference other paths, see the ISC Peering Page.
The AS-Path only identifies a particular node, inside of that node may be multiple servers. To identify a particular server ISC enables the "hostname.bind" Chaos record as documented in RFC 4892. By sending a query for this record to the F-Root service address the individual host serving that query can be identified by the end user. There is also a newer standard, RFC 5001 documents a Name Server ID (NSID) which can be returned on an EDNS query that could provide similar functionaity.
Returning to the draft in question a different mechanism has been proposed. In the Unique Origin ASN draft the suggestion is that each node announces the anycast space from a unique ASN that would identify the node. This would result in the actual route being originated from multiple ASN's, one for each node.
ISC has identified the following problems with the draft:
- "Node" is not well defined. For ISC a node is at least two servers, however if the method in the draft were to approximate the level of granularity found in the RFC 4892 method each server would need to have an ASN so it could be identified by routing. This would require ISC to more than double the number of ASNs in use for F-Root.
- This method would all but render the various inconsistent-origin ASN reports available to be useless. To remain relevant, these reports would need to white-list all Anycasted services so they do not appear on the reports which would be a significant additional burden. These reports prove quite useful when networks with IP space, but without ASN's (or BGP) move from provider to provider.
- There are other mechanisms already in place that provide this level of data, often with increased precision. For instance, even if ISC were to drop the use of ASN 3557 and originate the service prefix from all of the local ASN's it would be impossible to identifiy a particular server via that method. ISC would continue to recommend using hostname.bind, the RFC 4892 mechanism, to identify F-Root servers; and would even view the RFC 5001 method as superior.
- This mechanism would likely increase the size of the DFZ routing table. While an Anycast prefix would only take up a single routing slot entry in a BGP device, BGP devices must also consider the paths available to reach that prefix. By creating more unique paths there will be increased memory consumption on all devices in the DFZ.
- This mechanism is unlikely to help end users. Many Internet end users don't receive BGP feeds. Should their provider run a looking glass or similar service, it may not point to the same Anycast instance as the users connection due to the way that Anycast routing works. Thus this method would have the limited audience of people who actually run BGP speaking routers.
In short, ISC believes this draft provides no advantages over the current methods ISC uses with F-Root. At the same time, it has the potential to do real harm to the useful inconsistent-origin ASN services, and may be another contributing factor adding to path bloat in the DFZ. ISC believes the RFC 4892 or RFC 5001 methods are vastly superior to identify DNS Anycast services, and believes similar functionality should be developed for any other Anycasted applications.
- BIND 10
- Other Software Projects
- security advisories
- software forums
- ABOUT ISC