[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 <[email protected]> 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. " _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
