-------------------- Jari Arkko (2005-10-19): https://www.machshav.com/pipermail/mobike/2005-October/001133.html *imprecise explanation of what nat cases are not supported* > "Does not fully support" means that no special effort is made to > support this functionality. However, if the alternative is losing > connectivity completely, the responder can still attempt to proceed > with the change, and depending on, e.g., the exact type of NAT, it > may succeed. However, analyzing the exact circumstances when this > will or will not work is not done in this document. > > I'm OK with the text being vague about the type of scenarios supported beyond the basic client-inside-NAT case. However, the above text appears to say that the responder is capable of detecting such situations, which I don't think is at least always true. -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001165.html Here's some proposed text: "Does not fully support" means that no special effort is made to support this functionality. However, if the alternative is losing connectivity completely, the responder can still attempt to proceed with the change, and depending on, e.g., the exact type of NAT, it may succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. => "Does not fully support" means that no special effort is made to support this functionality. Responders may also be unaware of NATs or specific types of NATs they are behind. However, when a change has occurred that will cause a loss of connectivity, MOBIKE responders will still attempt to inform the initiator of the change. Depending on, e.g., the exact type of NAT, it may or may not succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001203.html Works for me. --------------------