WHY IS 65535 NOT PART OF THE PRIVATE AUTONOMOUS SYSTEM RANGE?

This post involves me telling you a question that appeared in a vendor certification exam six years ago. Technically this is breaking NDA, but all my certs have expired with this particular vendor, and also I’m not telling you which vendor it is, and also it was six years ago, and also it was six years ago. Also, it’s worth mentioning that this was six years ago. Did I mention that it was six years ago?

The question was something along the lines of “What range of autonomous system numbers are reserved for private use”. All four possible answers were in the 16-bit AS range, which is odd considering that 32-bit AS numbers had been around since 2007. Poor 32-bit AS numbers. So misunderstood, so forgotten. I love you, 32-bit AS numbers. I will never forget u.

In any case, the actual answer is 64512 to 65534, as defined by the IANA here.

STUDYING PROTIP: If you’re having trouble memorising the quite arbitrary number of 64512, I recommend always using it in your BGP labs. It will soon drill its way into your brain if you keep typing it!

This particular exam question gave four choices. One of the options was “64512 to 65534”, and one was “64512 to 65535”. Hmm. Hmm!

The problem with this question is that there’s a lot of documentation by many different vendors that will tell you that 65535 is indeed part of the private range. For that reason, I wasn’t entirely confident that choosing the actual correct answer would get me the points I needed!

For example, the clip below is from a very old Cisco BGP book (published 2004) which I was flicking through today, and which inspired me to make this post:

Even today in the year 2021, vendors frequently list 65535 as being part of the private block, such as this Juniper KB article and this Cisco KB article.

Here’s where things get interesting though. See that BGP book I screenshat? (That is the correct past-tense of screenshot, by the way, and I’ll fight anyone who disagrees.) Well, it turns out that at the time it was written, the book may have been correct. And there’s every chance that those Juniper/Cisco docs were also correct at the time they were written, too.

See, it turns out that back in March 1996, AS 65535 WAS part of the private range! What’s going on? Let’s dig into some RFCs to find out.

 

HISTORY LESSON TIME!

The reserved range of autonomous system numbers was originally defined in RFC 1930, which has the very sexy and exciting name of “Guidelines for creation, selection, and registration of an Autonomous System (AS)”.

Check this out:

But at some point between 1996 and 2013, this changed.

RFC 6996, which I’m sure you already know is called “Autonomous System (AS) Reservation for Private Use”, is dated July 2013. It states that the private range now ends at 65534. It doesn’t say why this has changed, or even acknowledge the change, although the RFC is explicitly listed as updating RFC 1930:

Later on in July 2014, RFC 7300 brings much more clarity.

This RFC is called “Reservation of Last Autonomous System (AS) Numbers”, and it reserves the numbers at the end of the 16-bit and 32-bit AS blocks – 65535 and 4294967295 respectively – as being “Last Autonomous System Numbers”. Crucially, this RFC actually tells us the reasoning for the change – and to understand it, you need to know a little bit about BGP communities.

 

WHY DID THEY CHANGE IT?

The reason that 65535 is reserved is because of a bunch of reserved BGP communities, some of which are defined in RFC 1997.

You know what a BGP community is, right? It’s like a tag you can put onto a BGP advertisement, so that you can tell other routers to take a certain action if that community exists.

There’s two kinds of communities: “regular” communities, and extended communities. Focusing just on the regular ones for now, communities are made up of two 16-bit numbers, with a colon between them, for example 123:456, or 59876:33333.

The first number is pretty much always your autonomous system number. The second number can be anything of your choosing.

For example, if your AS was 64512 then you might use 64512:100 to set the local preference to 500, while 64512:666 might mean “set the next-hop to discard the traffic”. Communities can be used to change pretty much anything you like, and they’re used extensively in the service provider world to make sure that the many hundreds of thousands of prefixes on the public internet get routed correctly.

In addition to the ones you can define yourself, there are also some “well-known” communities. I always thought this was a goofy name for them. Try going out in the street and asking the average Jeff or Samantha whether they’ve heard of these communities. You’ll soon see how “well-known” they are.

In any case, these communities are reserved, and should be understood by all BGP-speaking routers. The below screenshot is from RFC 1997, which defines three of them. Read the whole screenshot if you like, but the bit I really want you to pay attention to is the actual numerical value of these three communities, written in hexadecimal.

As you can see from the screenshot above, the actual numerical contents of these communities is a lot of binary 1’s at the start. For example, NO_EXPORT is hex 0xFFFFFF01. If you were to write it out as a decimal community in the usual way, it would be 65535:65281.

Do you see the problem here?

What if an organization decided to use 65535 as their private AS, and they just so happened to decide to use 65535:65281 for some internal reason? This could have very dire unintended consequences indeed!

There’s more communities than just these three. In fact, you can see all the reserved communities at the IANA’s website here. Notice that all the reserved communities begin with 0xFFFF – that’s 65535.

As such, 65535 was taken away from the private pool. Note that RFC 7300 says “Operators SHOULD NOT use these Last ASNs for any other purpose or as Private Use ASNs”.  That’s SHOULD NOT, not MUST NOT. There’s no restriction, it’s just a recommendation. In any case, this clearly changed at some point between 1996 and 2013. And based on the fact that I can’t find very much that’s been written about it, my guess is that it happened more closely to 2013.

(By the way, the RFC does also say that this community problem doesn’t apply to the 32-bit AS 4294967295, but it’s reserved anyway in case of some future reason that we don’t know about yet. Luckily, unlike IPs, there’s enough 32-bit autonomous systems to last us for a fair while!)

 

THAT’S IT!

So there we have it! It turns out that the reason 65535 isn’t part of the private block is to protect network engineers from themselves.

I hope you enjoyed this little tour of networking history. It was a nice opportunity to learn a little BGP along the way! I find it so difficult to remember arbitrary numbers, but learning the reasons behind everything definitely helps it to stick in my mind. Hopefully you found it useful too.

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

Alternatively, if you hang around outside my house and listen very closely through the letterbox, you might be able to guess from my agonising screams when new posts go up. It might sound like a lot of hassle for you to do that, but Twitter is a garbage website, so the “standing outside my house at all times” strategy is probably more sensible in the long run.

And if you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.