Subject: [BEHAVE] Re: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 8 Aug 2007 22:50:11 +0300

Le vendredi 3 août 2007, Nathan Ward a écrit :
> >  1) There are proprietary Teredo extensions (AFAIK, at least one
> > that allows working with symmetric NATs).  Do these depend on
> > additional code the servers?  If so, one server is not necessarily
> > equivalent to another, and I could understand why MSFT would be
> > reticent to use anycast.  If so, one also might need to reconsider
> > whether an anycast prefix makes sense when servers may provide
> > different feature sets.
>
> I'm not aware of these extensions, can anyone provide info?

From http://www.microsoft.com/technet/network/ipv6/teredo.mspx :

  Symmetric NATs
  (...)
  Teredo in Windows Vista and Windows Server 2008 can work between
  Teredo clients if only one Teredo client is behind one or more
  symmetric NATs. For example, Teredo in Windows Vista and Windows
  Server 2008 will work if one of the peers is behind a symmetric NAT
  and the other is behind a cone or restricted NAT.

As far as I can tell, symmetric NAT detection is already part of the 
base spec, so it is not unlikely that this unspecified extension does 
not involve any change to the servers.

What's weirdest to me, as a regular of the BEHAVE WG, is support for 
symmetric-to-restricted traversal. Symmetric-to-cone is "easy", but 
symmetric-to-restricted, hmm?! At least, ICE cannot do that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Aug 2007 17:07:50 -0700

> symmetric-to-restricted, hmm?! At least, ICE cannot do that.

Using RFC3489 terms, ICE can successfully establish a direct peer-to-
peer UDP session between two hosts where one is behind a 'symmetric' 
NAT and another is behind a 'restricted cone' NAT (but you're right
that ICE cannot establish that connection if it's a 'port restricted 
cone').

RFC4787's terminology, although longer than what most people use and
are familiar with, does a much cleaner job of separating the port 
assignment (which is part of the problem; this is the major problem
with 'symmetric' NATs) from the filtering (which is the other part 
of the problem).

-d