diff --git a/src/content/docs/byoip/concepts/irr-entries/best-practices.mdx b/src/content/docs/byoip/concepts/irr-entries/best-practices.mdx index 17958789de3adb..0dff981184ac2d 100644 --- a/src/content/docs/byoip/concepts/irr-entries/best-practices.mdx +++ b/src/content/docs/byoip/concepts/irr-entries/best-practices.mdx @@ -1,34 +1,19 @@ --- -title: Best practices +title: Manage IRR entries pcx_content_type: reference sidebar: order: 7 -head: - - tag: title - content: IRR entry updates best practices - --- -import { GlossaryTooltip } from "~/components" - -An Internet Routing Registry (IRR) record is what notifies internet service providers (ISPs) of how you are allowing your resources to be used. It is necessary to keep your IRR entries up to date so that it is public information that Cloudflare has permission to advertise your prefix or prefixes and to ensure that your traffic can be properly routed on the internet. +import { GlossaryTooltip } from "~/components"; -The American Registry for Internet Numbers (ARIN) maintains an IRR that allows registrants of AS numbers and IP addresses to publish that information so that ISPs can make appropriate routing decisions. This helps ensure ISPs will recognize your routes as legitimate and enables them to ignore unauthorized routes published by someone else. +You must keep your Internet Routing Registry (IRR) entries up to date so that it is public information that Cloudflare has permission to advertise your prefix or prefixes, and to ensure that your traffic can be properly routed on the internet. ## Configure an IRR entry -You can add or update an IRR entry by following the directions within any of the recommended internet registries listed in the [Internet Routing Registry](https://www.irr.net/index.html). - -If you own your own subnet, use the RIPE and APNIC routing registries. These registries allow you to verify subnet ownership. - -If you lease your subnet, follow these guidelines: - -* When you do not need ownership verification, use the AFRINIC or NTT routing registry. -* When you submit a route object via email, use the ARIN registry. Address blocks owned by others do not appear in the ARIN interface. +You can add or update an IRR entry by following the directions of your routing registry. Each routing registry has its own set of instructions to configure an IRR entry. -The recommended registries are AFRINIC, APNIC, ARIN, NTT, RADB, and RIPE. - -Each routing registry has its own set of instructions to configure an IRR entry. Refer to the table below for more information. +The recommended registries are AFRINIC, APNIC, ARIN, LACNIC, and RIPE. Refer to the table below for more information. @@ -50,13 +35,9 @@ Each routing registry has its own set of instructions to configure an IRR entry. - - - - - - - + + + @@ -72,8 +53,8 @@ Verify your Internet Routing Registry (IRR) entries to ensure that the IP prefix Each IRR entry record must include the following information: * **Route**: Each IP prefix Cloudflare advertises for you. -* **Origin ASN**: Your ASN, or if you do not have your own ASN, the Cloudflare ASN (AS13335). -* **Source**: The name of the routing registry, for example, AFRINIC, APNIC, ARIN, RADB, RIPE, or NTT. +* **Origin ASN**: The Cloudflare ASN (AS13335) or your own ASN. +* **Source**: The name of the routing registry (for example, ARIN). Add or update IRR entries when they meet any of these criteria: diff --git a/src/content/docs/byoip/concepts/irr-entries/index.mdx b/src/content/docs/byoip/concepts/irr-entries/index.mdx index 609d7e796b5deb..8faa7fb1dfc6bf 100644 --- a/src/content/docs/byoip/concepts/irr-entries/index.mdx +++ b/src/content/docs/byoip/concepts/irr-entries/index.mdx @@ -1,17 +1,22 @@ --- -title: Internet Routing Registry +title: Internet Routing Registry (IRR) pcx_content_type: concept sidebar: order: 2 - + label: Overview + group: + label: Internet Routing Registry +head: + - tag: title + content: IRR Overview --- -The [Internet Routing Registry (IRR)](http://www.irr.net/index.html) is a globally distributed database of routing information. The IRR contains announced routes and routing policies in a common format, and network operators use this information to configure their backbone routers. +import { GlossaryDefinition } from "~/components"; -The IRR consists of many individual [routing registries](http://www.irr.net/docs/list.html), and some are managed by regional entities, such as APNIC, ARIN, and RIPE. Each routing registry contains IRR entries that provide information about IP prefixes and the [autonomous systems](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/) authorized to announce them. + -To announce your subnet prefixes, Cloudflare requires accurate IRR entries for your prefixes and autonomous system numbers (ASNs). +The IRR consists of many individual [routing registries](http://www.irr.net/docs/list.html), and some are managed by regional entities - such as the American Registry for Internet Numbers (ARIN), the Regional Internet Registry for Europe, Middle East and Central Asia (RIPE), and so on. Each routing registry contains IRR entries that provide information about IP prefixes and the [autonomous systems](https://www.cloudflare.com/learning/network-layer/what-is-an-autonomous-system/) authorized to announce them. -When you configure network infrastructure for services such as [Magic Transit](/magic-transit/about/), [verify your IRR entries](/byoip/concepts/irr-entries/best-practices/#verify-an-irr-entry). +To announce your subnet prefixes, Cloudflare requires accurate IRR entries for your prefixes and autonomous system numbers (ASNs). -For help with adding missing IRR entries or updating inaccurate entries, refer to the [best practices for IRR entries](/byoip/concepts/irr-entries/best-practices/). +When you configure network infrastructure for services such as [Magic Transit](/magic-transit/about/), or before onboarding your IP to Cloudflare, [verify your IRR entries](/byoip/concepts/irr-entries/best-practices/#verify-an-irr-entry). diff --git a/src/content/docs/byoip/concepts/loa.mdx b/src/content/docs/byoip/concepts/loa.mdx index cc5a2ae574ff5d..75cb7cf5e549e0 100644 --- a/src/content/docs/byoip/concepts/loa.mdx +++ b/src/content/docs/byoip/concepts/loa.mdx @@ -10,20 +10,26 @@ head: import { Render } from "~/components"; -A Letter of Agency (LOA) - sometimes referred to as a Letter of Authorization - is a document that authorizes Cloudflare to announce a prefix(es) on behalf of another entity. The LOA is required by Cloudflare's transit providers so they can accept the routes Cloudflare advertises on behalf of another entity. +A Letter of Agency (LOA) - sometimes referred to as a Letter of Authorization - is a document that authorizes Cloudflare to announce prefixes on behalf of another entity. The LOA is required by Cloudflare's transit providers so they can accept the routes Cloudflare advertises on behalf of another entity. The letter must contain both the prefixes you are authorizing Cloudflare to announce and which ASN they will be announced under. Cloudflare can announce a prefix under your ASN or you can use Cloudflare's ASN, which is AS13335. -:::note -For all future onboardings, you must use AS13335. Current customers who are already using Cloudflare's AS209242 do not need to make any changes and can continue using that ASN. -::: +## Requirements -Cloudflare accepts digital signatures on an LOA, as long as it is clear who is signing the LOA. +- For all future onboardings, if using the Cloudflare ASN, you must use AS13335. Current customers who are already using Cloudflare's AS209242 do not need to make any changes and can continue using that ASN. -:::note[Note] -An LOA is a formal document which should be on company letterhead and contain a wet signature. The Letter of Agency must be a PDF. Transit providers may reject the LOA if it is in a JPG or PNG format. -::: +- Cloudflare accepts digital signatures on an LOA, as long as it is clear who is signing the LOA. -You can use the below template when creating an LOA document. +- An LOA is a formal document which should be on company letterhead and contain a wet signature. The Letter of Agency must be a PDF. Transit providers may reject the LOA if it is in a JPG or PNG format. + +## Auto-generated LOA + +If you are onboarding your own IPs via the [self-serve flow](/byoip/get-started/), you can set `delegate_loa_creation` (in the [Add Prefix API call](/api/resources/addressing/subresources/prefixes/methods/create/)) to `true` . This will allow Cloudflare to automatically generate the LOA, speeding up the process. + +Auto-generated LOAs rely on [RPKI-signed ROAs](/byoip/concepts/route-filtering-rpki/) and [ownership validation](/byoip/get-started/#validate-prefix-ownership) checks. + +## Template + +If you need to create an LOA document, you can use the template below. diff --git a/src/content/docs/byoip/concepts/route-filtering-rpki.mdx b/src/content/docs/byoip/concepts/route-filtering-rpki.mdx new file mode 100644 index 00000000000000..beccf3a469aa49 --- /dev/null +++ b/src/content/docs/byoip/concepts/route-filtering-rpki.mdx @@ -0,0 +1,16 @@ +--- +title: Route filtering and RPKI +pcx_content_type: concept +sidebar: + order: 2 +--- + +import { GlossaryTooltip } from "~/components"; + +As referred in the [IRR concept page](/byoip/concepts/irr-entries/), network operators use IRR records to configure backbone routers. In summary, it is the IRR records that provide information about IP prefixes and the autonomous systems (ASN) authorized to announce them. Then, network operators will apply filtering policies to avoid invalid announcements. + +Considering this important role of IRR records, validation via Resource Public Key Infrastructure (RPKI) was introduced. With RPKI, the IP/ASN association is cryptographically validated before being passed on to the routers. + +When registering your prefix under one of the five Regional Internet Registries (RIRs)[^1], you can generate a cryptographically-signed object called Route Origin Authorization (ROA). ROAs are public and you can use [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator) or other sources, such as [Routinator](https://rpki-validator.ripe.net/ui/), to check your prefixes. + +[^1]: AFRINIC, APNIC, ARIN, LACNIC, and RIPE. \ No newline at end of file diff --git a/src/content/docs/byoip/get-started.mdx b/src/content/docs/byoip/get-started.mdx index 6a62fc6e4d6ad9..f3f2d2f10301eb 100644 --- a/src/content/docs/byoip/get-started.mdx +++ b/src/content/docs/byoip/get-started.mdx @@ -5,36 +5,267 @@ sidebar: order: 2 --- -import { GlossaryTooltip } from "~/components"; +import { APIRequest, Tabs, TabItem, GlossaryDefinition, GlossaryTooltip, Details } from "~/components"; -Work with your account team to understand everything you need to ensure a smooth transition during the onboarding process. +To use your own IP addresses with Cloudflare, please check with your account team to confirm your contract covers this functionality. You will need to configure settings specific to the services you want to use, as well as meet some standard requirements for all BYOIP customers. -Cloudflare requires a service-specific configuration for your prefixes, as well as some requirements common to all BYOIP customers regardless of service type. +Once your account configurations are in place, consider the sections below to learn how to set up your BYOIP prefixes. Also make sure to review the [BYOIP Service-Specific Terms](https://www.cloudflare.com/service-specific-terms-network-services/#bring-your-own-ip-terms). -## Requirements +:::note[Magic Transit] +The process described on this page does not support onboarding IP prefixes for use with [Cloudflare Magic Transit](/magic-transit/). For further guidance, refer to the [Magic Transit get started](/magic-transit/get-started/). +::: + +## Before you begin + +- Your prefix must be registered under one of the Regional Internet Registries (RIRs): -The following requirements are common to all products compatible with BYOIP. + - [AFRINIC](https://afrinic.net/) + - [APNIC](https://www.apnic.net/) + - [ARIN](https://www.arin.net/) + - [LACNIC](https://lacnic.net/) + - [RIPE](https://www.ripe.net/) -You must verify that your [Internet Routing Registry (IRR)](/byoip/concepts/irr-entries/) records are up to date and contain: +- Also verify that your [Internet Routing Registry (IRR)](/byoip/concepts/irr-entries/) records are are up to date and contain: - `route` or `route6` objects matching the exact prefixes you want to onboard - `origin` matching the correct ASN you want to onboard -:::caution[RPKI validation] -You are not required to use Resource Public Key Infrastructure (RPKI). However, if you do, make sure your ROAs are accurate. You can use [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator) and a second source such as [Routinator](https://rpki-validator.ripe.net/ui/) to double-check your prefixes. + :::note + The process described on this page only supports using Cloudflare's ASN (AS13335). If you must announce the prefixes under your own ASN, contact your account team. + ::: + +- You must use [Resource Public Key Infrastructure (RPKI) validation](/byoip/concepts/route-filtering-rpki/) and make sure your ROAs are accurate. You can use [Cloudflare's RPKI Portal](https://rpki.cloudflare.com/?view=validator) and a second source such as [Routinator](https://rpki-validator.ripe.net/ui/) to double-check your prefixes. + +- If you are not familiar with how Cloudflare API works, refer to [Fundamentals](/fundamentals/api/). Make sure you have the necessary permissions and that you have your account ID. + +--- + +## 1. Set up your prefixes + +### Add your prefix + +Use the [Add Prefix endpoint](/api/resources/addressing/subresources/prefixes/methods/create/) to create a prefix in the Cloudflare account that should own the BYOIP prefix. + + + +```json title="Response" {15-19} ""id": "72823e95d6c64d48a8111fec81179816"" + + "result": { + "id": "72823e95d6c64d48a8111fec81179816", + "created_at": "2025-02-25T00:34:11.423722Z", + "modified_at": "2025-02-25T00:34:11.423722Z", + "cidr": "203.0.113.0/24", + "account_id": "654c5f71c324478cc9f68d60065d4620", + "description": "", + "approved": "P", + "on_demand_enabled": false, + "on_demand_locked": false, + "advertised": null, + "advertised_modified_at": null, + "loa_document_id": "b9ff4afe312246a8b2e7324d98f40b23", + "asn": 13335, + "ownership_validation_token": "", + "delegate_loa_creation" : true, + "irr_validation_state": "pending", + "rpki_validation_state": "pending", + "ownership_validation_state": "pending", + } + +``` + +2. Take note of the `id` assigned to the prefix you added. It will be used in future steps. + +:::note[Letter of Agency (LOA)] +The process described on this page leverages automated LOA generation. If you set `delegate_loa_creation` to `false`, you have to manually upload your LOA, make a [PATCH request](/api/resources/addressing/subresources/prefixes/methods/edit/) once the prefix is approved, and contact your account team - which is more prone to error and increases the onboarding time. ::: -## Process overview +### Validate prefix ownership + +Validate prefix ownership using one of the following methods: + + + +1. Copy the `ownership_validation_token` returned by the API call. +2. On the IRR record of the prefix you are onboarding, add the following string in either a `description` or `remarks` field. Replace `` by the actual token you copied in the previous step. + +``` +cf-validation: +``` + +:::note + +The exact steps to update your IRR record will depend on the registry you are using. Refer to [Internet Routing Registry (IRR)](/byoip/concepts/irr-entries/best-practices/) for details. + +::: + + + + +1. Consider the size of the prefix you are bringing to Cloudflare. Since the standard `in-addr.arpa` tree assumes delegations on octet or nibble boundaries, if you onboard prefixes that are not aligned with those, you will have to split up the prefix into subnets and create the corresponding reverse DNS zones for each. + +
+ +To calculate how many smaller subnets you need, use the following formula: + +``` +2^(next boundary - current netmask) +``` + +For `1.1.0.0/23`, you would setup two (`2^(24-23)`) reverse DNS zones, one for `1.1.0.0/24` and another for `1.1.1.0/24`. + +For `2001:0db8::/34`, you would setup four (`2^(36-34)`) reverse DNS zones, for `2001:0db8::/36`, `2001:0db8:1:/36`, `2001:0db8:2::/36`, and `2001:0db8:3::/36`. + +
+ +2. Set up a reverse DNS zone. If you use Cloudflare for DNS, refer to [Reverse DNS zones](/dns/additional-options/reverse-zones/#set-up-a-reverse-zone). If you use a different DNS provider, follow their instructions. +3. Create TXT records using `cf-validation` as their `name`. They should look like the following example: + + +``` +cf-validation. IN TXT +``` + +4. Update nameservers at your Regional Internet Registry (RIR). The exact steps to update your nameservers will depend on the registry you are using. + + + +Once the ownership validation is successful, you can remove the token. + +When all validations pass - RPKI, IRR, and ownership - the `approved` field in your prefix will return `"V"`. This means you can proceed to create IP address service bindings[^1]. + +If needed, you can use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) to check if any issues were found during validation. If so, proceed with the necessary changes and make a request to restart validation. Refer to [Prefix validation checks](/byoip/troubleshooting/prefix-validation/) for details. + +### (Optional) Delegate your BYOIP prefixes + +You can allow other accounts to use part or all of your BYOIP prefix. Refer to [Prefix delegations](/byoip/concepts/prefix-delegations/) for details. + +", + "delegated_account_id": "" + }} +/> + +:::note +Although you can delegate IPs to other accounts, the IP address service bindings are still created and managed on the parent account - meaning the Cloudflare account where you added the prefix in step 1. +::: + +--- + +## 2. Create service bindings + +In IP address management, service bindings map the traffic destined for a given IP address to the Cloudflare service that it should be routed through. + +### Default service binding + +When you onboard your IP prefixes to Cloudflare, there must be one service binding that spans across your entire prefix. Traffic destined for a given IP address will be routed to this service by default. You can also configure [additional service bindings](#optional-additional-bindings) as described in the next step. + +1. Make a `GET` request to the [List Services](/api/resources/addressing/subresources/services/methods/list/) endpoint and take note of the `id` associated with the service you want to use. +2. (Optional) If needed, use the [List Prefixes](/api/resources/addressing/subresources/prefixes/methods/list/) endpoint to get or confirm the `id` associated with your prefix. +3. Make a `POST` request to the [Create service binding](/api/resources/addressing/subresources/prefixes/subresources/service_bindings/methods/create/) endpoint, indicating the entire BYOIP prefix that you are onboarding and the service that should be used for your default binding. + +" +}} +/> + +A corresponding BGP prefix will be created automatically. Allow five hours before you advertise the prefix. + +### (Optional) Additional bindings + +If you want to selectively route traffic on a per-IP address basis to CDN or Spectrum, you can create additional service bindings. + +:::note +The steps below only cover assigning specific IPs to additional services. For guidance that includes CDN or Spectrum setup steps, refer to [Service bindings](/byoip/service-bindings/). +::: + +1. Plan for what IP(s) will get the additional binding. Cloudflare **strongly** recommends implementing service bindings through an **aggregated** CIDR block, as it is more efficient than adding discrete bindings for non-contiguous CIDR blocks. + +
+ +**Spectrum protected prefix:** `203.0.113.0/24` + +**IPs to upgrade to CDN:** + +`203.0.113.16`
+`203.0.113.17`
+`203.0.113.18`
+`203.0.113.19`
+`203.0.113.20`
+`203.0.113.21`
+`203.0.113.22`
+`203.0.113.23` + +Add one discrete CDN service binding for `203.0.113.16` with a `/29` netmask. + +
+ +2. Make a `POST` request to the [Create service binding](/api/resources/addressing/subresources/prefixes/subresources/service_bindings/methods/create/) endpoint, indicating the IP address you want to bind to the CDN or Spectrum. Specify the **corresponding network mask** as needed. + +" + }} + code={{ + mark: [6, 7] + }} +/> + +In the response body, the initial provisioning state should be `provisioning`. + + +```json output {9} + + { + "errors": [], + "messages": [], + "success": true, + "result": { + "cidr": "203.0.113.16/29", + "id": "", + "provisioning": { + "state": "provisioning" + }, + "service_id": "", + "service_name": "" + } + } +``` + +Once a service binding is created (or deleted), it will take **four to six hours** to propagate across Cloudflare's global network. + +--- + +## 3. Advertise the BGP prefix + +Once automatically created (following [step 2](#2-create-service-bindings)), BGP prefixes are initially withdrawn. After all your configurations are in place - including [address maps](/byoip/address-maps/)[^2] if you will use CDN service -, proceed to advertise the BGP route for your prefix. -Overall, the steps can be summarized as follows: +1. Use the [Update BGP prefix](/api/resources/addressing/subresources/prefixes/subresources/bgp_prefixes/methods/edit/) endpoint to start the advertisement. -1. You revise your [IRRs and ROAs](#requirements) (if applicable) to make sure they are correct. -2. You prepare a [Letter of Agency (LOA)](/byoip/concepts/loa/) containing both the prefix you are authorizing Cloudflare to announce and which ASN they will be announced under. Cloudflare will present this to our transit partners as evidence that we are allowed to announce the route. -3. You use the [Upload LOA Document](/api/resources/addressing/subresources/loa_documents/methods/create/) API endpoint to submit the letter under your account and the [Add Prefix](/api/resources/addressing/subresources/prefixes/methods/create/) endpoint to create the prefix in your account with the associated `loa_document_id`. -4. After receiving the LOA, Cloudflare validates the [requirements](#requirements) and provisions the IPs. -5. (Optional) You can use [prefix delegations](/byoip/concepts/prefix-delegations/) to share all or part of your prefix with another Cloudflare account. -6. You use [service bindings](/byoip/service-bindings/)[^1] and [address maps](/byoip/address-maps/)[^2] to control how your IPs are used. -7. You advertise or withdraw the BGP route for a prefix via the [BGP Prefixes API](/api/resources/addressing/subresources/prefixes/subresources/bgp_prefixes/). + [^1]: Mappings that control through which pipeline traffic destined for a given IP address will be routed. [^2]: Mappings that specify which IP addresses should be used when Cloudflare responds to DNS queries for proxied hostnames. \ No newline at end of file diff --git a/src/content/docs/byoip/troubleshooting.mdx b/src/content/docs/byoip/troubleshooting/index.mdx similarity index 94% rename from src/content/docs/byoip/troubleshooting.mdx rename to src/content/docs/byoip/troubleshooting/index.mdx index f5029fe2e94dd7..a031a0240f5c67 100644 --- a/src/content/docs/byoip/troubleshooting.mdx +++ b/src/content/docs/byoip/troubleshooting/index.mdx @@ -1,9 +1,11 @@ --- -pcx_content_type: troubleshooting title: Troubleshooting +pcx_content_type: troubleshooting sidebar: order: 10 - + label: General +head: [] +description: Review common troubleshooting scenarios for BYOIP. --- import { GlossaryTooltip } from "~/components"; diff --git a/src/content/docs/byoip/troubleshooting/prefix-validation.mdx b/src/content/docs/byoip/troubleshooting/prefix-validation.mdx new file mode 100644 index 00000000000000..4e993fad53ef45 --- /dev/null +++ b/src/content/docs/byoip/troubleshooting/prefix-validation.mdx @@ -0,0 +1,51 @@ +--- +pcx_content_type: troubleshooting +title: Troubleshoot prefix validation +sidebar: + order: 4 + label: Prefix validation checks +--- + +import { APIRequest, GlossaryTooltip } from "~/components"; + +1. Use the [Prefix Details endpoint](/api/resources/addressing/subresources/prefixes/methods/get/) to check if any issues were found during validation. + + + +```json title="Response" {17-19} + + "result": { + "id": "72823e95d6c64d48a8111fec81179816", + "created_at": "2025-02-25T00:34:11.423722Z", + "modified_at": "2025-02-25T00:34:11.423722Z", + "cidr": "203.0.113.0/24", + "account_id": "654c5f71c324478cc9f68d60065d4620", + "description": "", + "approved": "P", + "on_demand_enabled": false, + "on_demand_locked": false, + "advertised": null, + "advertised_modified_at": null, + "loa_document_id": "b9ff4afe312246a8b2e7324d98f40b23", + "asn": 13335, + "ownership_validation_token": "", + "delegate_loa_creation" : true, + "irr_validation_state": "valid", + "rpki_validation_state": "valid", + "ownership_validation_state": "missing", + } + +``` + +2. Consider the states returned in the API response (for example, `missing`, `invalid`, `mismatch_asn`) and review your IRR record, ROA, and ownership validation method accordingly. + + - Information in the IRR and ROA records should meet the [onboarding prerequisites](/byoip/get-started/#before-you-begin). + + - [Ownership validation](/byoip/get-started/#validate-prefix-ownership) requires a matching ROA and the correct validation token found in all DNS TXT records or in the IRR record. + +3. After applying the necessary changes, use the Validate Prefix endpoint to re-trigger the validation checks. + + \ No newline at end of file diff --git a/src/content/glossary/byoip.yaml b/src/content/glossary/byoip.yaml index ce2e3c4cb280d7..3006f107601e54 100644 --- a/src/content/glossary/byoip.yaml +++ b/src/content/glossary/byoip.yaml @@ -17,7 +17,7 @@ entries: - term: Internet Routing Registry (IRR) general_definition: |- - a globally distributed database of routing information which contains announced routes and routing policies in a common format. Network operators use this information to configure backbone routers. + a globally distributed database of routing information which contains announced routes and routing policies in a common format. Network operators use this information, as well as [RPKI](/byoip/concepts/route-filtering-rpki/), to configure backbone routers. - term: Resource Public Key Infrastructure (RPKI) general_definition: |-
ARIN https://www.arin.net/resources/manage/irr/quickstart/
NTThttps://www.gin.ntt.net/support-center/policies-procedures/routing-registry/
RADBhttps://www.radb.net/support/
LACNIChttps://lacnic.zendesk.com/hc/articles/360038667154-What-are-a-route-and-a-route-6-objects
RIPE