Hi, Alexey Thanks for your reply! > 3 Every time the source output the data packet, it should check each SA > associated with the specific secure policy. If it find any one > xfrm_state has the meaningful pmtu value, then it should calculate the > resulting PMTU and send <<ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED>> message > to the real source in the secure policy selector. This checking point > should be in function: dst_output();. I am not so sure about this. First (and a bit different) thing: pmtus of SAs should be taken into account when we calculate dst->pmtu. So, each pmtu event should cause recalculation of dst->pmtu on the bundle. It is necessary, when tunnel is used for locally generated packets, we should prepare good frames which will not fail while being transformed. I think I must have overlooked something, but I can't figure out why it is necessary to recalculate dst->pmtu on the bundle when each pmtu event occurs. What's the special aspects related with dealing with locally tunneled packets? Thank you very much for your detailed explanation. The second thing is painful. We have to send icmp for original packet as it entered our host. So, pmtu checks at each trnasformations is not so easy. There are two variants: one was suggested by Dave, namely, we store required 8 octets of original skb somewhere in skb head and proceed like you proposed, checking that transformed skb still fits to pmtu. The second variant is just to check against precaluclated dst->pmtu on the entry to dst_output() before doing transformations. Logically it is cleaner, it is simpler and faster, but it will result in underestimation of mtu for esp due to alignment paddings and for IPCOMP it will be totally unfair. Actually, it was the point where Dave, James and me stopped. Dave's variant looks more promising. I agree with you and vote for Dave's variant! I omitted the alignment padding issues previously. Then since Dave's variant is a good solution for handling PMTU in IPsec for IPv4, do you think it's appropriate if I write some patches for it now? Is there any other tricky issue to be resolved for handling PMTU in IPsec for IPv4 until now? Thanks, Forrest - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
