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. 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
