To get useful IPv6 communication working, you need devices to be on the same IPv6 subnet to be able to communicate. Since DHCPv6 is not the preferred common way to share addresses, this leaves you with two options to make sure you're using the same IPv6 subnet: using router advertisements, or static IPv6 address assignments.
I'm guessing (and could be wrong on this particular point) that this IPv6 "pass through" setting causes your router to act more like a switch if the frame's payload is an IPv6 packet.
If your router is acting like a switch, and not really "routing" the IPv6 packets but passing them through to your ISP, then essentially your ISP is acting as your router. In that case, your physical "router" device is not routing traffic, and is not part of the IPv6 configuration, so when I say "router" I really mean your ISP.
The other possibility is that your "router" is set to route traffic between subnets. In that case, you might have some trouble later with troubleshooting IPv6 routing between subnets. However, that is a more complex step. The simpler step, to troubleshoot first, is to use ICMPv6 via the "ping", "ping -6", or "ping6" command (which to use will depend on your operating system) to successfully communicate.
I typically would try to not use such a "pass through" setting, because then my local setup would not be dependent on my ISP. If my router is acting like an actual router, and routing between subnets as needed, then I can at least communicate with my own equipment without concern of any setting that the ISP may change (even if they disable my Internet service).
For initial troubleshooting, static IPv6 address assignments (meaning that you select the addresses) may be simpler. The first thing you need to do is to figure out what the router's IPv6 addresses are. There should be one address that starts with "fe80:" through "febf:" (by far, this seems to usually be "fe80:"), and one other address, which for now I will call "2001:0db8:something". (Actually, I can pretty much guarantee you that it doesn't start with "2001:db8:"; that address range is reserved for documentation examples, like this one.)
With static addressing, assign your computer a close but different IPv6 address. For instance, if your router is using 2001:db8:f00d:cafe:babe:face:0fc0:ffee, then assign your address to be 2001:db8:f00d:cafe::5
I'm going to just assume that you're familiar with IPv6 notation: e.g., you understand how 2001:db8::5 expands to a full IPv6 address. So, I may use addresses that use the standard abbreviating techniques. If you don't know that, you'll want to review a tutorial on that before you spend much more time troubleshooting.
Your Wi-Fi card and router should also have a "link local" address. Each of these will start within the range of "fe80:something" through "febf:something" according to the relevant RFC section, although I typically see them start with just "fe80:" (and have seen Cisco training say that it starts with fe80:). You could try pinging that, which would help to confirm that IPv6 is functioning on the Wi-Fi card. Note that using link local addresses with ping may require specifying the interface. So, in Windows, instead of "ping -6 fe80::1", you may need to do "ping -6 fe80::1%24". The "24" in this case refers to the card number, which is the left number shown by the Interface list of Windows's "netstat -nr" output. I know this question was tagged "Windows 8.1", but I'll just quickly mention that if using Unix, your syntax might be something like "ping6 fe80::1%eth0" (named after your network adapter, which in Linux is often "eth0"). This is because if a computer has multiple NICs (e.g. Ethernet and Wi-Fi), the computer cannot use standard routing rules (by simply checking which subnet) to determine which NIC to use when sending to an address that starts with fe80:, because typically both cards are on an fe80: subnet. So you must specify.
Of course, one possible problem is ICMPv6 being firewalled. Maybe a bit unlikely, but worth checking out if IPv6 pings fail.
Most of the core IPv6 functionality is part of the TCP/IPv6 stack, which is typically part of the operating system. Another component is the TCP/IPv4 stack, which is also typically part of the operating system. Those stacks handle layer 3 and above of the OSI model. The difference between Ethernet and Wi-Fi is at layer 2 of the OSI model, and is typically handled by another piece of the operating system (perhaps a NIC driver? Or a binding?). So if you have TCP/IPv6 working with Ethernet and you have Wi-Fi working, then the necessary components of the networking software are all tested. The big point of potential failure is how the OSI layer 3 and OSI layer 2 interact. That is affected by having the network card configuration (which is mostly layer 2 stuff) have just a little bit of OSI Layer 3 detail. That is the part in all this which is likely to be broken. In simpler terms, the way to have all this work is typically to just make sure that the network card is being assigned the right details regarding the IPv6 address and subnet size (also known as a "prefix length" especially in IPv6, or commonly a "subnet mask" in IPv4). And the "default gateway" is needed for routing, but an incorrect setting on that shouldn't affect your ability to communicate with devices that are on the same link (using addresses that are in the same subnet).