IPv6 Mapping Prefix PDU for the RPKI-Router Protocol

In IPv6-only network deployments, IPv4 service delivery relies on stateless address mapping mechanisms (e.g., 4map6, MAP-T, MAP-E, IVI) where an IPv6 mapping prefix is configured at Provider Edge (PE) devices to identify the location of IPv4 address blocks. For any given IPv4 address block, its corresponding IPv6 mapping prefix is considered the mapping origin. PE devices distribute these mapping relationships through MP-BGP extensions. The authenticity of these address mapping relationships is critical. Without proper validation, an attacker could announce a fake IPv6 mapping prefix for an IPv4 address block, causing IPv4 service traffic to be redirected to the wrong egress PE and resulting in IPv4 prefix hijacking. To address this security concern, the Mapping Origin Authorization (MOA) framework was introduced. MOA is a cryptographically signed RPKI object that authorizes an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. The RPKI to Router Protocol provides a simple, reliable mechanism for routers to receive validated RPKI data from trusted caches. Currently, the protocol defines two payload PDU types: IPv4 Prefix (Type 4) for Route Origin Authorization (ROA) data for IPv4, and IPv6 Prefix (Type 6) for ROA data for IPv6. However, no PDU type currently exists to convey MOA data-specifically, the authorization mapping from IPv4 prefixes to an IPv6 mapping prefix. This document defines a new PDU type, the "IPv6 Mapping Prefix" PDU (Type TBD1), that extends the RPKI to Router Protocol to carry MOA information. This enables routers to perform Mapping Origin Validation (MOV) for IPv4-to-IPv6 address mapping announcements, thereby preventing IPv4 prefix hijacking in IPv6-only underlay networks. This document focuses on the transport of MOA data from caches to routers. The validation logic, including how MOA validation interacts with IPv6 ROA validation, is handled in the MOA verification specification, which is expected to accompany the MOA profile, and is outside the scope of this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The following terms are used in this document: MOA: Mapping Origin Authorization, a cryptographically signed RPKI object that authorizes an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. MOV: Mapping Origin Validation, the process of verifying that an IPv4-to-IPv6 mapping announcement is authorized by a valid MOA. IPv6 mapping prefix: An IPv6 prefix that is configured at PE devices to identify the location of IPv4 address blocks in an IPv6-only underlay network. 4map6: An MP-BGP extension for distributing IPv4-to-IPv6 mapping information. Cache: A cache that collects and verifies RPKI data, including MOA objects, and makes them available to routers via the RPKI to Router Protocol.

The IPv6 Mapping Prefix PDU is a payload PDU type that conveys a set of IPv4 prefixes authorized to be mapped by a specific IPv6 mapping prefix. The format is analogous to the existing IPv4 Prefix and IPv6 Prefix PDUs defined in, with modifications to accommodate the mapping relationship.

The IPv6 Mapping Prefix PDU contains the following fields: Protocol Version (8 bits): MUST be 1 for this version of the protocol. PDU Type (8 bits): TBD1 (to be assigned by IANA). Length (32 bits): The total length of the PDU in bytes, including the 8-byte header (Protocol Version, PDU Type, zero, Length) and all subsequent fields. The length MUST be 33 bytes for the minimal PDU (carrying one IPv4 prefix), plus 5 bytes for each additional IPv4 prefix. For a PDU carrying N IPv4 prefixes, the length is 28 + (5 × N) bytes. Flags (8 bits): The lowest-order bit indicates announcement (1) or withdrawal (0). The remaining bits are reserved; they MUST be zero on transmission and MUST be ignored on receipt. IPv6 Mapping Prefix Length (8 bits): An unsigned integer (0-128) denoting the prefix length of the IPv6 mapping prefix. IPv6 Mapping Prefix (128 bits): The IPv6 mapping prefix, with trailing bits beyond the prefix length set to zero. Number of IPv4 Prefixes (8 bits): An unsigned integer (1-255) indicating the count of IPv4 prefixes carried in this PDU. IPv4 Prefixes (variable): A sequence of IPv4 prefix entries. Each entry consists of: IPv4 Prefix Length (8 bits): Prefix length (0-32). IPv4 Prefix (32 bits): The IPv4 prefix, with trailing bits beyond the prefix length set to zero.

The MOA IPv6 Mapping Prefix PDU:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv4 Prefix Len| Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The IPv4 Prefixes

As with the IPv4 Prefix and IPv6 Prefix PDUs in, the lowest-order bit of the Flags field indicates whether this PDU announces a new mapping authorization (1) or withdraws a previously announced mapping authorization (0). The semantics of announcement and withdrawal follow the same rules defined in Section 5.6.

The IPv4 Prefixes field encodes a set of IPv4 prefixes that are authorized to be mapped by the IPv6 mapping prefix. The canonical ordering for the IPv4 prefixes SHOULD follow the definition in, where each prefix is represented by its first IPv4 address (addr) and prefix length (plen), and the set is sorted by addr (lower first) then plen (lower first). This canonical representation allows relying party software to more easily verify the contents of the PDU.

The cache server MUST ensure that it sends only one IPv6 Mapping Prefix PDU for a unique tuple {IPv6 Mapping Prefix, set of IPv4 prefixes} at any point in time. If the router receives multiple IPv6 Mapping Prefix PDUs with the same tuple (including the same Flags value), the behavior follows Section 5.6: the router SHOULD raise a Duplicate Announcement Received error.

When a cache receives MOA objects from the RPKI repository, it MUST parse each MOA to extract the IPv6 mapping prefix and the associated set of IPv4 prefixes. The cache then constructs one or more IPv6 Mapping Prefix PDUs: For each MOA (which contains one IPv6 mapping prefix and a set of IPv4 prefixes), the cache SHOULD generate a single IPv6 Mapping Prefix PDU that includes all IPv4 prefixes from that MOA, provided that the total PDU length does not exceed the maximum supported by the transport (typically limited by TCP maximum segment size). If the set of IPv4 prefixes is large, the cache MAY split them across multiple PDUs, each carrying a subset of the prefixes with the same IPv6 mapping prefix. The IPv4 Prefixes field MUST be presented in the canonical ordering described in Section 4.2 to facilitate verification. When splitting is employed for announcements, the handling of withdrawals MUST follow the following guidance: Withdrawal of all prefixes: When all prefixes that were previously announced across multiple PDUs need to be withdrawn, the cache MAY send either (a) a single Withdrawal PDU containing all IPv4 prefixes, or (b) multiple Withdrawal PDUs, each corresponding to the subsets used in the original announcement PDUs. Both approaches are acceptable. Withdrawal of a subset: When only a subset of prefixes needs to be withdrawn, the cache MUST send one or more Withdrawal PDUs that collectively include exactly those prefixes to be withdrawn, and no others. Router behavior: The router MUST treat the union of all prefixes contained in received Withdrawal PDUs for a given IPv6 mapping prefix as withdrawn, regardless of how the withdrawals are split across PDUs. Specifically, the router MUST remove from its local MOV database any mapping authorization for which a corresponding Withdrawal PDU is received, without requiring the withdrawal PDU count to match the number of announcement PDUs.

Upon receiving an IPv6 Mapping Prefix PDU with Flags=1, the router SHOULD install the mapping authorization into its local MOV database. For each mapping announcement received via 4map6 MP-BGP, the router can then validate whether the announcing IPv6 mapping prefix is authorized for the announced IPv4 prefix by checking against the MOA data conveyed via this PDU. When the router receives an IPv6 Mapping Prefix PDU with Flags=0, it SHOULD remove the corresponding mapping authorization from its local MOV database. If a router receives an IPv6 Mapping Prefix PDU that is malformed (e.g., invalid Length field, IPv6 Mapping Prefix Length out of range, IPv4 Prefix Count out of range, or an individual IPv4 Prefix Length out of range), it MUST send an Error Report PDU with Error Code 0 as defined in Section 5.10.

The IPv6 Mapping Prefix PDU is subject to the same Refresh, Retry, and Expire timer mechanisms defined in Section 5.8, and the same Serial Number mechanism defined in Section 5.9 also applies. Specifically: Refresh timer: When the Refresh timer expires, the router MUST sends a Reset Query to the cache to refresh all MOA data. While waiting for the response, the router SHOULD continue to use the currently installed MOA data for MOV decisions. Retry timer: If the router does not receive a response to its Reset Query within the Retry interval, it SHOULD retransmit the Reset Query. Expire timer: When the Expire timer expires and the router has not successfully refreshed its MOA data, the router MUST remove all MOA data from its local MOV database and cease performing MOV decisions based on MOA until the cache connection is re-established. Serail Number:The Serial Number in the End of Data PDU [RFC8210] Section 5.8 governs the version of the data set. A change in MOA data MUST be accompanied by an incremented Serial Number. Routers MUST use the Serial Number to detect stale or out-of-sync data.

IANA is requested to assign a new PDU Type code for the "IPv6 Mapping Prefix" PDU in the "RPKI-Router Protocol PDU Types" registry.

The security considerations for the RPKI to Router Protocol described in Section 13 apply equally to this extension. In particular: Data integrity: The IPv6 Mapping Prefix PDU inherits the integrity protection provided by the underlying transport (TCP) and the authentication mechanism between cache and router. However, the authorization information itself is derived from cryptographically signed MOA objects; the cache MUST validate each MOA before generating PDUs from it. Cache trust: As noted in , the router MUST have a trust relationship with the cache. The cache is responsible for correctly aggregating and validating MOA data from the Global RPKI. Denial of service: An attacker that compromises a cache could inject false mapping authorizations or withdraw legitimate ones. Operators SHOULD deploy caches in a secure environment and use authenticated transport (e.g., SSH or TLS) for the RPKI-Router protocol session as described in Section 10. Replay attacks: The protocol's Serial Number mechanism ensures that routers can detect stale or replayed PDUs. This mechanism applies equally to the IPv6 Mapping Prefix PDU. IPv6 ROA dependency: The operation of MOA depends on the authenticity of address authorization in the underlying IPv6 network. Therefore, it is RECOMMENDED to also deploy IPv6 ROA validation where MOA is deployed. The detailed interaction between MOA validation and IPv6 ROA validation, including validation order and fallback behavior, is outside the scope of this document and is addressed in the MOA verification specification, which is expected to accompany the MOA profile.

The authors would like to thank the authors of and for their foundational work. Special thanks to the SIDROPS working group for their reviews and feedback on this extension.