I Am Not A Number

Understanding IANA and Why It Matters for Anyone Running Infrastructure

IANA is the Internet Assigned Numbers Authority. It is not a government agency, not a company you can sue, and not something most developers ever interact with directly. It is a function operated by an organization called Public Technical Identifiers under contract to ICANN, and its job is to maintain the registries that keep the internet from assigning the same identifier to two different things at once. That sounds simple until you need to register something non-standard and discover that the paperwork is harder than writing the protocol itself.

The registries under IANA include IP address allocations, autonomous system numbers, protocol numbers, Uniform Resource Identifier (URI) schemes, and media types among others. Each one serves a different purpose, and each one has different pain points. The IP assignments are regionally delegated to RIRs like ARIN or RIPE NCC, so if you are trying to get IPv4 space you go through your regional body, not IANA directly. But the protocol numbers and URI schemes? Those you request straight from IANA. This distinction is something people routinely miss and it wastes days when you realize you have been filling out the wrong form. The phrase "I Am Not A Number" comes up in technical conversations the way it shows up in casual discourse, often as a shorthand for pushing back against reductionist thinking. But in practice the real work involves dealing with the actual numbering systems IANA maintains. Understanding what those numbers represent and how they function is more useful than any slogan. Take protocol numbers as an example. When you see IP header field 17, that is the IANA-assigned protocol number for UDP. Field 6 is TCP. Field 89 is OSPF. These are assigned by IANA and published in their official registry. You can find them at iana.org/assignments/protocol-numbers/protocol-numbers.xhtml. They are small, they are static, and they are everywhere in every packet inspection tool and firewall rule set you will ever write. If you ever need to register a new protocol number for an experimental routing protocol you are running in a lab, the application is straightforward. Submit a request through the IANA form, provide documentation showing how the protocol works, explain the encapsulation, and wait a few weeks. Simple in theory.

How to Register Things With IANA in Practice

Most registrations follow one of three tracks: the Expert Review track, the IESG Approval track, and the Standards Action track. The difference between them determines how much effort you need to invest. Expert review applies to low-risk entries like private use ranges or internal protocol identifiers. IESG approval is for things that affect the broader internet stack. Standards Action means the protocol must be at least an RFC in progress before you can get an assignment. I spent three weeks on a URI scheme registration a while back because I did not initially understand which track applied to my case. The scheme I was registering was for a custom application protocol used internally across several corporate networks. I filed under expert review at first because I assumed the scope was limited. IANA returned the request and asked for IESG approval instead, since the scheme had any realistic chance of being deployed outside controlled environments. That feedback was accurate. The registry exists precisely to prevent namespace collisions at scale, and IANA takes its gatekeeping role seriously. I ended up drafting an RFC draft, getting it through working group review, and only then receiving the scheme assignment. The whole process took about four months from first submission to final registration. If you need something faster and your use case is genuinely internal, you can often negotiate a private-use assignment instead, but you give up the guarantee that nobody else will use the same name. URI scheme registration documentation is available at iana.org/assignments/uri-schemes/uri-schemes.xhtml. The application there asks for the proposed scheme name, the intended semantics, the security considerations, and contact information. Do not skip the security section. Registrations fail most often because the applicant glosses over how their scheme handles authentication, authorization, or data exposure. Write that part thoroughly even if your protocol seems obvious to you.

What Goes Wrong Most Often

One thing that catches people off guard is the media type registry. The IANA media types (formerly MIME types) are used constantly in web development, file upload handlers, and API design. The registry is at iana.org/assignments/media-types/media-types.xhtml. The problem is that many people assume they can just start using a custom media type like application/x-myformat without registering it. The x- prefix was originally intended for experimental or private use, but even that carries risk. If you publish software that sends application/x-myformat over the wire and someone else independently registers application/myformat, you now have a collision. It has happened. I have seen it happen in production when two companies building similar internal tools chose the same unregistered type and then spent months untangling the parsing errors that followed. Another area where things break is ASN registration. Autonomous System Numbers are delegated through RIRs, but the global coordination happens through IANA. If you run a multi-homed network and request ASNs from the wrong RIR for your region, your allocations can end up in a geographically inconsistent state that causes BGP path selection issues. This is rare but painful to debug. The IANA ASN pool is finite, and once an RIR exhausts its allocation it has to go back to IANA for more. That process is managed, but it is not instantaneous. Plan your ASN needs months ahead if you are running a large provider. IPv6ULA addresses and documentation examples are another place where ignorance of IANA's role causes problems. IANA does not assign individual /64 prefixes to end users. It delegates large blocks to RIRs, which then hand out smaller pieces. But for documentation and example code, IANA maintains the RFC 4193 ULA prefix _fc00::/7 and the documentation prefix 2001:db8::/32. Those are safe to use in examples. Using anything else from the global unicast space in sample code is a bad habit that occasionally leaks into production configs when people copy-paste without checking.

When IANA Assignments Are the Wrong Solution

There are scenarios where going through IANA makes sense and others where it actively hurts you. If you are building a proprietary protocol that will never leave your organization, registering a URI scheme or media type is pointless overhead. Use a namespaced identifier in your own schema and move on. The registration process takes time, requires documentation you may not have written yet, and creates a permanent public record of your design choices. Some teams treat IANA registration as a quality seal, but it is not. It is a coordination mechanism, nothing more. The fact that your scheme is registered tells other engineers it is officially unique, but it does not validate the protocol design itself. For experimental protocols in academic or research settings, the IETF offers a dedicated range for experimental use. Protocol numbers in the range from 253 through 255 in the IP header are reserved for experimental codes and do not require IANA assignment. Similarly, the IETF maintains an experimental URI scheme namespace. These exist precisely so you can test things without filing paperwork. I used the experimental protocol number range for a custom routing overlay I built for a university project. It avoided the entire IANA process and let me iterate quickly. The tradeoff is that anyone deploying the same experimental number in production will collide with you. There is also the question of whether IANA's processes keep pace with modern development. Some engineers have complained that the timeline for scheme registration is too slow for fast-moving projects. The current review cycle is typically a few weeks to a few months depending on the track. For a startup launching a new protocol, that is a real constraint. There is no fast-track option for commercial applications. The process is the same whether you are a researcher or a company. This is not a flaw in the technical design of the registries, but it is a practical bottleneck that affects how people adopt new standards.

Key Registries to Know

Protocol numbers: iana.org/assignments/protocol-numbers/protocol-numbers.xhtml. This is the one you reference when configuring IP-level tools and writing packet parsers. URI schemes: iana.org/assignments/uri-schemes/uri-schemes.xhtml. Essential for anyone defining custom URL-like identifiers. Media types: iana.org/assignments/media-types/media-types.xhtml. Used in HTTP headers, email, and any binary data interchange format.

ASN registry and RIR allocations: Each RIR maintains its own portal, but IANA oversees the global coordination. ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC each handle their own regions. Port numbers: iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml. These are managed by IANA directly and are frequently requested. The well-known port range from 0 through 1023 requires IANA approval. Dynamic or private ports from 49152 through 65535 do not need registration and are safe for internal use.

I Am Not A Number — The Registry Perspective

The registries IANA maintains are the reason your HTTPS requests resolve correctly, your email attachments render properly, and your BGP peering sessions stay stable. They are unglamorous infrastructure. Most people will never need to submit a registration. But the ones who do learn quickly that the process rewards preparation and punishes ambiguity. Write clear documentation. Understand which track applies to your request. And do not treat a registry entry as a substitute for designing a protocol that works.