Subject: RE: [midcom] [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

From: "Yutaka Takeda" <[email-masked]>
Date: Fri, 13 Feb 2004 12:49:56 -0800

> > I think there is still some value in the NAT-type tests 
> even with use
> > of ICE. Positive assertions about traversable NATs may be brittle, I
> > agree. Negative assertions about hard-to-traverse NATs are 
> quite safe
> > and can eliminiate unnecessary tries. Particularly, if you know you
> > are behind a symmetric NAT you can safely eliminate STUN 
> address from
> > your offer.
> 
> I disgaree.
> 
> Cullen's results show that we are seeing hybrid NATs whose 
> type depends 
> on whether the random port selected by the client is 
> allocated already 
> or not. In such a case, if the client picks an already-allocated port 
> during the detection phase, it may detect the nat as 
> symmetric, when it 
> fact it might be port restricted in other cases.
> 
> With ICE, if you happen to be unlucky during a stun allocation, turn 
> would get used. If you're lucky, and you get a port-restricted port, 
> then the relay would not be used.

Cullen's results are also telling us that there are more chances for clients
to come across a symmetric case than we can see with current STUN 
test.

Since ICE has ability to traverse p2p UDP connection through a 
symmetric NAT if the other end does not have or does has a full-cone 
NAT or restricted, the results seem to motivate us more to go towards 
ICE.

Although ICE does this job without a knowledge of NAT types, I feel
it is good to have a standardized protocol to discover the types of 
NAT. In fact, we would have not been able to come to this point 
without the knowledge of NAT types and actual discovery tests, but in 
this case, clarification for applicability limitation of the NAT type 
discovery process and their reasons should be added to the document
I suppose.

Yutaka

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 14 Feb 2004 23:22:05 -0500

inline.

> discovery process and their reasons should be added to the document

Such limitations are in there already. However, people are using these 
algorithms in any case and are trusting the results. I think, at the 
very least, that any nat detection or diagnostic usage should be totally 
removed from the main specification and described purely as a diagnostic 
tool.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com