IPv6 Configuration Scenarios

A TCP packet was permitted by the access list.

Why it fails: The log line states denied, and the %IPV6_ACL-6-ACCESSLOGDP message is generated by a deny statement with logging enabled, so the packet was dropped, not permitted. A permit entry with log would produce an ACCESSLOGP message instead.

The access list is not applied to any interface.

Why it fails: The log entry proves the ACL is applied and matching traffic: a deny entry with the ACCESSLOGDP message only generates when packets traverse an interface bound to that list. The option confuses absence of a hit counter with absence of application. An unapplied ACL would be the answer if no log entries appeared despite matching traffic.

The packet was dropped due to uRPF.

Why it fails: The message is an IPv6 ACL deny log, not a uRPF drop, which would be reported by unicast RPF counters or a different syslog facility. The named list FILTER and ACCESSLOGDP identifier point to an explicit ACL deny entry.

The DHCPv6 server has assigned only an IPv6 address to the client.

Why it fails: The binding shows both an IA NA address (2001:DB8:1::100) and an IA PD delegated prefix (2001:DB8:1::/48), so address-only assignment is contradicted by the prefix entry. It is tempting because IA NA alone is the common case for hosts; prefix delegation applies when the client is a requesting router needing downstream subnets.

The DHCPv6 client is using stateless autoconfiguration (SLAAC) because no address is shown.

Why it fails: An address is present (2001:DB8:1::100), and SLAAC bypasses DHCPv6 binding state entirely, so no binding would appear. It is tempting because SLAAC also autoconfigures addresses, but it uses router advertisements, not the DHCPv6 server's binding table shown here.

The DHCPv6 server has a pool with only one prefix available.

Why it fails: The binding shows one client holding one IA_NA address and one IA_PD prefix; it says nothing about pool size or remaining prefixes, since bindings list active leases only. It tempts because a single prefix appears, but pool exhaustion would require checking pool configuration or statistics, not this per-client binding table.

The DHCPv6 relay agent is not functioning because messages are not being forwarded.

Why it fails: The debug shows SOLICIT, ADVERTISE, REQUEST and REPLY each forwarded in both directions, so relay is working end to end. This option would fit if messages arrived but no forwarding lines appeared, indicating a relay configuration fault.

The DHCPv6 server is unreachable because no REPLY is received.

Why it fails: The log shows a REPLY received from 2001:DB8:2::1 and forwarded to the client, so the server is demonstrably reachable and the four-message exchange completed. It is tempting because a missing REPLY is the classic signature of an unreachable DHCPv6 server, but that symptom would appear as repeated SOLICIT retransmissions with no ADVERTISE or REPLY.

The DHCPv6 client is using a global unicast address as its link-local address.

Why it fails: Every client message arrives from FE80::1, a link-local address, which is the expected source for DHCPv6 clients on the local segment. It is tempting because a client misconfigured with a global address as its link-local would look similar in a capture, but the FE80:: prefix here proves the address is genuinely link-local.

The DHCP guard policy is applied only if the snooping database is present.

Why it fails: The DHCP guard attach-policy and snooping database file commands are independent; the policy applies regardless of whether the database file exists. It is tempting because snooping databases feed binding validation, but DHCP guard enforces server and client roles directly. Database presence affects binding lookups, not policy attachment.

The interface will not forward any DHCP messages until the database is populated.

Why it fails: DHCP guard filters server or client messages based on the attached policy; forwarding is not suspended pending database population. The snooping database file merely persists bindings across reloads. It is tempting because snooping must learn bindings, but DHCP guard enforcement does not wait on the database, and normal DHCP relay and client traffic continues.

The snooping database is used to validate DHCP server messages.

Why it fails: The snooping database stores IPv6-to-MAC bindings learned from ND and DHCP snooping; it does not validate DHCP server messages. DHCP guard performs that role-based validation. It is tempting because both features relate to DHCP security, but the database is a binding repository, not a server-message validator.

It sets the trust level for ND inspection.

Why it fails: ND inspection trust is configured with 'ipv6 nd inspection policy' and the 'device-role' keyword there, not inside a DHCP guard policy. The DHCP guard device-role instead labels a port as 'server' or 'client' to decide which ports may send DHCP server messages, so it is tempting because both features share the device-role syntax.

It defines the VLAN membership for the interface.

Why it fails: VLAN membership is set by the interface's switchport configuration or subinterface encapsulation, not by device-role. The command labels a port as 'server' or 'client' so DHCP guard knows which ports may legitimately relay or serve DHCPv6; it is tempting because device-role is applied per interface, which superficially resembles a per-port VLAN assignment.

It enables IPv6 routing on the interface.

Why it fails: IPv6 routing is enabled by 'ipv6 unicast-routing' globally and 'ipv6 address' on the interface, not by device-role. The command marks a port as 'server' or 'client' so DHCP guard permits or blocks DHCPv6 server messages; it is tempting because device-role is entered under interface configuration, where routing commands also live.

IPsec

Why it fails: IPsec protects traffic at the IP layer between two endpoints and cannot authenticate individual ND messages, which are link-local and multicast. SEND, using Cryptographically Generated Addresses and RSA signatures, is the mechanism specified for this; IPsec would secure tunnel or host-to-host flows instead.

SSL/TLS

Why it fails: SSL/TLS operates above TCP and secures application sessions such as HTTPS, whereas ND runs directly over ICMPv6 with no transport layer to wrap. SEND is the defined cryptographic authentication mechanism for ND; TLS would be the choice for protecting a web or API session.

MACsec

Why it fails: MACsec secures the Ethernet link itself with hop-by-hop encryption and integrity, so it cannot provide end-to-end authentication of ND messages between arbitrary nodes. SEND, with CGA and RSA signatures, is designed for that purpose; MACsec suits point-to-point link protection between switches.

RA Guard

Why it fails: RA Guard filters inbound IPv6 Router Advertisement messages on access ports to block rogue routers; it inspects RA packets, not host reachability, and maintains no device tracking database. It is tempting because it is an FHS feature tied to IPv6 first-hop security, but its function is RA filtering, not host tracking.

DHCPv6 Guard

Why it fails: DHCPv6 Guard filters DHCPv6 server and client messages on access ports to prevent rogue DHCPv6 servers; it does not build a device tracking database of host reachability. It is tempting as a first-hop security feature, but its mechanism is DHCPv6 message filtering, not host tracking.

PACL

Why it fails: PACL is a port-based access control list applied to Layer 2 switch ports to filter traffic; it performs stateless packet filtering and maintains no device tracking database. It is tempting because it is an FHS access-control feature, but its mechanism is ACL filtering, not host reachability tracking.

It permits all IPv6 traffic

Why it fails: Sequence 10 drops traffic sourced from 2001:DB8:2::/48 before the sequence 20 permit is evaluated, so that prefix is blocked. Permitting everything would need the deny entry absent or placed after the permit, which the ordering here prevents.

It permits only IPv6 traffic from 2001:DB8:2::/48

Why it fails: The sequence 20 permit matches any source, so all other IPv6 traffic is allowed alongside the denied prefix; only 2001:DB8:2::/48 is blocked. Permitting solely that prefix inverts the logic, since sequence 10 explicitly denies it rather than allowing it.

It denies all IPv6 traffic

Why it fails: The list denies only traffic sourced from 2001:DB8:2::/48, then permits everything else via the sequence 20 entry, so traffic from other prefixes still passes. Denying all traffic would require an implicit deny with no matching permit, which this ACL does not have.

It prevents rogue DHCPv6 servers from assigning malicious addresses.

Why it fails: ND Inspection validates ICMPv6 Neighbor Solicitation and Advertisement messages against the binding table; it does not police DHCPv6 server traffic. It is tempting because rogue DHCPv6 servers are a real threat, but that is handled by DHCPv6 Guard, which filters server advertisements on untrusted ports.

It uses a prefix list to determine which source addresses are allowed.

Why it fails: ND Inspection builds its binding table from snooped Neighbor Discovery messages and uses a policy (trusted/untrusted) plus optional static bindings, not a prefix list of permitted source addresses. A prefix list is tempting because IPv6 access lists and RA Guard policies do filter by prefix, but that is a different feature.

It is enabled globally and cannot be applied on a per-interface basis.

Why it fails: ND Inspection is configured per interface (or per VLAN) with ipv6 nd inspection, marking ports trusted or untrusted, so it is not a global-only feature. It is tempting because some IPv6 first-hop security features are enabled globally, but interface-level policy is precisely how ND Inspection scopes its enforcement.

The client is using SLAAC instead of DHCPv6.

Why it fails: The presence of an IA NA binding with a server-assigned address, DUID and T1/T2 timers proves stateful DHCPv6 address assignment occurred. SLAAC produces no server binding entry. This option would be correct if the client had formed its address from a received prefix via router advertisement.

The client's lease has expired.

Why it fails: The binding shows a valid lifetime of 2592000 seconds with an expiry timestamp in the future, so the lease remains active. Expired leases are removed from the binding table or shown with zero remaining lifetime. This option would be correct if the Expires field showed a past date.

The client is not authorized.

Why it fails: The binding lists Username: unknown, which reflects that no authentication or authorisation was configured for this client, not a rejection. The address was still assigned successfully. This option would be correct if the server had refused the request and no binding existed.

The tunnel mode is multipoint, but the spokes need to be configured with 'tunnel mode gre ip' for direct communication.

Why it fails: 'tunnel mode gre multipoint' is required for DMVPN and is already correct; changing spokes to 'tunnel mode gre ip' would break the mGRE/NBMA design entirely. The option is tempting because point-to-point GRE tunnels do carry spoke-to-spoke traffic, but that static full-mesh approach is not DMVPN phase 2.

The spokes have different NHRP network IDs, preventing registration.

Why it fails: Mismatched NHRP network IDs would prevent registration, yet the hub already shows both spokes registered, so the IDs must match. The option is tempting because network-ID mismatch is a classic DMVPN fault, and it would be the cause if registration had failed rather than succeeded.

The IPv6 addresses on the tunnel interfaces are in different subnets.

Why it fails: DMVPN tunnel interfaces must share one subnet, and the stem gives no evidence of differing subnets; the hub already shows both spokes registered, which requires reachable tunnel addresses. The option is tempting because subnet mismatch does break spoke-to-spoke reachability, but it would also prevent the registrations already observed.

uRPF is disabled

Why it fails: Strict mode is enabled, so uRPF is not disabled; the output explicitly reports "IPv6 uRPF: strict mode" on the interface. Disabled interfaces omit this line entirely. The option tempts engineers who assume uRPF defaults to off unless configured, which holds on interfaces where no uRPF command was applied — but here the running configuration already shows strict mode active.

uRPF is enabled in loose mode

Why it fails: Loose mode accepts any source address present in the routing table, regardless of the ingress interface, so it would not be reported as strict. The output explicitly states strict mode, which requires the source to be reachable via the receiving interface. Loose mode suits asymmetric routing, where return traffic arrives on a different path.

uRPF is enabled but only for multicast

Why it fails: The output states strict mode, which applies to unicast source addresses; multicast traffic is not validated by uRPF at all, so the claim contradicts the displayed configuration. It tempts because uRPF does interact with multicast through specific commands, but that would appear as a separate multicast-specific line, not as strict mode.

RA Guard

Why it fails: RA Guard filters ICMPv6 Router Advertisement and Redirect messages on untrusted ports, blocking rogue routers; it does not snoop Neighbor Solicitation or Advertisement used by DAD. It is tempting because both are IPv6 First Hop Security features operating on ICMPv6.

DHCPv6 Guard

Why it fails: DHCPv6 Guard filters DHCPv6 server and relay messages on untrusted ports; it does not inspect Neighbor Discovery traffic, so DAD attacks pass through. It is tempting because both are First Hop Security features, but DHCPv6 Guard operates on UDP 546/547, not ICMPv6 ND.

Source Guard

Why it fails: Source Guard builds a binding table from DHCPv6 snooping and drops traffic whose IPv6 source does not match the binding; it does not inspect ND messages for DAD. It is tempting because it also mitigates spoofing, but its enforcement is source-address based, not ND-based.