Differences

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

--- peering-toolbox:single_upstream [2022/05/16 16:19] – [Upstream 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 37: / Line 40: @@
 If the newcomer network operator has already obtained its own address space and ASN for the network (usually from the Regional Internet Registry) they can deploy that, rather than using address space from their upstream provider.
-The advantage of doing this is that we are independent of our upstream. We can change transit providers very easily, simply by getting our new transit provider to announce our address space to the world.
+The major advantage of doing this is that they are independent of their upstream - no lock in at all. The newcomer can change transit providers very easily, simply by getting asking their new transit provider to announce their address space to the world.
+(Technically this is a bit more challenging than it may at first seem. Which is why we introduce BGP into the picture later in the Toolbox.)
+For a newcomer to use their own address space, the steps are:
+  - 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 [[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.
+==== Letter of Authority ====
+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>
-(Technically this is a bit more challenging than it may seem!)
+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.
-To use your own address space, the steps are:
+**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.
-  - Deploy your address block across your network as appropriate
-  - Create a Route Object for your address space using your upstream provider's ASN
-  - Create a ROA for your address space using your upstream provider's ASN
-  - Provide a Letter of Authority (LOA) to your upstream provider requesting their peers and transits accept and propagate your 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 you
 [[:peering-toolbox/next-steps| Back to 'Establishing Peering' page]]