IPv6 Services Closure: NPTv6, DHCPv6-PD, and General Prefix

IPv6 does several things differently from IPv4, and a few of them are genuinely better - once you understand them. Prefix delegation hands a whole subnet to a downstream router automatically. A general prefix lets you renumber an entire site by changing one line. NPTv6 translates prefixes without the stateful baggage of NAT. These are the IPv6 services that close out the CCIE services domain, and they are the ones engineers who "know IPv6" often skip.

This article covers DHCPv6-PD, general prefixes, and NPTv6, with real output from a CML lab showing a delegated prefix flowing all the way to a downstream interface. For the fundamentals, see the complete IPv6 guide.

DHCPv6 Prefix Delegation: automatic downstream subnets

In IPv4, a home or branch router gets a single address from the ISP and NATs everything behind it. IPv6 does something far more elegant: the ISP delegates a whole prefix - say a /56 or /48 - to the customer router, which then sub-delegates /64s to its own downstream segments. No NAT, real end-to-end addressing, and it happens automatically.

DHCPv6 Prefix Delegation (PD) is the mechanism. There are two roles:

• The delegating router (upstream, e.g. the ISP edge) owns a pool of prefixes and hands them out.
• The requesting router (downstream, the customer) asks for a prefix and uses it to number its interfaces.

The delegating router

ipv6 dhcp pool PD-POOL
 prefix-delegation pool DELEGATED-PREFIXES lifetime 3600 1800
 dns-server 2001:DB8:99::53
!
ipv6 local pool DELEGATED-PREFIXES 2001:DB8:AAAA::/48 64
!
interface Ethernet0/3
 ipv6 nd other-config-flag
 ipv6 dhcp server PD-POOL

The ipv6 local pool defines the space to delegate (2001:DB8:AAAA::/48) and the size of each delegation (/64). The DHCP pool hands out prefixes from it. From the lab, once the downstream router requested:

R1#show ipv6 dhcp binding
Client: FE80::A8BB:CCFF:FE00:6230
  IA PD: IA ID 0x00050001, T1 900, T2 1440
    Prefix: 2001:DB8:AAAA::/64
            preferred lifetime 1800, valid lifetime 3600

The delegating router has handed 2001:DB8:AAAA::/64 to the downstream router and tracks the lease exactly like an IPv4 DHCP binding - but for a whole subnet, not a single address.

The requesting router, and the general prefix

The downstream router asks for the prefix and - here is the clever part - stores it as a general prefix, a named handle it can then use to number any interface:

interface Ethernet0/3
 ipv6 dhcp client pd DELEGATED-FROM-R1     ! request, store as this general prefix
!
interface Ethernet0/1
 ipv6 address DELEGATED-FROM-R1 ::1:0:0:0:1/64   ! number FROM the delegated prefix

And it works end to end:

R2#show ipv6 general-prefix
IPv6 Prefix DELEGATED-FROM-R1, acquired via DHCP PD
  2001:DB8:AAAA::/64 Valid lifetime 3575, preferred lifetime 1775
   Ethernet0/1 (Address command)

R2#show ipv6 interface Ethernet0/1
    2001:DB8:AAAA::1, subnet is 2001:DB8:AAAA::/64 [CAL/PRE]

Read the chain: the router acquired 2001:DB8:AAAA::/64 via DHCP PD, stored it as the general prefix DELEGATED-FROM-R1, and its downstream interface E0/1 automatically got a global address (2001:DB8:AAAA::1) built from that prefix. The delegated prefix flowed from the ISP, through the customer router, onto a LAN interface - no manual addressing at any step.

General prefix: renumber a site in one line

The general prefix is worth dwelling on because it solves a real operational pain. In IPv4, if your ISP renumbers you, you touch every interface, every ACL, every static route with the old prefix in it. In IPv6 with a general prefix, you define the prefix once (from PD, or manually) and reference it by name on every interface:

interface Ethernet0/1
 ipv6 address DELEGATED-FROM-R1 ::1:0:0:0:1/64
interface Ethernet0/2
 ipv6 address DELEGATED-FROM-R1 ::2:0:0:0:1/64

Each interface's address is "the general prefix, plus this per-interface suffix". Change the general prefix - because the ISP renumbered you, or you switched providers - and every interface referencing it renumbers automatically. One change, whole site. And with DHCP PD feeding the general prefix, that change happens on its own when the delegation updates. This is IPv6 solving a problem IPv4 never could, and it is why PD + general prefix is the standard modern IPv6 edge design.

NPTv6: prefix translation without NAT's baggage

Sometimes you do need to translate IPv6 prefixes - most commonly for multihoming without provider-independent space, or to present a stable internal prefix while the external one changes. IPv4's answer is NAT, with all its stateful, connection-tracking, application-breaking overhead. IPv6 offers a cleaner tool: NPTv6 (Network Prefix Translation, RFC 6296).

NPTv6 is stateless and 1:1. It translates one prefix to another algorithmically - the internal 2001:DB8:1::/64 becomes external 2001:DB8:2::/64 by a checksum-neutral prefix rewrite, with the host portion untouched. Because it is stateless and 1:1, it does not break end-to-end connectivity the way IPv4 NAT does: every internal host still maps to exactly one external address, deterministically, and inbound connections work.

interface Ethernet0/0
 ipv6 nat
interface Ethernet0/1
 ipv6 nat
!
ipv6 nat prefix 2001:DB8:1::/64 ...        ! translate internal to external prefix

Platform note, honestly stated: NPTv6 support varies by IOS XE image, and on the lightweight virtual platform used for this lab it is not fully available. On a full IOS XE platform (cat8000v and similar) it is present. Rather than stage output we could not produce, we describe the mechanism accurately: NPTv6 is stateless, 1:1, checksum-neutral prefix translation. Where DHCPv6-PD and general prefixes are fully captured above (they work on the lab platform), NPTv6 is a concept-plus-platform-note - which is the honest position when a feature is image-dependent.

The design point stands regardless: NPTv6 is what you reach for when you would have used NAT in IPv4, and it is deliberately less harmful. Prefer provider-independent addressing where you can (so you translate nothing); use NPTv6 when you genuinely need prefix translation but want to keep the end-to-end model that makes IPv6 worth deploying.

When to use each

Key takeaways

• DHCPv6-PD delegates a whole prefix to a downstream router automatically - real end-to-end addressing, no NAT. A delegating router hands out prefixes; a requesting router uses them.
• Verified end to end: the delegating router handed 2001:DB8:AAAA::/64, the requesting router stored it as a general prefix, and its downstream interface was automatically numbered (2001:DB8:AAAA::1) from it.
• A general prefix lets you renumber an entire site by changing one value - every interface referencing it updates automatically. Pair it with PD for hands-off edge addressing.
• NPTv6 is stateless, 1:1, checksum-neutral prefix translation - what you use instead of NAT when you truly need prefix translation, and far less harmful to the end-to-end model. Its IOS XE support is image-dependent (concept + platform note here; DHCPv6-PD and general prefix are fully captured).
• Prefer provider-independent addressing so you translate nothing; use NPTv6 only when you must.

Next: expert services troubleshooting - NAT, DHCP, and SLA ticket scenarios. The full cluster index lives on the IPv6 pillar and the IP services pillar.