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. 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.
[YL] Also, this will also require some logic in the B4 to check the DF bit and make decision what to do. > >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, Yiu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
