[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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