Subject: [Hipsec] Teredo compatibility

From: Miika Komu <[email-masked]>
Date: Fri, 11 Dec 2009 13:49:58 +0200

Hi,

we've done some concrete work on NAT traversal with ICE, but what about 
Teredo? I think RFC5201 and RFC5206 should have some statements about 
Teredo-based addresses?

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 12 Dec 2009 00:52:05 +1300

Why?  It just works, if Teredo is available it's just another IPv6 address.

Andrew

On 12/12/2009, at 12:49 AM, Miika Komu wrote:

> Hi,
> 
> we've done some concrete work on NAT traversal with ICE, but what about Teredo? I think RFC5201 and RFC5206 should have some statements about Teredo-based addresses?
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Fri, 11 Dec 2009 14:02:52 +0200

Andrew McGregor wrote:

Hi,

it should be short section then, right?)

I basically agree with you. Based on our experimentation, it works but 
there are some caveats regarding to pairing of addressing. So, sending 
of packets from src->dst:

Teredo->Teredo: works
Teredo->IPv6: does not work without a (commercial) relay service
IPv6->Teredo: works
IPv6->IPv6: (works :)

Samu, please comment if I got the two middle ones in wrong order.

Also, at least the miredo implementation on linux is good, but not 
perfect. Some performance-related issues and sometimes HIP packets just 
don't go through (usually restarting of miredo works).

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 12 Dec 2009 01:05:13 +1300

Ok, but in any case, candidate address probing deals with those issues.

Andrew

On 12/12/2009, at 1:02 AM, Miika Komu wrote:

> I basically agree with you. Based on our experimentation, it works but there are some caveats regarding to pairing of addressing. So, sending of packets from src->dst:
> 
> Teredo->Teredo: works
> Also, at least the miredo implementation on linux is good, but not perfect. Some performance-related issues and sometimes HIP packets just don't go through (usually restarting of miredo works).
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 11 Dec 2009 07:44:59 -0500

> Teredo->IPv6: does not work without a (commercial) relay service

What about your own Miredo relay?

> perfect. Some performance-related issues and sometimes HIP packets 
> just don't go through (usually restarting of miredo works).
>
>>> we've done some concrete work on NAT traversal with ICE, but what 
>>> about Teredo? I think RFC5201 and RFC5206 should have some 
>>> statements about Teredo-based addresses?

---

From: Miika Komu <[email-masked]>
Date: Fri, 11 Dec 2009 14:47:33 +0200

Robert Moskowitz wrote:

Hi,

> What about your own Miredo relay?

works also, but you need the relay. I don't know if miredo supports this.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 11 Dec 2009 08:18:16 -0500

Miika Komu wrote:
>>> I basically agree with you. Based on our experimentation, it works 
>>> but there are some caveats regarding to pairing of addressing. So, 
>>> sending of packets from src->dst:
>>>
>>> Teredo->Teredo: works

Been a while since I set mine up; that system is down now.  Take a look 
at the current specs and see what you can do with it.  One of my 
transition scenarios was for a corp to run their own Teredo relay.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 18 Dec 2009 10:35:05 +0200

Hi,

as Andrew indicates, the whole point of ICE is that it sends probes to 
see what works and what does not. We should not go off and specify stuff 
that will be discovered anyway at run time.

Cheers,

Gonzalo

---

From: Miika Komu <[email-masked]>
Date: Sun, 20 Dec 2009 16:40:23 +0200

Gonzalo Camarillo wrote:

Hi,

running ICE over Teredo works but is potentially a big overkill due to 
redundant functionality. Some of the results can be predicted as 
depicted below (and even incorporated in the ICE module if needed).

---

From: Ari Keranen <[email-masked]>
Date: Mon, 21 Dec 2009 09:55:20 +0200

Hi Miika,

I think trying to predict the success of NAT traversal is not a good 
idea if you can't get close to 100% accuracy. You should rather test 
what works and act accordingly; and that's exactly what ICE does.

And if you do ICE and include the Teredo address as the highest 
prioritized ICE candidate, you'll end up doing connectivity checks only 
for that candidate before selecting it for use, so there's hardly any 
overkill. And if the Teredo candidate fails you'll end up using 
something else that works.

Cheers,
Ari

Miika Komu wrote:
>> see what works and what does not. We should not go off and specify 
>> stuff that will be discovered anyway at run time.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> Andrew McGregor wrote:

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 21 Dec 2009 11:47:43 +0200

Hi,

trying to predict the outcome of the probes was mainstream thinking a 
few years ago. ICE was developed when it was pretty clear that 
prediction just did not work...

In any case, the idea in the HIP WG is to specify how to use NAT 
traversal mechanisms in HIP. If somebody wants to optimize ICE, MMUSIC 
(or maybe BEHAVE) would probably be the place to do it.

Cheers,

Gonzalo