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

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 <otroan@employees.org> 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 <Ted.Lemon@nominum.com> wrote:
>> 
>> On Oct 14, 2014, at 5:01 AM, Ole Troan <otroan@employees.org> 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
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires