Le 2012-03-23 à 10:16, <mohamed.boucad...@orange.com> a écrit : > Hi Rémi, > > This is well understood. The issue and the behaviour you are describing is > common to all address sharing solutions with or without NAT; including all > A+P flavours (MAP, 4rd, SDNAT). > > The point is: ** IF ** the issue raised by Washam is judged ** SEVERE ** > issue, consider the solution presented in > http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2.
In this context, the important consideration is AFAIK that it is completely acceptable to lose fragmented packets that, with bad luck, happen to be routed via distinct BRs when there is a route change. Frequent route changes would have many more severe consequences than this one if considered normal. Do we agree on this? Cheers, RD > > Cheers, > Med > >> -----Message d'origine----- >> De : Rémi Després [mailto:despres.r...@laposte.net] >> Envoyé : vendredi 23 mars 2012 10:02 >> À : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : GangChen; Softwires >> Objet : Re: [Softwires] Fragmentation in sdnat-02 >> >> Hi, Med, >> >> Thanks for this question. >> >> 1. As we know, all fragments of a packet from a given >> off-domain host to a given in-domain IPv4 address usually >> enter the domain via the same BR. (Otherwise packet >> disordering would badly disrupt TCP). >> >> 2. When fragments of a packet enter a domain via distinct BRs >> (e.g. due to some change in routing or load balancing >> information bases), the algorithm of >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >> ion-4.5.2. (3) is such that the packet will be lost: >> - A fragments going via a BR that didn't receive the first >> fragment is discarded by this BR. This results from the last >> column of the decision table. >> - Reassembly in the destination becomes therefore impossible. >> OK? >> >> >> Cheers, >> RD >> >> Le 2012-03-22 à 08:51, <mohamed.boucad...@orange.com> >> <mohamed.boucad...@orange.com> a écrit : >> >>> Dear Gang, >>> >>> Thanks, but I failed to find the text describing how to >> handle two fragments received by two distinct BRs. >>> >>> Could you please point me to that text in case I miss it? >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : GangChen [mailto:phdg...@gmail.com] >>>> Envoyé : jeudi 22 mars 2012 08:33 >>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : Washam Fan; Softwires >>>> Objet : Re: [Softwires] Fragmentation in sdnat-02 >>>> >>>> 2012/3/21, mohamed.boucad...@orange.com >> <mohamed.boucad...@orange.com>: >>>>> Dear Washam, >>>>> >>>>> This is an issue common to all stateless solutions, >>>> including deterministic >>>>> NAT with (anaycast) IPv4 address pool. >>>>> >>>>> FWIW, we recorded this issue here: >>>>> >> http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. >>>>> >>>>> As a solution to this issue, we proposed to implement the >>>>> fragmentation-related function in one single node: any >>>> received fragment is >>>>> redirected to a dedicated node which will be responsible for >>>> reassembly or >>>>> forward the fragment to the appropriate CPE. This node >> must dedicate >>>>> resources to handle out of order fragments. >>>> >>>> FYI, I see another approach doing that with a entry table + >>>> redirection action, similarly like >>>> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect >>>> ion-4.5.2. >>>> >>>> BRs >>>> >>>> Gang >>>> >>>>> Saying that, I can not quantify the severity of this issue in all >>>>> operational networks. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : softwires-boun...@ietf.org >>>>>> [mailto:softwires-boun...@ietf.org] De la part de Washam Fan >>>>>> Envoyé : mercredi 21 mars 2012 07:25 >>>>>> À : Softwires >>>>>> Objet : [Softwires] Fragmentation in sdnat-02 >>>>>> >>>>>> Hi Authors, >>>>>> >>>>>> In section 3.2, it states IPv4 address pool should be >> anycasted. This >>>>>> introduces a risk where different incoming fragments go >> to different >>>>>> AFTRs. Because one IPv4 address is shared between multiple >>>>>> subscribers, reassemly is needed on AFTRs when receiving >>>> fragments. If >>>>>> different fragments go thru different AFTRs, the >> reassmely process >>>>>> would fail and incur DoS. >>>>>> >>>>>> Thanks, >>>>>> washam >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
