Yoav Nir writes: > In IKEv1 capabilities were usually declared in VendorIDs. In IKEv2 > they are mostly declared in notifications within IKE_SA_INIT. Why > the difference? No idea. It’s just the way other extensions were > done, but with a private extension you can do either.
Actually in both IKEv1 and IKEv2 you use VendorIDs if you use private use number space. I.e. if you decide to use private use notify number, or private use payload numbers then you need to sue VendorIDs in the IKE_SA_INIT before you send those private use values. I.e. the Vendor IDs are used to identify whose private use numbers you are using. The reason in IKEv2 we mostly use real IANA allocated status notifications is that the status notifications in the IKEv2 have IANA allocation policy of Expert review, i.e. they are easier to get. For IKEv1 the allocation policy was Specification required, which means you need to have some kind of public specification (RFC or similar) before you can get those. So because getting new status notifications is easier in IKEv2, we have added lots of features negotiated using them. As they have been used so much for extensions, they also have the benefit of backward compatibility, i.e if other end does not support them, implementations will simply ignore them (i.e. I would say all implementations knows how to ignore unknown status notifications). > Whether the parameters are passed in new payloads, Using new payloads might break some implementations, even when the specification says they should not break, but as they are not used that much in IKEv2 now, this is not something that vendors test against. > notify payloads or Config attributes is a matter of taste. > Generally, Config attributes are mostly for remote access and have > request-response semantics, so they’re somewhat negotiable. Lots of implementations support very fixed format for configuration payloads, and even though the IKEv2 format allows them to be used in different ways, most of the implementations only support very limited set of operations for them. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
