Le vendredi 3 août 2007, Nathan Ward a écrit :
> > 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>.
Windows uses isatap.<domain> too, but that's not specified in IETF. But
it seems to be quite problematic (see http://wpad.com/), and the WPAD
Internet draft has long since expired.
Also, I am not convinced that ALL cheap NAT middleboxes preserve the
domain name from upstream DHCP/PPP. And it would fail for host that
have static domain name configuration.
If people think there is a real need for the DNS-based solution, I would
rather go for a fixed FQDN from the .arpa TLD or whichever, and back it
with anycast as a fallback.
By the way, I suppose DNS-based solution can be used for legacy
deployments too, since teredo.ipv6.microsoft.com and friends could
probably be turned into IN CNAME teredo.arpa.
> I'm not aware of these extensions, can anyone provide info?
I believe there is no public specification for these. At least, I
haven't found any.
> > 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.
Servers do not talk to each others. But servers are embedded in the
Teredo address, so that relays and clients ("peers") sometimes contact
the server of another client, for hole punching.
My understanding is that, if we were to use anycast, bits 32-63 of
Teredo addresses would essentially be frozen to the anycast server
address, and peers would contact the closest server instead of the that
of the client they want to punch an hole to. That should still work.
But it adds a requirement that all Teredo *relays* have a working Teredo
anycast route. That should still work.
--
Rémi Denis-Courmont
http://www.remlab.net/
Attachment:
signature.asc
Description: This is a digitally signed message part.