--------------------

Jari Arkko (2005-10-19):
https://www.machshav.com/pipermail/mobike/2005-October/001133.html

*RR requirements according to earlier decisions*

>   Both parties can optionally verify that the other party can actually
>   receive packets at the claimed address.  This "return routability
>   check" can be done before updating the IPsec SAs, immediately after
>   updating them, or continuously during the connection.
>
>   By default, the return routability check SHOULD be done before
>   updating the IPsec SAs.  In environments where the peer is expected
>   to be well-behaved (many corporate VPNs, for instance), or the
>   address can be verified by some other means (e.g., the address is
>   included in the peer's certificate), the return routability check MAY
>   be omitted or postponed until after the IPsec SAs have been updated.
>  
>
I think we decided earlier that the RR checks are by default
on, and that they are by default done before updating the
SAs. The above text seems to omit the former default. Suggested
fix:

   Both parties can optionally verify that the other party can actually
   receive packets at the claimed address.  By default, this "return
   routability check" SHOULD be performed. In environments where the
   peer is expected to be well-behaved (many corporate VPNs, for instance),
   or the address can be verified by some other means (e.g., the address is
   included in the peer's certificate), the return routability check MAY
   be omitted.

   The check can be done before updating the IPsec SAs, immediately after
   updating them, or continuously during the connection. By default, the
   return routability check SHOULD be done before updating the IPsec 
   SAs, but in some environments it MAY be postponed until after the
   IPsec SAs have been updated.

--------------------