CCNA online course

IPv6 Unique Local Addresses (ULA) for CCNA

Learn IPv6 Unique Local Addresses: FC00::/7, FD00::/8, random global IDs, /64 subnetting, SLAAC, routing, Cisco IOS configuration, verification, and troubleshooting.

IPv6 Unique Local Addresses (ULAs) are private-use IPv6 addresses for communication inside an organization or between privately connected sites. They provide stable internal addressing without depending on an ISP or regional Internet registry.

ULA addresses are normally not routed across the public Internet. They are similar in purpose to IPv4 private address space, but IPv6 does not require NAT merely because private addressing is used.

Why use IPv6 Unique Local Addresses?

A ULA prefix can remain unchanged while an organization changes ISPs, renumbers its public IPv6 space, or connects sites through a private WAN or VPN. This makes ULAs useful for internal services, management networks, labs, private site-to-site connectivity, and applications that should not depend on Internet reachability.

ULA routes can be carried throughout an organization. Routers at internal sites may exchange ULA routes using static routing, OSPFv3, or another IPv6 routing protocol. However, Internet-facing routers should filter ULA routes so they are not advertised to public peers.

ULA address block and structure

The complete ULA block is FC00::/7. The first seven bits identify ULA space. The next bit is the local assignment indicator:

• FC00::/8: reserved for a possible future centrally assigned mechanism. It is not normally selected for an organization’s local deployment.
• FD00::/8: the locally assigned portion used in normal deployments. A locally assigned ULA begins with hexadecimal FD.

In practice, an organization creates a /48 prefix in the form FDxx:xxxx:xxxx::/48. The FD portion contains the ULA identifier and local assignment bit, followed by a 40-bit randomly generated Global ID.

For example, FD12:3456:789A:0010:0000:0000:0000:0001 can be divided as follows:

• FD12:3456:789A::/48 is the organization’s ULA allocation.
• 0010 is the subnet ID, producing FD12:3456:789A:10::/64.
• ::1 is the interface ID used by a router gateway in this example.

Locally assigned and centrally assigned ULA space

The local assignment bit distinguishes locally generated ULA prefixes from the reserved portion of the block. For normal deployment, use an FDxx prefix. Do not arbitrarily choose an address anywhere in FC00::/7, and do not use an FCxx prefix as though it were ordinary locally assigned space.

FC00::/8 is associated with a possible future centrally assigned system. The currently usable local model is FD00::/8.

Generating a ULA prefix

RFC 4193 recommends generating the 40-bit Global ID with sufficient randomness. Random generation reduces the probability that two independently administered organizations will select the same /48 when they later connect through a VPN, merger, acquisition, or private interconnection.

The resulting allocation has this pattern:

FDxx:xxxx:xxxx::/48

An example for documentation is FD12:3456:789A::/48. A predictable prefix such as FD00:0:0::/48 is easy to type but should not be used in production because it increases collision risk.

Documentation examples are not production allocations. In production, generate the Global ID, record the resulting /48 in the organization’s address plan, and ensure that the prefix is not already used by a connected network.

Subnetting a ULA /48

IPv6 LANs and VLANs normally receive a /64. The 16-bit Subnet ID provides 65,536 possible /64 prefixes within one /48.

Using predictable Subnet ID values, such as 10 for users and 20 for servers, is acceptable when it is documented. The collision concern applies primarily to the organization-wide 40-bit Global ID.

Assigning ULA addresses to hosts

Static interface addressing

Servers, routers, firewalls, and infrastructure devices may receive manually assigned addresses. Static addresses are useful when a device must have a stable address for management, monitoring, routing, or service configuration.

SLAAC

SLAAC, or Stateless Address Autoconfiguration, allows a host to form an address after receiving an IPv6 Router Advertisement. The router advertises a ULA /64, and the host combines that prefix with an interface identifier. Router advertisements also communicate default-router information.

DHCPv6

DHCPv6 can provide managed address assignment or supplemental information such as DNS servers. DHCPv6 and SLAAC are not mutually exclusive. A network can use router advertisements for the prefix and default router while using DHCPv6 for additional configuration or managed addresses.

Interface identifiers

• Manual identifier: useful for infrastructure and servers with documented addresses.
• SLAAC-derived identifier: formed by the host from the advertised prefix and its configured IPv6 behavior.
• Privacy-oriented address: temporary or changing host addresses that reduce long-term tracking. These are often suitable for client devices, but services that require stable addressing need appropriate DNS and application planning.

Routing behavior and Internet reachability

ULA prefixes may be routed between internal VLANs, offices, data centers, and private WAN or VPN links. A router needs a route to every remote ULA prefix, just as it needs routes for other IPv6 networks.

Public Internet routers should not carry ULA routes. Apply explicit filtering at external routing boundaries, including route redistribution and BGP export policies. A useful policy objective is to deny FC00::/7 from Internet-facing advertisements.

ULA does not provide public reachability. If an Internet user must reach a service, the service needs an appropriate global unicast address and corresponding firewall, DNS, and routing policy. Translating ULA traffic for Internet access is a separate design decision; NAT is not inherently required merely because ULA is used.

ULA and global unicast coexistence

IPv6 supports dual addressing: one interface can have both a ULA and a Global Unicast Address (GUA). A common LAN may advertise an internal ULA /64 and an ISP-provided GUA /64 at the same time.

When both address types exist, source and destination address selection influences which address a host uses. Routing policy, firewall policy, and DNS should agree with the intended reachability. For example, internal DNS can return a service’s ULA so internal clients use the private path, while external DNS returns the service’s GUA for Internet clients.

Example: two sites using ULA

Site A uses FD12:3456:789A::/48. Site B uses FD98:7654:3210::/48. Each site assigns /64s to its LANs and connects to the other site over an IPv6-enabled WAN or VPN.

• Site A users: FD12:3456:789A:10::/64
• Site A servers: FD12:3456:789A:20::/64
• Site B users: FD98:7654:3210:10::/64
• Site B servers: FD98:7654:3210:20::/64

Static routes or an IPv6 interior routing protocol can carry these prefixes between sites. The routes should remain available to authorized private peers but must not be exported to public Internet peers.

Cisco IOS configuration

Enable IPv6 forwarding and configure two LANs

ipv6 unicast-routing
!
interface GigabitEthernet0/0
 description Users LAN
 ipv6 address FD12:3456:789A:10::1/64
 no shutdown
!
interface GigabitEthernet0/1
 description Servers LAN
 ipv6 address FD12:3456:789A:20::1/64
 no shutdown

On a multilayer switch, the same IPv6 address command can be applied to a switched virtual interface after creating the VLAN:

interface Vlan10
 description Users VLAN
 ipv6 address FD12:3456:789A:10::1/64
 no shutdown

Static routing to a remote ULA subnet

ipv6 route FD98:7654:3210:10::/64 2001:DB8:0:1::2

The next hop must be a valid address on the transit link. The documentation prefix shown here is illustrative; use assigned transit addressing in a production network.

OSPFv3 for internal ULA routing

ipv6 router ospf 10
 router-id 1.1.1.1
!
interface GigabitEthernet0/0
 ipv6 ospf 10 area 0
!
interface GigabitEthernet0/1
 ipv6 ospf 10 area 0

OSPFv3 can advertise internal ULA prefixes. Use route filtering and redistribution policy to prevent those routes from reaching public Internet peers. For related OSPF concepts, see Configure OSPF and Link State Advertisement LSA.

Verification commands

show ipv6 interface brief
show ipv6 interface GigabitEthernet0/0
show ipv6 route
show ipv6 neighbors
ping ipv6 FD12:3456:789A:20::10
traceroute ipv6 FD98:7654:3210:10::10

• show ipv6 interface brief confirms configured addresses and interface state.
• show ipv6 interface displays the interface’s IPv6 settings and Neighbor Discovery details.
• show ipv6 route confirms connected, static, or dynamically learned ULA routes.
• show ipv6 neighbors displays Neighbor Discovery entries on local links.
• ping ipv6 tests reachability to a destination.
• traceroute ipv6 helps identify the hop where forwarding fails.

Troubleshooting ULA networks

Hosts cannot reach another ULA subnet

• Verify that ipv6 unicast-routing is enabled.
• Check that both interfaces have the correct /64 and are operational.
• Inspect the routing table for the remote ULA prefix.
• Check static routes, OSPFv3 operation, and IPv6 ACLs.
• Use ping and traceroute hop by hop.

A client does not automatically receive a ULA address

• Verify that the router interface has the intended /64.
• Confirm that Router Advertisements are being sent and are not suppressed.
• Check SLAAC and DHCPv6 flags and settings.
• Confirm that the client has IPv6 enabled and has learned an on-link prefix and default route.

Two connected organizations have overlapping ULAs

This usually results from predictable or copied prefixes. Compare the configured and advertised prefixes on both sides. Renumber one organization with a properly generated FD-based /48, then update routing, ACLs, DNS, VPN selectors, and documentation.

ULA routes are sent toward a public peer

Inspect outbound route advertisements and redistribution policies. Apply an explicit deny for FC00::/7 at Internet-facing boundaries, then confirm that authorized private peers still receive the required internal routes.

An internal service fails after an ISP change

Check whether clients or DNS records depended on the old GUA. Internal services should use stable ULA-based addressing where appropriate. Verify that internal DNS and ULA routes remain intact while public DNS, firewall rules, and GUA-related routing are updated.

Design limitations and best practices

• ULA addresses do not make a service publicly reachable.
• Do not assume NAT is required for every ULA deployment. Decide separately how Internet access and translation should work.
• Generate the Global ID with sufficient randomness; do not reuse simple production examples.
• Use a /64 for each routed LAN or VLAN unless a specific, well-understood design requires otherwise.
• Document the organization’s /48, every assigned Subnet ID, routing boundaries, DNS usage, and ownership.
• Filter ULA routes at public routing boundaries.
• Use ULA for internal management, private services, laboratories, private WANs, and addressing continuity during ISP changes.
• Use GUA addresses when hosts or services require Internet reachability.

Exam notes

• FC00::/7 is the complete ULA block.
• FD00::/8 is the locally assigned range used in normal deployments.
• FC00::/8 is reserved for a possible future centrally assigned model.
• A typical locally assigned ULA allocation is a random Global ID inside FDxx:xxxx:xxxx::/48.
• The 16-bit Subnet ID creates /64 subnets from the /48.
• The lower 64 bits are the Interface ID in a typical IPv6 unicast address.
• ULA routes can be used internally but should not be advertised across the public Internet.
• ULA and GUA can coexist on the same interface.

Key takeaway

Use a randomly generated FDxx:xxxx:xxxx::/48 for stable private IPv6 addressing, divide it into /64s with the Subnet ID, route it inside trusted networks, and pair it with GUA addressing when Internet reachability is required.