Re: I-D ACTION:draft-nward-v6ops-teredo-server-selection-00.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Jumping on to the old discussion as I recently set up a public Teredo 
relay and a server and ran into logistical problems of obtaining 
users..

On Mon, 9 Jul 2007, Joe Abley wrote:
...
> I'm not convinced that a name is required, actually. If RFC 3068 could assign 
> an IP address for use as an anycast 6to4 relay, I don't see why a new 
> document couldn't do a corresponding assignment for Teredo.
>
> Codifying an address and a corresponding covering prefix for use in an 
> anycast advertisement also has better characteristics with respect to a 
> migration from the status quo, since old implementations could be supported 
> seamlessly by simply changing the A record for teredo.ipv6.microsoft.com to 
> match whatever is assigned.

While I agree that a name isn't really needed, this goes against the 
principle that IP addresses should not be glued in the applications.

Now, there seem to be practical problems in obtaining a forward DNS 
name that would be under IETF control. A DNS name would also be 
helpful for those smaller sites which would prefer to overload the DNS 
name rather than do anycast.

However, the drawbacks (more complexity) and difficulty of getting 
such a DNS name seem to outweigh the benefits, and I'd recommend going 
forward with just an anycast prefix (the vendors of Teredo clients can 
just put that as one or the only Teredo server addresses).

I have two doubts that are not addresses by the draft, though:

 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.

 2) Does using anycast address as the rendezvous IP affect the NAT
    traversal and qualification procedure, a) if the server were to
    respond using the anycast address, or b) if the server chose
    another address in the response?

    For example, consider the case where a NAT pinhole is opened when
    trying to contact anycast instance 1, the routing changes, and you
    get to anycast instance 2 but the pinhole is still open.
    Would/could this cause qualification problems or other issues? (I
    don't think so, but I wonder if there are some problem cases
    here.)

Btw: the different options for auto-discovery were also analyzed in 
http://www.watersprings.org/pub/id/draft-palet-v6ops-tun-auto-disc-03.txt 
(expired 2 years ago, some input was received since then but not 
edited in), which may be interesting for the authors.

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