TCP/IP: Internet Address Architecture

When the Internet’s address structure was originally defined, every unicast IP address had a network portion, to identify the network on which the interface using the IP address was to be found, and a host portion, used to identify the particular host on the network given in the network portion. Thus, some number of contiguous bits in the address became known as the net number, and remaining bits were known as the host number. At the time, most hosts had only a single network interface, so the terms interface address and host address were used somewhat interchangeably.

With the realization that different networks might have different numbers of hosts, and that each host requires a unique IP address, a partitioning was devised wherein different-size allocation units of IP address space could be given out to different sites, based on their current and projected number of hosts. The partitioning of the address space involved five classes. Each class represented a different trade-off in the number of bits of a 32-bit IPv4 address devoted to the network number versus the number of bits devoted to the host number.

One of the earliest difficulties encountered when the Internet began to grow was the inconvenience of having to allocate a new network number for any new network segment that was to be attached to the Internet. This became especially cumbersome with the development and increasing use of local area networks (LANs) in the early 1980s.

To address the problem, it was natural to consider a way that a site attached to the Internet could be allocated a network number centrally that could then be subdivided locally by site administrators. If this could be accomplished without altering the rest of the Internet’s core routing infrastructure, so much the better.

Implementing this idea would require the ability to alter the line between the network portion of an IP address and the host portion, but only for local purposes at a site; the rest of the Internet would "see" only the traditional class A, B, and C partitions. The approach adopted to support this capability is called subnet addressing[RFC0950].

Using subnet addressing, a site is allocated a class A, B, or C network number, leaving some number of remaining host bits to be further allocated and assigned within a site. The site may further divide the host portion of its base address allocation into a subnetwork (subnet) number and a host number.

In exchange for the additional flexibility provided by subnet addressing, a new cost is imposed. Because the definition of the Subnet and Host fields is now site-specific (not dictated by the class of the network number), all routers and hosts at a site require a new way to determine where the Subnet field of the address and the Host field of the address are located within the address. Before subnets, this information could be derived directly by knowing whether a network number was from class A, B, or C (as indicated by the first few bits in the address).

This particular configuration allows the site to support 256 subnetworks, and each subnetwork may contain up to 254 hosts (now the first (network) and last (broadcast) addresses for each subnetwork are not available, as opposed to losing only the first and last addresses of the entire allocated range). Recall that the subnetwork structure is known only by hosts and routers where the subnetting is taking place. The remainder of the Internet still treats any address associated with the site just as it did prior to the advent of subnet addressing.

The subnet mask is an assignment of bits used by a host or router to determine how the network and subnetwork information is partitioned from the host information in a corresponding IP address. Subnet masks for IP are the same length as the corresponding IP addresses (32 bits for IPv4 and 128 bits for IPv6). They are typically configured into a host or router in the same way as IP addresses—either statically (typical for routers) or using some dynamic system such as the Dynamic Host Configuration Protocol (DHCP). For IPv4, subnet masks may be written in the same way an IPv4 address is written (i.e., dotted-decimal).

Although not originally required to be arranged in this manner, today subnet masks are structured as some number of 1 bits followed by some number of 0 bits. Because of this arrangement, it is possible to use a shorthand format for expressing masks that simply gives the number of contiguous 1 bits in the mask (starting from the left). This format is now the most common format and is sometimes called the prefix length.

Masks are used by routers and hosts to determine where the network/subnetwork portion of an IP address ends and the host part begins. A bit set to 1 in the subnet mask means the corresponding bit position in an IP address should be considered part of a combined network/subnetwork portion of an address, which is used as the basis for forwarding datagrams. Conversely, a bit set to 0 in the subnet mask means the corresponding bit position in an IP address should be considered part of the host portion.

It is possible to use a different-length subnet mask applied to the same network number in different portions of the same site. Although doing this complicates address configuration management, it adds flexibility to the subnet structure because different subnetworks may be set up with different numbers of hosts. Variable-length subnet masks (VLSM) are now supported by most hosts, routers, and routing protocols.

Recall that the number of hosts is constrained by the number of bits remaining in the IP address that are not used by the network/subnet number. For IPv4 and a /24 prefix, this allows for 32 – 24 = 8 bits (256 hosts); for /25, half as many (128 hosts); and for /26, half further still (64 hosts).

Note that each interface on each host and router depicted is now given both an IP address and a subnet mask, but the mask differs across the network topology.

With an appropriate dynamic routing protocol running among the routers (e.g., OSPF, IS-IS, RIPv2), traffic is able to flow correctly among hosts at the same site or to/from the outside of the site across the Internet.

Although it may not seem obvious, there is a common case where a subnetwork contains only two hosts. When routers are connected together by a point-to-point link requiring an IP address to be assigned at each end, it is common practice to use a /31 network prefix with IPv4, and it is now also a recommended practice to use a /127 prefix for IPv6 [RFC6164].

In each IPv4 subnetwork, a special address is reserved to be the subnet broadcast address. The subnet broadcast address is formed by setting the network/subnetwork portion of an IPv4 address to the appropriate value and all the bits in the Host field to 1.

Historically, a datagram using this type of address as its destination has also been known as a directed broadcast. Such a broadcast can, at least theoretically, be routed through the Internet as a single datagram until reaching the target subnetwork, at which point it becomes a collection of broadcast datagrams that are delivered to all hosts on the subnetwork.

In addition to the subnet broadcast address, the special-use address 255.255.255.255 is reserved as the local net broadcast (also called limited broadcast), which is never forwarded by routers.

Note that although routers may not forward broadcasts, subnet broadcasts and local net broadcasts destined for the same network to which a computer is attached should be expected to work unless explicitly disabled by end hosts. Such broadcasts do not require action by a router; link-layer broadcast mechanisms, if available, are used for supporting them.

Broadcast addresses are typically used with protocols such as UDP/IP or ICMP because these protocols do not involve two-party conversations as in TCP/IP.

IPv6 lacks any broadcast addresses; for places where broadcast addresses might be used in IPv4, IPv6 instead uses exclusively multicast addresses.

In addition to being longer than IPv4 addresses by a factor of 4, IPv6 addresses also have some additional structure. Special prefixes used with IPv6 addresses indicate the scope of an address. The scope of an IPv6 address refers to the portion of the network where it can be used.

Important examples of scopes include node-local (the address can be used only for communication on the same computer), link-local (used only among nodes on the same network link or IPv6 prefix), or global (Internet-wide).

In IPv6, most nodes have more than one address in use, often on the same network interface. Although this is supported in IPv4 as well, it is not nearly as common.

Link-local IPv6 addresses (and some global IPv6 addresses) use interface identifiers (IIDs) as a basis for unicast IPv6 address assignment.

IIDs are used as the low-order bits of an IPv6 address in all cases except where the address begins with the binary value 000, and as such they must be unique within the same network prefix.

IIDs are ordinarily 64 bits long and are formed either directly from the underlying link-layer MAC address of a network interface using a modified EUI-64 format [EUI64], or by another process that randomizes the value in hopes of providing some degree of privacy against address tracking.

In IEEE standards, EUI stands for extended unique identifier.

Many IEEE standards-compliant network interfaces (e.g., Ethernet) have used shorter-format addresses (48-bit EUIs) for years. The only significant difference between the EUI-48 and EUI-64 formats is their length.

The OUI is 24 bits long and occupies the first 3 bytes of both EUI-48 and EUI-64 addresses. The low-order 2 bits of the first bytes of these addresses are designated the u and g bits, respectively.

An EUI-64 can be formed from an EUI-48 by copying the 24-bit OUI value from the EUI-48 address to the EUI-64 address, placing the 16-bit value, hex FFFE in the fourth and fifth bytes of the EUI-64 address, and then copying the remaining organization-assigned bits.

Here we can see how the Ethernet’s hardware address 00:0c:29:85:26:07 is mapped to an IPv6 address.

In order to help relieve the pressure on the availability of IPv4 addresses (especially class B addresses), the classful addressing scheme was generalized using a scheme similar to VLSM, and the Internet routing system was extended to support Classless Inter-Domain Routing (CIDR) [RFC4632]. This provided a way to conveniently allocate contiguous address ranges that contained more than 255 hosts but fewer than 65,536. That is, something other than single class B or multiple class C network numbers could be allocated to sites.

Using CIDR, any address range is not predefined as being part of a class but instead requires a mask similar to a subnet mask, sometimes called a CIDR mask. CIDR masks are not limited to a site but are instead visible to the global routing system. Thus, the core Internet routers must be able to interpret and process masks in addition to network numbers. This combination of numbers, called a network prefix, is used for both IPv4 and IPv6 address management.

Eliminating the predefined separation of network and host number within an IP address makes finer-grain allocation of IP address ranges possible.

In the table, the bits defined and fixed by the prefix are highlighted. The remaining bits may be set to any combination of 0s and 1s, thereby covering the possible address range.

Removing the classful structure of IP addresses made it possible to allocate IP address blocks in a wider variety of sizes. Doing so, however, did not address the third concern from the list of problems; it did not help to reduce the number of routing table entries.

A routing table entry tells a router where to send traffic.

Essentially, the router inspects the destination IP address in an arriving datagram, finds a matching routing table entry, and from the entry extracts the "next hop" for the datagram.

At the time, few techniques were known to dramatically reduce the number of routing table entries while maintaining shortest-path routes to all destinations in the Internet. The best-known approach was published in a study of hierarchical routing [KK77] in the late 1970s by Kleinrock and Kamoun. They observed that if the network topology were arranged as a tree and addresses were assigned in a way that was "sensitive" to this topology, very small routing tables could be used while still maintaining shortest-path routes to all destinations.

In this figure, circles represent routers and lines represent network links between them.

In the Internet context, the hierarchical routing idea can be used in a specific way to reduce the number of Internet routing entries that would be required otherwise. This is accomplished by a procedure known as route aggregation. It works by joining multiple numerically adjacent IP prefixes into a single shorter prefix (called an aggregate or summary) that covers more address space.

Multicast addressing is supported by IPv4 and IPv6. An IP multicast address (also called group or group address) identifies a group of host interfaces, rather than a single one. Generally speaking, the group could span the entire Internet.

The portion of the network that a single group covers is known as the group’s scope [RFC2365]. Common scopes include node-local (same computer), link-local (same subnet), site-local (applicable to some site), global (entire Internet), and administrative.

Administrative scoped addresses may be used in an area of the network that has been manually configured into routers. A site administrator may configure routers as admin-scope boundaries, meaning that multicast traffic of the associated group is not forwarded past the router. Note that the site-local and administrative scopes are available for use only with multicast addressing.

Under software control, the protocol stack in each Internet host is able to join or leave a multicast group. When a host sends something to a group, it creates a datagram using one of its own (unicast) IP addresses as the source address and a multicast IP address as the destination. All hosts in scope that have joined the group should receive any datagrams sent to the group. The sender is not generally aware of the hosts receiving the datagram unless they explicitly reply. Indeed, the sender does not even know in general how many hosts are receiving its datagrams.

For IPv4, the class D space (224.0.0.0–239.255.255.255) with 28 bits free has been reserved for supporting multicast.

The blocks of addresses up to 224.255.255.255 are allocated for the exclusive use of certain application protocols or organizations. These are allocated as the result of action by the IANA or by the IETF.

The local network control block is limited to the local network of the sender; datagrams sent to those addresses are never forwarded by multicast routers. The All Hosts group (224.0.0.1) is one group in this block.

The internetwork control block is similar to the local network control range but is intended for control traffic that needs to be routed off the local link. An example from this block is the Network Time Protocol (NTP) multicast group (224.0.1.1) [RFC5905].

For IPv6, which is considerably more aggressive in its use of multicast, the prefix ff00::/8 has been reserved for multicast addresses, and 112 bits are available for holding the group number.

Many IPv6 multicast addresses allocated by the IANA for permanent use intentionally span multiple scopes. Each of these is defined with a certain offset relative to every scope (such addresses are called scope-relative or variable-scope for this reason). For example, the variable-scope multicast address ff0x::101 is reserved for NTP servers by [IP6MA]. The x indicates variable scope.

As with IPv4, there are a number of reserved IPv6 multicast addresses. These addresses are grouped by scope, except for the variable-scope addresses mentioned before.

An anycast address is a unicast IPv4 or IPv6 address that identifies a different host depending on where in the network it is used. This is accomplished by configuring Internet routers to advertise the same unicast routes from multiple locations in the Internet. Thus, an anycast address refers not to a single host in the Internet, but to the "most appropriate" or "closest" single host that is responding to the anycast address.

Anycast addressing is used most frequently for finding a computer that provides a common service [RFC4786].

For unicast IPv4 and IPv6 address space, the IANA delegates much of its allocation authority to a few regional Internet registries (RIRs). The RIRs coordinate with each other through an organization formed in 2003 called the Number Resource Organization (NRO).

These entities typically deal with relatively large address blocks. They allocate address space to smaller registries operating in countries (e.g., Australia and Singapore) and to large ISPs.

ISPs, in turn, provide address space to their customers and themselves. When users sign up for Internet service, they are ordinarily provided a (typically small) fraction or range of their ISP’s address space in the form of an address prefix.

These address ranges are owned and managed by the customer’s ISP and are called provider-aggregatable (PA) addresses because they consist of one or more prefixes that can be aggregated with other prefixes the ISP owns. Such addresses are also sometimes called non-portable addresses.

Switching providers typically requires customers to change the IP prefixes on all computers and routers they have that are attached to the Internet (an often unpleasant operation called renumbering).

An alternative type of address space is called provider-independent (PI) address space. Addresses allocated from PI space are allocated to the user directly and may be used with any ISP. However, because such addresses are owned by the customer, they are not numerically adjacent to the ISP’s own addresses and are therefore not aggregatable.

An ISP being asked to provide routing for a customer’s PI addresses may require additional payment for service or simply not agree to support such a configuration. In some sense, an ISP that agrees to provide routing for a customer’s PI addresses is taking on an extra cost relative to other customers by having to increase the size of its routing tables. On the other hand, many sites prefer to use PI addresses, and might be willing to pay extra for them, because it helps to avoid the need to renumber when switching ISPs (avoiding what has become known as provider lock).

It is possible to use the Internet WHOIS service to determine how address space has been allocated. For example, we can form a query for information about the IPv4 address 72.1.140.203 by accessing the corresponding URL http://whois.arin.net/rest/ip/72.1.140.203.txt:

Here we see that the address 72.1.140.203 is really part of the network called SPEK-SEA5-PART-1, which has been allocated the address range 72.1.140.192/27.

Furthermore, we can see that SPEK-SEA5-PART-1’s address range is a portion of the PA address space called NET-72-1-128-0-1. We can formulate a query for information about this network by visiting the URL http://whois.arin.net/rest/net/NET-72-1-128-0-1.txt:

This record indicates that the address range 72.1.128.0/18 (called by the "handle" or name NET-72-1-128-0-1) has been directly allocated out of the address range 72.0.0.0/8 managed by ARIN. More details on data formats and the various methods ARIN supports for WHOIS queries can be found at.

We can look at a different type of result using one of the other RIRs. For example, if we search for information regarding the IPv4 address 193.5.93.80 using the Web query interface at http://www.ripe.net/whois, we obtain the following result:

Here, we can see that the address 193.5.93.80 is a portion of the 193.5.88.0/21 block allocated to WIPO.

Note that the status of this block is ASSIGNED PI, meaning that this particular block of addresses is of the provider-independent variety.

The reference to RPSL indicates that the database records are in the Routing Policy Specification Language [RFC2622][RFC4012], used by ISPs to express their routing policies. Such information allows network operators to configure routers to help minimize Internet routing instabilities.

The simplest type of Internet service that can be obtained today is to receive a single IP address (typically IPv4 only in the United States) from an ISP to be used with a single computer. For services such as DSL, the single address might be assigned as the end of a point-to-point link and might be temporary.

Many Internet users who own more than one computer find that having only a single computer attached to the Internet is not an ideal situation. As a result, they have home LAN or WLAN networks and use either a router or a computer acting as a router to provide connectivity to the Internet. Such configurations are very similar to the single-computer case, except the router forwards packets from the home network to the ISP and also performs NAT (also called Internet Connection Sharing (ICS) in Windows) by rewriting the IP addresses in packets being exchanged with the customer’s ISP. From the ISP’s point of view, only a single IP address has been used.

Today, much of this activity is automated, so the need for manual address configuration is minimal. The routers provide automatic address assignment to the home clients using DHCP. They also handle address assignment for the link set up with the ISP if necessary.

Many organizations find that the allocation of a single unicast address, especially if it is only temporarily assigned, is insufficient for their Internet access needs.

In particular, organizations intending to run Internet servers (such as Web sites) generally wish to have an IP address that does not change over time. These sites also often have multiple LANs; some of them are internal (separated from the Internet by firewalls and NAT devices), and others may be external (providing services to the Internet). For such networks, there is typically a site or network administrator who must decide how many IP addresses the site requires, how to structure subnets at the site, and which subnets should be internal and which external.

Some organizations that depend on Internet access for their continued operations attach to the Internet using more than one provider (called multihoming) in order to provide for redundancy in case of failure, or for other reasons.

Because of CIDR, organizations with a single ISP tend to have PA IP addresses associated with that ISP. If they obtain a second ISP, the question arises as to what IP addresses should be used in each of the hosts.

Some guidance has been developed for operating with multiple ISPs, or when transitioning from one to another (which raises some similar concerns). For IPv4, [RFC4116] discusses how either PI or PA addresses can be used for multihoming.

Here, a (somewhat) fictitious site S has two ISPs, P1 and P2.

If it uses PA address space from P1’s block (12.46.129.0/25), it advertises this prefix at points C and D to P1 and P2, respectively. The prefix can be aggregated by P1 into its 12/8 block in advertisements to the rest of the Internet at point A, but P2 is not able to aggregate it at point B because it is not numerically adjacent to its own prefix (137.164/16).

In addition, from the point of view of some host in the other parts of the Internet, traffic for 12.46.129.0/25 tends to go through ISP P2 rather than ISP P1 because the prefix for site S is longer than when it goes through P1. This is a consequence of the way the longest matching prefix algorithm works for Internet routing.

In essence, a host in the other parts of the Internet could reach the address 12.46.129.1 via either a matching prefix 12.0.0.0/8 at point A or the prefix 12.46.129.0/25 at point B. Because each prefix matches (i.e., contains a common set of prefix bits with the destination address 12.46.129.1), the one with the larger or longer mask (larger number of matching bits) is preferred, which in this case is P2. Thus, P2 is in the position of being unable to aggregate the prefix from S and also winds up carrying most of S’s traffic.

If site S decides to use PI space instead of PA space, the situation is more symmetric.

However, no aggregation is possible. In this case, the PI prefix 198.134.135.0/24 is advertised to P1 and P2 at points C and D, respectively, but neither ISP is able to aggregate it because it is not numerically adjacent to either of the ISPs' address blocks. Thus, both ISPs advertise the identical prefix 198.134.135.0/24 at points A and B. In this fashion the "natural" shortest-path computations in Internet routing can take place, and site S can be reached by whichever ISP is closer to the host sending to it. In addition, if site S decides to switch ISPs, it does not have to change its assigned addresses. Unfortunately, the inability to aggregate such addresses can be a concern for future scalability of the Internet, so PI space is in relatively short supply.

Multihoming for IPv6 has been the subject of study within the IETF for some time, resulting in the Multi6 architecture [RFC4177] and the Shim6 protocol [RFC5533].