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

On 2/08/2007, at 11:24 PM, Pekka Savola wrote:

> Hi,
>
> Jumping on to the old discussion as I recently set up a public  
> Teredo relay and a server and ran into logistical problems of  
> obtaining users..

Reviving this thread is on my to-do list, actually.
I note with interest that the list has a high latency - approx 55  
mins - the cc arrived immediately (11:24pm), and the list email  
arrived some time later (12:19am).

> On Mon, 9 Jul 2007, Joe Abley wrote:
> ...
>> 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.
>
> While I agree that a name isn't really needed, this goes against  
> the principle that IP addresses should not be glued in the  
> applications.
>
> Now, there seem to be practical problems in obtaining a forward DNS  
> name that would be under IETF control. A DNS name would also be  
> helpful for those smaller sites which would prefer to overload the  
> DNS name rather than do anycast.
>
> However, the drawbacks (more complexity) and difficulty of getting  
> such a DNS name seem to outweigh the benefits, and I'd recommend  
> going forward with just an anycast prefix (the vendors of Teredo  
> clients can just put that as one or the only Teredo server addresses).

While I agree that that's a way forward, it still allows your vendor  
to direct you to a non-anycast Teredo server, simply by changing  
their DNS. This is different to entrusting it to your ISP, as they  
already carry your native IPv4 traffic, so you trust them sufficiently.

And as you say, it removes the ability for an ISP to /not/ use  
anycast, which I think is likely to be quite useful.

Is there any precedent for a name being used like this that people  
are aware of? I'm aware of prefixes, i.e. wpad.<domain>.

> I have two doubts that are not addresses by the draft, though:
>
>  1) There are proprietary Teredo extensions (AFAIK, at least one that
>     allows working with symmetric NATs).  Do these depend on
>     additional code the servers?  If so, one server is not necessarily
>     equivalent to another, and I could understand why MSFT would be
>     reticent to use anycast.  If so, one also might need to reconsider
>     whether an anycast prefix makes sense when servers may provide
>     different feature sets.

I'm not aware of these extensions, can anyone provide info?

>  2) Does using anycast address as the rendezvous IP affect the NAT
>     traversal and qualification procedure, a) if the server were to
>     respond using the anycast address, or b) if the server chose
>     another address in the response?
>
>     For example, consider the case where a NAT pinhole is opened when
>     trying to contact anycast instance 1, the routing changes, and you
>     get to anycast instance 2 but the pinhole is still open.
>     Would/could this cause qualification problems or other issues? (I
>     don't think so, but I wonder if there are some problem cases
>     here.)

I can't imagine that it would, as the servers are stateless, the  
discovery is a single packet in each direction, and the servers do  
not talk to each other.
I can imagine a routing change causing the network to drop (or  
otherwise excessively delay) a packet, but the result of that would be:
a) Network drops first discovery packet - Teredo doesn't come up.
b) Network drops second discovery packet - Teredo thinks it's behind  
restricted NAT, but still functions, but requires server involvement  
for incoming connections.

In the case of (a), I'd expect Teredo client implementations to retry  
later, as this is no different to the server being temporarily  
unreachable.

> Btw: the different options for auto-discovery were also analyzed in  
> http://www.watersprings.org/pub/id/draft-palet-v6ops-tun-auto- 
> disc-03.txt (expired 2 years ago, some input was received since  
> then but not edited in), which may be interesting for the authors.

I'll review that document, cheers!

--
Nathan Ward