Teredo server selection

[Nathan Ward <v6ops@daork.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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





-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.7.0 (Build 867)
Charset: US-ASCII

wsBVAwUBR2zRKahXB4ariYS3AQhDYggAnYzN/XnLvPEn7q7aFusPi4czBhGIgQMb
/weIRrojdF3TTNHMVByrQJuqm8nkkcSvyS8IfC/wsK368i1C2x+mf+xfeFAqmMqA
gg6iIUOTgFObNM5M7Fa5+Bx115Wc+ztjMGkLYMkL8+m1TeOSWg1kQ6B2WdOidrzp
lhvkKeruTZeeBI2carg+b0qiHv7zkJP2JzC5kv0tyP1qz0TPXh+hCveiOq0wckHz
I5Dl5kNJeW/wSALbZ0EGi+rVhQr0bPt5dkg4klyeItl9Bb88GK2yX4195xobiY29
zyPyzrkYr2y9zghpAKAcszytoeW7hxuv+iakvBUNwaWcVK7+SoFJHQ==
=JYxc
-----END PGP SIGNATURE-----