IPv6 Stateless Fragmentation Identification OptionsInternet Systems Consortium950 Charter StreetRedwood CityCA94063USmarka@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.
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
For IPv4 in IPv6 the IPv4 source and destination addresses
are needed.
For IPv6 in IPv6 the IPv6 source and destination addresses
are needed.
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.
Internet Protocol, Version 6 (IPv6) Specification