Subject: Atomic fragments (interoperability issues)

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Aug 2014 11:48:37 -0300

Folks,

This is some text we've drafted regarding the interoperability
implications of relying on IPv6 atomic fragments for translators. --
comments welcome.

---- cut here ----
   Besides the security assessment provided in Section 3, it is
   interesting to evaluate the pros and cons of having IPv6-to-IPv4
   translating router rely on the generation of IPv6 atomic fragments.

   Relying on the generation of IPv6 atomic fragments implies a reliance
   on:

   1.  ICMPv6 packets arriving from the sending node to the destination
       node

   2.  Nodes receiving ICMPv6 PTB messages reporting an MTU smaller than
       1280 bytes actually producing atomic fragments

   3.  Support for IPv6 fragmentation on the IPv6 side of the translator

   Unfortunately,

   o  There exists a fair share of evidence of ICMPv6 Packet Too Big
      messages being dropped on the public Internet (for instance, that
      is one of the reasons for which the [RFC4821] was published).
      Therefore, relying on such messages being successfully delivered
      will affect the robustness of the protocol that relies on them.

   o  A number of IPv6 implementations have been known to fail to
      generate IPv6 atomic fragments in response to ICMPv6 PTB messages
      reporting an MTU smaller than 1280 bytes [RFC6946] [Morbitzer].
      Additionally, results included in Section 6 of [RFC6145] note that
      57% of the tested web servers failed to produce IPv6 atomic
      fragments in response to ICMPv6 PTB messages reporting an MTU
      smaller than 1280 bytes.  Thus, any protocol relying on IPv6
      atomic fragment generation for proper functioning will have
      interoperability problems with the aforementioned IPv6 stacks.

   o  IPv6 atomic fragment generation represents a case in which
      fragmented traffic is produced where otherwise it would not be
      needed.  Since there is widespread filtering of IPv6 fragments in
      the public Internet [I-D.gont-v6ops-ipv6-ehs-in-real-world], this
      would mean that the (unnecessary) use of IPv6 fragmentation might
      result, unnecessarily, in a Denial of Service situation even in
      legitimate cases.

   [RFC6145] is currently the only "consumer" of IPv6 atomic fragments,
   and it correctly and diligently notes (in Section 6) the possible
   interoperability problems of relying on IPv6 atomic fragments,
   proposing as a workaround something very similar to what we proposed
   in Section 6.  We believe that, by making the more robust behavior
   the default behavior of the "IP/ICMP Translation Algorithm",
   robustness is increased, and the corresponding code is simplified.
---- cut here ----

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492