[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Teredo server selection
-----BEGIN PGP SIGNED MESSAGE-----
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
1) Lookup A record for `_teredo._udp.arpa.' (or whatever. Note the
trailing . - we don't want to be looking up
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
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.7.0 (Build 867)
-----END PGP SIGNATURE-----