



sidrops Working Group                                            G. Dong
Internet-Draft                                                    C. Xie
Intended status: Standards Track                           China Telecom
Expires: 31 October 2026                                   29 April 2026


          IPv6 Mapping Prefix PDU for the RPKI-Router Protocol
                   draft-dong-sidrops-rtr-moa-pdu-00

Abstract

   This document defines a new Protocol Data Unit (PDU) type for the
   RPKI to Router Protocol to convey Mapping Origin Authorization (MOA)
   information from RPKI caches to routers.  The new PDU, named the
   "IPv6 Mapping Prefix" PDU, carries the authorization mapping between
   one or more IPv4 prefixes and their corresponding authorized IPv6
   mapping prefix.  This extension enables routers to perform Mapping
   Origin Validation (MOV) for IPv4-to-IPv6 address mapping
   announcements in IPv6-only underlay networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 31 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Dong & Xie               Expires 31 October 2026                [Page 1]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  MOA IPv6 Mapping Prefix PDU Format  . . . . . . . . . . . . .   4
     3.1.  PDU Fields  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Diagram . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  PDU Semantics . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Flags Field . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  IPv4 Prefixes Field . . . . . . . . . . . . . . . . . . .   6
     4.3.  Uniqueness Requirements . . . . . . . . . . . . . . . . .   6
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
     5.1.  PDU Generation from MOA Objects . . . . . . . . . . . . .   6
     5.2.  Router Processing . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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[I-D.ietf-v6ops-framework-md-ipv6only-underlay].  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[I-D.ietf-idr-mpbgp-extension-4map6].

   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



Dong & Xie               Expires 31 October 2026                [Page 2]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


   prefix hijacking.  To address this security concern, the Mapping
   Origin Authorization (MOA) framework was
   introduced[I-D.ietf-sidrops-moa-profile].  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[RFC8210] 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.


1.1.  Requirements Language

   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[RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Terminology

   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[I-D.ietf-sidrops-moa-profile].

   *  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.




Dong & Xie               Expires 31 October 2026                [Page 3]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


   *  Cache: A cache that collects and verifies RPKI data, including MOA
      objects, and makes them available to routers via the RPKI to
      Router Protocol[RFC8210].

3.  MOA IPv6 Mapping Prefix PDU Format

   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[RFC8210], with modifications to accommodate
   the mapping relationship.

3.1.  PDU Fields

   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.



Dong & Xie               Expires 31 October 2026                [Page 4]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


3.2.  Diagram

   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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Protocol   |      PDU      |                               |
       |    Version    |      Type     |              Zero             |
       |       1       |               |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Length                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     | IPv6 Mapping  |  IPv4 Prefix  |     Zero      |
       |               | Prefix Length |    Count      |               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                     IPv6 Mapping Prefix                       |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                  IPv4 Prefixes (variable)                     |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 1: The MOA IPv6 Mapping Prefix PDU


   The IPv4 Prefixes field:


        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

4.  PDU Semantics

4.1.  Flags Field

   As with the IPv4 Prefix and IPv6 Prefix PDUs in[RFC8210], 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[RFC8210] Section 5.6.



Dong & Xie               Expires 31 October 2026                [Page 5]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


4.2.  IPv4 Prefixes Field

   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[I-D.ietf-sidrops-rpki-prefixlist], 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.

4.3.  Uniqueness Requirements

   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[RFC8210] Section 5.6: the router SHOULD
   raise a Duplicate Announcement Received error.

5.  Operational Considerations

5.1.  PDU Generation from MOA Objects

   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.




Dong & Xie               Expires 31 October 2026                [Page 6]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


5.2.  Router Processing

   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.

6.  IANA Considerations

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

          +--------+-------------+--------------------------------------+ |
          Value | Name | Description |
          +----------------------+--------------------------------------+ |
          TBD |IPv6 Mapping | MOA: set of IPv4 prefixes authorized | | |
          Prefix | by an IPv6 mapping prefix |
          +--------+-------------+--------------------------------------+

7.  Security Considerations

   The security considerations for the RPKI to Router Protocol described
   in [RFC8210] 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 [RFC8210], 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 [RFC8210] Section 10.



Dong & Xie               Expires 31 October 2026                [Page 7]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


   *  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 [I-D.ietf-sidrops-moa-profile],
      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.

8.  Acknowledgements

   The authors would like to thank the authors of [RFC8210] and
   [I-D.ietf-sidrops-moa-profile] for their foundational work.  Special
   thanks to the SIDROPS working group for their reviews and feedback on
   this extension.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

   [I-D.ietf-sidrops-moa-profile]
              Xie, C., Dong, G., Li, X., Huston, G., and D. Ma, "A
              Profile for Mapping Origin Authorizations (MOAs)", Work in
              Progress, Internet-Draft, draft-ietf-sidrops-moa-profile-
              03, 11 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              moa-profile-03>.

9.2.  Informative References

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.



Dong & Xie               Expires 31 October 2026                [Page 8]

Internet-Draft  IPv6 Mapping Prefix PDU for the RPKI-Rou      April 2026


   [I-D.ietf-v6ops-framework-md-ipv6only-underlay]
              Xie, C., Ma, C., Li, X., Mishra, G. S., and T. Graf,
              "Framework for Multi-domain IPv6-only Underlay Network and
              IPv4-as-a-Service", Work in Progress, Internet-Draft,
              draft-ietf-v6ops-framework-md-ipv6only-underlay-20, 8
              April 2026, <https://datatracker.ietf.org/doc/html/draft-
              ietf-v6ops-framework-md-ipv6only-underlay-20>.

   [I-D.ietf-idr-mpbgp-extension-4map6]
              Xie, C., Dong, G., Li, X., Han, G., and Z. Guo, "MP-BGP
              Extension and the Procedures for IPv4/IPv6 Mapping
              Advertisement", Work in Progress, Internet-Draft, draft-
              ietf-idr-mpbgp-extension-4map6-05, 3 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              mpbgp-extension-4map6-05>.

   [I-D.ietf-sidrops-rpki-prefixlist]
              Snijders, J. and G. Huston, "A profile for Signed Prefix
              Lists for Use in the Resource Public Key Infrastructure
              (RPKI)", Work in Progress, Internet-Draft, draft-ietf-
              sidrops-rpki-prefixlist-05, 10 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              rpki-prefixlist-05>.

Authors' Addresses

   Guozhen Dong
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: donggz@chinatelecom.cn


   Chongfeng Xie
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   102209
   China
   Email: xiechf@chinatelecom.cn









Dong & Xie               Expires 31 October 2026                [Page 9]
