Replies to Scapy ICMPv6 Echo requests result in an ICMPv6 Parameter Problem message on Windows

Brief description

ICMPv6 Echo requests sent by Scapy on Windows result in an ICMPv6 Type 4 Parameter Problem error message being generated in response to the received reply. The messages are Code 1 (unrecognised next header). This occurs for echo requests generated and sent by Scapy as well as echo requests replayed by Scapy, where the original echo request/reply did not result in an error.

Scapy version

2.5.0.dev141

Python version

3.11.3

Operating system

Windows 11

Additional environment information

Tested on Windows 10 22H2 (Build 19045.3086) with Python 3.10.1 and Windows 11 22H2 (Build 22621.1992) with Python 3.11.3 using Scapy 2.5.0 and Scapy 2.5.0.dev141. Requires a network with functional IPv6.

How to reproduce

Scapy-generated packets

1. Start Wireshark (or another packet sniffer) and filter for ICMPv6 traffic (a capture filter of icmp6 and a display filter of icmpv6.type < 130 suffice)
2. Generate an ICMPv6 Echo Request in Scapy and send

pkt = IPv6(dst='google.co.uk') / ICMPv6EchoRequest()
res = sr1(pkt,timeout=1)

3. Observer a "Parameter Problem (unrecognized next header type encountered" message after the reply.

Scapy-replayed packets

1. Start Wireshark and filter for ICMPv6 traffic (a capture filter of icmp6 and a display filter of icmpv6.type < 130 suffice)
2. Generate an ICMPv6 Echo request and reply, e.g. by using ping from Powershell: ping -6 -n 1 google.co.uk
3. Copy the echo request packet from Wireshark: right click on the packet > "Copy" > "...as a Hex Stream"
4. Replay the packet using Scapy:

replay = Ether(bytes.fromhex("<paste copied packet here>"))
res = srp(replay,timeout=1)

5. Observe that the original echo/request did not result in a parameter problem, but the replayed packet did.

Actual result

This annotated screenshot shows the actual packets sent and received for a Scapy-generated ICMPv6 echo request, a Windows ping and a Scapy-replayed echo request:

Both echo requests emitted by Scapy resulted in a Paramter Problem error being sent in response to the ICMPv6 Echo reply.

The echo replies to the Windows ping (dumped as a hex stream):

3333ac62c9a133330000200386dd6000000000283a722a0014504009081e000000000000200320010db8000000002c198d90ac62c9a18100b3b900011c5d6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869

and the Scapy-replayed packet:

3333ac62c9a133330000200386dd6000000000283a722a0014504009081e000000000000200320010db8000000002c198d90ac62c9a18100b3b900011c5d6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869

are identical as expected, but the latter results in an ICMPv6 error being generated. The requests are also identical.

The generated errors state that an unrecognised Next Header type has been encountered in octet offset 6 of the reply.
The next header field in the packet that generates the error is correctly set to 58 (ICMPv6).

Expected result

ICMPv6 echo replies received in response to request sent by Scapy should not result in an error message being sent.

Related resources

Sanitised Pcap that contains the packets shown in the included screenshot: scapy-ping-anon.pcap.gz. Packets 1-3 capture a Scapy-generated ping (incorrect behaviour), packets 4-5 capture a Windows ping (expected behaviour), packets 6-8 capture Scapy replaying the Windows ping (incorrect behaviour).

Reproduce the issue on Windows using the Scapy snippets in the report and capture ICMPv6 traffic with Wireshark. Compare the Scapy-generated and replayed packets with the PowerShell ping capture and the supplied pcap, then trace the relevant Scapy packet-sending path. Done means Scapy echo replies no longer trigger an ICMPv6 Type 4 Parameter Problem message.