Re: issue 3 - nats

Jari,

Agreed.

-mohan


> Does this cover everything, or do we have additional questions?
> Here are also some tentative answers to the questions:
> 
>   (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) Send keepalives on current or on all paths?
>        [To be decided later.]
>   (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
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike