Le 27 oct. 2010 à 16:36, Lee, Yiu a écrit : > Hi Remi, >> >> The following alternative should IMHO be at least permitted: >> The IPv4 packet with DF not set is split into fragments small enough for >> each one to fit, with its encapsulation header, in the tunnel MTU. >> Thus: >> - Reassembly of IPv6 isn't needed at tunnel exit (simpler and causing >> less delays) >> - the overhead of the IPv6 extension header that is needed for >> fragmentation is avoided. >> > [YL] The fragmentation happens because of a tunnel between the B4 and AFTR > in the access network. I think this is the B4 and AFTR who created the > tunnel are responsible for fixing the problem.
> If B4 fragmented the v4 > packet, this is a possibility that the target server may drop the > fragmented v4 packet due to security concerns. I miss the point. I don't see why servers would refuse fragmented datagrams for security reasons. > This will affect the user > experience behind the b4. We did some scaling test on ISC AFTR > implementation and an open source B4 implementation. The fragmentation and > reassemble didn't create a lot of overhead especially the AFTR would > receive both v6 packets almost immediately. It doesn't require the AFTR to > buffer for too long. The behavior you described clearly makes sense. The point is ONLY that an alternative behavior, which also makes sense, should be authorized (not objected to by a "should") > [YL] Also, this will also require some logic in the B4 to check the DF bit > and make decision what to do. Right. That's indeed part of the alternative that IMHO should be authorized. >> The maximum number of ports that customers will be authorized to use, >> both on the average and individually, should IMHO remain free from any >> recommended numbers. >> Each provider will have to make its decision based on many parameters of >> its own. >> In particular, as IPv6 takes momentum, less and less IPv4 ports per >> customer will be needed over time. >> >> A proposal would be to delete the sentence as being out of scope. >> (No one who may have problems with a choice in the 3000-5000 range should >> be able to say that IETF is responsible, because of the "should".) >> > [YL] Agreed and will remove it from the next revision. Thanks, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
