Re: 55 - scope and limitations (marcelo's issue)

Looks good to me.

--Jari

[email protected] wrote:

>Here's a "slightly" edited version of the text. Does it look ok?
>
>--
>
>1.2.  Scope and Limitations
>
>   This document focuses on the main scenario outlined above, and
>   supports only tunnel mode IPsec SAs.
>
>   The mobility support in MOBIKE allows both parties to move, but does
>   not provide a "rendezvous" mechanism that would allow simultaneous
>   movement of both parties, or discovering the addresses when the
>   IKE_SA is first established.  This implies that MOBIKE is best suited
>   for situations where the address of at least one endpoint is
>   relatively stable, and can be discovered using existing mechanisms
>   such as DNS (see Section 3.1).
>
>   MOBIKE allows both parties to be multihomed; however, only one pair
>   of addresses is used for an SA at a time.  In particular, load
>   balancing is beyond the scope of this specification.
>
>   MOBIKE follows the IKEv2 practice where a response message is sent to
>   the same address and port from which the request was received.  This
>   implies that MOBIKE does not work over unidirectional paths.
>
>   NATs introduce additional limitations beyond those listed above.  For
>   details, refer to Section 2.3.
>
>   The base version of the MOBIKE protocol does not cover all potential
>   future use scenarios, such as transport mode, application to securing
>   SCTP, or optimizations desirable in specific circumstances.  Future
>   extensions may be defined later to support additional requirements.
>
>   Readers are encouraged to consult the MOBIKE design document [Design]
>   for further information and rationale behind these limitations.
>
>--
>
>3.1.  Initial IKE Exchange
>
>   The initiator is responsible for finding a working pair of addresses
>   so that the initial IKE exchange can be carried out.  Any information
>   from MOBIKE extensions will only be available later, when the
>   exchange has progressed far enough.  Exactly how the addresses used
>   for the initial exchange are discovered is beyond the scope of this
>   specification; typical sources of information include local
>   configuration and DNS.
>
>   If either or both of the peers have multiple addresses, some
>   combinations may not work.  Thus, the initiator SHOULD try various
>   source and destination address combinations when retransmitting the
>   IKE_SA_INIT request.
>
>---
>
>BR,
>Pasi
>
>
>  
>