Every device connected to the Internet has at least one IP address. Devices used in private networks based on the TCP/IP protocols also require IP addresses.

In either case, the forwarding procedures implemented by IP routers use IP addresses to identify where traffic is going. IP addresses also indicate where traffic has come from.

IP addresses are similar in some ways to telephone numbers, but whereas telephone numbers are often known and used directly by end users.

IP addresses are often shielded from a user’s view by the Internet’s DNS, which allows most users to use names instead of numbers.

1. Expressing IP Address

The vast majority of Internet users who are familiar with IP addresses understand the most popular type: IPv4 addresses. Such addresses are often represented in so-called dotted-quad or dotted-decimal notation.

Table 1. Example IPv4 addresses written in dotted-quad and binary notation
Dotted-Quad Representation Binary Representation

0.0.0.0

00000000 00000000 00000000 00000000

1.2.3.4

00000001 00000010 00000011 00000100

10.0.0.255

00001010 00000000 00000000 11111111

165.195.130.107

10100101 11000011 10000010 01101011

255.255.255.255

11111111 11111111 11111111 11111111

In IPv6, addresses are 128 bits in length, four times larger than IPv4 addresses, and generally speaking are less familiar to most users. The conventional notation adopted for IPv6 addresses is a series of four hexadecimal ("hex," or base-16) numbers called blocks or fields separated by colons.

Although not as familiar to users as decimal numbers, hexadecimal numbers make the task of converting to binary somewhat simpler. In addition, a number of agreed-upon simplifications have been standardized for expressing IPv6 addresses [RFC4291]:

  1. Leading zeros of a block need not be written.

    For example, the address 5f05:2000:80ad:5800:0058:0800:2023:1d71 can been written as 5f05:2000:80ad:5800:58:800:2023:1d71.

  2. Blocks of all zeros can be omitted and replaced by the notation ::.

    For example, the IPv6 address 0:0:0:0:0:0:0:1 can be written more compactly as ::1. Similarly, the address 2001:0db8:0:0:0:0:0:2 can be written more compactly as 2001:db8::2.

    To avoid ambiguities, the :: notation may be used only once in an IPv6 address.

  3. Embedded IPv4 addresses represented in the IPv6 format can use a form of hybrid notation in which the block immediately preceding the IPv4 portion of the address has the value ffff and the remaining part of the address is formatted using dotted-quad.

    For example, the IPv6 address ::ffff:10.0.0.1 represents the IPv4 address 10.0.0.1. This is called an IPv4-mapped IPv6 address.

  4. A conventional notation is adopted in which the low-order 32 bits of the IPv6 address can be written using dotted-quad notation.

    The IPv6 address ::0102:f001 is therefore equivalent to the address ::1.2.240.1. This is called an IPv4-compatible IPv6 address.

    Note that IPv4-compatible addresses are not the same as IPv4-mapped addresses; they are compatible only in the sense that they can be written down or manipulated by software in a way similar to IPv4 addresses.

Table 2. Examples of IPv6 addresses and their binary representations
Hex Notation Binary Representation

5f05:2000:80ad:5800:58:800:2023:1d71

0101111100000101 0010000000000000 1000000010101101 0101100000000000 0000000001011000 0000100000000000 0010000000100011 0001110101110001

::1

0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000001

::1.2.240.1 or ::102:f001

0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000100000010 1111000000000001

In some circumstances (e.g., when expressing a URL containing an address) the colon delimiter in an IPv6 address may be confused with another separator such as the colon used between an IP address and a port number. In such circumstances, bracket characters, [ and ], are used to surround the IPv6 address.

For example, the URL http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/ refers to port number 443 on IPv6 host 2001:0db8:85a3:08d3:1319:8a2e:0370:7344 using the HTTP/TCP/IPv6 protocols.

2. Basic IP Address Structure

Because of the large number of addresses (especially for IPv6), it is convenient to divide the address space into chunks. IP addresses are grouped by type and size.

Most of the IPv4 address chunks are eventually subdivided down to a single address and used to identify a single network interface of a computer attached to the Internet or to some private intranet. These addresses are called unicast addresses.

Beyond unicast addresses, other types of addresses include broadcast, multicast, and anycast, which may refer to more than one interface, plus some special-purpose addresses.

2.1. Classful Addressing

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.

Table 3. The original ("classful") IPv4 address space partitioning
Class Address Range High-Order Bits Use Fraction of Total Number of Nets Number of Hosts

A

0.0.0.0–127.255.255.255

0

Unicast/special

1/2

128

16,777,216

B

128.0.0.0–191.255.255.255

10

Unicast/special

1/4

16,384

65,536

C

192.0.0.0–223.255.255.255

110

Unicast/special

1/8

2,097,152

256

D

224.0.0.0–239.255.255.255

1110

Multicast

1/16

N/A

N/A

E

240.0.0.0–255.255.255.255

1111

Reserved

1/16

N/A

N/A

2.2. Subnet Addressing

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).

Table 4. An example of a subnetted class B address. Using 8 bits for the subnet ID provides for 256 subnets with 254 hosts on each of the subnets. This partitioning may be altered by the network administrator.
Class Centrally Allocated Locally Managed at Site

B

110

Net Number (16 bits; 14 free)

Subnet ID (8 bits)

Host ID (8 bits)

This particular configuration allows the site to support 256 subnetworks, and each subnetwork may contain up to 254 hosts (now the first and last 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.

subnet addressing
Figure 1. A site is allocated the classical class B network number 128.32. The network administrator decides to apply a site-wide subnet mask of 255.255.255.0, giving 256 subnetworks where each subnetwork can hold 256 – 2 = 254 hosts. The IPv4 address of each host on the same subnet has the subnetwork number in common. All of the IPv4 addresses of hosts on the left-hand LAN segment start with 128.32.1, and all of those on the right start with 128.32.2.

2.3. Subnet mask

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.

Table 5. IPv4 subnet mask examples in various formats
Dotted-Decimal Representation Shorthand (Prefix Length) Binary Representation

128.0.0.0

/1

10000000 00000000 00000000 00000000

255.0.0.0

/8

11111111 00000000 00000000 00000000

255.192.0.0

/10

11111111 11000000 00000000 00000000

255.255.0.0

/16

11111111 11111111 00000000 00000000

255.255.254.0

/23

11111111 11111111 11111110 00000000

255.255.255.192

/27

11111111 11111111 11111111 11100000

255.255.255.255

/32

11111111 11111111 11111111 11111111

Table 6. IPv6 subnet mask examples in various formats
Hex Notation Shorthand (Prefix Length) Binary Representation

ffff:ffff:ffff:ffff::

/64

1111111111111111 1111111111111111 1111111111111111 1111111111111111 0000000000000000 0000000000000000 0000000000000000 0000000000000000

ff00::

/8

1111111100000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000

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.

ip network subnet
Figure 2. An IP address can be combined with a subnet mask using a bitwise AND operation in order to form the network/subnetwork identifier (prefix) of the address used for routing. In this example, applying a mask of length 24 to the IPv4 address 128.32.1.14 gives the prefix 128.32.1.0/24.

2.4. Variable-Length Subnet Masks (VLSM)

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.

Variable-Length Subnet Masks
Figure 3. VLSM can be used to partition a network number into subnetworks with a differing number of hosts on each subnet. Each router and host is configured with a subnet mask in addition to its IP address. Most software supports VLSM, except for some older routing protocols (e.g., RIP version 1).

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].

2.5. Broadcast Address

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.

Subnet Broadcast Address
Figure 4. The subnet broadcast address is formed by ORing the complement of the subnet mask with the IPv4 address. In this case of a /24 subnet mask, all of the remaining 32 – 24 = 8 bits are set to 1, giving a decimal value of 255 and the subnet broadcast address of 128.32.1.255.

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.

192.168.91.128
$ sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
$ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0
192.168.91.137
$ ping -b -c 2 192.168.91.255
PING 192.168.91.255 (192.168.91.255) 56(84) bytes of data.
64 bytes from 192.168.91.2: icmp_seq=1 ttl=128 time=0.208 ms
64 bytes from 192.168.91.128: icmp_seq=1 ttl=64 time=0.956 ms (DUP!)
64 bytes from 192.168.91.128: icmp_seq=1 ttl=64 time=0.963 ms (DUP!)
64 bytes from 192.168.91.2: icmp_seq=2 ttl=128 time=0.146 ms

$ ping -b -c2 255.255.255.255
PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.
64 bytes from 192.168.91.2: icmp_seq=1 ttl=128 time=0.304 ms
64 bytes from 192.168.91.128: icmp_seq=1 ttl=64 time=0.320 ms (DUP!)
64 bytes from 192.168.91.128: icmp_seq=1 ttl=64 time=0.320 ms (DUP!)
64 bytes from 192.168.91.2: icmp_seq=2 ttl=128 time=0.235 ms

2.6. IPv6 Addresses and Interface Identifiers

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.

  • EUI-64 identifiers start with a 24-bit Organizationally Unique Identifier (OUI) followed by a 40-bit extension identifier assigned by the organization, which is identified by the first 24 bits.

  • The OUIs are maintained and allocated by the IEEE registration authority [IEEERA].

  • EUIs may be "universally administered" or "locally administered."

  • In the Internet context, such addresses are typically of the universally administered variety.

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.

EUI-48 and EUI-64 formats
Figure 5. The EUI-48 and EUI-64 formats defined by the IEEE. These are used within IPv6 to form interface identifiers by inverting the u bit.

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.

  • The u bit, when set, indicates that the address is locally administered.

  • The g bit, when set, indicates that the address is a group or multicast-type address.

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.

$ ip a s ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:85:26:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.91.137/24 brd 192.168.91.255 scope global dynamic ens32
       valid_lft 1073sec preferred_lft 1073sec
    inet6 fe80::20c:29ff:fe85:2607/64 scope link
       valid_lft forever preferred_lft forever

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

  • First, it is converted to EUI-64, forming the address 00:0c:29:ff:fe:85:26:07.

  • Next, the u bit is inverted, forming the IID value 02:0c:29:ff:fe:85:26:07.

  • To complete the link-local IPv6 address, we use the reserved link-local prefix fe80::/10.

  • Together, these form the complete address, fe80::20c:29ff:fe85:2607.

  • The presence of /64 is the standard length used for identifying the subnetwork/host portion of an IPv6 address derived from an IID as required by [RFC4291].

3. CIDR and Aggregation

In the early 1990s, after the adoption of subnet addressing to ease one form of growing pains, the Internet started facing a serious set of scaling problems. Three particular issues were considered so important as to require immediate attention:

  1. By 1994, over half of all class B addresses had already been allocated. It was expected that the class B address space would be exhausted by about 1995.

  2. The 32-bit IPv4 address was thought to be inadequate to handle the size of the Internet anticipated by the early 2000s.

  3. The number of entries in the global routing table (one per network number), about 65,000 in 1995, was growing. As more and more class A, B, and C routing entries appeared, routing performance would suffer.

These three issues were attacked by a group in the IETF called ROAD (for ROuting and ADdressing), starting in 1992. They considered problems 1 and 3 to be of immediate concern, and problem 2 as requiring a long-term solution. The short-term solution they proposed was to effectively remove the class breakdown of IP addresses and also promote the ability to aggregate hierarchically assigned IP addresses. These measures would help problems 1 and 3. IPv6 was envisioned to deal with problem 2.

3.1. Prefixes

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.

  • As with classful addressing, dividing the address spaces into chunks is most easily achieved by grouping numerically contiguous addresses for use as a type or for some particular special purpose.

  • Such groupings are now commonly expressed using a prefix of the address space.

    • An n-bit prefix is a predefined value for the first n bits of an address.

    • The value of n (the length of the prefix) is typically expressed as an integer in the range 0–32 for IPv4 and 0–128 for IPv6.

    • It is generally appended to the base IP address following a / character.

Table 7. Examples of prefixes and their corresponding IPv4 or IPv6 address range
Prefix Prefix (Binary) Address Range

0.0.0.0/0

00000000 00000000 00000000 00000000

0.0.0.0–255.255.255.255

128.0.0.0/1

10000000 00000000 00000000 00000000

128.0.0.0–255.255.255.255

128.0.0.0/24

10000000 00000000 00000000 00000000

128.0.0.0–128.0.0.255

198.128.128.192/27

11000110 10000000 10000000 11000000

198.128.128.192–198.128.128.223

165.195.130.107/32

10100101 11000011 10000010 01101011

165.195.130.107

2001:db8::/32

0010000000000001 0000110110111000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000

2001:db8::–2001:db8:ffff:ffff

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.

  • Clearly, a smaller prefix length corresponds to a larger number of possible addresses.

  • In addition, the earlier classful addressing approach is easily generalized by this scheme.

    • For example, the class C network number 192.125.3.0 can be written as the prefix 192.125.3.0/24 or 192.125.3/24.

    • Classful A and B network numbers can be expressed using /8 and /16 prefix lengths, respectively.

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.

A network with a tree topology
Figure 6. In a network with a tree topology, network addresses can be assigned in a special way so as to limit the amount of routing information (“state”) that needs to be stored in a router. If addresses are not assigned in this way (left side), shortest-path routes cannot be guaranteed without storing an amount of state proportional to the number of nodes to be reached. While assigning addresses in a way that is sensitive to the tree topology saves state, if the network topology changes, a reassignment of addresses is generally required.

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

  • The root (top) of the tree on the left is the router labeled 19.12.4.8. In order to know a next hop for every possible destination, it needs an entry for all the routers "below" it in the tree: 190.16.11.2, 86.12.0.112, 159.66.2.231, 133.17.97.12, 66.103.2.19, 18.1.1.1, 19.12.4.9, and 203.44.23.198. For any other destination, it simply routes to the cloud labeled "Other Parts of the Network." This results in a total of nine entries.

  • In contrast, the root of the right-hand tree is labeled 19.0.0.1 and requires only three entries in its routing table. Note that all of the routers on the left side of the right tree begin with the prefix 19.1 and all to the right begin with 19.2. Thus, the table in router 19.0.0.1 need only show 19.1.0.1 as the next hop for any destination starting with 19.1, whereas 19.2.0.1 is the next hop for any destination starting with 19.2. Any other destination goes to the cloud labeled "Other Parts of the Network." This results in a total of three entries.

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.

Route Aggregation
Figure 7. In this example, the arrows indicate aggregation of two address prefixes to form one; the underlined prefixes are additions in each step. In the first step, 190.154.27.0/26 and 190.154.27.64.0/26 can be aggregated because they are numerically adjacent, but 190.154.27.192/26 cannot. With the addition of 190.154.27.128/26, they can all be aggregated together in two steps to form 190.154.27.0/24. With the final addition of the adjacent 190.154.26.0/24, the aggregate 190.154.26.0/23 is produced.

4. Special-Use Addresses

Both the IPv4 and IPv6 address spaces include a few address ranges that are used for special purposes (and are therefore not used in assigning unicast addresses).

For both IPv4 and IPv6, address ranges not designated as special, multicast, or reserved are available to be assigned for unicast use. Some unicast address space (prefixes 10/8, 172.16/12, and 192.168/16 for IPv4 and fc00::/7 for IPv6) is reserved for building private networks. Addresses from these ranges can be used by cooperating hosts and routers within a site or organization, but not across the global Internet. Thus, these addresses are sometimes called nonroutable addresses. That is, they will not be routed by the public Internet.

The management of private, nonroutable address space is entirely a local decision. The IPv4 private addresses are very common in home networks and for the internal networks of moderately sized and large enterprises. They are frequently used in combination with network address translation (NAT), which rewrites IP addresses inside IP datagrams as they enter the Internet.

Table 8. IPv4 special-use addresses (defined January 2010)
Prefix Special Use Reference

0.0.0.0/8

Hosts on the local network. May be used only as a source IP address.

[RFC1122]

10.0.0.0/8

Address for private networks (intranets). Such addresses never appear on the public Internet.

[RFC1918]

127.0.0.0/8

Internet host loopback addresses (same computer). Typically only 127.0.0.1 is used.

[RFC1122]

169.254.0.0/16

"Link-local" addresses—used only on a single link and generally assigned automatically.

[RFC3927]

172.16.0.0/12

Address for private networks (intranets). Such addresses never appear on the public Internet.

[RFC1918]

192.0.0.0/24

IETF protocol assignments (IANA reserved).

[RFC5736]

192.0.2.0/24

TEST-NET-1 addresses approved for use in documentation. Such addresses never appear on the public Internet.

[RFC5737]

192.88.99.0/24

Used for 6to4 relays (anycast addresses).

[RFC3068]

192.168.0.0/16

Address for private networks (intranets). Such addresses never appear on the public Internet.

[RFC1918]

198.18.0.0/15

Used for benchmarks and performance testing.

[RFC2544]

198.51.100.0/24

TEST-NET-2. Approved for use in documentation.

[RFC5737]

203.0.113.0/24

TEST-NET-3. Approved for use in documentation.

[RFC5737]

224.0.0.0/4

IPv4 multicast addresses (formerly class D); used only as destination addresses.

[RFC5771]

240.0.0.0/4

Reserved space (formerly class E), except 255.255.255.255.

[RFC1112]

255.255.255.255/32

Local network (limited) broadcast address.

[RFC0919] [RFC0922]

Table 9. IPv6 special-use addresses (defined April 2008)
Prefix Special Use Reference

::/0

Default route entry. Not used for addressing.

[RFC5156]

::/128

The unspecified address; may be used as a source IP address.

[RFC4291]

::1/128

The IPv6 host loopback address; not used in datagrams sent outside the local host.

[RFC4291]

::ffff:0:0/96

IPv4-mapped addresses. Such addresses never appear in packet headers. For internal host use only.

[RFC4291]

::{ipv4-address}/96

IPv4-compatible addresses. Deprecated; not to be used.

[RFC4291]

2001::/32

Teredo addresses.

[RFC4380]

2001:10::/28

Overlay Routable Cryptographic Hash Identifiers. Such addresses never appear on the public Internet.

[RFC4843]

2001:db8::/32

Address range used for documentation and for examples. Such addresses never appear on the public Internet.

[RFC3849]

2002::/16

6to4 addresses of 6to4 tunnel relays.

[RFC3056]

3ffe::/16

Used by 6bone experiments. Deprecated; not to be used.

[RFC3701]

5f00::/16

Used by 6bone experiments. Deprecated; not to be used.

[RFC3701]

fc00::/7

Unique, local unicast addresses; not used on the global Internet.

[RFC4193]

fe80::/10

Link-local unicast addresses.

[RFC4291]

ff00::/8

IPv6 multicast addresses; used only as destination addresses.

[RFC4291]

4.1. Multicast Addresses

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 groupi’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.

4.2. IPv4 Multicast Addresses

For IPv4, the class D space (224.0.0.0239.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].

Table 10. Major sections of IPv4 class D address space used for supporting multicast
Range (Inclusive) Special Use Reference

224.0.0.0–224.0.0.255

Local network control; not forwarded

[RFC5771]

224.0.1.0–224.0.1.255

Internetwork control; forwarded normally

[RFC5771]

224.0.2.0–224.0.255.255

Ad hoc block I

[RFC5771]

224.1.0.0–224.1.255.255

Reserved

[RFC5771]

224.2.0.0–224.2.255.255

SDP/SAP

[RFC4566]

224.3.0.0–224.4.255.255

Ad hoc block II

[RFC5771]

224.5.0.0–224.255.255.255

Reserved

[IP4MA]

225.0.0.0–231.255.255.255

Reserved

[IP4MA]

232.0.0.0–232.255.255.255

Source-specific multicast (SSM)

[RFC4607] [RFC4608]

233.0.0.0–233.251.255.255

GLOP

[RFC3180]

233.252.0.0–233.255.255.255

Ad hoc block III 233.252.0.0/24 is reserved for documentation)

[RFC5771]

234.0.0.0–234.255.255.255 235.0.0.0–238.255.255.255

Unicast-prefix-based IPv4 multicast addresses Reserved

[RFC6034] IP4MA]

239.0.0.0–239.255.255.255

Administrative scope

[RFC2365]

4.3. IPv6 Multicast Addresses

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.

IPv6 Multicast Address Format
Figure 8. The base IPv6 multicast address format includes 4 flag bits (0, reserved; R, contains rendezvous point; P, uses unicast prefix; T, is transient). The 4-bit Scope value indicates the scope of the multicast (global, local, etc.). The Group ID is encoded in the low-order 112 bits. If the P or R bit is set, an alternative format is used.
Table 11. Values of the IPv6 Scope field
Value Scope

0

Reserved

1

Interface-/machine-local

2

Link-/subnet-local

3

Reserved

4

Admin

5

Site-local

6–7

Unassigned

8

Organizational-local

9–d

Unassigned

e

Global

f

Reserved

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.

Table 12. Example permanent variable-scope IPv6 multicast address reservations for NTP (101)
Address Meaning

ff01::101

All NTP servers on the same machine

ff02::101

All NTP servers on the same link/subnet

ff04::101

All NTP servers within some administratively defined scope

ff05::101

All NTP servers at the same site

ff08::101

All NTP servers at the same organization

ff0e::101

All NTP servers in the Internet

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.

Table 13. Reserved addresses within the IPv6 multicast address space
Address Scope Special Use Reference

ff01::1

Node

All nodes

[RFC4291]

ff01::2

Node

All routers

[RFC4291]

ff01::fb

Node

mDNSv6

[IDChes]

ff02::1

Link

All nodes

[RFC4291]

ff02::2

Link

All routers

[RFC4291]

ff02::4

Link

DVMRP routers

[RFC1075]

ff02::5

Link

OSPFIGP

[RFC2328]

ff02::6

Link

OSPFIGP designated routers

[RFC2328]

ff02::9

Link

RIPng routers

[RFC2080]

ff02::a

Link

EIGRP routers

[EIGRP]

ff02::d

Link

PIM routers

[RFC5059]

ff02::16

Link

MLDv2-capable routers

[RFC3810]

ff02::6a

Link

All snoopers

[RFC4286]

ff02::6d

Link

LL-MANET-routers

[RFC5498]

ff02::fb

Link

mDNSv6

[IDChes]

ff02::1:2

Link

All DHCP agents

[RFC3315]

ff02::1:3

Link

LLMNR

[RFC4795]

ff02::1:ffxx:xxxx

Link

Solicited-node address range

[RFC4291]

ff05::2

Site

All routers

[RFC4291]

ff05::fb

Site

mDNSv6

[IDChes]

ff05::1:3

Site

All DHCP servers

[RFC3315]

ff0x::

Variable

Reserved

[RFC4291]

ff0x::fb

Variable

mDNSv6

[IDChes]

ff0x::101

Variable

NTP

[RFC5905]

ff0x::133

Variable

Aggregate Server Access Protocol

[RFC5352]

ff0x::18c

Variable

All ACs address (CAPWAP)

[RFC5415]

ff3x::/32

(Special)

SSM block

[RFC4607]

4.4. Anycast Address

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].

5. Allocation

IP address space is allocated, usually in large chunks, by a collection of hierarchically organized authorities.

The authorities are generally organizations that allocate address space to various owners—usually ISPs or other smaller authorities.

Authorities are most often involved in allocating portions of the global unicast address space, but other types of addresses (multicast and special-use) are also sometimes allocated. The authorities can make allocations to users for an undetermined amount of time, or for a limited time (e.g., for running experiments).

The top of the hierarchy is the IANA [IANA], which has wide-ranging responsibility for allocating IP addresses and other types of numbers used in the Internet protocols.

5.1. Unicast

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).

Table 14. Regional Internet registries that participate in the NRO
RIR Name Area of Responsibility Reference

AfriNIC—African Network Information Center

Africa

http://www.afrinic.net

APNIC—Asia Pacific Network Information Center

Asia/Pacific Area

http://www.apnic.net

ARIN—American Registry for Internet Numbers

North America

http://www.arin.net

LACNIC—Regional Latin America and Caribbean IP Address Registry

Latin America and some Caribbean islands

http://lacnic.net/en/index.html

RIPE NCC—Réseaux IP Européens

Europe, Middle East, Central Asia

http://www.ripe.net

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:

NetRange: 72.1.140.192 - 72.1.140.223
CIDR: 72.1.140.192/27
OriginAS:
NetName: SPEK-SEA5-PART-1
NetHandle: NET-72-1-140-192-1
Parent: NET-72-1-128-0-1
NetType: Reassigned
RegDate: 2005-06-29
Updated: 2005-06-29
Ref: http://whois.arin.net/rest/net/NET-72-1-140-192-1

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:

NetRange: 72.1.128.0 - 72.1.191.255
CIDR: 72.1.128.0/18
OriginAS:
NetName: SPEAKEASY-6
NetHandle: NET-72-1-128-0-1
Parent: NET-72-0-0-0-0
NetType: Direct Allocation
RegDate: 2004-09-09
Updated: 2009-05-19
Ref: http://whois.arin.net/rest/net/NET-72-1-128-0-1

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:

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
%
% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '193.5.88.0 - 193.5.95.255'
inetnum: 193.5.88.0 - 193.5.95.255
netname: WIPONET
descr: World Intellectual Property Organization
descr: UN Specialized Agency
descr: Geneva
country: CH
admin-c: AM4504-RIPE
tech-c: AM4504-RIPE
status: ASSIGNED PI
mnt-by: CH-UNISOURCE-MNT
mnt-by: DE-COLT-MNT
source: RIPE # Filtered

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.

$ whois 220.196.60.2
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '220.192.0.0 - 220.207.255.255'

% Abuse contact for '220.192.0.0 - 220.207.255.255' is 'ipas@cnnic.cn'

inetnum:        220.192.0.0 - 220.207.255.255
netname:        UNICOM
descr:          China Unicom
descr:          No.21 Financial Street,Xicheng District,
descr:          Beijing 100140 ,P.R.China
country:        CN
admin-c:        YW6851-AP
tech-c:         YW6851-AP
abuse-c:        AC1601-AP
status:         ALLOCATED PORTABLE
mnt-by:         MAINT-CNNIC-AP
mnt-lower:      MAINT-CNNIC-AP
mnt-routes:     MAINT-CNCGROUP-RR
mnt-irt:        IRT-CNNIC-CN
last-modified:  2021-06-16T01:29:30Z
source:         APNIC

6. Unicast Address Assignment

Once a site has been allocated a range of unicast IP addresses, typically from its ISP, the site or network administrator must determine how to assign addresses in the address range to each network interface and how to set up the subnet structure.

6.1. Single Provider/No Network/Single Address

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.

Linux% ifconfig ppp0 # ip a
ppp0 Link encap:Point-to-Point Protocol
inet addr:71.141.244.213
P-t-P:71.141.255.254 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:33134 errors:0 dropped:0 overruns:0 frame:0
TX packets:41031 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:17748984 (16.9 MiB) TX bytes:9272209 (8.8 MiB)
$ netstat -ng # ip maddr
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.251
lo              1      224.0.0.1
ppp0            1      224.0.0.251
ppp0            1      224.0.0.1
lo              1      ff02::fb
lo              1      ff02::1
lo              1      ff01::1
ppp0            1      ff02::fb
ppp0            1      ff02::1
ppp0            1      ff01::1
Table 15. A user’s computer connects to the Internet over DSL assigned as the end of a point-to-point link.
Device Address Meaning

lo

127.0.0.1

IPv4 loopback address

lo

::1

IPv6 loopback address

ppp0/lo

224.0.0.1

All Hosts multicast address

ppp0/lo

224.0.0.251

IPv4 mDNS (multicast DNS) service

ppp0/lo

ff01::1

All Nodes IPv6 multicast address (Node)

ppp0/lo

ff02::1

All Nodes IPv6 multicast address (Link)

ppp0/lo

ff02::fb

IPv6 mDNSv6 (multicast DNS) service

ppp0

71.141.244.213

IPv4 address assigned to the computer that connected to the Internet over DSL

6.2. Single Provider/Single Network/Single Address

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.

6.3. Single Provider/Multiple Networks/Multiple Addresses

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.

A typical small to medium-size enterprise network
Figure 9. A typical small to medium-size enterprise network. The site has been allocated 64 public (routable) IPv4 addresses in the range 128.32.2.64/26. A DMZ network holds servers that are visible to the Internet. The internal router provides Internet access for computers internal to the enterprise using NAT.

6.4. Multiple Providers/Multiple Networks/Multiple Addresses (Multihoming)

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.

Provider-aggregatable and provider-independent IPv4 addresses used in a hypothetical multihomed enterprise
Figure 10. Provider-aggregatable and provider-independent IPv4 addresses used in a hypothetical multihomed enterprise. Site operators tend to prefer using PI space if it is available. ISPs prefer PA space because it promotes prefix aggregation and reduces routing table size.

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].

7. References

  1. Fall, Kevin R._ Stevens, W. Richard_ Wright, Gary R - TCP_IP Illustrated, Volume 1_ The Protocols (2012, Addison-Wesley, Pearson)