Subject: Teredo server selection

From: Nathan Ward <[email-masked]>
Date: Sat, 22 Dec 2007 21:56:06 +1300

Folks,

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 thought about SRV, but having a dynamic port seems to render little  
benefit (that I can see), as Teredo relays wanting to use servers to  
open holes in restricted NATs would be expecting the server to be  
listening on the standard port.
I didn't consider security, because blocking the Teredo port in order  
to block Teredo implies a default-allow policy when attempting to  
block tunnelling technologies, which seems unlikely, or silly enough  
that it deserves to be broken :-)

Does this sound like a good compromise? I'm open to reasoning for the  
usage of SRV.

Something I have been considering is that prefixes that servers  
advertise in RA messages are to be unique to that server or server  
"cluster", as opposed to being built from the well known anycast  
address. This perhaps takes some of the concern away where users would  
be unable to detect what server they are using, and it gets around any  
potential problems with strict mode RPF+anycast. However, it means  
that a host would get a new address every time the routing changed  
sufficiently enough to push them towards a new Teredo server.

Something I am considering to solve that is if the client gets an RA  
that does not match the server address they are trying to use, that  
they temporarily re-configure to use the new server address based on  
that RA, and try again.

Thoughts? Is that too hard, now that client implementations are in  
place? I don't expect that it would break backwards compatibility - it  
would just mean that older clients reconfigure if routing changes too  
much.

- --
Nathan Ward

---

From: Florian Weimer <[email-masked]>
Date: Sat, 22 Dec 2007 23:28:50 +0100

> `_teredo._udp.arpa.defaultdomain' etc.)

You should really discuss this with DNS people.  This is a very bad idea
because it produces lots of pointless queries which need to be handled
somewhere, probably on a production name server.

---

From: Nathan Ward <[email-masked]>
Date: Sun, 23 Dec 2007 13:44:48 +1300

> somewhere, probably on a production name server.

You are talking about the use of .arpa, I assume, and query load on  
the root servers?

I think I understand the concern, but negative caching would deal with  
this, same as it does for .local., .invalid., etc. The negative TTL on  
both .arpa and . is 86400s.

We're only talking about 1 query each time the Teredo client boots, so  
load on ISPs' recursive nameservers is not large - my laptop does  
several queries per minute when idle, let alone at boot time or when  
it's actively doing something.

- --
Nathan Ward

---

From: Brian Dickson <[email-masked]>
Date: Sun, 23 Dec 2007 05:32:54 -0500

Nathan Ward wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
The default maximum negative cache TTL for BIND9 is 3 hours (10800s).
This overrides the negative TTL on any zone with longer TTL.

(*Relying* on negative caching as a key part of any design, is a *bad* 
idea.)
> We're only talking about 1 query each time the Teredo client boots,
This would be 1 query per day per Windows box, roughly. Okay, maybe not 
*every* day, but often
enough, like on Patch Tuesday, every Windows box reboots at roughly the 
same time, and generates
one query.
>  so  
What about the case where hosts have been set up with local recursive 
servers (i.e. on the host itself)?
Those would *all* hit the root and TLD server(s) for .arpa. in each such 
instance (host reboots).

Besides which, I don't understand why this *shouldn't* be something 
locally instantiated,
if it is supported by the ISP. Something like, "teredo.defaultdomain", 
by looking up "teredo" with no trailing dot.

I'm wondering why it is even necessary to do any of this set-up, before 
starting an application that actually wants/needs Teredo service.

I don't know what the proportion of hosts with Teredo enabled, which 
actually *use* it is -- but if it is substantially less
than 100%, I think the operational impact to Teredo potentially 
interfering with native IPv6, should be given strong
consideration.

The coding convenience of "do this when we boot" is not a strong 
argument in favour of any  particular
approach, when "do this" involves Internet-wide interactions.

Brian

---

From: Florian Weimer <[email-masked]>
Date: Sun, 23 Dec 2007 13:15:30 +0100

> You are talking about the use of .arpa, I assume, and query load on  

Yes, but the issue will not be much different if you use any other zone.

> both .arpa and . is 86400s.

This doesn't work too well in practice, unfortunately.

> it's actively doing something.

Huh?  Why don't you have to requery when you suspect your network
environment has changed, or when you no longer can reach the Toredo
server (for an extended period of time)?