Re: issue #16

Hi Hannes, and thanks for summarizing! Inline:

> a) mobike might get information from other protocols. this might indicate
> that there is something wrong with the currently selected preferred address.
> mobike does not specify with which protocols it needs to interact and it
> does not specify the policy for changing the preferred address. this is
> implementation dependent. 

Right.

> b) there is also a mechanism to detect that something happened along the
> path between the ikev2 initiator and the ikev2 responder using some sort of
> message exchange (we called it dead-peer detection - which is not the best
> name for it; sctp folks called it heartbeat).
> this message exchange might reveal that something is wrong along the path
> between from a given source address towards a destination address. this
> might require a new preferred address to be selected. this new preferred

Yes.

> address needs to be communicated to the other ikev2 peer. 

Note: this might also be an address that both peers already know
about, but they have been using the one that is now in trouble,
according to DPD.

> the format of these messages will be found in a mobike specification. 
> 
> btw, we are not the first discussing this area. there has been a lot of work
> in the context of sctp on this issue. i have the impression that they have
> the same view on it.

Yes.

> hence, i think that there are not particular problems here

I agree.

--Jari