Agreed. But the problem is the NAT device doesn't know how much buffer it will need to reserve for de-fragmentation because it doesn't know how many times a packet got fragmented. This opens hole for "Fragmentation Buffer Full" attack. I am curious how today most home gateway handles v4 fragmentation from hosts?
On 6/2/10 8:11 AM, "Alain Durand" <[email protected]> wrote: > Except that, as the AFTR needs to NAT the packet back to the tunnel, it needs > to reassemble the packet first.. > > - Alain. > > > > On May 28, 2010, at 8:49 AM, Lee, Yiu wrote: > > Hi Taurn, > > So the v4 packet is fragmented by the remote host before reaching AFTR? If so, > the AFTR shouldn¹t wait but pass the fragmented packet untouched with > encapsulation. That said, the fragmented v4 packet could be fragmented one > more time in the AFTR after adding the v6 header overhead. B4 must reassemble > the v6 fragmented packets before sending to the host. It is the host > responsible for reassembling the v4 fragmented packets. > > Regards, > Yiu > > On 5/28/10 2:23 AM, "Tarun Saxena" > <[email protected]<x-msg://766/[email protected]>> wrote: > > Hello Alain, > > DS-Lite draft mentions that for big packets, v6 fragmentation must be > performed after encapsulation both at the B4 and AFTR. What is the expected > behaviour in case an already fragmented IPv4 packet is received at an > end-point? > > 1) Should the end-point wait for all the fragments to turn, reassemble > the packet and then encapsulate. > 2) Or, it should just handle fragments as ³normal² v4 packets and > encapsulate them. > a. What if the encapsulated fragment needs v6 fragmentation? > > Is there a take from the standards point of view, or are these details left > open for the implementation to do what it deems fit? > > Regards > Tarun Saxena > Ph +91 80 41904390 > Juniper Networks > > > ________________________________ > _______________________________________________ > Softwires mailing list > [email protected]<x-msg://766/[email protected]> > https://www.ietf.org/mailman/listinfo/softwires >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
