Dan Harkins writes: > The solution of allocating new numbers still doesn't really solve the > problem because if you receive an KE payload from group 19, 20, or 21 > "you can make your guess whether they also implemented errata or not, > and act based on that" and that sounds like a recipe for future > non-interoperability.
As I just noticed we do support RFC4753 without errata in our previous versions we need to do something on this. What my current plan would be to make patch that will change implementations to support errata, and also change the group numbers to new. This means you get no proposal support or invalid ke payload notification if you try to talk to old versions supporting groups 19-21. If the policy allows any of the modp groups then invalid ke payload error cause both ends to move to modp groups which means implementations can talk to each other, and if policy only allows those new groups then you get no proposal chosen and then you need to modify policy to support some common groups. > The IANA registry for these groups is used by more than just IKE(v2) > and it would be nice if it was coherent and did not make assumption like > that. ikev2-parameters IANA registry should not be used for anything else than IKEv2. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
