Subject: Re: [BEHAVE] Does ICE-TCP work only with relayed candidates across a Linux NAT?

From: Adam Roach <[email-masked]>
Date: Sun, 27 Jul 2008 17:28:51 +0100

On 6/24/08 5:12 PM, Philip Matthews wrote:
> Just a quick comment  that ICE-TCP is in an uncertain state right now, 
> as its success rate is rather low (around 40%) and the MMUSIC WG has 
> not decided what it wants to do about this.

Jonathan pressed me for an opinion on how to solve this several weeks 
ago, and I've tried to give it some thought in the interim. I'll give a 
quick dump of my thoughts on the topic in hope of spurring conversation. 
Based on the bit of thinking I've done between now and then, I'm pretty 
certain that we have only four broad category of options:

   1. Keep the current, low-success technique

   2. Require TCP connections between hosts behind separate NATs to
      always go through external relays

   3. Require some level of support in NATs; options include:
          * Devise and document a set of procedures that NATs can
            recognize to assist with TCP traversal
          * Leverage existing or developing specifications, like UPnP,
            MIDCOM or NAT-PMP
          * Colocate "relay"-type functionality in a NAT, using TURN,
            SOCKS, or similar (this gets around the downsides of #2,
            which I discuss below).

   4. Tunnel TCP over something more NAT-friendly (i.e., UDP); potential
      options are:
          * Could put TCP directly over UDP
          * Could put TCP over IP over UDP
          * Could put TCP over IPSEC over UDP

Category 1 has the downside of not usually working. It has value as a 
supplemental fallback technique, however -- over time, new NATs may 
elect to intentionally add support for it, and the other approaches in 
use (along with their drwabacks) may be phased out.

Category 2 has the clear downside of requiring additional network 
resources, and of introducing unnecessary latency. Its key benefit is 
that it works, and can be deployed without replacing equipment in every 
internet-connected house and business in the world.

Category 3 has the downside of requiring upgrades to most deployed NATs 
(although there are deployed NATs with UPnP and NAT-PMP support already, 
so there could be some initial support). It has the benefit of being 
explicit and architecturally more clean. Because of this explicit 
nature, network administrators can provision more intelligent policy in 
the NATs than would be possible with the other two approaches.

Category 4 has the downside of requiring either kernel modifications or 
userland TCP stacks. The first is tricky to deploy; the second is rife 
with opportunity for mis-steps. That said, there are two approaches that 
have reasonable enough existing deployment that we might consider 
re-using them:

    * Tunnel-drivers, which hook into the kernel IP stack. I know from
      personal experience that that tun/tap exists for OS X and Linux;
      the Wikipedia article also claims support for all major operating
      systems.
    * IPsec, which is supported in all major operating systems. That is,
      we would actually set up an IPsec association (with the assistance
      of RFC 3948), and run the TCP over that.

Both of these approaches may cause issues with VPNs, depending on where 
these VPNs wedge into the operating system. They also require the 
ICE-TCP application to make modifications to the routing table and to 
have access to resources that are restricted on most operating systems 
-- which requires the equivalent of root access for the client applications.

I was really warming to this fourth category until I realized this bit 
about root access, which I personally consider a deal-breaker.

I think that's about it. Each approach has significant downsides, but 
some benefits also. Of course, it *is* ICE, so the solutions aren't 
mutually exclusive -- we could add them all to the specification, and 
let the clients sort out which ones work. :)

/a
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sun, 27 Jul 2008 22:06:26 +0300

>    1. Keep the current, low-success technique

My take is that the complexity to usefulness ratio is not really in favor of 
ICE-TCP-SO at the moment. I suspect implementors would actually go for...

>       always go through external relays

...but that has obvious operational limits that you already mentioned.

>             SOCKS, or similar (this gets around the downsides of #2,

That's what people have been doing so far, for lack of a better alternative. 
This fails with many NATs, and will increasingly fail as we get into nested 
NATs, however.

>           * Could put TCP directly over UDP

draft-denis-udp-transport-00 proposes that, but I failed to have it on any WG 
agenda :o

>           * Could put TCP over IP over UDP

Why not? That's RFC4380, no need to re-invent the wheel.

>           * Could put TCP over IPSEC over UDP

Way overkill. IMHO, this shares the disadvantages of both previous solutions, 
plus it adds useless encryption/authentication overhead.

>       of RFC 3948), and run the TCP over that.

Will not really work from normal applications though.

> -- which requires the equivalent of root access for the client

TCP over UDP can be done (albeit inconveniently) without root. RFC4380 too at 
least in principle, though it is more natural to hasthe OS provide it for all 
applications.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Adam Roach <[email-masked]>
Date: Sun, 27 Jul 2008 23:02:46 +0100

> Why not? That's RFC4380, no need to re-invent the wheel.

Fascinating. I hadn't consiered Teredo for this purpose, but it does 
solve the problem.

> plus it adds useless encryption/authentication overhead.

The key attractor for me was deployed codebase. I beleive 4380 has the 
same basic properties without the encryption overhead, so I think that's 
a better candidate.

We still haven't quite solved the "root access or userland stack" issue, 
though.

> TCP over UDP can be done (albeit inconveniently) without root.

Indulge my ignorance -- what are you talking about here? I think 
"userland TCP stack" is a deal-killer; did you have something else in mind?

/a

---

From: Philip Matthews <[email-masked]>
Date: Mon, 28 Jul 2008 08:16:03 -0400

> "userland TCP stack" is a deal-killer; did you have something else  

Why do you consider a userland TCP stack to be a deal-killer? Say  
there was a high-quality, userland TCP stack with a BSD-or-equivalent  
license all set up to run over UDP (or whatever). Is it the work in  
making your application use it rather than the kernel TCP stack that  
is the problem? Can you explain in detail.

- Philip

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Jul 2008 13:22:34 +0100

You assume the existence of such a thing, then assume implementations  
will use it.

Its anecdotal, but the existence of chipsets that implement IP has not  
stopped a rather
large number of embedded device producers from re-implementing it  
themselves.

And we've had a great deal of grief at many SIPits because of it. (For  
example, it's apparently trivial to get arp horribly wrong).

RjS

On Jul 28, 2008, at 1:16 PM, Philip Matthews wrote:

> there was a high-quality, userland TCP stack with a BSD-or- 
> equivalent license all set up to run over UDP (or whatever). Is it  
> the work in making your application use it rather than the kernel  
> TCP stack that is the problem? Can you explain in detail.
>
> - Philip
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 28 Jul 2008 15:11:12 +0300

> "userland TCP stack" is a deal-killer; did you have something else in mind?

There are some existing such stacks. I definitely would not want to be the one 
implementing such a thing. But then again, what are our alternatives?

We have relaying, which is easy to implement, and firewall friendly. But it is 
euphemistically challenging to deploy/maintain.

We have simultaneous-open which is difficult to implement, and works poorly: 
many NATs don't like it, most firewalls don't like it, and many stacks don't 
support it.

And then we have tunneling which is very difficult to implement (unless you 
assume the OS does it - Windows has built-in Teredo) and works about as well 
as UDP through NATs.

Clearly, when we decided to use ICE for UDP through NATs, we poke the 
intricate solution that works, rather than the simple solution that does not 
work (legacy STUN). I am inclined to making the same choice for TCP through 
NATs. To me, that means tunneling, either at transport or at IP layer.

---

From: "Craig, Dave" <[email-masked]>
Date: Mon, 28 Jul 2008 10:14:00 -0700

Category 4 may not leave such a bad taste in your mouth, if you have a privileged ICE service (daemon or kernel module) that sets up the tunnels just for the TCP 4-tuple that you're about to use for ICE.  Making it a service gives it the ability to setup tunnels without exposing an interface for setting up arbitrary tunnels to applications.

Thanks,
        Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Sunday, July 27, 2008 9:29 AM
To: Philip Matthews
Cc: Craig, Dave; [email-masked]
Subject: Re: [BEHAVE] Does ICE-TCP work only with relayed candidates across a Linux NAT?

/a

---

From: "Craig, Dave" <[email-masked]>
Date: Mon, 28 Jul 2008 10:26:09 -0700

Teredo looks like a great encapsulation protocol, but doesn't it only support encapsulation of IPv6 addresses?  Is there a version of Teredo that'll support encapsulating IPv4 addresses?

Thanks,
        Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Sunday, July 27, 2008 3:03 PM
To: Rémi Denis-Courmont
Cc: [email-masked]; Philip Matthews
Subject: Re: [BEHAVE] Does ICE-TCP work only with relayed candidates across a Linux NAT?

/a

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 28 Jul 2008 20:53:15 +0300

On Monday 28 July 2008 20:26:09 ext Craig, Dave, you wrote:
> Teredo looks like a great encapsulation protocol, but doesn't it only
> support encapsulation of IPv6 addresses?  Is there a version of Teredo
> that'll support encapsulating IPv4 addresses?

No. But I doubt that would be tractable anyway. Any IPv4 address space is 
likely to clash with the assigned IPv4 address of the node. Remember we are 
not in a VPN scenario where everything gets blindly through the VPN and 
conflicting address range issues can be mostly ignored. Therefore, I have to 
question the usability of any IPv4-over-IPv4 solution in the problem space of 
ICE-TCP.

---

From: "Craig, Dave" <[email-masked]>
Date: Mon, 28 Jul 2008 11:34:41 -0700

Ah, so the only solution that will work for both IPv4 and IPv6 stacks is draft-denis-udp-transport-00?

I've worked with Linux stacks and have not had problems with the clashing address spaces.  The tables like the established connection hash includes the interface identifier.  Would it be reasonable to rely on this across platforms and not have to develop another encapsulation protocol?

Thanks,
        Dave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 29 Jul 2008 11:22:10 +0300

> draft-denis-udp-transport-00?

It would be unfair to represent this as the only solution. At best, it is the 
only active I-D :)

> I've worked with Linux stacks and have not had problems with the clashing
> address spaces.

On Linux, if the other ends of the tunnel uses an inner IP address which is 
equal to one IP address assigned to your host, any packet toward that IP 
address will be routed through loopback. Linux has the "local" routing table 
for loopback that preempts everything else. I suspect any operating system 
that can be used as a router will exhibit similar behavior.

Generally, if two different hosts have the same IP address, it is difficult 
(on these operating systems) for application to select which host the IP 
address shall refer to. On Linux, binding a socket to a device 
(SO_BINDTODEVICE) is a privileged operation. I am not even sure if it is even 
do-able on Windows at all.

> The tables like the established connection hash includes
> the interface identifier.  Would it be reasonable to rely on this across
> platforms and not have to develop another encapsulation protocol?

This does not seem to match my (limited) knowledge of the Linux IP stack. TCP 
sockets have source/destination IP/port. If the route to an IP address 
changes in the middle of a connection, further packets will use the new 
route. This can be mitigated using source-address-dependent routing, but 
that's not common practice, to say the least, requires privileges, and might 
not work at all on, say Windows and BSD/OSX.

It also becomes trickier and trickier if you need to have multiple peers at a 
time. Risk of overlap raise very fast when using RFC1918 space.

---

From: "Craig, Dave" <[email-masked]>
Date: Tue, 29 Jul 2008 13:39:31 -0700

How about a fifth option to those that Philip had proposed?  Modify the TCP stack to support a traversal mode where the application specifies the initial sequence number, TCP options, and can start with second handshake SYNACK to support the simultaneous open.  The SDP payload would include the TCP initial sequence number, so stateful firewall and NAT inspection will not drop the packets.

This approach has the benefit of not trying to add a header to get around the stateful firewall/NAT inspection.  It also does not require any protocol changes.

---

From: "Saikat Guha" <[email-masked]>
Date: Tue, 29 Jul 2008 14:01:47 -0700

On Tue, Jul 29, 2008 at 1:39 PM, Craig, Dave <[email-masked]> wrote:
> How about a fifth option to those that Philip had proposed?
> Modify the TCP stack to support a traversal mode where
> the application specifies the initial sequence number, TCP
> options, and can start with second handshake SYNACK

This would run into the same problem as with the first option.

The main reason option one has low-success today is because the
translated port number cannot be predicted. And port prediction is
fragile in enterprise/heavy-use environments. Initial seq, TCP
options, are second order annoyances.

Given the 4 options in Adam's mail, my question is not so much what
the success/complexity rate is today, but rather what it will be in
the future.

Is there any data to suggest vendors are embracing (or are not
embracing) address independent mappings?

-- 
Saikat

---

From: "Craig, Dave" <[email-masked]>
Date: Tue, 29 Jul 2008 17:28:51 -0700

Could you be more specific what you mean by address independent mappings?

As for low-success, isn't port translation is the same problem for both TCP and UDP?  However, ICE for TCP has more problems than UDP because of the second order annoyances from my experiments.

Now if you're talking about the future of ICE for both TCP and UDP getting worse in enterprise/heavy-use environments, wouldn't we need something very different than ICE?

Thanks,
        Dave

---

From: "Saikat Guha" <[email-masked]>
Date: Tue, 29 Jul 2008 17:37:55 -0700

> Could you be more specific what you mean by address independent mappings?

At the risk of inviting the wrath of Francois, address independent
mapping = cone NATs.

> As for low-success, isn't port translation is the same problem
> for both TCP and UDP?

IIRC, more NATs have non indemendent mappings (symmetric NATs) for TCP
than for UDP because they can get away with being so for TCP than UDP.

So with TCP we would use STUN to find the mapped port for a given
local port, and then when we try to use it again for the actual
destination, we find out that the mapped port we get for the new flow
is N+1 or something. That's what drove us to exploring port
prediction.

Going forward if all NATs have independent mapping behavior for TCP,
we expect the success rate of the "low performing technique" to rise
to 90%. Whether that will materialize, depends on vendor buyin into
the BEHAVE BCPs.

> However, ICE for TCP has more problems than UDP because of the second order annoyances from my experiments.

I'd love to hear about your experiences.

> Now if you're talking about the future of ICE for both TCP and UDP getting worse in enterprise/heavy-use environments, wouldn't we need something very different than ICE?

The enterprise/heavy-use issue comes up because port prediction breaks
down when too many clients are predicting/attempting independently.
With address independent mapping, that issue goes away.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 Jul 2008 12:07:40 +0300

> options, are second order annoyances.

Not at all my findings. Port number prediction is a non-issue with firewall, 
and many consumer NATs provide address-independent mappings. The reason why 
ICE-TCP fails a lot more than ICE-UDP is because NATs and firewall look at 
TCP flags. They want SYN outbound and SYN/ACK inbound, and simultaneous open 
does not work, whereas UDP hole punching does.

---

From: Adam Roach <[email-masked]>
Date: Wed, 30 Jul 2008 11:35:52 +0100

> Ah, so the only solution that will work for both IPv4 and IPv6 stacks is draft-denis-udp-transport-00?

Why does it matter? The deployment delays with IPv6 are infrastructure, 
not operating system. All major operating systems have had IPv6 support 
for nearly a decade now. With Teredo, only the endpoints (and the Teredo 
server, which is basically a purpose-built STUN server) need to have any 
notion of IPv6 -- everything else is IPv4.

After Rémi pointed out Teredo, I did a little bit of digging, and it 
looks just about ideal for solving this problem. Here's the high-level 
view of how it would work:

During ICE candidate gathering, the client would collect its Teredo 
address. This might be a long-standing Teredo address that the machine 
has lying around, or it could be one that the client causes to become 
active during candidate gathering.

For background; when a Teredo client starts up, it sends something very 
similar to a STUN packet to its configured Teredo server, and finds out 
its local address. So, for example, using the Teredo address that my 
laptop just pulled up... I have a provisioned Teredo server of 
130.129.19.226; and the IP/port that it told me I'm sending from is 
130.129.19.226:55419. My machine takes this information an synthesizes 
an IPv6 address of 2001::53aa:64c:0:2784:7d7e:ec1d. Here's what that means:

  2001::    - Teredo Prefix
  53aa:64c: - 130.129.19.226 (my Teredo server)
  0:        - Flags  (0 = no NAT)
  2784:     - XORed port; 2784 xor FFFF = 55419
  7d7e:ec1d - XORed IP addr; 7D7EEC1D xor FFFF = 130.129.19.226

So, my ICE client takes this IPv6 address 
(2001::53aa:64c:0:2784:7d7e:ec1d) and adds it to the candidate list, 
with a priority somewhere between a NATted address and a relayed address.

During candidate gathering, the other side does the same thing, and 
gives me its Teredo-generated address (in this example, we'll say the 
address is 2001::53aa:64c:308c:7996:b906:6402)

Now, when my client goes to send to the other client, it will try 
sending to 2001::53aa:64c:308c:7996:b906:6402. The Teredo layer extracts 
the "7996:b906:6402" from this, converts it into the IP address and port 
of the remote Teredo layer (70.249.155.253:34409), and sends the 
Teredo-encapsulated IPv6 packet to that UDP port. As long as the remote 
host isn't behind a symmetric NAT, that UDP packet gets through, hits 
the remote Teredo layer, gets unencapsulated, and is presented to that 
client as a normal "just arrived over an IPv6 interface" packet. With 
*my* Teredo address as the source. And data going in the other direction 
simply reverses this entire process.

So, we basically have a free-and-clear IP channel at this point between 
the clients. We can send TCP, UDP, SCTP, DCCP, ICMP, IKE, ESP, whatever 
the heck we *want* over this channel.

And this all just *works* for Windows by default, an for OS X, Linux, 
and most BSDs by installing a freely-available package. It's out there. 
I'm using it. It's dirt simple. It's deployed.

There are also some really, *really* neat implications when you consider 
interworking Teredo with real IPv6 clients on real IPv6 networks, but I 
don't want to muddy the waters with all that niftiness until people 
understand how Teredo solves the issue with hosts that are attached with 
only IPv4.

/a

---

From: "Saikat Guha" <[email-masked]>
Date: Wed, 30 Jul 2008 08:31:42 -0700

> does not work, whereas UDP hole punching does.

Interesting. Is any of this data/experience published? What sort of
environments and NATs did you look at?

On Tue, Jun 24, 2008 at 9:12 AM, Philip Matthews
<[email-masked]> wrote:
> Just a quick comment  that ICE-TCP is in an uncertain state right now, as
> its success rate is rather low (around 40%) and the MMUSIC WG has not
> decided what it wants to do about this.

IIRC, Philip was referring to the study we did in 2005 (which
identified port prediction as the problem), and if the sitution has
since changed qualitatively, that would be worth looking into.

---

From: "Craig, Dave" <[email-masked]>
Date: Wed, 30 Jul 2008 10:08:56 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Saikat Guha
Sent: Wednesday, July 30, 2008 8:32 AM
To: Rémi Denis-Courmont
Cc: Craig, Dave; [email-masked]
Subject: Re: [BEHAVE] Does ICE-TCP work only with relayed candidates across a Linux NAT?

> environments and NATs did you look at?

I'm experiencing a problem very similar to what Remi has described with the Linux NAT that I started this thread with.

Thanks,
        Dave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 Jul 2008 20:20:33 +0300

> environments and NATs did you look at?

Not that I know. I personally am not in the business of publishing research 
papers at the moment (no offense intended).

---

From: "Craig, Dave" <[email-masked]>
Date: Wed, 30 Jul 2008 11:48:40 -0700

Won't all of the applications using this new Teredo-based traversal now need to listen, accept, and manage addresses for connections for IPv6 addresses just for IPv4-only traversal?

        Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Wednesday, July 30, 2008 3:36 AM
To: Craig, Dave
Cc: [email-masked]
Subject: Re: [BEHAVE] Does ICE-TCP work only with relayed candidates across a Linux NAT?

  2001::    - Teredo Prefix

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jul 2008 09:06:13 +0100

> Won't all of the applications using this new Teredo-based traversal now need to listen, accept, and manage addresses for connections for IPv6 addresses just for IPv4-only traversal?

You weren't at last night's plenary, were you?

But, yes, we're going to start requiring all carriages to have motors of 
some kind, even if they still have horses attached to them.

/a

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 31 Jul 2008 05:49:56 -0400

I need to think more about the encapsulation aspects of this, which, if 
they are implementable, would definitely be an option. The part that is 
really awful is that deployments would need a Teredo server AND a stun 
server. Is it possible to take a server reflexive candidate learned from 
STUN and just transform it into a teredo v6 address in the client? And 
by, "is it possible", I mean, "is it supported by the implementations of 
Teredo that are available in windows, linux, bsd, etc.".

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jul 2008 11:04:46 +0100

On 7/31/08 10:49 AM, Jonathan Rosenberg wrote:
> I need to think more about the encapsulation aspects of this, which, 
> if they are implementable, would definitely be an option. The part 
> that is really awful is that deployments would need a Teredo server 
> AND a stun server. Is it possible to take a server reflexive candidate 
> learned from STUN and just transform it into a teredo v6 address in 
> the client? And by, "is it possible", I mean, "is it supported by the 
> implementations of Teredo that are available in windows, linux, bsd, 
> etc.".

I think you probably can't do that. There's a little bit of assistance 
provided by the Teredo servers for NAT piercing that go beyond the 
functions included in STUN. If my understanding is correct, these 
mechanisms are not relevant for Teredo-to-Teredo connections -- but, 
because interaction with normal IPv6 clients through a relay is also 
part of any Teredo implementation, you can't omit them from the deployment.

Now, I suspect you could use a Teredo server instead of a STUN server, 
but that's probably a larger change than you're willing to make.

As a compromise, co-locating a Teredo server with a STUN server on the 
same hardware would make a lot of operational sense, as they will both 
process very little traffic, and both need the same kind of attachment 
to the network (from a topological perspective).

/a

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 31 Jul 2008 13:21:35 +0300

On Thursday 31 July 2008 12:49:56 ext Jonathan Rosenberg, you wrote:
> server.

For plain TCP/IPv4, you need to perform mapping discovery over TCP/IPv4. For 
TCP over XXX over UDP over IPv4, you need to perform discovery over UDP over 
IPv4. And whole the IPv4 address will most likely be the same, the port 
number will be different.

I am not sure what the worry is. The Teredo address has the Teredo server as a 
single point of failure. The STUN reflexive address has the STUN server as a 
SPOF all the same. But they should be independent and no worse than STUN as a 
SPOF for ICE-UDP.

Coming to the latency, there is no way TCP-SO could share a STUN binding 
discovery procedure with any UDP-based encapsulation mechanism (Teredo or 
otherwise). The good news is that multiple procedures can be run at the same 
time, to shrink latency.

> Is it possible to take a server reflexive candidate learned from 

You can synthesize a Teredo address with STUN - theoretically. But that's not 
supported by any implementation of the four that I have heard of. Also, if 
the other end is a native IPv6 node but does not implement Teredo, or has no 
IPv4 connectivity at all, the Teredo server is needed. Another option is to 
run ICE without a STUN server, i.e. without STUN server reflexive address.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 31 Jul 2008 13:25:28 +0300

On Thursday 31 July 2008 13:21:35 ext Rémi Denis-Courmont, you wrote:
> You can synthesize a Teredo address with STUN - theoretically. But that's
> not supported by any implementation of the four that I have heard of.

On second thought, this is wrong. The Teredo server is also needed for 
Teredo-Teredo communication, as a minimalistic signaling channel (since 
Teredo cannot rely on SIP for that).