When to do Return Routability Checks

hi all, 

i would like to close the 'When to do Return Routability Checks' issue
(which can be found at: 
http://www.vpnc.org/ietf-mobike/issue6.txt)

please take a look at previous text in the design document on this issue: 

"
3.2 When to do Return Routability Checks

   One of the decisions that needs to be done, when to do return
   routability checks. The simple approach is to do it always. 
                                                      ^^^^^^^^
[hannes] 'always' is not very precise. 

 Another
   option is to do it every time new IP-address is taken in to use.

[hannes] jari introduces useful terminology relevant for this sentence in
<draft-arkko-multi6dt-failure-detection-00.txt>. we might want to use some
of it in mobike. 

 The
   basic format of the return routability check could be similar than
   dead-peer-detection, but the problem is that if that fails then the
   IKEv2 specification requires the IKE SA to be deleted. Because of
   this we might need to do some kind of other exchange.

   If the other end is SGW with limited set of fixed IP-addresses, then
   the SGW can get certificate having all the IP-addresses in the
   certificate. If the certificate includes all the IP-addresses, it is
   no point to do weaker return routability check, the data in the
   certificate is already properly authenticated after the IKE SA is
   created, so the peer might simply use that and ignore return
   routability checks.

   Another option is to use draft-dupont-mipv6-3bombing
   [I.D.dupont-mipv6-3bombing] approach: do it only if you had to send
   the update from some other address than indicated preferred address.

   Final option would simply not to do return routability checks at all.
   If we use indirect change notifications then we only move to the new
   IP address after successfull dead-peer-detection on the new address,
   which is already return routability check. In the direct change
   notifications the authenticated peer have given out authenticated
   IP-address, thus we could simply trust the other end. There is no way
   external attacker can cause any attacks, but we are not protected by
   the internal attacker, i.e. the authenticatede peer forwarding its
   traffic to the new address. On the other hand we do know the identity
   of the peer in that case.
"

[hannes] the relationship between authorization and the aspect of timing
(WHEN to send return routability checks - if at all) needs to be separated. 

discussions during the ietf meeting (see issue tracker web page) concluded
that it is a policy issue when to perform the return routability checks.
this conclusion seems to be fine with me. i will try to produce a new text
proposal. 

ciao
hannes