Differences

This shows you the differences between two versions of the page.

--- peering-toolbox:route_origin_authorisation [2022/05/06 14:24] – [What about legacy address space?] philip
+++ peering-toolbox:route_origin_authorisation [2022/08/26 17:15] (current) – [Legacy address space] philip
@@ Line 1: / Line 1: @@
-===== Route Origin Authorisation =====
+====== Route Origin Authorisation ======
 One of the major problems with the Internet Routing Registry is that the information contained therein is historically placed there on trust. While the five RIRs have made big strides to tidy up their instances of the IRR (allowing object creation only by members), the remainder of the IRR still contains a lot of inaccurate, incorrect, and out dated information. And there is no validation or verification of any of the information provided either - any entity can place anything in the RADB, for example, simply by paying the subscription fee.
-==== Background ====
+Route Origin Authorisation is one of the four recommendations of the global programme known as the Mutually Agreed Norms for Routing Security ([[https://www.manrs.org/|MANRS]]), supported by the Internet Society.
+The following sections discuss the key components for Route Origin Authorisation.
+  * [[route_origin_authorisation#background|Background]]
+  * [[route_origin_authorisation#roa_creation|Creating ROAs]]
+  * [[route_origin_authorisation#legacy_address_space|Legacy IPv4 Address space]]
+===== Background =====
 In the early 2010s a new effort to validate routing information finally started early deployment, and is now seeing widespread deployment, plus full support in the routing operating systems of the major/serious equipment vendors. The goal is to reduce the instances of malicious announcements of address space (aka //route hijacks//) and genuine configuration errors (aka //fat fingers//) which knock out significant parts of the global Internet infrastructure.
@@ Line 15: / Line 22: @@
 More and more network operators around the globe are checking BGP announcements against the published ROAs - if a BGP announcement does not match the ROA, the BGP announcement is dropped. This is know as Route Origin Validation (ROV).
-==== ROA Creation ====
+===== ROA Creation =====
 Creation of a ROA is done via the respective RIR's member portal - the Network Operator should contact their RIR for more information on how to do this.
@@ Line 23: / Line 30: @@
 **Note very well**: only create a ROA for the exact route that is being announced - never create a ROA for an unannounced route or subnet, as that could result in that route or subnet being hijacked.
-==== What about legacy address space? ====
+===== Legacy address space =====
 Holders of legacy (InterNIC assigned) address space are encouraged to create ROAs to assist with ensuring greater integrity of the global routing system.
-Some (but not all) RIRs have a mechanism allowing legacy address holders whose IP address space is now managed by the RIR under the ERX project to create and maintain a ROA for a small annual fee.
+Some (but not all) RIRs have a mechanism allowing legacy address holders whose IP address space is now managed by the RIR under the ERX project to create and maintain a ROA for a small annual fee. These operators are encouraged to contact the RIR holding these legacy addresses to find out how to create ROAs.
-[[:peering-toolbox/how-to-peer| Back to "What I need to Peer" page]]
+[[:peering-toolbox/how-to-peer| Back to "What is required for Peering" page]]