IPV6 practice questions

Standard IPv4 ACLs use numbers in the range 100-199.

Why wrong: Standard IPv4 ACLs are numbered in the ranges 1–99 and 1300–1999, not 100–199. The number range 100–199 is explicitly reserved for extended numbered ACLs, which evaluate source and destination IP addresses, protocol, and port numbers. Misidentifying 100–199 as standard ACL numbers confuses the ACL type and its underlying matching logic.

Standard IPv4 ACLs filter only the source IP address and are best placed close to the source to be most effective.

Why wrong: Standard ACLs indeed filter only on the source IP address, but that limited matching capability requires them to be placed as close to the destination as possible, not the source. If placed near the source, a standard ACL entry that denies a particular source would block that source's traffic to all destinations, including legitimate ones. Positioning near the destination limits the ACL's impact to the intended target network, avoiding accidental collateral denial.

Numbered ACLs allow individual access control entries (ACEs) to be deleted without removing the entire ACL.

Why wrong: Numbered ACLs do not permit deletion of an individual access control entry; to remove one ACE, the entire ACL must be deleted and re-entered without that entry. Named ACLs, in contrast, assign sequence numbers to each ACE, allowing selective deletion, insertion, and resequencing without recreating the full list. This operational limitation of numbered ACLs applies to both standard and extended numbered variants and is a common source of configuration errors.

The interface is administratively down.

Why wrong: The interface status in the output reads 'up, line protocol is up', indicating that the interface is fully operational at both Layer 1 and Layer 2. An administratively down interface would instead show 'administratively down, line protocol is down' and would not generate any IPv6 traffic, including Router Advertisements. Since the router is actively advertising and the link-local address is present, the interface is clearly not shut down or disabled.

The MAC address of the interface is invalid, preventing EUI-64 from generating a proper address.

Why wrong: The link-local address FE80::21A:2BFF:FE3C:4D5E shown in the output is derived from the interface MAC address using EUI-64, which inserts FFFE in the middle and flips the U/L bit. The presence of this valid link-local address proves the MAC address is not invalid and EUI-64 generation succeeded. An invalid or all-zero MAC would prevent IPv6 from generating any link-local address, but the output clearly displays a properly formed one, so this option cannot be the cause.

The router is not sending Router Advertisements, so hosts cannot autoconfigure.

Why wrong: The output explicitly states 'ND router advertisements are sent every 200 seconds', which confirms the router is actively sending ICMPv6 Router Advertisements on this interface. Hosts would therefore be able to perform stateless address autoconfiguration (SLAAC) and learn the default router. However, the problem is that hosts cannot reach the router's own link-local address, which points to a missing or incorrectly configured IPv6 address on the router itself, not to a lack of RA messages.

A NAT rule translating IPv6 to IPv4

Why wrong: IPv6 was designed to restore end-to-end connectivity without relying on NAT; in normal native IPv6 environments, routing uses global unicast addresses directly. A NAT rule that translates IPv6 to IPv4 would be an unnecessary and complex workaround, and it would not help the host reach off-link IPv6 destinations unless that IPv4 path itself is routed. Since the host already reaches neighbors using IPv6, the missing element is not address translation but a route to a default gateway.

A VLAN trunk on the host NIC

Why wrong: VLAN trunking is a Layer 2 feature used to carry multiple VLANs over a single switch link, typically between switches or to a router-on-a-stick. An end host NIC rarely requires trunking, and the symptom described is unrelated to VLAN tagging because it concerns Layer 3 reachability. Even if the NIC were configured with a trunk, that would not provide a default route or next hop for off-link IPv6 packets.

A second global unicast address on the same interface

Why wrong: Adding a second global unicast address to the same interface only provides an additional source or destination identifier for that interface; it does not install any route or gateway information into the host's IPv6 routing table. The host still lacks a default route for off-link traffic, and the existing address already satisfies the requirement of having a valid IPv6 source address. Therefore, a duplicate address does not solve the described reachability problem.

Global unicast

Why wrong: Global unicast addresses (2000::/3) are globally routable and must be obtained either through static configuration, Stateless Address Autoconfiguration (SLAAC), or DHCPv6; they are not automatically created on an interface merely by activating IPv6. The interface's automatic address is strictly link-local, while a global address is assigned based on network prefix information from Router Advertisements or manual setup. This makes global unicast an incorrect answer for an automatically created address type.

Unique local

Why wrong: Unique local addresses (fc00::/7) serve a role analogous to IPv4 private addresses, but they are not automatically configured on an interface when IPv6 is enabled. Instead, they require explicit manual configuration or stateful assignment via DHCPv6, and they are designed to be routable within a private site, not restricted to a single link. Because they are not automatically created, they cannot be the correct answer.

Multicast

Why wrong: Multicast addresses (ff00::/8) identify a group of interfaces across a network, not a single interface's unicast identity, and an IPv6 host does not automatically create a multicast address as a source or host address. While an interface joins multicast groups like all-nodes (ff02::1) and solicited-node automatically, those are destination-only group addresses, not address types assigned to the interface itself. Thus multicast is not an automatically created interface address type in the context of this question.

The policy needs to match only one source subnet.

Why wrong: If the policy needs to match only a single source subnet, a standard access list using a wildcard mask like 0.0.255.255 fully satisfies that goal. Standard ACLs evaluate only the source address, so one permit or deny statement can identify the subnet without extra protocol or port granularity. This requirement does not require an extended ACL at all.

The ACL must be placed near the destination.

Why wrong: Placement near the destination is a recommended practice once an extended ACL is selected, because it limits extraneous traffic traversing the network. However, the physical or logical placement of an ACL does not determine whether a standard or extended ACL is required; a standard ACL can also be deployed, although it is typically positioned near the source. Therefore, this is a design guideline, not a selection premise.

The network uses IPv6 instead of IPv4.

Why wrong: Whether the network is IPv4 or IPv6 does not alter the fundamental limitation: a named IPv6 ACL is essentially equivalent to an extended ACL in capability, and the choice between standard-like and extended-like matching still depends on the need for granular match criteria. If the requirement is only to match a source subnet, either address family can use a simple source-only ACL. Thus, using IPv6 does not inherently force the extended ACL variant.

The routers need global unicast addresses before OSPFv3 can run.

Why wrong: OSPFv3's transport is based on IPv6 link-local addresses; it does not require global unicast addresses to establish the neighbor state. The OSPFv3 Hello protocol uses link-local destinations (FF02::5) and source addresses, so the adjacency can form even if global addresses are absent or not yet assigned. Global addresses are only necessary for external route advertisement or certain network designs, not for basic neighbor formation.

The router IDs must be identical before adjacency can form.

Why wrong: OSPFv3 requires each router to have a unique 32-bit Router ID, typically derived from an IPv4 address, to identify itself in the routing domain. If two routers had identical Router IDs, the adjacency would not form correctly; instead, it would cause a conflict and one of them would be rejected. The actual requirement is that Router IDs are unique, not identical, for a neighbor relationship to succeed.

The link-local addresses must be learned from DHCPv6.

Why wrong: IPv6 link-local addresses (FE80::/10) are automatically configured on every interface using EUI-64 or random generation, independent of DHCPv6. OSPFv3 uses these link-local addresses as the source for Hello packets and routing updates, so no DHCPv6 involvement is needed for adjacency formation. Even if DHCPv6 were used for other address assignment, it is irrelevant to the OSPFv3 neighbor process.

It enables OSPFv3 on GigabitEthernet0/0.

Why wrong: This command, `ipv6 route 2001:db8:100::/64 GigabitEthernet0/0`, is a static-route configuration entry, not a routing-protocol activation. OSPFv3 is a dynamic link-state protocol that is enabled under the router configuration with a process ID and then applied to interfaces via `ipv6 ospf` commands, or by using `ospfv3` in global and interface configuration. The presence of the `ipv6 route` keyword clearly indicates a manual prefix advertisement, and no OSPFv3 process is ever referenced.

It creates an IPv6 default route.

Why wrong: An IPv6 default route is represented by the prefix `::/0`, which matches all IPv6 addresses, and is typically configured as `ipv6 route ::/0` followed by a next-hop or exit interface. The command in question explicitly targets the unicast prefix `2001:db8:100::/64`, a unique local-looking prefix that only covers a single /64 block, so it cannot serve as a catch-all route. Therefore, this option mischaracterizes the scope of the configured prefix.

It converts the interface into a tunnel.

Why wrong: Tunnels in IPv6 are created by defining an interface with the `interface tunnel` command, specifying tunnel mode (e.g., `tunnel mode ipv6ip`), and setting tunnel source and destination addresses. A static route like the one shown merely adds a forwarding entry to the routing table and has no effect on the physical or logical nature of the exit interface. The `GigabitEthernet0/0` interface remains a standard routed port, not a tunnel interface.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64 eui-64' and 'no shutdown'. No need to enable IPv6 unicast-routing because it is on by default.

Why wrong: This is incorrect because IPv6 unicast-routing is not enabled by default on Cisco IOS; it must be explicitly configured with the 'ipv6 unicast-routing' global command. Without it, IPv6 packets will not be forwarded between interfaces.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64' (without eui-64) and 'no shutdown'. Enable 'ipv6 unicast-routing' globally on both routers.

Why wrong: This is incorrect because the question specifies that R1's G0/1 should use EUI-64. The command 'ipv6 address 2001:db8:1::/64' assigns a static address (the full /64 prefix as the interface ID), which is not what is required. The correct command includes the 'eui-64' keyword to generate the interface ID from the MAC address.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64 eui-64' and 'no shutdown'. Enable 'ipv6 unicast-routing' globally on both routers. Also, change the default gateway on PC1 to 2001:db8:1::1.

Why wrong: This is incorrect because the default gateway on PC1 should be the IPv6 address of R1's G0/1 interface. With EUI-64, the interface address is derived from the MAC address, not necessarily ::1. The question states that R1's G0/1 uses EUI-64, so the gateway address is not predetermined as ::1. The PCs already have correct gateways as per the existing explanation.

Change R1 G0/0 subnet mask to /30, add a default route via 192.0.2.254, and keep the EUI-64 IPv6 address on G0/0.

Why wrong: This is incorrect because the default route points to 192.0.2.254, which is not R2's G0/0 IP (192.0.2.2), so IPv4 traffic will not be forwarded. Also, EUI-64 generates an interface ID from the MAC, which will not match the subnet expected by R2's static address 2001:db8:1::2/64.

Change R1 G0/0 subnet mask to /24, add a default route via 192.0.2.2, and configure a static IPv6 address 2001:db8:1::1/64 on G0/0.

Why wrong: This is incorrect because the subnet mask on R1's G0/0 remains /24, which does not match R2's /30. R1 will consider the subnet to be 192.0.2.0/24, while R2 uses 192.0.2.0/30, causing a mismatch that prevents direct communication.

Change R1 G0/0 subnet mask to /30, add a default route via 192.0.2.2, and keep the EUI-64 IPv6 address on G0/0.

Why wrong: This is incorrect because while the IPv4 issues are fixed, the IPv6 address generated by EUI-64 will not match the subnet expected by R2's static address 2001:db8:1::2/64. EUI-64 creates an interface ID based on the MAC, which is unpredictable and unlikely to be in the same subnet as R2's static address.

Remove the incorrect static route 192.0.2.0 255.255.255.0 10.0.0.1 and add ip route 192.0.2.0 255.255.255.0 10.0.0.2 1

Why wrong: This is incorrect because the administrative distance of 1 is lower than the directly connected route's AD of 0, so the floating static route would be preferred over the directly connected route, defeating its purpose as a backup.

Keep the existing static route and add ip route 192.0.2.0 255.255.255.0 10.0.0.2 10

Why wrong: The existing static route cannot remain because it uses 10.0.0.1 — R1's own G0/0 address — as the next hop for the remote 192.0.2.0/24 network. When R1 processes this route, it performs a recursive lookup for 10.0.0.1 and finds itself, causing packets to be looped back out the same interface instead of being forwarded to R2; this route becomes the active route with AD 1, outcompeting the new AD 10 route. Adding the floating static route with next-hop 10.0.0.2 does not remove or override the bad route—the lower-AD bad route remains preferred, so traffic to 192.0.2.0/24 is still black-holed. You must delete the faulty static route first, then add the correct floating route with AD 10.

Remove the incorrect static route 192.0.2.0 255.255.255.0 10.0.0.1 and add ip route 192.0.2.0 255.255.255.0 g0/0

Why wrong: This is incorrect because using an exit interface (g0/0) instead of a next-hop IP address for a static route to a remote network can cause issues if the interface goes down, but more importantly, the question requires a floating static route with AD 10, which is not provided here. Additionally, the route would be directly connected? Actually, using an exit interface makes the route a directly connected static route, which has AD 0? No, static routes with exit interface have AD 1 by default. But the question specifies a floating static route with AD 10, so this does not meet the requirement.

The OSPFv3 process ID must match on both routers.

Why wrong: OSPFv3 process IDs are only meaningful on the local router and do not influence the OSPFv3 neighbor relationship. Each router can run a different process ID number as long as the interface has been enabled for OSPFv3 in the same IPv6 area. Neighborship depends on stable parameters such as area ID, hello/dead timers, and MTU, not on the process ID. Therefore, a mismatch would not prevent R1 from seeing R2 in the neighbor table.

The link-local addresses are not in the same subnet.

Why wrong: ICMPv6 and OSPFv3 use link-local addresses (fe80::/10) exclusively for neighbor discovery and for exchange of routing information on the local segment. These addresses are only required to be unique on the link, never globally or in the same subnet as the remote peer. Because both interfaces are on the same Ethernet segment, their link-local addresses are automatically valid for OSPFv3 communication. A subnet mismatch of link-local addresses is therefore impossible and cannot be the cause of a missing neighbor entry.

The router ID 1.1.1.1 is duplicated on R2.

Why wrong: If the router ID 1.1.1.1 were actually duplicated, the routers would still discover each other via Hello packets and move through OSPF state machine into EXSTART/EXCHANGE before the duplicate ID is detected and the adjacency is halted. The absence of any neighbor entry at all, rather than a stuck state, indicates that OSPFv3 packets are not being processed on the interface. Duplicate router IDs are also unlikely in this scenario because the question only shows a missing neighbor on R1, not a conflict log. So this is not the correct explanation.

ipv6 enable

Why wrong: 'ipv6 enable' is an interface-level command that activates IPv6 processing on a single interface without assigning an IPv6 address. It does not enable IPv6 routing globally on the router. To route IPv6 packets between networks, you must issue the global command 'ipv6 unicast-routing' in global configuration mode.

ip routing ipv6

Why wrong: 'ip routing ipv6' is not valid Cisco IOS syntax. The command 'ip routing' is used to enable IPv4 routing, but there is no such command with 'ipv6' appended in that order. IPv6 routing is enabled with the separate global command 'ipv6 unicast-routing', so this option does not achieve the intended result.

ipv6 route enable

Why wrong: The command 'ipv6 route enable' is not a valid Cisco IOS command. The correct global command to enable IPv6 routing is 'ipv6 unicast-routing'. Additionally, 'ipv6 route' is used for configuring static routes, not for enabling routing functionality, so this option is incorrect.

R1(config)# ipv6 unicast-routing R1(config)# ipv6 router ospf 100 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# network 2001:db8:12::0/64 area 0 R1(config-rtr)# network 2001:db8:1::0/64 area 0 R2(config)# ipv6 unicast-routing R2(config)# ipv6 router ospf 100 R2(config-rtr)# router-id 2.2.2.2 R2(config-rtr)# network 2001:db8:12::0/64 area 0 R2(config-rtr)# network 2001:db8:2::0/64 area 0

Why wrong: This configuration is incorrect because OSPFv3 on Cisco IOS does not use the IPv4-style 'network' command under router configuration mode; that command is only valid for OSPFv2. In OSPFv3, interfaces must be placed into the OSPF process individually using the interface-level 'ipv6 ospf 100 area 0' command. Since no interface is enabled for OSPFv3, the routers will not send or process OSPFv3 hello packets, and no adjacency or route exchange can occur.

R1(config)# ipv6 unicast-routing R1(config)# ipv6 router ospf 100 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# interface gigabitethernet0/0 R1(config-if)# ipv6 ospf 100 area 0 R2(config)# ipv6 unicast-routing R2(config)# ipv6 router ospf 100 R2(config-rtr)# router-id 2.2.2.2 R2(config-rtr)# interface gigabitethernet0/0 R2(config-if)# ipv6 ospf 100 area 0

Why wrong: This configuration is wrong because OSPFv3 is enabled only on the GigabitEthernet0/0 interfaces; the loopback0 interfaces are left out of the OSPFv3 process. Without the 'ipv6 ospf 100 area 0' command under loopback0, the loopback IPv6 prefixes are not advertised into OSPF, so R1 and R2 will not install each other's loopback routes in their routing tables. The GigabitEthernet link will form an adjacency, but the loopback networks will remain unreachable, failing the requirement.

R1(config)# ipv6 unicast-routing R1(config)# ipv6 router ospf 100 R1(config-rtr)# router-id 1.1.1.1 R1(config-rtr)# interface gigabitethernet0/0 R1(config-if)# ipv6 ospf 100 area 0 R1(config-if)# interface loopback0 R1(config-if)# ipv6 ospf 100 area 0 R2(config)# ipv6 unicast-routing R2(config)# ipv6 router ospf 100 R2(config-rtr)# router-id 1.1.1.1 R2(config-rtr)# interface gigabitethernet0/0 R2(config-if)# ipv6 ospf 100 area 0 R2(config-if)# interface loopback0 R2(config-if)# ipv6 ospf 100 area 0

Why wrong: Both routers have been configured with the identical router-ID 1.1.1.1, which is invalid for OSPFv3 because router-IDs must be unique throughout the OSPF routing domain. When a router receives a hello packet advertising the same router-ID it uses itself, it rejects the neighbor and will not form an adjacency. Consequently, no OSPF database synchronization occurs, and neither router learns the other's loopback or link prefixes, so traffic between the routers fails.

It is the same thing as a client SSID.

Why wrong: An SSID (Service Set Identifier) is the human-readable name of a wireless network that clients scan for and select to connect, typically broadcast in beacon frames. CAPWAP is a backend protocol that only operates on the wired network between an AP and a controller, invisible to wireless clients. Confusing them mixes the client-facing characteristic of a WLAN with the control-plane tunneling mechanism used behind the scenes, and they have no functional equivalence.

It is a replacement for WPA2 and WPA3.

Why wrong: CAPWAP is a tunneling protocol, not an encryption or authentication standard, so it cannot replace WPA2 or WPA3. WPA2 and WPA3 secure the wireless link by using AES-CCMP or AES-GCMP encryption and handshake-based authentication between the client and the AP. CAPWAP, in contrast, operates behind the AP layer, not between the client and AP, and it carries encrypted payloads rather than providing the encryption itself.

It is used only for IPv4 ACL filtering.

Why wrong: CAPWAP is a Layer 3 protocol that encapsulates AP-controller traffic using UDP/IP, which has no connection to IPv4 ACL filtering. Access control lists (ACLs) are a separate security mechanism that permits or denies packets based on source/destination addresses, ports, or protocols, and they are configured on routers, switches, or WLCs. CAPWAP does not filter traffic; it simply provides a tunnel for control and data messages, so calling it an ACL tool is incorrect.

Enable IPv6 unicast routing, configure OSPFv2 process with router-id, enable OSPFv2 on GigabitEthernet0/0 in area 0, and verify neighbor and route.

Why wrong: This option is incorrect because OSPFv2 is explicitly designed for IPv4 routing and uses IPv4 addresses to build LSAs and adjacencies; it cannot carry IPv6 prefix information. Since the requirement is to route IPv6 traffic, OSPFv3 is the correct protocol, as it supports IPv6 address families and runs natively over IPv6. Enabling OSPFv2 would leave the IPv6 routing table empty and no IPv6 neighbors would form.

Enable IPv6 unicast routing, configure OSPFv3 process without a router-id, enable OSPFv3 on GigabitEthernet0/0 in area 0, and verify neighbor and route.

Why wrong: The critical flaw here is omitting the router-id for OSPFv3. In OSPFv3, the router-id is a 32-bit value that must be explicitly configured because OSPFv3 does not use IPv6 addresses to identify routers—unlike OSPFv2, which can derive a router-id from IPv4 interfaces. Without a manually assigned router-id, the OSPFv3 process will default to 0.0.0.0, and the router will be unable to establish neighbor adjacencies, so no routes will ever be exchanged.

Enable IPv6 unicast routing, configure OSPFv3 process with router-id, enable OSPFv3 on GigabitEthernet0/0 in area 0, but do not verify neighbor or route.

Why wrong: This option incorrectly omits the verification phase. After configuring OSPFv3, it is essential to check that neighbor adjacencies have formed using 'show ipv6 ospf neighbor' and that IPv6 routes are installed using 'show ipv6 route ospf'; without these checks, the task is incomplete. The question explicitly asks to verify the neighbor and route, so skipping verification means the configuration has not been validated and potential issues like incorrect area assignment or interface misconfiguration would go undetected.

An IPv6 access list on the router is blocking Router Advertisement messages.

Why wrong: An access list could block ICMPv6 Router Advertisements, preventing hosts from obtaining prefixes and global unicast addresses. However, this does not explain why the router's own interface lacks a global unicast address when statically configured or when the router itself should be generating RAs. The missing ipv6 unicast-routing command is a more fundamental cause.

The IPv4 resource is not configured for NAT64 translation.

Why wrong: While NAT64 is a common method for IPv6-only hosts to access IPv4 resources, the symptom explicitly shows a missing global unicast address on the router interface and a missing ipv6 unicast-routing command. This indicates a basic IPv6 routing failure, not a translation service configuration issue.

The host has an incorrect default gateway for IPv6.

Why wrong: A misconfigured default gateway on the host would prevent it from reaching off-link resources. However, the technician observed a missing global unicast address on the router interface and the absence of ipv6 unicast-routing, indicating that the router itself is not properly configured for IPv6 routing. The host's gateway issue would be a consequence, not the root cause.

The laptop's DNS server settings are incorrect.

Why wrong: Incorrect DNS settings would not prevent the laptop from obtaining an IP address via DHCP; the laptop would still get a valid IP and gateway but fail to resolve names. The APIPA address indicates a DHCP failure, not a DNS problem.

The laptop has a static IP address configured that conflicts with another device.

Why wrong: A static IP address would not be 169.254.x.x unless manually set, which is unlikely. An IP conflict would produce a different symptom (e.g., intermittent connectivity, error message) and the laptop would still show a manually configured gateway.

The Ethernet cable is faulty or disconnected.

Why wrong: A faulty cable would cause the network adapter to show 'Network cable unplugged' or a link status of 'Disconnected' in ipconfig, not an APIPA address. APIPA is only assigned when the interface has link but no DHCP response.

A default static route is used when no dynamic routing protocols are configured.

Why wrong: A default static route is used as a gateway of last resort for any destination not in the routing table, regardless of whether dynamic protocols are configured. It is not dependent on the absence of dynamic routing.

A floating static route must have a lower administrative distance than the primary route.

Why wrong: A floating static route must have a higher administrative distance than the primary route, not a lower one. The lower the administrative distance, the more preferred the route; if the floating route had a lower AD, it would take precedence over the primary route, making the so-called backup the active route. By assigning a higher AD, the floating static route remains in the routing table only when the primary route is absent or unreachable, which is the correct mechanism for failover.

An IPv6 static route can specify an IPv4 address as the next-hop.

Why wrong: An IPv6 static route requires an IPv6 next-hop address because the router maintains separate routing tables and next-hop resolution processes for IPv4 and IPv6. Specifying an IPv4 address as the next-hop would be invalid and the command would be rejected, as the router cannot resolve an IPv4 address in the IPv6 routing table. Even on a dual-stack router, the next-hop for an IPv6 prefix must be a valid IPv6 address.

The routers need matching hostnames before OSPFv3 can start.

Why wrong: Hostnames are purely informational labels and are never transmitted in OSPFv3 Hellos or used in the neighbor selection process. OSPFv3 adjacency depends on matching Router ID, area ID, timers, and optional authentication; hostname configuration has no effect on these parameters. Therefore, two routers with different hostnames can still become OSPFv3 neighbors if all protocol parameters are correctly set.

IPv6 requires a /64 only for routing protocols to function.

Why wrong: The claim that IPv6 requires a /64 only for routing protocols is incorrect because OSPFv3 works with any IPv6 prefix length; routing protocols do not mandate a particular subnet mask. The routers' inability to form an adjacency is best explained by a mismatch in OSPFv3 configuration, such as different area IDs, not by the prefix length. A /64 is commonly used for network addressing but is not a protocol requirement for adjacency.

OSPFv3 cannot run on directly connected interfaces.

Why wrong: OSPFv3 is explicitly designed to run on directly connected IPv6 interfaces; it uses a shared link to exchange Hello and database packets, so a point-to-point connection between two routers is a typical and fully supported deployment. If the routers cannot form an adjacency, the cause is not that the interfaces are directly connected, but rather some misconfiguration such as mismatched areas, timers, or wrong instance ID. Direct connectivity is a precondition, not an obstacle.