Principles of Designing Hierarchical Addressing Structure in Deploying IPv6

I decided to share my experience in designing and implementing IPv6 while adhering to industry specifications. A substantial amount of material has accumulated (development, implementation, security), but we need to start from the beginning and from the top. So the goal of this article is to provide information and recommendations regarding aspects of addressing planning when deploying IPv6.

But before I begin, I would like to add one more argument in favor of IPv6. Well, let's agree – it’s beautiful!

It is beautiful when it is done not with "crooked hands" (as shown in the picture in one of the comments), but according to a well-developed plan, in accordance with all standards, and with an understanding of the practical experience accumulated by the industry.

It is important to note that most often the registrar (in Russia, the registrar is RIPE NCC) issues a minimum address space of /48. Even for a medium-sized company with branches, this is very little. One should always try to reserve as much space as possible because we must remember the principle of continuous network expansion. When I started working on the implementation of IPv6 in one agency, the project was at a complete standstill, primarily due to the lack of subnets. With several dozen branches, ARIN allocated them only /48. From this space, they linearly divided it into a lot of small pieces. As a result, very little worked, and it was chaos and hell. Engineers constantly complained about "the nasty IPv6." It wasn't IPv6 that was nasty, but the design and methods of its implementation. We managed to get ARIN to allocate the agency /40 (by the way, they also kept /48) and redesigned the layout. This was possible because there are industry rules that define the sizes of address space:

Thus, one of the fundamental aspects of any IP communications infrastructure is the addressing plan. The implementation of IPv6 in a network with its new addressing architecture means that network designers need to reconsider existing approaches to network addressing. A lack of understanding of this aspect significantly slows down the deployment and integration of IPv6.

A well-structured plan allows for linear resource scaling. In IPv6, scalability means that you can add thousands of new network segments without changing the overall addressing logic. This approach helps ensure operational advantages:

• Clarity of structure (emphasizes that the logic of dividing the network is immediately visible).

• Intuitiveness of addressing (when the administrator does not need to guess which segment the prefix belongs to).

• Transparency of hierarchy (emphasis on the fact that the levels of the network are easily distinguishable).

• Cognitive accessibility, easier recognizability (prefixes are easy to remember or differentiate from one another).

• Semantic clarity (when the prefix carries a clear meaning, such as a region or department code).

• Visual cleanliness (minimum “mess” of numbers and letters) and understandable navigation (within the address space).

• Optimization of route aggregation.

• More efficient administration of access control lists (ACL) and other security policies.

• Scalability (the system does not become “chaotic” as it grows).

My list of industry standards to consider when planning address space:

1) Standardization of subnet sizes [ RFC 7381 ]

Dividing the allocated address space into equally sized subnets (site, subnet, function) helps simplify the overall addressing scheme. Such a hierarchy is easier to design, administer, make changes to, and track. Additionally, they are easier to aggregate, potentially allowing for more compact routing tables and neater access control lists (ACLs), reducing the risk of errors.

If the IPv6 plan is correctly designed, even with a tenfold increase in the network, the administrator still understands the structure of the addresses at first glance because it is designed according to a unified plan.

2) Observing nibble boundaries [RFC 4864; RFC 6177]

A nibble boundary is a network mask that corresponds to a boundary of 4 bits. In an IPv6 prefix, each hexadecimal character represents one nibble, which is 4 bits.

Observing nibble boundaries provides more readable addressing, making prefixes more recognizable and easier to understand. This will significantly improve the efficiency of network administrators and reduce the number of configuration errors.

It should also be remembered that the length of the delegated DNSv6 prefix must always be a multiple of 4 (/64, /60, /56, /52, /48, etc.) to ensure consistency of reverse tree records (DNS PTR) in ip6.arpa. Therefore, if we want reverse DNS name resolution to work in IPv6 networks, the prefix length must end on a nibble boundary.

3) Allocating a 64-bit prefix as the minimum size of a network segment [RFC 3956; RFC 3971; RFC 4864; RFC 4866; RFC 5375; RFC 6461; RFC 7371; RFC 8981]

The industry standard recommends using a 64-bit prefix on every network segment, regardless of its size in an IPv4 network. It is important to note that the only exception is point-to-point connections on communication links between routers (in IPv4, this is usually networks with a /30 prefix). The Internet Engineering Task Force (IETF) has proposed a standard [RFC 6164], which recommends using 127-bit prefixes for point-to-point connections between routers.

In other cases, using a subnet prefix length other than /64 will disrupt the functionality of many IPv6 features, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND), impair Stateless Address Autoconfiguration (SLAAC), limit the use of privacy extensions in IPv6, cause mobile IPv6 connection errors, and affect the operation of Protocol Independent Multicast in Sparse Mode (PIM-SM) with a built-in RP. Many other applications, services, and servers expect the client to be allocated a full /64 network. Receiving a prefix of a different size may result in them simply not connecting. A number of other features currently under development are also based on the use of /64 subnet prefixes.

Therefore, using /64 as the minimum subnet size for clients ensures the operability of all IPv6 functions. It also reduces operational and overhead costs for configuration and simplifies the management of network infrastructure.

4) Hierarchical Address Space Organization [RFC 5375]

A hierarchical addressing scheme for designing large networks can potentially optimize its operation, universality in service provision, increase adaptability to changes, and simplify network management.

The most significant advantage of a hierarchical scheme is the ability to aggregate address space at all levels:

· Geographic boundaries — by assigning a common prefix to all subnets within a geographic area.

· Organizational boundaries — by assigning a common prefix to administrative groups within corporate infrastructure.

· Service type — by reserving prefixes for specific services such as: VoIP, WiFi, Internet access, security systems, monitoring, etc.

For example, consider the design of a hierarchical IPv6 structure for a large company whose branches are located in different regions of the country. The company has purchased an address space of /40.

The /40 range can be divided into 4 regions, each sized /42. Yes, the /42 size does not pass the half-byte boundary. In this case, it is acceptable since it is simply an additional logical level of the "folder" group for the regions, created for convenience (the half-byte boundary size of /44 would allow creating 16 regions, which is too many for ordinary commercial organizations).

Each region will contain up to 64 sites sized /48. Each site can contain up to 16 service type groups, and each service group can contain up to 4096 networks sized /64. The additional logical level of services in the hierarchy allows grouping subnets into separate categories (security, network devices, databases, monitoring devices, user networks, etc.). This will be useful for route aggregation and creating smaller access control lists (ACLs) and security policies within the site, as it is clear that traffic for subnets where users are located will differ significantly from traffic in subnets with domain controllers, database servers, or network monitoring.

There are cases where it makes sense to divide each /52 network from the third level into 16 subgroups of size /56, each containing 256 grids of /64.

Below is an example visualization of possible breakdowns of an IPv6 network sized /48.

Design options can vary depending on the organizational structure and functionality. The most important thing is to conduct a thorough analysis of the existing networks and to have a good understanding of the strategic development vector of the organization, which affects the dynamics of network expansion.

5) Methods for distributing IPv6 prefixes [RFC 5375; RFC 6177]

For large organizations and websites, sparse allocation is recommended. Sparse allocation of IPv6 implies assigning prefixes with a large number of additional unused prefixes between them. The address space is represented as a circle, which is divided into equal sectors starting from the top level of the hierarchy. Each section, in turn, is sliced into the necessary number of lower-level sectors. The main advantage of this method lies in leaving reserved space. Sparse allocation is sometimes referred to as bisection, which allocates blocks at the boundary of each new half. This method provides reserved address space that is more likely to be contiguous.

The figure below presents a visualization of the sparse allocation method with a size of /42 at the regional level (1-4) to a size of /48 at the site level:

The advantage of the sparse allocation mode is the guaranteed presence of contiguous space reserved for all allocated resources. It is well-suited for route aggregation, reduces the size of routing tables, and simplifies the configuration of firewalls and other network devices. Although this method is not defined as a standard, it is considered a recommended approach to address planning to maintain the cleanliness and efficiency of IPv6 routing tables.

However, for small sites, best practice is to use compact rather than sparse subnet numbering and to utilize lower bits when subnetting whenever possible in conjunction with "N+1" allocation. In IPv6, "N+1" allocation typically refers to the strategy where the network operator requests a prefix for its current needs (N) plus an additional allocation (+1) to ensure future growth, often for reservation or to keep adjacent blocks for organizational expansion.

The final choice of addressing scheme should be made based on the analysis of the specifics and requirements of each segment, detailed examination of the topology, and determination of the network expansion vectors.

6) Reserve the first and last subnet

From a security perspective, a router or gateway should not be considered the first host in a subnet. Similarly, hosts should not be viewed sequentially, starting from the lower and upper bounds of the node address range. Manually configurable random node identifiers are a good solution, but they come with higher operational costs, which may make them impractical for managing the entire network. However, the additional administrative burden may be justified when applied to subnets with high target value. We must remember that as the network grows, it becomes more resilient to accidental failures but extremely vulnerable when attacked at the main hubs. Any unpredictable mechanism for assigning identifiers to important network devices is preferable if it provides the right balance between security and ease of maintenance.

More information about securely deploying IPv6 systems will be in a separate security article. Here I mention this principle as it is directly related to address space planning and the unification of static address assignment principles.

8) Use of lowercase letters in IPv6 addresses [RFC 5952]

Although case sensitivity in IPv6 addresses does not matter, RFC 5952 recommends using lowercase. “The characters 'a', 'b', 'c', 'd', 'e', and 'f' in an IPv6 address MUST be represented in lowercase.”

*********

Designing IPv6 networks requires a systematic approach. Proper planning of IPv6 address space relies on industry standards and a deep understanding of the practical experience accumulated in the industry.

In this article, I have only covered the principles of planning IPv6 network address space. In the following articles, I will attempt to summarize the accumulated practical experience on the security of IPv6 networks and proper implementation. For example, selective filtering of ICMPv6 messages at the network perimeter, ensuring the preservation of core IPv6 functions while simultaneously blocking malicious or probing traffic (RFC 4890), the correct order and mechanisms for implementation (Happy Eyeball RFC 8305, RFC 7381), and other important aspects.