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

[Ole Troan <[e-mail]>]

[resending to list, cause mailman whinged about too many in cc]
Andrew,

thank you for the comment. let me top-post my reply.

the scenario we were concerned about was where a number of CPEs would share the same IPv4 address, and where many of them would communicate with the same destination. if there wasn't a way to coordinate the fragment id space used, there would be a chance of the remote destination incorrectly reassembling packets. where one fragment would come from CPE #1 and the other from CPE #2.

there is a tradeoff between that problem and the problem you identify, that is risking fragment collision within one single connection.

splitting the fragment id space so that there is only a single bit per CPE sounds like a corner case that should be disallowed. I don't know if we have the knowledge to be able to specify exactly how much of the fragment id space is safe to split up though.is it 4, 6, or 8 bits?

if changing back to SHOULD from the MUST would lead people to accept that we leave the exact recommendations for further study I would be happy to do that.

I have cc'ed Ted who brought this up initially in his AD review, and I've also included Joe Touch in case he has further insights.

cheers,
Ole



> On 13 Oct 2014, at 19:22 , Andrew 👽 Yourtchenko <[e-mail]> wrote:
> 
> [ 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, if I
> understand it correctly.
> 
> 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 promised hyperbole: take a share ratio of 64K. One CPE gets a
> single 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. "