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
