Philip Smith's Internet Development Site

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{peering-toolbox/peeringtoolbox.png?400|}}

====== Single Upstream ======

When an entity decides that it is going to set up to be a network operator (usually an Access Provider), they will purchase an Internet connection from a local network operator.

While this has nothing much to do with peering as such, it is included for completeness, to describe the sequence of events a typical newcomer network operator would navigate.

The configuration of this link is very simple and is designed by the upstream provider to get their customer up and running quickly.

There are two possible cases here:

  - [[single_upstream#upstream-addressing|Using Upstream's Address space]]
  - [[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 =====

Newcomers as network operators are unlikely to have their own address space. More likely than not they will get a small amount of address space from their upstream provider.

The configuration is straight forward:
  - The upstream provider delegates the address space to their customer
  - The customer numbers their network using this address space
  - The upstream announces the address space to the global Internet as part of their larger address block

On the routers, the upstream point a static route for the delegated address space to their customer.

And the customer points a static default route to their upstream on its router.

And that's all that is needed.

**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).

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 =====

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 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>

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]]