This page is about IP Subnetting.
Some people may arrive here looking for a “subnetting chart”. If this is what's being sought, check out the Variable-Length Subnetting Chart and/or other VLSM charts in the section about making subnets.[#ipsbntp3]:
IP Subnetting: Part 3: Details Specific to IPv4 and IPv6
(This is meant as a follow-up of IP Subnetting.)
- IP Subnetting Part 1: What Subnets Are
- IP Subnetting: Part 2: Key Subnet Rules
- IP Subnetting: Part 3: Details Specific to IPv4 and IPv6
- IP Subnetting: Part 4: VLSM and Notations Like CIDR
- IP Subnetting: Part 5: Wrap-Up/Examples
- IP Subnetting: Part 6: Subnetting Patterns: Tips For Speed
- Types of destinations
Two common types of Internet Protocol communications are “unicast” communication and “broadcast” communication.
This is rather similar in concept to one person speaking in a normal-volumed speaking voice to another nearby person. If another person device tries to listen to the conversation, that person might be able to hear the conversion just fine.
“Broadcast” traffic is designed for all devices in a group to be listening to. This is similar to speaking loudly in front of a group, or maybe even using a megaphone.
Update: this may be covered more by network traffic destinations.
(What was just stated is true for both IPv4 and IPv6. Knowing that will be helpful in understanding some of the upcoming details that are more specific to just IPv4 or just IPv6.)
- Further IPv4 and IPv6 details
Each subnet has a “network ID” which looks just like the first address of the subnet.
So far, everything that this text has just explained has been true for both IPv4 and IPv6. (The example addresses are IPv4 addresses, but IPv6 addresses can also be split up into groups.)
- Unusable IPv4
This next note does focus on details that are more specific to IPv4.
For IPv4, the last address on each network block is typically reserved to be a “broadcast address”. This standard was specified in September 1982 by Internet Experimental Note 212: “Internet Protocol - Local Area Networking Addressing Issues (a.k.a. “IEN 212”: “IP - LAN Addressing Issues”). Then, in October 1984, this was documented by RFC 919: Broadcasting Internet Datagrams really solidified this as a standard.
As a result of this standard, the last address is typically considered to be “unusable” for IPv4 traffic which is not broadcast traffic.
Prior to that, some pieces of networking equipment used the first address of each subnet as a “broadcasting” standard. (That may even have been the more common standard.) In order to be able to communicate with such old equipment, a decision was made to reserve the first address of each subnet so that communication with such older equipment could work.
This does seem rather wasteful. Most networks will typically not use any IPv4 broadcast traffic except for using the DHCP/IPv4 protocol. Reserving two addresses for every subnet, just for this feature (which can typically have the same benefits be effectively available, by using the global broadcast address of 255.255.255.255) does seem like a rather high cost for minimal benefit (often no benefit whatsoever).
Having a bunch of IPv4 broadcast addresses is not a design that provides a large number of benefits, although adherence to standards does help with ubiquitous (i.e., widespread) compatibility. When a bunch of (small) subnets are being used, then a bunch of addresses are reserved for standards compliance.
One way to waste less addresses is to use fewer subnets, by using larger subnets. Instead of using eight groups of four addresses, and having 16 out of 32 addresses be reserved for compatiblity, a single block of 32 addresses would only reserve 2 addresses (out of the same group of 32 addresses).
- [#ip6sbnet]: IPv6 subnetting
Modern day IPv6 subnetting is done just like IPv4 subnetting.
A visual example was once helpful in trying to describe that point. So, just as the previous text had a chart showing 32 IPv4 addresses being split, here is a chart showing 32 IPv6 being split.
IPv6 split 32 per group 16 per group 8 per group 4 per group 2001:db8::0 2001:db8::1 2001:db8::2 2001:db8::3 2001:db8::4 2001:db8::5 2001:db8::6 2001:db8::7 2001:db8::8 2001:db8::9 2001:db8::a 2001:db8::b 2001:db8::c 2001:db8::d 2001:db8::e 2001:db8::f 2001:db8::10 2001:db8::11 2001:db8::12 2001:db8::13 2001:db8::14 2001:db8::15 2001:db8::16 2001:db8::17 2001:db8::18 2001:db8::19 2001:db8::1a 2001:db8::1b 2001:db8::1c 2001:db8::1d 2001:db8::1e 2001:db8::1f 2001:db8::0 2001:db8::1 2001:db8::2 2001:db8::3 2001:db8::4 2001:db8::5 2001:db8::6 2001:db8::7 2001:db8::8 2001:db8::9 2001:db8::a 2001:db8::b 2001:db8::c 2001:db8::d 2001:db8::e 2001:db8::f 2001:db8::0 2001:db8::1 2001:db8::2 2001:db8::3 2001:db8::4 2001:db8::5 2001:db8::6 2001:db8::7
2001:db8::8 2001:db8::9 2001:db8::a 2001:db8::b 2001:db8::c 2001:db8::d 2001:db8::e 2001:db8::f 2001:db8::0 2001:db8::1 2001:db8::2 2001:db8::3
2001:db8::4 2001:db8::5 2001:db8::6 2001:db8::7
2001:db8::8 2001:db8::9 2001:db8::a 2001:db8::b
2001:db8::c 2001:db8::d 2001:db8::e 2001:db8::f 2001:db8::10 2001:db8::11 2001:db8::12 2001:db8::13 2001:db8::14 2001:db8::15 2001:db8::16 2001:db8::17 2001:db8::18 2001:db8::19 2001:db8::1a 2001:db8::1b 2001:db8::1c 2001:db8::1d 2001:db8::1e 2001:db8::1f 2001:db8::10 2001:db8::11 2001:db8::12 2001:db8::13 2001:db8::14 2001:db8::15 2001:db8::16 2001:db8::17
2001:db8::18 2001:db8::19 2001:db8::1a 2001:db8::1b 2001:db8::1c 2001:db8::1d 2001:db8::1e 2001:db8::1f 2001:db8::10 2001:db8::11 2001:db8::12 2001:db8::13
2001:db8::14 2001:db8::15 2001:db8::16 2001:db8::17
2001:db8::18 2001:db8::19 2001:db8::1a 2001:db8::1b
2001:db8::1c 2001:db8::1d 2001:db8::1e 2001:db8::31
Note: The VLSM chart provided by ][CyberPillar][ is not meant to be entirely IPv4 specific. The chart also shows network prefixes for IPv6 /120 subnets, and smaller subnets as well. The only difference is that the VLSM chart provided by ][CyberPillar][ shows numbers in decimal (which is more ideal for standard dotted-quad IPv4 notation), but the numbers in the chart (which represent last octet of an IPv4 address) would need to be converted to two hexadecimal digits to represent standard IPv6 notation. Keeping that in mind, the chart is perfectly accurate for IPv6 subnets that are /120 subnets, and smaller subnets (which will have a larger number of “network” bits when using the standard CIDR notation).
- Historical complications
Some people have suggested that IPv6 subnetting is more complicated. Really, it isn't.
Err... umm... that is... the rules for IPv6 subnetting are not more complicated than IPv4 subnetting, anymore. Actually, there used to be more details about IPv6 addresses.
In the original design of IPv6, there were more specific parts of an IPv6 address, RFC 2374 section 3.1: Aggregatable Global Unicast Address Structure had some specific rules related to the first 48 bits of an IPv6 address. (Also documented elsewhere, e.g. MSDN documentation of IPv6 address format.)
However, a lot of those rules went by the wayside by August 2003 when RFC 3587 section 2 officially made those rules “Historic”. That RFC still had the recommendation of having 16 bits be reserved for identifying subnets that were /64 in size. The idea, at the time, was that “end users” would get /48 subnets. However, even having 16-bits as a “subnetting ID” is no longer the official active recommendation, since RFC 6177: IPv6 Address Assignment to End Sites became the updated IETF BCP 157: IPv6 Address Assignment to End Sites.
That newer RFC (6177) went along with the practice of providing /56 subnets to “end users”. (A /56 would provide only 8 bits for subnetting different /64 subnets, which is notably less than the 16 bits that each “end user” received from the /48 subnets that were recommended by IETF RFCs 2374 and 3587.)
So, what this boils down to is this: IPv6 had some extra details and rules compared to IPv4, but some of those results got rescinded before many network professionals bothered to learn those rules. Fortunately, there is very little need for modern network professionals to bother learning those old rules. Unfortunately, those old rules have tainted IPv6 subnetting with a reputation of being more challenging.
The main ideas of special meanings for IPv6 bits, which have still remained as active recommendations/ideas, are:
- the last 64 bits represents a host ID,
- and some number of bits (for example: 8 bits or perhaps even 16 bits) are used for creating subnets. Those bits come just before the 64 bits that are used to identify the host ID.
- Further discussion of IPv6 subnetting standards
(This section provides further details. These details are probably less critical for people to be needing to try to memorize, but this is provided as background information that might help to explain things for people who are curious, including people who may have previously heard some different details like how many bits are used for subnetting.)
(This section might be reptitive? Further review may be worthwhile...)
Some earlier documentation, widely taught as the new way to do things, indicating that the last 64 bits of an address be a host ID that is based on a system's MAC-48 address. An example is inserting 0xFF or 0xFE in between the first half of a MAC-48 address and the last half of a MAC-48 address, as noted by Appendix A of RFC 4291. (Appendix A starts on page 20 of IETF RFC 4291.) However, there were some other approaches to calculating the last 64 bits of an IPv6 address, such as RFC 4193: section 3.2.2: Sample “for Pseudo-Random Global ID Algorithm”. RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 may also have had an impact (perhaps see also: Privacy notes found on ISOC).
The idea of leaving the last 64 bits of an address available for a host ID may be important for anyone planning to use SLAAC, an IPv6 automatic address configuration method. At least some software implementation(s) of SLAAC have been known to expect a subnet size of exactly /64. So, to remain compatible with any routers that use such an implementation, which uses behavior that is technically within official specifications, leaving the last 64 bits of an address for the host ID is a practice that may still have some benefit.
A lot of the other rules related to IPv6 subnetting are either really quite similar to IPv4 subnetting, or the rules no longer matter. Some of the rules that were made for IPv6, which did not exist for IPv4, stopped mattering before those IPv6 rules were really widely impactful. Perhaps the key exception is that the bits that come right before the final 64 bits are commonly used as subnetting bits. (These are the bits that appear just before bits 65 through 128, the last 64 bits which are the host ID bits.) Currently those are bits 57 through 64 (based on the idea of giving out /56 subnets, as mentioned by RFC 6177: IPv6 Address Assignment to End Sites.) However, there used to be 16 bits availablke for subnetting (which came just before the 64 host ID bits, so those subnetting bits were bits 49 through 64). That was based on the idea of giving out /48 subnets. So, recommendations have changed a number of times before.
The discussion continues, being carried on by “IP Subnetting: Part 4: Wrap-up/Examples”.