View source for Classless Inter-Domain Routing

{{Short description|Method for IP address allocation and routing}}
{{Redirect|CIDR}}
{{Copy edit |reason=direct links to RFCs (using {{tl|IETF RFC}} that its documentation says is not for that usage) rather than correctly citing these RFCs |date=August 2025}}
{{Use American English |date=August 2025}}
{{Use mdy dates |date=August 2025}}
'''Classless Inter-Domain Routing''' ('''CIDR''' {{IPAc-en|ˈ|s|aɪ|d|ər|,_|ˈ|s|ɪ|-}}) is a method for allocating [[IP address]]es for [[IP routing]]. The [[Internet Engineering Task Force]] introduced CIDR in 1993 to replace the previous [[classful network]] addressing architecture on the [[Internet]]. Its goal was to slow the growth of [[routing table]]s on [[router (computing)|routers]] across the Internet, and to help slow the rapid [[IPv4 address exhaustion|exhaustion of IPv4 addresses]].<ref name="RFC 1518">{{cite IETF |rfc=1518 |title=An Architecture for IP Address Allocation with CIDR |author1=Y. Rekhter |author2=T. Li |date=September 1993}}</ref><ref name="RFC 1519">{{cite IETF |rfc=1519 |title=Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy |author1=V. Fuller |author2=T. Li |author3=J. Yu |author4=K. Varadhan |date=September 1993}}</ref>

IP addresses are described as consisting of two groups of [[bit]]s in the address: the [[most significant bit]]s are the [[network prefix]], which identifies a whole network or [[subnet]], and the [[least significant bit|least significant]] set forms the ''host identifier'', which specifies a particular interface of a host on that network. This division is used as the basis of traffic routing between IP networks and for address allocation policies.

Whereas classful network design for [[IPv4]] sized the network prefix as one or more eight-bit groups, resulting in the blocks of Class A, B, or C addresses, under CIDR address space is allocated to [[Internet service provider]]s and [[end user]]s on any address-bit boundary. In [[IPv6]], however, the interface identifier has a fixed size of 64 bits by convention, and smaller subnets are never allocated to end users.

{{Anchor|VLSM}}CIDR is based on '''variable-length subnet masking''' ('''VLSM'''), in which network prefixes have variable length (as opposed to the fixed-length prefixing of the previous classful network design). The main benefit of this is that it grants finer control of the sizes of subnets allocated to organizations, hence slowing the exhaustion of IPv4 addresses from allocating larger subnets than needed. CIDR gave rise to a new way of writing IP addresses known as CIDR notation, in which an IP address is followed by a suffix indicating the number of bits of the prefix. Some examples of CIDR notation are the addresses {{IPaddr|192.0.2.0|24}} for IPv4 and {{IPaddr|2001:db8::|32}} for IPv6. Blocks of addresses having contiguous prefixes may be aggregated as [[supernet]]s, reducing the number of entries in the global routing table.

==Background==
Each IP address consists of a network prefix followed by a [[host (network)|host]] identifier. In the [[classful network]] architecture of [[IPv4]], the three most significant bits of the 32-bit IP address defined the size of the network prefix for [[unicast]] networking, and determined the network class A, B, or C.<ref name=rfc943>{{cite IETF |rfc=943 |title=Assigned Numbers |editor1=J. Reynolds |editor2=J. Postel |date=April 1985}}</ref>

{{Table alignment}}
{| class="wikitable col3right col4right col5right"
!Class
!Most-significant bits
!Network prefix length<br>(bits)
!Host identifier length<br>(bits)
!Address range
|-
|A
|0
|8
|24
|0.0.0.0–127.255.255.255
|-
|B
|10
|16
|16
|128.0.0.0–191.255.255.255
|-
|C
|110
|24
|8
|192.0.0.0–223.255.255.255
|-
|D<sup>(multicast)</sup>
|1110
|{{n/a}}
|{{n/a}}
|224.0.0.0–239.255.255.255
|-
|E<sup>(reserved)</sup>
|1111
|{{n/a}}
|{{n/a}}
| 240.0.0.0–255.255.255.255
|}

The advantage of this system is that the network prefix could be determined for any IP address without any further information. The disadvantage is that networks were usually too big or too small for most organizations to use, because only three sizes were available. The smallest allocation and routing block contained 2<sup>8</sup> = 256 addresses, larger than necessary for personal or department networks, but too small for most enterprises. The next larger block contained 2<sup>16</sup> = {{gaps|65|536}} addresses, too large to be used efficiently even by large organizations. But for network users who needed more than {{gaps|65|536}} addresses, the only other size (2<sup>24</sup>) provided far too many, more than 16 million. This led to inefficiencies in address use as well as inefficiencies in routing, because it required a large number of allocated class-C networks with individual route announcements, being geographically dispersed with little opportunity for [[route aggregation]].

Within a decade after the invention of the [[Domain Name System]] (DNS), the classful network method was found not [[scalable]].<ref name="RFC 1517">{{cite IETF |rfc=1517 |title=Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) |editor=R. Hinden |date=September 1993}}</ref> This led to the development of [[subnet]]ting and CIDR. The formerly meaningful class distinctions based on the most-significant address bits were abandoned and the new system was described as "classless", in contrast to the old system, which became known as "classful". Routing protocols were revised to carry not just IP addresses, but also their subnet masks. Implementing CIDR required every host and router on the Internet to be reprogrammed in small ways—no small feat at a time when the Internet was entering a period of rapid growth. In 1993, the [[Internet Engineering Task Force]] published a new set of standards, {{IETF RFC|1518}} and {{IETF RFC|1519}}, to define this new principle for allocating IP address blocks and routing IPv4 packets. An updated version, {{IETF RFC|4632}}, was published in 2006.<ref name="RFC 4632">{{cite IETF |rfc=4632 |title=Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan |author1=V. Fuller |author2=T. Li |date=August 2006}}</ref>

After a period of experimentation with various alternatives, Classless Inter-Domain Routing was based on variable-length subnet masking (VLSM), which allows each network to be divided into subnetworks of various power-of-two sizes, so that each subnetwork can be sized appropriately for local needs. Variable-length subnet masks were mentioned as one alternative in {{IETF RFC|950}}.<ref name="RFC 950 2.1">{{cite IETF |rfc=950 |title=Internet Standard Subnetting Procedure |editor1=J. Mogul |editor2=J. Postel |date=August 1985 |section=2.1}}</ref> Techniques for grouping addresses for common operations were based on the concept of cluster addressing, first proposed by Carl-Herbert Rokitansky.<ref>Carl-Herbert Rokitansky, "Internet Cluster Addressing Scheme and its Application to Public Data Networks", Proc. 9th International Conference on Computer Communication (ICCC' 88), pp. 482–491, Tel Aviv, Israel, October/November 1988</ref><ref>[http://www.ietf.org/mail-archive/web/ietf/current/msg24136.html Cluster Addressing and CIDR] in the mail archives of the IETF</ref>

{{anchor|notation}}

==CIDR notation==
CIDR notation is a compact representation of an IP address and its associated network mask. The notation was invented by [[Phil Karn]] in the 1980s.<ref name=kantor>{{cite web |title=Re: Stupid Question maybe? |url=https://seclists.org/nanog/2018/Dec/334 |publisher=North American Network Operators Group |author=Brian Kantor |date=December 2018 |quote=/24 is certainly cleaner than 255.255.255.0. I seem to remember it was Phil Karn who in the early 80's suggested that expressing subnet masks as the number of bits from the top end of the address word was efficient, since subnet masks were always a series of ones followd by zeros with no interspersing, which was incorporated (or independently invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519.}}</ref><ref name=simpson>{{cite web |title=Re: Stupid Question maybe? |url=https://seclists.org/nanog/2018/Dec/368 |publisher=North American Network Operators Group |author=William Simpson |date=December 2018 |quote=Actually, Brian is correct. Phil was w-a-y ahead of the times. But I don't remember him talking about it until the late '80s.}}</ref> CIDR notation specifies an IP address, a [[slash (punctuation)|slash]] character ⟨/⟩, and a decimal number. The decimal number is the count of consecutive leading ''1'' bits (from left to right) in the network mask. Each ''1'' bit denotes a bit of the address range which must remain identical to the given IP address. The IP address in CIDR notation is always represented according to the standards for IPv4 or IPv6.

The address may denote a specific interface address (including a host identifier, such as {{IPaddr|10.0.0.1|8}}), or it may be the beginning address of an entire network (using a host identifier of 0, as in {{IPaddr|10.0.0.0|8}} or its equivalent {{IPaddr|10|8}}). CIDR notation can even be used with no IP address at all, e.g. when referring to a {{IPaddr||24}} as a generic description of an IPv4 network that has a 24-bit prefix and 8-bit host numbers.

For example:
* {{IPaddr|198.51.100.14|24}} represents the IPv4 address {{IPaddr|198.51.100.14}} and its associated network prefix {{IPaddr|198.51.100.0}}, or equivalently, its subnet mask {{IPaddr||24|netmask=dotted}}, which has 24 leading ''1'' bits.
* the IPv4 block {{IPaddr|198.51.100.0|22}} represents the 1024 IPv4 addresses from {{IPaddr|198.51.100.0}} to {{IPaddr|198.51.103.255}}.
* the IPv6 block {{IPaddr|2001:db8::|48}} represents the block of IPv6 addresses from {{IPaddr|2001:db8:0:0:0:0:0:0}} to {{IPaddr|2001:db8:0:ffff:ffff:ffff:ffff:ffff}}.
* {{IPaddr|::1|128}} represents the IPv6 [[loopback]] address. Its prefix length is 128 which is the number of bits in the address.

In IPv4, CIDR notation came into wide use only after the implementation of the method, which was documented using [[dotted-decimal]] subnet mask specification after the slash, for example, {{IPaddr|192.24.12.0|22|netmask=dotted}}.<ref name="RFC 1519" /> Describing the network prefix width as a single number ({{IPaddr|192.24.12.0|22}}) was easier for network administrators to conceptualize and to calculate. It became gradually incorporated into later standards documents<ref>{{cite ietf |rfc=1878 |title=Variable Length Subnet Table For IPv4 |author1=T. Pummill |author2=B. Manning |date=December 1995}}</ref><ref>{{cite ietf |rfc=2167 |title=Referral Whois (RWhois) Protocol V1.5 |author1=S. Williamson |author2=M. Kosters |author3=D. Blacka |author4=J. Singh |author5=K. Zeilstra |date=June 1997 |quote=IP networks are also lexically hierarchical labels using the Classless Inter-Domain Routing (CIDR) notation, but their hierarchy is not easily determined with simple text manipulation; for example, 198.41.0.0/22 is a part of 198.41.0.0/16, which is a part of 198.40.0.0/15.}}</ref> and into network configuration interfaces.

The number of addresses of a network may be calculated as 2<sup>address length − prefix length</sup>, where "address length" is 128 for IPv6 and 32 for IPv4. For example, in IPv4, the prefix length {{IPaddr||29}} gives: 2<sup>32−29</sup> = 2<sup>3</sup> = 8 addresses.

==Subnet masks==
A subnet mask is a [[bitmask]] that encodes the prefix length associated with an IPv4 address or network in quad-dotted notation: 32 bits, starting with a number of ones equal to the prefix length, ending with zeros, and encoded in four-part dotted-decimal format: {{IPaddr||24|netmask=dotted}}. A subnet mask encodes the same information as a prefix length but predates the advent of CIDR. In CIDR notation, the prefix bits are always contiguous. Subnet masks were allowed by {{IETF RFC|950}}<ref name="RFC 950 2.1"/> to specify non-contiguous bits until {{IETF RFC|4632}}<ref name="RFC 4632"/>{{rp|at=Section 5.1}} stated that the mask must consist of only contiguous ones, if any, in the more significant bits and contiguous zeroes, if any, in the less significant bits. Given this constraint, a subnet mask and CIDR notation serve exactly the same function.

==CIDR blocks==
CIDR is principally a bitwise, prefix-based standard for the representation of IP addresses and their routing properties. It facilitates routing by allowing blocks of addresses to be grouped into single routing table entries. These groups, commonly called CIDR blocks, share an initial sequence of bits in the binary representation of their IP addresses. IPv4 CIDR blocks are identified using a syntax similar to that of IPv4 addresses: a dotted-decimal address, followed by a slash, then a number from 0 to 32, i.e., {{IPaddr|a.b.c.d|n}}. The dotted-decimal portion is the IPv4 address. The number following the slash is the prefix length, the number of shared initial bits, counting from the most-significant bit of the address. When emphasizing only the size of a network, the address portion of the notation is usually omitted. Thus, a /20 block is a CIDR block with an unspecified 20-bit prefix.

An IP address is part of a CIDR block and is said to match the CIDR prefix if the initial n bits of the address and the CIDR prefix are the same. An IPv4 address is 32 bits so an n-bit CIDR prefix leaves 32−n bits unmatched, meaning that 2<sup>32−n</sup> IPv4 addresses match a given n-bit CIDR prefix. Shorter CIDR prefixes match more addresses, while longer prefixes match fewer. In the case of overlaid CIDR blocks, an address can match multiple CIDR prefixes of different lengths.

CIDR is also used for [[IPv6 address]]es and the syntax semantic is identical. The prefix length can range from 0 to 128, due to the larger number of bits in the address. However, by convention, a subnet on broadcast MAC layer networks always has 64-bit host identifiers.<ref>{{Cite IETF |rfc=7136|last=Carpenter |first=B. |last2=Jiang |first2=S. |date=February 2014 |title=Significance of IPv6 Interface Identifiers |language=en |doi-access=free }}</ref> Larger prefixes (/127) are only used on some point-to-point links between routers, for security and policy reasons.<ref>{{Cite IETF |rfc=6164 |last=Kohno |first=M. |last2=Nitzan |first2=B. |last3=Bush |first3=R. |last4=Matsuzaki |first4=Y. |last5=Colitti |first5=L. |last6=Narten |first6=T. |date=April 2011 |title=Using 127-Bit IPv6 Prefixes on Inter-Router Links |language=en}}</ref>[[File:IP Address Match.svg|400px|right]]

===Assignment of CIDR blocks===
The [[Internet Assigned Numbers Authority]] (IANA) issues to [[regional Internet registries]] (RIRs) large, short-prefix CIDR blocks. However, a {{IPaddr||8}} (with over sixteen million addresses) is the largest block IANA will allocate. For example, {{IPaddr|62.0.0.0|8}} is administered by [[RIPE NCC]], the European RIR. The RIRs, each responsible for a single, large, geographic area, such as Europe or North America, subdivide these blocks and allocate subnets to local Internet registries (LIRs). Similar subdividing may be repeated several times at lower levels of delegation. End-user networks receive subnets sized according to their projected short-term need. Networks served by a single ISP are encouraged by [[IETF]] recommendations to obtain IP address space directly from their ISP. Networks served by multiple ISPs, on the other hand, may obtain [[provider-independent address space]] directly from the appropriate RIR.

[[File:CIDR Address.svg|right|400px]]
For example, in the late 1990s, the IP address {{IPaddr|208.130.29.33}} (since reassigned) was used by www.freesoft.org. An analysis of this address identified three CIDR prefixes. {{IPaddr|208.128.0.0|11}}, a large CIDR block containing over 2 million addresses, had been assigned by [[ARIN]] (the North American RIR) to [[MCI Communications|MCI]]. Automation Research Systems (ARS), a Virginia [[Value-added reseller|VAR]], leased an Internet connection from MCI and was assigned the {{IPaddr|208.130.28.0|22}} block, capable of addressing just over 1000 devices. ARS used a {{IPaddr||24}} block for its publicly accessible servers, of which {{IPaddr|208.130.29.33}} was one. All of these CIDR prefixes would be used, at different locations in the network. Outside MCI's network, the {{IPaddr|208.128.0.0|11}} prefix would be used to direct to MCI traffic bound not only for {{IPaddr|208.130.29.33}}, but also for any of the roughly two million IP addresses with the same initial 11 bits. Within MCI's network, {{IPaddr|208.130.28.0|22}} would become visible, directing traffic to the [[leased line]] serving ARS. Only within the ARS corporate network would the {{IPaddr|208.130.29.0|24}} prefix have been used.

===IPv4 CIDR blocks===
{| class="wikitable"
! rowspan = 2 | Address<br />format
! rowspan = 2 | Difference<br />to last address
! rowspan = 2 | Mask
! colspan = 2 | Addresses
! rowspan = 2 | Relative<br />to class<br />A, B, C
! rowspan = 2 | Restrictions<br />on ''a'', ''b'', ''c'' and ''d''<br /><small>(0..255 unless noted)</small>
! rowspan = 2 | Typical use
|-
! Decimal
!2<sup>''n''</sup>
|-
|{{IPaddr|a.b.c.d|32}}
| 
|{{IPaddr|255.255.255.255|}}
| style="text-align:right;" |1
| style="text-align:right;" |2<sup>0</sup>
| style="text-align:right;" |{{frac|1|256}} C
|
| Host route
|-
|{{IPaddr|a.b.c.d|31}}
| +{{IPaddr|0.0.0.1|}}
|{{IPaddr|255.255.255.254|}}
| style="text-align:right;" |2
| style="text-align:right;" |2<sup>1</sup>
| style="text-align:right;" |{{frac|1|128}} C
|''d'' = 0 ... (2''n'') ... 254
| Point-to-point links ({{IETF RFC|3021}})
|-
|{{IPaddr|a.b.c.d|30}}
| +{{IPaddr|0.0.0.3|}}
|{{IPaddr|255.255.255.252|}}
| style="text-align:right;" |4
| style="text-align:right;" |2<sup>2</sup>
| style="text-align:right;" |{{frac|1|64}} C
|''d'' = 0 ... (4''n'') ... 252
| {{nowrap|Point-to-point links (glue network)}}
|-
|{{IPaddr|a.b.c.d|29}}
| +{{IPaddr|0.0.0.7|}}
|{{IPaddr|255.255.255.248|}}
| style="text-align:right;" |8
| style="text-align:right;" |2<sup>3</sup>
| style="text-align:right;" |{{frac|1|32}} C
|''d'' = 0 ... (8''n'') ... 248
| Smallest multi-host network
|-
|{{IPaddr|a.b.c.d|28}}
| +{{IPaddr|0.0.0.15|}}
|{{IPaddr|255.255.255.240|}}
| style="text-align:right;" |16
| style="text-align:right;" |2<sup>4</sup>
| style="text-align:right;" |{{frac|1|16}} C
|''d'' = 0 ... (16''n'') ... 240
| rowspan=3 | Small [[LAN]]
|-
|{{IPaddr|a.b.c.d|27}}
| +{{IPaddr|0.0.0.31|}}
|{{IPaddr|255.255.255.224|}}
| style="text-align:right;" |32
| style="text-align:right;" |2<sup>5</sup>
| style="text-align:right;" |{{frac|1|8}} C
|''d'' = 0 ... (32''n'') ... 224
|-
|{{IPaddr|a.b.c.d|26}}
| +{{IPaddr|0.0.0.63|}}
|{{IPaddr|255.255.255.192|}}
| style="text-align:right;" |64
| style="text-align:right;" |2<sup>6</sup>
| style="text-align:right;" |{{frac|1|4}} C
|''d'' = 0, 64, 128, 192
|-
|{{IPaddr|a.b.c.d|25}}
| +{{IPaddr|0.0.0.127|}}
|{{IPaddr|255.255.255.128|}}
| style="text-align:right;" |128
| style="text-align:right;" |2<sup>7</sup>
| style="text-align:right;" |{{frac|1|2}} C
|''d'' = 0, 128
| rowspan=2 | Large [[LAN]]
|-
|{{IPaddr|a.b.c.0|24}}
| +{{IPaddr|0.0.0.255|}}
|{{IPaddr|255.255.255.0|}}
| style="text-align:right;" |256
| style="text-align:right;" |2<sup>8</sup>
| style="text-align:right;" |1 C
|
|-
|{{IPaddr|a.b.c.0|23}}
| +{{IPaddr|0.0.1.255|}}
|{{IPaddr|255.255.254.0|}}
| style="text-align:right;" |512
| style="text-align:right;" |2<sup>9</sup>
| style="text-align:right;" |2 C
|''c'' = 0 ... (2''n'') ... 254
|
|-
|{{IPaddr|a.b.c.0|22}}
| +{{IPaddr|0.0.3.255|}}
|{{IPaddr|255.255.252.0|}}
| style="text-align:right;" |1,024
| style="text-align:right;" |2<sup>10</sup>
| style="text-align:right;" |4 C
|''c'' = 0 ... (4''n'') ... 252
|Small business
|-
|{{IPaddr|a.b.c.0|21}}
| +{{IPaddr|0.0.7.255|}}
|{{IPaddr|255.255.248.0|}}
| style="text-align:right;" |2,048
| style="text-align:right;" |2<sup>11</sup>
| style="text-align:right;" |8 C
|''c'' = 0 ... (8''n'') ... 248
| rowspan=2 | Small [[ISP]]/ large business
|-
|{{IPaddr|a.b.c.0|20}}
| +{{IPaddr|0.0.15.255|}}
|{{IPaddr|255.255.240.0|}}
| style="text-align:right;" |4,096
| style="text-align:right;" |2<sup>12</sup>
| style="text-align:right;" |16 C
|''c'' = 0 ... (16''n'') ... 240
|-
|{{IPaddr|a.b.c.0|19}}
| +{{IPaddr|0.0.31.255|}}
|{{IPaddr|255.255.224.0|}}
| style="text-align:right;" |8,192
| style="text-align:right;" |2<sup>13</sup>
| style="text-align:right;" |32 C
|''c'' = 0 ... (32''n'') ... 224
| rowspan=3 | [[ISP]]/ large business
|-
|{{IPaddr|a.b.c.0|18}}
| +{{IPaddr|0.0.63.255|}}
|{{IPaddr|255.255.192.0|}}
| style="text-align:right;" |16,384
| style="text-align:right;" |2<sup>14</sup>
| style="text-align:right;" |64 C
|''c'' = 0, 64, 128, 192
|-
|{{IPaddr|a.b.c.0|17}}
| +{{IPaddr|0.0.127.255|}}
|{{IPaddr|255.255.128.0|}}
| style="text-align:right;" |32,768
| style="text-align:right;" |2<sup>15</sup>
| style="text-align:right;" |128 C
|''c'' = 0, 128
|-
|{{IPaddr|a.b.0.0|16}}
| +{{IPaddr|0.0.255.255|}}
|{{IPaddr|255.255.0.0|}}
| style="text-align:right;" |65,536
| style="text-align:right;" |2<sup>16</sup>
| style="text-align:right;" |256 C = B
|
|
|-
|{{IPaddr|a.b.0.0|15}}
| +{{IPaddr|0.1.255.255|}}
|{{IPaddr|255.254.0.0|}}
| style="text-align:right;" |131,072
| style="text-align:right;" |2<sup>17</sup>
| style="text-align:right;" |2 B
|''b'' = 0 ... (2''n'') ... 254
|
|-
|{{IPaddr|a.b.0.0|14}}
| +{{IPaddr|0.3.255.255|}}
|{{IPaddr|255.252.0.0|}}
| style="text-align:right;" |262,144
| style="text-align:right;" |2<sup>18</sup>
| style="text-align:right;" |4 B
|''b'' = 0 ... (4''n'') ... 252
|
|-
|{{IPaddr|a.b.0.0|13}}
| +{{IPaddr|0.7.255.255|}}
|{{IPaddr|255.248.0.0|}}
| style="text-align:right;" |524,288
| style="text-align:right;" |2<sup>19</sup>
| style="text-align:right;" |8 B
|''b'' = 0 ... (8''n'') ... 248
|
|-
|{{IPaddr|a.b.0.0|12}}
| +{{IPaddr|0.15.255.255|}}
|{{IPaddr|255.240.0.0|}}
| style="text-align:right;" |1,048,576
| style="text-align:right;" |2<sup>20</sup>
| style="text-align:right;" |16 B
|''b'' = 0 ... (16''n'') ... 240
|
|-
|{{IPaddr|a.b.0.0|11}}
| +{{IPaddr|0.31.255.255|}}
|{{IPaddr|255.224.0.0|}}
| style="text-align:right;" |2,097,152
| style="text-align:right;" |2<sup>21</sup>
| style="text-align:right;" |32 B
|''b'' = 0 ... (32''n'') ... 224
|
|-
|{{IPaddr|a.b.0.0|10}}
| +{{IPaddr|0.63.255.255|}}
|{{IPaddr|255.192.0.0|}}
| style="text-align:right;" |4,194,304
| style="text-align:right;" |2<sup>22</sup>
| style="text-align:right;" |64 B
|''b'' = 0, 64, 128, 192
|
|-
|{{IPaddr|a.b.0.0|9}}
| +{{IPaddr|0.127.255.255|}}
|{{IPaddr|255.128.0.0|}}
| style="text-align:right;" |8,388,608
| style="text-align:right;" |2<sup>23</sup>
| style="text-align:right;" |128 B
|''b'' = 0, 128
|
|-
|{{IPaddr|a.0.0.0|8}}
| +{{IPaddr|0.255.255.255|}}
|{{IPaddr|255.0.0.0|}}
| style="text-align:right;" |16,777,216
| style="text-align:right;" |2<sup>24</sup>
| style="text-align:right;" |256 B = A
|
| Largest [[IANA]] block allocation
|-
|{{IPaddr|a.0.0.0|7}}
| +{{IPaddr|1.255.255.255|}}
|{{IPaddr|254.0.0.0|}}
| style="text-align:right;" |33,554,432
| style="text-align:right;" |2<sup>25</sup>
| style="text-align:right;" |2 A
|''a'' = 0 ... (2''n'') ... 254
|
|-
|{{IPaddr|a.0.0.0|6}}
| +{{IPaddr|3.255.255.255|}}
|{{IPaddr|252.0.0.0|}}
| style="text-align:right;" |67,108,864
| style="text-align:right;" |2<sup>26</sup>
| style="text-align:right;" |4 A
|''a'' = 0 ... (4''n'') ... 252
|
|-
|{{IPaddr|a.0.0.0|5}}
| +{{IPaddr|7.255.255.255|}}
|{{IPaddr|248.0.0.0|}}
| style="text-align:right;" |134,217,728
| style="text-align:right;" |2<sup>27</sup>
| style="text-align:right;" |8 A
|''a'' = 0 ... (8''n'') ... 248
|
|-
|{{IPaddr|a.0.0.0|4}}
| +{{IPaddr|15.255.255.255|}}
|{{IPaddr|240.0.0.0|}}
| style="text-align:right;" |268,435,456
| style="text-align:right;" |2<sup>28</sup>
| style="text-align:right;" |16 A
|''a'' = 0 ... (16''n'') ... 240
|
|-
|{{IPaddr|a.0.0.0|3}}
| +{{IPaddr|31.255.255.255|}}
|{{IPaddr|224.0.0.0|}}
| style="text-align:right;" |536,870,912
| style="text-align:right;" |2<sup>29</sup>
| style="text-align:right;" |32 A
|''a'' = 0 ... (32''n'') ... 224
|
|-
|{{IPaddr|a.0.0.0|2}}
| +{{IPaddr|63.255.255.255|}}
|{{IPaddr|192.0.0.0|}}
| style="text-align:right;" |1,073,741,824
| style="text-align:right;" |2<sup>30</sup>
| style="text-align:right;" |64 A
|''a'' = 0, 64, 128, 192
|
|-
|{{IPaddr|a.0.0.0|1}}
| +{{IPaddr|127.255.255.255|}}
|{{IPaddr|128.0.0.0|}}
| style="text-align:right;" |2,147,483,648
| style="text-align:right;" |2<sup>31</sup>
| style="text-align:right;" |128 A
|''a'' = 0, 128
|
|-
|{{IPaddr|0.0.0.0|0}}
| +{{IPaddr|255.255.255.255|}}
|{{IPaddr|0.0.0.0|}}
| style="text-align:right;" |4,294,967,296
| style="text-align:right;" |2<sup>32</sup>
| style="text-align:right;" |256 A
|
| Entire IPv4 Internet, [[default route]]
|}

In routed subnets larger than {{IPaddr||31}} or {{IPaddr||32}}, the number of available host addresses is usually reduced by two, namely the largest address, which is reserved as the [[broadcast address]], and the smallest address, which identifies the network itself<ref name="RFC 922">{{cite IETF |rfc=922 |title=Broadcasting Internet Datagrams in the Presence of Subnets |editor=J. Mogul |date=October 1984 |section=7}}</ref> and is reserved solely for this purpose.<ref name="RFC 1812">{{cite IETF |rfc=1812 |title=Requirements for IP Version 4 Routers |editor=F. Baker |date=June 1995 |section=4.2.3.1}}</ref>

In such usage, a {{IPaddr||31}} network, with one binary digit in the host identifier, is unusable, as such a subnet would provide no available host addresses after this reduction. {{IETF RFC|3021}} creates an exception to the "host all ones" and "host all zeros" rules to make {{IPaddr||31}} networks usable for point-to-point links. {{IPaddr||32}} addresses (single-host network) must be accessed by explicit routing rules, as there is no address available for a gateway.

===IPv6 CIDR blocks===
{| class="wikitable" style="text-align: center; margin-left: auto; margin-right: auto; border: none;"
|+ IPv6 CIDR prefixes
|-
! rowspan="2" | Prefix size !! colspan="3" | Number of equivalent subnets !! rowspan="2" | Interface ID bits
|-
! /48 !! /56 !! /64 
|-
| /24 || 16M || 4G || 1T || 104
|-
| /25 || 8M || 2G || 512G || 103
|-
| /26 || 4M || 1G || 256G || 102
|-
| /27 || 2M || 512M || 128G || 101
|-
| /28 || 1M || 256M || 64G || 100
|-
| /29 || 512K || 128M || 32G || 99
|-
| /30 || 256K || 64M || 16G || 98
|-
| /31 || 128K || 32M || 8G || 97
|-
| /32 || 64K || 16M || 4G || 96
|-
| /33 || 32K || 8M || 2G || 95
|-
| /34 || 16K || 4M || 1G || 94
|-
| /35 || 8K || 2M || 512M || 93
|-
| /36 || 4K || 1M || 256M || 92
|-
| /37 || 2K || 512K || 128M || 91
|-
| /38 || 1K || 256K || 64M || 90
|-
| /39 || 512 || 128K || 32M || 89
|-
| /40 || 256 || 64K || 16M || 88
|-
| /41 || 128 || 32K || 8M || 87
|-
| /42 || 64 || 16K || 4M || 86
|-
| /43 || 32 || 8K || 2M || 85
|-
| /44 || 16 || 4K || 1M || 84
|-
| /45 || 8 || 2K || 512K || 83
|-
| /46 || 4 || 1K || 256K || 82
|-
| /47 || 2 || 512 || 128K || 81
|-
| /48 || 1 || 256 || 64K || 80
|-
| /49 ||  || 128 || 32K || 79
|-
| /50 ||  || 64 || 16K || 78
|-
| /51 ||  || 32 || 8K || 77
|-
| /52 ||  || 16 || 4K || 76
|-
| /53 ||  || 8 || 2K || 75
|-
| /54 ||  || 4 || 1K || 74
|-
| /55 ||  || 2 || 512 || 73
|-
| /56 ||  || 1 || 256 || 72
|-
| /57 ||  ||  || 128 || 71
|-
| /58 ||  ||  || 64 || 70
|-
| /59 ||  ||  || 32 || 69
|-
| /60 ||  ||  || 16 || 68
|-
| /61 ||  ||  || 8 || 67
|-
| /62 ||  ||  || 4 || 66
|-
| /63 ||  ||  || 2 || 65
|-
| /64 ||  ||  || 1 || 64
|-
| colspan="5" | '''K''' = 1,024 
|-
| colspan="5" | '''M''' = 1,048,576
|-
| colspan="5" | '''G''' = 1,073,741,824
|-
| colspan="5" | '''T''' = 1,099,511,627,776
|}
The large address size of IPv6 permitted worldwide route summarization and guaranteed sufficient address pools at each site. The standard subnet size for IPv6 networks is a {{IPaddr||64}} block, which is required for the operation of [[IPv6 stateless address autoconfiguration|stateless address autoconfiguration]].<ref name="RFC 4862">{{IETF RFC|4862}}</ref> At first, the IETF recommended in {{IETF RFC|3177}} as a best practice that all end sites receive {{IPaddr||48}} address allocations,<ref name="RFC 3177">{{cite IETF |rfc=3177 |title=IAB/IESG Recommendation on IPv6 Address Allocations to Sites |publisher=IAB/IESG |date=September 2001}}</ref> but criticism and reevaluation of actual needs and practices has led to more flexible allocation recommendations in {{IETF RFC|6177}}<ref name="RFC 6177">{{cite IETF |rfc=6177 |title=IPv6 Address Assignment to End Sites |author=T. Narten |author2=G. Huston |author3=L. Roberts |date=March 2011}}</ref> suggesting a significantly smaller allocation for some sites, such as a {{IPaddr||56}} block for residential networks.

This IPv6 subnetting reference lists the sizes for IPv6 [[subnetwork]]s. Different types of network links may require different subnet sizes.<ref>{{cite web|url=http://www.getipv6.info/index.php/IPv6_Addressing_Plans |title=ARIN IPv6 Addressing Plans |publisher=Getipv6.info |date=2016-03-25 |access-date=2018-03-12}}</ref> The subnet mask separates the bits of the network identifier prefix from the bits of the interface identifier. Selecting a smaller prefix size results in fewer number of networks covered, but with more addresses within each network.<ref>{{cite web |url=https://www.ripe.net/info/info-services/addressing.html |title=RIPE IP Allocation Rates |archive-url=https://web.archive.org/web/20110203130851/http://ripe.net/info/info-services/addressing.html |archive-date=2011-02-03}}</ref>

 2001:0db8:0123:4567:89ab:cdef:1234:5678
 |||| |||| |||| |||| |||| |||| |||| ||||
 |||| |||| |||| |||| |||| |||| |||| |||128     Single end-points and [[loopback]]
 |||| |||| |||| |||| |||| |||| |||| |||127   Point-to-point links (inter-router)
 |||| |||| |||| |||| |||| |||| |||| ||124
 |||| |||| |||| |||| |||| |||| |||| |120
 |||| |||| |||| |||| |||| |||| |||| 116
 |||| |||| |||| |||| |||| |||| |||112
 |||| |||| |||| |||| |||| |||| ||108
 |||| |||| |||| |||| |||| |||| |104
 |||| |||| |||| |||| |||| |||| 100
 |||| |||| |||| |||| |||| |||96
 |||| |||| |||| |||| |||| ||92
 |||| |||| |||| |||| |||| |88
 |||| |||| |||| |||| |||| 84
 |||| |||| |||| |||| |||80
 |||| |||| |||| |||| ||76
 |||| |||| |||| |||| |72
 |||| |||| |||| |||| 68
 |||| |||| |||| |||64   Single LAN; default prefix size for [[IPv6#Stateless_address_autoconfiguration_(SLAAC)|SLAAC]]
 |||| |||| |||| ||60   Some (very limited) [[6rd]] deployments (/60 = 16 /64 blocks)
 |||| |||| |||| |56   Minimal end-site assignment;<ref name="RFC 6177"/> e.g. [[home network]] (/56 = 256 /64 blocks)
 |||| |||| |||| 52   /52 block = 4096 /64 blocks
 |||| |||| |||48   Typical assignment for larger sites (/48 = 65536 /64 blocks)
 |||| |||| ||44
 |||| |||| |40
 |||| |||| 36   possible future [[local Internet registry]] (LIR) extra-small allocations
 |||| |||32   LIR minimum allocations
 |||| ||28   LIR medium allocations
 |||| |24   LIR large allocations
 |||| 20   LIR extra large allocations
 |||16
 ||12   [[Regional Internet registry]] (RIR) allocations from IANA<ref>{{cite web|url=https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml |title=IANA IPv6 unicast address assignments |publisher=Iana.org |access-date=2018-03-12}}</ref>
 |8
 4

==Numerical interpretation==
Topologically, the set of subnets described by CIDR represent a [[Cover (topology)|cover]] of the corresponding address space. The interval described by the notation <math>X/n</math> numerically corresponds to addresses of the form <math>[x \cdot 2^{32-n}, x \cdot 2^{32-n} + 2^{32-n} - 1]</math> (for IPv4) and <math>[x \cdot 2^{128n}, x \cdot 2^{128n} + 2^{128-n} - 1]</math> (for IPv6), where <math>X = x \cdot 2^{32-n}</math> and <math>X = x \cdot 2^{128-n}</math> has the lower <math>n</math> bits set to 0. For a fixed <math>n</math>, the set of all <math>X/n</math> subnets constitute a [[Partition of a set|partition]], that is a cover of non-overlapping sets. Increasing <math>n</math> yields finer and finer subpartitions. Thus two subnets <math>X/n</math> and <math>Y/m</math> are either disjoint or one is a subnet of the other.

==Prefix aggregation==
CIDR provides fine-grained [[routing prefix aggregation]]. For example, if the first 20 bits of their network prefixes match, sixteen contiguous {{IPaddr||24}} networks can be aggregated and advertised to a larger network as a single {{IPaddr||20}} [[routing table]] entry. This reduces the number of routes that have to be advertised.

==See also==
* [[Internet protocol suite]]

==References==
{{reflist}}

==Further reading==
* {{Cite IETF |rfc=2317 |title=Classless IN-ADDR.ARPA delegation |date=March 1998}}
* {{Cite IETF |rfc=1817 |title=CIDR and Classful Routing |date=August 1995}}

==External links==
* [https://www.cidr-report.org/as2.0/ CIDR Report] (updated daily)

[[Category:Internet Standards]]
[[Category:Internet architecture]]
[[Category:IP addresses]]
[[Category:Routing]]