Plans/Methods for addressing

Before assigning addresses, it naturally makes sense to determine what addresses will be used to assign. Certainly some consideration is provided for making sure that devices are within the desired subnets. However, what about the subnets themselves? All too often the general advice given is to simply use sections of private addressing, starting from the beginning, and so many technicians may not even be familiar with other techniques. However, are there better ways?

This section is about determining what addresses will be used when automatic addressing protocols hand out addresses and/or when manually assigned addresses are selected.

This is simply some generalized advice about choosing addresses. This advice does not strictly need to be followed just to have a working network, although there may be some advantages to do so. It is certainly possible that someone who does not follow these guidelines may end up, correctly or accidentally, creating a network which works just fine. However, in the case of accidental luck, chances are there may be some problems down the road.

Another item to determine is where the documentation will be stored. This way, there is a location for storing the information that gets decided here. See also: network documentation.

[#ip4adyrn]: Some general guidelines on selecting private IPv4 address ranges
[#cmnpvadr]: Do not start off by using: 192.168.0/24, 192.168.1/24, etc., nor 192.168.168/24
Reason number one: High usage

These should remain unused. Why should people refrain from using these addresses? Because they are so commonly used!

(Yes, that logic probably does sound a lot like the “Yogism” which says “Nobody goes there anymore because it's too crowded.”)

For example, these addresses may be used as default values for some equipment. Broadband (e.g. DSL and Cable) “modems”, firewalls, and smart switches may default to addresses in these ranges fairly frequently. (Some such equipment may have a “console” port just for configuring. However, some other equipment may not include another physical port just for such a rarely (possibly never) used situation, and expect configuration to happen via an Ethernet connection to default ports. There are multiple possible causes that could result in a device using these default values: a newly obtained device being added to the network may be starting with these values, or possibly the address starts being used due to a reset switch being intentionally held down, or possibly because that the device was designed to return to default values if a custom configuration failed to load. If a device is using these values, for whatever reason, the device not communicate much with most of the rest of the network devices, but that may be desirable before the device is properly configured. It is usually easiest to speak with using a single other device that is temporarily, intentionally placed on the subnet.

If, for example, 192.168.1.1 was used for a key server or a firewall, and then some other device started using that address, then the result is likely to be an IP address conflict that causes problems on the network. Furthermore, once the problems start occurring and the cause of the problem is determined, connecting to the device to fix the problem may be more difficult due to the IP address conflict. Simply changing the IP address of the conflicting device (the main file server or the main device used for an Internet connection) may not be an attractive option when the device usually using that address is supposed to be available for other tasks. Also, turning off key network infrastructure, just to fix one device, may not be a simple, straightforward task when trying to fix a network problem remotely. In contrast, if a different subnet was used, the device could likely be communicated with easily by a workstation that is temporarily assigned multiple IP addresses at once: one IP address to continue to communicate on the normal network, and one IP address to communicate on the temporary subnet.

The other thing that causes these addresses to be used so frequently on actual networks is that these addresses are often addresses used for documentation, examples, and networks created by those with minimal networking skills. Those with more extensive networking skills will often also use these same subnets because, after all, they should theoretically work and the reality is that they often do, and those are the subnets that the experienced technician has experience successfully using. However, because of the increased likelihood of these subnets being used, if networks ever need to combine, there is a much larger chance of requiring renumbering in order to prevent an IP address conflict. A simple solution is to use networks which are less likely to be used by others.

The most-used subnets are likely 192.168.1/24 (especially likely to be used is the address 192.168.1.1, although FortiGate uses the address 192.168.1.99, and 192.168.1.254 may be used fairly often) followed closely by 192.168.0/24 (especially 192.168.0.1). Subsequent /24 networks, such as 192.168.2/24 and 192.168.3/24, end up being used with notably less frequency as the third octal byte of the address continues to increase.

Here are some other ranges which are known to be used by some very large companies. Avoiding them may be less likely to lead to conflicts (either immediately, or down the road when a computer might become part of an organization that does interact with a product/service by one of the large companies.)

192.168.100/24

Calomel.org guide to using ifstated says that 192.168.100.10 “is in Comcast's "walled garden"; an internal cable modem network use for diagnostics and for unregistered cable modems.” Seeing this address requires taking action “to get an” (IP(v4) network address) “which is public and valid.”

192.168.168/24
The 192.168.168/24 (specifically 192.168.168.168) is used by some SonicWall equipment.
Reason number two: consider another way
There are often advantages to keeping an open mind, familiarizing one's self with options, and considering using a different method. Before blindly implementing networks with these common addresses because they are commonly used, and they work, and perhaps their usage seems familiar, simply see the text about using RFC 1219 and, at the very least, just simply consider whether or not that seems to offer any advantages. Then, the recommended way to proceed is, naturally, to use whichever one seems superior.
[#coun1219]: Alternate ways of counting (using RFC 1219's guidelines and strategy from RFC 3531)
Warning

This topic is quite complex, and is not widely utilized. People who struggle with subnetting may wish to ignore this. People who are designing networks as part of a formal training program, such as a class, should probably check with the training leader (e.g., the instructor of a class) about whether to use this method of subnetting.

In a nutshell, this is not currently recommended for people who dislike math where things often seem more theoretical, rather than tangible.

This section of documentation studies a way to choose the order of subnets other than just looking for subnets in numerical order (which will likely appear to be combined, or adjacent to each other, on a VLSM chart).

At the time of this writing, it is believed that the major network certification providers that cover networking, such as CompTIA Network+ or Cisco CCNA, cover this sort of material in any of the basic certifications. This method would almost be considered to be “non-standard”, except that it is documented by some IETF RFC documents.

Those who are interested in exploring theoretical possibilities, to obtain maximum optimization in some areas, are encouraged to check out this subnetting method and understand how it works. However, this could easily amplify the risk of subnetting seeming to be complicated, and so this is not currently being recommended for general use by those who are less passionate about such things.

The numeric patterns

See Charts of the third octet of a /16, using RFC 1219. To use this method, simply pick a random even number to start counting with using the charts shown, and then randomly decide whether to use odd numbers or even numbers. (If odd numbers, simply add one to the numbers shown in the charts.) Don't have a coin to help randomly choose between even and odd? If alone, try looking at a clock, and see if the number of seconds is an even or odd number. If performing this as a group made of people listening to these instructions simultaneously, first break up the unity by having each person count to a number unique to them, such as each person counting, about one number per second, to half of the day of the month that person was born in. (As people are likely to count at a bit of a different speed). Then have them check how many seconds past the minute it is.

According to the logic presented in RFC 1219 (which is for IPv4... a similar RFC 3531 discusses some similar logic with IPv6), if sequential counting of subnets is going to be used, it makes sense to count the subnets by using numbers as if counting binary with the bits in reverse order so that the least significant digits appear first.

Variations could be made, such as counting from the middle bits (like the IPv6-focused RFC 3531 demonstrates) instead of from the right. One could also do some things as well, such as bit shifting by a constant or varying amount, as long as this was done in such a fashion to make sure that other numbers are also bit-shifted as needed so that there are no collisions. However, with whatever pattern is used, make sure that any variation is clearly noted (and backed up as needed) so that the pattern one may continue to be used (easily, without needing to work hard to determine what the pattern was) in case expansion is ever needed.

Comparing this method to sequential counting
Advantages

Some may want to understand some advantages to using such a counting method before implementing it.

The advantage is to gain some flexibility by intelligent use of the bits. To explain: The number of subnets requires a certain number of bits to keep track of the individual subnets. For example, if there are six subnets, then three bits are required in order to keep track of all of the subnets, and then the remaining subnet bits simply aren't performing any use. By having these unused bits be set to the right of the subnet's number, those bits can easily be used for longer host identifiers in case that is needed because of one of the subnets using more than 254 hosts addreses. (Keep in mind that 254 hosts addresses may be used up without having different hosts, due to host naming patterns (where a certain amount of addresses are reserved for similar uses) and/or a host having multiple IP addresses.)

For example, if it is later decided that 27 subnets are needed (5 bits) and each of then need to keep track of up to 700 hosts (which will require 10 bits), one may simply change the subnet masks as needed and no subnet IDs, nor already assigned host IDs, will need to be changed. The renumbering requirements may be far less substantial. (Plus, there is still one remaining flexible bit in this example, and until there is a need for more subnets or more hosts, there is no need to dedicate whether the purpose of this bit will end up being to help track more subnet IDs or whether it will be used to track more host IDs.) In essense, the optional “leading zeros” of the subnet ID are to the right of the used digits of the subnet ID, and those unused bits get added to the unused bits from the leading zeros of the host IDs, and all of those unused bits may later be used for either purpose.

In comparison, if the right-most bits of the third octet of an IPv4 address, bits 17-24, are used sequentially, the leading zeros are seperated from the host IDs. Those leading bits, therefore, cannot easily be made to accomodate a /22 to keep track of more hosts, because bits 23 and 24 were previously allocated and are being used for keeping track of subnets. For the host IDs to grow, the subnets need to be re-numbered, and that re-numbering is required only because the bits to the left of the used subent bits are unused, wasted bits.

As another example, the network being used for this example involves initially having seven subnets (requiring 4 bits for subnet IDs) with twenty four hosts each (requiring five bits for host IDs). It is later decided to add ten more subnets, but no additional IPv4 address space has been made available, and also increasing the number of hosts per subnet up to fifty two hosts per subnet. This will be implemented by taking the first subnet (identified by 4 bits of subnet ID) and subnetting it further, using an additional five bits to keep track of the subnet ID. The result is that the ten new subnets are identified by a total of nine bits each. The number of bits for the host ID increased to six. No subnets need to gain new subnet numbers, and no hosts need to get new host IDs. There is, in fact, one remaining bit for expansion, which may be used to either keep track of subnets or keep track of host IDs.

Disadvantages

The disadvantage to using this method is that one may not be able to share the left-most subnet bits with the larger network (such as a network provided by an ISP). For instance, using numerical order, subnets of .1 and .2 share the left-most 6 bits, which means that those 6 bits could be used for aggregation (by “supernetting” multiple subnets into a larger supernet). Using the method described by RFC 3531, the nearby subnets of .8 and .16 share only the left-most 3 bits, so fewer bits are positioned nicely for creating supernets.

(Instead, there are more bits positioned on the right side of the address, positioning them nicely to be used to identify a specific “host”. So there is no real overall loss in bits; the flexibility is just moved to a different location. However, the flexibility that is gained in one location, which may be more likely to be the more useful location, is also flexibility that is lost in another location, which may be more likely to be the less useful location in many circumstances. Conceivably, there could be some circumstances where the inability to supernet as deeply may be more valuable.)

However, the re-doing subnet IDs are probably more likely to be something done because of a fluctation with the number of hosts rather than a fluctuation in the number of IPs provided by a network provider (such as an ISP). So this method is nice. (Additionally, this disadvantage could be mitigated somewhat by using a different counting pattern, such as that of the number patterns using RFC 3531's guidelines.)

Also, combining multiple routes may involve using bigger routes. For instance, using RFC 3531 section 3.3's Centermost counting method of 0, 8, 16, 24, 4, 12, 20, 28, 32 are have the same left 2 bits, so they could be part of the same /26 (if breaking up a /24 into subnets) or /18 (if breaking up a /16 into subnets), whereas counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 uses the same left four bits, so a subnet grouping could be as small as a /28 (if breaking up a /24 into subnets) or a /20 (if breaking up a /16 into subnets).

Also, people are less likely to have the order of subnets quickly memorized when using these alternate counting methods. That may slow people down. This is not really a technical disadvantage that would hinder automated processes, but may affect how quickly some experts could create subnets “manually” (meaning that they aren't using an automated process, so they either do this in their head, or by using a scratch pad to write onto).

Unfortunatley, a lot of people completely lack familiarity with this method because this method does not seem to have been taught in as many different sources of example documentation. However, that unfamiliarity does lead to yet one more advantage: If networks combine, a network implementing this method may be less likely to need to renumber due to the other network using the same subnet ID.

RFC 1219 and RFC 3531

These counting methods are described a bit further on RFC 3531 charts. To compare them, RFC 3531 offers a bit less flexibility for host addresses, because it tries to divide the flexibility evenly between host addresses and subnets.

Use addresses from many large subnets

This advice is primarily meant for IPv4. (A discussion of how this applies to IPv6 follows the IPv4 discussion.)

The term “large” being used above is, in this case, meaning to refer to a subnet size such as a /24, rather than smaller subnet sizes such as /29s or even /30s.

If there are multiple ranges of addresses to be used from an abundant range, such as IPv4 private addresses, consider going ahead by placing these in visibly different subnets. For example, if there are four IPv4 /30 subnets and two IPv4 /29 subnets and two IPv4 /28 subnets, consider liberally using other subnets such as 192.168.0.0/30 and 192.168.128.0/30 and 192.168.64.0/30 and 192.168.192.0/30 and 192.168.32.0/28 and 192.168.160.0/28 and 192.168.96.0/28 and 192.168.224.0/28.

This idea may go contrary to some guidelines which promote conservative use of address space. After all, the subnet sizes provided could all fit within a single IPv4 /26 subnet block leaving three quarters of the /24 still untouched, and not needing to use any blocks from any other subnets. With the subnets chosen in the example above, it is quite easy to tell that each subnet is using up addresses in a different /24 (and, in fact, each subnet shown above is in a diffrent /19), even if only two usable addresses are needed. Using a whole /19 just for two addresses may seem like an incredible waste, so why do it?

Actually, although these addresses exist in different /19 blocks, a whole isn't used in any of these examples. The numbers were derived from using the counting using RFC 1219's method. The number of bits used to store subnetting information is a total of three bits, which is not any more bits than if 192.168.0.0/24 through 192.168.7.0/24 were used. These blocks could also be thought of as /24's, and that may seem less wasteful to some people. However, besides that point, the concept of using different /24 blocks may still seem unnervingly wasteful to some people since this is contrary to the training that some people have received about conservatively using IPv4 numbers.

The answer is simple: When troubleshooting how network traffic flows or doesn't flow, it may be quite a bit nicer to be able to look at an address and instantly see whehter it is part of the same subnet as another address. Using different /24 blocks may make that far easier than needing to go check on what the subnet size is (to distinguish the /28s from the /29s), and even further time is taken if, after one does look up the prefix length or subnet mask, if one cannot instantly know whether two addresses are in the same subnet. Any time thinking about this or looking it up in some fashion is time that wouldn't need to spent if everything was just in a /24. This time dealing with such details distracts the troubleshooting administrator from other technical details that the technician could be focusing on to successfully complete the troubleshooting.

Fine tuning of the number selection in order to cram everything into as small of blocks as possible is a valuable skill and may be useful in some contexts, but for a simple small network with just a couple dozen machines, such fine tuning may be more likely to waste time right away (when designing the network), and possibly also waste more time down the road (when troubleshooting; specifically when trying to determine why traffic isn't flowing exactly as expected).

With IPv6, the same concepts apply, except that instead of using addresses from various /24 blocks, the more likely prefix size to consider would be separate /64 blocks. Actually, with IPv6 this advice may not be something that is applicable as often, as there is another larger reason to spread different subnets out to differnet blocks which are no smaller than /64 blocks (meaning that the prefix length is no larger than /64). That is because of SLAAC's limitations of not working with blocks with a subnet which is smaller in size than a /64.

Further information about IPv4 address ranges
  • The most important addresses to be aware of may be the ranges specified by BCP 5. (BCP 5 is a name that should be stable, although RFC 1918 is a name that more people are familiar with and it probably shows up in more documentation, even though the BCP 5 may, in theory, someday point to a newer RFC.) Namely, know limitations (especially the fact that public Internet routing blocks addresses in these ranges) and that they are freely available for private assignment. Network technicians will generally benefit from memorizing these ranges.
  • Some other addresses ranges to be mentioned by RFC 5735: Special Use IPv4 Addresses. Some of these ranges should probably also be memorized by network technicians early on, while others might simply be ranges to be aware of.
  • For more information about IPv4 address ranges, see IPv4 address (range) usage.

For convenience:
(IPv4) Subnet mask address chart:
A /25 has half as many addresses as a /24. The number of the subnet mask is increased by the amount of addresses that fits in a block of this size.
The number of addresses only refers to prefix lengths of /24 - 32.
/0, /8, /16 are like /24 : 1 block of 256 numbers (254 usable addresses) (subnet mask 255.255.255.0).
/1, /9, /17 are like /25 : 2 blocks of 128 numbers (126 usable addresses) (subnet mask 255.255.255.128) (0 + 128).
/2, /10, /18 are like /26 : 4 blocks of 64 numbers (62 usable addresses) (subnet mask 255.255.255.192) (128 + 64).
/3, /11, /19 are like /27 : 8 blocks of 32 numbers (30 usable addresses) (subnet mask 255.255.255.224) (192 + 32).
/4, /12, /20 are like /28 : 16 blocks of 16 numbers (14 usable addresses) (subnet mask 255.255.255.240) (224 + 16).
/5, /13, /21 are like /29 : 32 blocks of 8 numbers (6 usable addresses) (subnet mask 255.255.255.248) (240 + 8).
/6, /14, /22 are like /30 : 64 blocks of 4 numbers (2 usable addresses) (subnet mask 255.255.255.252) (248 + 4).
/7, /15, /23 are like /31 : 128 blocks of 2 numbers (not many usable addresses) (subnet mask would end with (subnet mask .254) (.252+2).
/32 : 1 address (one usable address) (subnet mask 255.255.255.255) (252 + 2 + 1).

Many people learning IPv4 subnetting may be inclined to try to learn the subnet masks. That may not be a bad idea, but knowing some of the patterns in the above chart may be helpful to be able to quickly and accurately make the chart on the fly.

One pattern is that the size of each network block halves with each new prefix length. For instance, while a /11 has the 256 possible values of the second octet broken up into groups of 32 numbers, a /12 has the octet broken up into groups of 16 numbers. Since the size of the groups is halved, there can be twice as many groups.

Here is another pattern which takes a little more work to understand, but can be helpful to quickly re-create the chart. If the last octet of the IPv4 subnet is not zero, then the last octet of the subnet mask equals the last octet of the previous IPv4 subnet mask plus the number of addresses that fit within the netblock. As an example of that, a /28 subnet mask ends with “.240”. That number can be obtained by taking “224”, which is the last octet of the subnet mask of the previous prefix size (a /27), and adding that number to 16, which is the size of the network block of a /28.

To help make this more understandable, numbers in parenthesis are shown after the subnet mask. Those numbers are showing the addition being referred to, so simply see where those numbers appear in the subnet mask and where one of those same numbers appears in the amount of usable addresses.

Since the size of each network block is halved each time (as discussed), and the amount that the last octet of the subnet mask is increased by is equal to the size of the network block (which was also discussed), the amount of increase in the last octet of the subnet mask is also a number that gets haved each time.

If a person notices that the subnet masks are starting to be memorized quicker than the size of addresses within the netmask, it may be useful to know that the amount of usable addresses in a /25 or smaller subnet (which would have a prefix length which is longer, represented by a larger number) equals the last octet of the subnet mask minus the last octet of the previous subnet mask.

Note that the chart says that a /13 is “like” a /29, not that they are identical. The amount of addresses is obviously way different. However, some things are common. For instance, the last non-zero octet in the subnet mask are the same: The second octet of a /13's subnet mask is 248, just like a /29's last octet in a subnet mask is 248. Also, the 256 possible values represented by the octet is essentially split into a distinct number of seperate groups. With both a /13 and a /29, that number of distinct groups is the same (32). Similarly, a /10 will have the same number of distinct groups (there's four of them) as a /26.

The idea of a /31 having zero usable addresses is logically consistent and is supported by documentation supported by some large organizations. However, RFC 3021 discusses a proposal for another use for subnets using this otherwise useless subnet size.

[#ip6adyrn]: Advice about IPv6 address ranges

One may first wish to determine whether to use public IPv6 addresses or private IPv6 addresses such as those that are in the fd00::/8 range.

The following are some guidelines about what IPv6 addresses make for a good choice to use.
The address range fec0::/10 (Do not use for new designs)

This address range goes from the start of fec0::/16 through end of feff::/16, binary starts with 1111 1110 11...).

Some simple advice is: Do not use fec0::/10 for any new network designs. This isn't to say that fec0::/10 may absolutely never be used. However, working with fec0::/10 may require considerations that make it so that this address range is not the easiest range to use. Unless there is a need to use it, stay away from it: Don't use it, even if other (older) documentation may refer or even recommend this as an option. (This address blcok is being mentioned first to help spread modern information, as using this was once a recommended option. Now, however, it is generally recommended to not use these addresses.) If for no other reason, one reason to avoid using these addresses is simply because it seems feasible that various equipment might, now or in the future, vary in how to support or not support this address range.

To elaborate: The fec0::/10 was named “Site-Local” by RFC 3513 section 2.5.6 and would have been a candidate for being private addresses, thereby acting similar to the address ranges specified by BCP 5 (RFC 1918) for IPv4. However, the concept of an IPv6 “site” turned out to be fairly difficult to understand/implement/support, and the result was that RFC 3879 was made to deprecate these addresses. This deprecation is acknowledged by RFC 4291 section 2.5.7 : Site-Local IPv6 Unicast Addresses.

As a specific example of text from that RFC, RFC 3879 section 4 does say “However, router implementations SHOULD be configured to prevent routing of this prefix by default.” Presumably, therefore, it should be assumed that such traffic is not allowed unless there is a reason to use a non-default configuration. It may make good sense for those who want tight control over the network to simply block such traffic unless exceptions are made. (This sort of policy will help to make it so that exceptions may be documented and subsequently tracked.)

Some older documentation stated “Site-Local while continuing to exist in the IPv6 specification is the subject of on-going work in the IETF and is currently not supported.” So it seems that even before RFC 3879, wide-spread reliance on how this worked may not have been recommended.

An exception to this rule (of not using these addresses) may be the well-known IPv6 addresses for DNS server(s). Details are available at information on “Well-known” (site-local) addresses.

Choosing whether to support this ends up being a matter of whether one wishes to make things work as much as possible, even if such actions are violating recommended practice: Proponents of recommended practice may prefer that non-conforming implementations fail to work. Causing incorrect things to fail may cause some short term inconvenience, but the reason people may favor this is because it helps to identify incorrect configurations. That may help people to be able to correct situations early, rather than effectively hiding problems until they are even more difficult to identify, and more difficult to fix. Other people may be in favor of making things work as much as possible. This might potentially result in an “incorrect” configuration, but any results that seem unideal on a theoretical level might never end up being impactful to anybody. Some people prefer flexibility, while others prefer not allowing (and therefore not having) problems that might exist by attempting to have flexibility. There may be a balance between doing things with rigid correctness, and being flexible, and there might not be a single best answer. This guide certainly doesn't propose to take sides and declare which side is more right.

[#rulesfd8]: Addresses from the range fd00::/8

Locally assigned IP addresses, a.k.a. “private” IP addresses, for IPv6 may come from the fd00::/8 range. Unlike fec0::/10 which is noted to be deprecated by RFC 3879 and RFC 4291 section 2.5.7 : Site-Local IPv6 Unicast Addresses, RFC 4291 does not refer to fd00::/8 as deprecated. Therefore, feel free to use these as “private” addresses (similar in nature to BCP 5 (RFC 1918) for IPv4).

(The reservation of this range comes from RFC 4193. Specifically, fc00::/7 (which are all addresses that with six bits set to one, followed by a bit cleared to zero) can be divided into two IPv6 /8 blocks. These blocks are are fc00::/8 (which are all addresses starting with six bits set to one, followed by a bit cleared to a value of zero, followed by another bit which is set to zero), and fd00::/8 (which are all addresses starting with six bits set to one, followed by a bit cleared to a value of zero, followed by a bit which is set to one). RFC 4193 section 3.1 gives a name of “L” to the eighth bit of all fc00::/7 addresses. (The fd00::/8 range is what RFC 4193 section 3.2 discusses. This can be understood by keeping in mind that all fc00::/7 addresses with this “L” bit set to one are addresses within the fd00::/8 range.)

Some proponents have promoted designs which involve providing public, routable IPv6 addresses to all network-capable IPv6-capable devices. Despite some of those arguments, RFC 4193's intent is to provide a large range of private, non-routed addresses that network administrators may use. Therefore, this guide's recommendation is to not be afraid to use such addresses using the guidelines that are laid out by one or more RFC documents (such as RFC 4193). RFC 4193 section 4.3 states: “The default behavior of” (“Site border routes and firewalls”) “should be to install a "reject" route for these prefixes.” (However, NAT could be employed, similar to IPv4's private addresses specified in BCP 5 (RFC 1918). Some advocates are heavily against the idea of doing such a thing, though.)

Another option would be to use public IPv6 addresses, and block the traffic for them, which would likely be more palatably acceptable. The problem is that requires that firewall rules be customized to block such traffic: By using fd00::/8, the firewalls are more likely to be set to block such traffic by default (in order to follow the advice of what “should” be done, as noted by (RFC 4193 section 4.3) until other handling for the traffic is set up. Until things are fully configured, preventing traffic from interacting with the Internet is likely the safer approach. (Note that, as RFC 4193 section 7 points out, any “gloabl IPv6 unicast” address outside of the fd00::/8 range could be protected equally by firewalls. However, filtering such traffic may frequently not be the default action for global unicast addresses.

There are some requirements that RFC 4193 lays out for this range. After the first 8 bits, the next 40 bits are a global ID. Those 40 bits have some requirements:

  • RFC 4193 Section 3.2 notes that those 40 bits are supposed to comply with “[RANDOM]”, which the document later identifies as BCP 106 (which was RFC 4086 at the time when RFC 4193 was published).
  • RFC 4193 Section 3.2 also says the 40 bits also “are not designed to aggregate” and should not be sequential or assigned with well-known numbers.
  • RFC 5453 documents other invalid addresses, such as addresses within FD00::/8 which start with FDFF:FFFF:FFFF:FF80: or any later/higher address that is still within the FD00::/8 range. (This ends with the address at the end of the FDFF:FFFF:FFFF:FFFF::/64 netblock.) (It may be wise to check for updates of that RFC, by looking to see if tools.ietf.org lists any updates for that RFC in the header of that RFC.)

Although RFC 4193 section 3.2.2 provides a method of calculating the first 48 bits of the address, this is simply a “suggested algorithm” (using the description from section 3.2.1). Also, the sentence at the top of RFC 4193 page 5 just before section 3.2.1 does show clearly that the global IDs “do not need any central coordination or assignment” and that these “local assignments are self-generated”.

After the first 8 bits (0xFF) and the next 40 bits, it is intended that the next 16 bits will be used as desired to create subnets. These bits don't have the same sort of rules that bits number 9 through 48 have. To summarize, after the first byte (0xfd), the next 56 bits are used to specify creating a Global ID and a subnet. Those 56 bits are meant to be chosen by network administrators designing private networks, with the restrictions noted in the above rules that apply to the first 40 of those 56 bits should follow. The last 16 of those bits, also locally assigned and not centrally coordinated, do not have any of these rules and it is intended that the designer of the network may use these bits in whatever fashion seems desirable.

However, just because those 16 bits may be selected without rules does not mean there isn't a wiser way to do things. RFC 3531 provides some guidelines, which basically involves counting in binary with the least significant bits being the middle bytes rather than a bit on either side. Specifically, RFC 3531 section 3.3 shows the first 10 values of a pattern so those exact values may be used for up to 10 subnets (and further values may be used for more subnets). However, the example in RFC 3531 section 3.3 is using only 8 bits: Since there are 16 bits to subnet with, simply add four zeros before each example and four zeroes after each example.

The final 64 bits are the host portion of the address. Within a /64 subnet, if a single address is assigned dynamically using SLAAC then it is probably safest to simply have all addresses within that /64 range be assigned dynamically by SLAAC, as SLAAC is not likely to avoid using certain addresses just because they are reserved (unless SLAAC's DAD does determine that the address is in active use by another device).

[#rfc3531x]: Expanding on RFC 3531's example

Above was discussed the pattern of RFC 3531 section 3.3. Here is an implementation with 16 bits.

Instead of writing binary out with the bits in the following order:
2^16 2^15 2^14 2^13 2^12 2^11 2^10 2^9 2^8 2^7 2^6 2^5 2^4 2^3 2^2 2^1
(That is, most significant bit first, and least significant bit on the outside), the order is:
(2^16 2^14 2^12 2^10) 2^8 2^6 2^4 2^2 2^1 2^3 2^5 2^7 (2^9 2^11 2^13 2^15)
If there are 16 bits, use the places that are surrounded by parenthesis. If there are only 8 bits, ignore the places surrounded by parenthesis (so, don't use them).

Counting is then normal, like as if counting in binary: After using up the possible values that can be specified using just the bit in the 2^1 place, continue to count by using the bit in the 2^2 place. After using up the bits in the 2^2 place, continue to count by using the bit in the 2^3 place. That means, if using 8 bits, counting goes from:
00011000 (Bits in the 2^2 and 2^1 places are set: In standard binary notation this would be like 00000011)
to:
00000100 (Bits in the 2^2 and 2^1 places are cleared and bit in 2^3 starts getting used: In standard binary notation this would be like 00000100)
and then to:
00001100 (Bit in the 2^3 place is still set, and counting continues by increasing the bit in the 2^1 just like normal. In standard binary notation this would be like 00000101.)

Similar to the RFC 1219 charts for IPv4 addresses, this site may have had, and may once again have, RFC 3531 charts for the first 256 addresses.

Attention needed: This is based on some old notes which may not be accurate anymore. And a 16-bit variation: How to handle a larger decimal number: Divide by 256. The remainder/modulus represents the least significant bits: Use that remainder with the chart. For the dividend portion, use that with this chart. Take the first hexadecimal digit and put that before the least significant bits. Take the second hexadecimal digit and put that after the least significant bits.

Other charts may be at: hex values (chart), converting hex/bin:
0000 0
0001 1
0010 2
0011 3
0100 4
0101 5
0110 6
0111 7
1000 8
1001 9
1010 A
1011 B
1100 C
1101 D
1110 E
1111 F

Public IPv6 addresses

IANA IPv6 Address Space may show that 4000::/3 through the end of f800::/6 is “Reserved by IETF”. That is by far most of the IPv6 addresses. Additionally, much of the address space before 2000:: may also be marked as reserved.

If one already has public IPv6 addresses, there is little harm in using them. However, one should not expect such addresses to be automatically firewalled. (In contrast, well-implemented networks are likely to prevent routing traffic with fd00::/8 destination addresses from going to the Internet or being accepted from the Internet, quite similar to the “private IPv4 addresses” from BCP 5 (RFC 1918). However, in comparison to those specific IPv4 addresses, some may be less likely to use NAT with IPv6 even if, due to more limited address space with IPv4, those same people have less reservations with using “private IPv4 addresses”

Note that if one has a network/subnet of public, routable addresses may be made unroutable through identifying which addresses aren't supposed to reach the Internet and then setting up firewall rules that block traffic from subnets that those addresses are a part of. (Other ways to have private addresses are to use the range fd00::/8 or the less recommended fec0::/10.)

Misc IPv6 address info
RFC 5156 describes some addresses that should not be considered standard public IPv6 addresses. (This document is useful for helping to determine firewall rules. RFC 4890 probably is as well.)
Getting a /48

To summarize the above, the first byte of the /48 should be 0xFD. (For example, the first two bytes might be 0xFD00.) For the remaining 40 bits of the /48, calculate five octal bytes according to the guidelines provided above. A recommended way to calculate those bits is the method described in RFC 4193 section 3.2.2, which has some requirements including an EUI-64 number (which may be derived from a MAC address). Ensure the end result doesn't violate RFC 5453.

Having picked a number between 0 and 65535 and simply choosing 20, we'll use subnets 20 through 22 as specified by counting using the method described by the IPv4-centric RFC 3531 section 3.3. By doing this, the subnets that will be used are... ? Unfinished?????????

Further information about IPv6 address ranges

Unknown/possibly-old info

Like the IPv4 addresses mentioned above, we'll probably want to be using at least three subnets. The common way to do this is to decide on a /48, and then use 16 bits to subnet that /48 into /64 subnets. For example, if the /48 was 2001:db8:0:: then the /64 addresses could be 2001:db8:0:fedc:ba98:0:1000::