Understanding the Tests¶
We give only a short overview of the tests here, parts of the text have been borrowed from the document mentioned above.
We suggest you first check the details of every test in ft6’s user interface, which will hopefully make the internals of the test clear enough.
If you would like to get additional information we encourage you to read EANTC’s pdf.
This test verifies that the firewall is able to filter and forward certain ICMPv6 Messages.
Some ICMPv6 must never be filtered (like echo request and echo response),
some must always be filtered (you wouldn’t want anyone to map your internal network by sending Neighbor Discovery messages over the internet),
and the rest may or may not be forwarded.
ft6 sends every ICMPv6 Message to see how the firewall behaves.
Type 0 Routing Header¶
The Type 0 Routing Header (RH0) has been deprecated due to security concerns.
With RH0 it was possible to specify what nodes a packet should visit on it’s way from the source to the destination.
You could also configure loops, thus causing traffic congestion.
Whether to forward or drop a packet containing a routing header is dependant on the value of the segments-left field.
Also, your firewall should be able to filter based on the value of the type field, as other routing headers might be desired (such as type 2, used for IPv6 Mobility).
Header Chain Inspection¶
With IPv6 there have been introduced a number of Extension Headers that may or may not be present in each IPv6 datagram.
There is a restriction on the order in which these headers may appear. ft6 sends a selection of valid and invalid packets.
When a node receives overlapping fragments it is possible that the “later” fragments overwrite data from “previous” fragments.
This can have considerable implications when the TCP destination port is overwritten.
Your firewall should be able to detect and drop overlapping fragments but still permit non-overlapping fragments.
Tiny Fragments are fragments that don’t have a TCP or UDP header in the first fragment.
The firewall has to wait for additional fragments until it can inspect the port to decide whether to forward or drop the packet.
A Firewall has to wait a maximum of up to 60 seconds for all fragments arriving.
If after 60 seconds not all of them have arrived, the firewall has to drop the whole packet.
Excessive Hop-By-Hop Options¶
Each Hop-By-Hop Option should occur at most once in any IPv6 packet (except paddings).
ft6 sends a variety of duplicate options to see if the firewall drops them.
Note: This test was specified by EANTC only for Hop-By-Hop Options header but is implemented for Destination
Options Header too (RFC4943, section 188.8.131.52).
PadN Covert Channel¶
The PadN Option is used in Hop-By-Hop Option and Destination Option Headers to align options at 8-byte boundaries.
The bytes used for padding are not interpreted according to the IPv6 standard but could be used to send messages covertly.
Note: This test is also executed for Pad1, which if it does not contain only zeros might not be a Pad1 Option anymore (see RFC2460, section 4.2).
Multicast addresses are not to be used as source addresses and link-local addresses should not be forwarded.