Re: issue 3 - nats

 In your previous mail you wrote:

   Resolution:
   
    (a) Can we move behind a NAT?
          [Yes. But requires NAT-D payloads in the address change
          message, as discussed under issue 11.]
   
=> NAT-D or NAT-P (both detect NATs), see item j.

    (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.]
   
=> what is the real meaning of the question (NAT-T one side,
MOBIKE the other side?)

    (e) If we are behind a NAT on one interface, can
         another interface work without NAT/NAT-T?
         [Yes.]
   
=> I disagree if this gives extra complexity.

    (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.]
   
=> I don't see the interest to support this very limited scenario.

    (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.]
   
=> NAT-D or NAT-P

    (k) Is NAT-T support still optional within MOBIKE?
         [Yes. You should be able to use MOBIKE in plain v6 environments,
         for instance.]
   
=> the IPv6 case is very important because of the use of IPsec by MIPv6
(a MIPv6 Home Agent and a MOBIKE Security Gateway is nearly the same
thing) and of the style of multihoming used for IPv6.

Regards

[email protected]