Internet Systems Consortium

950 Charter Street Redwood City CA 94063 US marka@isc.org

Fragmented IPv6 packets are often dropped because there is no way to identify whether a fragment matches a otherwise permitted packet as the L4 header information is not available on all the fragments. The document defines hop-by-hop options that can be used to supply the missing information in non initial fragments.

Fragmented IPv6 packets are often dropped because there is no way to identify whether a fragment matches a otherwise permitted packet as the L4 header information is not available on all the fragments. The document defines hop-by-hop options that can be used to supply the missing information in non initial fragments. The information required differs depending upon the L4 packet. For TCP and UDP the source and destination ports are needed. For ICMP the type of ICMP packet is needed. These options are expected to be used by middle boxes (firewalls and load balancers) and end nodes.

For TCP and UDP a skippable hop-by-hop option (for backwards compatibility) containing the source and destination ports from the TCP and UDP headers is needed. To permit the use of NATs, however undesired, the option contents are marked changeable enroute. The option code has mnemonic PORTS and value (TBD) and is added to all fragments of UDP and TCP packets when they are fragmented. By adding the option to all fragments you reduce the amount of fragmentation reassembly failures that would result if you only added the option to non-initial fragments and were dropping non-initial fragments without this option. NAT should update the port fields to match those in the TCP and UDP headers if it updates those fields as part of the NAT processing.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1| (TBD) | 4 | source port | +---------------+---------------+---------------+---------------+ | destination port | +-------------------------------+

To identify the type of ICMPv6 packet a fragment is part of the type and code values need to be copied from the ICMPv6 header. As with the TCP and UDP case, a skippable hop-by-hop option is required. ICMPv6 type and code points are not changed by NAT so a immutable hop-by-hop option could be used. In most cases a ICMPv6 error message won't need to be fragmented as the maximum size of a ICMPv6

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0| (TBD) | 2 | type | code | +---------------+---------------+---------------+---------------+

For IPv4 in IPv6 the IPv4 source and destination addresses are needed.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0| (TBD) | 8 | IPv4 source address ~ +---------------+---------------+---------------+---------------+ ~ IPv4 source address | IPv4 destination address ~ +---------------+---------------+---------------+---------------+ ~ IPv4 destination address | +---------------+---------------+

For IPv6 in IPv6 the IPv6 source and destination addresses are needed.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0| (TBD) | 32 | IPv6 source address ~ +---------------+---------------+---------------+---------------+ ~ IPv6 source address ~ +---------------+---------------+---------------+---------------+ ~ IPv6 source address | IPv6 destination address ~ +---------------+---------------+---------------+---------------+ ~ IPv6 destination address ~ +---------------+---------------+---------------+---------------+ ~ IPv6 destination address | +---------------+---------------+

Should this be a single hop-by-hop option or multiple hop-by-hop options? If a single hop-by-hop option, should it include the next header field of the fragment header or should this be implicit?

To be completed.

The use of these options will expose nodes to more fragmentation based attacks and potentially more traffic which will ultimately be dropped if a attacker can guess which option values will be permitted. With the exception of the fragmentation based attacks, permitting fragments with these options is no worse that permitting multiple un-fragmented packets based in the same parameters. When reassembling a packet all fragments of a packet should have a identical fragment identification option and it should be on all fragment or on none of the fragments. For TCP and UDP the ports values may or may not match up with those of the un-fragmented packet when the packet has been through a NAT. When a packet has passed through multiple NAT boxes that are unaware of this option both the source and destination ports may have been changed so the ports may appear to be completely unrelated. The source port is changed by a client NAT and the destination port is changed by a NAT acting a load balancer.