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

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