Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

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

Versions:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Document	Type	Active Internet-Draft (individual)
	Authors	Nan Geng , Shunwan Zhuang , Yu Fu , Mingqing(Michael) Huang
	Last updated	2026-03-01
	RFC stream	(None)
	Intended RFC status	(None)
	Formats	txt html xml htmlized bibtex bibxml
	Additional resources	GitHub Repository
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Search email archive

draft-geng-sidrops-rtr-selective-sync-06

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.

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.

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]

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

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