Subject: Re: Teredo server selection

From: Joe Abley <[email-masked]>
Date: Wed, 2 Jan 2008 09:24:00 -0500

On 22-Dec-2007, at 03:56, Nathan Ward wrote:

> I'm looking at my server selection stuff for Teredo again, and have
> been looking at ways to get around the (political) problems of having
> a well known name.
>
> My current thinking is, why not have a well known DNS name, but it is
> NOT globally available. The server discovery procedure would be
> something like:
> 1) Lookup A record for `_teredo._udp.arpa.' (or whatever. Note the
> trailing . - we don't want to be looking up
> `_teredo._udp.arpa.defaultdomain' etc.)
> 2) If there is an NXDOMAIN response, the well known anycasted server
> address is used. (hard coded, I'm afraid)
> 3) If there is a NOERROR response pointing to a valid Teredo server,
> this is used.
> 4) If there is any other RCODE, Teredo is not attempted.

I fear that:

  - the politics involved in choosing a name will be tedious
  - there are potential root/ARPA/whatever server load considerations,  
given the potential base of teredo clients
  - bootstrapping a network plumbing exercise using a DNS name sounds  
like it has the potential to expose circular dependencies

Given a well-known anycast address for Teredo (is there one?) I'm not  
sure why the easy answer to this is to forget about the DNS and just  
use the IP address. If sites want to keep the traffic local, they can  
always arrange for traffic aimed at that address to be delivered to a  
local host in their network.

(I'll note that I've been on extended e-mail cold-turkey [ho, ho] over  
the holidays, and may be missing some context in this thread. If what  
I am saying makes no sense, please be gentle.)

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Jan 2008 08:08:57 -0800

Hello,

Can anyone tell me whether RFC2767 ("Dual Stack Hosts using
the "Bump-In-the-Stack" Technique (BIS)") has been widely
implemented and/or deployed in operational networks? Do you
further expect that it will play an important  role in IPv6
transition? (Originally sent this to the authors, but it
bounced.)

Thank you,

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 4 Jan 2008 10:03:24 -0800

I wasn't kidding when I asked this. There is a perceived
requirement for supporting legacy IPv4-only applications 
on dual-stack end systems for communication with IPv6-only
correspondents. To my understanding, this was the use case
for which RFC2767 was designed but I have been unable to
turn up any useful information other than the RFC itself.

Is there a hole in the IPv6 transition plan?

Thanks - Fred

> -----Original Message-----
> From: Templin, Fred L 
> Sent: Wednesday, January 02, 2008 8:09 AM
> To: v6ops WG
> Subject: RFC2767 implementation and deployment experience?
> 
> Hello,
>

---

From: Nathan Ward <[email-masked]>
Date: Sun, 6 Jan 2008 16:21:44 +1300

> like it has the potential to expose circular dependencies

The first two appear to be issues.
The latter should not be an issue, as existing Teredo clients use DNS  
names for server discovery.

I'm not convinced that there would be significant extra load on the  
root servers however - things like .local, .mshome, .workgroup, etc.  
would cause similar load, I expect.

> Given a well-known anycast address for Teredo (is there one?) I'm  
> not sure why the easy answer to this is to forget about the DNS and  
> just use the IP address. If sites want to keep the traffic local,  
> they can always arrange for traffic aimed at that address to be  
> delivered to a local host in their network.
>
> (I'll note that I've been on extended e-mail cold-turkey [ho, ho]  
> over the holidays, and may be missing some context in this thread.  
> If what I am saying makes no sense, please be gentle.)

There is not a well known IPv4 anycast address for Teredo servers to  
use at this time.

I'd like for there to be a DNS based solution to allow an operator to  
direct end users to a server based on whatever metrics they choose, as  
opposed to just the best IPv4 path. This would allow DNS round robin,  
for example.

My suggestion RE negative names was to work around potential political  
problems where having a globally available name would be a problem.  
Ie. having server.teredo.arpa. (or whatever) returning an A RR  
pointing to an anycasted address. Would the preference be to:
a) Have a well known globally available name, which returns an A RR  
pointing to the anycast address. Operators can 'overload' this.
      Benefit: Less load on the root servers, as positive caching is  
better.
      Drawback: Someone has to be authoritative. Can this be a  
function of [a subset of?] the root servers?
b) Have a well known name that is NOT globally available, which  
operators can optionally return an A RR for.
      Benefit: We don't have to be authoritative.
      Drawback: Potentially higher load on the root servers.
c) Do something else

A show of hands, with comments if you'd like, would be useful here.

--
Nathan Ward