issue 3 - nats
Jari Arkko <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
Some personal thoughts on solutions for this issue:
We have consensus that MOBIKE and NAT-T need to
work together. It seems like the core of the remaining
issue is "what exactly does this mean" and "what can we
achieve, given protocol and other limitations".
One way to approch these questions is to try to break
down the problem in smaller pieces. For instance, I
believe the following questions have been asked at
one point or another during the discussion:
Scenarios that we can support
(a) Can we move behind a NAT?
(b) Can we move out from a NAT?
(c) To which extent do we support the case that
party outside the NAT moves?
(d) If we are behind a NAT, can peer have multiple
addresses?
(e) If we are behind a NAT on one interface, can
another interface work without NAT/NAT-T?
(f) Can the responder be behind a NAT?
New functionality
(g) Do we need NAT prevention?
(h) Do we want to disable UDP encapsulation when moving outside
from behind a NAT?
Implementation
(i) Send keepalives on current or on all paths?
(j) How do we detect NATs?
Conformance requirements
(k) Is NAT-T support still optional within MOBIKE?
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