Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

Gonzalo Camarillo <> Mon, 07 March 2016 12:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4285E1B4055 for <>; Mon, 7 Mar 2016 04:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dHal11dyj3vm for <>; Mon, 7 Mar 2016 04:35:11 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 994D81B4053 for <>; Mon, 7 Mar 2016 04:35:10 -0800 (PST)
X-AuditID: c1b4fb3a-f79ce6d000005138-b6-56dd757c2eee
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FC.97.20792.C757DD65; Mon, 7 Mar 2016 13:35:08 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 7 Mar 2016 13:35:07 +0100
To: Miika Komu <>,
References: <> <> <> <> <>
From: Gonzalo Camarillo <>
Message-ID: <>
Date: Mon, 07 Mar 2016 14:35:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7gW5N6d0wg61bRSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPZX15kKfglV7LzyhLWBsYe/i5GTQ0LAROLamc3MELaYxIV7 69m6GLk4hAQOM0r87psC5axmlGibsZ8dpEpYwF7i5L5bYLaIgLXEh8vLmUBsIYHXjBLTXhiC 2GwCFhJbbt1nAbF5BbQlJk1dAFTPwcEioCLxbnIxSFhUIEbiYucRJogSQYmTM5+AlXMK6EjM u/mREcRmFjCQOLJoDiuELS+x/e0cZohV2hLLn7WwTGAUmIWkfRaSlllIWhYwMq9iFC1OLS7O TTcy0kstykwuLs7P08tLLdnECAzBg1t+W+1gPPjc8RCjAAejEg/vB7W7YUKsiWXFlbmHGCU4 mJVEeDeUAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzsn26HCYkkJ5YkpqdmlqQWgSTZeLglGpg 9GXsvBhj27ekS2J3lHJI7L2U3Y+/Ncc2Sz2+ONGrflaOmcr60p2u37UW9DTefm7z+W3UisOX DBNWHXhlOq3t1fa9i97s80/P4Tzft+lk0WrX/05pm0x+dcvbddbpiLyYruvRMK3pAb/CNJeU 8pAO2z0eC/5P+2l4Or40fd+24FlbM9yv679xV2Ipzkg01GIuKk4EAFPX5Ws9AgAA
Archived-At: <>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Mar 2016 12:35:13 -0000


I have just talked with Miika and he has volunteered to take the pen and
add the necessary clarifications to the draft so that it is more
readable. Thanks, Miika!

First he will look into adding clarifications to the existing draft
while still referencing the old RFC. If the group is not happy with the
readability after the editorial pass (or our AD does not finally let us
downref the old RFC), we can consider bringing material from the old RFC
directly into the new one.

I would also like the group to comment on the following two proposals:

1) the draft will allow implementers to use HIP native relays only. In
addition, the use of STUN and TURN relays will be optional.

2) in addition to covering the base exchange, the draft will also cover
the mobility readdressing exchange.



On 29/02/2016 4:41 PM, Miika Komu wrote:
> Hi,
> On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote:
>> Hi Jeff,
>> thanks for your feedback.
>>> Regarding pros/cons:
>>> How widely-deployed is STUN/TURN? Are public servers widespread?
>> there are several of them. They are mostly used for VoIP. You can google
>> for "public stun turn servers" or something similar. There are a few
>> lists out there.
> I guess the situation is like this:
> HIP control plane relay:
> * new critical infrastructure that needs to be deployed anyway (TURN
> server cannot be used for this)
> Gathering of address candidates:
> * from a STUN server (many available)
> * ...or from control plane relay registration (which is mandatory anyway)
> Data plane relay:
> * using TURN server (it seems some are available)
> * ...or using the ESP relay as specified in native NAT spec (none
> deployed, but I guess could co-locate with the HIP control plane relay)
> So, the critical part are the HIP control plane relays which provide
> also similar functionality as STUN servers (i.e. provide server
> reflexive candidates). So I guess the question boils down to the
> availability of TURN servers.
> P.S. Nothing really prevents to use STUN servers to discover address
> candidates in the native NAT traversal version. The discovery process is
> independent of the NAT penetration process.
> _______________________________________________
> Hipsec mailing list