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.

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. The Flags field is set to 1 for announcement when a new MOA is discovered or when an existing MOA is updated. When a MOA is withdrawn (e.g., due to expiration or revocation), the cache MUST send an IPv6 Mapping Prefix PDU with the Flags field set to 0 for the same tuple.

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.

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: As noted in , 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 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.