Remove private-use values from IKEv2

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

Private-use values for payloads, attributes, and so on lead to lack 
of interoperability and are not needed. The only time private-use 
numbers should be used is for limited testing experimental changes to 
IKE, but such testing can just as easily be done using vendor-id 
payloads. For example, a message with a particular vendor ID payload 
could mean "ignore the encryption algorithm specified in the SA 
payload and use WhizzyAlg-128 instead."

The IETF has a long history of problems with private-use anything. 
Because implementations often get out of the laboratory, there are 
often value clashes. Worse yet, there often demands that, because so 
many people are using private value xyz to mean the abc feature, we 
should not give abc a regular value when it becomes an RFC, we should 
keep using xyz (or at least say in the RFC that xyz is equivalent to 
the new number).

Real testing of new algorithms (as compared to the more common "early 
implementation") is rare, and when it happens, it is quite easy to 
control with vendor ID payloads.

Note that, if private-use payload types are forbidden, there is no 
longer any use for the critical bit. In that case, the critical bit 
should be removed from IKEv2 in order to make the protocol simpler.

--Paul Hoffman, Director
--VPN Consortium