Steve,
We are not talking about changing AH v1; we are discussing AH v2. To correctly implement AH v2, one already has to be able to accommodate 64 bit sequence numbers, vs. the 32 bit sequence numbers in v1. AH v2 is still an I-D, not an RFC. So, while a change in whether to include the flow label in the ICV would make v2 not backward compatible with v1, v2 is already not backward compatible with v1 due to the required sequence number support difference.
I think the word "compatible" is inadequate to describe the situation completely.
It is true that AHv2 defines 64 bit sequence numbers, but the last time I looked at the draft, the extended sequence number space was an option that was only used when peers agreed to use it. So AHv2 still supports the old 32 bit sequence numbers too. The use of the 64 bit range is negotiated in IKE, and it is not used if either side wants to avoid it. I think this applies to the other changes of AHv2 as well.
Note that the 64 bit sequence number option is the default for IKEv2. We have no other way to signal use of the newest versions of these protocols, so the sequence number option really acts as a signal, at least for AH. It is not clear that there are any backwards compatibility problem re the current and next versions of AH, if we don't make this change. ESP might be an issue, depending on how folks react to receipt of the "no next protocol" header, etc.
This leads me to believe that AHv2 is an *extension* of AHv1, and an AHv1 implementation can still work well together with an AHv2 implementation. To put it in another way, an AHv1 implementation may not fullfill all the requirements of AHv2, but an AHv2 implementation will fulfill all the requirements of AHv1. Correct?
see above comments
If so, the change of the flow label ICV calculation rules would break this compatibility between AHv1 and AHv2. I think we need to be careful when making such changes. Is it really necessary? Will AHv2 use a different protocol number as Itojun suggested, or will the use of the new ICV calculation rules be signalled in IKE? Otherwise it is not possible to have interoperability. OTOH, assuming we need to allocate new protocol numbers or add yet another negotiation parameter, are the benefits of the change worth the cost?
same protocol number, unless someone says something very soon!
Yes, the question is whether it is worth whatever cost (new protocol number or lack of backwards compatibility) we incur. I'm not sure it is. I just want to make sure that the IPsec and IPv6 WGs have a chance to explore the issues before we declare AH done. Note that the current text MUST be changed, as it gives the wrong reason for not including the flow label under the ICV. So, we either change the rationale provided, or we change how we handle the field. All I was asking was which of these would folks prefer.
Steve
Steve
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
