It might be worth understanding why this problem is even worth addressing/mentioning.
Is the possibility of 2 or more host devices (behind 2 or more MAP CE routers) sharing the same IPv4 address would be "generating the fragmented packets" towards the same destination around the same time, not close to zero due to PMTUD etc.? AFAIK, RFC6888 doesn¹t mention such a problem or requirement for CGN? IMO, there shouldn¹t be any normative recommendation, if this problem is mentioned. -- Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Ted Lemon <[email protected]> Date: Tuesday, October 14, 2014 at 9:32 AM To: Ole Troan <[email protected]> Cc: Softwires-wg list <[email protected]> Subject: Re: [Softwires] MAP draft 11 question on fragment ID space reduction >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
