Differences

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

--- peering-toolbox:single_upstream [2022/05/16 16:31] – [Letter of Authority] philip
+++ peering-toolbox:single_upstream [2022/08/26 19:53] (current) – [Own Addressing] philip
@@ Line 14: / Line 14: @@
   - [[single_upstream#own-addressing|Using our own Address space]]
+A diagram showing the typical physical layout of this scenario is shown below:
+{{:peering-toolbox:1-upstream.png?300| }}
 ===== Upstream Addressing =====
@@ Line 29: / Line 32: @@
 And that's all that is needed.
-This major disadvantage of this is that the newcomer network operator is tied to their upstream. If they want to change upstream providers, they have to renumber their entire network, including all their customers. This can be a tiresome, frustrating, and often lengthy process (even with DHCP and IPv6's automatic address assignment capabilities).
+**Note**: the major disadvantage of this is that the newcomer network operator is tied to their upstream. If they want to change upstream providers, they have to renumber their entire network, including all their customers. This can be a tiresome, frustrating, and often lengthy process (even with DHCP and IPv6's automatic address assignment capabilities).
-General recommendation to newcomer network operators is to get their own Internet Resources directly from their Regional Internet Registry. This avoids major pain in the future if and when they need to change their upstream provider.
+The general recommendation to newcomer network operators is that they onbtain their own Internet Resources directly from their Regional Internet Registry. This avoids major painful reconfiguration (disruption) in the future if and when they need to change their upstream provider.
 ===== Own Addressing =====
@@ Line 44: / 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 59: / Line 62: @@
 <code>
+<ENTITY HEADED NOTEPAPER>
 <entity full address>
@@ Line 67: / Line 72: @@
 This letter serves as authorisation for <upstream> with AS number <ASN> to
-transit the following IP address blocks:
+announce the following IP address blocks on our behalf:
 <address-block1> (and subnets up to /<mask>)
@@ Line 80: / Line 85: @@
 <signature>
 <name>
+<position>
+<entity>
 </code>
+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 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]]