IPv4 has one way for a host to get an address. IPv6 has three, they can run at the same time, and the router only advises which to use — the host decides what it actually does. That combination produces a set of design choices with no IPv4 equivalent, and a set of failures where the network is configured exactly as intended and a large share of the devices on it have no IPv6 at all.
The choice is usually framed as automatic configuration against a server, as though it were the same decision as static against dynamic addressing in IPv4. It is not. The automatic mechanism is mandatory in the sense that every host implements it, and the server-based mechanism for addresses is optional in the sense that several significant platforms have never implemented it and have said they do not intend to.
This article covers how a host actually obtains an address, what the two advisory flags control and what they do not, which model to choose and on what grounds, why renumbering is far harder than it should be, and the deployments that leave devices with no IPv6 while looking entirely healthy. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
The flags in a router advertisement are advice rather than instruction, and a host that does not implement server-assigned addressing will ignore the managed flag entirely and configure itself or do nothing.How Does a Host Actually Get an Address?
What is the sequence?
The host builds a link-local address for itself immediately and checks that nobody else has it. It then listens for a router advertisement, or solicits one. If the advertisement contains a prefix marked for autoconfiguration, the host combines that prefix with a suffix it generates and checks that address too. If the advertisement advises using a server, a host that implements server-based addressing asks one. Each address is checked before use, and a host commonly ends up with several.
A Deeper Dive into Address Formation
The link-local address, which is not optional
Every interface has one, formed without any network involvement, and everything else depends on it. Neighbour discovery uses it, router advertisements are sourced from it, and the default gateway a host installs is a link-local address rather than a global one.
That last point is worth stating because it surprises people configuring routers: the gateway hosts use is the router's link-local address on that segment, not the global address configured on the interface. A global address on the router is for the router's own traffic and for management, not for being a gateway.
Where the suffix comes from
Historically from the hardware address, which made the suffix stable, globally unique and a permanent identifier for the device wherever it went. That property was recognised as a privacy problem and modern hosts generate the suffix differently — stable within a network but different on each network, so it cannot be used to track a device between them.
The consequence for operations is that the address no longer contains the hardware address, so a binding between the two has to come from the switch's own records rather than from reading the address. Anything that assumed otherwise — an access list, a monitoring correlation — stops working on modern hosts.
Temporary addresses
Hosts also generate short-lived addresses used as the source for outgoing connections, replaced every few hours. The stable address remains for incoming connections; the temporary ones exist so that a remote site cannot correlate a user's activity over time.
They are enabled by default on the major client platforms. Every count of addresses per host, every binding table limit and every attempt to attribute a log entry to a device has to account for them, and a design built on the assumption of one address per host will be wrong by a factor of three or four.
! What one laptop actually holds
! Linux:
ip -6 addr show dev eth0
! fe80::... link-local, permanent
! 2001:db8:10::... stable global
! 2001:db8:10::... temporary, preferred
! 2001:db8:10::... temporary, deprecated
!
! And what the router sees of it
R1# show ipv6 neighbors vlan 10
R1# show ipv6 interface Vlan10 | include link-local|Joined
Duplicate detection
Every address is checked before it is used, by asking whether anybody already holds it. If anybody answers, the host does not use that address, and for a link-local address that leaves the interface unusable for IPv6 entirely.
This is normally invisible and becomes visible in two situations: a genuine duplicate, which is rare with modern suffix generation, and a network element that answers on behalf of addresses it does not hold, which makes the host believe every address it tries is taken.
! Duplicate detection: one attempt by default, on every address
R1(config)# interface Vlan10
R1(config-if)# ipv6 nd dad attempts 1
!
! A duplicate on the link-local address disables IPv6 on the port
R1# show ipv6 interface Vlan10 | include DAD|duplicate|link-local
IPv6 is enabled, link-local address is FE80::1
ND DAD is enabled, number of DAD attempts: 1
!
R1# show logging | include DUPLICATE
The lifetimes attached to each address
Two of them. A preferred lifetime, during which the address is used for new connections, and a valid lifetime, after which it is removed entirely. Between the two the address still works for existing connections but is no longer chosen for new ones.
Both come from the router advertisement and both matter for renumbering, covered later. The second one is the constraint: an address remains usable for its valid lifetime and there is no straightforward way to shorten that once hosts have accepted it.
! The router side: prefix, lifetimes, and DNS in the advertisement
R1(config)# ipv6 unicast-routing
!
R1(config)# interface Vlan10
R1(config-if)# ipv6 address 2001:DB8:10::1/64
R1(config-if)# ipv6 nd prefix 2001:DB8:10::/64 2700 1800
R1(config-if)# ipv6 nd ra dns server 2001:DB8::53 900
R1(config-if)# ipv6 nd ra interval 60
R1(config-if)# ipv6 nd ra lifetime 180
!
! Hosts now have everything with no server involved at all
R1# show ipv6 interface Vlan10 | section ND
| Address | Formed from | Lifetime | Used for |
|---|---|---|---|
| Link-local | Self, no network input | Permanent | Everything internal, including the gateway |
| Stable global | Advertised prefix + generated suffix | As advertised | Incoming connections |
| Temporary | Advertised prefix + random suffix | Hours | Outgoing connections |
| Server-assigned | A server chose it | The lease | Everything, where used |
What Do the Flags Really Control?
How much authority do they have?
None, strictly. The flags in a router advertisement are advice: one says addresses should come from a server, the other says other settings should. A host is free to act on them or not, and the behaviour varies by platform. The flag with real effect is the one attached to the prefix, telling hosts to build an address from it — that one every implementation honours, which makes it the reliable lever and the others advisory.
A Deeper Dive into the Flags
The prefix flag, which works
A prefix advertised with the autoconfiguration flag set causes every host that receives it to build an address. This is the mechanism that is genuinely universal, and it is why a segment with a router advertising a prefix has working IPv6 on every device without anything else being configured.
Clearing that flag advertises the prefix as present on the link without offering address configuration, which is the correct setting when addresses are to come from a server. Leaving it set alongside a server-based model produces hosts with both kinds of address.
The managed flag, which is a suggestion
It advises hosts to obtain addresses from a server. Hosts that implement server-based addressing act on it. Hosts that do not simply ignore it, and if the prefix flag was cleared as well, those hosts end up with no global address at all.
That combination — addresses from a server only — is the one that produces a segment where some devices have IPv6 and others silently do not. The devices without it continue working over IPv4, so nothing is reported and the design appears to be functioning.
The other flag
It advises hosts to obtain settings other than addresses from a server: name servers, a search domain, and similar. A host builds its own address and asks a server for the rest.
This combination is widely supported and is the practical middle ground. It keeps address assignment on the mechanism everything implements while allowing the settings that benefit from central management to come from a server.
! Autoconfigured addresses, other settings from a server
R1(config)# ipv6 dhcp pool STATELESS
R1(config-dhcpv6)# dns-server 2001:DB8::53
R1(config-dhcpv6)# dns-server 2001:DB8::54
R1(config-dhcpv6)# domain-name example.com
!
R1(config)# interface Vlan10
R1(config-if)# ipv6 nd prefix 2001:DB8:10::/64 2700 1800
R1(config-if)# ipv6 nd other-config-flag
R1(config-if)# ipv6 dhcp server STATELESS
!
! Note: no managed flag. Addresses stay autoconfigured.
R1# show ipv6 dhcp pool
R1# show ipv6 interface Vlan10 | include config flag
Setting both address mechanisms
A prefix marked for autoconfiguration alongside the managed flag tells hosts to do both. A host that implements both ends up with a self-built address and a server-assigned one, which is legal, wasteful and confusing to operate — the device appears twice in every record, with two addresses that have different lifetimes and different behaviour.
It is almost always a mistake arising from adding the server-based mechanism without clearing the prefix flag. Where the intent is server-assigned addressing, the prefix flag must be cleared in the same change.
Getting name servers to hosts
Two routes. The advertisement itself can carry name server addresses, which works with no server at all and is supported on every current client platform. Or a server can supply them, which requires the other flag and a server.
The first is simpler and it is the one that makes a segment fully functional with nothing but a router. Where a server already exists for other reasons, using it is reasonable; where one would have to be introduced solely for name servers, the advertisement is the better answer.
! Clear the prefix flag when the server owns addressing
R1(config)# interface Vlan10
R1(config-if)# ipv6 nd prefix 2001:DB8:10::/64 2700 1800 no-autoconfig
R1(config-if)# ipv6 nd managed-config-flag
R1(config-if)# ipv6 nd other-config-flag
R1(config-if)# ipv6 dhcp server STATEFUL
!
R1(config)# ipv6 dhcp pool STATEFUL
R1(config-dhcpv6)# address prefix 2001:DB8:10:0:A::/80 lifetime 3600 1800
R1(config-dhcpv6)# dns-server 2001:DB8::53
R1(config-dhcpv6)# domain-name example.com
Which Model Should You Choose?
What decides it?
Whether every device on the segment must have IPv6. If it must, the model has to be one that every platform implements, which means autoconfigured addresses — optionally with a server supplying the other settings. Server-assigned addressing is appropriate on segments where the device population is known and controlled, such as a data centre, and it is the wrong choice on a user segment carrying whatever people bring with them.
A Deeper Dive into the Choice
The platform that does not implement it
One widely used mobile platform has never implemented server-based address assignment and its maintainers have stated that they do not intend to, on the grounds that the autoconfiguration mechanism is sufficient and mandatory. Whatever one thinks of that position, it is a fact to design around.
The practical effect on a corporate wireless network is direct: a server-assigned model gives IPv6 to the laptops and not to a large share of the phones and tablets. Those devices use IPv4, everything they do continues to work, and nothing anywhere reports a problem.
What is actually being given up
The usual argument for server-assigned addressing is control: known addresses, a record of who has what, and reservations for specific devices. Those are real benefits in IPv4 and they are weaker here.
Records are available from the switch's binding table regardless of how the address was obtained, so the audit trail does not depend on the assignment model. Reservations depend on a client identifier that is not the hardware address and that changes when an operating system is reinstalled, which makes them less stable than the IPv4 equivalent. The control being purchased is smaller than it appears.
Where server-assigned addressing is right
A data centre segment where every device is a server under your control and the address genuinely needs to be known and stable. A segment with a regulatory requirement for assignment records that must come from a server specifically. And any case where the device population is enumerated rather than arbitrary.
In those places the platform limitation does not arise, because the platforms in question are not present. That is the distinction: it is a controlled-population mechanism.
The combination that works everywhere
Autoconfigured addresses, with name servers supplied either in the advertisement or by a stateless server. Every platform gets an address, every platform gets name servers, and there is no dependency on any client choosing to cooperate.
This is the recommendation for user segments and it is not a compromise. It is the model the address architecture was designed around, with the one genuinely missing piece — name servers — solved by an option in the advertisement that current clients all support.
Prefix delegation, which is a different question
A router obtaining a block of address space from an upstream provider, to divide among its own segments, uses the server-based mechanism for that purpose. This is unrelated to how hosts get addresses and is not affected by the client platform question, because the client here is a router.
It is the normal arrangement for a branch obtaining space from an internet provider, and the resulting prefix is then advertised to the branch's segments by whichever host model was chosen. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
! The branch router obtains a block, then advertises from it
R1(config)# interface GigabitEthernet0/0
R1(config-if)# description To the provider
R1(config-if)# ipv6 enable
R1(config-if)# ipv6 dhcp client pd BRANCH-PREFIX
!
R1(config)# interface Vlan10
R1(config-if)# ipv6 address BRANCH-PREFIX ::10:0:0:0:1/64
R1(config-if)# ipv6 nd prefix default 2700 1800
!
R1# show ipv6 dhcp interface GigabitEthernet0/0
R1# show ipv6 general-prefix
| Model | Addresses from | Other settings from | Suits |
|---|---|---|---|
| Pure autoconfiguration | The advertisement | The advertisement | Simple segments, no server |
| Autoconfiguration + stateless server | The advertisement | A server | User segments, everywhere |
| Server-assigned | A server | A server | Controlled populations only |
| Both mechanisms | Both | A server | Nothing — usually an error |
| Prefix delegation | A server, to a router | — | Obtaining space from a provider |
Why Is Renumbering So Hard?
What is the obstacle?
A prefix is advertised with a valid lifetime, and hosts keep addresses built from it for that lifetime. To protect against an attacker shortening lifetimes maliciously, hosts refuse to accept a drastic reduction from an unauthenticated advertisement — the lifetime can only be brought down so far so fast. So a prefix advertised with a long lifetime cannot simply be withdrawn: the addresses persist on hosts whatever the router says afterwards.
A Deeper Dive into Lifetimes
Where the long default came from
Early guidance suggested lifetimes measured in weeks, on the reasoning that a prefix is stable and frequent re-advertisement is wasteful. That reasoning was sound in isolation and it makes renumbering impractical, because a host holding an address with weeks of validity will keep trying to use it long after the network has moved on.
Current guidance is much shorter — lifetimes measured in tens of minutes rather than weeks — precisely so that a change can propagate in a reasonable time. It costs a small amount of multicast traffic and buys the ability to renumber.
What happens during a renumber
The new prefix is advertised alongside the old one. Hosts build addresses from both. The old prefix's preferred lifetime is reduced so that new connections use the new address while existing ones continue on the old. Eventually the old prefix's valid lifetime expires and its addresses are removed.
That sequence works well when the lifetimes are short. With long lifetimes the final step takes as long as the original lifetime, during which hosts hold addresses in a range that may no longer be routed.
The protection that gets in the way
The rule preventing a drastic reduction exists because an attacker able to shorten lifetimes could remove addresses from hosts at will. It is a reasonable protection and it means a mistake cannot be undone quickly.
The practical consequence: advertise a thirty-day lifetime by accident and you cannot bring it down to five minutes by correcting the configuration. The reduction is limited, and the addresses persist. There is no command that fixes this on the network side.
Choosing lifetimes
Short enough that a change propagates within an acceptable window, long enough that a brief loss of advertisements does not remove addresses from hosts. Tens of minutes for the valid lifetime and somewhat less for the preferred lifetime is the current recommendation and is a large change from older defaults.
The interaction to be aware of is with the advertisement interval: if advertisements are sent every few minutes and the lifetime is tens of minutes, several advertisements can be missed without consequence. A lifetime shorter than a few advertisement intervals makes the segment fragile.
! Short lifetimes, so renumbering is possible at all
R1(config)# interface Vlan10
R1(config-if)# ipv6 nd prefix 2001:DB8:10::/64 2700 1800
R1(config-if)# ipv6 nd ra interval 60
R1(config-if)# ipv6 nd ra lifetime 180
!
! Deprecate a prefix: preferred 0, so it is no longer chosen
R1(config-if)# ipv6 nd prefix 2001:DB8:OLD::/64 2700 0
!
! And the new one alongside it
R1(config-if)# ipv6 nd prefix 2001:DB8:NEW::/64 2700 1800
!
R1# show ipv6 interface Vlan10 | section prefix
Renumbering in practice
Add the new prefix while the old one is still advertised. Confirm hosts have addresses from both. Deprecate the old prefix by advertising it with a zero preferred lifetime, which stops new connections using it without removing it. Wait for existing connections to finish. Then stop advertising it, and wait out the valid lifetime.
The whole sequence is comfortable with short lifetimes and impractical with long ones, which is why the lifetime decision made at deployment determines whether renumbering is a maintenance activity or a project.
What breaks alongside the addresses
Anything referring to an address in the old range: access lists, firewall rules, monitoring targets, name records. Those are not governed by lifetimes and have to be changed by hand or by tooling.
The address change is the easy part. This is the argument for using provider-independent space where that is available, or for keeping internal references to names rather than addresses wherever possible.
Which Deployments Leave Devices Without IPv6?
What should be checked?
Four things. A server-assigned model on a segment carrying devices that do not implement it. An advertisement reaching hosts while the server's replies do not, because a relay was not configured. Both mechanisms enabled at once, producing two addresses per device. And a filtering or first hop security control discarding the very messages the mechanism depends on. In every case the affected devices continue working over IPv4 and nobody reports anything.
A Deeper Dive into Silent Failures
Why nothing is reported
A dual-stack host with no IPv6 address uses IPv4 for everything and works. The user notices nothing, the application team notices nothing, and the only evidence is in records nobody reads unless they are looking.
That makes verification a deliberate activity rather than something that happens when something breaks. A deployment that is never verified is indistinguishable from one that works.
The missing relay
Where the server is not on the segment, the router must relay requests to it. Requests are sent to a multicast address that does not leave the segment, so without a relay the server never hears them and no host is ever answered.
The advertisement still arrives, because the router sends it. So hosts are told to ask a server, they ask, and nothing answers. On a server-assigned model that leaves them with no global address at all.
! Requests do not leave the segment on their own
R1(config)# interface Vlan10
R1(config-if)# ipv6 dhcp relay destination 2001:DB8::67
!
! Confirm the relay is configured and requests are going somewhere
R1# show ipv6 dhcp interface Vlan10
Vlan10 is in relay mode
Relay destinations:
2001:DB8::67
!
R1# show ipv6 dhcp relay binding
The security control discarding the mechanism
An access layer configured to discard router advertisements on ports where no router should be is correct and necessary. Applying that policy to the uplink discards the legitimate router's advertisements, and every host on the switch loses its ability to configure an address.
The same applies to server messages: a policy discarding them on client ports is correct, and the same policy on the path toward the server prevents replies from reaching anyone. Both are covered in detail elsewhere; they belong in this list because they are a common cause of devices with no address.
Counting what should be there
The check is arithmetic. Count the devices associated to the segment, count the global addresses in the binding table, and compare. On a healthy segment the second is several times the first, because of temporary addresses. A ratio near or below one means devices are missing addresses.
That single comparison catches every failure in this section and takes one command per side. It is the verification that should follow any IPv6 deployment and it is almost never performed.
! The comparison that catches everything in this section
Sw1# show device-tracking database vlan 10 | count ND
Sw1# show mac address-table vlan 10 | count DYNAMIC
!
! Expect several global addresses per device, not fewer.
! A ratio near 1 means devices have no global address.
!
Sw1# show device-tracking database vlan 10 | count FE80
Sw1# show device-tracking database vlan 10 | count 2001
Attribution, once temporary addresses exist
A log entry naming an address that rotated four hours ago cannot be attributed to a device without a record of which device held that address at that time. The binding table holds the current state; attributing historical activity needs that state to have been recorded as it changed.
This is a real operational gap in many deployments and it is worth solving before it is needed. Exporting binding table changes to a collector, or enabling accounting that records the association, turns an unanswerable question into a lookup.
! Record the association as it changes, not just its current value
Sw1(config)# device-tracking binding logging
Sw1(config)# logging host 10.200.0.40
Sw1(config)# service timestamps log datetime msec localtime show-timezone
!
! The current state is easy; the history is what attribution needs
Sw1# show device-tracking database address 2001:DB8:10::A4F2:19C3:1D77:3E90
Sw1# show logging | include SISF|device-tracking
A verification list
Five checks. Devices have global addresses, in the expected multiple. The name servers reaching hosts are the intended ones. The prefix and flags advertised are what the design specifies. The lifetimes are short enough to renumber. And the binding table's history is being recorded somewhere for attribution.
All five are quick and the first is the one that matters most, because everything else is moot on a device with no address.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers IPv6 addressing and address assignment within its infrastructure services domain. What is examined is generally the mechanism — what the flags advise, where the suffix comes from, and the distinction between the stateless and stateful models — rather than a full deployment.
| Symptom | Cause | Check |
|---|---|---|
| Some device types have no IPv6 | Server-assigned model | Address count against device count |
| No device has a global address | Advertisements not arriving | Guard policy on the uplink |
| Hosts ask and nothing answers | No relay configured | Relay destination on the segment |
| Two global addresses per device | Both mechanisms enabled | Prefix flag alongside managed flag |
| Addresses persist after a change | Long valid lifetime | Advertised lifetimes |
| Cannot attribute a log entry | Temporary addresses, no history | Binding table export |
Conclusion
Three mechanisms can supply an address and they can run together, with the router advising rather than instructing. Only one flag has universal effect: the one on the prefix, telling hosts to build an address from it. The flag advising hosts to use a server is a suggestion that several widely deployed platforms decline, which makes a server-assigned model on a user segment a decision to have no IPv6 on a large share of the devices carried into the building each morning.
For a user segment the answer is autoconfigured addresses, with name servers supplied either in the advertisement or by a stateless server. Every platform gets an address, every platform gets name servers, and nothing depends on a client choosing to cooperate. Server-assigned addressing belongs where the device population is enumerated — a data centre — and the control it buys elsewhere is smaller than it looks, because the audit record comes from the switch regardless of how the address was obtained.
The decision that cannot be undone is the lifetime. A prefix advertised with a long valid lifetime cannot be withdrawn quickly, because hosts refuse a drastic reduction from an unauthenticated advertisement — a protection that is correct and that turns a five-minute mistake into a multi-week one. Short lifetimes from the first day are what make renumbering an afternoon's work rather than a project. And because a device with no IPv6 address simply carries on over IPv4, none of this reports itself: count the global addresses against the device count after every deployment, because that comparison is the only thing that will tell you. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 4862 — IPv6 Stateless Address Autoconfiguration
- RFC 8415 — Dynamic Host Configuration Protocol for IPv6
- RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration
- RFC 7217 — A Method for Generating Stable Interface Identifiers
- RFC 8981 — Temporary Address Extensions for SLAAC
- RFC 9096 — Improving the Reaction of CPE Routers to IPv6 Renumbering
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 4862 specifies stateless address autoconfiguration, in which a host forms an address by combining an advertised prefix with an interface identifier it generates.
- RFC 4862 defines the preferred and valid lifetimes of an autoconfigured address, during which it may be used for new connections and after which it is removed.
- RFC 4862 restricts the extent to which a host will reduce an address's remaining valid lifetime in response to an unauthenticated router advertisement, in order to limit denial of service.
- RFC 4862 specifies duplicate address detection, performed before any address including the link-local address is used.
- RFC 4861 defines the managed and other configuration flags carried in router advertisements, and the autonomous flag carried in the prefix information option.
- RFC 8415 specifies DHCP for IPv6, including non-temporary address assignment, prefix delegation, and the client identifier used to identify a client.
- RFC 8415 specifies that clients send messages to a link-scoped multicast address, which requires a relay agent where the server is not on the same link.
- RFC 8106 defines router advertisement options carrying recursive name server addresses and a search list, allowing name resolution to be configured without a DHCP server.
- RFC 7217 specifies a method for generating interface identifiers that are stable within a network and differ between networks, replacing identifiers derived from the hardware address.
- RFC 8981 specifies temporary addresses generated and replaced periodically by hosts, used as the source address for outgoing connections.
- RFC 9096 recommends substantially shorter prefix lifetimes than earlier practice, in order to make renumbering feasible within a reasonable period.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include IPv6 addressing and address assignment within the infrastructure services domain.