[Softwires] MAP draft 11 question on fragment ID space reduction

[Andrew 👽 Yourtchenko <[e-mail]>]

[ resending the full mail including the softwire maillist, not just
the authors ]

Hello,

In http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-11

A change in "8.3.3. Sending IPv4 fragments to the outside" from
"SHOULD" to "MUST" jumped at me, which caused to think more about this
paragraph.

This paragraph says now:

"If two IPv4 host behind two different MAP CE's with the same IPv4
   address sends fragments to an IPv4 destination host outside the
   domain, those hosts may use the same IPv4 fragmentation identifier,
   resulting in incorrect reassembly of the fragments at the destination
   host.  Given that the IPv4 fragmentation identifier is a 16 bit
   field, it can be used similarly to port ranges.  A MAP CE MUST
   rewrite the IPv4 fragmentation identifier to be within its allocated
   port-set."

I'd argue that setting it to "MUST" tries to solve a corner case but
in return introduces a much worse behavior for the common case.

I'll use a slight hyperbole to illustrate the worst case of such an
impact for a common case.

First, implementation-wise: I assume the CPE would take the frag ID
and apply modN operation where N is the share ratio, and then shift
the frag ID into correct space.

Now, the hyperbole: take a share ratio of 64K. One CPE gets a
single TCP/UDP port, and a single fragment id to peruse.

And, from a host behind one of these CPEs you open a TCP session to
another host on IPv4. You start sending a file. Your TCP window grows
beyond a single segment, and you send 4 fragments - 2 per segment, and
because of the rewriting they all get the same IP ID. As a result the
destination can not reassemble the packets.

Note that this is a typical case - no collision, no two hosts opening
a session. It gets affected.

This is of course a hyperbole to show the problem.

The smaller share ratio makes the problem less acute, but even with
16-bit space and even some years ago [1] there were problems. So given
that the broadband speeds multiplied in the meantime, shrinking the ID
space will make the problem worse.

Since it looks like the fragment value does not affect the interoperability, I'd
request to put this back to "SHOULD" (arguably it even be relaxed to
"MAY", given the severity of the issue above), and let the
implementers themselves consider whether it is worth doing or not.

[1] https://tools.ietf.org/html/draft-mathis-frag-harmful-00

Thanks!

--a

p.s. a cosmetic nit: looks like the following sentence in section 5.2
has an extra "that":

"The Rule IPv6 prefix (which is part of the End-user IPv6 prefix) that
   is common among all CEs using the same Basic Mapping Rule within the
   MAP domain. "