Differences

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

--- peering-toolbox:single_upstream [2022/08/26 07:58] – [Letter of Authority] philip
+++ peering-toolbox:single_upstream [2022/08/26 09:53] (current) – [Own Addressing] philip
@@ Line 47: / Line 47: @@
   - Deploy the address block across the network as appropriate (if limited IPv4, NAT may be needed)
   - Create a Route Object for the address space using the upstream provider's ASN (via the RIR member portal)
-  - Create a ROA for the address space using the upstream provider's ASN (via the RIR member portal)
+  - Create a [[peering-toolbox/route_origin_authorisation|ROA]] for the address space using the upstream provider's ASN (via the RIR member portal)
   - Provide a [[peering-toolbox/single_upstream#letter_of_authority|Letter of Authority]] to their upstream provider requesting their peers and transits accept and propagate the address space (some providers request this, so it is good to be prepared)
   - Organise with the upstream (transit provider) for the address space to be announced globally and routed to them.
@@ Line 92: / Line 92: @@
 There are many variations on this theme, of course. Quite often the upstream provider will provide a LOA in the format that they, or their upstream providers will require.
-**Note:** The LOA has been superceded by ROAs for many operators - if valid ROA exists, they will allow the prefix to propagate. LOAs are very easy to forge or falsify and are generally avoided now.
+**Note:** The LOA has been superceded by ROAs for many operators - if valid ROA exists, they will allow the prefix to propagate. LOAs are easy to [[https://sanog.org/resources/sanog29/SANOG29-Conference_BGP%20Routing%20Hijacking-Maz.pdf|forge or falsify]] and are generally recommended to be avoided now.
 [[:peering-toolbox/next-steps| Back to 'Establishing Peering' page]]