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#section-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
