Subject: Re:Teredo vs Silkroad

From: "Eiffel Wu" <[email-masked]>
Date: Fri, 21 May 2004 19:39:12 +0800

>On Fri, 21 May 2004, Eiffel Wu wrote:
>> As compared with the Teredo, Silkroad has the following
>> strongpoints:
>>
>> 2. Silkroad can deploy without the support of relay, while the
>> Teredo needs the relay which advertises the reachability of Teredo
>> Prefix.
>
>That's not really true, I think.  You can deploy Teredo using your 
>own, arbitrary prefix, ("internal Teredo server"), and to the rest of 
>the Internet, it looks like native IPv6 service.

Cited from Teredo:
Teredo relays are IPv6 routers that advertise reachability of the
Teredo service IPv6 prefix through the IPv6 routing protocols.

Teredo address format:
  +-------------+-------------+-------+------+-------------+
  | Prefix      | Server IPv4 | Flags | Port | Client IPv4 |
  +-------------+-------------+-------+------+-------------+
   
   - Prefix: the 32 bit Teredo service prefix.
   - Server IPv4: the IPv4 address of a Teredo server.

>> 3. Silkroad supports all types of NATs, while Teredo doesn't support
>> symmetric NATs.
>
>Obviously, this could be added very easily to Teredo as well, but it 
>would require that Teredo servers would act as tunnel endpoints, and 
>there would not be direct tunneling.  That would burden the servers to 
>that it would probably be undesirable.
Whether or no, Teredo does not support symmetric NATs.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 May 2004 15:41:38 +0300 (EEST)

> Teredo service IPv6 prefix through the IPv6 routing protocols.

Yes, but look at the definitions:

========
2.5     Teredo IPv6 service prefix
   
   An IPv6 addressing prefix which is used to construct the IPv6
   address of Teredo clients.
   
2.5.1   Global Teredo IPv6 service prefix
   
   An IPv6 addressing prefix whose value is XXXX:XXXX:/32.
   (TBD IANA; experiments use the value 3FFE:831F::/32, taken from a   
   range of experimental IPv6 prefixes assigned to Microsoft.)
=========

in other words, there can be multiple Teredo IPv6 service prefixes.  
Anyone can establish one just if the operator has a /32 prefix to 
spare. Many probably don't :).

In addition to that, there is the _global_ service prefix which is 
used by default.

btw. Christian, in section 5.2.1:

 This prefix should be a valid Teredo IPv6 server prefix: the
   first 32 bits should contain the global Teredo IPv6 service prefix,
   and the next 32 bits should contain the server's IPv4 address.

==> here 'global' should be omitted, I think?   

> Whether or no, Teredo does not support symmetric NATs.

See section 6.  If you used Teredo just as a tunnel service, it would 
work with symmetric NATs as well.  I don't think many people would 
want to deploy the servers like that though.. :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "liumin" <[email-masked]>
Date: Sat, 22 May 2004 00:31:37 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Pekka Savola
> Sent: Friday, May 21, 2004 8:42 PM
> To: Eiffel Wu
> Cc: [email-masked]
> Subject: Re:Teredo vs Silkroad
> 

If there are multiple Teredo IPv6 service prefixes, how do Teredo
Clients belonging to different address prefix communicate with each
other? And what function should be added to the Teredo server and Teredo
relay?

> want to deploy the servers like that though.. :)

Yes, Teredo could make some changes and support symmetric NATs. But as a
result, it will lose its biggest strongpoint. In fact, the most special
aspect of Teredo is that the mapped IPv4 address and port of client can
be learnt from the Teredo IPv6 address, thus make it easy to implement
direct connectivity. The most strongpoint of such an approach is for
Full Cone NAT. When the NAT type is Restricted Cone NAT or Port
Restricted Cone NAT, Teredo need transmit some bubbles to provide direct
connectivity. Under this case, the advantage of Teredo is weakened to
some extent. What is more, if Teredo wants to support symmetric NATs, it
will have to make traffic pass through Teredo server. Moreover, because
you can only know the NAT is cone NAT or not from Teredo address, you
need other methods to determine whether the Teredo client you want to
communicate is located behind a symmetric NAT. All of these will
complicate Teredo significantly and destroy its characteristics and
advantages. Anyway, I don't think it is wise to overcome one drawback by
losing one good point.