



sidrops                                                          N. Geng
Internet-Draft                                                 S. Zhuang
Intended status: Standards Track                                  Huawei
Expires: 3 September 2026                                          Y. Fu
                                                           China Telecom
                                                                M. Huang
                                                 Zhongguancun Laboratory
                                                            2 March 2026


    Selective Synchronization Extension for RPKI-to-Router Protocol
                draft-geng-sidrops-rtr-selective-sync-06

Abstract

   The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI
   data to routers.  This document proposes to extend the existing RTR
   protocol to support selective data synchronization.  Selective
   synchronization can avoid unnecessary transmissions.  The router can
   receive only the data that it really needs.

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 3 September 2026.

Copyright Notice

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

   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



Geng, et al.            Expires 3 September 2026                [Page 1]

Internet-Draft      Selective Synchronization for RTR         March 2026


   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.  Subscribing Data PDU  . . . . . . . . . . . . . . . . . . . .   4
   3.  Process of Subscribing Data . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The RPKI-to-Router (RTR) protocol helps synchronize the validated
   RPKI data from a trusted cache to routers.  There are already several
   versions of the protocol
   [RFC6810][RFC8210][I-D.ietf-sidrops-8210bis].  The supported types of
   data that can be transferred increase, which is shown in Table 1.

                +=============+=============+=============+
                |  Version 0  |  Version 1  |  Version 2  |
                +=============+=============+=============+
                | IPv4 Prefix | IPv4 Prefix | IPv4 Prefix |
                +-------------+-------------+-------------+
                | IPv6 Prefix | IPv6 Prefix | IPv6 Prefix |
                +-------------+-------------+-------------+
                |             |  Router Key |  Router Key |
                +-------------+-------------+-------------+
                |             |             |     ASPA    |
                +-------------+-------------+-------------+

                      Table 1: Supported data types in
                   different versions of the RTR protocol

   However, in some cases, routers may be interested in a part of RPKI
   data types, instead of all.  In such cases, synchronizing all types
   of data to routers is unreasonable.








Geng, et al.            Expires 3 September 2026                [Page 2]

Internet-Draft      Selective Synchronization for RTR         March 2026


   Furthermore, there may be more types of RPKI data in the RPKI
   repositories and RPs in the future.  Ignoring the router's
   requirements and directly synchronizing all types of data to the
   router may induce unnecessary and non-negligible transmission
   overheads.  The followings are example types, and some of them may be
   possibly supported in the RPKI system in the future:

   *  Secured Routing Policy Specification Language (RPSL) [RFC7909]

   *  Signed Prefix Lists [I-D.ietf-sidrops-rpki-prefixlist]

   *  Autonomous Systems Cones [I-D.ietf-grow-rpki-as-cones]

   *  Mapping Origin Authorizations (MOAs) [I-D.xie-sidrops-moa-profile]

   *  Signed SAVNET-Peering Information (SiSPI) [I-D.chen-sidrops-sispi]

   *  Path validation with RPKI [I-D.van-beijnum-sidrops-pathrpki]

   *  Signed Groupings of Autonomous System Numbers
      [I-D.spaghetti-sidrops-rpki-asgroup]

   *  Autonomous System Relationship Authorization (ASRA)
      [I-D.geng-sidrops-asra-profile]

   This document extends the RTR protocol to support selective data
   synchronization.  The RTR client can subscribe to specific types of
   RPKI data from the server via the Subscribe PDU.  After a successful
   subscription, the server will only synchronize the subscribed types
   of RPKI data to the corresponding client, reducing unnecessary data
   transmission and improving efficiency.  The extension is valuable for
   scenarios where routers require only specific RPKI data types to meet
   their operational needs.

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.










Geng, et al.            Expires 3 September 2026                [Page 3]

Internet-Draft      Selective Synchronization for RTR         March 2026


2.  Subscribing Data PDU

   This document defines a new type of PDU for the RTR protocol,
   specifically named the Subscribing Data PDU.  The purpose of this new
   RTR PDU is to enable a router to explicitly indicate to the RTR
   server the specific types of RPKI data it is interested in receiving.
   The format of the Subscribing Data PDU is illustrated in Figure 1,
   which outlines the structure and arrangement of each field within the
   PDU.

   0          8          16         24        31
   .-------------------------------------------.
   | Protocol |   PDU    |                     |
   | Version  |   Type   |         Zero        |
   |          |          |                     |
   +-------------------------------------------+
   |                                           |
   |                  Length                   |
   |                                           |
   +-------------------------------------------+
   |  Data    |          |         | Data      |
   |  Type 1  | ...      | ...     | Type N    |
   |          |          |         |           |
   `-------------------------------------------'

                  Figure 1: Format of Subscribing Data PDU

   The Subscribing Data PDU contains the following data elements.  Note
   that all fields within the Subscribing Data PDU, except for the newly
   introduced PDU Type field and Data Type fields, retain the same
   meanings as defined in the existing RTR protocol
   [I-D.ietf-sidrops-8210bis].

   *  Protocol Version: An 8-bit unsigned integer.  To support this new
      PDU type, a new version of the RTR protocol (e.g., 3) will be
      required, as the existing protocol version does not include
      provisions for this subscription mechanism.

   *  PDU Type: An 8-bit unsigned integer.  A new PDU Type value (TBD)
      is required for the Subscribing Data PDU.

   *  Zero: All bits SHOULD be set to 0.  The field MUST be ignored when
      parsing the PDU.

   *  Length: A 32-bit unsigned integer which has as its value the count
      of the octets in the entire PDU, including the 8 octets of header
      which includes the length field.  The meaning and limitation keep
      same as the existing RTR protocol.



Geng, et al.            Expires 3 September 2026                [Page 4]

Internet-Draft      Selective Synchronization for RTR         March 2026


   *  Data Types: A list of 8-bit unsigned integers, where each integer
      specifies a Data Type that the router intends to subscribe to.  It
      is explicitly defined that the values assigned to these Data Type
      fields are consistent with the PDU Type values that have already
      been allocated to different types of RTR data in the existing RTR
      protocol, ensuring consistency with the existing RTR protocol
      specifications and avoiding any ambiguity in data type
      identification.  Currently, the valid values for the Data Type
      fields (corresponding to the supported RTR data types) are as
      follows: 4 for IPv4 Prefix data, 6 for IPv6 Prefix data, 9 for
      Router Key data, and 11 for Autonomous System Provider
      Authorization (ASPA) data.  Additional valid values may be added
      in future protocol versions as new RTR data types are defined.  If
      the Subscribing Data PDU does not carry any Data Type fields, this
      indicates that the router subscribes to all data types supported
      by the current version of the RTR protocol.

3.  Process of Subscribing Data

   A router may send a Subscribing Data PDU to subscribe to specific RTR
   data at any stage after establishing an RTR session with the RTR
   server.  It is required that a single Subscribing Data PDU carry the
   complete subscription information.  The subscription information MUST
   NOT be split and carried across multiple Subscribing Data PDUs.  If
   the router intends to update its existing subscription, it can send a
   new Subscribing Data PDU, which will overwrite the previous
   subscription entirely.  When the router changes its subscription
   information, it shall determine how to handle the data it has already
   received and stored locally that is not within the scope of the new
   subscription (e.g., deleting data that is no longer in the new
   subscription scope).

   If a router does not send any Subscribing Data PDU after establishing
   the RTR session, or if the sent Subscribing Data PDU does not carry
   any Data Type fields, this indicates that the router subscribes to
   all data types supported by the current version of the RTR protocol.
   If the Data Type fields carried in the Subscribing Data PDU contain
   duplicate values, the RTR server shall simply ignore the duplicate
   entries and only process each unique Data Type value once, ensuring
   that the subscription configuration is consistent and free of
   redundant entries.










Geng, et al.            Expires 3 September 2026                [Page 5]

Internet-Draft      Selective Synchronization for RTR         March 2026


   The RTR server is required to maintain subscription information for
   each active RTR session individually.  When synchronizing data
   (either full synchronization or incremental synchronization) to the
   router through a session, the server shall check the subscription
   information corresponding to that session and only synchronize the
   data types that the router has subscribed to, thereby avoiding the
   transmission of unnecessary data.

   It is important to note that the server's implementation of the
   Serial Number remains unchanged.  The cache still maintains a single
   Serial Number, regardless of the subscription configurations of
   different sessions.  This design minimizes the need for extensive
   modifications to existing RTR protocol implementations.

   There may be scenarios where data on the RTR server is updated, and
   the server sends a Serial Notify PDU to the router to inform it of
   the new data availability.  However, when the router sends a Serial
   Query PDU to request the updated data, all requested data may be
   filtered out by the server.  This occurs when the updated data does
   not match any of the data types the router has subscribed to.

4.  IANA Considerations

   The proposal requires a new version value (e.g., 3) for the RTR
   protocol.

   All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu]
   in protocol versions 0, 1, and 2 are also allowed in protocol version
   3, with the addition of the new Subscribing Data PDU.  The type value
   of the new PDU needs to be allocated.  The "rpki-rtr-pdu" registry
   needs to be updated as follows:




















Geng, et al.            Expires 3 September 2026                [Page 6]

Internet-Draft      Selective Synchronization for RTR         March 2026


         Protocol   PDU
         Version    Type  Description
         --------   ----  ---------------
           0-2        0   Serial Notify
           0-2        1   Serial Query
           0-2        2   Reset Query
           0-2        3   Cache Response
           0-2        4   IPv4 Prefix
           0-2        6   IPv6 Prefix
           0-2        7   End of Data
           0-2        8   Cache Reset
             0        9   Reserved
           1-2        9   Router Key
           0-2       10   Error Report
           0-1       11   Reserved
             2       11   ASPA
             3      TBD   Subscribing Data
           0-3      255   Reserved

5.  Security Considerations

   The security considerations of [I-D.ietf-sidrops-8210bis] also
   applies to this document.

6.  References

6.1.  Normative References

   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol", RFC 6810,
              DOI 10.17487/RFC6810, January 2013,
              <https://www.rfc-editor.org/info/rfc6810>.

   [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-8210bis]
              Bush, R., Austein, R., and T. Harrison, "The Resource
              Public Key Infrastructure (RPKI) to Router Protocol,
              Version 2", Work in Progress, Internet-Draft, draft-ietf-
              sidrops-8210bis-24, 5 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
              8210bis-24>.

   [iana-pdu] "rpki-rtr-pdu", n.d.,
              <https://www.iana.org/assignments/rpki#rpki-rtr-pdu>.



Geng, et al.            Expires 3 September 2026                [Page 7]

Internet-Draft      Selective Synchronization for RTR         March 2026


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

6.2.  Informative References

   [RFC7909]  Kisteleki, R. and B. Haberman, "Securing Routing Policy
              Specification Language (RPSL) Objects with Resource Public
              Key Infrastructure (RPKI) Signatures", RFC 7909,
              DOI 10.17487/RFC7909, June 2016,
              <https://www.rfc-editor.org/info/rfc7909>.

   [I-D.van-beijnum-sidrops-pathrpki]
              van Beijnum, I., "Path validation with RPKI", Work in
              Progress, Internet-Draft, draft-van-beijnum-sidrops-
              pathrpki-00, 20 June 2019,
              <https://datatracker.ietf.org/doc/html/draft-van-beijnum-
              sidrops-pathrpki-00>.

   [I-D.ietf-grow-rpki-as-cones]
              Snijders, J., stucchi-lists@glevia.com, and M. Aelmans,
              "RPKI Autonomous Systems Cones: A Profile To Define Sets
              of Autonomous Systems Numbers To Facilitate BGP
              Filtering", Work in Progress, Internet-Draft, draft-ietf-
              grow-rpki-as-cones-02, 24 April 2020,
              <https://datatracker.ietf.org/doc/html/draft-ietf-grow-
              rpki-as-cones-02>.

   [I-D.spaghetti-sidrops-rpki-asgroup]
              Snijders, J. and F. Korsbäck, "A profile for RPKI Signed
              Groupings of Autonomous System Numbers (ASGroup)", Work in
              Progress, Internet-Draft, draft-spaghetti-sidrops-rpki-
              asgroup-00, 16 November 2022,
              <https://datatracker.ietf.org/doc/html/draft-spaghetti-
              sidrops-rpki-asgroup-00>.

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



Geng, et al.            Expires 3 September 2026                [Page 8]

Internet-Draft      Selective Synchronization for RTR         March 2026


   [I-D.xie-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-xie-sidrops-moa-profile-
              06, 26 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-xie-sidrops-
              moa-profile-06>.

   [I-D.chen-sidrops-sispi]
              Chen, L., Liu, L., Li, D., and L. Qin, "A Profile of
              Signed SAVNET-Peering Information (SiSPI) Object for
              Deploying Inter-domain SAVNET", Work in Progress,
              Internet-Draft, draft-chen-sidrops-sispi-04, 14 September
              2025, <https://datatracker.ietf.org/doc/html/draft-chen-
              sidrops-sispi-04>.

   [I-D.geng-sidrops-asra-profile]
              Geng, N., Sriram, K., and M. Huang, "A Profile for
              Autonomous System Relationship Authorization (ASRA)", Work
              in Progress, Internet-Draft, draft-geng-sidrops-asra-
              profile-02, 17 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-geng-sidrops-
              asra-profile-02>.

Authors' Addresses

   Nan Geng
   Huawei
   Beijing
   China
   Email: gengnan@huawei.com


   Shunwan Zhuang
   Huawei
   Beijing
   China
   Email: zhuangshunwan@huawei.com


   Yu Fu
   China Telecom
   Beijing
   China
   Email: fuy44@chinatelecom.cn






Geng, et al.            Expires 3 September 2026                [Page 9]

Internet-Draft      Selective Synchronization for RTR         March 2026


   Mingqing Huang
   Zhongguancun Laboratory
   Beijing
   China
   Email: huangmq@mail.zgclab.edu.cn














































Geng, et al.            Expires 3 September 2026               [Page 10]
