In the first part of this series, we had a brief overview of what BGP is. Then last time, we dived into what autonomous systems (ASes) are and the relationships that can exist between them, as well as the existence of Tier 1 networks and Internet Exchange Points (IXPs). That provided a broad overview of the Internet’s structure.

However, so far in this series, we’ve talked about IP addresses—or really, IP prefixes and CIDRs—as if they are something that just exists. This mental model is no longer sufficient. Before we can truly understand routing, we must first understand how IP addresses really work—how they are assigned and who is authorized to announce them.

Address assignment

As alluded to before, IP addresses are Internet numbers like ASNs, and as such are assigned in a similar manner. IANA controls the global assignment of addresses but delegates the day-to-day assignment to RIRs. For more details on how things are structured here, see the previous part of this series.

In theory, IP addresses are given to anyone who can justify a need for them. Usually, that means you wish to establish independence from your ISP by having your own IPs that you can announce yourself under your own ASN, or let any capable ISP announce them on your behalf from their ASN, enabling you to switch ISPs at any time without changing your IP address. Once you demonstrated this need, you will be given an IP prefix whose length is based on the intended size of your network, with shorter prefixes (containing more IPs) for larger networks.

However, to prevent the Internet routing table from growing out of control completely, a convention is established to prevent small (i.e. longer) IP prefixes from being announced on the Internet. The current longest acceptable prefix globally is /24 for IPv4 and /48 for IPv6, and this is unlikely to change any time soon. As a result, you will never be assigned a prefix longer than the longest routable prefix, since then you won’t be able to announce it and the prefix is wasted.

In practice, things are not so simple. For IPv6, the theory meshes pretty well with reality, but with IPv4 exhaustion, things are a lot more complicated there. In short, all RIRs have exhausted their address space, though some, such as APNIC and ARIN, have reserved pools remaining that require special justification. Requests for IPv4 addresses that can’t be met from reserved pools will end up on a waitlist and be eventually fulfilled when addresses are returned to the RIRs. As an alternative to RIRs, IPv4 addresses can be rented or bought on the market. The exact details here can justify a whole blog post on its own, so I’ll leave it at that1. The long-term solution, of course, is to migrate everything to IPv6.

There’s also the concept of legacy IPv4 allocations that predate the creation of RIRs, which opens a whole new can of worms that we’ll not dive into here. That part of history and its repercussions in the present can also justify an entire post2.

Authorization to announce addresses

Once you have obtained your IP addresses, you will now need to allow your ISP to announce it on your behalf. This ISP may also be yourself if you have an ASN. There are three ways in which this could be done:

  1. Write a letter of authorization (LoA);
  2. Create a route or route6 object in an Internet Routing Registry (IRR); or
  3. Create a route origin authorization (ROA) with Resource Public Key Infrastructure (RPKI).

Sometimes, you may need to do more than one of these. Let’s look at each option.

Letter of authorization (LoA)

A letter of authorization is exactly what it sounds like—a letter that says your ISP is allowed to announce the IP range on your behalf. Some ISPs require these before they will announce IPs on your behalf, and they may also be given to their upstream ISPs. It looks something like this:

To whom it may concern,

This letter serves as authorization for Example ISP (AS64500) to announce the following IP ranges:

  • 192.0.2.0/24
  • 2001:db8::/32

As a representative of Example LIR, the owner of the aforementioned IP ranges, I hereby declare that I am authorized to represent and sign this letter of authorization. This authorization shall remain in effect until revoked or modified in writing.

Should you have any questions about this request, please email me at [email protected] or call me at (555) 555-5555.

Sincerely,

Signature for John Smith

John Smith
CEO of Example LIR

“Example LIR” here can be the LIR from whom you received your IP addresses, or your own legal entity3 if you received the resource directly from an RIR.

Some ISPs may accept the above in a plaintext .txt file, whereas others may require a PDF file with a very official-looking company letterhead. Regardless of the format, you may see a problem here—no matter how official these letters look, they are easily forgeable. Despite this, some ISPs require an LoA for reasons unknown to me.

Internet Routing Registry (IRR)

We’ve touched upon this last time when talking about the as-set object type, but IRRs are databases in which objects concerning the routing on the Internet are stored. There are several, such as:

  • AfriNIC, APNIC, ARIN, LACNIC, RIPE: each RIR operates their own IRR for their own users for no additional cost;
  • RADb: the Routing Assets Database, a public IRR that’s independent of any RIR, which costs $595/year at the time of writing to use; and
  • AltDB: a free-to-use IRR that’s neither very trustworthy nor reliable.

To authorize AS64500 to announce 192.0.2.0/24, a route object must be created for 192.0.2.0/24 with AS64500 as the origin. Similarly, to authorize AS64500 to announce 2001:db8::/32, a route6 object must be created for 2001:db8::/32 with AS64500 as the origin.

In the RIR-operated IRRs, only the holder of the IP prefix can create route and route6 objects. However, this restriction does not apply to other IRRs. While some of them may attempt to verify ownership, things can get messy very quickly, and many IRRs don’t verify anything at all. For this reason, you are recommended to simply use the RIR-operated IRRs if you can, which you should be able to do in most cases except for certain legacy IPv4 spaces.

Despite all its defects, using IRR is better than nothing, and many networks will only accept prefixes from downstreams and peers that are valid in IRR.

Resource Public Key Infrastructure (RPKI)

This is probably the most secure method to authorize an ASN to announce an IP range. As the name implies, RPKI is based on public key cryptographic signatures. It works in a hierarchical way similar to how IP addresses are assigned, starting from the RIR’s trust anchor. When IP addresses are allocated to an entity (such as an LIR or end-user), the allocator (such as RIR or LIR) will delegate the range in RPKI to the same entity by authorizing the entity’s public key to sign further delegations or Route Origin Authorizations (ROAs).

At the lowest level, ROAs state which ASNs are allowed to announce which IP ranges. By default, the ASN is only allowed to announce the exact prefix authorized. There is also an optional “maximum prefix length” field, allowing the ASN to announce smaller prefixes, but no longer than the maximum length. Through public key cryptography, every valid ROA can be chained back to an RIR.

Then, routers can check each prefix and the ASN announcing it against RPKI to obtain three outcomes:

  • RPKI valid: there exists an ROA for the prefix that allows said ASN;
  • RPKI invalid: there exists an ROA for the prefix, but no ROA that allows said ASN;
  • RPKI unknown: there is no ROA for the prefix.

Networks implementing RPKI are expected to reject all RPKI invalid announcements. However, RPKI unknown announcements should be allowed since they come from networks that have not implemented RPKI.

With a cryptographic signature, RPKI is inherently more secure than LoAs and IRRs. However, despite various initiatives, many ISPs still don’t check for RPKI, instead relying on legacy methods like IRR and LoAs. This means that they may be tricked into accepting IP prefix announcements from ASes that are not authorized to do so. You can see the current state and check your own ISP’s RPKI implementation on this helpful site made by Cloudflare.

Furthermore, at the time of writing, around half of the prefixes announced on the Internet are not protected by RPKI, according to NIST’s RPKI monitor. Any prefix that’s not signed by RPKI is vulnerable to hijacking by an unauthorized AS.

On a side note, while RPKI securely proves which ASN is allowed to announce an IP prefix, it doesn’t protect the IP prefix from all hijacking. For example, an ISP may pretend to be an upstream of an AS authorized to announce the IP prefix. This is the problem that Autonomous System Provider Authorization (ASPA) is meant to solve, but this is still currently a draft standard.

Conclusion

I hope this gives you some useful insight into how IP addresses function on the Internet. I hope you are not too horrified by how LoAs continue to be used despite their sketchiness. Next time, I will talk a bit more about BGP route selection, traffic engineering, and anycasting.

Notes

  1. I feel like this would turn into a tutorial on obtaining IPv4 addresses in $CURRENT_YEAR, and I am not sure I want to do that. ↩

  2. I am more likely to write about this, if only as an example of what not to do for resource management. At the same time, things are also somewhat complicated, with ARIN doing everything they can to get legacy IPv4 holders to sign a resource agreement, which is full of politics. ↩

  3. By legal entity, I mean your company if the resources were given to a corporation that you control, or yourself, potentially under a trade name, if you operate something like a sole proprietorship. ↩