Summary

  • RFC 4012 kept legacy import, export, and default in their IPv4-unicast frame while adding mp-* attributes for family-aware policy.
  • On those new attributes, an omitted optional AFI clause means any across IPv4/IPv6 unicast and multicast; it does not mean “no family specified.”

A blank AFI was not an empty field

A reader encountering mp-import without an afi clause might assume the statement has no family scope. RFC 4012 makes the opposite choice: the omitted clause resolves to any, a defined scope covering IPv4 unicast, IPv4 multicast, IPv6 unicast, and IPv6 multicast. A missing word therefore carries a rule. It is not an invitation for each parser or operator to guess.

That default belongs to the new mp-* attributes only. The older import, export, and default attributes retain their established IPv4-unicast meaning. RFC 4012 thus avoids two kinds of ambiguity at once: old records are not silently reinterpreted, and a new multiprotocol expression with no AFI is not left semantically empty. The first question for a reviewer is not just “what policy text follows?” but “what scope did the grammar assign before I read the rest?”

The old vocabulary had a family boundary

RFC 2622, published in 1999, defined the Routing Policy Specification Language for IPv4-unicast routing. Its familiar import, export, and default attributes gave operators a way to describe how an autonomous system would exchange routes. In 2005, RFC 4012 extended that model for IPv6 and multicast policy, aiming to preserve compatibility and keep the change bounded. RFC 2622 RFC 4012

The names mattered because an old parser could not safely infer a new family from an old attribute. RFC 4012 therefore kept the legacy attributes' IPv4-unicast meaning and added mp-import, mp-export, and mp-default. An afi clause could identify ipv4.unicast, ipv4.multicast, ipv6.unicast, or ipv6.multicast, among other defined scopes. When an mp-* attribute omitted that optional clause, the specification assigned it the broad any scope across the four families. This is a rule for reading the policy expression, not evidence that a router supports or applies all four. RFC 4012, Sections 2.1–2.5

This was a careful extension, not a claim that every network had become multiprotocol in the same way. The language let a registry distinguish policies that a generic IPv4-unicast vocabulary could not express cleanly. It also left room for old records and implementations to retain their earlier meaning.

RPSLng also composes scopes: ipv4 and ipv6 each cover that version’s unicast and multicast; any.unicast and any.multicast span one traffic type across both versions; any is the union of all four base combinations. The grammar is compact because these unions are named, not because their reach is implicit.

The same AFI acronym points to different layers

RFC 4012 also adds the route6 class, but its object key and change authorization are separate from the optional AFI rule; RFC 2725 treats that authorization question. It is boundary context, not a second thesis here. RFC 4012, Section 3 RFC 2725

BGP also uses AFI/SAFI labels, but RFC 4760 attaches them to network-layer reachability and next-hop fields in UPDATE messages. RFC 4012's optional AFI scopes the RPSL policy expression. The shared vocabulary does not make the two statements interchangeable; route selection and per-neighbor advertisement belong to RFC 4271's runtime process. RFC 4271 RFC 4760

Named AFI unions made the grammar composable

The easy historical summary is that RPSL learned IPv6. More precisely, RFC 4012 made a policy's address-family scope expressible and named unions across versions and traffic types. That describes the language design; it does not say networks began treating both versions alike.

That precision is useful precisely because address families are not interchangeable labels. A network can have different peers, filters, next hops, reachability, and operating decisions for IPv4 and IPv6. A statement that applies to any is broader than one that names ipv6.unicast; the distinction belongs in the record. It still does not erase the operator's separate choices about what to accept or announce.

Later BGP policy work provides a chronological contrast. RFC 8212, published in 2017, requires explicit EBGP import and export policy; it addresses BGP behavior and does not change how RFC 4012 parses an omitted AFI in RPSL. RFC 8212

The specification set scope; implementation gave it effect

Lu Heng's Notes 65 and 64 offer an editorial lens for this design choice: a shared specification is useful when independent parsers can derive the same scope from the same text. That is not a claim about RFC 4012's authors or their motives. The any default supplies a deterministic common reading; local operators still decide whether that broad scope matches their policy and what their systems should run. Note 65 Note 64

The most consequential part of this extension may be the value of a clause left unwritten. In an mp-* expression, no AFI does not narrow the statement or suspend judgment; it invokes the named union any. RFC 4012 therefore did more than add IPv6 vocabulary. It made scope composable and made omission deterministic, while keeping the older IPv4-unicast contract intact.

These standards establish no adoption rate, database-completeness measure, named operator configuration, route leak, or IPv6 deployment outcome. The supported conclusion is narrower: RFC 4012 made the scope of RPSL policy expressions more precise and deterministic.

Primary sources