Summary

  • In AFRINIC’s registry, mnt-routes designates a maintainer allowed to create or edit route or routing-policy information associated with an address block.
  • The permission governs a database statement. Advertising, accepting and carrying the route still require separate router, BGP, filtering and upstream actions.

On 27 September 2018, AFRINIC changed who had to approve a route object. The registry stopped requiring separate authorisation from the holder of the origin ASN, while keeping authorisation from the holder of the IPv4 or IPv6 address space. AFRINIC explained that an address holder could delegate route-object management to an upstream provider by adding mnt-routes to the relevant inetnum or inet6num object.

That change makes the attribute more important, not more expansive. AFRINIC describes mnt-routes as naming a maintainer that may create or edit routes or routing policies associated with the resource. A valid maintainer credential can therefore answer a narrow question: which protected update path the registry accepted for this record at that time. It does not answer who logged into a router, whether the ASN holder agreed, or whether a BGP session carried the prefix.

The route object itself is also a declaration with a defined audience. AFRINIC says an IRR stores planned routes and routing policies in RPSL so that other operators can use them. A route or route6 object links a prefix to the ASN that plans to announce it. Tools may turn that statement into a filter, and a peer or transit provider may deploy the result on its routers.

Every verb in that sequence belongs to a different control surface. AFRINIC authenticates and stores the update. Mirrors may distribute it on their own schedules. A relying network chooses the source, retrieves a version, runs a policy generator, reviews or automates its output and deploys a configuration. The originating network separately configures BGP and completes its arrangements with an upstream. No one registry field performs all of those actions.

AFRINIC’s current best-practices page states the boundary directly: creating routing objects does not mean routes will be advertised. Operators must still configure BGP on their routers and complete network setup with transit or upstream providers. The same page says an object can keep an announcement from being filtered where automated checks are used. Influence is therefore conditional: the relying network must actually consume the relevant IRR data and act on it.

The right evidence record preserves both sides of the boundary. For the database side, keep the exact address and route objects, the mnt-routes, mnt-lower and mnt-by chain, the source, the operation, before-and-after versions and time. For the operating side, collect the mirror view used by the relying network, generated filter, deployment record, observed BGP announcement, upstream acceptance and separately timed reachability evidence.

This separation also prevents two opposite errors. A route object does not prove live traffic, but its absence does not prove that no route is being announced. Some networks use other IRR sources, manual policy or different validation systems; others may lag behind a changed object. The defensible conclusion is limited to the evidence surface actually observed.

Sources