Hi Remi, On 10/16/14, Rémi Després <[email protected]> wrote: > Hi, Ole, > > FWIW, a look at > https://tools.ietf.org/html/draft-ietf-softwire-4rd-09#section-4.6.3 might > be helpful.
This is exactly the problem. You replace the problem of a highly visited destination (for whom the natural path is to deploy IPv6 anyway and bypass the whole transition mechanism?) having potential for reassembly errors with a problem of N-fold increased fragment collision probability on *all* streams, where N is your share ratio, and which side of this tradeoff is worse is unclear to me - both are bad in different ways. Fortunately, since CGNs provide a higher sharing ratio of addresses (and they can't possibly rewrite the IDs because they do not have a deterministic algorithm), and are much more widely deployed than any of the tech we are discussing, we should have already hit this problem in real life many times over ? Any feedback on this ? --a > > Cheers, > RD > > > Le 15 oct. 2014 à 15:27, Ole Troan <[email protected]> a écrit : > >> Ted, et al, >> >> there are good arguments going both ways, so apologies for my changing >> opinion here. ;-) >> >> we could go with the hand-wavy, there is a problem here, we don't have a >> good solution: >> >> <t>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 could be used >> similarly to port ranges. A MAP CE could rewrite the IPv4 >> fragmentation identifier to be within its allocated port-set, >> if the resulting fragment identifier space was large enough >> related to the rate fragments was sent. However, splitting the >> identifier space in this fashion would increase the >> probability of reassembly collision for all connections >> through the CPE. See also <xref target="RFC6864"/></t> >> >> the alternatives are that we could say, since the problem of multiple CPEs >> with same IP address sending fragments to same destination required >> coordination that if the fragment id space was say 10 bits, then rewrite. >> or we could go even further and say that the CPE would have to throttle >> traffic to ensure that the id space didn't cycle within the reassembly >> timeout. >> or we could drop the text altogether. >> >> my preference would be the above proposed text. it has the problem >> description but it doesn't prescribe a solution. >> >> any other opinion? >> >> ps: whatever solution we have here should probably also apply to the other >> mechanisms. e.g. >> https://tools.ietf.org/html/draft-ietf-softwire-4rd-09#section-4.6.3 >> >> cheers, >> Ole >> >> >> >>> On 14 Oct 2014, at 15:32 , Ted Lemon <[email protected]> wrote: >>> >>> On Oct 14, 2014, at 5:01 AM, Ole Troan <[email protected]> wrote: >>>> 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? >>> >>> There's a lot to think about here. The fragment ID translation algorithm >>> probably needs to maintain a cache so that it doesn't accidentally >>> overload fragment IDs. The set of all outstanding fragments has the >>> potential to be larger than the set of all ports in use, so there is >>> definitely reason to be concerned about shrinking the fragment ID space. >>> However, shrinking the fragment ID space _does_ serve the useful purpose >>> of isolating fragment ID collisions to the nodes that are supposed to be >>> receiving the fragments. >>> >>> It may be that the right thing to do is to note that this is a problem, >>> make a recommendation, but essentially leave it as future research, since >>> we really haven't analyzed the problem in enough depth to make an >>> informed recommendation. >>> >>>> 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. >>> >>> So yes, this might be a good way to go. >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
