On Fri, 4 Oct 2013, Valery Smyslov wrote:
So it may decide to fragment message too late. The only exception - the situation you described, when responder always sends messages fragmented. I think we may add this exception to responder's logic.
Okay.
I also think that PMTU discovery isn't very useful for IKE. That's why it is MAY.
That does not help implementors who still have to implement the MAY's. if even you as a document author does not think it is veru usefil, then I think it should just not be in the document.
I just don't like hardcoded values for message size, especially 576 bytes, as I couldn't find in the RFCs that IP datagrams of this size will pass anywhere. So, in my mind, we don't have safe low limit for IPv4. That's why I leave a small backdoor - PMTU discovery, that is not limited to any predefined value.
But the hardcoded value does not need to be set in stone for everyone. It can be a value of "at least X and at most Y", and then left to implementors and operational experience.
There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number and Total Fragments. But Total Fragments field plays a dual role if peer uses PMTU discovery - i.e. tries several fragment sizes. In this case Total Fragments allows to distinguish between fragments from different sets (assuming that trying smaller fragment size results in increasing number of fragments).
All the more reasons not to have PMTU dicovery. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
