Skip to content
Explore the learning library ☟
SanchitGurukulTechnology · Education · Innovation Take a quiz

IPv6 Prefixes Explained: /64, /56, /48 and Hierarchical Address Planning


IPv6 provides a 128-bit address space designed to support extremely large numbers of networks and devices.

However, the real advantage of IPv6 addressing is not simply the number of available addresses.

A well-designed IPv6 address plan can provide:

  • Clear network hierarchy
  • Simple subnet allocation
  • Route aggregation
  • Easier troubleshooting
  • Room for future growth
  • Consistent VLAN addressing
  • Simpler network documentation

The key concept is the:

IPv6 prefix

A prefix identifies a block of IPv6 addresses.

For example:

ConfigurationTEXT
2001:db8:1234::/48

and:

ConfigurationTEXT
2001:db8:1234:100::/56

and:

ConfigurationTEXT
2001:db8:1234:101::/64

represent different-sized address blocks.

A larger prefix length means a smaller address block.

For example:

/64

is more specific than:

/48

Understanding how these blocks relate to each other is the foundation of scalable IPv6 network design.

Anatomy of an IPv6 Prefix

Understanding IPv6 Prefixes

An IPv6 address contains:

128 bits

A full IPv6 address can be written as eight 16-bit hexadecimal groups.

Example:

ConfigurationTEXT
2001:0db8:1234:0101:0000:0000:0000:0025

Following normal IPv6 text representation rules, this can be shortened to:

ConfigurationTEXT
2001:db8:1234:101::25

Prefix and Interface Portion

For most ordinary IPv6 LAN addressing, the network is represented by the first:

64 bits

and the remaining 64 bits identify an interface within that subnet.

Example:

ConfigurationTEXT
2001:db8:1234:101::25/64

can be viewed conceptually as:

ConfigurationTEXT
Subnet Prefix:
2001:db8:1234:101::/64

Interface Portion:
::25

The complete address is:

ConfigurationTEXT
2001:db8:1234:101::25

Global Routing Prefix and Subnet ID

RFC 4291 describes the general global-unicast format using:

  • Global routing prefix
  • Subnet ID
  • Interface ID

Conceptually:

ConfigurationTEXT
Global Routing Prefix | Subnet ID | Interface ID

The exact length of the prefix assigned to an organization is not universally fixed.

An organization might receive, for example:

  • /48
  • /52
  • /56
  • Another prefix appropriate to the deployment and provider policy

Therefore, avoid assuming:

Every enterprise always receives a /48.

What Does /48 Mean?

Consider:

ConfigurationTEXT
2001:db8:1234::/48

The first 48 bits are fixed.

In hexadecimal notation, that corresponds to the first three hextets:

ConfigurationTEXT
2001:db8:1234

If ordinary LANs use /64, the next 16 bits can identify individual subnets.

This provides:

65,536 possible /64 subnet values

inside the /48.

Examples:

ConfigurationTEXT
2001:db8:1234:1::/64
2001:db8:1234:2::/64
2001:db8:1234:3::/64
2001:db8:1234:100::/64
2001:db8:1234:ffff::/64

What Does /56 Mean?

Suppose a site receives:

ConfigurationTEXT
2001:db8:1234:100::/56

A /56 can contain:

256 /64 subnets

For example:

ConfigurationTEXT
2001:db8:1234:100::/64
2001:db8:1234:101::/64
2001:db8:1234:102::/64
...
2001:db8:1234:1ff::/64

This is one reason /56 can be useful as a site-level allocation in some address plans.


Hierarchical Addressing and Route Aggregation

Hierarchical addressing means allocating IPv6 address space in a structured way so that related networks share common prefixes.

For example:

ConfigurationTEXT
Organization
2001:db8:1234::/48

could be divided into several site blocks.

Example Site Hierarchy

ConfigurationTEXT
Corporate IPv6 Block
2001:db8:1234::/48

HQ
2001:db8:1234:100::/56

Branch 1
2001:db8:1234:200::/56

Data Center
2001:db8:1234:300::/56

Each /56 can then contain multiple /64 LANs.

For example, inside HQ:

ConfigurationTEXT
HQ Aggregate
2001:db8:1234:100::/56

Users
2001:db8:1234:101::/64

Voice
2001:db8:1234:102::/64

Servers
2001:db8:1234:110::/64

Wireless
2001:db8:1234:120::/64

Management
2001:db8:1234:1f0::/64

Why Hierarchy Helps Routing

Suppose HQ contains dozens of /64 networks.

Instead of advertising every subnet individually toward the network core, the design may allow HQ to advertise:

ConfigurationTEXT
2001:db8:1234:100::/56

The core can then use one aggregate route to represent many HQ networks.

This reduces:

  • Routing-table entries
  • Routing-protocol updates
  • Configuration complexity

It can also make troubleshooting easier because the prefix itself indicates the general destination.

Aggregation Must Match the Topology

Do not summarize networks merely because their hexadecimal values appear convenient.

A summary route should normally represent destinations that are actually reachable through the same routing area or next-hop structure.

For example, advertising:

ConfigurationTEXT
2001:db8:1234:100::/56

from HQ makes sense if the /64 networks inside that block are actually located behind HQ.

If some of those subnets are elsewhere, the summary could attract traffic incorrectly.

Avoid Encoding Too Much Organizational Detail

It may be tempting to encode every piece of information into the IPv6 address:

  • Country
  • Region
  • Building
  • Floor
  • Department
  • VLAN
  • Application
  • Security zone

Too much hierarchy can make the addressing plan rigid and waste large blocks of address space.

Use enough hierarchy to make:

  • Aggregation
  • Operations
  • Troubleshooting

easier.

Do not attempt to reproduce the complete organizational chart inside every IPv6 prefix.

Hierarchical IPv6 Address Plan

Designing a Practical IPv6 Address Plan

A good addressing plan should accommodate the network you have today and reasonable future growth.

Example Enterprise Requirement

Assume an organization has received:

ConfigurationTEXT
2001:db8:1234::/48

The company currently has:

  • Headquarters
  • Data center
  • Branch offices
  • Future cloud connectivity

Instead of immediately allocating random /64 prefixes, divide the space into larger logical blocks.

Example High-Level Plan

Purpose Prefix
Headquarters 2001:db8:1234:100::/56
Branch 1 2001:db8:1234:200::/56
Data Center 2001:db8:1234:300::/56
Cloud / Hosted 2001:db8:1234:400::/56
Future Growth Remaining space

The values are examples, not mandatory standards.

Headquarters Plan

HQ could then use:

Network IPv6 Prefix
User VLAN 2001:db8:1234:101::/64
Voice VLAN 2001:db8:1234:102::/64
Wireless 2001:db8:1234:103::/64
Servers 2001:db8:1234:110::/64
Management 2001:db8:1234:1f0::/64

Reserve Space

Do not assign every available subnet on the first day.

Leave room for:

  • New buildings
  • New VLANs
  • Security zones
  • Acquisitions
  • Cloud services
  • New data centers

IPv6 provides enough address space to plan for operational convenience rather than extreme conservation.

Use Nibble Boundaries Where Practical

One hexadecimal digit represents:

4 bits

Prefix lengths such as:

  • /48
  • /52
  • /56
  • /60
  • /64

align with hexadecimal boundaries.

That makes address plans easier for humans to read.

For example:

ConfigurationTEXT
/48
2001:db8:1234::/48

/56
2001:db8:1234:1200::/56

/64
2001:db8:1234:1234::/64

Non-nibble-aligned prefixes are still valid IPv6 CIDR prefixes.

IPv6 is classless.

Nibble boundaries are simply easier to read and document.

Keep LANs at /64

For ordinary Ethernet LANs, VLANs, wireless networks, and networks using SLAAC, use:

ConfigurationTEXT
/64

as the normal subnet size.

Do not subdivide:

ConfigurationTEXT
2001:db8:1234:101::/64

into /68, /72, or similar smaller LANs merely to conserve addresses.

If more LANs are required, allocate additional /64 prefixes from the larger site block.

Modern Interface Identifiers

The lower 64 bits of a normal IPv6 LAN address should not be assumed to contain the device’s MAC address.

Modern hosts may generate Interface Identifiers using:

  • Stable privacy-preserving algorithms
  • Temporary addresses
  • Manually assigned values
  • Other implementation-specific methods

For infrastructure servers, administrators may use easy-to-document addresses such as:

ConfigurationTEXT
Gateway:
2001:db8:1234:110::1

DNS:
2001:db8:1234:110::53

Web Server:
2001:db8:1234:110::80

where operational policy allows it.


Configuring and Testing the Address Plan

The exact configuration depends on the vendor.

The following Cisco IOS/IOS XE example demonstrates three /64 VLAN-style interfaces from the example plan.

Enable IPv6 Routing

Command
configure terminal
ipv6 unicast-routing

Configure the User Network

Command
interface GigabitEthernet0/0
 description HQ-USERS
 ipv6 address 2001:db8:1234:101::1/64
 no shutdown

Configure the Server Network

Command
interface GigabitEthernet0/1
 description HQ-SERVERS
 ipv6 address 2001:db8:1234:110::1/64
 no shutdown

Configure the Management Network

Command
interface GigabitEthernet0/2
 description HQ-MANAGEMENT
 ipv6 address 2001:db8:1234:1f0::1/64
 no shutdown

The exact interface names depend on the platform.

Verify IPv6 Interfaces

Command
show ipv6 interface brief

Confirm:

  • Interface is operational.
  • Correct /64 prefix is assigned.
  • Expected IPv6 address appears.

Verify Connected Routes

Command
show ipv6 route

The routing table should contain connected routes for the configured prefixes.

For example:

Output / Result
2001:DB8:1234:101::/64
2001:DB8:1234:110::/64
2001:DB8:1234:1F0::/64

Actual output format depends on the platform and software release.

Check IPv6 Neighbors

Command
show ipv6 neighbors

This helps verify Neighbor Discovery and connected devices.

Test Connectivity

Command
ping ipv6 2001:db8:1234:110::10

If inter-subnet connectivity fails, check:

  • Interface status
  • IPv6 address
  • Prefix length
  • Routing
  • Neighbor Discovery
  • ACLs
  • Firewall policy
  • Return path

Test Route Aggregation

If HQ is designed around:

ConfigurationTEXT
2001:db8:1234:100::/56

the upstream routing design may advertise that aggregate instead of every /64.

Before summarizing, verify that all prefixes contained in the advertised summary are actually reachable through the advertising router or that an appropriate discard/null route and more-specific route strategy is used.


Choosing Prefix Lengths and Avoiding Common Mistakes

IPv6 does not use classful address boundaries.

Different prefix lengths have different purposes.

/48

A /48 is commonly useful as an example of a larger organizational or site allocation.

It contains:

65,536 /64 subnets

However:

A /48 is not a universal requirement for every organization.

The actual assignment size depends on:

  • Provider policy
  • Regional registry policy
  • Organization size
  • Current requirements
  • Expected growth

/56

A /56 contains:

256 /64 subnets

It can be useful for:

  • Smaller sites
  • Branch offices
  • Residential/customer assignments
  • Internal hierarchy beneath a larger aggregate

depending on the deployment.

/64

A /64 is the normal prefix used for most IPv6 LANs.

It should be the default choice for:

  • Ethernet LAN
  • User VLAN
  • Server VLAN
  • Wireless LAN
  • Networks using SLAAC

/127

RFC 6164 standardizes /127 prefixes for:

inter-router point-to-point links

Example:

ConfigurationTEXT
2001:db8:1234:ff00::/127

This is a specialized router-to-router use case.

It does not mean ordinary user LANs should use /127.

/128

A /128 represents a single IPv6 address.

It is commonly encountered for:

  • Host routes
  • Loopback addresses
  • Routing advertisements for a single endpoint

It should not be confused with a normal LAN subnet allocation.

Common Mistake — Subdividing a /64

Suppose Marketing receives:

ConfigurationTEXT
2001:db8:1234:101::/64

Do not assume it can safely be divided into many /68 LANs while retaining normal SLAAC behavior.

Instead, allocate multiple /64 networks from the site’s larger aggregate.

Common Mistake — Assuming /48 Is Mandatory

The old idea that all end sites should receive exactly /48 is no longer the general IETF recommendation.

IPv6 allocations should provide enough address space for:

  • Multiple subnets
  • Expected growth
  • Operationally sensible hierarchy

without forcing artificial conservation.

Common Mistake — Treating IPv6 Like IPv4 VLSM

IPv4 administrators often spend significant effort choosing:

  • /25
  • /26
  • /27
  • /28

based on host count.

This thinking normally should not be applied to IPv6 LANs.

For ordinary IPv6 LAN design:

Allocate a /64.

The goal is not to conserve interface addresses.

The goal is to create a simple, scalable, standards-compatible network.

Common Mistake — Using an Address as Documentation Prefix

The documentation block:

ConfigurationTEXT
2001:db8::/32

must not be used as an actual production Internet prefix.

It exists specifically for documentation and examples.

Common Mistake — Overlapping Prefixes

Avoid accidentally allocating overlapping networks.

For example, if:

ConfigurationTEXT
2001:db8:1234:100::/56

has been assigned to HQ, remember that it contains /64 subnets from:

ConfigurationTEXT
2001:db8:1234:100::/64

through:

ConfigurationTEXT
2001:db8:1234:1ff::/64

Do not independently assign one of those /64s to another site.

Maintain an IP Address Management System

Document:

  • Parent allocation
  • Site blocks
  • VLAN prefixes
  • Routing summaries
  • Reserved space
  • DNS zones
  • Gateway addresses
  • Ownership
  • Purpose

For larger environments, an IPAM platform is much safer than relying only on spreadsheets or engineer memory.

IPv6 Prefix Planning Workflow

Key Takeaways and Summary

Key Takeaways

  1. IPv6 uses 128-bit addresses and CIDR prefix lengths to represent address blocks.
  2. The general global-unicast structure contains a routing prefix, subnet information, and an interface identifier.
  3. A /48 can provide 65,536 /64 subnets, but /48 is not a mandatory assignment size for every organization.
  4. A /56 provides 256 /64 subnets and can be useful as an intermediate site-level allocation.
  5. /64 is the normal choice for ordinary IPv6 LANs and networks using SLAAC.
  6. Hierarchical address planning allows multiple /64 networks to be summarized under larger site prefixes.
  7. Route aggregation should follow the actual network topology rather than merely convenient hexadecimal numbering.
  8. /127 is standardized for inter-router point-to-point links, while /128 represents a single address.
  9. Modern IPv6 Interface Identifiers should not be assumed to contain a device’s MAC address.
  10. A good IPv6 design reserves space for growth and documents prefixes in an IPAM system.

Summary

IPv6 addressing becomes much easier when it is treated as a hierarchy of prefixes rather than an enormous collection of individual addresses.

A scalable design might look conceptually like:

ConfigurationTEXT
Organization
/48

Site
/56

LAN or VLAN
/64

Individual Interface
IPv6 Address

The exact organizational allocation may be different.

For example, an organization could receive:

  • /48
  • /52
  • /56
  • Another appropriately sized prefix

The important principle is to receive enough address space for multiple subnets and reasonable future growth.

Inside the organization:

  • Allocate larger blocks to sites where useful.
  • Allocate /64 prefixes to ordinary LANs.
  • Leave unused space for expansion.
  • Aggregate routes where the topology allows it.
  • Document the hierarchy.
  • Avoid unnecessary IPv4-style address conservation.

For example:

ConfigurationTEXT
Organization:
2001:db8:1234::/48

HQ:
2001:db8:1234:100::/56

HQ Users:
2001:db8:1234:101::/64

HQ Voice:
2001:db8:1234:102::/64

HQ Servers:
2001:db8:1234:110::/64

This structure is easier to:

  • Route
  • Summarize
  • Document
  • Troubleshoot
  • Expand

The most important IPv6 address-planning principle is:

Design around networks and hierarchy—not around conserving individual host addresses.


SanchitGurukul Static Resources

Official External References

Your feedback matters

Was this post helpful?

0 reactions

SanchitGurukul — Technology • Education • Innovation

Discussion

0 approved comments

No approved comments yet. You can start the discussion below.

Leave a Comment

No login is required. Name and email are used for moderation/security. Your email is never displayed publicly. All comments require administrator approval.

This field is not used to determine whether a comment is safe.

Plain text only. File uploads, scripts, executable code, abuse and spam are not accepted.


Discover more from SanchitGurukul

Subscribe to get the latest posts sent to your email.

Keep exploring

Related guides

Namaste! I’m SG Saarthi 👋Need help learning or finding something?