Exotic IPv6 Packets: Hop-By-Hop Headers and Destination Options

More information

I am using thc-ipv6 v2.1 from here:

http://www.thc.org/thc-ipv6/

I am testing the firewall6 tool, which sends many different types of SYN packets via IPv6.

I have a netcat listener running on my Mac, listening on address 2::1 and TCP port 135.

I am using a Mac with OS X 10.7.5.

Here's a run of all the tests:

Here's a capture of test 1: a basic IPv6 SYN packet. It gets a SYN/ACK reply.

Here's a capture of test 3: an IPv6 packet with an error at layer 2--incorrect Type field of IPv4. It gets no reply.

Comment from a friendly network engineer:

That test is checking to see if a device, so to speak, blindly process a datagram. The only way a device has to determine the L3 is to look at the L2 first - in this case, the L2 says "IPv4" - so the packet should be dispatched to the IPv4 stack. Once that happens, the IP version is not actually 4, but 6 - hence it's dropped.

This is similar to another test - send the right ethertype for IPv6, send a valid IPv6 header - but as L4, and ICMP (v4) packet. See if you get a reply or not. In this case, the test is again to see if the stack on the receiving end just blindly dispatches the L4 payload w/o making sure L3 and L4 agree

Hop-by-Hop Options

Here's how the "Hop-by-Hop" header is specified by RFC 2460:

Here's the packet sent by firewall6, test 4. It uses the "Hop-by-Hop" Option.

The second header contains these eight bytes, as shown in the image below:

06 00 00 00 00 00 00 00

Wireshark interprets these in accordance with RFC 2460:

So the "Hop-by-Hop" Option here should be ignored. And so it is--the SYN packet receives a SYN/ACK reply just like a normal SYN packet.

Error Removed

Here I had a discussion of RFC 5095, under the mistaken belief that "Hop-by-Hop" Options were deprecated. But @pdbucan and @danride pointed out my error. Routing Header Zero was deprecated, but not "Hop-by-Hop" Options.
Mac OS X does the correct thing and replies with SYN/ACK.

Destination Options

Test 5 of firewall6 sends this packet:

This has a "Destination Options" header, as defined in RFC 2460:

So this sends options to be processed by the destination node, and the three options are empty padding, so this should have no effect.

Mac OS X does the right thing and replies with SYN/ACK.

130 Destination Options Headers

Test 8 of firewall6 sends this strange packet. It starts with a "Destination Options" header as before, but follows it with more "Destination Options" headers. All of them contain no useful data, just zeroes, as before.

(Note that "Destination Options" is indicated by code 60 in base ten, or 3c in hexadecimal.)

Way down at the bottom sits a normal TCP segment:

Although this is technically a correctly formed IPv6 packet, it does not get a reply from Mac OS X.

This could be regarded as a failure of the OS X implementation of IPv6.

Comment from a friendly network engineer:

OS/X uses the KAME stack (modified), and the number of Extension Headers is a configurable option - by default is 15 (sysctl net.inet6.ip6.hdrnestlimit). So any IPv6 packet with more than 15 extension headers (of any type) gets dropped.

And the reason to send 130 Destination Options EH is to try to "push the limits" for some devices - due to limitations, a device may decide to only parse up to X (X maybe 128) EHs, and then move on, even if it hasn't reached the ULP - Upper Layer Protocol. This focuses specially on firewalls and other packet filtering devices - if the device has a limit of 128 EHs, and "fails open", it may not enforce a configured policy.

2 KB of Destination Options

This packet is made by firewall6 test 18. It's so large, it is fragmented into two packets.

Wireshark reassembles the packets to show the combined IPv6 payload:

This packet has a single "Destination Options" header, followed by the TCP segment.

The first "IPv6 Option" is 2 bytes starting at offset 0002, as shown in the figure above.

The last IPv6 Option starts at offset 07f6, as shown below:

There are a total of 07f6 -2 = 2036 bytes of "IPv6 Option" fields in this reassembled IPv6 packet.

Once again Mac OS X fails to reply to this packet, which could be regarded as a failure to implement IPv6 correctly.

2 KB of Destination Options + Another Destination Options

This packet is made by firewall6 test 19. It's the packet that kills Kaspersky's firewall, as shown in the video below.

This packet is also fragmented into two packets. Wireshark reassembles them to show the structure.

First there's a single "Destination Option" header containing 2040 bytes.

Then there is a second "Destination Option" header.

This packet has a single "Destination Options" header, followed by the TCP segment.

Once again, Mac OS X fails to reply to this packet, which it should do.

32 2KB Destination Headers

This packet is made by firewall6 test 20. As you can see below, it takes 35 packets (#9 through #43) to transport this IPv6 message, which contains 32 Destination Headers, each 2 KB in size.

OS X fails to reply to this packet, so although it doesn't crash, it doesn't correctly find the TCP segment at the end either.

Posted 5:49 pm 3-30-13 by Sam Bowne
Mac OS X version added 3-31-13
Title changed 4-1-13
"More information" link added 4-1-13
Error saying "Hop-by-Hop: options were decrecated removed 4-2-13 (ty @pdbucan and @danride).
Comments from "a friendly network enginneer" added 4-4-14