Differences

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

--- peering-toolbox:single_upstream [2022/05/16 16:22] – [Own Addressing] 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 Letter of Authority (LOA) 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)
+  - 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 51: / Line 54: @@
 What is meant by a Letter of Authority?
+A Letter of Authority (or LOA) is a simple document authorising a network operator to announce address space.
+It is written on the address holder's official headed notepaper, and signed by the authorised representative. The authorised representative is usually the same person who is the listed administrative or technical contact of the delegation as held at the Regional Internet Registry.
+A typical LOA might look like this:
+<code>
+<ENTITY HEADED NOTEPAPER>
+<entity full address>
+<date>
+To whom it may concern:
+This letter serves as authorisation for <upstream> with AS number <ASN> to
+announce the following IP address blocks on our behalf:
+<address-block1> (and subnets up to /<mask>)
+<address-block2> (and subnets up to /<mask>)
+As the authorised representative of <entity> I hereby declare that I'm authorised
+to sign this Letter of Authority
+Should there be any questions about the contents of this Letter of Authority
+please contact <email> or phone <phone>.
+<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]]