https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/
Draft summary: NRTMv4 is a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other.
The following versions of IRR software have reported to have implemented draft-ietf-grow-nrtm-v4-05. (Future version numbers are expectations and might change)
| Implementation | Version | Reported by |
|---|---|---|
| IRRD | 4.5 (unreleased) | Sasha Romijn |
| RIPE NCC Whois | 1.115.1 (released) | Ed Shryane |
| nrtm4-validator | 0.1.0 (released) | Sasha Romijn |
| Deutsche Telekom nrtm4-client | 0.2.2 (released) | Fedor Vompe |
| nrtm4tools | unreleased | Paul Etchells |
For brevity, Update Notification File is abbreviated as UNF.
| IRRD | RIPE NCC Whois | |
|---|---|---|
| published public key MUST be encoded in PEM (3.1) | yes | yes |
| RECOMMENDED that implementations provide easily accessible tools for operators to generate new signing keys ... and assist with key rotation (3.1) | yes | yes |
| configuration options SHOULD be clearly named to indicate that they are private keys (3.1) | yes | yes |
| MUST follow the initialization steps upon the first export ..., or if the server ... can not reliably produce a continuous set of deltas from a previous state (3.2) | yes | yes |
| (on reinitialization) The mirror server MUST generate a new session ID (3.2) | yes | yes |
| (on reinitialization) server MUST generate a snapshot for version number one (3.2) | yes | yes |
| (on reinitialization) server MUST generate a new UNF with the new session ID, a reference to the new snapshot, and no deltas | yes | yes |
| Changes to IRR objects MUST be recorded in Delta Files (3.3.1) | yes | yes |
| MUST publish a Delta File approximately every minute, if there have been changes ... (3.3.1) | yes | yes |
| If multiple changes have occurred within the time frame that would cancel each other out ... MUST still include all these changes (3.3.1) | yes | yes |
| if lagging in production of Delta Files ... MUST generate one larger "catch up" Delta File (3.3.1) | yes | yes |
| A new Delta File MUST be generated with a new version, one greater than the last Delta File version, or one greater than the last Snapshot File version if there were no prior deltas at all (3.3.1) | yes | yes |
| The Delta File MUST include all changes that happened during the time frame, in the order in which they occurred. (3.3.1) | yes | yes |
| The URL where the Delta File is published MUST contain the session ID and version number ... It MUST also contain a random value that can not be predicted before publication (3.3.1) | yes | yes |
| After generating a new Delta File, a mirror server SHOULD remove all Delta Files older than 24 hours (3.3.1) | yes | yes |
| The UNF MUST be updated to include the new Delta File and update the database version (3.3.1) | yes | yes |
| The mirror server MUST generate a new Snapshot File between once per hour and once per day, if there have been changes to the IRR objects (3.3.2) | yes | yes |
| version number of the new snapshot MUST be equal to the last Delta File version (3.3.2) | yes | yes |
| If there have been no changes to the IRR objects since the last snapshot, the mirror server MUST NOT generate a new snapshot (3.3.2) | ?? | yes |
| URL where the Snapshot File is published MUST contain the session ID and version number ... It MUST also contain a random value that can not be predicted before publication (3.3.2) | yes | yes |
| The UNF MUST be updated to include the new snapshot, if one was generated (3.3.2) | yes | yes |
| SHOULD continue to produce Delta Files during this (snapshot update) window, which means the server MAY publish a Snapshot File with a version number older than the most recent Delta File at the time of publication (3.3.2) | yes/yes | yes |
| UNF must be updated when a new Delta or Snapshot File is published and, even if there have been no changes, at least every 24 hours (3.3.3) | yes | yes |
| MAY have a policy that restricts the publication of certain IRR objects or attributes, or modifies these before publication (3.3.4) | yes | yes |
| RECOMMENDED to modify objects in such a way that this change is evident to humans reading the object text (3.3.4) | yes | yes |
| RECOMMENDED to remove password hashes from the auth lines in mntner objects (3.3.4) | yes | yes |
| a policy that restricts or modifies object publication, this MUST be applied consistently to Snapshot Files and Delta Files from the moment the policy is enacted or modified. | yes | yes |
| IRRD | RIPE NCC Whois | DT nrtm4-client | nrtm4tools | |
|---|---|---|---|---|
| MUST initialize from a Snapshot File when initially configured or if they are not able to update their local data from the provided Delta Files (4.2) | yes | yes | yes | yes |
| MUST retrieve the UNF (4.2 and 4.3) | yes | yes | yes | yes |
| MUST verify that the source attribute in the UNF matches the configured IRR Database name (4.2 and 4.3) | yes | yes | yes | yes |
| (on reinitialization) MUST retrieve the Snapshot File and load the objects into its local storage (4.2) | yes | yes | yes | yes |
| (on reinitialization) MUST verify that the hash of the Snapshot File matches the hash in the UNF that referenced it. If ... compressed with GZIP, the hash MUST match the compressed data. In case of a mismatch of this hash, the file MUST be rejected (4.2) | yes/yes/yes | yes/yes/yes | yes/yes/yes | yes/yes/yes |
| (on reinitialization) MUST record the session_id and version of the loaded Snapshot File (4.2) | yes | yes | yes | yes |
| MUST verify that the session ID matches the previously known session ID. If this does not match, the client MUST reinitialize from the snapshot (4.3) | yes/yes | yes/yes | yes/yes | yes/no |
| MUST verify that the UNF version is the same or higher than the client's current most recent version. If not, the UNF MUST be rejected. It is RECOMMENDED for the client to distinguish between an UNF that is a single version older, and a much older version, in any status messages (4.3) | yes/yes/no | yes/yes/no | yes/yes/yes | yes/yes/no |
| MUST verify that the UNF contains one contiguous set of Delta File versions after the client's current most recent version up to the latest version in the UNF. If ... not contiguous, the UNF MUST be rejected. If the available Delta File versions do not range from the client's most recent version plus one, the client MUST reinitialize from the snapshot (4.3) | yes/yes/yes | yes/yes/yes | yes/yes/yes | yes/yes/no |
| MUST verify that the hashes of each Delta and Snapshot File have not changed compared to previous entries seen for the same file type and version. If a newer UNF contains a different hash for a specific file ... client MUST reject the UNF (4.3) | yes/yes | no/no | yes/yes, only deltas | no/no |
| MUST retrieve all Delta Files for versions since the client's last known version (4.3) | yes | yes | yes | yes |
| MUST verify that the hash of each newly downloaded Delta File matches the hash in the UNF that referenced it. If the Delta File was compressed with GZIP, the hash MUST match the compressed file. In case of a mismatch of this hash, the Delta File MUST be rejected (4.3) | yes/yes/yes | yes/yes/yes | yes/yes/yes | yes/yes/yes |
| MUST process all changes in the Delta Files in order (4.3) | yes | yes | yes | yes |
| MUST update its records of the most recent version to the version of the UNF (4.3) | yes | yes | yes | yes |
| If the UNF or one of the Delta Files is rejected, the mirror client MUST NOT process any newer Deltas than those that are valid and have been successfully verified (4.3) | yes | no | yes | yes |
| If some Delta Files are rejected, it MAY process the valid Delta Files, but MUST NOT skip over any rejected Delta Files while doing so (4.3) | no/NA | no | no/NA | yes |
| Every time a mirror client retrieves a new version of the UNF, it MUST verify the included signature (4.4) | yes | yes | yes | yes |
| The signature MUST be valid for the configured public key for the contents of the UNF (4.4) | yes | yes | yes | yes |
| If the signature does not match, the mirror client MUST reject the UNF, unless a key rotation is in progress (4.4) | yes | yes/NA | yes/yes | no |
| If the generation timestamp is more than 24 hours ago, the file is stale and the mirror client SHOULD warn the operator ... but MAY continue to process it otherwise (4.4) | yes/no (old files are rejected) | no/no | yes (warning)/yes | no/yes |
| MAY have a policy that restricts the processing of objects to certain object classes, or other limitations on which objects it processes .. this MUST be applied consistently to Snapshot Files and Delta Files from the moment the policy is enacted or modified (4.5) | yes/yes | no/no | yes/yes | no/no |
| IRRD | RIPE NCC Whois | DT nrtm4-client | |
|---|---|---|---|
| A mirror client SHOULD be able to handle unknown object classes and objects that are invalid according to its own validation rules (8.1) | yes | yes | yes |
| RECOMMENDED for mirror clients to log these cases (8.1) | yes | yes | yes |
| RECOMMENDED for mirror clients to be flexible where possible and reasonable when applying their own validation rules to IRR objects retrieved from mirror servers (8.1) | yes | yes | yes |
| (for intermediate instances, if supported) they MUST have separate session IDs. The intermediate server MUST NOT republish the same files it retrieved from the authoritative source with the same session ID (8.2) | yes/yes | N/A | N/A |
| implementations MAY also support reading from files on the local filesystem (8.3) | yes | N/A | N/A |
| (local files) SHOULD still follow all validation rules, including the validation of the signature and hashes (8.3) | yes | N/A | N/A |
| (for key rotation) MUST include this key in the next_signing_key field in any UNF generated while the new signing key is configured (8.4) | yes | yes | N/A |
| MAY offer a method to cause the Notification Update File to be refreshed earlier (8.4) | no | no | N/A |
| When mirror clients next retrieve the UNF, they MUST detect the next_signing_key field, and store the key (8.4) | yes | no | yes |
| (after rotation) Any UNF generated after this point MUST be signed with this new key, and will not contain a next_signing_key field (8.4) | yes | yes | N/A |
| RECOMMENDED period between publication of the upcoming key in the next_signing_key field, and removal of the old key, is one week (8.4) | N/A, manual operator process | yes | N/A |
| When mirror clients retrieve an UNF and find that the signature does not match, they MUST attempt to verify against a next_signing_key encountered in a previous (valid) file. If the signature matches for this new key, the client MUST update its configuration to use the new key for validation. After this, the client MUST NOT use the old key for validation at any time: a mirror server can not switch back to an old key (8.4) | yes/yes/yes | no/no/no | yes/yes/yes |
| IRRD | RIPE NCC Whois | DT nrtm4-client | |
|---|---|---|---|
| The HTTPS endpoint used for NRTMv4 MUST be configured according to the best practices in RFC9325 (9) | N/A, HTTPS configuration by operator in separate frontend proxy | yes | N/A |
| Mirror clients MUST NOT use other protocols than HTTPS, such as HTTP or FTP (9) | yes | yes | yes |
| IRRD server | RIPE NCC whois server | |
|---|---|---|
| IRRD client | yes | yes |
| nrtm4-validator client | yes | yes |
| nrtm4tools client | yes | yes |
| DT nrtm4-client | yes | yes |