Networking FAQ 3: Names and Addresses

Where do IP addresses and domain names come from?

Ultimate authority over names and addresses on the Internet comes from the Internet Corporation for Assigned Names and Numbers (ICANN), which was originally founded as a not-for-profit corporation created in 1998 as a result of the United States government's initiative to privatize control of the Internet. According to its bylaws, ICANN has three core responsibilities:

1. Coordinate the allocation and assignment of the three sets of unique identifiers for the Internet, which are:
   (a) Domain names (forming a system referred to as "DNS");
   (b) Internet protocol (IP) addresses and autonomous system (AS) numbers; and
   (c) Protocol port and parameter numbers.
2. Coordinate the operation and evolution of the DNS root name server system.
3. Coordinate policy development reasonably and appropriately related to these technical functions.

ICANN delegates control over most of the global DNS hierarchy to a number of independent registries which manage the hundreds of top-level domains (TLDs). For example, VeriSign currently maintains the .com and .net TLDs, while .org is maintained by the Public Internet Registry (PIR). (A complete listing of current TLDs and their registries is available here). Each registry is responsible for maintaining the database of domain names belonging to its TLD(s). Note that some TLDs, such as .gov and .edu, impose certain restrictions on organizations which can register domain names.

However, most registries don't register new domain names to end users directly. This process is delegated to ICANN-accredited registrars. Registrars act as middlemen between an individual or company registering a domain name for use and the registry responsible for the TLD to which the domain name belongs. In exchange for a small fee (usually around ten to thirty US dollars per year depending on the TLD), registrars inform the registry of the creation or modification of the domain name and maintain the relevant contact information for it.

There are literally thousands of commercial registrars which offer domain registration services around the world. Many web hosting providers offer domain registration as part of their hosting services. Some registries, like VeriSign, also function as registrars, but not all. While independent registries are contracted for maintenance of most TLDs, maintenance of the critical root DNS zone is left to a subordinate body of ICANN, the Internet Assigned Numbers Authority (IANA).

In addition to running the DNS root zone, IANA is responsible for delegating the assignment of IPv4 and IPv6 addresses from the global pool via Regional Internet Registries (RIRs), not to be confused with DNS TLD registries. There are five RIRs at the time of this writing, each servicing one or more geographic regions:

• AfriNIC (Africa)
• APNIC (Asia)
• ARIN (North America)
• LACNIC (South America)
• RIPE (Europe, the Middle East, and Central Asia)

An Internet Service Provider (ISP) or end user obtains IP address allocations from its appropriate RIR, or from an intermediate national or local Internet registry. RIRs are also responsible for the assignment of autonomous system (AS) numbers, which are used to uniquely identify an organization on the Internet.

IANA also manages protocol number assignments. By far the most familiar of these are TCP and UDP port numbers. For example, TCP port 80 is assigned for HTTP, whereas UDP port 53 is assigned for DNS. IANA also administers assignments including IP protocols, Internet Control Message Protocol (ICMP) type codes, Simple Network Management Protocol (SNMP) number spaces, and much more.

Did we really run out of IPv4 addresses?

Yes, but we only had a couple decades of warning. On February 3, 2011, ICANN allocated the last five remaining /8 spaces, one to each of the five RIRs. Since then, it has become increasingly difficult to secure new IPv4 space. Many organizations have begun implementing IPv6, but its adoption rate has not been as quickly as has been hoped. And it will be a long time before we actually start moving not just toward IPv6 but away from IPv4.

Can I buy more IP addresses?

In short, yes. I haven't had much experience with the process personally, but Lindsay Hill has published an excellent account.

Does IPv6 really provide a bazillion addresses?

An IPv6 address is 128 bits long, which in theory yields 2¹²⁸ unique addresses. People love to make outlandish and pointless analogies using this number ("That's enough to address every grain of sand on Earth!") but in practice we'll end up wasting far more addresses than we use.

For starters, most network segments will be assigned a 64-bit prefix regardless of how many end hosts they contain, to ensure compatibility with SLAAC and to simplify addressing schemes. So even on large multi-access segments we'll only ever use a few thousand out of 2⁶⁴ possible addresses. The good news is that such waste is nothing to fret about; it's actually part of how IPv6 is intended to work.

Additionally, the largest allow allocation for most organizations is a /32. If all of your segments are addressed as /64s, that only leaves 32 bits of space in which you have say over how networks are allocated. But hang on: 32 bits is equivalent numerically to the scope of the entire IPv4 world, just for your network! And on top of that, host addresses are essentially free because you'll never exhaust the space of a /64.

So no, we can't give every grain of sand on the planet an IPv6 address, as badly as we might want to. But the effectively infinite segment size coupled with the exponentially increased prefix space ensures that you should never find yourself backed into a corner when drafting an addressing scheme.

Why does IPv6 use hexadecimal addressing?

Odds are that you first learned about IPv4 and subnetting, and then moved onto IPv6 and its crazy-long addresses with letters in them. IPv4 addresses are expressed in decimal as 8-bit chunks separated by periods, called as dotted-decimal notation, whereas IPv6 addresses are expressed in hexadecimal as 16-bit chunks separated by colons. Hexadecimal was chosen for IPv6 because it allows for more compact addressing: Every byte is expressed with only two digits. This is in contrast to decimal, which can use up to three digits to express the value of a byte.

Consider the IPv6 address 2001:db8:4000:2d04:0002:55ff:fe47:b3c9. We could express this value in dotted-decimal format as 32.1.13.184.64.0.45.4.0.2.85.255.254.71.179.201, but that takes a lot longer to write or say. We could also express the IPv4 address 192.0.2.75 as c000:024b if we wanted to, but no one would recognize it as an IPv4 address.

Ultimately, both types of address are just binary strings (32 bits for IPv4 and 128 bits for IPv6). They only look different because we choose to write them differently.

What is IPAM?

IP address management (IPAM) entails tracking the allocation and utilization of IP address space on a network. This can be as simple as using a spreadsheet to record the static assignments of individual IPs within a subnet, or as complex as deploying a dedicated IPAM application to manage assignments across a global network. Many IPAM products integrate with DNS and DHCP services to keep these systems synchronized automatically. Most organizations start tracking IP allocations in a spreadsheet and move to a dedicated application as the network grows. There are many open source and commercial IPAM products available to choose from.

How do I create an IP addressing scheme?

Early in your career, you'll likely be working on networks with established infrastructure and addressing schemes. These might be decent, or they might be terrible, but they're there. You should always try in earnest to abide by existing schemes and policies where prudent, even if they're not ideal.

For example, suppose convention has been to allocate a /16 prefix out of the 10.0.0.0/8 RFC 1918 space for every new site on your network, regardless of its size. This approach could be made more efficient by varying the size of new allocations as appropriate to the size of each site, but deviating from the policy now might compromise strategies that were enacted back when the existing scheme was drafted. It might be best to continue with the current obtuse allocation policy until a sufficient effort can be put forth to overhaul addressing across the entire network.

That said, sometimes it's necessary to develop a new IP addressing design from scratch, whether for a greenfield deployment or to migrate away from a legacy scheme. While it would be impractical to discuss here all of the caveats you might encounter when laying out an address plan, there are a few solid guidelines that should keep you from shooting yourself in the foot.

• Efficient aggregation is key. The ability to efficiently summarize routes is crucial to a healthy, stable network. Allocate networks so that they can be summarized intuitively by function or geographic area. For example, if assigning a campus network out of 172.16.0.0/16, you might assign each building a /20, and number each floor with a /24 within that /20 sequentially. While perhaps not as efficient, this is preferable to numbering all floors sequentially, as that approach weakens your ability to summarize by building.

• Allow for future growth. Your addressing scheme should never be fully allocated at inception; you'll always want to leave room for growth, whether that means additional buildings or larger segments or whatever. One good strategy is to, for each prefix you allocate, reserve the subsequent prefix for future use. This allows you to simply double the size of any prefix if it needs to expand in the future. So if you allocate 192.168.118.0/24 to a segment, go ahead and reserve 192.168.119.0/24 for future use.

• Never assign networks by "natural" boundaries. It's a rookie mistake to address networks using natural decimal increments, which are not binary-friendly. For example, numbering networks as 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, etc. The same goes for numbering by VLAN ID. These networks don't aggregate at all.

• Don't forget infrastructure! One common pitfall is to painstakingly plan out every access segment, only to realize you've completely overlooked the network infrastructure itself. Be sure to set aside address space for point-to-point links, loopbacks, management, and other internal functions. Many people opt to address infrastructure out of a separate parent prefix, especially when using private addressing.

• Plan for IPv4 and IPv6 in parallel. Every segment in your network should have both IPv4 and IPv6 allocations, even if you're not using IPv6 yet. Planning for IPv6 now will avoid duplicating effort in the future.

How does IPv6 subnetting work?

Technically speaking, there is no such thing as IPv6 subnetting. When IPv4 was first developed, network size was determined by address class. We very quickly realized that this would not scale well, so the subnet mask was introduced just a few years later in 1985 (see RFC 950) and we've been using subnets ever since. However, IPv6 never included the concept of classful networks, so by extension there's no such thing as an IPv6 subnet. Instead, we refer to IPv6 networks as prefixes (a term which is also appropriate for IPv4 networks).

That said, "subnetting," or the manipulation of prefix length, works with the exact same logic in IPv6 as it does in IPv4. Extending the prefix length by one bit doubles its size; removing one bit halves it. Although doing the math by hand requires converting addresses to binary (just as with IPv4), networkers are strongly encouraged to allocate addresses along nibble (four-bit) boundaries where feasible. For example, RIRs like ARIN and RIPE only allocate address space as /32, /36, /40, and so on. This allows for easy evaluation of prefix masks, as the mask will not split any hexadecimal characters.

What prefix length should I use on point-to-point links?

Historically, point-to-point links we numbered with IPv4 using /30 prefix lengths. This was because the first and last IP address (as in any subnet) were deemed unusable as endpoint addresses. However, this was an extremely inefficient approach, as only 50% of addresses could be used: Each link consumed twice the IP space needed.

Fortunately, virtually all modern routers support the use of /31 prefixes for point-to-point links, which was first standardized in RFC 3021 back in 2000. This allows us to achieve 100% addressing efficiency, as each link requires and consumes only two IPv4 addresses. For example, the two end points of a link numbered with 192.168.0.0/31 would be 192.168.0.0 and 192.168.0.1. The 192.168.0.0 address might seem unnatural, but rest assured it's entirely valid with a /31 mask. So is 192.168.0.255/31.

Point-to-point links should be addressed with IPv6 in a similar manner, utilizing a /127 prefix. This was one time considered poor practice, however is now recommended per RFC 6164. Some network operators opt to configure links with a /127 prefix but to only allocate the first /127 out of a /64 for each link, rather than allocating sequential /127s. This keeps the link addressing very clean, since only the first two IPs will ever be used; for example, 2001:db8:ab:cd::/127 and 2001:db8:ab:cd::1/127. This might seem wasteful, however it's perfectly acceptable and even encouraged to allocate a single /64 per segment regardless of its size.

How should I name devices on my network?

Your approach to network naming will depend largely on personal taste and how much freedom you're allowed. Sometimes you will be required by policy to adopt the naming scheme of a parent entity or partner company. In other cases, the sheer breadth of your network might necessitate a naming scheme more complex than you'd prefer. While you can't always control how your network devices are named, here are some tips for creating an organized hierarchy should you be afforded the opportunity.

• Make liberal use of subdomains. If you have a number of small, geographically disparate sites, create a zone for each of them so that the hostnames for similar devices match across sites. For example, mail01.abc-east.example.com and mail01.abc-west.example.com. This prevents individual hostnames from becoming too unwieldy. But while it might make sense to go as far as creating one subdomain per building on a large campus, I'd probably stop short of creating one per floor. You'll have to decide what degree of granularity is appropriate for your network.

• Names should imply function. Some people like to serialize device names and use an external database to correlate function and location, but that's a huge pain in the ass if you have to look things up manually. Use names like "web" for HTTP servers, "db" for databases, "dns" for DNS, and so on. Use a generic label like "app" for servers which host multiple applications.

• Never name devices by brand. One rookie mistake is to confuse a device model with its function. For example, don't name your Cisco ASA firewalls asa1 and asa2. This would requires the devices' names to be changed if replaced with a different model of firewall (an option you always want to leave open).

• Naming schemes should be predictable. If you know there are four access switches at an office, they should be named something like switch01, switch02, switch03, and switch04, not Homer, Marge, Bart, and Lisa. While I appreciate the Simpsons reference, these names imply nothing about when the switches were installed or the position of each in the network hierarchy. (And what happens if you have to add three more switches? Which characters would you pick next?)

• Add zero padding where appropriate. You might have noticed that I zero-padded the switch names above to two digits even though there are only four switches. Padding offers a high degree of confidence that you'll be able as many switch as you'll ever need (up to 99) and still have names sorted properly. Consider what happens if you have eleven switches and don't pad their numbers: Alphabetically, they would be sorted as switch1, switch10, switch11, switch2, switch3... Zero-padding keeps things tidy.

• Use standardized abbreviations for geographic locations. Many organizations opt to use the three-character International Air Transport Association (IATA) code assigned to the nearest airport of a site. For example, a site in Ashburn, Virginia, would be designated IAD (the IATA designator for Dulles International Airport). If you have multiple sites in the same region, consider adding a numeric index to the code (IAD1, IAD2, IAD3...). Or if you need further granularity, consider adopting the UN's LOCODE system, which appends a unique three-character location code to a country's two-character code. Under LOCODE, the Ashburn site would be designated US-QAS. (The codes aren't always pretty, but they work.)