Dear Med, Yes. There are no texts targeting to this topics. I mean we could leverage the consideration in 4rd-U to build a entry table. One more REDIRECTION action obviously should be added to the row of "RESULTING ACTIONS". Any received fragment looking for conditions and execute a proper action(forwarding or redirection)
BRs Gang 2012/3/22, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>: > 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
