The first hop security features for IPv6 look like the IPv4 ones with different names, and that resemblance is misleading in both directions. The structure is the same — a table of what belongs where, and enforcement points that read it — but what fills the table is different, what churns it is different, and the most damaging failure has no IPv4 equivalent at all.
The difference that drives everything is that IPv6 hosts configure themselves. They do not have to ask anything for an address; they listen for a router advertisement and build one. So the highest-value control is not about address assignment at all, it is about who is permitted to claim to be a router — and the most common rogue router is not an attacker, it is a laptop with connection sharing enabled or a hypervisor that was configured carelessly.
This article covers why IPv6 needs a different set of controls, what populates the binding table and what makes it churn, which guard does which job, what the tracking underneath them does to hosts that did not expect it, and a deployment order that does not take a floor offline. 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.
Most binding entries arrive by gleaning rather than by observing an assignment, a single host legitimately holds several addresses at once, and the two guards worth deploying first do not depend on the table at all.Why Does IPv6 Need a Different Set of Controls?
What is structurally different?
Hosts configure themselves. A device on an IPv6 segment listens for a router advertisement and builds a global address from it, with no server involved and nothing to authorise the exchange. So the highest-impact attack — and the most common accident — is a device that advertises itself as a router, which immediately becomes the default gateway for every host that hears it. There is no IPv4 equivalent, because in IPv4 a host that has not been given a gateway simply has none.
A Deeper Dive into the Differences
The rogue router, which is usually an accident
A laptop with connection sharing switched on, a hypervisor whose virtual switch was attached to the wrong network, a consumer router plugged into a wall port by somebody being helpful. Each of these advertises itself as a router without anyone intending it, and hosts on the segment believe it because belief is the specification.
The effect is immediate and total for the hosts that hear it: their default gateway becomes a device that cannot forward anything useful. And because IPv4 continues to work, the symptom presented to the service desk is that some applications are slow or that one particular site does not load, which takes considerably longer to attribute than a complete outage would.
Addresses that a host invents
A host derives its own addresses. It always has a link-local address, it may build a global one from each advertised prefix, and it may generate temporary addresses that rotate every few hours for privacy. Four or five simultaneous addresses for one device is entirely normal.
Two consequences for the table. Its size is a multiple of the host count rather than equal to it. And a per-port address limit chosen by IPv4 intuition — two or three — will block legitimate traffic on any modern operating system, because the temporary addresses alone will exceed it.
No assignment exchange to watch
The IPv4 mechanism works by observing a client accept an address from a server. In IPv6 there frequently is no server, so the table is populated by gleaning: the switch observes the neighbour discovery messages a host sends when it brings an address into use and records what it saw.
Gleaning is less authoritative than observing an assignment. The switch is recording what the host claimed rather than what a server granted, which means the table's contents are only as trustworthy as the enforcement preventing hosts from claiming things they should not — and that enforcement reads the table. The circularity is real and is resolved by the two guards that do not depend on the table at all.
Which is why the order matters
Router advertisement filtering and address server filtering are both stateless. They examine a message and decide, with no table involved, and they can be deployed immediately with essentially no risk of blocking legitimate traffic. Between them they address the two highest-impact problems.
Everything that reads the table comes afterwards, once the table is populated and understood. Deploying in the other order — enforcement first, table later — is the standard way to disconnect a floor.
What carries over unchanged
The trust boundary. Ports facing other switches and ports facing legitimate routers and servers are trusted; ports facing users are not. This is the same rule as the IPv4 features and it produces the same failure when it is applied late: an untrusted uplink means the legitimate router's advertisements are discarded and every host on the switch loses its gateway.
| Question | IPv4 | IPv6 | Consequence |
|---|---|---|---|
| How does a host get an address? | A server assigns it | It builds one from an advertisement | Rogue router is the main threat |
| How many addresses per host? | One | Four or five, normally | Per-port limits must be higher |
| How is the table filled? | Watching an assignment | Mostly gleaning | Entries are claims, not grants |
| Do addresses change? | On lease renewal | Temporary ones rotate hourly | The table churns constantly |
| Highest value control | Assignment snooping | Advertisement filtering | Different first step |
What Builds the Binding Table, and What Churns It?
Where do entries come from?
Four sources. Gleaning from neighbour discovery, which is how most entries arrive: the switch watches a host bring an address into use and records it. Observing a server assignment, where one is in use. The IPv4 half of a dual-stack deployment, since the same table holds both. And static entries for devices that do neither. What churns it is temporary addresses, which hosts generate and retire on a cycle of hours, producing constant turnover that has no IPv4 equivalent.
A Deeper Dive into the Table
Gleaning, and what it records
When a host brings an address into use it announces it, to check that nobody else has it. The switch sees that message and creates an entry binding the address to the hardware address, the VLAN and the port. That is the entry the enforcement features will later consult.
The important property is that nothing authorised it. The host said so and the switch believed it, which is why gleaning is described as a security level below inspection: the table is being populated from unverified claims, and tightening that is what the higher levels do.
! A policy that only learns, without enforcing anything
Sw1(config)# device-tracking policy DT-LEARN
Sw1(config-device-tracking)# security-level glean
Sw1(config-device-tracking)# device-role node
Sw1(config-device-tracking)# limit address-count 12
Sw1(config-device-tracking)# no protocol udp
!
! Attach to client ports, and a trusted policy to uplinks
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# device-tracking attach-policy DT-LEARN
! Uplinks and ports facing routers: trusted, and a switch role
Sw1(config)# device-tracking policy DT-TRUNK
Sw1(config-device-tracking)# security-level glean
Sw1(config-device-tracking)# device-role switch
Sw1(config-device-tracking)# trusted-port
Sw1(config-device-tracking)# tracking disable
!
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# device-tracking attach-policy DT-TRUNK
The address limit, and why the IPv4 number is wrong
A per-port limit exists to stop one device exhausting the table. Choosing it by IPv4 intuition produces a number around two or three, and a single modern laptop will exceed that with its link-local address, its advertised global address, and two temporary addresses in rotation.
A limit in the low tens is appropriate for a port serving one device, and higher where a port feeds a small switch or a virtualised host. Exceeding the limit drops the newest entries, so the symptom is a device that works and then loses connectivity when its temporary address rotates — which is intermittent, periodic, and very hard to attribute.
Reading the table
Entries show the address, the hardware address, the port, the VLAN, how the entry was learned and its current state. The learning method is the field worth attending to: an entry created by gleaning is a claim, an entry created from an observed assignment is a grant, and a static entry is a decision.
The state field matters too. An entry moves between reachable, stale and down as the switch verifies it, and an entry stuck in an unverified state usually indicates the probing problem described in a later section rather than anything about the host.
! The table, and how each entry got there
Sw1# show device-tracking database
Network Layer Address Link Layer Address Interface vlan prlvl state
ARP 10.10.10.51 001b.4411.3ab7 Gi1/0/12 10 0005 REACHABLE
ND 2001:DB8:10::51 001b.4411.3ab7 Gi1/0/12 10 0005 REACHABLE
ND 2001:DB8:10::a4f2:19c3:... 001b.4411.3ab7 Gi1/0/12 10 0005 REACHABLE
ND FE80::21B:44FF:FE11:3AB7 001b.4411.3ab7 Gi1/0/12 10 0005 REACHABLE
!
! Per-interface view, including the count against the limit
Sw1# show device-tracking database interface GigabitEthernet1/0/12
Sw1# show device-tracking policies
Churn, and what it costs
Temporary addresses rotate, so entries are created and retired continuously on every port. On an access switch with hundreds of hosts this is a steady background rate of table changes that does not exist in IPv4 and that consumes processing on the switch.
It is normally harmless and becomes relevant in two situations: a platform whose table capacity is modest relative to the host count, and a design that logs every table change to a central collector, where the volume is considerably larger than expected. Both are worth checking before deployment rather than after.
Static entries, and who needs them
Anything whose address the switch will never observe being brought into use — a device that was already running when tracking was enabled and will not re-announce, or a device with an unusual stack. These need an entry created by hand, exactly as in IPv4.
The population is smaller than in IPv4 because gleaning catches devices that never speak to any server, which is the category that required manual work there. That is one of the few places where the IPv6 version of this is less effort.
Which Guard Does Which Job?
How do they divide up?
Two are stateless and examine a message type directly: advertisement filtering decides who may claim to be a router, and server filtering decides who may hand out addresses. Three consult the binding table: neighbour message inspection rejects claims that contradict it, source enforcement rejects traffic from addresses not in it, and destination enforcement rejects traffic aimed at addresses nobody holds. The first two carry almost no deployment risk; the last three carry all of it.
A Deeper Dive into the Guards
Advertisement filtering
Discards router advertisements arriving on ports that are not supposed to have routers behind them. It is stateless, immediate and it solves the single largest real problem on an IPv6 access layer. A port declared as facing a host discards advertisements outright; a port declared as facing a router accepts them, optionally after checking the advertised prefix and flags against a policy.
The deeper policy options — matching prefixes, constraining the flags that tell hosts how to configure themselves, requiring a minimum hop limit — are worth applying on the ports that do face routers, because they catch a misconfigured legitimate router as well as a hostile one.
! Client ports: no router advertisements at all
Sw1(config)# ipv6 nd raguard policy RA-HOST
Sw1(config-nd-raguard)# device-role host
!
! Uplinks: accept them, but check what they say
Sw1(config)# ipv6 nd raguard policy RA-ROUTER
Sw1(config-nd-raguard)# device-role router
Sw1(config-nd-raguard)# trusted-port
Sw1(config-nd-raguard)# match ipv6 access-list RA-SOURCES
Sw1(config-nd-raguard)# hop-limit minimum 255
!
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ipv6 nd raguard attach-policy RA-HOST
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# ipv6 nd raguard attach-policy RA-ROUTER
Address server filtering
The same idea applied to the address assignment protocol: a port declared as facing clients discards server messages, and a port facing a server accepts them. Where an address server is in use this closes the second obvious attack and also catches the accidental case — a device running a server nobody knew about.
It is worth deploying even in a network that uses no address server at all, because in that case every server message on the segment is by definition illegitimate and the policy is trivially correct.
! Clients may not answer as servers
Sw1(config)# ipv6 dhcp guard policy DHCP-CLIENT
Sw1(config-dhcp-guard)# device-role client
!
! The path to the real server, with a check on who it is
Sw1(config)# ipv6 dhcp guard policy DHCP-SERVER
Sw1(config-dhcp-guard)# device-role server
Sw1(config-dhcp-guard)# trusted-port
Sw1(config-dhcp-guard)# match server access-list DHCPV6-SERVERS
Sw1(config-dhcp-guard)# preference min 100
!
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ipv6 dhcp guard attach-policy DHCP-CLIENT
Neighbour message inspection
The IPv6 counterpart of address-resolution inspection. Neighbour messages are checked against the binding table and discarded when they contradict it, which prevents a device claiming an address that belongs to something else — including the gateway.
It depends entirely on the table, which means it must not be enabled until the table is populated and the devices that will never appear in it have been given entries. Enabling it early produces exactly the isolation that the IPv4 equivalent produces when deployed in the wrong order.
Source and destination enforcement
Source enforcement discards traffic whose source address is not bound to the port it arrived on. Destination enforcement discards traffic aimed at addresses that no device on the segment holds, which addresses a specific IPv6 problem: a scan of a large prefix causes the router to attempt resolution for every address in it and exhausts its neighbour cache.
That second one belongs on routers rather than on access switches and is genuinely useful, because the prefix sizes involved in IPv6 make the exhaustion attack trivially cheap to mount and expensive to absorb.
! Source enforcement on client ports, once the table is trusted
Sw1(config)# ipv6 source-guard policy SG-CLIENT
Sw1(config-sisf-sourceguard)# deny global-autoconf
Sw1(config-sisf-sourceguard)# permit link-local
!
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ipv6 source-guard attach-policy SG-CLIENT
!
! Destination enforcement, on the router, against cache exhaustion
R1(config)# ipv6 destination-guard policy DG-POLICY
R1(config-destguard)# enforcement always
R1(config)# vlan configuration 10
R1(config-vlan-config)# ipv6 destination-guard attach-policy DG-POLICY
Attaching to a VLAN rather than a port
Policies can be attached to a VLAN, which applies them to every port carrying it. That is convenient and it is also how an uplink accidentally receives a client policy, because the uplink carries the VLAN too.
Where a VLAN attachment is used, the trusted ports need an explicit port-level policy that overrides it. Port attachment takes precedence, so this works — but it has to be done deliberately, and forgetting it is the fastest route to discarding the legitimate router's advertisements. 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.
| Guard | Threat it addresses | Needs the table | Belongs on |
|---|---|---|---|
| Advertisement filtering | A device claiming to be the gateway | No | Every access port |
| Server filtering | A device handing out addresses | No | Every access port |
| Neighbour inspection | A device claiming another's address | Yes | Access ports, after the table |
| Source enforcement | Traffic with a forged source | Yes | Access ports, last |
| Destination enforcement | Neighbour cache exhaustion | Yes | Routers, not access switches |
What Does the Tracking Do to Hosts That Did Not Expect It?
What is the problem?
To keep entries accurate, the switch periodically probes hosts to confirm an address is still in use. Some host implementations interpret that probe as another device claiming their address, run their duplicate-detection procedure, conclude the address is taken and stop using it. The host then has no working IPv6 address and continues on IPv4, so the fault is reported days later as "IPv6 stopped working" with nothing to correlate it to.
A Deeper Dive into Tracking Behaviour
Why the probing exists
An entry that is never verified becomes wrong when a device moves or is unplugged, and a stale entry either blocks the device that legitimately has that address now or permits a device that should not. Probing keeps the table accurate and it is the correct default for a table that enforcement depends on.
The trade is that probing is an active behaviour aimed at hosts, and hosts vary in how they interpret it. This is the one place in the first hop security family where the switch's default behaviour can break a correctly configured host that is doing nothing wrong.
Which hosts are affected
It varies by operating system, by version and by network stack, and it is not predictable from documentation. Some clustering and load-balancing implementations are also sensitive, because they deliberately share an address between machines and the probe interacts badly with that arrangement.
The practical approach is to test rather than to predict: enable tracking on a small set of ports covering each operating system in the estate, leave it for a few days, and look for hosts that lost IPv6. That is a cheaper investigation than the alternative, which is the same investigation conducted across a building with users involved.
The settings that control it
Probing can be disabled entirely, which keeps the table populated by gleaning alone at the cost of accuracy. It can be adjusted so that the probe is sent in a form less likely to be misread. And the lifetimes governing how long an entry is considered valid without verification can be extended, which reduces how often probing happens.
Disabling it is the blunt answer and it is the right one on ports where the affected host types live, provided the enforcement features on those ports are chosen accordingly. A table that is not verified should not be the basis for source enforcement.
! Where the host type is known to react badly
Sw1(config)# device-tracking policy DT-NOPROBE
Sw1(config-device-tracking)# security-level glean
Sw1(config-device-tracking)# tracking disable
Sw1(config-device-tracking)# limit address-count 12
!
! Or keep probing, but less often
Sw1(config)# device-tracking policy DT-SLOW
Sw1(config-device-tracking)# tracking enable reachable-lifetime 600
Sw1(config-device-tracking)# limit address-count 12
!
! What the switch is doing to each entry
Sw1# show device-tracking database details
Sw1# show device-tracking counters interface GigabitEthernet1/0/12
The implicit policy
Tracking is switched on underneath the guards rather than as a separate decision — enabling a feature that needs the table causes a default policy to be applied. So a deployment that only intended to filter router advertisements can end up probing hosts, with the settings nobody chose, on ports nobody thought about.
The defence is to define an explicit policy and attach it deliberately everywhere, rather than letting defaults appear. An explicit policy with the settings you chose is also visible in the configuration, where a default one is not.
! Find the policies that were applied without being configured
Sw1# show device-tracking policies
Target Type Policy Feature Target range
Gi1/0/12 PORT default Device-tracking vlan all
Te1/0/1 PORT DT-TRUNK Device-tracking vlan all
!
! And what the default one actually does
Sw1# show device-tracking policy default
Upgrading from the older feature set
Platforms that ran the previous generation of these features convert the configuration on upgrade. The conversion is generally correct and it produces policy names and defaults that were not chosen by anybody, which then behave differently from what the previous configuration did.
After any such upgrade, the policy list is worth reading rather than assuming. This is the same class of finding as the implicit policy above and it arrives at the moment when nobody is looking for it.
What to check before enabling anything table-dependent
The table has roughly the expected number of entries for the host count, allowing several per host. The address limit is not being hit on any port. Probing behaviour has been tested against each operating system present. And the policy applied to every port is one that was explicitly configured rather than a default.
Four checks, and each one corresponds directly to a failure described in this article.
How Should This Be Deployed and Verified?
What is the order?
Advertisement filtering first, with the uplink given a router-role policy in the same change. Then server filtering, the same way. Then an explicit tracking policy that learns without enforcing, left to populate for a week while probing behaviour is observed. Then static entries for whatever never appears. Then neighbour inspection on one VLAN with the counters open. Then source enforcement, one wiring closet at a time. The first two steps are safe; everything after the third can take a floor offline.
A Deeper Dive into the Deployment
Why the first two steps are different
They are stateless. A router advertisement arriving on a client port is illegitimate regardless of any table, and so is a server message. There is no population to wait for and no completeness to establish, so the change can be made and verified in one window.
They also deliver the majority of the real benefit, because the rogue gateway and the rogue address server are what actually happens on enterprise networks. A deployment that does only these two steps and stops is a substantially safer network than one that did nothing, and it is a defensible place to stop.
The learning period
A tracking policy set to learn without enforcing fills the table and changes nothing about forwarding. A week of that produces an accurate picture of how many addresses each port really holds, which is the input to the limit setting and the evidence that the limit chosen is not too low.
It is also the period during which the probing problem will surface, if it is going to. Watching for hosts that lose IPv6 during this week is far preferable to discovering it after enforcement is on, because during this week nothing the switch is doing can be the cause of a connectivity failure — which makes the probing effect unambiguous when it appears.
Verifying each stage
After the first two steps: the guards' counters show drops on client ports and none on the uplink. After the learning period: the table's entry count is consistent with the host count times several, and no port is at its limit. After inspection: the drop counters are zero or explained. After source enforcement: every port's policy is the intended one and no uplink appears with a client policy.
! Stage 1-2: are the stateless guards working, and only where intended?
Sw1# show ipv6 nd raguard policy RA-HOST
Sw1# show ipv6 dhcp guard policy DHCP-CLIENT
Sw1# show device-tracking counters vlan 10
!
! Stage 3: is the table the size it should be?
Sw1# show device-tracking database | count ND
Sw1# show device-tracking database | count REACHABLE
! Stage 5-6: which policy is on which port, and is anything dropping?
Sw1# show device-tracking policies
Sw1# show device-tracking counters interface TenGigabitEthernet1/0/1
Sw1# show ipv6 source-guard policy SG-CLIENT
!
! The one command that catches a misattached policy
Sw1# show device-tracking policies | include Te1/0/
What to monitor afterwards
Three numbers. The table's entry count, whose sudden fall indicates a tracking or policy problem. The count of ports at their address limit, which should be zero and whose growth predicts the periodic disconnection described earlier. And the guards' drop counters, which should be near zero in steady state on an access layer where nothing hostile is happening.
The second of those is the early warning. A port reaching its limit does not fail immediately; it fails the next time the host rotates an address, which may be hours later. Catching it at the limit rather than at the failure is the difference between a scheduled change and a support call.
The dual-stack interaction
The same table holds both address families on modern platforms, and the IPv4 features described elsewhere read the same structure. That is convenient and it means a policy change made for IPv6 reasons affects IPv4 enforcement on the same ports.
Specifically, an address limit that counts both families needs to accommodate the IPv4 address as well as the several IPv6 ones. Setting it from an IPv6-only calculation leaves no room and produces the limit failure on the family nobody was thinking about.
Documenting the exceptions
Ports where probing was disabled, and why. Limits raised above the standard, and for what. Uplinks carrying an explicit policy to override a VLAN attachment. Each of these will be normalised by somebody restoring a switch from the standard template, and each produces a failure whose cause is invisible in a comparison against that template.
A comment in the interface configuration is the most durable form, because it travels with the port rather than living in a document nobody opens.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers IPv6 first hop security within its infrastructure security domain. What is asked is generally which guard addresses which threat and why a rogue router advertisement is the characteristic IPv6 problem, rather than a full deployment.
| Stage | Enable | Risk | Verify before proceeding |
|---|---|---|---|
| 1 | Advertisement filtering + uplink policy | Low | No drops on the uplink |
| 2 | Server filtering + uplink policy | Low | No drops on the uplink |
| 3 | Tracking, learn only, for a week | Low, but watch for probe effects | Table size, and no port at its limit |
| 4 | Static entries | Low | Nothing unexplained remains |
| 5 | Neighbour inspection, one VLAN | High | Drop counters understood |
| 6 | Source enforcement, one closet | High | No uplink has a client policy |
Conclusion
The controls look like their IPv4 counterparts and the threat is not the same. IPv6 hosts build their own addresses from router advertisements, which makes a device claiming to be a router the highest-impact problem on the segment — and in practice that device is almost always a laptop with connection sharing on or a hypervisor attached to the wrong network rather than an attacker. Filtering advertisements is therefore the first step rather than a later one, and it is stateless, immediate and carries almost no risk.
The binding table is populated mostly by gleaning, which records what a host claimed rather than what a server granted, and it holds several entries per host because a single machine legitimately has a link-local address, an advertised global one, and temporary addresses that rotate every few hours. A per-port limit chosen by IPv4 intuition will be exceeded by one laptop, and the resulting failure is periodic, self-recovering and nearly impossible to attribute without knowing to look for it.
The failure with no IPv4 equivalent is the tracking underneath everything else. The switch probes hosts to keep entries accurate, some host implementations read that probe as another device claiming their address, and those hosts respond by abandoning IPv6 while continuing happily on IPv4 — so the report arrives days later with nothing to correlate it to. Test it during a learning week, on each operating system in the estate, before anything depends on the table. And if the appetite for the table-dependent stages runs out, deploying the two stateless guards and stopping there is a genuinely defensible network. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 4861 — Neighbor Discovery for IP version 6
- RFC 4862 — IPv6 Stateless Address Autoconfiguration
- RFC 6105 — IPv6 Router Advertisement Guard
- RFC 7113 — Implementation Advice for RA-Guard
- RFC 8981 — Temporary Address Extensions for SLAAC
- RFC 6583 — Operational Neighbor Discovery Problems
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 4861 specifies neighbour discovery, including the router advertisement by which a host learns of a default router and the prefixes available on the link.
- RFC 4861 specifies neighbour solicitation and advertisement, which carry no authentication and may therefore be sent by any device on the link.
- RFC 4862 specifies stateless address autoconfiguration, in which a host forms a global address from an advertised prefix without any server involvement.
- RFC 4862 specifies duplicate address detection, in which a host abandons an address if it receives a neighbour message suggesting another device holds it.
- RFC 8981 specifies temporary addresses for autoconfiguration, which a host generates and replaces periodically, so that a single host holds several global addresses over time.
- RFC 6105 defines router advertisement guard, a mechanism by which a switch discards router advertisements received on ports where no router should be present.
- RFC 7113 describes implementation advice for router advertisement guard, including evasion using fragmentation and extension headers.
- RFC 6583 describes operational problems with neighbour discovery, including exhaustion of the neighbour cache by traffic addressed to a large number of unused addresses in a prefix.
- Cisco documentation describes the device tracking binding table, populated by gleaning neighbour discovery messages, by observing DHCP exchanges, and by static configuration.
- Cisco documentation describes the per-port address count limit and states that entries beyond the limit are not created.
- Cisco documentation describes device tracking probing and provides options to disable it or to extend the reachable lifetime, for host implementations that respond adversely to the probes.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include IPv6 first hop security within the infrastructure security domain.