issue 3 - nats

Jari Arkko writes:
>   (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. Does not require much. But see item h.]
>   (c) To which extent do we support the case that
>         party outside the NAT moves?
>         [No. This one is really hard. We will make our life much
>         simpler by saying no here. 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. Contrary to mobility, multihoming is possible
>         quite easily. Detailed protocol design has some further
>         details that need to be developed later, e.g., is there
>         a need to do keepalives on all address pairs? Tentatively,
>         the answer to that is no.]
>   (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 agree on your suggestion for answers for those questions above. 

>   (i) Send keepalives on current or on all paths?
>        [To be decided later.]

Yes, that depends quite a lot about protocol, but if it ends up to be
initiator decide style protocol, then the answer will most likely be
no. If it is going to be so that both ends can decide which pair of
addresses to use, then we must also send keepalives on all paths. So
this is related to issue 20.

>   (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.]

Agree on those again. 
-- 
[email protected]