[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Teredo vs Silkroad




> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf
> Of Pekka Savola
> Sent: Friday, May 21, 2004 8:42 PM
> To: Eiffel Wu
> Cc: v6ops@ops.ietf.org
> Subject: Re:Teredo vs Silkroad
> 
> On Fri, 21 May 2004, Eiffel Wu wrote:
> > >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.
> 
> 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 :).


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?


> 
> 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?
> 
> > >> 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.
> 
> 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.. :)

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. 




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