RE: Issue: NAT-T interaction (#3)

I would say any solution we come up MUST work with NAT, maybe not
all types of NATs but at least basic NAT environment.

Rather than testing NAT existance after each address change I would
recommend us
consider forcing UDP wrapper on for all mobile cases. The pro is that the
connection
will be re-established with no additional signaling and it will work even
if NAT is added after address change without peers being aware of it. 
Of course the drawback is that we add extra 8 bytes to the data.

Regards!

/Jing


-----Original Message-----
From: Jari Arkko [mailto:[email protected]]
Sent: Monday, June 21, 2004 11:20 AM
To: MOBIKE Mailing List
Cc: Paul Hoffman / VPNC
Subject: [Mobike] Issue: NAT-T interaction (#3)



This is about the interaction with NAT traversal:
does the MOBIKE protocol work one one party goes behind NAT,
comes from behind NAT, or goes from one NAT to another?
There was a lot of discussion about this at Seoul, so it
is clearly an issue of concern to many people. Is limiting
our protocol to only working if there is no NAT might be
too restrictive because most users don't know when they
are behind a NAT, or are about to move to behind a NAT?

Or should MOBIKE and NAT-T be seen as alternative
solutions; if you enable NAT-T then you use just
that and live with its limitations & if you use
MOBIKE then you don't have a NAT?

In Seoul it seemed that the WG wanted MOBIKE and
NAT-T to work together. If so, would testing for
NATs occur after each address change?

[Reminder: our charter says we shall not replace
or modify NAT traversal, and that we should not
integrate the protocol tightly with NAT traversal.
However, we need to document how (and when) they
work together.]

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

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