Re: issue 3 - nats

I believe we have now converged on this issue as well.
Tero posted a comment on the keepalive part,
which changed the original proposal a bit, however.

Note that this is still at a fairly high level. It seems likely
that we will hit more detailed issues in actual protocol
work. But it may be hard to do further discussion of this
part of the issue unless we have a concrete proposal
and see those detailed issues in front of us. So my
suggestion is that we move on and deal with those issues
separately if and when they arise.

Resolution:

 (a) Can we move behind a NAT?
       [Yes. But requires NAT-D payloads in the address change
       message, as discussed under issue 11.]

 (b) Can we move out from a NAT?
       [Yes. But see item h.]

 (c) To which extent do we support the case that
       party outside the NAT moves?
       [No. Outsider may not be able to initiate anything
       inside. The only exception is covered under
       item f.]

 (d) If we are behind a NAT, can peer have multiple
       addresses?
       [Yes.]

 (e) If we are behind a NAT on one interface, can
      another interface work without NAT/NAT-T?
      [Yes.]

 (f) Can the responder be behind a NAT?
      [Yes, but in a very limited scenario, when the NAT is
      a static NAT and not a NAPT.]

 (g) Do we need NAT prevention?
       [Yes.]

 (h) Do we want to disable UDP encapsulation when
       moving outside from behind a NAT?
       [Yes.]

 (i) Send keepalives on current or on all paths?
      [Just the current one, as the "initiator decides"
      solution that we have picked in issue 20 makes
      this the logical choice here.]

 (j) How do we detect NATs?
     [Using NAT-T functionality.]

 (k) Is NAT-T support still optional within MOBIKE?
      [Yes. You should be able to use MOBIKE in plain v6 environments,
      for instance.]

--Jari