]> 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 and Notation Conventions

Requirements Notation 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.

Terminology The following terms are defined in and are not redefined here:

• augment
• data model
• data node
• module
• namespace
• YANG

Tree Diagrams Tree diagrams used in this document follow the notation defined in .

Data Model Overview This document defines two YANG modules: "ietf-rpki-rtr" and "ietf-rpki-table". The "ietf-rpki-rtr" YANG module 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 module 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 full tree of the "ietf-rpki-rtr" YANG module is provided in . The following subsections list the subtree structures.

Overall Structure The overall tree structure of the "ietf-rpki-rtr" YANG module is shown in . The "ietf-rpki-rtr" YANG module augments the core routing YANG module "ietf-routing" specified in for managing RTR protocol sessions. Specifically, this YANG module augments "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol".

Overall RPKI to Router Tree Structure

The "ietf-rpki-rtr" YANG module has a root container 'rpki-rtr', which has a subcontainer 'sessions'. The container 'sessions' contains a list 'session', where each entry represents a session configuration and state to a specific RPKI cache server.

RTR Session Configuration The RTR session configuration structure for the list 'session' is shown in .

RTR Session Configuration Subtree Structure

The configuration data nodes for the list 'session' are described as follows: 'server-address': Indicates the IP address of the RPKI cache server. 'server-port': Indicates the port number the server listens on. 'local-address': Indicates the source IP address used when initiating a RTR session connection locally. 'local-port': Indicates the source port number used when initiating a RTR session connection locally. 'enabled': Indicates the management switch for the RTR session. 'preference': Indicates the priority for connecting to the RPKI cache server. 'description': Indicates the description information for the RTR session. 'reconnect-interval': Indicates the reconnection interval after session disconnection. 'enable-authentication': Indicates the switch to enable connection authentication for the RTR session. 'authentication': Indicates the configuration information of connection authentication for the RTR session, as shown in .

RTR Session Authentication Subtree Structure

'vrp-limit' (): Indicates the limit configuration on the number of VRP record received from the RTR session. 'aspa-limit' (): Indicates the limit configuration on the number of ASPA record received from the RTR session.

RTR Session Received Record Limit Subtree Structure

In , 'vrp-limit' and 'aspa-limit' have the same structure, both having the maximum number of records allowed to be received from the RTR session ('max-number'), the threshold percentage for record maximum number ('threshold-percentage'), and handling strategy when exceeding the record threshold ('over-threshold-action').

RTR Session State The RTR session state structure for the list 'session' is shown in .

RTR Session State Subtree Structure

The state data nodes for the list 'session' are described as follows: 'session-state': Indicates the connection status of the RTR session. 'statistics': Indicates the statistics of RPKI records or messages received from the server of the RTR session, as shown in .

RTR Session Statistics Subtree Structure

'connection-data': Indicates the state information relating to the session connection with the RPKI cache server, as shown in .

RTR Session Connection Data Subtree Structure

'protocol-data': Indicates state parameters related to the RTR protocol of the session, as shown in .

RTR Session Protocol Data Subtree Structure

'pdu-counters': Indicates the send and receive statistics of various types of RTR PDUs, as shown in .

RTR Session PDU Counters Subtree Structure

'error-pdu-counters': Indicates error PDU statistics during RTR protocol interaction, as shown in .

RTR Session Error PDU Counters Subtree Structure

YANG Module This YANG module has normative references to , , , , , , , , and . 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"; } 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 rt-types:percentage; 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 "Disconnects with the RPKI cache server, and tries to reconnect after reconnection timer expires."; } enum idle-forever { description "Disconnects with the RPKI cache server forever."; } } description "The action to taken when record number exceeds threshold."; } } 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 reconnect-interval { type uint32 { range "1..30000"; } units "minutes"; description "Time interval for the reconnection timer."; } 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 securing 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."; } 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 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 hundredths of a second 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 { type yang:timestamp; description "Time of last serial sync with cache server."; } leaf last-full-sync { type yang:timestamp; description "Time of last reset sync with cache server."; } leaf last-serial-query { type yang:timestamp; description "Time of last serial query sent to cache server."; } leaf last-reset-query { 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 { type yang:timestamp; description "Time of last host, port, VRF or local interface change."; } leaf last-error { type yang:timestamp; description "Time of sending/receiving protocol error to/from cache server."; } leaf last-connection-error { type yang:timestamp; description "Time of last connection error to cache server."; } leaf last-connection { 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"; } } 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 "Error PDU statistics during RTR protocol interaction"; 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 full tree of the "ietf-rpki-table" YANG module is provided in . The following subsections list the subtree structures.

Overall Structure The overall tree structure of the "ietf-rpki-table" YANG module is shown in . The "ietf-rpki-table" YANG module also augments the core routing YANG module "ietf-routing" specified in . Specifically, this YANG module augments "/rt:routing".

Overall RPKI Table Tree Structure

The "ietf-rpki-rtr" YANG module has three containers: 'vrp-tables', 'router-key-tables', and 'aspa-tables'. The 'vrp-tables' container lists the VRP records received from all RPKI cache servers, and each list 'vrp-table' identifies a VRP record table received from a RPKI cache server. The 'router-key-tables' container lists the Router Key records received from all RPKI cache servers, and each list 'router-key-table' identifies a Router Key record table received from a RPKI cache server. The 'aspa-tables' container lists the ASPA records received from all RPKI cache servers, and each list 'aspa-table' identifies an ASPA record table received from a RPKI cache server.

VRP Table The structure of the list 'vrp-table' is shown in .

RPKI VRP Table Subtree Structure

The 'vrp-table' data nodes are described as follows: 'name': Indicates the name of the VRP table. 'ccr-roapayloadstate-hash': Indicates the CCR state hash for the ROA payload. 'ipv4': Indicates detailed information and statistics of IPv4 VRP records in the VRP table. 'ipv6': Indicates detailed information and statistics of ipv6 VRP records in the VRP table.

Router Key Table The structure of the list 'router-key-table' is shown in .

RPKI Router Key Table Subtree Structure

The 'router-key-table' data nodes are described as follows: 'name': Indicates the name of the Router Key table. 'ccr-routerkeystate-hash': Indicates the CCR state hash for the Router Key payload. 'router-keys': Indicates detailed information of Router Key records in the Router Key table.

ASPA Table The structure of the list 'aspa-table' is shown in .

RPKI ASPA Table Subtree Structure

The 'aspa-table' data nodes are described as follows: 'name': Indicates the name of the ASPA table. 'ccr-aspapayloadstate-hash': Indicates the CCR state hash for the ASPA payload. 'aspas': Indicates detailed information of ASPA records in the ASPA table.

YANG Module This YANG module has normative references to , , , , and . 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 data 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-prefix-length { type uint8 { range "0 .. 32"; } description "IPv4 Prefix Length."; } typedef ipv6-prefix-length { type uint8 { range "0 .. 128"; } description "IPv6 Prefix Length."; } typedef subject-key-id { type binary { length "20"; } description "Subject Key Identifier."; } typedef ccr-hash { type binary { length "32"; } description "Canonical Cache Representation (CCR) state hash. This represents a 256-bit SHA-256 hash of the canonical representation of RPKI data as defined in RFC YYYY. The hash provides a compact, verifiable representation of the complete state of RPKI validation data, enabling efficient synchronization and consistency verification between caches."; reference "RFC YYYY: A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)"; } grouping aspa-overall-records { description "Autonomous System Provider Authorization (ASPA) records received from all RPKI cache servers."; list aspas { key "customer-asn"; description "An entry for ASPA."; leaf customer-asn { type inet:as-number; description "The AS number of a customer."; } leaf server-address { type inet:ip-address; description "IP address of the RPKI cache server."; } list provider-asns { key "provider-asn"; description "Providers of the customer."; leaf provider-asn { type inet:as-number; description "The AS number of a provider."; } } } } augment "/rt:routing" { description "RPKI tables augmentation of ietf-routing module."; container vrp-tables { config false; description "List of tables containing Validated ROA Payloads received from all RPKI cache servers."; list vrp-table { key "name"; description "Table of Validated ROA Payloads received from a RPKI cache server."; leaf name { type string; description "Name of the Validated ROA Payload table."; } leaf ccr-roapayloadstate-hash { type ccr-hash; description "CCR state hash for the ROA payload. This hash represents the canonical state of this specific ROA entry as defined in the CCR specification. It is optional and can be used to verify the integrity and consistency of ROA data originating from the RPKI cache."; reference "RFC YYYY: A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)"; } container ipv4 { config false; description "Container for IPv4 Validated ROA Payloads table."; container vrps { config false; description "IPv4 Validated ROA Payloads received from the RPKI cache server."; list vrp { key "prefix max-len asn source"; description "An entry of IPv4 Validated ROA Payload."; leaf prefix { type inet:ipv4-prefix; description "The IPv4 prefix of the IPv4 Validated ROA Payload."; } leaf max-len { type ipv4-prefix-length; description "Denotes the longest IPv4 prefix allowed. This MUST NOT be less than the IPv4 prefix length."; } leaf asn { type inet:as-number; description "The origin AS number of the IPv4 Validated ROA Payload."; } leaf source { type union { type string; type inet:ip-address; } description "String representing the source of the record in this record-set."; } } } leaf total-records { type yang:gauge32; description "Total number of IPv4 Validated ROA Payload records."; } leaf records-added { type yang:counter64; description "Number of IPv4 Validated ROA Payload records cumulatively added."; } leaf records-deleted { type yang:counter64; description "Number of IPv4 Validated ROA Payload records cumulatively deleted."; } } container ipv6 { config false; description "Container for IPv6 Validated ROA Payloads table."; container vrps { config false; description "IPv6 Validated ROA Payloads received from the RPKI cache server."; list vrp { key "prefix max-len asn source"; description "An entry for IPv6 Validated ROA Payload."; leaf prefix { type inet:ipv6-prefix; description "The IPv6 prefix of the IPv6 Validated ROA Payload."; } leaf max-len { type ipv6-prefix-length; description "Denotes the longest IPv6 prefix allowed. This MUST NOT be less than the prefix length."; } leaf asn { type inet:as-number; description "The origin AS number of the IPv6 Validated ROA Payload."; } leaf source { type union { type string; type inet:ip-address; } description "Representing the source of the record in this record-set. Either a server IP or a source file of static records."; } } } leaf total-records { type yang:gauge32; description "Total number of IPv6 Validated ROA Payload records."; } leaf records-added { type yang:counter64; description "Number of IPv6 Validated ROA Payload records cumulatively added."; } leaf records-deleted { type yang:counter64; description "Number of IPv6 Validated ROA Payload records cumulatively deleted."; } } } } container router-key-tables { config false; description "List of Router Key table received from all RPKI cache servers."; list router-key-table { key "name"; description "Table of Router Keys received from a RPKI cache server."; leaf name { type string; description "Name of the Router Key table."; } leaf ccr-routerkeystate-hash { type ccr-hash; description "CCR state hash for the Router Key payload. This hash represents the canonical state of this specific Router Key entry as defined in the CCR specification. It is optional and can effectively verify the consistency of BGPsec Router Key data derived from the RPKI cache."; reference "RFC YYYY: A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)"; } container router-keys { config false; description "Router Keys received from the RPKI cache server."; list router-key { key "ski asn key server-address"; description "An entry for Router Key."; leaf ski { type subject-key-id; description "A Router Key's Subject Key Identifier (SKI)."; reference "RFC 6487: A Profile for X.509 PKIX Resource Certificates"; } leaf asn { type inet:as-number; description "The AS number of the router which the key belongs to."; } leaf key { type binary; description "A Router Key's subjectPublicKeyInfo value, as described in Section 3.1.1 of RFC 8608, encoded using ASN.1 Distinguished Encoding Eules (DER)."; reference "RFC 8608: BGPsec Algorithms, Key Formats, and Signature Formats"; } leaf server-address { type inet:ip-address; description "IP address of the RPKI cache server."; } } } } } container aspa-tables { config false; description "List of tables of ASPAs received from all RPKI cache servers."; list aspa-table { key "name"; description "Table of ASPAs received from a RPKI cache server."; leaf name { type string; description "Name of the ASPA table."; } leaf ccr-aspapayloadstate-hash { type ccr-hash; description "CCR state hash for the ASPA payload. This hash represents the canonical state of this specific ASPA entry as defined in the CCR specification. It is optional and facilitates consistency checking for AS path validation data originating from the RPKI cache."; reference "RFC YYYY: A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)"; } uses aspa-overall-records; } } } } ]]>

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. Thanks to Per Andersson for the Yangdoctors Early review.

References Normative References 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. 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 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] This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] 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] This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. 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). 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. This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. 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. This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. 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. This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022. This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. This document presents three IETF-defined YANG modules and a script used to create four supporting IANA modules. The three IETF modules are ietf-ssh-common, ietf-ssh-client, and ietf-ssh-server. The "ietf-ssh-client" and "ietf-ssh-server" modules are the primary productions of this work, supporting the configuration and monitoring of Secure Shell (SSH) clients and servers. The four IANA modules are iana-ssh-encryption-algs, iana-ssh-key-exchange-algs, iana-ssh-mac-algs, and iana-ssh-public-key-algs. These modules each define YANG enumerations providing support for an IANA-maintained algorithm registry. RFC 9911, DOI 10.17487/RFC9911 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. 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 Distinguished Encoding Rules (DER) encoded data interchange format which can be used to represent various aspects of the state of a validated RPKI cache at a particular point in time. The CCR profile is a compact and versatile format, well-suited for a variety of applications, for example, audit trails, analytics pipelines, and validated payload dissemination. Informative References 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] 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] 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. 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). 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. 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. 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. 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.

Full Tree of RPKI to Router YANG Module

Full Tree of RPKI Table YANG Module

Contributors H3C

China chen.mengxiao@h3c.com

HPE

santosh.kolenchery@hpe.com

H3C

China zhang.haiyanga@h3c.com