Subject: [Ietf-behave] Re: [midcom] Results on draft-jennings-midcom-stun-results-01.txt

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Oct 2004 15:46:21 -0700 (PDT)

This may just be broken in win stun - I'm not sure.

WinStun does several test in parallel and that results in one of the test
interfering with a later one. To avoid these interferences, it uses
different ports for some of the test. I have not looked at it in a long
time. More resent version of the command line version of this support using
multiple IP address (on the client) - you need 3 ip address now to
differentiate all the various types of NATs that have been encountered.

Cullen

PS - moved this thread to behave list ...

On 9/4/04 7:47 PM, "Tony Yat-Tung Cheung" <tony.cheung@xxxxxxxxxxxx> wrote:

> Hi,
> 
> Thanks. I also see that the discovery algorithm has be removed from
> draft-rosenberg-rfc3489bis-00. So I think the discovery algorithm will
> not be standardized in any time soon then.
> 
> Still, I am interested in know the original algorithm in RFC 3489. I
> found that the implementation of WinStun uses a certain source port to
> send Test I, but a different source port to send Test II and Test III.
> Other implementation uses the same port to send all STUN requests for
> discovery. They each yield different result for the same NAT I have
> tried them on.
> 
> In my opinion, the STUN discovery should follow the application (such
> as RTP) closely.
> So I think all STUN requests should be sent from the same source port.
> 
> Thank you.
> 
> Best Regards,
> Tony Yat-Tung Cheung
> 
> On 5 Sep 04, at 2:47 AM, Christian Huitema wrote:
> 
>> 
>>> I also have a question on the NAT discovery in RFC 3489. For the NAT
>>> discovery procedure, should all STUN requests be sent from the same
>>> source port?
>> 
>> The main value of STUN is to unambiguously define the message formats
>> used in the protocol, and the server responses to these messages. The
>> discovery algorithm is, IMHO, less useful.
>> 
>> The algorithm in RFC 3489 is based on a categorization of NAT that was
>> state of the art three years ago. As our knowledge progresses, we may
>> expect implementers to try better algorithms. As long as they don't
>> change message formats and server behavior, this will not break
>> interoperability.
>> 
>> -- Christian Huitema
> 
> 
> _______________________________________________
> midcom mailing list
> midcom@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/midcom