Subject: Re: [Hipsec] NAT traversal and the standards track work

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 03 May 2010 12:47:51 +0300

Folks,

it seems we have consensus on including the mobility and multihoming
extensions in the scope of our new to-be-chartered NAT traversal effort.

With respect to whether we want to go native or still use the STUN-based
connectivity checks, it would be good to have more discussions on the list.

Thanks,

Gonzalo

On 26/04/2010 1:06 PM, Tobias Heer wrote:
> 
> Am 26.04.2010 um 06:51 schrieb Henderson, Thomas R:
> 
>>
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
>>> Sent: Tuesday, April 20, 2010 5:45 AM
>>> To: HIP
>>> Subject: [Hipsec] NAT traversal and the standards track work
>>>
>>> Hi,
>>>
>>> we need to decide what to do with NAT traversal when moving to the
>>> standards track. We have the following drafts:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-hip-nat-traversal/
>>>
>>> The draft above will soon become an Experimental RFC.
>>>
>>> https://datatracker.ietf.org/doc/draft-keranen-hip-native-nat-
>>> traversal/
>>>
>>> The draft above proposes implementing HIP-based connectivity checks
>>> instead of STUN-based ones.
>>>
>>> http://www.watersprings.org/pub/id/draft-melen-hip-nat-mm-00.txt
>>>
>>> The draft above, which needs to be revised, describes the mobility and
>>> multihoming extensions for NAT traversal.
>>>
>>> I would like to hear people's views on what to do here.
>>>
>>
>> Gonzalo, I would like to see both topics (NAT traversal, and mobility management aspects of NAT traversal) on the revised charter, as the second phase of standards-track work, as we discussed in Anaheim.  I am neutral on the questions of which one of the two drafts to adopt (if a choice needs to be made now) and on whether the nat-mm draft should remain separate or should be combined into one NAT traversal draft.
>>
> I share Tom's opinion here. I would like to see both progress (provided there is enough manpower to support both). However, I think it might be useful to address mobility in the actual NAT documents since it poses special challenges that are special to NATs. 
> 
> Tobias
> 
>> - Tom
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hipsec
> 
> 
> 
> 
> --  
> 
> Dipl.-Inform. Tobias Heer, Ph.D. Student
> Distributed Systems Group 
> RWTH Aachen University, Germany
> tel: +49 241 80 207 76
> web: http://ds.cs.rwth-aachen.de/members/heer
> 
> 
> 
> 
> 
> 
> 
>

---

From: Jan Melen <[email-masked]>
Date: Tue, 4 May 2010 17:00:30 +0300

Hi

1) I agree that the mobility and multihoming should be included in to the new scope.

2) STUN vs. Native! My opinion is that we should go for native as it reduces the implementation complexity quite a bit and there is not that much as is re-usable components in ICE/STUN.

   Regards,
     Jan

---

From: Ari Keranen <[email-masked]>
Date: Tue, 04 May 2010 18:46:56 +0300

On 05/03/2010 12:47 PM, Gonzalo Camarillo wrote:
> With respect to whether we want to go native or still use the
> STUN-based connectivity checks, it would be good to have more
> discussions on the list.

I think the best way forward would be to use native HIP messages for the 
standards track specification and the native NAT traversal mode draft 
should be a suitable basis for the work.

Our implementation experience and the benefits of the native mode 
(implementation effort, demuxing issues, etc.) were discussed at the 
last WG meeting and also on other threads on this list. After the 
discussions there have been no objections on, and quite a few of us feel 
strongly, that the native mode is a better idea. Or would someone still 
disagree on this?

I don't have a strong opinion on whether the mobility and multihoming 
with NAT traversal should be a separate document, but I think it is 
important that also this work gets done. If someone can devote enough 
quality cycles on this, a separate document could have more background 
and intro text explaining the different mm-scenarios and thus be useful. 
Otherwise we can have a shorter version as a part of the native mode draft.

Cheers,
Ari

>>>> -----Original Message----- From: [email-masked] 
>>>>  Sent: Tuesday, April 20, 2010 5:45 AM To: HIP Subject:
>>>> [Hipsec] NAT traversal and the standards track work
>>>> 
>>>> Hi,
>>>> 
>>>> we need to decide what to do with NAT traversal when moving to
>>>> the standards track. We have the following drafts:
>>>> 
>>>> The draft above proposes implementing HIP-based connectivity
>>>> checks instead of STUN-based ones.
>>>> 
>>>> The draft above, which needs to be revised, describes the
>>>> mobility and multihoming extensions for NAT traversal.
>>>> 
>>> Gonzalo, I would like to see both topics (NAT traversal, and
>>> mobility management aspects of NAT traversal) on the revised
>>> charter, as the second phase of standards-track work, as we
>>> discussed in Anaheim.  I am neutral on the questions of which one
>>> of the two drafts to adopt (if a choice needs to be made now) and
>>> on whether the nat-mm draft should remain separate or should be
>>> combined into one NAT traversal draft.
>>> 
>> I share Tom's opinion here. I would like to see both progress
>> (provided there is enough manpower to support both). However, I
>> think it might be useful to address mobility in the actual NAT
>> documents since it poses special challenges that are special to
>> NATs.
>> 
>> Tobias
>> 
>>> - Tom _

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 May 2010 19:17:19 +0300

Hi,

it seems we also have consensus on going native.

Cheers,

Gonzalo