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

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Aug 2007 14:24:30 +0300 (EEST)

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..

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).

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.

  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.)

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.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Nathan Ward <[email-masked]>
Date: Fri, 3 Aug 2007 16:25:25 +1200

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).

>> 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.
>
> helpful for those smaller sites which would prefer to overload the  
> DNS name rather than do anycast.
>
> 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>.

>     whether an anycast prefix makes sense when servers may provide

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

>     don't think so, but I wonder if there are some problem cases

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.

> 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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 6 Aug 2007 22:48:43 +0300

> 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.
> > don't think so, but I wonder if there are some problem cases here.)
>

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/

---

From: Christian Huitema <[email-masked]>
Date: Mon, 6 Aug 2007 13:10:23 -0700

> But it adds a requirement that all Teredo *relays* have a working
> Teredo anycast route. That should still work.

The very first "shipworm" draft was actually based on anycast. With that in mind, each host received a 64 bit prefix, made of a fixed /16 for the service, the mapped address of the host, and the mapped port of the host. The draft promptly made it to WGLC, only to be sent back after review, with the main piece of feedback being "please don't use anycast". With anycast, clients don't know who their server is, which makes debugging painful and generally dilute accountability. Also, using anycast as IPv4 source address provides a handy way to defeat all forms of egress control, spoof addresses, etc.

-- Christian Huitema

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 8 Aug 2007 22:50:11 +0300

Le vendredi 3 août 2007, Nathan Ward a écrit :
> >  1) There are proprietary Teredo extensions (AFAIK, at least one
> > that allows working with symmetric NATs).  Do these depend on

From http://www.microsoft.com/technet/network/ipv6/teredo.mspx :

  Symmetric NATs
  (...)
  Teredo in Windows Vista and Windows Server 2008 can work between
  Teredo clients if only one Teredo client is behind one or more
  symmetric NATs. For example, Teredo in Windows Vista and Windows
  Server 2008 will work if one of the peers is behind a symmetric NAT
  and the other is behind a cone or restricted NAT.

As far as I can tell, symmetric NAT detection is already part of the 
base spec, so it is not unlikely that this unspecified extension does 
not involve any change to the servers.

What's weirdest to me, as a regular of the BEHAVE WG, is support for 
symmetric-to-restricted traversal. Symmetric-to-cone is "easy", but 
symmetric-to-restricted, hmm?! At least, ICE cannot do that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/