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

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




On 5-Jul-2007, at 08:30, Nathan Ward wrote:

That's a good question as to who would host and maintain the zone. In the document I say: "The root servers (or some other independent party) would host the DNS name". I'm not sure who that third party could be, but the root servers (or perhaps a subset of the root servers) seem well placed in terms of reliability, and trust-ability.

Procedurally, probably the way to side-step this issue would be to document actions that you'd like the IANA to take (assign address/ prefix, host zone, etc). That approach is not without its headaches, but allows at least more operational flexibility than hard-coding such details in a static document. "teredo.iana.org"?

Perhaps an alternative to having a fallback in DNS is to have the anycast address configured as the Teredo server address to use when the DNS name is un-resolvable - that would require some extra logic in the clients though, but it would be pretty trivial I'd imagine:

address = dns_lookup(well.known.dns.name)
if (address = failed) then address = a.b.c.d

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.


Joe