issue 4: how to signal support for MOBIKE

I don't think we officially closed this issue yet,
but it seems that when we discussed it in the past
meetings we converged on using the vendor IDs as
specified in the IKEv2 spec:

    A Vendor ID payload MAY announce that the sender is capable to
    accepting certain extensions to the protocol, or it MAY simply
    identify the implementation as an aid in debugging.  A Vendor ID
    payload MUST NOT change the interpretation of any information defined
    in this specification (i.e., the critical bit MUST be set to 0).

Pasi's draft contains an example of how this would be done for
MOBIKE:

    Implementations that support this specification MUST include a Vendor
    ID payload in the IKE_SA_INIT exchange (first two messages).  The
    value for this payload is XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX (TBD).

The other alternative that has been discussed is the
use of the critical bit. We would define a new payload
and mark it critical.

Here's my reasoning why the Vendor ID payload approach
seems slightly better: First, we need to remember that the
initial IKEv2 exchange is at least four messages. This
means that if we want to exchange capabilities and
addresses, we can exchange the capabilities in the first
round and then alternative address information in the
second round.

So I would suggest that we use the Vendor ID approach.
Below you'll find my suggested text for the design draft.
(A quick search revealed no previous text about the
matter, but I may have missed something.)

X. Indicating Support for MOBIKE

A node needs to be able to trust that its address
change messages are understood by the peer. Otherwise
an address change may render the connection useless,
and it is important that both sides realize this as
early as possible.

Ensuring that the messages are understood can in
be arranged either by marking some IKEv2 payloads
critical so that they are either processed or
an error message is returned, or by using Vendor
ID payloads. In the latter approach a specific
string denoting MOBIKE will signal the support
of the MOBIKE protocol. (Should there be optional,
separable parts in the protocol there may be a
need for more than one Vendor ID; this is left
for further study).

The recommended solution is to use Vendor ID
payloads during the initial IKEv2 exchange,
perhaps in the first round, so that the
second round can be used for actual MOBIKE
signaling, if necessary. This ensures that
in all cases a MOBIKE capable node knows
whether its peer supports MOBIKE or not.

If the peer does support MOBIKE, the node
can then use MOBIKE-specific messages
and payloads, with the critical bit set to
zero or one depending on the semantics
of the message. If the peer does not support
MOBIKE, then the node knows that, at least
without NATs, a movement implies need to
rerun IKEv2 from the start.

Note that the node could also attempt
MOBIKE optimistically with the critical
bit set to one when a movement has occurred.
The drawback of this approach is, however, that
the an unnecessary MOBIKE message round is
introduced on the first movement.