Subject: RE: Teredo and auto-discovery [Re: POLL: Consensus for moving forward with Teredo?]

From: "Christian Huitema" <[email-masked]>
Date: Sun, 2 May 2004 09:34:21 -0700

Anycast can be retrofitted trivially in Teredo. The client is configured
with the domain name or the IP address of a Teredo server; it suffices
to resolve the domain name to an anycast address, or configure the
anycast address as address of the server. Teredo servers don't keep
state per client session, so the service will work even in case of
anycast re-routing.

However, there is a reason why anycast was removed, and the reason is
IESG review. Anycast reduces traceability; using anycast addresses as
source addresses creates a number of security issues, e.g. prevents
ingress filtering. I believe that there are too many such issues to make
anycast a "base design".

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of JORDI PALET MARTINEZ
> Sent: Sunday, May 02, 2004 1:32 AM
> To: [email-masked]
> Subject: Re: Teredo and auto-discovery [Re: POLL: Consensus for moving
> forward with Teredo?]
> 
> Pekka,
> 
> When we started to work on the auto-discovery, you suggested that the
goal
> could be not just the TB/TSs, but other transition mechanism, as all
they
> require an "end-point". That was I was trying to mean ;-)
> 
> I think we should try to offer the best service to the people starting
to
> use IPv6 and at the same time the easier way for ISPs to deploy it.
Less
> protocols (or a few of them using common mechanisms, at least in
part),
> could help on this, I believe.
> 
> If anycast was already part of Teredo, why don't get it back. I think
that
> having this option could be part of the "better service", in the sense
> that the box can try to find an anycast address, and if it's not
> available, fall-back into the manual configuration (or
preconfiguracion
> from the vendor, or both). At this way, some ISPs willing to offer the
> service, will facilitate the task of the user, that will not need to
> manually change it. At the same time, users traveling, could have
better
> service when attached to some networks (like we have with 6to4 more
and
> more frequently).
> 
> Regards,
> Jordi
> 
> ----- Original Message -----
> From: "Pekka Savola" <[email-masked]>
> To: "JORDI PALET MARTINEZ" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, May 01, 2004 6:48 AM
> Subject: Teredo and auto-discovery [Re: POLL: Consensus for moving
forward
> with Teredo?]
> 
> 
> > On Sat, 1 May 2004, JORDI PALET MARTINEZ wrote:
> > > I wonder if Teredo could take advantage of the auto-discovery idea
> > >
(ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-palet-v6ops-
> tun-auto-disc-00.txt),
> > > making sure that if required both the 6to4, TB/TS/TSP, ISATAP and
> > > the Teredo relays, can coexist automatically in the same box. This
> > > could easily simplify the deployment and be an important
> > > multiplicative factor.
> > >
> > > So, I will suggest a new option "a.bis)": The idea is to make a
very
> > > quick move on defining a solution for the auto-discovery, and
> > > include this in a revised Teredo version (same with ISATAP, TSP,
> > > etc.).
> > >
> > [...]
> > >
> > > Christian, Pekka what do you think ? (I've not read the latest
> > > versions of Teredo, so I'm not sure if what I'm saying is actually
> > > meaningful, but I understand that the server/relay need to be
> > > pre-configured, so can we make it auto-discovered ?, indeed we
> > > didn't included Teredo in our I-D, but may be an option for the
next
> > > revision).
> >
> > I'm having difficulty figuring out what you mean, yes :).
> >
> > Relay doesn't need to be configured.  Server must be configured, and
> > typically would probably have to be unless there would be an anycast
> > prefix which could be used to find the closest serving server (like
> > with 6to4 relays).  (Vendors shipping products which use their
server
> > pre-configure this so no user config is needed.)  Anycast discovery
> > was removed from the spec some time ago, but it it's deemed useful,
it
> > could maybe be added back so that you would only use the anycast
> > address to discover the relay, and use a unicast address after that
> > (or something).
> >
> > With regard to the end-points, you could devise a tunnel server
> > solution that's usable by Teredo clients out-of-the-box.  If you
> > hijack a popular Teredo server's IP address, you can even force your
> > users to use the tunnel server ;-).
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
> >
> 
> 
> **********************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on line at:
> http://www.ipv6-es.com
> 
> This electronic message contains information which may be privileged
or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be
aware
> that any disclosure, copying, distribution or use of the contents of
this
> information, including attached files, is prohibited.
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 3 May 2004 13:30:49 +0300 (EEST)

> state per client session, so the service will work even in case of

What about using anycast only for initial contact to establish the 
unicast address of the closest server, similar to means described in 
e.g. draft-ietf-mboned-auto-multicast-02.txt ?

Obviously, this is rather independent part of the procedure and would
just need to replace the whatever "server discovery" function Teredo
has, so plugging it back later on if deemed feasible wouldn't seem
very difficult either.

> ingress filtering. I believe that there are too many such issues to make

To be precise, it prevents ingress filtering without an exception list
from the direction of networks deploying Teredo servers which are
advertised outside of their site, correct?  I.e., Teredo servers which
advertise the anycast prefix in inter-domain routing.  One could argue
that servers deployed in such a fashion may not be an actual problem..

I personally don't see much problem with using anycast as source;  
we've certainly always used that for our 6to4 relay, and many others
as well.  But I can see why that makes some people a little bit
nervous.. :)