Probably the easiest way to recognize that a server is unresponsive is when there is a SYN packet from the client to the server followed by two TCP Retransmission SYN packets from the client to the server, and zero packets from the server back to the client. This situation means the server was totally unresponsive when the client was attempting to establish the TCP 3 way handshake connection.

Because a Wireshark capture can easily contains tens of thousands of packets, it's unreasonable to look through every line for retransmissions packets. Use the tcp.analysis.retransmission filter to see if your capture has any retransmission packets.

A bit more challenging situation to capture is when the client and server were able to established the connection via the TCP 3 way handshake. However, sometime after the connection was made, the server stops responding. In this type of scenario, we would find the 3 packets that make up the 3 way handshake.

While the server is still responding, we would see keep alive ACK request packets being sent from the client to the server and then the server responding with keep alive ACK response packets.

However, once the server stops responding, we would see many keep alive ACK response packets sent from the client to the server yet not keep alive ACK response packets from the server to the client. In another words, the server stops responding. We would also start to see RST ACK packets from the client to the server. RST means Connection Reset.

One possibility is that a firewall on the server was mistakenly configured to block incoming connections on the port.

Because a Wireshark capture can easily contains tens of thousands of packets, it's unreasonable to look through every line for a RST, ACK packet. Use the tcp.flags.reset==1 filter to see if your capture has any RST, ACK packets.

It could simply be the case that IPv6 address fd00::8 is not assigned to any host in the network.

On the other hand, in this example, there is a successful ping to fd00::8.