A housing authority uses IPv6 device tracking to build binding tables and wants to constrain which source addresses may leave an access port. Which conceptual control applies those bindings?
Select an answer to reveal the explanation.
Short Explanation
Device tracking fills an IPv6 binding book; Source Guard then checks packets against that book. Sources that never showed up as legitimate neighbors don’t get to speak on that jack.
Full Explanation
IPv6 first-hop security uses device tracking and binding tables learned from Neighbor Discovery and related gleaning. IPv6 Source Guard enforces those bindings so unauthorized source addresses cannot leave the access port—conceptually parallel to IPv4 IPSG with DHCP snooping. A housing authority that builds bindings via device tracking and then constrains sources applies IPv6 Source Guard on top of that table.
IPv4-only DHCP snooping without IPv6 ND gleaning does not populate or enforce IPv6 bindings. MST instance mapping of IPv6 prefixes into VLAN 1 is unrelated nonsense for source constraint. CoPP that drops all ICMPv6 including path MTU messages campus-wide harms needed ICMPv6 and is not binding-based source guard.
Exam caveat: device tracking/bindings + IPv6 Source Guard = authorized sources only on the port.
Operational check: verify IPv6 binding table population from ND/device tracking, enable IPv6 Source Guard on housing access ports, attempt an unauthorized source address, confirm drops, and preserve necessary ICMPv6 elsewhere via proper CoPP—not blanket drops. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.