Subject: [Mobike] issue 3 - nats

From: Jari Arkko <[email-masked]>
Date: Fri, 13 May 2005 13:04:39 +0300

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

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 May 2005 13:26:02 +0300

>   (h) Do we want to disable UDP encapsulation when moving outside

I agree on your suggestion for answers for those questions above. 

>   (i) Send keepalives on current or on all paths?

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.

>        [Yes. You should be able to use MOBIKE in plain v6 environments,

Agree on those again. 
-- 
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 May 2005 13:56:24 +0300

>this is related to issue 20.
Yes, that makes sense.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 15 May 2005 11:19:01 -0700

Jari,

Agreed.

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Sun, 29 May 2005 17:38:25 +0300

I believe we have now converged on this issue as well.
Tero posted a comment on the keepalive part,
which changed the original proposal a bit, however.

Note that this is still at a fairly high level. It seems likely
that we will hit more detailed issues in actual protocol
work. But it may be hard to do further discussion of this
part of the issue unless we have a concrete proposal
and see those detailed issues in front of us. So my
suggestion is that we move on and deal with those issues
separately if and when they arise.

Resolution:

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

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

--Jari