YANG Data Model for RPKI to Router Protocol

YANG Data Model for RPKI to Router Protocol China Mobile

32 Xuanwumen West Street Beijing Xicheng District 100053 China liuyisong@chinamobile.com

New H3C Technologies

8 Yongjia North Road Beijing Haidian District 100094 China linchangwang.04414@h3c.com

Huawei Technologies

China rainsword.wang@huawei.com

HPE

1133 Innovation Way Sunnyvale, CA 94089 United States of America jishnu.roy@hpe.com

HPE

1133 Innovation Way Sunnyvale, CA 94089 United States of America jeffrey.haas@hpe.com

ZTE Corporation

China liu.hongwei3@zte.com.cn

ZDNS

Floor 21, Block B, Greenland Center Chaoyang Beijing, 100102 China madi@zdns.cn

Ops SIDROPS Working Group YANG, RPKI, RTR This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210).

Introduction and describes a protocol to deliver Resource Public Key Infrastructure (RPKI) prefix origin data and router keys from a trusted cache server to a router, referred to as the RPKI to Router (RTR) protocol. describes version 2 of the RTR protocol, which adds a new Autonomous System Provider Authorization (ASPA)) PDU type. This document defines YANG data models for managing RTR protocol (, , and ).

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

Model Overview Two YANG data models are defined in this document. The ietf-rpki-rtr.yang data model provides the methods for managing RTR protocol. It includes:

Connectivity parameters, such as RPKI cache server IP address and destination port.
Session parameters, such as purge time, refresh time, response time.
Session status and statistics, such as session ID, serial number, number of received and transmitted messages.

The ietf-rpki-table.yang data model provides the methods for managing records of RTR protocol and the corresponding state hash which is a hash value used in the Canonical Cache Representation (CCR) content . It includes:

Validated ROA Payload (VRP) records.
Router key records.
ASPA records.
CCR state hash, which is optional and is used to verify the integrity and consistency of RPKI data originating from the RPKI cache.

RPKI to Router YANG Module

Tree View The complete tree of the "ietf-rpki-rtr" YANG module is represented as following. See for an explanation of the symbols used.

YANG Module WG List: SIDROPS Editor: Yisong Liu Editor: Changwang Lin Editor: Haibo Wang Editor: Jishnu Roy Editor: Jeffrey Haas Editor: Hongwei Liu Editor: Di Ma "; description "This module describes a YANG model for the Resource Public Key Infrastructure (RPKI) to Router (RTR) protocol management. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-03-31 { description "Initial Version"; reference "RFC XXXX: YANG Data Model for RPKI to Router Protocol"; } typedef ipv4-pfx-len { type uint8 { range "0 .. 32"; } description "IPv4 Prefix Length."; } typedef ipv6-pfx-len { type uint8 { range "0 .. 128"; } description "IPv6 Prefix Length."; } typedef subject-key-id { type binary { length 20; } description "Subject Key Identifier."; } identity rpki-rtr { base rt:routing-protocol; description "RTR protocol."; } grouping records-limit { description "Limit of records that can be received from the RPKI cache server."; leaf max-number { type uint64; description "Configures the maximum number of records that can be received from the RPKI cache server."; } leaf threshold-percentage { type uint8 { range "0..100"; } units "percent"; description "Configures the threshold percentage for record maximum number."; } leaf over-threshold-action { type enumeration { enum alert-only { description "Generates alert messages."; } enum discard { description "Discards excess records."; } enum reconnect { description "Diconncets with the RPKI cache server, and tries to reconnect after reconnection timer expires."; } enum idle-forever { description "Diconncets with the RPKI cache server forever."; } } description "The action to taken when record number exceeds threshold."; } leaf reconnect-interval { type uint32 { range "1..30000"; } units "minutes"; description "Time interval for the reconnection timer."; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'rpki-rtr')" { description "This augmentation is valid for a routing protocol instance of RTR."; } description "RTR protocol augmentation of ietf-routing module control-plane-protocol."; container rpki-rtr { description "Configuration parameters for the RTR protocol."; container sessions { description "Parameters of RPKI sessions to cache servers."; list session { key "server-address"; description "Each entry contains parameters for a RPKI session identified by the 'server-address' key."; leaf server-address { type inet:ip-address; mandatory true; description "The IP address of the RPKI cache server resembling a session"; } leaf server-port { type inet:port-number; description "The remote port for the connection to the RPKI cache server"; } leaf local-address { type union { type inet:ip-address; type if:interface-ref; } description "The local IP (either IPv4 or IPv6) address to use for the connection to the RPKI cache server. This may be expressed as either an IP address or reference to the name of an interface."; } leaf local-port { type inet:port-number; description "The local port for the connection to the RPKI cache server"; } leaf enabled { type boolean; default "true"; description "Whether the RPKI cache server is enabled."; } leaf preference { type uint32; description "The router's preference to connect to that cache. The lower the value, the more preferred."; } leaf description { type string; description "Textual description of the RPKI cache server"; } leaf session-state { type enumeration { enum idle { description "The session is down."; } enum connect { description "The session is waiting for the underlying transport session to be established."; } enum establish { description "The session is up."; } enum ex-incr { description "Incremental update of records in progress."; } enum ex-full { description "Full update of records in progress."; } } config false; description "The session state."; } leaf enable-authentication { type boolean; default "false"; description "Whether the session is secured."; } container authentication { when "../enable-authentication = 'true'"; description "Container for describing how a particular session is to be secured."; choice option { description "Choice for session secruring methods."; case md5 { leaf md5-password { type ianach:crypt-hash; description "The password for md5 authentication."; } description "Uses TCP-MD5 to secure the session."; } case ssh { uses ssh:ssh-client-grouping { reference "RFC 9644: YANG Groupings for SSH Clients and SSH Servers"; } description "Uses SSH to secure the session."; } case tcp-ao-keychain { leaf keychain-name { type key-chain:key-chain-ref; description "Name of key chain."; reference "RFC 8177: YANG Data Model for Key Chains"; } description "Uses key-chain to secure the session."; } } } container vrp-limit { description "Limit of Validated ROA Payload records that can be received from the RPKI cache server."; uses records-limit; } container aspa-limit { description "Limit of Autonomous System Provider Authorization (ASPA) records that can be received from the RPKI cache server."; uses records-limit; } container statistics { config false; description "Statistics of the RPKI cache server."; leaf total-vrp-records { type yang:zero-based-counter64; description "The total number of Validated ROA Payloads received from the RPKI cache server."; } leaf ipv4-vrp-records { type yang:zero-based-counter64; description "The number of Validated ROA Payloads for IPv4 prefixes received from the RPKI cache server."; } leaf ipv6-vrp-records { type yang:zero-based-counter64; description "The number of Validated ROA Payloads for IPv6 prefixes received from the RPKI cache server."; } leaf router-key-records { type yang:zero-based-counter64; description "The number of router keys received from the RPKI cache server."; } leaf aspa-records { type yang:zero-based-counter64; description "The number of ASPAs received from the RPKI cache server."; } } container connection-data { config false; description "State information relating to the connection with the RPKI cache server."; leaf flaps { type uint32; description "Count for number of flaps observed on the session."; } leaf last-session-up-down { type yang:timestamp; description "This timestamp indicates the time that the RPKI-RTR session last transitioned in or out of the UP state. The value is the timestamp in microseconds relative to the Unix Epoch (Jan 1, 1970 00:00:00 UTC). The RPKI-RTR session uptime can be computed by clients as the difference between this value and the current time in UTC (assuming the session is in the UP state, per the session-state leaf)."; reference "RFC 6810: The Resource Public Key Infrastructure (RPKI) to Router Protocol"; } leaf last-update-sync-timestamp { type yang:timestamp; description "Time of last serial sync with cache server."; } leaf last-full-sync-timestamp { type yang:timestamp; description "Time of last reset sync with cache server."; } leaf last-serial-query-timestamp { type yang:timestamp; description "Time of last serial query sent to cache server."; } leaf last-reset-query-timestamp { type yang:timestamp; description "Time of last reset query sent to cache server."; } leaf last-eod-received { type yang:timestamp; description "Time in microseconds at which last EOD was received."; } leaf last-config-change-timestamp { type yang:timestamp; description "Time of last host, port, VRF or local interface change."; } leaf last-error-timestamp { type yang:timestamp; description "Time of sending/receiving protocol error to/from cache server."; } leaf last-connection-error-timestamp { type yang:timestamp; description "Time of last connection error to cache server."; } leaf last-connection-timestamp { type yang:timestamp; description "Time of last connection to cache server."; } leaf error-reason { type string; description "Reason for error in connection."; } } container protocol-data { config false; description "State parameters related to the RTR protocol"; leaf protocol-version { type uint32; description "The version number of the RTR protocol."; } leaf refresh-time { type yang:timestamp; description "Configures the time a router waits in between sending periodic serial queries to the RPKI cache server."; } leaf response-time { type yang:timestamp; description "Configures the time a router waits for a response after sending a serial or reset query to the RPKI cache server."; } leaf purge-time { type yang:timestamp; description "Configures the time a router waits to keep data from the RPKI cache server after the session drops."; } leaf hold-time { type yang:timestamp; description "Hold-time for this session."; } leaf record-lifetime { type yang:timestamp; description "Record-lifetime this session."; } leaf retry-interval { type uint32; description "Number of seconds between poll error and cache server poll"; } leaf expire-interval { type uint32; description "Number of seconds to retain data synced from cache server"; } leaf session-id { type uint16; config false; description "When a cache server is started, it generates a Session ID to identify the instance of the cache and to bind it to the sequence of Serial Numbers that cache instance will generate."; reference "RFC 6810: The Resource Public Key Infrastructure (RPKI) to Router Protocol RFC 8210: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1"; } leaf serial-full { type uint32; config false; description "A 32-bit strictly increasing unsigned integer which wraps from 2^32-1 to 0. It denotes the logical version of a cache. It resembles the latest full query."; reference "RFC 6810: The Resource Public Key Infrastructure (RPKI) to Router Protocol RFC 8210: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1"; } leaf serial-incremental { type uint32; config false; description "A 32-bit strictly increasing unsigned integer which wraps from 2^32-1 to 0. It denotes the logical version of a cache. It resembles the latest incremental query."; reference "RFC 6810: The Resource Public Key Infrastructure (RPKI) to Router Protocol RFC 8210: The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1"; } leaf in-total-messages { type yang:zero-based-counter64; description "The total number of messages received from the RPKI cache server."; } leaf out-total-messages { type yang:zero-based-counter64; description "The total number of messages transmitted to the RPKI cache server."; } } container pdu-counters { config false; description "Counters of PDUs that are received from cache"; leaf serial-notify { type yang:zero-based-counter64; description "Serial notify PDU count"; } leaf cache-response { type yang:zero-based-counter64; description "Cache response PDU count"; } leaf ipv4-prefix { type yang:zero-based-counter64; description "IPv4 prefix PDU count"; } leaf ipv6-prefix { type yang:zero-based-counter64; description "Ipv6 prefix PDU count"; } leaf end-of-data { type yang:zero-based-counter64; description "End of data PDU count"; } leaf cache-reset { type yang:zero-based-counter64; description "Cache reset PDU count"; } leaf reset-query { type yang:zero-based-counter64; description "Reset query PDU count"; } leaf serial-query { type yang:zero-based-counter64; description "Serial query PDU count"; } } container error-pdu-counters { config false; description "Counters of error PDUs that originate from router or cache server"; leaf corrupt-data { type yang:zero-based-counter64; description "Corrupt data PDU count"; } leaf internal-error { type yang:zero-based-counter64; description "Internal error PDU count"; } leaf unsupported-protocol-version { type yang:zero-based-counter64; description "Unsupported protocol version PDU count"; } leaf unsupported-pdu-type { type yang:zero-based-counter64; description "Unsupported PDU type count"; } leaf unexpected-protocol-version { type yang:zero-based-counter64; description "Unexpected protocol version PDU count"; } leaf no-data-available { type yang:zero-based-counter64; description "No data available PDU count"; } leaf invalid-request { type yang:zero-based-counter64; description "Invalid request PDU count"; } leaf withdrawal-unknown-record { type yang:zero-based-counter64; description "Withdrawal of unknown record PDU count"; } leaf duplicate-announcement-received { type yang:zero-based-counter64; description "Duplicate announcement received PDU count"; } } } } } } } ]]>

RPKI Table YANG Module

Tree View The complete tree of the "ietf-rpki-table" YANG module is represented as following. See for an explanation of the symbols used.

Implementation Status Note to the RFC Editor - remove this section before publication, as well as remove the reference to . This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Juniper Networks (HPE)

Organization: Juniper Networks (HPE).
Implementation: The following leaves/parameters in description are implemented.
Description: YANG model leaves that are supported:
- Ietf-rpki-rtr.yang
- Ietf-rpki-table.yang
Maturity Level: Ready-for-deployment
Coverage:
Version: Draft-03
Licensing: N/A
Implementation experience: Nothing specific.
Contact: jishnu.roy@hpe.com
Last updated: March 30, 2026

New H3C Technologies

Organization: New H3C Technologies.
Implementation: The following leaves/parameters in description are implemented.
Description: "ietf-rpki-rtr" and "ietf-rpki-table" YANG modules have been implemented in New H3C Products.
Maturity Level: Ready-for-deployment
Coverage: All data nodes of "ietf-rpki-rtr" and "ietf-rpki-table" YANG modules.
Version: Draft-03
Licensing: N/A
Implementation experience: Nothing specific.
Contact: li_meng_limeng@h3c.com
Last updated: March 30, 2026

Security Considerations This section is modeled after the template described in Section 3.7.1 of . The "ietf-rpki-rtr" YANG module and "ietf-rpki-table" YANG module define data models that are designed to be accessed via YANG-based management protocols, such as Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). All writable data nodes are likely to be sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities: Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities: There are no particularly sensitive RPC or action operations.

IANA Considerations

RPKI to Router YANG Module Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group (): IANA is requested to register the following YANG modules in the "YANG Module Names" registry () within the "YANG Parameters" registry group.

RPKI Table YANG Module Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group (): IANA is requested to register the following YANG module in the "YANG Module Names" registry () within the "YANG Parameters" registry group.

Acknowledgments The authors would like to thank Job Snijders, Santosh Kolenchery, Ebben Xavier Aries, Tapasee Ratna Goutam and Haiyang Zhang for their review and discussion of this document.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF XML Registry This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] The Resource Public Key Infrastructure (RPKI) to Router Protocol In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. [STANDARDS-TRACK] The YANG 1.1 Data Modeling Language YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them. This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810. Network Configuration Access Control Model The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2 Arrcus, DRL, & IIJ Research Dragon Research Labs Asia Pacific Network Information Centre In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. Informative References The Secure Shell (SSH) Authentication Protocol The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] Network Configuration Protocol (NETCONF) The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. RESTCONF Protocol This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). YANG Tree Diagrams This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The Transport Layer Security (TLS) Protocol Version 1.3 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Guidelines for Authors and Reviewers of Documents Containing YANG Data Models This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) BSD Software Development RIPE NCC RIPE NCC OpenBSD This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a DER-encoded data interchange format which can be used to represent various aspects of the state of a validated cache at a particular point in time. The CCR profile is a compact and versatile format well-suited for a diverse set of applications such as audit trail keeping, validated payload dissemination, and analytics pipelines.

Contributors H3C

China chen.mengxiao@h3c.com

HPE

santosh.kolenchery@hpe.com

H3C

China zhang.haiyanga@h3c.com