Hi, Ole, FWIW, a look at https://tools.ietf.org/html/draft-ietf-softwire-4rd-09#section-4.6.3 might be helpful.
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
