Issue 35: Adding version number to MOBIKE_SUPPORTED

[email protected] writes:
> If someone later creates a version of MOBIKE with more
> functionality (or something), we could always negotiate the
> support for it the same way we do now (add a new notification
> payload).  I don't quite see what would be the advantage
> of creating a separate negotiation mechanism just for MOBIKE...?

Because I do not want to see:

      HDR, SAi1, KEi, Ni,
           N(MOBIKE_SUPPORTED),
	   N(MOBIKE_SUPPORTED_VER01),
	   N(MOBIKE_SUPPORTED_VER02),
	   N(FOO_SUPPORTED_VER00),
	   N(BAR_SUPPORTED),
           [N(NAT_DETECTION_*)]  -->


etc....

Like you already see in IKEv1 NAT-T. Implementations send out lots of
different vendor IDs.

I think our current implementation sends 5 different NAT-T IKEv1
vendor ids:

md5(draft-stenberg-ipsec-nat-traversal-02)
md5(draft-huttunen-ipsec-esp-in-udp-00.txt)
md5(draft-ietf-ipsec-nat-t-ike-02)
md5(draft-ietf-ipsec-nat-t-ike-03)
md5(RFC 3947)

and there is even some vendors sending out vendor id's for
md5(draft-ietf-ipsec-nat-t-ike-0{4,5,6,7,8}) even when those documents
didn't have the vendor ID defined, so nobody would ever implement
them.

I really do not want to that happen to MOBIKE too. Adding 4 bytes of
version number to the payload is quite easy way to fix that. 
-- 
[email protected]