From behave-bounces@ietf.org Tue May 01 12:45:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HivUD-00081d-Nw; Tue, 01 May 2007 12:45:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HivUD-00081H-9R for behave-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 12:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HivUC-000819-WA; Tue, 01 May 2007 12:45:57 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HivUB-0000Ib-PB; Tue, 01 May 2007 12:45:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id B50D832897; Tue, 1 May 2007 16:45:55 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HivUB-0002ye-Kj; Tue, 01 May 2007 12:45:55 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 01 May 2007 12:45:55 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Internet Architecture Board , behave mailing list , behave chair , RFC Editor Subject: [BEHAVE] Protocol Action: 'NAT Behavioral Requirements for TCP' to BCP X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The IESG has approved the following document: - 'NAT Behavioral Requirements for TCP ' as a BCP This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-tcp-07.txt Technical Summary This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. Working Group Summary This document was a product of the BEHAVE working group. There is consensus to publish this document. Protocol Quality This document describes recommended practices for NATs. Most existing NATs already conform to these requirements. The document has benefitted from comments and reviewes by people active in TCPM. It was also WG last called in TCPM. IETF Last call comments has been addressed. Personnel Dan Wing is the Document Shepherd, and Magnus Westerlund is the Responsible Area Director. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 03 07:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjZF1-0004PJ-2U; Thu, 03 May 2007 07:12:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HjZEz-0004M2-Es for behave-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 07:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjZEw-0004IW-Gc for behave@ietf.org; Thu, 03 May 2007 07:12:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjZEv-0003s3-6F for behave@ietf.org; Thu, 03 May 2007 07:12:50 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 90097213C0; Thu, 3 May 2007 13:12:48 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-c9-4639c3b0ed21 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 76517213F2; Thu, 3 May 2007 13:12:48 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 13:12:48 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 13:12:48 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E400B232F; Thu, 3 May 2007 14:12:47 +0300 (EEST) Message-ID: <4639C3AE.9010002@ericsson.com> Date: Thu, 03 May 2007 14:12:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Alfred E. Heggestad" Subject: Re: [BEHAVE] Comments on turn-ipv6 References: <461A6F8F.9060905@db.org> In-Reply-To: <461A6F8F.9060905@db.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2007 11:12:48.0190 (UTC) FILETIME=[FB6675E0:01C78D73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Oscar Novo , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, > I would like to suggest that this spec could be merged into the > main TURN spec (turn-03). Is there any reason why we need to publish > this as a separate document? I will leave this decision to the chairs. I am fine either way. > Section 4.1 Allocating a Binding > > The length is specified to be 8 bytes. I think this should be 4 bytes, > as a STUN attribute specifies the number of bytes in the attribute > *payload* excluding the 4 bytes in the STUN attribute. True. We will fix this in the next revision of the document. Cheers, Gonzalo _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 03 18:06:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjjRp-00025u-6C; Thu, 03 May 2007 18:06:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HjjRn-00025i-1Q for behave-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 18:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjjRm-00025a-OE for behave@ietf.org; Thu, 03 May 2007 18:06:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjjRl-0005BD-FY for behave@ietf.org; Thu, 03 May 2007 18:06:46 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 May 2007 15:06:43 -0700 X-IronPort-AV: i="4.14,487,1170662400"; d="scan'208"; a="483366247:sNHT1390229128" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l43M6g89005960 for ; Thu, 3 May 2007 15:06:42 -0700 Received: from [128.107.139.43] (dhcp-128-107-139-43.cisco.com [128.107.139.43]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l43M6fEi013800 for ; Thu, 3 May 2007 22:06:41 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <3F0FED04-F593-4A26-B66B-6C85DFFF8E18@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Behave WG From: Cullen Jennings Date: Thu, 3 May 2007 15:06:35 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=516; t=1178230002; x=1179094002; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20ICMP=20type=203,=20code=2013,=20one=20more=20time=20 |Sender:=20; bh=oHu0heUpx0lcyvCZXzvsTW/qER2vk9E22JE9oBUNP4M=; b=Tk3BA28ItYUcduUMsOcDimPwP0mLZLQ+Gss43/QXrkOK8CMEmxNLw6tThkWOHuLbgFm9A8p6 8N+uG4cC/e9OW/bLbDSdgD/PtSc75F3nN++a/eA8y2k/irBlySBSoi7YJYqAy1a4uaL+5Omdhw oLOSC3uwyQUw89GTfRtosLeTs=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [BEHAVE] ICMP type 3, code 13, one more time X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I was having lunch today with Srisuresh and we came to an interesting inside on how to resolve this. The important thing is not if a NAT thinks it's a router, host, or power tool. The important thing is what does an applications that receives the ICMP error does. One observation is that it might be that you want error codes sent to the inside to be different than one sent to the outside. The other observation is that if 9,10,13 are all soft errors - do we want a soft or hard error here? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 04 16:53:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk4mp-0001GD-GR; Fri, 04 May 2007 16:53:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hk4mp-0001G8-1N for behave-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 16:53:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk4mo-0001G0-O5 for behave@ietf.org; Fri, 04 May 2007 16:53:54 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk4mn-0003eL-F2 for behave@ietf.org; Fri, 04 May 2007 16:53:54 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 04 May 2007 13:53:52 -0700 X-IronPort-AV: i="4.14,494,1170662400"; d="scan'208"; a="58055741:sNHT38573118" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l44KrqhN013444; Fri, 4 May 2007 13:53:52 -0700 Received: from dwingwxp (dhcp-128-107-163-196.cisco.com [128.107.163.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l44Krqwn012090; Fri, 4 May 2007 20:53:52 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Behave WG'" Subject: RE: [BEHAVE] ICMP type 3, code 13, one more time Date: Fri, 4 May 2007 13:53:52 -0700 Message-ID: <00da01c78e8e$52a58d30$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <3F0FED04-F593-4A26-B66B-6C85DFFF8E18@cisco.com> Thread-Index: AceNz2Z0k99u5WfkTlOTK6nG0Dt0mgAvbJ6w DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1163; t=1178312032; x=1179176032; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ICMP=20type=203, =20code=2013, =20one=20more =20time=20 |Sender:=20; bh=gM0pEJPMVa+RTPaBknugzY4Iso6Jd99biRAwmwIj2eI=; b=cFIGeDeF52i4+dlX4TsGSgPRi58D8kzfjFDuK0Mgt2jjEGVB5NUylCBYpbIQeI7SqnYc+BhM vj2aspVSTjRmxUtkP04DrHi1Fh3KL71GPy3EAbOUk3g9l5XfQ1k6fFDD; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, May 03, 2007 3:07 PM > To: Behave WG > Subject: [BEHAVE] ICMP type 3, code 13, one more time > > > I was having lunch today with Srisuresh and we came to an > interesting > inside on how to resolve this. The important thing is not if a NAT > thinks it's a router, host, or power tool. The important thing is > what does an applications that receives the ICMP error does. One > observation is that it might be that you want error codes > sent to the inside to be different than one sent to the outside. When the NAT can't create a new mapping, the ICMP error would only be sent to the inside. Afterall, it's not possible to even create a new mapping from the outside. > The other > observation is that if 9,10,13 are all soft errors - do we want a > soft or hard error here? A NAT that runs out of resources (say, runs out of UDP mappings) seems a transient event on par with a routing error such as 'network unreachable' (ICMP type=3, code=0), which is classified as a soft error. (as individual.) -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 04 20:29:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk892-0002U6-JO; Fri, 04 May 2007 20:29:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hk890-0002RB-Sw for behave-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 20:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk890-0002Q2-IE for behave@ietf.org; Fri, 04 May 2007 20:29:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk88z-0003FY-83 for behave@ietf.org; Fri, 04 May 2007 20:29:02 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 04 May 2007 17:28:00 -0700 X-IronPort-AV: i="4.14,494,1170662400"; d="scan'208"; a="418831234:sNHT45067436" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l450S0tl025412; Fri, 4 May 2007 17:28:00 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l450Rwwo020292; Sat, 5 May 2007 00:27:58 GMT In-Reply-To: <00da01c78e8e$52a58d30$c4a36b80@amer.cisco.com> References: <00da01c78e8e$52a58d30$c4a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6DB517DD-983F-4DB5-9473-153BFEEF0E62@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [BEHAVE] ICMP type 3, code 13, one more time Date: Fri, 4 May 2007 17:27:18 -0700 To: Dan Wing X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=919; t=1178324880; x=1179188880; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[BEHAVE]=20ICMP=20type=203, =20code=2013, =20one=20more =20time=20 |Sender:=20; bh=AH5UjG7NfdZN94po1EvdfQQ42zYPud41drcme9WT8LQ=; b=P0dludwb2CrE5m4ZpVCHZWxU9tSETxqX05uyBbP+kor6Mh3nNwHEKL6CFLFPNiWkdVit9+N2 61094EPynqYChUM3S/b7xsK2o4EWuMIKxdwfyyHzdBFMR725iJRX7ShN; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'Behave WG' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On May 4, 2007, at 1:53 PM, Dan Wing wrote: > > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Thursday, May 03, 2007 3:07 PM >> To: Behave WG >> Subject: [BEHAVE] ICMP type 3, code 13, one more time >> >> >> I was having lunch today with Srisuresh and we came to an >> interesting >> inside on how to resolve this. The important thing is not if a NAT >> thinks it's a router, host, or power tool. The important thing is >> what does an applications that receives the ICMP error does. One >> observation is that it might be that you want error codes >> sent to the inside to be different than one sent to the outside. > > When the NAT can't create a new mapping, the ICMP error would only be > sent to the inside. Afterall, it's not possible to even create a > new mapping from the outside. Good point - I don't know what happened to my brain :-) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon May 07 06:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0T5-0001Sj-RT; Mon, 07 May 2007 06:29:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hl0T4-0001Sb-Qv for behave-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 06:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0T4-0001SQ-28 for behave@ietf.org; Mon, 07 May 2007 06:29:22 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl0T2-0007UG-K9 for behave@ietf.org; Mon, 07 May 2007 06:29:22 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l47ASmkV007620; Mon, 7 May 2007 13:29:00 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 13:28:49 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 13:28:48 +0300 Received: from esdhcp04178.research.nokia.com ([172.21.41.78]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 13:28:48 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] Comments on turn-ipv6 Date: Mon, 7 May 2007 13:28:52 +0300 User-Agent: KMail/1.9.6 References: <461A6F8F.9060905@db.org> <4639C3AE.9010002@ericsson.com> In-Reply-To: <4639C3AE.9010002@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705071328.52563.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 07 May 2007 10:28:48.0703 (UTC) FILETIME=[7FCBB4F0:01C79092] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ext Gonzalo Camarillo X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, On Thursday 03 May 2007 14:12:46 ext Gonzalo Camarillo wrote: > > I would like to suggest that this spec could be merged into the > > main TURN spec (turn-03). Is there any reason why we need to publish > > this as a separate document? > > I will leave this decision to the chairs. I am fine either way. In light of the ICE, ANAT, and addrsel (RFC3484) debate, I daresay that the= =20 idea of a "REQUEST-ADDRESS-TYPE" might be too simplistic or suboptimal. I would feel that for RFC3484 to operate best, and in particular, to cover = the=20 case where it is not known whether the other end has v4, v6 or both, it mig= ht=20 make much more sense for the TURN relay to offer a list of possible=20 addresses. In fact, from RFC3484/addrsel perspective, it should include at= =20 least one address for each of the label that are defined (so long as it has= =20 one of course). Note that it might have to put *several* IPv6 addresses=20 there, so REQUEST-ADDRESS-TYPE is insufficient. What about not changing anything the Allocate Request, and a new optional=20 attribute in the Allocate Response listing the IPv6 addresses offered by th= e=20 relay? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon May 07 18:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlC23-0005rp-KV; Mon, 07 May 2007 18:50:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HlC1w-0005iX-5e for behave-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 18:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlC1v-0005iG-Q2; Mon, 07 May 2007 18:50:07 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlC1q-0003pL-Qx; Mon, 07 May 2007 18:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A5A4626E8C; Mon, 7 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HlC1q-0001t4-Hn; Mon, 07 May 2007 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 07 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition Author(s) : G. Camarillo, O. Novo Filename : draft-ietf-behave-turn-ipv6-02.txt Pages : 8 Date : 2007-5-7 This document defines the REQUESTED-ADDRESS-TYPE attribute for the Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a client to explicitly request the address type the STUN relay server will allocate (e.g., an IPv4-only node may request the STUN relay server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-turn-ipv6-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-turn-ipv6-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-7164403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-turn-ipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-turn-ipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-7164403.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Wed May 09 09:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlm6c-0002Ob-Ff; Wed, 09 May 2007 09:21:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hlm6b-0002OT-1O for behave-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 09:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlm6a-0002OL-OE for behave@ietf.org; Wed, 09 May 2007 09:21:20 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlm6Z-0004rR-9W for behave@ietf.org; Wed, 09 May 2007 09:21:20 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49DL5LI032165; Wed, 9 May 2007 16:21:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 16:21:15 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 16:21:14 +0300 Received: from esdhcp04050.research.nokia.com ([172.21.40.50]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 16:21:14 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org, Gonzalo.Camarillo@ericsson.com, Oscar.Novo@ericsson.com Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Wed, 9 May 2007 16:21:16 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200705091621.16443.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 09 May 2007 13:21:14.0302 (UTC) FILETIME=[EB1455E0:01C7923C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, On Tuesday 08 May 2007 01:50:02 ext behave-bounces@ietf.org wrote: > This document defines the REQUESTED-ADDRESS-TYPE attribute for the > Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a > client to explicitly request the address type the STUN relay server > will allocate (e.g., an IPv4-only node may request the STUN relay > server to allocate an IPv6 address). Additionally, this document > also defines a new error response code with the value 440 (Address > Family not Supported). A few notes: 1/ Format for the family parameter within the attribute is not consistent w= ith=20 that used in STUN (XOR-)MAPPED-ADDRESS et al, where it consists of a single= =20 byte. Is there any reason for this? 2/ In my humble opinion, the address family numbers should simply refer to = the=20 base STUN spec instead of redefining the same values... so we do not need t= o=20 duplicate effort if we ever were to define new families (HIP?). 3/ I might have missed it, but what is the request address type is absent?= =20 Should the default be "always IPv4", or "protocol through which the server= =20 received the Allocate Request" ? I would assume "always IPv4" is better,=20 consistent with RFC3489bis insistance that there might be IPv4-to-IPv6 or=20 IPv6-to-IPv4 translation middleboxes. 4/ As I already pointed out earlier, the current TURN-IPv6 model does not=20 quite seem to fit with RFC3484, ICE and/or ANAT. I'd rather expect the serv= er=20 returns a list of possible addresses, one per RFC3484 label, as far as it h= as=20 such an address. Regards, =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 10 15:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEf5-0006Z5-HT; Thu, 10 May 2007 15:50:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HmEeo-0005xY-VZ for behave-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 15:50:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEeo-0005vC-6w; Thu, 10 May 2007 15:50:34 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HmEem-0007nt-Q6; Thu, 10 May 2007 15:50:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 59B982ACEF; Thu, 10 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HmEeI-0002ul-3M; Thu, 10 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 10 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-multicast-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Multicast Requirements for a Network Address Port Translator (NAPT) Author(s) : D. Wing Filename : draft-ietf-behave-multicast-05.txt Pages : 10 Date : 2007-5-10 This document specifies requirements for a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports any-source multicast or single-source multicast. A multicast-capable NAPT device that adheres to the requirements of this document can optimize the operation of multicast applications that are generally unaware of multicast NAPT devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-10103217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-10103217.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Thu May 10 19:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmI4D-0002Js-O0; Thu, 10 May 2007 19:29:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HmI4C-0002Jn-DW for behave-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 19:29:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmI4C-0002Jf-3l for behave@ietf.org; Thu, 10 May 2007 19:29:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmI49-0001Kp-QX for behave@ietf.org; Thu, 10 May 2007 19:29:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 10 May 2007 16:28:57 -0700 X-IronPort-AV: i="4.14,519,1170662400"; d="scan'208"; a="147378564:sNHT44160921" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4ANSvtY023454 for ; Thu, 10 May 2007 16:28:57 -0700 Received: from dwingwxp (dhcp-128-107-163-206.cisco.com [128.107.163.206]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4ANSv20016991 for ; Thu, 10 May 2007 23:28:57 GMT From: "Dan Wing" To: Date: Thu, 10 May 2007 16:28:57 -0700 Message-ID: <112001c7935a$fb528f20$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceTPIdDfjEC3mLqQm2OJnvk4A3WagAHcHVg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=274; t=1178839737; x=1179703737; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20draft-ietf-behave-multicast-05.txt=20 |Sender:=20; bh=GyjbXJMnexKWTygIP7TG6Xb4KhVel/Eoyq69swuatZI=; b=Cpgt7SR90wJfM6vP+0MFqdk/SuEOdsv9rp2xTjbFj0w3H35M963nvfuotAxBD4GAthdqIPme l/5dAq9wf2d6m5qU1Q38shqQFupgAOmYb8MunnobHmEgBP2RMr2qNHKg; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [BEHAVE] draft-ietf-behave-multicast-05.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org This is a significant rewrite from previous versions and includes all of the feedback I had received. The new version covers any-source multicast, source-specific multicast and IGMPv1-v3. http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-05.txt -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 11 00:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMZJ-0000My-2m; Fri, 11 May 2007 00:17:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HmMZI-0000Mk-7n for behave-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 00:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmMZH-0000M9-9L for behave@ietf.org; Fri, 11 May 2007 00:17:23 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmMZG-0000gu-17 for behave@ietf.org; Fri, 11 May 2007 00:17:23 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 10 May 2007 21:17:21 -0700 X-IronPort-AV: i="4.14,520,1170662400"; d="scan'208"; a="420898461:sNHT42399744" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4B4HLTF013465; Thu, 10 May 2007 21:17:21 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4B4HKV1012809; Fri, 11 May 2007 04:17:20 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , , , Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Thu, 10 May 2007 21:17:20 -0700 Message-ID: <001101c79383$4510db80$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceSPPdqnhpjcUOVTXmWDTorFHMqlQBQeGew In-Reply-To: <200705091621.16443.remi.denis-courmont@nokia.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=475; t=1178857041; x=1179721041; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20I-D=20ACTION=3Adraft-ietf-behave-turn-ipv6 -02.txt |Sender:=20; bh=eERGyv4wfimENxmz/aVHmyeSd3xBSisHGFDDlrh+O6o=; b=UYXtRM7gywIqSo6jgcAcsbEA+91B7R+HwYhLUbmZdJfi588aW/AYC/hHlUqn+mB+W866x8Zb Ij0Uu8g+j1yIaFXtsZ0QCk5dp3Yz4XE/E/cOX9WiR6ej1jqamTnUAquR; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org ... > 4/ As I already pointed out earlier, the current TURN-IPv6 > model does not quite seem to fit with RFC3484, ICE and/or ANAT. > I'd rather expect the server > returns a list of possible addresses, one per RFC3484 label, > as far as it has such an address. I expect this could that be accomplished by returning multiple RELAY-ADDRESS attributes, yes? I don't the need to return the TURN server's RFC3484 label itself, though -- is that necessary? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 11 03:46:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmPpH-0000ge-Dl; Fri, 11 May 2007 03:46:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HmPpF-0000gZ-Hp for behave-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 03:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmPpC-0000gN-GX for behave@ietf.org; Fri, 11 May 2007 03:46:02 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmPpB-0002np-01 for behave@ietf.org; Fri, 11 May 2007 03:46:02 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4B7jPcn021541; Fri, 11 May 2007 10:45:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 10:45:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 10:45:51 +0300 Received: from esdhcp041149.research.nokia.com ([172.21.41.149]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 10:45:51 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Fri, 11 May 2007 10:45:58 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> In-Reply-To: <001101c79383$4510db80$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705111045.58341.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 May 2007 07:45:51.0705 (UTC) FILETIME=[65E73490:01C793A0] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Oscar.Novo@ericsson.com, behave@ietf.org, Gonzalo.Camarillo@ericsson.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 11 May 2007 07:17:20 ext Dan Wing wrote: > > 4/ As I already pointed out earlier, the current TURN-IPv6 > > model does not quite seem to fit with RFC3484, ICE and/or ANAT. > > I'd rather expect the server > > returns a list of possible addresses, one per RFC3484 label, > > as far as it has such an address. > > I expect this could that be accomplished by returning multiple > RELAY-ADDRESS attributes, yes? I have seen several STUN implementations that can only handle one attribute= of=20 any given type per message, but otherwise that should work. > I don't the need to return the TURN server's RFC3484 label itself, though > -- is that necessary? No, of course not. Labels depend on the local system configuration anyway,= =20 that was only a hint that, in view of RFC3484, it would be better to not on= ly=20 give a native IPv6 address, but also (if one is available), say a 6to4=20 address, an ULA, and so on... =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 11 03:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmPxg-0008EA-Vj; Fri, 11 May 2007 03:54:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HmPxf-0008BJ-Q5 for behave-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 03:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmPxf-00089G-De for behave@ietf.org; Fri, 11 May 2007 03:54:47 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmPxd-0003UD-KD for behave@ietf.org; Fri, 11 May 2007 03:54:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4B7sbH4006795; Fri, 11 May 2007 10:54:42 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 10:54:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 10:54:25 +0300 Received: from esdhcp041149.research.nokia.com ([172.21.41.149]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 10:54:19 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-multicast-05.txt Date: Fri, 11 May 2007 10:54:26 +0300 User-Agent: KMail/1.9.6 References: <112001c7935a$fb528f20$c4a36b80@amer.cisco.com> In-Reply-To: <112001c7935a$fb528f20$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705111054.26828.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 May 2007 07:54:19.0964 (UTC) FILETIME=[94D95FC0:01C793A1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 11 May 2007 02:28:57 ext Dan Wing wrote: > This is a significant rewrite from previous versions and includes all of > the feedback I had received. The new version covers any-source multicast, > source-specific multicast and IGMPv1-v3. Most likely a typing error at =A7 4.2 w.r.t. IMGP versions. Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 11 14:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmaFr-0007D5-8M; Fri, 11 May 2007 14:54:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HmaFq-0007Cz-D2 for behave-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 14:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmaFq-0007Cr-3Y for behave@ietf.org; Fri, 11 May 2007 14:54:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmaFo-0002TS-Qq for behave@ietf.org; Fri, 11 May 2007 14:54:14 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 11 May 2007 11:54:12 -0700 X-IronPort-AV: i="4.14,523,1170662400"; d="scan'208"; a="421152788:sNHT45624116" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4BIsC7e007431; Fri, 11 May 2007 11:54:12 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4BIsBV1019272; Fri, 11 May 2007 18:54:11 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Fri, 11 May 2007 11:54:10 -0700 Message-ID: <01be01c793fd$c33296f0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200705111045.58341.remi.denis-courmont@nokia.com> Thread-index: AceToGrY/XdfTlHgT3++2xpvI2YJqAAXPcAg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1348; t=1178909652; x=1179773652; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20I-D=20ACTION=3Adraft-ietf-behave-turn-ipv6 -02.txt |Sender:=20; bh=hbPLqYrkUoJCZd7zUnihSw8D7HRTukDYwx5fygor+gA=; b=VUwWvjEbhJQRuNJBdu0Y9yc+rskT4Svgdhpv/dzNMtmO3Wka7oYu6mpWpWyDuMCo8bmJOgzq xJNTgJJVTaYZHQsX+2maO6rwNeN0DP/Mqohxay+MJy5cbGQqgzHFAKGC; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Oscar.Novo@ericsson.com, behave@ietf.org, Gonzalo.Camarillo@ericsson.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > On Friday 11 May 2007 07:17:20 ext Dan Wing wrote: > > > 4/ As I already pointed out earlier, the current TURN-IPv6 > > > model does not quite seem to fit with RFC3484, ICE and/or ANAT. > > > I'd rather expect the server > > > returns a list of possible addresses, one per RFC3484 label, > > > as far as it has such an address. > > > > I expect this could that be accomplished by returning multiple > > RELAY-ADDRESS attributes, yes? > > I have seen several STUN implementations that can only handle > one attribute of any given type per message, but otherwise > that should work. We can restrict the TURN server's retuning of multiple RELAY-ADDRESSes so they are only returned if the STUN client included the Magic Cookie value (which indicates the STUN client is rfc3489bis compliant, rather than rfc3489 compliant). > > I don't the need to return the TURN server's RFC3484 label > > itself, though -- is that necessary? > > No, of course not. Labels depend on the local system > configuration anyway, that was only a hint that, in view of > RFC3484, it would be better to not only give a native IPv6 > address, but also (if one is available), say a 6to4 > address, an ULA, and so on... But could an ICE endpoint find such information useful in prioritizing or preferring different addresses? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat May 12 12:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmudJ-0006jO-Cn; Sat, 12 May 2007 12:39:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hmg5R-0003D9-Mu for behave-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 21:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmg5R-0003D1-BZ for behave@ietf.org; Fri, 11 May 2007 21:07:53 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmg5P-0003yZ-2b for behave@ietf.org; Fri, 11 May 2007 21:07:53 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4C16t707198; Sat, 12 May 2007 01:06:55 GMT Received: from [47.130.18.117] ([47.130.18.117] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 21:07:47 -0400 Message-ID: <4645132B.9080400@nortel.com> Date: Fri, 11 May 2007 21:06:51 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: behave mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2007 01:07:47.0285 (UTC) FILETIME=[F417B050:01C79431] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Sat, 12 May 2007 12:39:49 -0400 Cc: Colin Perkins Subject: [BEHAVE] draft-ietf-avt-rtp-and-rtcp-mux-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The subject draft describes procedures for multiplexing RTP and RTCP over a single port. This may be of interest to members of the BEHAVE Working Group because it should simplify NAT traversal for RTP-based media streams. The draft has already passed AVT WGLC, but if anyone has any comments please send them to the AVT Chairs and/or the AVT list and they will be passed on as required. Tom Taylor _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon May 14 02:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnTs3-0008Fv-QU; Mon, 14 May 2007 02:17:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HnTs2-0008C7-Ah for behave-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 02:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnTs1-0008Bz-Uc for behave@ietf.org; Mon, 14 May 2007 02:17:21 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnTs1-0002bq-2S for behave@ietf.org; Mon, 14 May 2007 02:17:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4E6HES5006561; Mon, 14 May 2007 09:17:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 09:16:56 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 09:16:56 +0300 Received: from esdhcp04030.research.nokia.com ([172.21.40.30]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 09:16:55 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Dan Wing" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Mon, 14 May 2007 09:17:06 +0300 User-Agent: KMail/1.9.6 References: <01be01c793fd$c33296f0$c5f0200a@amer.cisco.com> In-Reply-To: <01be01c793fd$c33296f0$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705140917.06358.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 14 May 2007 06:16:55.0798 (UTC) FILETIME=[78B1A960:01C795EF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Oscar.Novo@ericsson.com, behave@ietf.org, Gonzalo.Camarillo@ericsson.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 11 May 2007 21:54:10 ext Dan Wing wrote: > > On Friday 11 May 2007 07:17:20 ext Dan Wing wrote: > > > > 4/ As I already pointed out earlier, the current TURN-IPv6 > > > > model does not quite seem to fit with RFC3484, ICE and/or ANAT. > > > > I'd rather expect the server > > > > returns a list of possible addresses, one per RFC3484 label, > > > > as far as it has such an address. > > > > > > I expect this could that be accomplished by returning multiple > > > RELAY-ADDRESS attributes, yes? > > > > I have seen several STUN implementations that can only handle > > one attribute of any given type per message, but otherwise > > that should work. > > We can restrict the TURN server's retuning of multiple > RELAY-ADDRESSes so they are only returned if the STUN client > included the Magic Cookie value (which indicates the STUN client > is rfc3489bis compliant, rather than rfc3489 compliant). Well, I meant some STUN parsers, regardless of RFC3489 or RFC3489bis. If we= go=20 that route, I believe RFC3489bis will need some more explicit note that an= =20 implementation must be able to handle duplicate attribute types. > > > I don't the need to return the TURN server's RFC3484 label > > > itself, though -- is that necessary? > > > > No, of course not. Labels depend on the local system > > configuration anyway, that was only a hint that, in view of > > RFC3484, it would be better to not only give a native IPv6 > > address, but also (if one is available), say a 6to4 > > address, an ULA, and so on... > > But could an ICE endpoint find such information useful in prioritizing or > preferring different addresses? One obvious benefit to this approach compared to the REQUEST-ADDRESS-TYPE=20 approach is that it avoids duplicating the TURN state machine (and RTT) on= =20 both the TURN client and the TURN server if the client is dual-stack. The usefulness of getting both an IPv4 and a IPv6 address looks obvious: AN= AT=20 needs that, and ICE-to-replace-ANAT will need it too. As for including a 6t= o4=20 or Teredo address in addition to a native IPv6, it avoids "quadrangular"=20 routing such as this: TURN client exchanges packets over NATed IPv4 with TURN server, which exchanges packets over native IPv6 with 6to4 relay, which exchanges packets over proto-41 with Peer and does that instead: TURN client exchanges packets over NATed IPv4 with TURN server, which servers as its own 6to4 relay exchanges packets over proto-41 with Peer But maybe I am too optimistic as too how well ICE will pair candidates. Ind= eed=20 IETF hasn't defined an API for RFC3484 :( Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 16 01:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoCXW-0001sf-UY; Wed, 16 May 2007 01:59:10 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoCXW-0001sY-7V for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 01:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoCXV-0001sQ-QI for behave@ietf.org; Wed, 16 May 2007 01:59:09 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoCXT-0004Du-VO for behave@ietf.org; Wed, 16 May 2007 01:59:09 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4G5wnaP015637; Wed, 16 May 2007 08:59:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:59:03 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:59:02 +0300 Received: from esdhcp04329.research.nokia.com ([172.21.43.29]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 08:59:02 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Oscar Novo (JO/LMF)" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Wed, 16 May 2007 08:59:14 +0300 User-Agent: KMail/1.9.6 References: <200705091621.16443.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705160859.15124.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 16 May 2007 05:59:02.0678 (UTC) FILETIME=[4DE40B60:01C7977F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 15 May 2007 17:17:05 ext Oscar Novo (JO/LMF) wrote: > 1/ Format for the family parameter within the attribute is not consistent > with that used in STUN (XOR-)MAPPED-ADDRESS et al, where it consists of a > single byte. Is there any reason for this? > > [ON] We can change the family parameter to a single byte to be consistent > with the MAPPED-ADDRESS. > > 2/ In my humble opinion, the address family numbers should simply refer to > the base STUN spec instead of redefining the same values... so we do not > need to duplicate effort if we ever were to define new families (HIP?). > > [ON] STUN spec does not define any number for IPv6. It only defines the > number for IPv4. =46rom draft-ietf-behave-rfc3489bis-06 =A711.1: The address family can take on the following values: 0x01:IPv4 0x02:IPv6 I assume TURN-IPv6 depends on rfc3489bis due to depending on STUN Relay=20 Usage/TURN. > 3/ I might have missed it, but what is the request address type is absent? > Should the default be "always IPv4", or "protocol through which the server > received the Allocate Request" ? I would assume "always IPv4" is better, > consistent with RFC3489bis insistance that there might be IPv4-to-IPv6 or > IPv6-to-IPv4 translation middleboxes. > > [ON] This draft defines a new attribute for STUN. If that attribute is > absented you should follow the STUN spec and assume always IPv4. The same RFC3489bis section says: It is possible for an IPv4 host to receive a MAPPED-ADDRESS containing an IPv6 address, or for an IPv6 host to receive a MAPPED- ADDRESS containing an IPv4 address. Clients MUST be prepared for this case. So this does not seem all that obvious to me. I however agree that it shoul= d=20 be IPv4 by default EVEN IF the Allocate Request came through IPv6, to avoid= =20 problems with any kind of IPv4-to-IPv6 translation on the path. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 16 14:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOMH-0007ui-Og; Wed, 16 May 2007 14:36:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoOMF-0007ua-QS for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 14:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOMF-0007uP-Gg for behave@ietf.org; Wed, 16 May 2007 14:36:19 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoOME-0006G4-83 for behave@ietf.org; Wed, 16 May 2007 14:36:19 -0400 Received: by py-out-1112.google.com with SMTP id f31so578645pyh for ; Wed, 16 May 2007 11:36:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=rh5h2HoubHgGM96T/wtK7DpRWPZa0Qblynpfrw8N/9xowZGoTTkwIBCBMqI2+wBQYuuv84mt7j89TZwYLaSKMyJJHegMnpZzBGRQAudpEaLNoLpHtRIaeEr3ThlnZzGygiMS3xrg/WZswsdi9HvMYwscqlPQyQHBzIsUscRoauU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uF9nXf44YW1X103fVy19JwraTOWneU0BTFD5Qer4GMAZpSIJ7UdGdxKm4RwRim1g9b5n2ApncMAqLFb5nGi7V459cpiYuxPb6pQv1bVaLiMAZjo3vDY/diAjgF10VFDvFp6Nd1bfRFqbmoIKP8vqJh1CdSApzHRF/MagiF7wxUg= Received: by 10.35.18.4 with SMTP id v4mr15451864pyi.1179340577735; Wed, 16 May 2007 11:36:17 -0700 (PDT) Received: by 10.35.67.18 with HTTP; Wed, 16 May 2007 11:36:17 -0700 (PDT) Message-ID: Date: Wed, 16 May 2007 14:36:17 -0400 From: "Adam Fisk" To: behave@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1449672551==" Errors-To: behave-bounces@ietf.org --===============1449672551== Content-Type: multipart/alternative; boundary="----=_Part_13245_17192589.1179340577334" ------=_Part_13245_17192589.1179340577334 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline As others have mentioned, I found the Message Type section to be a little opaque. Is the diagram a format that's in common use, and I just haven't seen it? Why does it start with M11 and opposed to M0, reading from left to right? I understand the unique location of the class bits is for backwards compatibility, but I just found it difficult to quickly grok where I should put those darn bits for the field as a whole (C1 and C0 weren't the confusing part). The "1" and "0" on the second line appear to be there to keep everything aligned, but couldn't there just an extra space after those two "M"s, as in: +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ |M |M |M|M|M|C|M|M|M|C|M|M|M|M| |11|10|9|8|7|1|6|5|4|0|3|2|1|0| +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ I at first thought the extra lines signified extra mysterious bits. I also still don't understand why it doesn't start with 0 reading from left to right. Thanks. -Adam ------=_Part_13245_17192589.1179340577334 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline As others have mentioned, I found the Message Type section to be a little opaque.  Is the diagram a format that's in common use, and I just haven't seen it?  Why does it start with M11 and opposed to M0, reading from left to right? 

I understand the unique location of the class bits is for backwards compatibility, but I just found it difficult to quickly grok where I should put those darn bits for the field as a whole (C1 and C0 weren't the confusing part).  The "1" and "0" on the second line appear to be there to keep everything aligned, but couldn't there just an extra space after those two "M"s, as in:

+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+

I at first thought the extra lines signified extra mysterious bits.  I also still don't understand why it doesn't start with 0 reading from left to right.

Thanks.

-Adam
 ------=_Part_13245_17192589.1179340577334-- --===============1449672551== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1449672551==-- From behave-bounces@ietf.org Wed May 16 14:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOWg-0000MH-4d; Wed, 16 May 2007 14:47:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoOWf-0000JS-Gk for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 14:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoOWf-0000IN-5z for behave@ietf.org; Wed, 16 May 2007 14:47:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoOWc-0000fi-QI for behave@ietf.org; Wed, 16 May 2007 14:47:05 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 May 2007 11:47:02 -0700 X-IronPort-AV: i="4.14,544,1170662400"; d="scan'208"; a="354536:sNHT19282272" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4GIl2Pl014267; Wed, 16 May 2007 11:47:02 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4GIl1aI027162; Wed, 16 May 2007 18:47:01 GMT From: "Dan Wing" To: "'Adam Fisk'" , Subject: RE: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt Date: Wed, 16 May 2007 11:47:01 -0700 Message-ID: <03bc01c797ea$974d5e80$dc6f6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceX6T2ZHlMi9xlDSQy3yhBDucyb+wAAOrPw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1421; t=1179341222; x=1180205222; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20message=20type=20in=20draft-ietf-behave-rf c3489bis-06.txt |Sender:=20; bh=puOee09+o/tHxmwEhkhfgUuB6KlxCpXXakmT2ylP3gc=; b=VL5QvHPxSL91MCeE1LWttiNQ28zsUe6qg5W75AVwgzaTjlVxjh4D1/8ndxm+IqYUWsMeCYJt ROxvtM42nXJuQ/DumdsekvvZ7nXPeFsa+Bzt3dpomcVPpaGYMWTaGDSR; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I agree your figure is easier to read. We'll adopt that for the next revision of rfc3489bis. I don't understand, though, why you would want to reverse the bit numbering? -d > -----Original Message----- > From: Adam Fisk [mailto:adamfisk@gmail.com] > Sent: Wednesday, May 16, 2007 11:36 AM > To: behave@ietf.org > Subject: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt > > As others have mentioned, I found the Message Type section to > be a little opaque. Is the diagram a format that's in common > use, and I just haven't seen it? Why does it start with M11 > and opposed to M0, reading from left to right? > > I understand the unique location of the class bits is for > backwards compatibility, but I just found it difficult to > quickly grok where I should put those darn bits for the field > as a whole (C1 and C0 weren't the confusing part). The "1" > and "0" on the second line appear to be there to keep > everything aligned, but couldn't there just an extra space > after those two "M"s, as in: > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > |M |M |M|M|M|C|M|M|M|C|M|M|M|M| > |11|10|9|8|7|1|6|5|4|0|3|2|1|0| > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > I at first thought the extra lines signified extra mysterious > bits. I also still don't understand why it doesn't start > with 0 reading from left to right. > > Thanks. > > -Adam > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 16 15:25:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoP7P-0006Rd-KM; Wed, 16 May 2007 15:25:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoP7N-0006IO-Ug for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 15:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoP7N-0006I8-KU for behave@ietf.org; Wed, 16 May 2007 15:25:01 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoP7N-0002Vf-8M for behave@ietf.org; Wed, 16 May 2007 15:25:01 -0400 Received: by py-out-1112.google.com with SMTP id f31so594174pyh for ; Wed, 16 May 2007 12:25:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=H9/Y71iWTtOptpdw6zaNH9lAakTb7zFVg8YYBV90mXj5Ymd7LG3WHEXY7B1lMchUKHS9n8fDvq0S73Nwq6zaU5K1dwJikamdpwXYBOUxHJkQ8qQ7oA9xojfI5rWcZknZGsw4UMDFqcPwzuoKvMC3u5vyPTVG0lS9W0TZ7CH5m7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WocxnYmBkq1XWi25F7PupYYshWdRb7Tu0bxJxxgIuCHC/d4E86rEM2Qba/VCGkPHA/pQJbJGdJSv2g0ICCiiO9v8h6tszOXXT7FpiThbc2P+MNEOu/TymzCmpmsKUSM5s/2tJ4kr3kPo2CSCLd4OvowRpT2VsMF1O8KMq9nxbRE= Received: by 10.35.70.2 with SMTP id x2mr15533216pyk.1179343500836; Wed, 16 May 2007 12:25:00 -0700 (PDT) Received: by 10.35.67.18 with HTTP; Wed, 16 May 2007 12:25:00 -0700 (PDT) Message-ID: Date: Wed, 16 May 2007 15:25:00 -0400 From: "Adam Fisk" To: "Dan Wing" Subject: Re: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt In-Reply-To: <03bc01c797ea$974d5e80$dc6f6b80@amer.cisco.com> MIME-Version: 1.0 References: <03bc01c797ea$974d5e80$dc6f6b80@amer.cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1220961793==" Errors-To: behave-bounces@ietf.org --===============1220961793== Content-Type: multipart/alternative; boundary="----=_Part_13632_24566709.1179343500779" ------=_Part_13632_24566709.1179343500779 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess I'm asking a question as much as suggesting a revision with the bit numbering. Since bit twiddling is right up there with complicated threading as far as making my head hurt quickly, I'll be explicit. In my understanding, a binding request is: 0x0001 and a successful binding response is: 0x0101 Assuming that's right, I guess I just think of numbering of the bits as moving from left to right, much as it does in the previous diagram "Figure 2: Format of a STUN Message Header" right above the one in question. I guess the "11" is to signify that it's the most significant bit? Maybe that's seen as helpful in the subsequent discussion of the class numbering? Please forgive me if I'm just confused. -Adam On 5/16/07, Dan Wing wrote: > > I agree your figure is easier to read. We'll adopt that for the next > revision of rfc3489bis. > > I don't understand, though, why you would want to reverse the bit > numbering? > > -d > > > > -----Original Message----- > > From: Adam Fisk [mailto:adamfisk@gmail.com] > > Sent: Wednesday, May 16, 2007 11:36 AM > > To: behave@ietf.org > > Subject: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt > > > > As others have mentioned, I found the Message Type section to > > be a little opaque. Is the diagram a format that's in common > > use, and I just haven't seen it? Why does it start with M11 > > and opposed to M0, reading from left to right? > > > > I understand the unique location of the class bits is for > > backwards compatibility, but I just found it difficult to > > quickly grok where I should put those darn bits for the field > > as a whole (C1 and C0 weren't the confusing part). The "1" > > and "0" on the second line appear to be there to keep > > everything aligned, but couldn't there just an extra space > > after those two "M"s, as in: > > > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > |M |M |M|M|M|C|M|M|M|C|M|M|M|M| > > |11|10|9|8|7|1|6|5|4|0|3|2|1|0| > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I at first thought the extra lines signified extra mysterious > > bits. I also still don't understand why it doesn't start > > with 0 reading from left to right. > > > > Thanks. > > > > -Adam > > > > > ------=_Part_13632_24566709.1179343500779 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess I'm asking a question as much as suggesting a revision with the bit numbering.  Since bit twiddling is right up there with complicated threading as far as making my head hurt quickly, I'll be explicit.  In my understanding, a binding request is:

0x0001

and a successful binding response is:

0x0101

Assuming that's right, I guess I just think of numbering of the bits as moving from left to right, much as it does in the previous diagram "Figure 2: Format of a STUN Message Header" right above the one in question.  I guess the "11" is to signify that it's the most significant bit?  Maybe that's seen as helpful in the subsequent discussion of the class numbering?

Please forgive me if I'm just confused.

-Adam


On 5/16/07, Dan Wing <dwing@cisco.com> wrote:
I agree your figure is easier to read.  We'll adopt that for the next
revision of rfc3489bis.

I don't understand, though, why you would want to reverse the bit numbering?

-d


> -----Original Message-----
> From: Adam Fisk [mailto:adamfisk@gmail.com ]
> Sent: Wednesday, May 16, 2007 11:36 AM
> To: behave@ietf.org
> Subject: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt
>
> As others have mentioned, I found the Message Type section to
> be a little opaque.  Is the diagram a format that's in common
> use, and I just haven't seen it?  Why does it start with M11
> and opposed to M0, reading from left to right?
>
> I understand the unique location of the class bits is for
> backwards compatibility, but I just found it difficult to
> quickly grok where I should put those darn bits for the field
> as a whole (C1 and C0 weren't the confusing part).  The "1"
> and "0" on the second line appear to be there to keep
> everything aligned, but couldn't there just an extra space
> after those two "M"s, as in:
>
> +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
> |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
> |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
> +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
>
> I at first thought the extra lines signified extra mysterious
> bits.  I also still don't understand why it doesn't start
> with 0 reading from left to right.
>
> Thanks.
>
> -Adam
>
>

------=_Part_13632_24566709.1179343500779-- --===============1220961793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1220961793==-- From behave-bounces@ietf.org Wed May 16 15:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPay-00019D-FZ; Wed, 16 May 2007 15:55:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoPax-000195-TN for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 15:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoPax-00018x-JA for behave@ietf.org; Wed, 16 May 2007 15:55:35 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoPax-0005vZ-49 for behave@ietf.org; Wed, 16 May 2007 15:55:35 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 May 2007 12:55:34 -0700 X-IronPort-AV: i="4.14,544,1170662400"; d="scan'208"; a="150017570:sNHT45913770" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4GJtY4F014659; Wed, 16 May 2007 12:55:34 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4GJtY20023740; Wed, 16 May 2007 19:55:34 GMT From: "Dan Wing" To: "'Adam Fisk'" Subject: RE: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt Date: Wed, 16 May 2007 12:55:33 -0700 Message-ID: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceX7+ZKv5AvD9HDRtu9ZWIwBgYRyAAAy4nw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3317; t=1179345334; x=1180209334; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20message=20type=20in=20draft-ietf-behave-rf c3489bis-06.txt |Sender:=20; bh=DWsD528tDFW/p71HSN51x3r+SbTX6Uf8lSy8VAvBB50=; b=AFAMVwyDWOPgsMh9bBzpyD6snrlDd3+8ImxkQpneIS6vDPG6hKLcg6XKvEh2uw0A+NOul7UT O5SLtrzfn9qsiGGLJtUHq9b3hwL1psNKVG5ka5y93kocON09jOh9Na5p; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Adam Fisk [mailto:adamfisk@gmail.com] > Sent: Wednesday, May 16, 2007 12:25 PM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] message type in > draft-ietf-behave-rfc3489bis-06.txt > > I guess I'm asking a question as much as suggesting a > revision with the bit numbering. Since bit twiddling is > right up there with complicated threading as far as making my > head hurt quickly, I'll be explicit. In my understanding, a > binding request is: > > 0x0001 Yes, C=00, and M=000000000001 > and a successful binding response is: > > 0x0101 Yes, C=1, and M=000000000001. The on-the-wire representation would be 100000001 which is 0x0101 in hex. Google has a hex calculator with more binary digits than my old TI calculator, http://www.google.com/search?q=0b100000001+in+hex > Assuming that's right, I guess I just think of numbering of > the bits as moving from left to right, much as it does in the > previous diagram "Figure 2: Format of a STUN Message Header" > right above the one in question. I guess the "11" is to > signify that it's the most significant bit? Correct. > Maybe that's > seen as helpful in the subsequent discussion of the class numbering? > > Please forgive me if I'm just confused. If you're confused, the text or figure needs improvement or needs an example. This isn't the first time this was brought up. It is unfortunately unavoidable at this point and is a pain. Would C examples, such as from http://www1.ietf.org/mail-archive/web/behave/current/msg01955.html, be helpful? I expect we could put that into an appendix. -d > -Adam > > > > On 5/16/07, Dan Wing wrote: > > I agree your figure is easier to read. We'll adopt > that for the next > revision of rfc3489bis. > > I don't understand, though, why you would want to > reverse the bit numbering? > > -d > > > > -----Original Message----- > > From: Adam Fisk [mailto:adamfisk@gmail.com ] > > Sent: Wednesday, May 16, 2007 11:36 AM > > To: behave@ietf.org > > Subject: [BEHAVE] message type in > draft-ietf-behave-rfc3489bis-06.txt > > > > As others have mentioned, I found the Message Type section to > > be a little opaque. Is the diagram a format that's in common > > use, and I just haven't seen it? Why does it start with M11 > > and opposed to M0, reading from left to right? > > > > I understand the unique location of the class bits is for > > backwards compatibility, but I just found it difficult to > > quickly grok where I should put those darn bits for the field > > as a whole (C1 and C0 weren't the confusing part). The "1" > > and "0" on the second line appear to be there to keep > > everything aligned, but couldn't there just an extra space > > after those two "M"s, as in: > > > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > |M |M |M|M|M|C|M|M|M|C|M|M|M|M| > > |11|10|9|8|7|1|6|5|4|0|3|2|1|0| > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I at first thought the extra lines signified extra mysterious > > bits. I also still don't understand why it doesn't start > > with 0 reading from left to right. > > > > Thanks. > > > > -Adam > > > > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 16 16:38:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQGT-0001wH-3P; Wed, 16 May 2007 16:38:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoQGS-0001wC-9w for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 16:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoQGS-0001w4-02 for behave@ietf.org; Wed, 16 May 2007 16:38:28 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoQGR-0004PT-KT for behave@ietf.org; Wed, 16 May 2007 16:38:27 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 16 May 2007 13:38:27 -0700 Received: from NA-EXMSG-C109.redmond.corp.microsoft.com ([157.54.62.155]) by tk1-exhub-c101.redmond.corp.microsoft.com ([157.56.116.111]) with mapi; Wed, 16 May 2007 13:38:26 -0700 From: Parakram Khandpur To: "behave@ietf.org" Date: Wed, 16 May 2007 13:38:23 -0700 Thread-Topic: Looking for data on NAT deployments in home scenarios Thread-Index: AceX7+ZKv5AvD9HDRtu9ZWIwBgYRyAAAy4nwAAGZvmA= Message-ID: References: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> In-Reply-To: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [BEHAVE] Looking for data on NAT deployments in home scenarios X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi I am looking to get some data on NAT deployments in home scenarios. Specifi= cally, I'm trying to find out the %age numbers (or even a qualitative measu= re) for the scenario where there are multiple network subnets or multilevel= NAT'ing within the same home. One possible way of having multiple subnets/= multilevel NAT'ing would be if a user buys a wireless router and plugs its = WAN port into the one of the LAN ports of an existing wired router. Thanks -Parakram -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Wednesday, May 16, 2007 12:56 PM To: 'Adam Fisk' Cc: behave@ietf.org Subject: RE: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt > -----Original Message----- > From: Adam Fisk [mailto:adamfisk@gmail.com] > Sent: Wednesday, May 16, 2007 12:25 PM > To: Dan Wing > Cc: behave@ietf.org > Subject: Re: [BEHAVE] message type in > draft-ietf-behave-rfc3489bis-06.txt > > I guess I'm asking a question as much as suggesting a > revision with the bit numbering. Since bit twiddling is > right up there with complicated threading as far as making my > head hurt quickly, I'll be explicit. In my understanding, a > binding request is: > > 0x0001 Yes, C=3D00, and M=3D000000000001 > and a successful binding response is: > > 0x0101 Yes, C=3D1, and M=3D000000000001. The on-the-wire representation would be 100000001 which is 0x0101 in hex. Google has a hex calculator with more binary digits than my old TI calculator, http://www.google.com/search?q=3D0b100000001+in+hex > Assuming that's right, I guess I just think of numbering of > the bits as moving from left to right, much as it does in the > previous diagram "Figure 2: Format of a STUN Message Header" > right above the one in question. I guess the "11" is to > signify that it's the most significant bit? Correct. > Maybe that's > seen as helpful in the subsequent discussion of the class numbering? > > Please forgive me if I'm just confused. If you're confused, the text or figure needs improvement or needs an example. This isn't the first time this was brought up. It is unfortunately unavoidable at this point and is a pain. Would C examples, such as from http://www1.ietf.org/mail-archive/web/behave/current/msg01955.html, be helpful? I expect we could put that into an appendix. -d > -Adam > > > > On 5/16/07, Dan Wing wrote: > > I agree your figure is easier to read. We'll adopt > that for the next > revision of rfc3489bis. > > I don't understand, though, why you would want to > reverse the bit numbering? > > -d > > > > -----Original Message----- > > From: Adam Fisk [mailto:adamfisk@gmail.com ] > > Sent: Wednesday, May 16, 2007 11:36 AM > > To: behave@ietf.org > > Subject: [BEHAVE] message type in > draft-ietf-behave-rfc3489bis-06.txt > > > > As others have mentioned, I found the Message Type section to > > be a little opaque. Is the diagram a format that's in common > > use, and I just haven't seen it? Why does it start with M11 > > and opposed to M0, reading from left to right? > > > > I understand the unique location of the class bits is for > > backwards compatibility, but I just found it difficult to > > quickly grok where I should put those darn bits for the field > > as a whole (C1 and C0 weren't the confusing part). The "1" > > and "0" on the second line appear to be there to keep > > everything aligned, but couldn't there just an extra space > > after those two "M"s, as in: > > > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > |M |M |M|M|M|C|M|M|M|C|M|M|M|M| > > |11|10|9|8|7|1|6|5|4|0|3|2|1|0| > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I at first thought the extra lines signified extra mysterious > > bits. I also still don't understand why it doesn't start > > with 0 reading from left to right. > > > > Thanks. > > > > -Adam > > > > > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 16 18:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRxG-0002B4-9f; Wed, 16 May 2007 18:26:46 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoRxF-0002Au-Dd for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 18:26:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoRxF-0002Am-3s for behave@ietf.org; Wed, 16 May 2007 18:26:45 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoRxE-0002JW-IE for behave@ietf.org; Wed, 16 May 2007 18:26:45 -0400 Received: by py-out-1112.google.com with SMTP id f31so646561pyh for ; Wed, 16 May 2007 15:26:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=n2roWDTrcwC45ttlIGeUqgZ3OWnyZu6B8az7BCmnFKR79sIkxpRM11+X/HZx1/qSptWxmjc1U9WxsPrCvcp+Ps+0P+g4zgoLbkFvPLV/nkM5lro5WqyZJwQAocTC9qngp0ZT+UoBPe4hvmp59zjdn2ujqbYEfZWuSwztyoFjEwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lBTagpLDahHdNWlxqGTm5slPhbQUrRYb6qIhNfK4V6VSpWkFcp3L3Iuu/HLPk/BnmNF+3Xxfm+hhwLfOCX0CqS1w3li0TpcBvvZSvm3RGcLZUN+omdKSbIRZ4ZW7QHNsFo/TZvcf3F0as1BYUXRJX3hLlU63MAuAuzk8wmX1gfA= Received: by 10.35.57.5 with SMTP id j5mr15805137pyk.1179354403999; Wed, 16 May 2007 15:26:43 -0700 (PDT) Received: by 10.35.67.18 with HTTP; Wed, 16 May 2007 15:26:43 -0700 (PDT) Message-ID: Date: Wed, 16 May 2007 18:26:43 -0400 From: "Adam Fisk" To: "Dan Wing" Subject: Re: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt In-Reply-To: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> MIME-Version: 1.0 References: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0185438022==" Errors-To: behave-bounces@ietf.org --===============0185438022== Content-Type: multipart/alternative; boundary="----=_Part_15457_18595892.1179354403910" ------=_Part_15457_18595892.1179354403910 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think just one example would do wonders, Dan, yeah. The earlier thread you referenced was useful in verifying I was reading the diagram correctly, but it seems like overkill for the draft itself. Just having the example of a successful binding response as 0x0101 would have been sufficient to move me along a little faster, or any example along those lines. Thanks very much. -Adam On 5/16/07, Dan Wing wrote: > > > > > -----Original Message----- > > From: Adam Fisk [mailto:adamfisk@gmail.com] > > Sent: Wednesday, May 16, 2007 12:25 PM > > To: Dan Wing > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] message type in > > draft-ietf-behave-rfc3489bis-06.txt > > > > I guess I'm asking a question as much as suggesting a > > revision with the bit numbering. Since bit twiddling is > > right up there with complicated threading as far as making my > > head hurt quickly, I'll be explicit. In my understanding, a > > binding request is: > > > > 0x0001 > > Yes, C=00, and M=000000000001 > > > and a successful binding response is: > > > > 0x0101 > > Yes, C=1, and M=000000000001. The on-the-wire representation would be > 100000001 which is 0x0101 in hex. Google has a hex calculator with more > binary digits than my old TI calculator, > http://www.google.com/search?q=0b100000001+in+hex > > > Assuming that's right, I guess I just think of numbering of > > the bits as moving from left to right, much as it does in the > > previous diagram "Figure 2: Format of a STUN Message Header" > > right above the one in question. I guess the "11" is to > > signify that it's the most significant bit? > > Correct. > > > Maybe that's > > seen as helpful in the subsequent discussion of the class numbering? > > > > Please forgive me if I'm just confused. > > If you're confused, the text or figure needs improvement or needs an > example. This isn't the first time this was brought up. It is > unfortunately unavoidable at this point and is a pain. > > Would C examples, such as from > http://www1.ietf.org/mail-archive/web/behave/current/msg01955.html, be > helpful? I expect we could put that into an appendix. > > -d > > > > -Adam > > > > > > > > On 5/16/07, Dan Wing wrote: > > > > I agree your figure is easier to read. We'll adopt > > that for the next > > revision of rfc3489bis. > > > > I don't understand, though, why you would want to > > reverse the bit numbering? > > > > -d > > > > > > > -----Original Message----- > > > From: Adam Fisk [mailto:adamfisk@gmail.com ] > > > Sent: Wednesday, May 16, 2007 11:36 AM > > > To: behave@ietf.org > > > Subject: [BEHAVE] message type in > > draft-ietf-behave-rfc3489bis-06.txt > > > > > > As others have mentioned, I found the Message Type section to > > > be a little opaque. Is the diagram a format that's in common > > > use, and I just haven't seen it? Why does it start with M11 > > > and opposed to M0, reading from left to right? > > > > > > I understand the unique location of the class bits is for > > > backwards compatibility, but I just found it difficult to > > > quickly grok where I should put those darn bits for the field > > > as a whole (C1 and C0 weren't the confusing part). The "1" > > > and "0" on the second line appear to be there to keep > > > everything aligned, but couldn't there just an extra space > > > after those two "M"s, as in: > > > > > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |M |M |M|M|M|C|M|M|M|C|M|M|M|M| > > > |11|10|9|8|7|1|6|5|4|0|3|2|1|0| > > > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > I at first thought the extra lines signified extra mysterious > > > bits. I also still don't understand why it doesn't start > > > with 0 reading from left to right. > > > > > > Thanks. > > > > > > -Adam > > > > > > > > > > > > > > > ------=_Part_15457_18595892.1179354403910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think just one example would do wonders, Dan, yeah.  The earlier thread you referenced was useful in verifying I was reading the diagram correctly, but it seems like overkill for the draft itself. 

Just having the example of a successful binding response as 0x0101 would have been sufficient to move me along a little faster, or any example along those lines.

Thanks very much.

-Adam


On 5/16/07, Dan Wing <dwing@cisco.com> wrote:


> -----Original Message-----
> From: Adam Fisk [mailto:adamfisk@gmail.com]
> Sent: Wednesday, May 16, 2007 12:25 PM
> To: Dan Wing
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] message type in
> draft-ietf-behave-rfc3489bis-06.txt
>
> I guess I'm asking a question as much as suggesting a
> revision with the bit numbering.  Since bit twiddling is
> right up there with complicated threading as far as making my
> head hurt quickly, I'll be explicit.  In my understanding, a
> binding request is:
>
> 0x0001

Yes, C=00, and M=000000000001

> and a successful binding response is:
>
> 0x0101

Yes, C=1, and M=000000000001.  The on-the-wire representation would be
100000001 which is 0x0101 in hex.  Google has a hex calculator with more
binary digits than my old TI calculator,
http://www.google.com/search?q=0b100000001+in+hex

> Assuming that's right, I guess I just think of numbering of
> the bits as moving from left to right, much as it does in the
> previous diagram "Figure 2: Format of a STUN Message Header"
> right above the one in question.  I guess the "11" is to
> signify that it's the most significant bit?

Correct.

> Maybe that's
> seen as helpful in the subsequent discussion of the class numbering?
>
> Please forgive me if I'm just confused.

If you're confused, the text or figure needs improvement or needs an
example.  This isn't the first time this was brought up.  It is
unfortunately unavoidable at this point and is a pain.

Would C examples, such as from
http://www1.ietf.org/mail-archive/web/behave/current/msg01955.html, be
helpful?  I expect we could put that into an appendix.

-d


> -Adam
>
>
>
> On 5/16/07, Dan Wing <dwing@cisco.com> wrote:
>
>       I agree your figure is easier to read.  We'll adopt
> that for the next
>       revision of rfc3489bis.
>
>       I don't understand, though, why you would want to
> reverse the bit numbering?
>
>       -d
>
>
>       > -----Original Message-----
>       > From: Adam Fisk [mailto:adamfisk@gmail.com ]
>       > Sent: Wednesday, May 16, 2007 11:36 AM
>       > To: behave@ietf.org
>       > Subject: [BEHAVE] message type in
> draft-ietf-behave-rfc3489bis-06.txt
>       >
>       > As others have mentioned, I found the Message Type section to
>       > be a little opaque.  Is the diagram a format that's in common
>       > use, and I just haven't seen it?  Why does it start with M11
>       > and opposed to M0, reading from left to right?
>       >
>       > I understand the unique location of the class bits is for
>       > backwards compatibility, but I just found it difficult to
>       > quickly grok where I should put those darn bits for the field
>       > as a whole (C1 and C0 weren't the confusing part).  The "1"
>       > and "0" on the second line appear to be there to keep
>       > everything aligned, but couldn't there just an extra space
>       > after those two "M"s, as in:
>       >
>       > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
>       > |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
>       > |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
>       > +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
>       >
>       > I at first thought the extra lines signified extra mysterious
>       > bits.  I also still don't understand why it doesn't start
>       > with 0 reading from left to right.
>       >
>       > Thanks.
>       >
>       > -Adam
>       >
>       >
>
>
>
>

------=_Part_15457_18595892.1179354403910-- --===============0185438022== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0185438022==-- From behave-bounces@ietf.org Thu May 17 10:26:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hogvw-0000nm-46; Thu, 17 May 2007 10:26:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HoDgX-0000qj-7P for behave-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 03:12:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoDgW-0000qb-Kt for behave@ietf.org; Wed, 16 May 2007 03:12:32 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoDgU-0001Ol-W6 for behave@ietf.org; Wed, 16 May 2007 03:12:32 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 76F5820887; Wed, 16 May 2007 09:12:30 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-16-464aaede36ce Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5CCA220886; Wed, 16 May 2007 09:12:30 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 09:12:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Wed, 16 May 2007 09:11:36 +0200 Message-ID: In-Reply-To: <200705160859.15124.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Thread-Index: AceXfzF7k82gai5pQGaMWW4wlSvKDQACUzCg References: <200705091621.16443.remi.denis-courmont@nokia.com> <200705160859.15124.remi.denis-courmont@nokia.com> From: "Oscar Novo \(JO/LMF\)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= X-OriginalArrivalTime: 16 May 2007 07:12:30.0270 (UTC) FILETIME=[910535E0:01C79789] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Thu, 17 May 2007 10:26:23 -0400 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thanks for your feedback. My previous comments referred to STUN Relay = Usage/TURN, not to 3489bis but you're right TURN-IPv6 should be = consistent with 3489bis as well. I'll work in a new version of the draft = and I will send it to the list in brief. Oscar=20 -----Original Message----- From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 Sent: 16. toukokuuta 2007 8:59 To: Oscar Novo (JO/LMF) Cc: behave@ietf.org; Gonzalo Camarillo (JO/LMF) Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt On Tuesday 15 May 2007 17:17:05 ext Oscar Novo (JO/LMF) wrote: > 1/ Format for the family parameter within the attribute is not=20 > consistent with that used in STUN (XOR-)MAPPED-ADDRESS et al, where it = > consists of a single byte. Is there any reason for this? > > [ON] We can change the family parameter to a single byte to be=20 > consistent with the MAPPED-ADDRESS. > > 2/ In my humble opinion, the address family numbers should simply=20 > refer to the base STUN spec instead of redefining the same values...=20 > so we do not need to duplicate effort if we ever were to define new = families (HIP?). > > [ON] STUN spec does not define any number for IPv6. It only defines=20 > the number for IPv4. >From draft-ietf-behave-rfc3489bis-06 =A711.1: The address family can take on the following values: 0x01:IPv4 0x02:IPv6 I assume TURN-IPv6 depends on rfc3489bis due to depending on STUN Relay = Usage/TURN. > 3/ I might have missed it, but what is the request address type is = absent? > Should the default be "always IPv4", or "protocol through which the=20 > server received the Allocate Request" ? I would assume "always IPv4"=20 > is better, consistent with RFC3489bis insistance that there might be=20 > IPv4-to-IPv6 or > IPv6-to-IPv4 translation middleboxes. > > [ON] This draft defines a new attribute for STUN. If that attribute is = > absented you should follow the STUN spec and assume always IPv4. The same RFC3489bis section says: It is possible for an IPv4 host to receive a MAPPED-ADDRESS containing an IPv6 address, or for an IPv6 host to receive a MAPPED- ADDRESS containing an IPv4 address. Clients MUST be prepared for this case. So this does not seem all that obvious to me. I however agree that it = should be IPv4 by default EVEN IF the Allocate Request came through = IPv6, to avoid problems with any kind of IPv4-to-IPv6 translation on the = path. -- R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 17 10:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hogvv-0000nh-V2; Thu, 17 May 2007 10:26:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hnxqj-0007KC-NO for behave-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 10:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnxqj-0007K4-Da for behave@ietf.org; Tue, 15 May 2007 10:18:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnxqh-0000tY-Qf for behave@ietf.org; Tue, 15 May 2007 10:18:01 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 407E0205B5; Tue, 15 May 2007 16:17:59 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-1f-4649c117c962 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2B0F7204C0; Tue, 15 May 2007 16:17:59 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 16:17:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Tue, 15 May 2007 16:17:05 +0200 Message-ID: In-Reply-To: <200705091621.16443.remi.denis-courmont@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Thread-Index: AceSPNHzDWg9qJ9nRb2wwDpw8arkLQEvrS6g References: <200705091621.16443.remi.denis-courmont@nokia.com> From: "Oscar Novo \(JO/LMF\)" To: =?iso-8859-1?Q?R=E9mi_Denis-Courmont?= , , "Gonzalo Camarillo \(JO/LMF\)" X-OriginalArrivalTime: 15 May 2007 14:17:59.0079 (UTC) FILETIME=[D6F69370:01C796FB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Thu, 17 May 2007 10:26:23 -0400 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello R=E9mi, Thanks for your comments, some more comments inline=20 Cheers, Oscar -----Original Message----- From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 Sent: 9. toukokuuta 2007 16:21 To: behave@ietf.org; Gonzalo Camarillo (JO/LMF); Oscar Novo (JO/LMF) Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Hello, On Tuesday 08 May 2007 01:50:02 ext behave-bounces@ietf.org wrote: > This document defines the REQUESTED-ADDRESS-TYPE attribute for the > Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a > client to explicitly request the address type the STUN relay server > will allocate (e.g., an IPv4-only node may request the STUN relay > server to allocate an IPv6 address). Additionally, this document > also defines a new error response code with the value 440 (Address > Family not Supported). A few notes: 1/ Format for the family parameter within the attribute is not = consistent with that used in STUN (XOR-)MAPPED-ADDRESS et al, where it = consists of a single byte. Is there any reason for this? [ON] We can change the family parameter to a single byte to be = consistent with the MAPPED-ADDRESS. 2/ In my humble opinion, the address family numbers should simply refer = to the base STUN spec instead of redefining the same values... so we do = not need to duplicate effort if we ever were to define new families = (HIP?). [ON] STUN spec does not define any number for IPv6. It only defines the = number for IPv4. 3/ I might have missed it, but what is the request address type is = absent?=20 Should the default be "always IPv4", or "protocol through which the = server received the Allocate Request" ? I would assume "always IPv4" is = better, consistent with RFC3489bis insistance that there might be = IPv4-to-IPv6 or IPv6-to-IPv4 translation middleboxes. [ON] This draft defines a new attribute for STUN. If that attribute is = absented you should follow the STUN spec and assume always IPv4. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 17 15:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holzk-00017F-E3; Thu, 17 May 2007 15:50:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Holzd-0000pR-BM for behave-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Holzc-0000pB-Vi; Thu, 17 May 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Holzc-00021Z-Lo; Thu, 17 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 4991C17657; Thu, 17 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Holz8-0005e5-1E; Thu, 17 May 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 17 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Multicast Requirements for a Network Address Port Translator (NAPT) Author(s) : D. Wing Filename : draft-ietf-behave-multicast-06.txt Pages : 10 Date : 2007-5-17 This document specifies requirements for a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports any-source multicast or single-source multicast. A multicast-capable NAPT device that adheres to the requirements of this document can optimize the operation of multicast applications that are generally unaware of multicast NAPT devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-17143733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-17143733.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Thu May 17 17:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonoZ-0005bA-Jf; Thu, 17 May 2007 17:47:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HonoY-0005Wc-9N for behave-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 17:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HonoX-0005W0-V1 for behave@ietf.org; Thu, 17 May 2007 17:47:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HonoW-0006GO-LW for behave@ietf.org; Thu, 17 May 2007 17:47:13 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 17 May 2007 14:47:12 -0700 X-IronPort-AV: i="4.14,550,1170662400"; d="scan'208"; a="154757853:sNHT38338146" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4HLlC0f001994 for ; Thu, 17 May 2007 14:47:12 -0700 Received: from dwingwxp ([10.32.240.197]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4HLlBV1027425 for ; Thu, 17 May 2007 21:47:11 GMT From: "Dan Wing" To: Date: Thu, 17 May 2007 14:47:10 -0700 Message-ID: <024301c798cc$eca64b20$c5f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbg== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=812; t=1179438432; x=1180302432; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=3A=20draft-ietf-behave-multicast-06.txt |Sender:=20; bh=Dbq3bVr8p/l/OeIOQ+Nmtw615z/6CEsc/rX53mfbLLg=; b=bDVi3GypvPa5u11ySJ2VScGlhnDlMfK3AHmc1TCYa+GZAUhABfm/QnfY36WyZKajRZeTJxQc Dhwy7Z9kHJEO4r79+kZA3jPEWov+8fcQrKHHRdZR985XhDe1W8ptj8XM; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [BEHAVE] WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The working group last call is starting now for "Multicast Requirements for a Network Address Port Translator (NAPT)", http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: This document specifies requirements for a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports any-source multicast or single-source multicast. A multicast-capable NAPT device that adheres to the requirements of this document can optimize the operation of multicast applications that are generally unaware of multicast NAPT devices. This WGLC will finish on Thursday, May 31 (two weeks from today). If this WGLC is successful, I will ask for review by the MAGMA working group and mboned@lists.uoregon.edu prior to submitting to IESG. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 18 12:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5m1-0001es-NN; Fri, 18 May 2007 12:57:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hp5lz-0001ek-QU for behave-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 12:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5lz-0001ec-Gi for behave@ietf.org; Fri, 18 May 2007 12:57:47 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp5lv-0000r5-6R for behave@ietf.org; Fri, 18 May 2007 12:57:47 -0400 Received: from [61.94.220.188] (unknown [61.94.220.188]) by smtp.mxes.net (Postfix) with ESMTP id 4DB385197C; Fri, 18 May 2007 12:57:39 -0400 (EDT) Message-ID: <464DDAFC.8040406@pjsip.org> Date: Fri, 18 May 2007 17:57:32 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Adam Fisk Subject: Re: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt References: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think this topic has been going over and over again on this list, so putting a C snippet to confirm the bits interpretation in appendix would clarify this once and for all, so I support that. I don't think it's overkill, RTP also has C snippet and it's been very useful for implementors. Just my 0.02p. -benny Adam Fisk wrote: > I think just one example would do wonders, Dan, yeah. The earlier > thread you referenced was useful in verifying I was reading the diagram > correctly, but it seems like overkill for the draft itself. > > Just having the example of a successful binding response as 0x0101 would > have been sufficient to move me along a little faster, or any example > along those lines. > > Thanks very much. > > -Adam > > > On 5/16/07, *Dan Wing* > wrote: > > > > > -----Original Message----- > > From: Adam Fisk [mailto:adamfisk@gmail.com > ] > > Sent: Wednesday, May 16, 2007 12:25 PM > > To: Dan Wing > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] message type in > > draft-ietf-behave-rfc3489bis-06.txt > > > > I guess I'm asking a question as much as suggesting a > > revision with the bit numbering. Since bit twiddling is > > right up there with complicated threading as far as making my > > head hurt quickly, I'll be explicit. In my understanding, a > > binding request is: > > > > 0x0001 > > Yes, C=00, and M=000000000001 > > > and a successful binding response is: > > > > 0x0101 > > Yes, C=1, and M=000000000001. The on-the-wire representation would be > 100000001 which is 0x0101 in hex. Google has a hex calculator with > more > binary digits than my old TI calculator, > http://www.google.com/search?q=0b100000001+in+hex > > > Assuming that's right, I guess I just think of numbering of > > the bits as moving from left to right, much as it does in the > > previous diagram "Figure 2: Format of a STUN Message Header" > > right above the one in question. I guess the "11" is to > > signify that it's the most significant bit? > > Correct. > > > Maybe that's > > seen as helpful in the subsequent discussion of the class numbering? > > > > Please forgive me if I'm just confused. > > If you're confused, the text or figure needs improvement or needs an > example. This isn't the first time this was brought up. It is > unfortunately unavoidable at this point and is a pain. > > Would C examples, such as from > http://www1.ietf.org/mail-archive/web/behave/current/msg01955.html, be > helpful? I expect we could put that into an appendix. > > -d -- Benny Prijono http://www.pjsip.org _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon May 21 07:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq5r3-0006xf-EN; Mon, 21 May 2007 07:15:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hq5r0-0006uy-TV for behave-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 07:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq5qz-0006sx-VG for behave@ietf.org; Mon, 21 May 2007 07:15:05 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq5qy-0002wJ-LR for behave@ietf.org; Mon, 21 May 2007 07:15:05 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49806) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Hq5qx-000145-Uf; Mon, 21 May 2007 12:15:03 +0100 In-Reply-To: <464DDAFC.8040406@pjsip.org> References: <03dc01c797f4$2a720b80$dc6f6b80@amer.cisco.com> <464DDAFC.8040406@pjsip.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CD3C211-A3DC-4AC4-902E-016BA77E62C8@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [BEHAVE] message type in draft-ietf-behave-rfc3489bis-06.txt Date: Mon, 21 May 2007 12:14:58 +0100 To: Benny Prijono X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 18 May 2007, at 17:57, Benny Prijono wrote: > I think this topic has been going over and over again on this list, > so putting a C snippet to confirm the bits interpretation in > appendix would clarify this once and for all, so I support that. I > don't think it's overkill, RTP also has C snippet and it's been > very useful for implementors. Sure, but be careful about portability - the code in RFC 3550 confuses many since it assumes a big-endian system, which is less than common these days. -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue May 22 05:39:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqQpd-0004Rk-UE; Tue, 22 May 2007 05:39:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HqQpc-0004Rc-Pr for behave-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 05:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqQpc-0004RU-G6 for behave@ietf.org; Tue, 22 May 2007 05:39:04 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqQpa-00038E-KO for behave@ietf.org; Tue, 22 May 2007 05:39:04 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E872F20FBF; Tue, 22 May 2007 11:39:01 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-34-4652ba35f5c3 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CAE9D21381; Tue, 22 May 2007 11:39:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 11:39:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 11:39:01 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 59FB72467; Tue, 22 May 2007 12:39:01 +0300 (EEST) Message-ID: <4652BA35.4030809@ericsson.com> Date: Tue, 22 May 2007 12:39:01 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705111045.58341.remi.denis-courmont@nokia.com> In-Reply-To: <200705111045.58341.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 May 2007 09:39:01.0455 (UTC) FILETIME=[077415F0:01C79C55] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Oscar.Novo@ericsson.com, behave@ietf.org, Karim El Malki , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, > No, of course not. Labels depend on the local system configuration anyway, > that was only a hint that, in view of RFC3484, it would be better to not only > give a native IPv6 address, but also (if one is available), say a 6to4 > address, an ULA, and so on... what are you thinking of regarding 6to4 addresses? Do you have a particular scenario in mind? Regarding ULA addresses, they could be used between the relay and the remote endpoint if the relay and the remote endpoint happen to be in the same site, but... is it worthwhile adding the complexity needed to address this type of scenario taking into account that it works fine with the current solution? If we decided to add support for relays to provide multiple IPv6 addresses, ICE (i.e., STUN) checks would discover which ones work and which ones don't. Cheers, Gonzalo _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue May 22 06:00:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqRAa-0000dG-4q; Tue, 22 May 2007 06:00:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HqRAZ-0000dB-5A for behave-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 06:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqRAY-0000cy-RS for behave@ietf.org; Tue, 22 May 2007 06:00:42 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqRAX-0000Q8-C4 for behave@ietf.org; Tue, 22 May 2007 06:00:42 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4MA0JM4012268; Tue, 22 May 2007 13:00:22 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 13:00:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 13:00:17 +0300 Received: from esdhcp04177.research.nokia.com ([172.21.41.77]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 13:00:17 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Tue, 22 May 2007 13:00:34 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705111045.58341.remi.denis-courmont@nokia.com> <4652BA35.4030809@ericsson.com> In-Reply-To: <4652BA35.4030809@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705221300.34346.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 22 May 2007 10:00:17.0287 (UTC) FILETIME=[FFE89970:01C79C57] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: behave@ietf.org, Karim El Malki , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 22 May 2007 12:39:01 you wrote: > Hi, > > > No, of course not. Labels depend on the local system configuration > > anyway, that was only a hint that, in view of RFC3484, it would be bett= er > > to not only give a native IPv6 address, but also (if one is available), > > say a 6to4 address, an ULA, and so on... > > what are you thinking of regarding 6to4 addresses? Do you have a > particular scenario in mind? If the peer has 6to4 connectivity but no native IPv6, this would avoid usin= g=20 both a TURN *and* a separate 6to4 relay; same note applies to Teredo. In 6to4 case, it would also ensure symmetric path of the IPv6-over-IPv4=20 segment, as 6to4<->native often involves different 6to4 relays in each=20 directions, while 6to4<->6to4 is always symmetric. It is questionable whether this will be useful in practice (will any TURN=20 relay have a 6to4 address anyway?). One case that seems more obviously interesting to me is providing both an I= Pv4=20 and an IPv6 address in the Allocate Response, which allows for efficient us= e=20 of TURN with ICE in the usage scenario formerly addressed by ANAT (Note: IP= v4=20 is defined as its own label in RFC3484; though this would be a simpler and= =20 less generic). Without this I expect TURN clients would need to perform two= =20 TURN Allocate Request, and TURN server will get double the state and reques= t=20 processing work. > Regarding ULA addresses, they could be used between the relay and the > remote endpoint if the relay and the remote endpoint happen to be in the > same site, but... is it worthwhile adding the complexity needed to > address this type of scenario taking into account that it works fine > with the current solution? > If we decided to add support for relays to provide multiple IPv6 > addresses, ICE (i.e., STUN) checks would discover which ones work and > which ones don't. Yes, that's the point. I was referring to labels as an example because I do= ubt=20 it would be useful to clutter the Allocate Response with different addresse= s=20 with similar routing/topology properties. Of course, IPv6 addresses from=20 different native prefixes could be provided if deemed potentially useful. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 01:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqj0C-00071V-9U; Wed, 23 May 2007 01:03:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hqj0A-00071F-JF for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 01:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqj0A-000717-7V for behave@ietf.org; Wed, 23 May 2007 01:03:10 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqj05-0006o5-Vn for behave@ietf.org; Wed, 23 May 2007 01:03:10 -0400 Received: from [61.94.220.103] (unknown [61.94.220.103]) by smtp.mxes.net (Postfix) with ESMTP id C7A2E51999 for ; Wed, 23 May 2007 01:03:03 -0400 (EDT) Message-ID: <4653CAFC.1070000@pjsip.org> Date: Wed, 23 May 2007 06:02:52 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org All, Apologies if this has been discussed, but I have some doubts regarding the processing of STUN error responses which requests had included MESSAGE-INTEGRITY attribute. Few doubts: - In 8.3.2. Processing Responses, it says "All responses that were not discarded, whether success responses or error responses, MUST first be authenticated by the client." I'm assuming that this means STUN response (success or error) with missing or incorrect M-I will be discarded before it reaches client transaction FSM. And if so, I'm assuming that client would continue retransmitting the request, as if it had not receive any response. - If the above are true, then I think there need to be some exception for some error responses which by definition cannot contain M-I, so they cannot be authenticated. Reading Section 9.1.1. "Receive Request Message", I reckon these error responses cannot contain M-I thus client should not authenticate them: 401 (Unauthorized) 432 (Missing Username) 434 (Missing Realm) 436 (Unknown Username) 431 (Integrity Check Failure) And probably 420 (Unknown Attribute), and few others (I can look for them, but for now I just want to be sure that what I'm saying makes sense at all). Comments? cheers, -benny -- Benny Prijono http://www.pjsip.org _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 03:21:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hql9b-00081T-L1; Wed, 23 May 2007 03:21:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hql9a-00081O-02 for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 03:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hql9Z-00081G-Ib for behave@ietf.org; Wed, 23 May 2007 03:21:01 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hql9X-0000Bz-Ni for behave@ietf.org; Wed, 23 May 2007 03:21:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4N7KgjP029626 for ; Wed, 23 May 2007 10:20:57 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:20:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:20:56 +0300 Received: from esdhcp04062.research.nokia.com ([172.21.40.62]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:20:56 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses Date: Wed, 23 May 2007 10:21:15 +0300 User-Agent: KMail/1.9.6 References: <4653CAFC.1070000@pjsip.org> In-Reply-To: <4653CAFC.1070000@pjsip.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200705231021.15239.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 23 May 2007 07:20:56.0926 (UTC) FILETIME=[E7E707E0:01C79D0A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Wednesday 23 May 2007 08:02:52 ext Benny Prijono wrote: > Reading Section 9.1.1. "Receive Request Message", I reckon these > error responses cannot contain M-I thus client should not > authenticate them: > > 401 (Unauthorized) The client will only receive a legitimate 401 if it did not authenticate in= =20 the first place, so it will not expect a M-I in the response either. > 432 (Missing Username) A conforming client will never emit authenticated messages without a USERNA= ME,=20 so... > 434 (Missing Realm) > 436 (Unknown Username) > 431 (Integrity Check Failure) These are the real issues. In practice, either you drop the errors, or you= =20 rely on the transaction ID. While the latter is vulnerable to a MITM attack= ,=20 that's a not really a concern since an active MITM can pretty much always D= oS=20 the service anyway. However, this relies on really non-predictable=20 transaction IDs. > And probably 420 (Unknown Attribute), and few others (I can look > for them, but for now I just want to be sure that what I'm > saying makes sense at all). There should normally be no problem authenticating a 420, unless a new=20 attribute that does influence M-I in a non-backward compatible manner is=20 defined. I surely hope we will not do that, and in any case, it should not = be=20 an issue for clients implementing the current drafts. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 05:15:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmwN-0004cM-Aj; Wed, 23 May 2007 05:15:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HqmwL-0004cH-N5 for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 05:15:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmwK-0004c9-T0 for behave@ietf.org; Wed, 23 May 2007 05:15:28 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqmwG-0000em-KG for behave@ietf.org; Wed, 23 May 2007 05:15:28 -0400 Received: from [61.94.220.240] (unknown [61.94.220.240]) by smtp.mxes.net (Postfix) with ESMTP id 060CA5193B for ; Wed, 23 May 2007 05:15:22 -0400 (EDT) Message-ID: <465405E2.10305@pjsip.org> Date: Wed, 23 May 2007 10:14:10 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses References: <4653CAFC.1070000@pjsip.org> <200705231021.15239.remi.denis-courmont@nokia.com> In-Reply-To: <200705231021.15239.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org R=E9mi Denis-Courmont wrote: > On Wednesday 23 May 2007 08:02:52 ext Benny Prijono wrote: >> Reading Section 9.1.1. "Receive Request Message", I reckon these >> error responses cannot contain M-I thus client should not >> authenticate them: >> >> 401 (Unauthorized) >=20 > The client will only receive a legitimate 401 if it did not authenticat= e in=20 > the first place, so it will not expect a M-I in the response either. You're right. >> 432 (Missing Username) >=20 > A conforming client will never emit authenticated messages without a US= ERNAME,=20 > so... But the error code is there anyway, so... >> 434 (Missing Realm) >> 436 (Unknown Username) >> 431 (Integrity Check Failure) >=20 > These are the real issues. In practice, either you drop the errors, or = you=20 > rely on the transaction ID. While the latter is vulnerable to a MITM at= tack,=20 > that's a not really a concern since an active MITM can pretty much alwa= ys DoS=20 > the service anyway. However, this relies on really non-predictable=20 > transaction IDs. I'm in favor of accepting these error responses even if they don't=20 have M-I. If we drop these error responses when they don't have M-I=20 (and they can't have M-I), this kind of defeat the purpose of the=20 error codes, since they can never reach transaction FSM. >> And probably 420 (Unknown Attribute), and few others (I can look >> for them, but for now I just want to be sure that what I'm >> saying makes sense at all). >=20 > There should normally be no problem authenticating a 420, unless a new=20 > attribute that does influence M-I in a non-backward compatible manner i= s=20 > defined. I surely hope we will not do that, and in any case, it should = not be=20 > an issue for clients implementing the current drafts. I don't mind with authenticating 420. What about 400 (Bad Request)? This error can be generated in the=20 parser because of malformed request, so the server may not be able=20 to generate M-I. cheers, -benny --=20 Benny Prijono http://www.pjsip.org _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 10:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqsJV-0008Gm-8Q; Wed, 23 May 2007 10:59:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HqsJT-0008Gd-P5 for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 10:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqsJT-0008GV-FM for behave@ietf.org; Wed, 23 May 2007 10:59:43 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqsJS-0002TL-74 for behave@ietf.org; Wed, 23 May 2007 10:59:43 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 07:59:41 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="156604422:sNHT40009266" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4NExfvu010727 for ; Wed, 23 May 2007 07:59:41 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4NExe06018148 for ; Wed, 23 May 2007 14:59:41 GMT From: "Dan Wing" To: Date: Wed, 23 May 2007 07:59:40 -0700 Message-ID: <0a2101c79d4a$fda24780$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcedSv0bvxLLWRlxReuwV/GVwVL9/Q== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=689; t=1179932381; x=1180796381; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20REALM's=20quotes |Sender:=20; bh=LVB7AysB0SS8VhoieSThWkTDTUA0wetH+uHPUaiPH7g=; b=dwyonNEdt1qgyNAZKmh9WWKKJNhHGdsI81A3W8iiY6cBni+IYw86xBGLhlol8Mjwp0OLX4u6 CxTRGgfBCazsYhqtNoOqkg50Cdu+RmrH6ZQV0uHSZuxcf0iTAeMkLb0W; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [BEHAVE] REALM's quotes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I'm helping with this iteration of rfc3489bis, and we had a question. Several reviewers of rfc3489bis had commented about the use of quotes in the REALM attribute in the existing draft: 11.7. REALM The REALM attribute is present in requests and responses. It contains text which meets the grammar for "realm" as described in RFC 3261 [11], and will thus contain a quoted string (including the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ quotes). ^^^^^^ Would anyone have heartache if we removed quotes from this attribute? Should we provide guidance that quotes might appear if a pre-RFC implementation is encountered? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 12:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtVy-0000RV-4i; Wed, 23 May 2007 12:16:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HqtVw-0000RL-Kv for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 12:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtVw-0000Qy-13 for behave@ietf.org; Wed, 23 May 2007 12:16:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqtVt-0005VG-3K for behave@ietf.org; Wed, 23 May 2007 12:16:39 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 23 May 2007 09:16:36 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="2164821:sNHT27714390" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4NGGaQU009959; Wed, 23 May 2007 09:16:36 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4NGGZ06003317; Wed, 23 May 2007 16:16:35 GMT From: "Dan Wing" To: "'Benny Prijono'" , Subject: RE: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses Date: Wed, 23 May 2007 09:16:35 -0700 Message-ID: <0a6b01c79d55$bc2e9960$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4653CAFC.1070000@pjsip.org> Thread-Index: Acec97H3uh4o7RqUSIG5a0bO/zWhaQAXXfLA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6109; t=1179936996; x=1180800996; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20MESSAGE-INTEGRITY=20in=20STUN=20error=20re sponses |Sender:=20; bh=p89hzG8cdX/b6mUFKQSKi/JJOGDse/BPzJm7zUoic4A=; b=sKhc/W1MbrvisrZi9Gki0j3GXdjQfBaznSeolpC0Ym6OOlK1QxvBdcseIVoKBH+NkJJun4Kl OI4BXs1aoG1myYzW55E+HSfW+kz9J/hsFkbp5cYv10AJ7wYuINeov0cg; Authentication-Results: sj-dkim-6; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi. This did come up during rfc3489bis's working group last call, and Philip, Jonathan, and I took a shot at clarifying which error codes could have Message-Integrity. Here is the current work-in-progress text for that section. Except where noted, if the request included the USERNAME attribute and was protected with a valid MESSAGE-INTEGRITY attribute, the error response MUST also be protected with its own MESSAGE-INTEGRITY attribute. The following response codes, along with their recommended reason phrases (in brackets) are defined: 300 Try Alternate: The client should contact an alternate server for this request. This error response MUST only be sent if the request included a USERNAME attribute and a valid MESSAGE- INTEGRITY attribute; otherwise it MUST NOT be sent and error code 400 is suggested. This error response MUST be protected with the MESSAGE-INTEGRITY attribute, and receivers MUST validate the MESSAGE-INTEGRITY of this response before redirecting themselves to an alternate server. Note: failure to generate and validate message-integrity for a 300 response allows an on-path attacker to falsify a 300 response thus causing subsequent STUN messages to be sent to a victim. 400 Bad Request: The request was malformed. The client SHOULD NOT retry the request without modification from the previous attempt. 401 Unauthorized: The request did not contain the expected MESSAGE- INTEGRITY attribute. The server MAY include the MESSAGE- INTEGRITY attribute in its error response. 420 Unknown Attribute: The server received STUN packet containing a mandatory attribute which it did not understand. The server MUST put this unknown attribute in the UNKNOWN-ATTRIBUTE attribute of its error response. 430 Stale Credentials: The request did contain a MESSAGE-INTEGRITY attribute, but it used a shared secret that has expired. The client should obtain a new shared secret and try again. The server MAY include the MESSAGE-INTEGRITY attribute in its error response. 431 Integrity Check Failure: The request contained a MESSAGE- INTEGRITY attribute, but the HMAC failed verification. This could be a sign of a potential attack, or client implementation error. The server MAY include the MESSAGE-INTEGRITY attribute in its error response. 432 undefined The previous version of this specification defined this value, but its use has been deprecated. 433 Use TLS: The server received a shared secret request over an unencrypted channel, and it needs to be re-sent over TLS. 434 Missing Realm: The server expected a REALM attribute in the request, but none was present. [[dwing: need to consider if we keep this one.]] 435 Missing Nonce: The server expected a NONCE attribute in the request, but none was present. This error response is used in conjunction with the NONCE attribute to cause the client to send the NONCE value in a subsequent request. This error code and the NONCE procedure apply to only some STUN usages. 436 Unknown Username: The USERNAME supplied in the request is not known or is not known to the server. With this error code, the server cannot compute the MESSAGE-INTEGRITY, and thus SHOULD NOT include the MESSAGE-INTEGRITY attribute in the response. 438 Stale Nonce: The NONCE attribute was present in the request but wasn't valid. 500 Server Error: The server has suffered a temporary error. The client should try again. 600 Global Failure: The server is refusing to fulfill the request. The client should not retry. Comments welcome. I had one question on your post, where you suggested that error code 420 (unknown attribute) didn't need Message-Integrity. I think it should. -d > -----Original Message----- > From: Benny Prijono [mailto:bennylp@pjsip.org] > Sent: Tuesday, May 22, 2007 10:03 PM > To: behave@ietf.org > Subject: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses > > > All, > > Apologies if this has been discussed, but I have some doubts > regarding the processing of STUN error responses which requests had > included MESSAGE-INTEGRITY attribute. > > Few doubts: > > - In 8.3.2. Processing Responses, it says > > "All responses that were not discarded, whether success > responses or error responses, MUST first be authenticated > by the client." > > I'm assuming that this means STUN response (success or error) > with missing or incorrect M-I will be discarded before it > reaches client transaction FSM. > > And if so, I'm assuming that client would continue retransmitting > the request, as if it had not receive any response. > > > - If the above are true, then I think there need to be some > exception for some error responses which by definition cannot > contain M-I, so they cannot be authenticated. > > Reading Section 9.1.1. "Receive Request Message", I reckon these > error responses cannot contain M-I thus client should not > authenticate them: > > 401 (Unauthorized) > 432 (Missing Username) > 434 (Missing Realm) > 436 (Unknown Username) > 431 (Integrity Check Failure) > > And probably 420 (Unknown Attribute), and few others (I can look > for them, but for now I just want to be sure that what I'm > saying makes sense at all). > > Comments? > > cheers, > -benny > > > -- > Benny Prijono > http://www.pjsip.org > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 12:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqta4-0005Sm-PK; Wed, 23 May 2007 12:20:56 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hqta3-0005Sh-B2 for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 12:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqta3-0005SX-1C for behave@ietf.org; Wed, 23 May 2007 12:20:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqta2-00067Z-NZ for behave@ietf.org; Wed, 23 May 2007 12:20:55 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 23 May 2007 09:20:54 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="156639534:sNHT49206222" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4NGKsPo031226; Wed, 23 May 2007 09:20:54 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4NGKrV1014105; Wed, 23 May 2007 16:20:53 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , Subject: RE: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses Date: Wed, 23 May 2007 09:20:53 -0700 Message-ID: <0a6c01c79d56$55e1d400$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <200705231021.15239.remi.denis-courmont@nokia.com> Thread-Index: AcedCvIUSYopmqZQRlup8s9+sWAK0gAStGZQ DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2430; t=1179937254; x=1180801254; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20MESSAGE-INTEGRITY=20in=20STUN=20error=20re sponses |Sender:=20; bh=9ASbqzgiNaM+jt9p8TBGelJBUzy/lF41Ctvhm8xwpUU=; b=doBYZ6UeGrW3M3P9oRsEe+0sRJ1amiO+WFgC9QxOENEoVuiKc1TJpHqfnWWJtrRU/ew0CWrs Pxon+Xi1DdFQfflAg8Y3s3XY5r56zmLqDzzVnGDdWtRtjwd2YlZ/E3zN; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org =20 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 > Sent: Wednesday, May 23, 2007 12:21 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses >=20 > On Wednesday 23 May 2007 08:02:52 ext Benny Prijono wrote: > > Reading Section 9.1.1. "Receive Request Message", I reckon these > > error responses cannot contain M-I thus client should not > > authenticate them: > > > > 401 (Unauthorized) >=20 > The client will only receive a legitimate 401 if it did not=20 > authenticate in=20 > the first place, so it will not expect a M-I in the response either. >=20 > > 432 (Missing Username) >=20 > A conforming client will never emit authenticated messages=20 > without a USERNAME, so... Yeah, that's why we're deprecating that error in -07. =20 > > 434 (Missing Realm) > > 436 (Unknown Username) > > 431 (Integrity Check Failure) >=20 > These are the real issues. In practice, either you drop the=20 > errors, or you rely on the transaction ID. While the latter is=20 > vulnerable to a MITM attack, that's a not really a concern since an=20 > active MITM can pretty much always DoS the service anyway. However,=20 > this relies on really non-predictable transaction IDs. Transaction IDs are required to be random and evenly distributed, which should protect against that. Fortunately, a STUN client implementation = that screws up its transaction ID generation only makes itself vulnerable to = such attacks. > > And probably 420 (Unknown Attribute), and few others (I can look > > for them, but for now I just want to be sure that what I'm > > saying makes sense at all). >=20 > There should normally be no problem authenticating a 420,=20 Agreed. > unless a new attribute that does influence M-I in a non-backward=20 > compatible manner is defined. I surely hope we will not do that, and=20 > in any case, it should not be an issue for clients implementing the=20 > current drafts. Yeah, that would be a problem. Recall that in Prague we decided we needed to support new hashes for Message-Integrity, but over the last week I have come up with some=20 concerns with our initial plan to simply define new attributes that were fancier/faster/newer hashes. I'll get a message to the list on that concern shortly. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 13:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HquhS-0004vR-91; Wed, 23 May 2007 13:32:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HquhR-0004vM-C5 for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 13:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HquhR-0004vD-28 for behave@ietf.org; Wed, 23 May 2007 13:32:37 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HquhM-0005cM-R5 for behave@ietf.org; Wed, 23 May 2007 13:32:37 -0400 Received: from [61.94.220.188] (unknown [61.94.220.188]) by smtp.mxes.net (Postfix) with ESMTP id E5C1851943; Wed, 23 May 2007 13:32:30 -0400 (EDT) Message-ID: <4654798A.8060008@pjsip.org> Date: Wed, 23 May 2007 18:27:38 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] REALM's quotes References: <0a2101c79d4a$fda24780$c6f0200a@amer.cisco.com> In-Reply-To: <0a2101c79d4a$fda24780$c6f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: > I'm helping with this iteration of rfc3489bis, and we had a question. > Several reviewers of rfc3489bis had commented about the use of quotes in the > REALM attribute in the existing draft: > > 11.7. REALM > > The REALM attribute is present in requests and responses. It > contains text which meets the grammar for "realm" as described in RFC > 3261 [11], and will thus contain a quoted string (including the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > quotes). > ^^^^^^ > > Would anyone have heartache if we removed quotes from this attribute? It's okay with me. Please remove it. > Should we provide guidance that quotes might appear if a pre-RFC > implementation is encountered? Probably yes. And probably best to leave the text in 8.3.1 where implementation must remove the quotes in REALM before calculating the key for MESSAGE-INTEGRITY. -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 13:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hquhb-000513-FP; Wed, 23 May 2007 13:32:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hquha-00050y-Ps for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 13:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hquha-00050q-Fm for behave@ietf.org; Wed, 23 May 2007 13:32:46 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HquhY-0005dl-0C for behave@ietf.org; Wed, 23 May 2007 13:32:46 -0400 Received: from [61.94.220.188] (unknown [61.94.220.188]) by smtp.mxes.net (Postfix) with ESMTP id 2D7AD519A4; Wed, 23 May 2007 13:32:41 -0400 (EDT) Message-ID: <465479E6.9070406@pjsip.org> Date: Wed, 23 May 2007 18:29:10 +0100 From: Benny Prijono User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses References: <0a6b01c79d55$bc2e9960$c6f0200a@amer.cisco.com> In-Reply-To: <0a6b01c79d55$bc2e9960$c6f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: > Hi. This did come up during rfc3489bis's working group last call, and > Philip, Jonathan, and I took a shot at clarifying which error codes could > have Message-Integrity. Here is the current work-in-progress text for that > section. This is exactly what I was looking for, thanks. > 400 Bad Request: The request was malformed. The client SHOULD NOT > retry the request without modification from the previous > attempt. Shouldn't we make M-I inclusion a MAY here? The parser may find error before reaching USERNAME attribute, so in this case the server won't be able to generate M-I. > Comments welcome. I had one question on your post, where you suggested that > error code 420 (unknown attribute) didn't need Message-Integrity. I think > it should. I don't mind that. It's just that 420 is normally found out during parsing process, so it might be easier if the server just respond with 420 there, without having to pass the response to authentication layer. But I suppose this is not a big deal. -benny _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 23 13:43:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqurs-0003y1-90; Wed, 23 May 2007 13:43:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hqurr-0003xv-Lj for behave-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 13:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqurr-0003xn-Bt for behave@ietf.org; Wed, 23 May 2007 13:43:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqurq-0000cT-2S for behave@ietf.org; Wed, 23 May 2007 13:43:23 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 23 May 2007 10:43:21 -0700 X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="487977866:sNHT1255973256" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4NHhKfM017738; Wed, 23 May 2007 10:43:20 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4NHhJV1023717; Wed, 23 May 2007 17:43:20 GMT From: "Dan Wing" To: "'Benny Prijono'" Subject: RE: [BEHAVE] MESSAGE-INTEGRITY in STUN error responses Date: Wed, 23 May 2007 10:43:19 -0700 Message-ID: <0aaf01c79d61$da5e9a50$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <465479E6.9070406@pjsip.org> Thread-Index: AcedYF+es5wE2yn8RKWD4EmJa6Py1wAAOy4A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1698; t=1179942200; x=1180806200; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20MESSAGE-INTEGRITY=20in=20STUN=20error=20re sponses |Sender:=20; bh=/dZX6MPMmwTfhFDECxnbcT1KbNR/83dzj9G6ue93e74=; b=xdvtMy9w822wb1dGxeiTJQWoC4j45iStbhnq2D+Z/rSPEq/s15ZVQxd2DEx/bbbZatbjMWsD hzmq46/EY1qvCee/PW3mGsOwXjplp5U1yJ84P19XOZqfMc8MnaBp/O5Z; Authentication-Results: sj-dkim-8; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org ... > > 400 Bad Request: The request was malformed. The client > > SHOULD NOT > > retry the request without modification from the previous > > attempt. > > Shouldn't we make M-I inclusion a MAY here? The parser may find > error before reaching USERNAME attribute, so in this case the server > won't be able to generate M-I. Agreed. Here is the revised text (with lowercased MAY NOT): 400 Bad Request: The request was malformed. The client SHOULD NOT retry the request without modification from the previous attempt. The server may not be able to generate a valid MESSAGE-INTEGRITY for this error, so the client MUST NOT expect a valid MESSAGE-INTEGRITY attribute on this response. > > Comments welcome. I had one question on your post, where > > you suggested that > > error code 420 (unknown attribute) didn't need > > Message-Integrity. I think it should. > > I don't mind that. > > It's just that 420 is normally found out during parsing process, so > it might be easier if the server just respond with 420 there, > without having to pass the response to authentication layer. But > I suppose this is not a big deal. I agree that's when it would normally be found, but by making this decision (to have 420 include Message-Integrity), we are requiring the server to validate the Message-Integrity of the request. Is that alright. I expect it is, but it will incur additional processing on the server because it now has to first validate the Message-Integrity attribute and then walk through all of the mandatory attributes to see if there is one it didn't understand. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 24 08:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrCkY-0004ZV-8M; Thu, 24 May 2007 08:49:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrCkX-0004ZM-OA for behave-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 08:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrCkX-0004ZE-EV; Thu, 24 May 2007 08:49:01 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrCkV-0000X9-5r; Thu, 24 May 2007 08:49:01 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIJ00ADOQ8FXA@szxga03-in.huawei.com>; Thu, 24 May 2007 20:48:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIJ00A31Q8EYX@szxga03-in.huawei.com>; Thu, 24 May 2007 20:48:15 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIJ00C07Q8AZB@szxml03-in.huawei.com>; Thu, 24 May 2007 20:48:14 +0800 (CST) Date: Thu, 24 May 2007 20:48:10 +0800 From: JiangXingFeng To: jdrosen@cisco.com Message-id: <000001c79e01$c93cf640$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceeAcjWFi3SPqvFTTKMJGlpNok7TQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: behave@ietf.org, mmusic@ietf.org Subject: [BEHAVE] A question on draft-ietf-mmusic-ice-15 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, Jonathan: I have read your draft and have a question to ask you. Would you please give me some explanations? ICE is making use of offer/answer mechanism to collect some candidate pairs and check the connectivity between the local candidates and remote candidates. If a remote candidate is of type of relayed address, in my understanding, when the agent want to send a STUN check packet to the remote relayed address, it may not arrived at the remote candidate because the STUN server may filter the packet because of no permission. In other words, Relay usage makes the STUN servers act as a NAT with end independent mapping behavior and address dependent filtering behavior. If there is no permission for a specific external peer, the STUN server will filter the packet from the remote peer unless client has created permissions for the remote peer in advance. I don't find any action taken make the agent to notify the STUN server relay packets from the remote candidates. Maybe I miss something and my understanding is not correct. Could you please give me more explanations? Regards! -- Jiang XingFeng _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 24 14:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrICR-0005Rq-NK; Thu, 24 May 2007 14:38:11 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrICQ-0005Rf-7b for behave-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 14:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrICP-0005RX-U7; Thu, 24 May 2007 14:38:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrICO-0000gv-J3; Thu, 24 May 2007 14:38:09 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 24 May 2007 11:38:08 -0700 X-IronPort-AV: i="4.14,574,1170662400"; d="scan'208"; a="2446397:sNHT19242468" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4OIc7MQ015449; Thu, 24 May 2007 11:38:07 -0700 Received: from dwingwxp (dhcp-128-107-163-206.cisco.com [128.107.163.206]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4OIc7V1001646; Thu, 24 May 2007 18:38:07 GMT From: "Dan Wing" To: "'JiangXingFeng'" Subject: RE: [BEHAVE] A question on draft-ietf-mmusic-ice-15 Date: Thu, 24 May 2007 11:38:07 -0700 Message-ID: <019d01c79e32$ac58c280$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <000001c79e01$c93cf640$6905a40a@china.huawei.com> Thread-Index: AceeAcjWFi3SPqvFTTKMJGlpNok7TQAMLaTw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1793; t=1180031888; x=1180895888; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20question=20on=20draft-ietf-mmusic-ice- 15 |Sender:=20; bh=MhlgQBQQDiauUhUyzQEx8c9J/k4+EwmFrmpEbNDV4vU=; b=mSaYJ2RDGKQ/bjmLPy7YlfRVTNGBa91FIeUceXv7cs22xWxzG/NUxinKV6mbm46gAz+3/lov E2AyGwhs+Wx/3iyCbt4EvZqDREGqLvlgCr/n29yByXjExyqnYjMY4HyH; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org TURN's Set Active Destination accomplishes that. See http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2 -d > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Thursday, May 24, 2007 5:48 AM > To: jdrosen@cisco.com > Cc: behave@ietf.org; mmusic@ietf.org > Subject: [BEHAVE] A question on draft-ietf-mmusic-ice-15 > > Hi, Jonathan: > > I have read your draft and have a question to ask you. Would > you please give > me some explanations? > > ICE is making use of offer/answer mechanism to collect some > candidate pairs > and check the connectivity between the local candidates and remote > candidates. If a remote candidate is of type of relayed > address, in my > understanding, when the agent want to send a STUN check > packet to the remote > relayed address, it may not arrived at the remote candidate > because the STUN > server may filter the packet because of no permission. > > In other words, Relay usage makes the STUN servers act as a > NAT with end > independent mapping behavior and address dependent filtering > behavior. If > there is no permission for a specific external peer, the STUN > server will > filter the packet from the remote peer unless client has > created permissions > for the remote peer in advance. > > I don't find any action taken make the agent to notify the > STUN server relay > packets from the remote candidates. Maybe I miss something and my > understanding is not correct. Could you please give me more > explanations? > > Regards! > > -- > Jiang XingFeng > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 00:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrR3U-0006z6-HX; Fri, 25 May 2007 00:05:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrR3U-0006yx-8h for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 00:05:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrR3T-0006yp-VI; Fri, 25 May 2007 00:05:31 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrR3S-0005Bt-Ge; Fri, 25 May 2007 00:05:31 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JIK009ULWNVD8@szxga02-in.huawei.com>; Fri, 25 May 2007 12:04:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JIK00BBBWNVCO@szxga02-in.huawei.com>; Fri, 25 May 2007 12:04:43 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JIK008S2WNRNO@szxml03-in.huawei.com>; Fri, 25 May 2007 12:04:43 +0800 (CST) Date: Fri, 25 May 2007 12:04:39 +0800 From: JiangXingFeng Subject: RE: [BEHAVE] A question on draft-ietf-mmusic-ice-15 In-reply-to: <019d01c79e32$ac58c280$c6f0200a@amer.cisco.com> To: 'Dan Wing' Message-id: <000001c79e81$d119d790$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceeAcjWFi3SPqvFTTKMJGlpNok7TQAMLaTwABOgDCA= X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > TURN's Set Active Destination accomplishes that. See > http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2 Thanks for your reply. Besides Set Active Destination, there are some other methods could do the same thing, such as Open, Send indications. Do we need to add more text to ICE draft and say that "before connectivity check begins, agent A should create permission for Relayed address in order to allow connectivity check's packet from other agent through the NAT and reach the agent. A"? --- JiangXingFeng _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 00:30:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrRRV-00061B-LT; Fri, 25 May 2007 00:30:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrRRT-00060n-7P for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 00:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrRRS-00060c-TE; Fri, 25 May 2007 00:30:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrRRR-0001QX-J0; Fri, 25 May 2007 00:30:18 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 24 May 2007 21:30:17 -0700 X-IronPort-AV: i="4.14,577,1170662400"; d="scan'208"; a="157374659:sNHT40034259" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4P4UG0F020784; Thu, 24 May 2007 21:30:16 -0700 Received: from dwingwxp ([10.32.240.198]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4P4UG06013284; Fri, 25 May 2007 04:30:16 GMT From: "Dan Wing" To: "'JiangXingFeng'" Subject: RE: [BEHAVE] A question on draft-ietf-mmusic-ice-15 Date: Thu, 24 May 2007 21:30:15 -0700 Message-ID: <043a01c79e85$64e8dd10$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <000001c79e81$d119d790$6905a40a@china.huawei.com> Thread-Index: AceeAcjWFi3SPqvFTTKMJGlpNok7TQAMLaTwABOgDCAAAPRDUA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=757; t=1180067416; x=1180931416; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20question=20on=20draft-ietf-mmusic-ice- 15 |Sender:=20; bh=GyFqoNwVIks9iCxYxTI6fGa5jnqP616TtTOh8WOEV1o=; b=fo8dZtEu9HvOlk1G++PzDO06g08xPc6pctsXjGz3WwISqzFqmLBjQ07kVyHF/ipK5Xd7SH6C Z128J9dtM5XQ82G4ZxRiPchVOCZsT/UualfcVNIN4FWdMW1P6Gasvz2p; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > TURN's Set Active Destination accomplishes that. See > > http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2 > > Thanks for your reply. Besides Set Active Destination, there > are some other methods could do the same thing, such as Open, > Send indications. > > Do we need to add more text to ICE draft and say that "before > connectivity check begins, agent A should create permission > for Relayed address in order to allow connectivity check's > packet from other agent through the NAT and reach the agent. > A"? It's not necessary -- the combination of the triggered checks and retries by the answerer cause the permission and the connectivity check to complete as soon as the permission is created. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 03:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrUAd-0001ay-VM; Fri, 25 May 2007 03:25:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrUAd-0001aq-Ba for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 03:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrUAa-0001ac-2O for behave@ietf.org; Fri, 25 May 2007 03:25:04 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrUAY-00071Z-Jo for behave@ietf.org; Fri, 25 May 2007 03:25:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4P7OgV5011828; Fri, 25 May 2007 10:24:44 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:24:33 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:24:32 +0300 Received: from esdhcp04056.research.nokia.com ([172.21.40.56]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:24:32 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt Date: Fri, 25 May 2007 10:24:52 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705111045.58341.remi.denis-courmont@nokia.com> <4652BA35.4030809@ericsson.com> In-Reply-To: <4652BA35.4030809@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705251024.52782.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 May 2007 07:24:32.0619 (UTC) FILETIME=[BD4AABB0:01C79E9D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Oscar.Novo@ericsson.com, behave@ietf.org, Karim El Malki , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Tuesday 22 May 2007 12:39:01 ext Gonzalo Camarillo wrote: > If we decided to add support for relays to provide multiple IPv6 > addresses, ICE (i.e., STUN) checks would discover which ones work and > which ones don't. Hmm, I am now thinking there is another issue that I failed to think of in = the=20 first place, if we allow multiple mapped address for a single TURN=20 allocation: how does the TURN server knows which mapped address to use when= =20 forwarding Send Indication?! :( Oops, sorry. =46or the "simple" scenario that an allocation can have one IPv4 and one IP= v6,=20 it's fine (matching address family is sufficient), but if we allowed multip= le=20 IPv6 address, there might be an issue. Maybe it's better to stick to only o= ne=20 address per family at most? Alternatives include ignoring this minor issue, or specifying the source=20 address in Send Indication and the destination address in Data Indication.= =20 =46or those intimate with the BSD socket API or with RFC3542, this issue is= =20 equivalent to IP_PKTINFO and IP6_PKTINFO stuff. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 04:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrV3v-0004FE-9N; Fri, 25 May 2007 04:22:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrV3t-0004F5-Gc for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 04:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrV3t-0004Ex-44 for behave@ietf.org; Fri, 25 May 2007 04:22:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrV3r-0000UH-G2 for behave@ietf.org; Fri, 25 May 2007 04:22:13 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C5F92209FE; Fri, 25 May 2007 10:22:10 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-4d-46569cb2ea6a Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ABD8E204A7; Fri, 25 May 2007 10:22:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:22:10 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 10:22:10 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0DB942467; Fri, 25 May 2007 11:22:10 +0300 (EEST) Message-ID: <46569CB1.5070207@ericsson.com> Date: Fri, 25 May 2007 11:22:09 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705111045.58341.remi.denis-courmont@nokia.com> <4652BA35.4030809@ericsson.com> <200705251024.52782.remi.denis-courmont@nokia.com> In-Reply-To: <200705251024.52782.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 25 May 2007 08:22:10.0179 (UTC) FILETIME=[CA287530:01C79EA5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Oscar Novo \(JO/LMF\)" , behave@ietf.org, Karim El Malki , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I have changed the subject to make discussions on this issue more explici= t. We could do as you suggest and include the source address in Send=20 Indications and the destination address in Data Indications. I think it=20 is better to be explicit, as opposed to having the relay use the=20 destination or the source address of the data to decide which allocated=20 address to use. Additionally, we could define the new address family as follows: 0x02 - Global Unicast IPv6 address If in the future we want to add support for, say, 6to4 addresses, we=20 could define a new address type. We also need to decide which model we want to support. At present, a=20 client requests a set of address families from the server. Earlier in=20 this thread, you seemed to want servers to provide clients with all the=20 address families they support. I believe the former model would work=20 fine as long as the client has a way to discover the capabilities of the=20 server in order to figure out which address families are actually support= ed. Comments? Gonzalo R=E9mi Denis-Courmont wrote: > On Tuesday 22 May 2007 12:39:01 ext Gonzalo Camarillo wrote: > > If we decided to add support for relays to provide multiple IPv6 > > addresses, ICE (i.e., STUN) checks would discover which ones work an= d > > which ones don't. >=20 > Hmm, I am now thinking there is another issue that I failed to think of= =20 > in the > first place, if we allow multiple mapped address for a single TURN > allocation: how does the TURN server knows which mapped address to use = when > forwarding Send Indication?! :( Oops, sorry. >=20 > For the "simple" scenario that an allocation can have one IPv4 and one = IPv6, > it's fine (matching address family is sufficient), but if we allowed=20 > multiple > IPv6 address, there might be an issue. Maybe it's better to stick to=20 > only one > address per family at most? >=20 > Alternatives include ignoring this minor issue, or specifying the sourc= e > address in Send Indication and the destination address in Data Indicati= on. > For those intimate with the BSD socket API or with RFC3542, this issue = is > equivalent to IP_PKTINFO and IP6_PKTINFO stuff. >=20 > -- > R=E9mi Denis-Courmont >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 05:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrVyb-00030t-MK; Fri, 25 May 2007 05:20:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrVyZ-00030j-Ea for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 05:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrVyZ-00030Y-4Y for behave@ietf.org; Fri, 25 May 2007 05:20:47 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrVyX-0004r4-Lj for behave@ietf.org; Fri, 25 May 2007 05:20:47 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4P9KHvT030301; Fri, 25 May 2007 12:20:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 12:20:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 12:20:22 +0300 Received: from esdhcp04056.research.nokia.com ([172.21.40.56]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 12:20:21 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Fri, 25 May 2007 12:20:42 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705251024.52782.remi.denis-courmont@nokia.com> <46569CB1.5070207@ericsson.com> In-Reply-To: <46569CB1.5070207@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705251220.42425.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 May 2007 09:20:22.0011 (UTC) FILETIME=[EB73BCB0:01C79EAD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Oscar Novo \(JO/LMF\)" , behave@ietf.org, Karim El Malki , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 25 May 2007 11:22:09 ext Gonzalo Camarillo wrote: > We could do as you suggest and include the source address in Send > Indications and the destination address in Data Indications. I think it > is better to be explicit, as opposed to having the relay use the > destination or the source address of the data to decide which allocated > address to use. True, thanks. > Additionally, we could define the new address family as follows: > > 0x02 - Global Unicast IPv6 address > > If in the future we want to add support for, say, 6to4 addresses, we > could define a new address type. This has pros and cons. A TURN client only need to know about IPv6 - not ab= out=20 6to4/Teredo/ULA - to be able to use a 6to4/Teredo/ULA mapped address. On th= e=20 other hand, it would need to know about HIP if it were to use HIP (it's=20 highly hypothetical that HIP will ever mix with TURN, but I cannot think of= =20 any other example). The question really is whether it's worth the added complexity - if nobody= =20 ever deploys TURN relays with different types of IPv6 addresses, it's not=20 much use. *I* am not working for a network gear vendor or an ISP, so I do n= ot=20 feel like taking a position on that thing. > We also need to decide which model we want to support. At present, a > client requests a set of address families from the server. Earlier in > this thread, you seemed to want servers to provide clients with all the > address families they support. I believe the former model would work > fine as long as the client has a way to discover the capabilities of the > server in order to figure out which address families are actually > supported. The simplest solution might be that the client puts all the address types i= t=20 wants to use, and the server only replies with those that it supports, and= =20 return an error if it does not support any of these (a bit like TLS=20 ciphersuite negociation, I believe). I assume the client is only ever interested in the adress types that it kno= ws.=20 So the full list of types known to server is not much use. This also saves = us=20 one extra transaction (more spec work, more implementation and more=20 round-trips). Best regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 07:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXgz-0003P5-9s; Fri, 25 May 2007 07:10:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrXgy-0003P0-4n for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 07:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXgx-0003Os-RO for behave@ietf.org; Fri, 25 May 2007 07:10:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrXgv-0007C1-R1 for behave@ietf.org; Fri, 25 May 2007 07:10:43 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 16ACD20C59; Fri, 25 May 2007 13:10:41 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-5d-4656c430e2f5 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F12E820BE9; Fri, 25 May 2007 13:10:40 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 13:10:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 13:10:39 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EA0F22467; Fri, 25 May 2007 14:10:39 +0300 (EEST) Message-ID: <4656C42F.50801@ericsson.com> Date: Fri, 25 May 2007 14:10:39 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705251024.52782.remi.denis-courmont@nokia.com> <46569CB1.5070207@ericsson.com> <200705251220.42425.remi.denis-courmont@nokia.com> In-Reply-To: <200705251220.42425.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 25 May 2007 11:10:40.0034 (UTC) FILETIME=[5419E820:01C79EBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Oscar Novo \(JO/LMF\)" , behave@ietf.org, Karim El Malki , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Remi, it seems that we agree on defining the new address family as Global=20 Unicast IPv6 Address, and including source address in Send Indications=20 and the destination address in Data Indications, then. We should also extend the 440 (Address Family not Supported) response so=20 that it carries the identifiers of those addresses that are not=20 supported (so that it is future proof, just in case there are more=20 address types defined in the future). Shall we go ahead edit the draft accordingly? Cheers, Gonzalo R=E9mi Denis-Courmont wrote: > On Friday 25 May 2007 11:22:09 ext Gonzalo Camarillo wrote: > > We could do as you suggest and include the source address in Send > > Indications and the destination address in Data Indications. I think= it > > is better to be explicit, as opposed to having the relay use the > > destination or the source address of the data to decide which alloca= ted > > address to use. >=20 > True, thanks. >=20 > > Additionally, we could define the new address family as follows: > > > > 0x02 - Global Unicast IPv6 address > > > > If in the future we want to add support for, say, 6to4 addresses, we > > could define a new address type. >=20 > This has pros and cons. A TURN client only need to know about IPv6 - no= t=20 > about > 6to4/Teredo/ULA - to be able to use a 6to4/Teredo/ULA mapped address. O= n the > other hand, it would need to know about HIP if it were to use HIP (it's > highly hypothetical that HIP will ever mix with TURN, but I cannot thin= k of > any other example). >=20 > The question really is whether it's worth the added complexity - if nob= ody > ever deploys TURN relays with different types of IPv6 addresses, it's n= ot > much use. *I* am not working for a network gear vendor or an ISP, so I=20 > do not > feel like taking a position on that thing. >=20 > > We also need to decide which model we want to support. At present, a > > client requests a set of address families from the server. Earlier i= n > > this thread, you seemed to want servers to provide clients with all = the > > address families they support. I believe the former model would work > > fine as long as the client has a way to discover the capabilities of= the > > server in order to figure out which address families are actually > > supported. >=20 > The simplest solution might be that the client puts all the address typ= es it > wants to use, and the server only replies with those that it supports, = and > return an error if it does not support any of these (a bit like TLS > ciphersuite negociation, I believe). >=20 > I assume the client is only ever interested in the adress types that it= =20 > knows. > So the full list of types known to server is not much use. This also=20 > saves us > one extra transaction (more spec work, more implementation and more > round-trips). >=20 > Best regards, >=20 > -- > R=E9mi Denis-Courmont >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 07:19:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXps-0001FF-Lq; Fri, 25 May 2007 07:19:56 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrXpS-00014g-22 for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 07:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXpR-00014G-6o for behave@ietf.org; Fri, 25 May 2007 07:19:29 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrXpO-0000cC-Oz for behave@ietf.org; Fri, 25 May 2007 07:19:29 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 490FB20B97; Fri, 25 May 2007 13:19:26 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-ea-4656c63e5e68 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29B7920A8E; Fri, 25 May 2007 13:19:26 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 13:19:25 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 13:19:25 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 621BD2467; Fri, 25 May 2007 14:19:25 +0300 (EEST) Message-ID: <4656C63D.7090807@ericsson.com> Date: Fri, 25 May 2007 14:19:25 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705251024.52782.remi.denis-courmont@nokia.com> <46569CB1.5070207@ericsson.com> <200705251220.42425.remi.denis-courmont@nokia.com> In-Reply-To: <200705251220.42425.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2007 11:19:25.0620 (UTC) FILETIME=[8D5FF740:01C79EBE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Oscar Novo \(JO/LMF\)" , behave@ietf.org, Karim El Malki , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, > I assume the client is only ever interested in the adress types that it > knows. > So the full list of types known to server is not much use. This also > saves us > one extra transaction (more spec work, more implementation and more > round-trips). I was thinking of a capability discovery mechanism that clients could use to choose a relay. That is, they would not query the relay for its capabilities at session establishment time. Instead, this would be done at configuration time. For example, a user may prefer to configure its client with a relay that supports the allocation of both IPv6 and IPv4 addresses, and not only IPv4. Cheers, Gonzalo _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri May 25 08:56:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZLF-0006NY-V8; Fri, 25 May 2007 08:56:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HrZLE-0006NN-Pb for behave-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 08:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZLE-0006NE-Fg for behave@ietf.org; Fri, 25 May 2007 08:56:24 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrZLD-00089l-0p for behave@ietf.org; Fri, 25 May 2007 08:56:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4PCsVji009741; Fri, 25 May 2007 15:55:06 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 15:55:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 15:55:04 +0300 Received: from esdhcp04056.research.nokia.com ([172.21.40.56]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 15:55:03 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Fri, 25 May 2007 15:55:23 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705251220.42425.remi.denis-courmont@nokia.com> <4656C42F.50801@ericsson.com> In-Reply-To: <4656C42F.50801@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705251555.23753.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 25 May 2007 12:55:03.0583 (UTC) FILETIME=[E977A2F0:01C79ECB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Oscar Novo \(JO/LMF\)" , behave@ietf.org, Karim El Malki X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 25 May 2007 14:10:39 you wrote: > Hi Remi, > > it seems that we agree on defining the new address family as Global > Unicast IPv6 Address, and including source address in Send Indications > and the destination address in Data Indications, then. > > We should also extend the 440 (Address Family not Supported) response so > that it carries the identifiers of those addresses that are not > supported (so that it is future proof, just in case there are more > address types defined in the future). > > Shall we go ahead edit the draft accordingly? That's fine with me, thanks. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun May 27 03:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsCtG-00089z-PL; Sun, 27 May 2007 03:10:10 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HsCtF-00089r-SC for behave-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 03:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsCtC-000898-HQ for behave@ietf.org; Sun, 27 May 2007 03:10:06 -0400 Received: from web33304.mail.mud.yahoo.com ([68.142.206.119]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HsCtC-0008M5-0o for behave@ietf.org; Sun, 27 May 2007 03:10:06 -0400 Received: (qmail 79248 invoked by uid 60001); 27 May 2007 07:10:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=4CR1PnH9hxUU56dLZ0cb1X2Pxp+Z97dkOjjmQGd+q6qRihJ0XMWgO0bbwhwh8jgQFmhHU54kVdHgx5KaCn7ujLXva3nbzkWJynNzEd7Mwqqh4bbBwg8HGCfsLdYsYUVDvibavwXkLsdaeNyXEp94Eni+0Wsx+W19geE61jIyTB4=; X-YMail-OSG: 53lJzN0VM1l7me9Crwq8w_J6aSsYKTcGS9.80pCRANr4tPmNvgwYcGyEnc5U4A.rk6w5NmFM7v1UWjZcLYr7sr9G.tb4o0zE_qMmxLmGgCllyCM- Received: from [69.236.65.249] by web33304.mail.mud.yahoo.com via HTTP; Sun, 27 May 2007 00:10:05 PDT Date: Sun, 27 May 2007 00:10:05 -0700 (PDT) From: Pyda Srisuresh Subject: RE: [BEHAVE] ICMP type 3, code 13, one more time To: Dan Wing , 'Cullen Jennings' , 'Behave WG' In-Reply-To: <00da01c78e8e$52a58d30$c4a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <276840.78180.qm@web33304.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan, >From the e-mails below, it seems, the use of ICMP type 3, error code 13 for REQ-8 has WG consensus. If my read is incorrect, please summarize the consensus. I would appreciate that. This is the last of the outstanding comments on the draft, AFAIK. Once I have the closure on this, I will be happy to get the next rev of the draft. I believe, the next rev of the draft should be ready for a WGLC. Thanks. regards, suresh --- Dan Wing wrote: > > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Thursday, May 03, 2007 3:07 PM > > To: Behave WG > > Subject: [BEHAVE] ICMP type 3, code 13, one more time > > > > > > I was having lunch today with Srisuresh and we came to an > > interesting > > inside on how to resolve this. The important thing is not if a NAT > > thinks it's a router, host, or power tool. The important thing is > > what does an applications that receives the ICMP error does. One > > observation is that it might be that you want error codes > > sent to the inside to be different than one sent to the outside. > > When the NAT can't create a new mapping, the ICMP error would only be > sent to the inside. Afterall, it's not possible to even create a > new mapping from the outside. > > > The other > > observation is that if 9,10,13 are all soft errors - do we want a > > soft or hard error here? > > A NAT that runs out of resources (say, runs out of UDP mappings) > seems a transient event on par with a routing error such as > 'network unreachable' (ICMP type=3, code=0), which is classified > as a soft error. > > (as individual.) > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue May 29 13:50:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5pz-0008Ic-Rh; Tue, 29 May 2007 13:50:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ht5pz-0008IU-13 for behave-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 13:50:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5py-0008IM-LO; Tue, 29 May 2007 13:50:26 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ht5pw-0007eR-OD; Tue, 29 May 2007 13:50:26 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1Ht5q4-0003pa-Fx; Tue, 29 May 2007 13:50:32 -0400 In-Reply-To: <043a01c79e85$64e8dd10$c6f0200a@amer.cisco.com> References: <043a01c79e85$64e8dd10$c6f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F2C075D-A4CF-4287-A228-CF2979624B30@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] A question on draft-ietf-mmusic-ice-15 Date: Tue, 29 May 2007 13:50:34 -0400 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: behave@ietf.org, mmusic@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 25-May-07, at 00:30 , Dan Wing wrote: >>> TURN's Set Active Destination accomplishes that. See >>> http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2 >> >> Thanks for your reply. Besides Set Active Destination, there >> are some other methods could do the same thing, such as Open, >> Send indications. >> >> Do we need to add more text to ICE draft and say that "before >> connectivity check begins, agent A should create permission >> for Relayed address in order to allow connectivity check's >> packet from other agent through the NAT and reach the agent. >> A"? > > It's not necessary -- the combination of the triggered checks > and retries by the answerer cause the permission and the > connectivity check to complete as soon as the permission is > created. Just a bit more clarification here. "Set Active Destination" is one way to install a filtering entry for the remote peer in the TURN server, but there is another way. Consider two peers, L and R, which are behind different NATs. L uses a TURN server T. If R sends a connectivity check to L's allocated address on T before anything else happens, then you are correct that T will discard the packet. However, this will install a filtering entry into R's local NAT. Then when L sends a connectivity check from T towards R, this will install a filtering entry on T for R, and this connectivity check packet will also get through R's NAT because of the previously installed filtering entry. If the order is reversed (L sends first), then a connectivity check from L's allocated address on T towards R will be dropped by R's NAT, but will install a filtering entry on T. Then when R sends a connectivity check from R to L's address on T, this connectivity check will get through because of the previously installed filtering entry on T. To summarize: If R sends first, then its connectivity check packets get dropped by T until L sends its first packet towards R. If L sends first, then its connectivity check packets get dropped by R's NAT until R sends its first packet towards L's address on T. In other words, the packets do not get through until both ends try to send. This is the reason that ICE defines a priority function for candidate pairs -- so both ends will send checks at approximately the same time. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue May 29 14:11:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht6Ai-0002DV-Sn; Tue, 29 May 2007 14:11:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Ht6Ah-0002DI-7m for behave-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 14:11:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht6Ag-0002DA-UO for behave@ietf.org; Tue, 29 May 2007 14:11:50 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht6Af-0000Vi-J0 for behave@ietf.org; Tue, 29 May 2007 14:11:50 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1Ht6Ag-0000u8-3P; Tue, 29 May 2007 14:11:50 -0400 In-Reply-To: <4656C42F.50801@ericsson.com> References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705251024.52782.remi.denis-courmont@nokia.com> <46569CB1.5070207@ericsson.com> <200705251220.42425.remi.denis-courmont@nokia.com> <4656C42F.50801@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B464C43-A9B8-4D64-A4C3-4E08065C2C42@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Tue, 29 May 2007 14:11:59 -0400 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Behave WG , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 25-May-07, at 07:10 , Gonzalo Camarillo wrote: > Hi Remi, > > it seems that we agree on defining the new address family as Global > Unicast IPv6 Address, and including source address in Send > Indications and the destination address in Data Indications, then. Sorry for jumping into this late. I assume you are talking about adding a SourceAddress attribute to the Send Indication and a DestinationAddress attribute to the Data Indication. Would a client always have to specify a source address attribute in a Send Indication, and a server always include a destination address in Data indication? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 00:45:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtG3t-0006QJ-B6; Wed, 30 May 2007 00:45:29 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtG3r-0006Q0-Qi for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 00:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtG3r-0006Pr-Gn for behave@ietf.org; Wed, 30 May 2007 00:45:27 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtG3p-0006bp-2Y for behave@ietf.org; Wed, 30 May 2007 00:45:27 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B9E952068D; Wed, 30 May 2007 06:45:23 +0200 (CEST) X-AuditID: c1b4fb3c-a7ce9bb0000073d5-97-465d01635988 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A9912204FC; Wed, 30 May 2007 06:45:23 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 06:45:23 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 06:45:22 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C807023F6; Wed, 30 May 2007 07:45:22 +0300 (EEST) Message-ID: <465D0162.5010807@ericsson.com> Date: Wed, 30 May 2007 07:45:22 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Philip Matthews Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705251024.52782.remi.denis-courmont@nokia.com> <46569CB1.5070207@ericsson.com> <200705251220.42425.remi.denis-courmont@nokia.com> <4656C42F.50801@ericsson.com> <5B464C43-A9B8-4D64-A4C3-4E08065C2C42@magma.ca> In-Reply-To: <5B464C43-A9B8-4D64-A4C3-4E08065C2C42@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 04:45:23.0050 (UTC) FILETIME=[555ED4A0:01C7A275] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Behave WG , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, inline: Philip Matthews wrote: > > On 25-May-07, at 07:10 , Gonzalo Camarillo wrote: > >> Hi Remi, >> >> it seems that we agree on defining the new address family as Global >> Unicast IPv6 Address, and including source address in Send Indications >> and the destination address in Data Indications, then. > > Sorry for jumping into this late. > I assume you are talking about adding a SourceAddress attribute to the > Send Indication and a DestinationAddress attribute to the Data Indication. Yes. > Would a client always have to specify a source address attribute in a > Send Indication, and a server always include a destination address in > Data indication? It would if the relay allocated more than one address. If the client (or the relay) did not specify anything, it would mean IPv4. Cheers, Gonzalo _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 02:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHKm-0007OF-VM; Wed, 30 May 2007 02:07:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtHKj-0007BF-TK for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 02:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHKi-00078f-Ve for behave@ietf.org; Wed, 30 May 2007 02:06:56 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtHKh-0004nu-H0 for behave@ietf.org; Wed, 30 May 2007 02:06:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U66ieb028273; Wed, 30 May 2007 09:06:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:06:43 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:06:43 +0300 Received: from esdhcp04057.research.nokia.com ([172.21.40.57]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:06:43 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Philip Matthews" , Behave WG , ext Dan Wing , Gonzalo Camarillo Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Wed, 30 May 2007 09:07:06 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <4656C42F.50801@ericsson.com> <5B464C43-A9B8-4D64-A4C3-4E08065C2C42@magma.ca> In-Reply-To: <5B464C43-A9B8-4D64-A4C3-4E08065C2C42@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705300907.06853.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 May 2007 06:06:43.0273 (UTC) FILETIME=[B235C390:01C7A280] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hello, On Tuesday 29 May 2007 21:11:59 you wrote: > Sorry for jumping into this late. > I assume you are talking about adding a SourceAddress attribute to > the Send Indication and a DestinationAddress attribute to the Data > Indication. Exactly. > Would a client always have to specify a source address attribute in a > Send Indication, and a server always include a destination address in > Data indication? =46or Data indication, I guess it's needed unless the allocation has only o= ne=20 server address of the source address family (in which case the client may=20 infer the server address from the source address family). =46or Send Indication, as Gonzalo said source address can be optional for I= Pv4,=20 but also if the allocation has only one address of the same family as the=20 destination. Are you concerned with bandwidth, complexity or curious, or...? I do not have any very strong opinion. One option would be to enforce a sin= gle=20 server address per family and per allocation; Then we do not need these=20 Destination in Data indication neither Source in Send indication. Maybe we= =20 should solicit feedback from the v6ops WG on that issue, eh? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 02:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHNv-00008k-NJ; Wed, 30 May 2007 02:10:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtHNt-00008d-Rj for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 02:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHNt-00008U-3o for behave@ietf.org; Wed, 30 May 2007 02:10:13 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtHNr-0005ij-9f for behave@ietf.org; Wed, 30 May 2007 02:10:13 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8C77320809; Wed, 30 May 2007 08:10:10 +0200 (CEST) X-AuditID: c1b4fb3c-aa4eebb0000073d5-7f-465d1542dbfa Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 71DFD2080F; Wed, 30 May 2007 08:10:10 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 08:10:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 08:10:09 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9973D2356; Wed, 30 May 2007 09:10:09 +0300 (EEST) Message-ID: <465D1541.6070309@ericsson.com> Date: Wed, 30 May 2007 09:10:09 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <4656C42F.50801@ericsson.com> <5B464C43-A9B8-4D64-A4C3-4E08065C2C42@magma.ca> <200705300907.06853.remi.denis-courmont@nokia.com> In-Reply-To: <200705300907.06853.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 06:10:09.0754 (UTC) FILETIME=[2D4843A0:01C7A281] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Behave WG , ext Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, > I do not have any very strong opinion. One option would be to enforce a > single > server address per family and per allocation; I believe we have rough consensus on using a single address per family, and on having the possibility of having multiple addresses per allocation. Cheers, Gonzalo _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 02:19:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHXF-0005gY-3u; Wed, 30 May 2007 02:19:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtHXE-0005gQ-M4 for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 02:19:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHXE-0005gI-Bf for behave@ietf.org; Wed, 30 May 2007 02:19:52 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtHXC-00010s-T4 for behave@ietf.org; Wed, 30 May 2007 02:19:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U6JcrF011279; Wed, 30 May 2007 09:19:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:19:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:19:35 +0300 Received: from esdhcp04057.research.nokia.com ([172.21.40.57]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:19:35 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Wed, 30 May 2007 09:19:58 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300907.06853.remi.denis-courmont@nokia.com> <465D1541.6070309@ericsson.com> In-Reply-To: <465D1541.6070309@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705300919.59054.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 May 2007 06:19:35.0172 (UTC) FILETIME=[7E4C3440:01C7A282] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Behave WG , ext Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Wednesday 30 May 2007 09:10:09 ext Gonzalo Camarillo wrote: > Hi, > > > I do not have any very strong opinion. One option would be to enforce a > > single > > server address per family and per allocation; > > I believe we have rough consensus on using a single address per family, > and on having the possibility of having multiple addresses per allocation. =46ine, then source-in-Send and destination-in-Data are not really needed. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 02:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHbC-0008UD-UW; Wed, 30 May 2007 02:23:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtHbB-0008TZ-DI for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 02:23:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHb7-0008P1-QU for behave@ietf.org; Wed, 30 May 2007 02:23:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtHb6-0001Mp-8b for behave@ietf.org; Wed, 30 May 2007 02:23:53 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 884DE21053; Wed, 30 May 2007 08:23:51 +0200 (CEST) X-AuditID: c1b4fb3e-b01efbb0000061ca-4a-465d18777456 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6A84C2044B; Wed, 30 May 2007 08:23:51 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 08:23:51 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 08:23:50 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B071026E8; Wed, 30 May 2007 09:23:50 +0300 (EEST) Message-ID: <465D1875.3070004@ericsson.com> Date: Wed, 30 May 2007 09:23:49 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300907.06853.remi.denis-courmont@nokia.com> <465D1541.6070309@ericsson.com> <200705300919.59054.remi.denis-courmont@nokia.com> In-Reply-To: <200705300919.59054.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 30 May 2007 06:23:50.0923 (UTC) FILETIME=[16BCB5B0:01C7A283] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Behave WG , ext Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, we agreed on defining the address family as Global IPv6 Unicast Address.=20 If, in the future, we decide to define new families (as you pointed=20 out), we will need the source-in-send and destination-in-data.=20 Therefore, I suggest we are explicit from the beginning and add them=20 from day one. This was my understanding of our discussions, actually. Cheers, Gonzalo R=E9mi Denis-Courmont wrote: > On Wednesday 30 May 2007 09:10:09 ext Gonzalo Camarillo wrote: >> Hi, >> >>> I do not have any very strong opinion. One option would be to enforce= a >>> single >>> server address per family and per allocation; >> I believe we have rough consensus on using a single address per family= , >> and on having the possibility of having multiple addresses per allocat= ion. >=20 > Fine, then source-in-Send and destination-in-Data are not really needed= . >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 02:44:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHud-0002X8-N9; Wed, 30 May 2007 02:44:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtHub-0002Wm-Ib for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 02:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtHub-0002Wc-7g for behave@ietf.org; Wed, 30 May 2007 02:44:01 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtHuZ-0005jS-Pp for behave@ietf.org; Wed, 30 May 2007 02:44:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U6hj6h007151; Wed, 30 May 2007 09:43:55 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:43:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:43:49 +0300 Received: from esdhcp04057.research.nokia.com ([172.21.40.57]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 09:43:49 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Wed, 30 May 2007 09:44:12 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300919.59054.remi.denis-courmont@nokia.com> <465D1875.3070004@ericsson.com> In-Reply-To: <465D1875.3070004@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705300944.12843.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 May 2007 06:43:49.0212 (UTC) FILETIME=[E0F919C0:01C7A285] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Behave WG , ext Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Wednesday 30 May 2007 09:23:49 ext Gonzalo Camarillo wrote: > we agreed on defining the address family as Global IPv6 Unicast Address. > If, in the future, we decide to define new families (as you pointed > out), we will need the source-in-send and destination-in-data. > Therefore, I suggest we are explicit from the beginning and add them > from day one. Ok, I might be confused because I do not know how you intend to spell it in= =20 the next draft. We really need source-in-send if (and only if) there is mor= e=20 than one address the server can use for a destination. So it depends what w= e=20 call address family here I guess. This can indeed happen if we have=20 different "families" that refer to the same network-layer protocol. Sorry. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 04:06:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJCL-00078K-4t; Wed, 30 May 2007 04:06:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtJCJ-00078B-JS for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 04:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJCG-000780-Dq for behave@ietf.org; Wed, 30 May 2007 04:06:20 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJCE-0007JP-Nc for behave@ietf.org; Wed, 30 May 2007 04:06:20 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1D6742103B; Wed, 30 May 2007 10:06:18 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-a8-465d307a47ad Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F301721026; Wed, 30 May 2007 10:06:17 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:06:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:06:17 +0200 Received: from [131.160.126.9] (rvi2-126-9.lmf.ericsson.se [131.160.126.9]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5DA8B2356; Wed, 30 May 2007 11:06:17 +0300 (EEST) Message-ID: <465D3078.4070704@ericsson.com> Date: Wed, 30 May 2007 11:06:16 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300919.59054.remi.denis-courmont@nokia.com> <465D1875.3070004@ericsson.com> <200705300944.12843.remi.denis-courmont@nokia.com> In-Reply-To: <200705300944.12843.remi.denis-courmont@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 08:06:17.0626 (UTC) FILETIME=[667527A0:01C7A291] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Behave WG , ext Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, > Ok, I might be confused because I do not know how you intend to spell it in > the next draft. We really need source-in-send if (and only if) there is more > than one address the server can use for a destination. So it depends what we > call address family here I guess. This can indeed happen if we have > different "families" that refer to the same network-layer protocol. exactly. We do not have it in the current draft because we currently only have two address families: IPv4 and IPv6. Then, you said that we may need to support different IPv6 address types. That is why we agreed to defining the global unicast IPv6 address family instead of simply IPv6 and add the source-in-send and destination-in-data stuff in case, in the future, somebody defines a new address IPv6-related address family. Cheers, Gonzalo _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 05:05:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtK7N-000189-Vh; Wed, 30 May 2007 05:05:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtK7N-000184-4U for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtK7M-00017t-P3 for behave@ietf.org; Wed, 30 May 2007 05:05:20 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtK7K-000700-9O for behave@ietf.org; Wed, 30 May 2007 05:05:20 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U951Ia007469; Wed, 30 May 2007 12:05:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:04:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:04:53 +0300 Received: from esdhcp04057.research.nokia.com ([172.21.40.57]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 12:04:53 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: "ext Gonzalo Camarillo" Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Wed, 30 May 2007 12:05:16 +0300 User-Agent: KMail/1.9.6 References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300944.12843.remi.denis-courmont@nokia.com> <465D3078.4070704@ericsson.com> In-Reply-To: <465D3078.4070704@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705301205.16696.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 30 May 2007 09:04:53.0204 (UTC) FILETIME=[95E7C940:01C7A299] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Behave WG , ext Philip Matthews , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Wednesday 30 May 2007 11:06:16 ext Gonzalo Camarillo wrote: > Hi, > > > Ok, I might be confused because I do not know how you intend to spell it > > in the next draft. We really need source-in-send if (and only if) there > > is more than one address the server can use for a destination. So it > > depends what we call address family here I guess. This can indeed happen > > if we have different "families" that refer to the same network-layer > > protocol. > > exactly. We do not have it in the current draft because we currently > only have two address families: IPv4 and IPv6. Then, you said that we > may need to support different IPv6 address types. That is why we agreed > to defining the global unicast IPv6 address family instead of simply > IPv6 and add the source-in-send and destination-in-data stuff in case, > in the future, somebody defines a new address IPv6-related address family. Right. Then it might make sense to not abuse the term "family". I tend to=20 associate that with socket protocol/address family and OSI layer-3, hence t= he=20 confusion. That's also how the base TURN spec uses it currently. So any oth= er=20 word as category, type, class, label, species, you-name-it, whatever-else=20 maybe?? =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 09:57:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtOg4-0007CP-S6; Wed, 30 May 2007 09:57:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtOg2-0007C9-RY for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 09:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtOg2-0007C1-Hs for behave@ietf.org; Wed, 30 May 2007 09:57:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtOfr-0001qw-2C for behave@ietf.org; Wed, 30 May 2007 09:57:26 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 83D0920219; Wed, 30 May 2007 15:57:14 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-59-465d82ba69d3 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 724902009D; Wed, 30 May 2007 15:57:14 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:57:14 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 15:57:13 +0200 Message-ID: <465D82B9.8040503@ericsson.com> Date: Wed, 30 May 2007 15:57:13 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: [BEHAVE] NAT Control STUN Usage References: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> <8BA6D352-586B-42A6-8D35-D433DFB57BA6@magma.ca> <45F90788.6010502@ericsson.com> In-Reply-To: <45F90788.6010502@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 May 2007 13:57:13.0781 (UTC) FILETIME=[6CE76E50:01C7A2C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: behave@ietf.org, Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus Westerlund skrev: > Philip Matthews skrev: >> Sorry to be coming into this conversation late. >> I am just catching up on various mailing lists after finishing my drafts. >> >> BEHAVE is chartered to work on STUN. >> STUN requires STUN servers to work, and defined how they behave. >> Why shouldn't we recommend placing some of the servers into NATs >> as this draft does? >> >> This draft is trying to address the problem of finding the allocated >> mappings >> for nested NAT cases. I think this problem is an important one to solve, >> because nested NATs are becoming more and more common. >> >> I think BEHAVE is a good place to work on a solution to this problem, >> and I think the proposed solution is reasonable. >> >> I think it would be silly to NOT solve this problem just because of >> charter issues. >> > > The problem is that large parts of this problem already has been solved > in the numerous NAT control protocols. Even in IETF we have two > different WG currently chartered with solving NAT control issues, MIDCOM > and NSIS. Going in this new direction for BEHAVE needs IETF wide > consensus and also good arguments why previous efforts are not solving > the problem. So if you are interested in this issue, please get together > and start discussing having a BOF. > Hi, Dan has requested a BOF on this topic. But I still haven't seen much debate why we would need something other than what is already under development within the IETF. I would appreciate some discussion and clarification before making any decision if there should be an BOF or not. Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 10:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPdj-0006c0-OD; Wed, 30 May 2007 10:59:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtPdi-0006bm-Me for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 10:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPdi-0006be-7g for behave@ietf.org; Wed, 30 May 2007 10:59:06 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtPdh-0005VC-62 for behave@ietf.org; Wed, 30 May 2007 10:59:06 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4UEwv9W002444; Wed, 30 May 2007 17:58:57 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 17:58:56 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 17:58:56 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Wed, 30 May 2007 17:58:55 +0300 Message-ID: In-Reply-To: <465D82B9.8040503@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] NAT Control STUN Usage Thread-Index: AceiwoNlSHQDmUylSKG6h5EoqNHhCQABHgaA References: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> <8BA6D352-586B-42A6-8D35-D433DFB57BA6@magma.ca><45F90788.6010502@ericsson.com> <465D82B9.8040503@ericsson.com> From: To: X-OriginalArrivalTime: 30 May 2007 14:58:56.0490 (UTC) FILETIME=[0BE3FCA0:01C7A2CB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: behave@ietf.org, philip_matthews@magma.ca, dwing@cisco.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I think STUN NAT control would be very valuable. Explicit NAT/FW control in general is important especially for wireless devices, where keepalives (especially for UDP) are really bad for battery consumption. This is not just a nice-to-have optimization, but I believe that in practice you could not use Internet-based VoIP/IM services over e.g. HSDPA or WiMAX, if you had to do the keepalives in the current way. =20 What makes STUN interesting compared to e.g. NSIS is its incremental deployment path. STUN is already supported in many SIP and XMPP clients, and the popularity is increasing. An existing STUN client implementation can be relatively easily extended to support NAT control as well (small thing compared to e.g. full ICE support). STUN NAT control would then very well fit into the process how STUN is otherwise used, so the cost would be quite small even if there were no STUN-capable NATs on client's path. STUN-capable NATs could then be gradually deployed to improve the situation. Frankly, I don't see a similar deployment potential for NSIS. In comparison to UPnP STUN has certain technical benefits like the ability to deal with nested NATs. Also, UPnP is quite limited to local area use and would not solve the wide-area wireless access issue I mentioned in the beginning. To have best possible value, I think STUN NAT control should also have a way to deal with firewalls without NATs, i.e. there would have to be a way to discover if there are STUN capable firewalls on the path. Of course, the more we add to the protocol the less obvious the incremental deployment argument becomes. So, in summary: This is a pressing problem. None of the existing solutions look promising for getting deployed. STUN NAT control has certain aspects that would make the deployment more incremental and thus easier. Thus, I am very supportive for the approval of the BoF. Regards, Markus=20 =20 >-----Original Message----- >From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 >Sent: 30 May, 2007 16:57 >To: Magnus Westerlund >Cc: behave@ietf.org; Philip Matthews; Dan Wing >Subject: Re: [BEHAVE] NAT Control STUN Usage > >Magnus Westerlund skrev: >> Philip Matthews skrev: >>> Sorry to be coming into this conversation late. >>> I am just catching up on various mailing lists after=20 >finishing my drafts. >>> >>> BEHAVE is chartered to work on STUN. >>> STUN requires STUN servers to work, and defined how they behave. >>> Why shouldn't we recommend placing some of the servers into NATs as=20 >>> this draft does? >>> >>> This draft is trying to address the problem of finding the=20 >allocated=20 >>> mappings for nested NAT cases. I think this problem is an important=20 >>> one to solve, because nested NATs are becoming more and more common. >>> >>> I think BEHAVE is a good place to work on a solution to=20 >this problem,=20 >>> and I think the proposed solution is reasonable. >>> >>> I think it would be silly to NOT solve this problem just because of=20 >>> charter issues. >>> >>=20 >> The problem is that large parts of this problem already has been=20 >> solved in the numerous NAT control protocols. Even in IETF=20 >we have two=20 >> different WG currently chartered with solving NAT control issues,=20 >> MIDCOM and NSIS. Going in this new direction for BEHAVE needs IETF=20 >> wide consensus and also good arguments why previous efforts are not=20 >> solving the problem. So if you are interested in this issue, please=20 >> get together and start discussing having a BOF. >>=20 > >Hi, > >Dan has requested a BOF on this topic. But I still haven't=20 >seen much debate why we would need something other than what=20 >is already under development within the IETF. I would=20 >appreciate some discussion and clarification before making any=20 >decision if there should be an BOF or not. > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 13:31:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtS1R-0002W0-1i; Wed, 30 May 2007 13:31:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtS1P-0002Ve-Qn for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 13:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtS1P-0002VR-GQ for behave@ietf.org; Wed, 30 May 2007 13:31:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtS1O-0001Fk-5r for behave@ietf.org; Wed, 30 May 2007 13:31:43 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2007 13:31:41 -0400 X-IronPort-AV: i="4.14,594,1170651600"; d="scan'208"; a="61519972:sNHT167662748" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4UHVfU7004583; Wed, 30 May 2007 13:31:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4UHVfBk007416; Wed, 30 May 2007 17:31:41 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 13:31:34 -0400 Received: from 10.86.115.72 ([10.86.115.72]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2007 17:31:33 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 30 May 2007 13:31:38 -0400 Subject: Re: [BEHAVE] NAT Control STUN Usage From: Melinda Shore To: Magnus Westerlund Message-ID: Thread-Topic: [BEHAVE] NAT Control STUN Usage Thread-Index: Acei4GCTnxvYcA7TEdy+zwAKleNSdA== In-Reply-To: <465D82B9.8040503@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 May 2007 17:31:34.0113 (UTC) FILETIME=[5E425D10:01C7A2E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1478; t=1180546301; x=1181410301; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20 |To:=20Magnus=20Westerlund=20; bh=PsVVI+ymxcIlxv7m7IV63QTLlCYo8CM/v6aGhq+Qkb8=; b=k/sG6DMw/Qy0EiMaQiMoH4pGcyZYc0nHvAMaOlfMxiNdzuh6ut4s5ADzClopcB0VpfAdtnjT tXACih9e2vBDG1ZXYtBZlFKu49KYLoGpXMoz0qJGbaKP1D+UBEf131WE; Authentication-Results: rtp-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: behave@ietf.org, Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 5/30/07 9:57 AM, "Magnus Westerlund" wrote: > Dan has requested a BOF on this topic. But I still haven't seen much > debate why we would need something other than what is already under > development within the IETF. I would appreciate some discussion and > clarification before making any decision if there should be an BOF or not. It seems dubious to me that yet another on-path signaling protocol is needed, or particularly that yet another on-path NAT signaling protocol is needed, when the problems that limit the deployability of any on-path NAT signaling protocol in the first place remain unsolved. I initially brought the on-path firewall/NAT signaling work to the IETF lo, those many years ago because it solves some hard problems around topology and ordering. Unfortunately, however, it requires that at least one end of a "path" not be NATted, and that either or both peers know that it's not NATted. The solutions that have been proposed (when they've been proposed - there's been a lot of hand-waving) are often worse than the problem, involving throwing new elements into the network or sending out an effectively unbounded number of messages to do discovery. The on-path stuff is extremely appealing but I think there are some difficult problems that need to be solved before it can be deployed, and it seems to me that it ought to be deployable before developing a redundant protocol. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 16:54:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVBW-0000yO-1S; Wed, 30 May 2007 16:54:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtVBV-0000yJ-0h for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 16:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVBU-0000yB-N5 for behave@ietf.org; Wed, 30 May 2007 16:54:20 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVBQ-00033e-El for behave@ietf.org; Wed, 30 May 2007 16:54:20 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HtVBP-0002S1-2v; Wed, 30 May 2007 16:54:16 -0400 In-Reply-To: <465D1875.3070004@ericsson.com> References: <001101c79383$4510db80$c5f0200a@amer.cisco.com> <200705300907.06853.remi.denis-courmont@nokia.com> <465D1541.6070309@ericsson.com> <200705300919.59054.remi.denis-courmont@nokia.com> <465D1875.3070004@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: Multiple allocated addresses per TURN allocation WAS (Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt) Date: Wed, 30 May 2007 16:54:11 -0400 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Behave WG , ext Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org My concern about the SourceAddress and DestinationAddress attributes =20 is partly overhead and partly additional complexity in TURN. The first could be addressed by enhancing the SetActiveDestination =20 indication to specify the default sending/receiving address so that =20 these attributes can be eliminated once the ICE connectivity checks =20 are finished. The second is just because I see STUN and TURN as getting more and =20 more complex to handle marginal cases. Personally, I don't see a reasonable use-case for a TURN relay with =20 more than one IPv4 address and one IPv6 address. Unless, some can =20 present one, I suggest we design for that case and not insert things =20 that are only really useful in future cases that currently seem =20 unlikely. As suggested below, it might be possible to infer the address of the =20 TURN-relay-to-destination portion of the path from the address or =20 header used on the TURN relay-to-client portion of the path. I am =20 not convinced this is really foolproof, but if it is, then I think =20 this is might be a simpler solution than defining the new attributes. - Philip On 30-May-07, at 02:23 , Gonzalo Camarillo wrote: > Hi, > > we agreed on defining the address family as Global IPv6 Unicast =20 > Address. If, in the future, we decide to define new families (as =20 > you pointed out), we will need the source-in-send and destination-=20 > in-data. Therefore, I suggest we are explicit from the beginning =20 > and add them from day one. > > This was my understanding of our discussions, actually. > > Cheers, > > Gonzalo > > R=E9mi Denis-Courmont wrote: >> On Wednesday 30 May 2007 09:10:09 ext Gonzalo Camarillo wrote: >>> Hi, >>> >>>> I do not have any very strong opinion. One option would be to =20 >>>> enforce a >>>> single >>>> server address per family and per allocation; >>> I believe we have rough consensus on using a single address per =20 >>> family, >>> and on having the possibility of having multiple addresses per =20 >>> allocation. >> Fine, then source-in-Send and destination-in-Data are not really =20 >> needed. > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 17:24:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVeQ-0008Rh-0q; Wed, 30 May 2007 17:24:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtVeN-0008Q4-Or for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 17:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVeN-0008Pw-Ex for behave@ietf.org; Wed, 30 May 2007 17:24:11 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVeK-0006Db-US for behave@ietf.org; Wed, 30 May 2007 17:24:11 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HtVeK-0005QQ-1x; Wed, 30 May 2007 17:24:08 -0400 In-Reply-To: <465D82B9.8040503@ericsson.com> References: <0e0801c75aba$9089b7f0$5600a8c0@Quinthar> <8BA6D352-586B-42A6-8D35-D433DFB57BA6@magma.ca> <45F90788.6010502@ericsson.com> <465D82B9.8040503@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77E74F57-DB15-4C83-935C-C9D93B71116B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Wed, 30 May 2007 17:24:04 -0400 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 30-May-07, at 09:57 , Magnus Westerlund wrote: > Magnus Westerlund skrev: > > Hi, > > Dan has requested a BOF on this topic. But I still haven't seen > much debate why we would need something other than what is already > under development within the IETF. I would appreciate some > discussion and clarification before making any decision if there > should be an BOF or not. There are two parts to the problem: Discovering nested NATs and Controlling NATs. The Discovery part, in my opinion, is the most basic and more important part of this work. This allows ICE to work in cases where another NAT does not support hairpinning, and allows ICE to find a more efficient path in cases where the NATs involve do support hairpinning. The discovery portion is also the most straight-forward part of the problem, as I don't think it raises any additional security concerns. The Control part is also useful, but it requires the Discovery portion, raises some security questions and seems to be the controversial aspect. So I think the debate should be: Do we do Discovery+Control, or just start with the Discovery part? I do not object to doing Discover+Control, but I don't want to lose the Discovery just because we tried to do the Control part. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed May 30 17:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVmu-00065z-Cn; Wed, 30 May 2007 17:33:00 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtVmt-00065q-HM for behave-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 17:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtVmt-00065g-7a for behave@ietf.org; Wed, 30 May 2007 17:32:59 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtVmr-0004Zm-LA for behave@ietf.org; Wed, 30 May 2007 17:32:59 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HtVmr-0001KN-14; Wed, 30 May 2007 17:32:57 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CF4789A-F640-4045-9E9F-7CAC07C9F8A4@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Wed, 30 May 2007 17:32:34 -0400 To: Melinda Shore X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 30-May-07, at 13:31 , Melinda Shore wrote: > On 5/30/07 9:57 AM, "Magnus Westerlund" > > wrote: >> Dan has requested a BOF on this topic. But I still haven't seen much >> debate why we would need something other than what is already under >> development within the IETF. I would appreciate some discussion and >> clarification before making any decision if there should be an BOF >> or not. > > It seems dubious to me that yet another on-path signaling protocol is > needed, or particularly that yet another on-path NAT signaling > protocol > is needed, when the problems that limit the deployability of any > on-path NAT signaling protocol in the first place remain unsolved. I would be interested in hearing what you see as the deployment problems. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 08:08:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjS3-0001iw-24; Thu, 31 May 2007 08:08:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtjS1-0001i9-GR for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 08:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtjS1-0001hK-6I for behave@ietf.org; Thu, 31 May 2007 08:08:21 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtjRz-0004U3-Nr for behave@ietf.org; Thu, 31 May 2007 08:08:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4VC85sT010429; Thu, 31 May 2007 15:08:14 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 15:07:54 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 15:07:53 +0300 Received: from esdhcp04063.research.nokia.com ([172.21.40.63]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 15:07:54 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Thu, 31 May 2007 15:08:17 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705311508.17791.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 31 May 2007 12:07:54.0045 (UTC) FILETIME=[5168E6D0:01C7A37C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Wednesday 30 May 2007 20:31:38 ext Melinda Shore wrote: > It seems dubious to me that yet another on-path signaling protocol is > needed, STUN has already running on the real-life Internet for quite a while. This= =20 usage leverage and extend on that. STUN makes a lot of sense particularly in ICE context given clients have to= =20 have it anyway, and the added complexity is minimal. > or particularly that yet another on-path NAT signaling protocol=20 > is needed, Only real-life NAT control protocols are UPnP (bloated and buggy protocol=20 designed outside IETF) and NAT-PMP. Both are unable to accomodate multiple= =20 hops, as STUN does. > when the problems that limit the deployability of any=20 > on-path NAT signaling protocol in the first place remain unsolved. Well, you do have to upgrade the NAT boxes to support the protocol. Though= =20 STUN has the interesting property that it still provides added value even i= f=20 not all of the on-path NATs supports it: it still lets you discover=20 intermediate NAT address bindings, for use in ICE or similar connectivity=20 frameworks. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 09:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkqN-00012c-FN; Thu, 31 May 2007 09:37:35 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtkqM-00012R-FF for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 09:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtkqM-00012J-5Y; Thu, 31 May 2007 09:37:34 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtkqI-0005Ej-Gu; Thu, 31 May 2007 09:37:34 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 31 May 2007 06:37:30 -0700 X-IronPort-AV: i="4.14,598,1170662400"; d="scan'208"; a="159417858:sNHT46795500" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l4VDbThc025078; Thu, 31 May 2007 06:37:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4VDbTV1025672; Thu, 31 May 2007 13:37:29 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 06:37:29 -0700 Received: from [10.32.241.149] ([10.32.241.149]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 06:37:29 -0700 Message-ID: <465ECF97.9080208@cisco.com> Date: Thu, 31 May 2007 09:37:27 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Matthews Subject: Re: [BEHAVE] A question on draft-ietf-mmusic-ice-15 References: <043a01c79e85$64e8dd10$c6f0200a@amer.cisco.com> <0F2C075D-A4CF-4287-A228-CF2979624B30@magma.ca> In-Reply-To: <0F2C075D-A4CF-4287-A228-CF2979624B30@magma.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 May 2007 13:37:29.0122 (UTC) FILETIME=[D5349020:01C7A388] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3361; t=1180618649; x=1181482649; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20A=20question=20on=20draft-ietf-mmusic-ice- 15 |Sender:=20; bh=JrENpEqluXNCn2izJrc1tVJOevfvrHLcOUoKcyRleU8=; b=hD9zR2LywnivPfVfxTscY2SsgmCEqMO8+VkHjkP2GxVHcN9XFCek1ienMv3eX9pJT57m8pju fVgJfDJ/8gkegtve/sVshp5IHeTyDbN2QkroD3sJAmZ38Co6zv82Blf2; Authentication-Results: sj-dkim-5; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: behave@ietf.org, mmusic@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org To be clear - there is no special behavior required from the endpoint connected to the TURN server for this to work. The ICE processing defined in the specification will cause an endpoint to naturally send connectivity checks which open up permissions. SetActiveDestination is not required and would not need to be used for this purpose. Thanks, Jonathan R. Philip Matthews wrote: > > On 25-May-07, at 00:30 , Dan Wing wrote: > >>>> TURN's Set Active Destination accomplishes that. See >>>> http://tools.ietf.org/html/draft-ietf-behave-turn-03#section-6.3.2 >>> >>> >>> Thanks for your reply. Besides Set Active Destination, there >>> are some other methods could do the same thing, such as Open, >>> Send indications. >>> >>> Do we need to add more text to ICE draft and say that "before >>> connectivity check begins, agent A should create permission >>> for Relayed address in order to allow connectivity check's >>> packet from other agent through the NAT and reach the agent. >>> A"? >> >> >> It's not necessary -- the combination of the triggered checks >> and retries by the answerer cause the permission and the >> connectivity check to complete as soon as the permission is >> created. > > > Just a bit more clarification here. > > "Set Active Destination" is one way to install a filtering entry for the > remote peer in the TURN server, but there is another way. > > Consider two peers, L and R, which are behind different NATs. > L uses a TURN server T. > > If R sends a connectivity check to L's allocated address on T > before anything else happens, then you are correct that T will > discard the packet. However, this will install a filtering entry > into R's local NAT. > Then when L sends a connectivity check from T towards R, > this will install a filtering entry on T for R, and this connectivity > check packet will also get through R's NAT because of the > previously installed filtering entry. > > If the order is reversed (L sends first), then a connectivity check > from L's allocated address on T towards R will be dropped by > R's NAT, but will install a filtering entry on T. > Then when R sends a connectivity check from R to L's address > on T, this connectivity check will get through because of the > previously installed filtering entry on T. > > > To summarize: > If R sends first, then its connectivity check packets get dropped > by T until L sends its first packet towards R. > If L sends first, then its connectivity check packets get dropped > by R's NAT until R sends its first packet towards L's address on T. > > In other words, the packets do not get through until both ends try > to send. This is the reason that ICE defines a priority function for > candidate pairs -- so both ends will send checks at approximately > the same time. > > - Philip > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 10:59:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htm7F-0002zd-IB; Thu, 31 May 2007 10:59:05 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Htm7D-0002zL-Uz for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 10:59:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htm7D-0002zD-LK for behave@ietf.org; Thu, 31 May 2007 10:59:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htm7C-0007nW-2z for behave@ietf.org; Thu, 31 May 2007 10:59:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 31 May 2007 07:59:00 -0700 X-IronPort-AV: i="4.14,599,1170662400"; d="scan'208"; a="3542933:sNHT2879119320" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4VEwx7Y017693; Thu, 31 May 2007 07:58:59 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4VEwltj010996; Thu, 31 May 2007 14:58:59 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 10:58:44 -0400 Received: from 10.86.115.72 ([10.86.115.72]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2007 14:58:44 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 10:58:48 -0400 Subject: Re: [BEHAVE] NAT Control STUN Usage From: Melinda Shore To: Philip Matthews Message-ID: Thread-Topic: [BEHAVE] NAT Control STUN Usage Thread-Index: AcejlDE+b/UODg+HEdy+zwAKleNSdA== In-Reply-To: <7CF4789A-F640-4045-9E9F-7CAC07C9F8A4@magma.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2007 14:58:44.0941 (UTC) FILETIME=[2F6B7FD0:01C7A394] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3765; t=1180623539; x=1181487539; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=92WI+rbEOH7FVheR6z9/S9cv814KUeM9afoIJ+FeINA=; b=MWGZTx3M+RUex5+mSEKbGTl9Ow8+hFfSB8W72dp9JvzP2vCiqP8/VHFOABmpJg6svwlmrmkj k67CFYQT6twM/aHPLndw2oY7XAUmcLyxxIs0UPX7nLqST+nOGxPuE0hY; Authentication-Results: sj-dkim-3; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 5/30/07 5:32 PM, "Philip Matthews" wrote: > I would be interested in hearing what you see as the deployment > problems. Sure: You need to have something that can turn the message around and provide a reply, or else you need to receive responses back from the middleboxes. The first option is unreliable and the second option leads to the possibilities of message proliferation and message expansion (since you can no longer rely on packet rewriting as a way of propagating topological information). You need to have some way to secure messages when you don't know in advance who you'll be sending messages to/receiving messages from, and you'll be doing it in situations where you're trying to limit packet size (avoid UDP fragmentation) and limit computational load (public key operations in a middlebox). We found that group keys are an excellent solution for use within a single security domain, but are obviously unsuitable for use in situations in which you might be crossing arbitrary administrative boundaries and can't know in advance who they'll be. One end or the other end has to have a public address/presence. If neither end has a public address or presence, that presence has to be outsourced to some other device. That often means dropping yet another box (a relay, for example) into both ends of the network. The placement of the relay has to be topologically appropriate to the endpoints or else the relay ends up being a sort of SBC. If you do go with a relay, you have to have some way to associate it with the endpoint and you have to have some way to publicize the association. The way that's typically handled right now is through telephony signaling. In fact, this whole thing is looking an awful lot like a VoIP network, and it's not actually very useful for other applications. (Presumably that's the reason for an interest in using STUN rather than an actual signaling protocol, as well). It's doable, but it's not doable in a general way and it's really going to work only in very constrained environments. It's not an 80/20 solution, but rather a 20/80 one. And, by the way, STUN would probably need substantial changes to the protocol machinery in order to handle state maintenance. Packetization is really not that interesting (a little interesting, but not a lot) - what matters is how the protocol behaves. "NAT control" installs state in middleboxes - you'll need to be able to handle errors like transmission failures, device reboots, routing changes, and so on. You'll also need to be able to delete the state you install. By the time you're done tweaking it so that it will be a useful state maintenance tool you'll have a full-blown signaling protocol, only a quirky one that's not very general and probably isn't very different from other signaling protocols aside from packetization. (FWIW, a few years ago I wrote up a "STUN-based Signaling" specification that uses the NLS state machine but STUN packetization, and there should still be copies floating around ID archives - it solves a political problem but not a technical one and was rightly ignored). I could accept (and do accept) the argument that NSIS is not a good choice for situations in which the substantial set up costs can't be amortized well, but that's not the argument that's being presented here. Anyway, the broader point is that we've already done on-path signaling six ways from Sunday and the hard problems association with NAT signaling remain unsolved. I have a hard time seeing why it's a good idea to create yet another protocol while continuing to avoid dealing with the problems associated with the architecture. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 14:12:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htp8R-0006Mw-FO; Thu, 31 May 2007 14:12:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Htp8Q-0006Mm-Sw for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 14:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htp8Q-0006Md-J8 for behave@ietf.org; Thu, 31 May 2007 14:12:30 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htp8Q-00066R-7A for behave@ietf.org; Thu, 31 May 2007 14:12:30 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1Htp8Q-0007Pt-5A; Thu, 31 May 2007 14:12:30 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A2592B1-22EC-472A-8A4F-BEAB2F757993@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Thu, 31 May 2007 14:12:27 -0400 To: Melinda Shore X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Thanks for detailed response! However, I am not sure I really understand all your points. See inline. On 31-May-07, at 10:58 , Melinda Shore wrote: > On 5/30/07 5:32 PM, "Philip Matthews" > wrote: >> I would be interested in hearing what you see as the deployment >> problems. > > Sure: > > You need to have something that can turn the message around and > provide a reply, or else you need to receive responses back from > the middleboxes. The first option is unreliable and the second > option leads to the possibilities of message proliferation and > message expansion (since you can no longer rely on packet rewriting > as a way of propagating topological information). If I understand you correctly, STUN currently takes the first approach by requiring a STUN server somewhere in the network. And you consider this unreliable because there is nothing that forces someone to provide a STUN server? Do I understand you correctly? > > You need to have some way to secure messages when you don't > know in advance who you'll be sending messages to/receiving > messages from, and you'll be doing it in situations where you're > trying to limit packet size (avoid UDP fragmentation) and limit > computational load (public key operations in a middlebox). We > found that group keys are an excellent solution for use within > a single security domain, but are obviously unsuitable for use > in situations in which you might be crossing arbitrary administrative > boundaries and can't know in advance who they'll be. In the STUN case, I think you are referring to the various attacks against STUN. Some, but not all, of them are mitigated by the Shared Secret exchange, but in practice not many people seem to implement this. > > One end or the other end has to have a public address/presence. > If neither end has a public address or presence, that presence > has to be outsourced to some other device. That often means > dropping yet another box (a relay, for example) into both ends > of the network. The placement of the relay has to be topologically > appropriate to the endpoints or else the relay ends up being > a sort of SBC. > > If you do go with a relay, you have to have some way to associate > it with the endpoint and you have to have some way to publicize the > association. The way that's typically handled right now is through > telephony signaling. In fact, this whole thing is looking an > awful lot like a VoIP network, and it's not actually very useful > for other applications. (Presumably that's the reason for an > interest in using STUN rather than an actual signaling protocol, > as well). > > It's doable, but it's not doable in a general way and it's really > going to work only in very constrained environments. It's not an > 80/20 solution, but rather a 20/80 one. > > And, by the way, STUN would probably need substantial changes > to the protocol machinery in order to handle state maintenance. > Packetization is really not that interesting (a little interesting, > but not a lot) - what matters is how the protocol behaves. "NAT > control" installs state in middleboxes - you'll need to be able > to handle errors like transmission failures, device reboots, > routing changes, and so on. You'll also need to be able to delete > the state you install. By the time you're done tweaking it so > that it will be a useful state maintenance tool you'll have a > full-blown signaling protocol, only a quirky one that's not > very general and probably isn't very different from other signaling > protocols aside from packetization. (FWIW, a few years ago I > wrote up a "STUN-based Signaling" specification that uses the NLS > state machine but STUN packetization, and there should still be > copies floating around ID archives - it solves a political problem > but not a technical one and was rightly ignored). > > I could accept (and do accept) the argument that NSIS is not a > good choice for situations in which the substantial set up costs > can't be amortized well, but that's not the argument that's being > presented here. I confess I didn't understand the above points. Perhaps you misunderstand what Dan is proposing to do with STUN? All he is proposing (as far as I know), is to discover the binding that a NAT has installed for a particular local host and port, and then either query the NAT for the timeout value associated with the binding, or suggest a value to the NAT. He is NOT proposing to use STUN to signal the connection, and the only other involvement of STUN will be as part of ICE to select a path for the media. Or perhaps is it just me that is all confused? - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 14:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htpk7-00046p-Fy; Thu, 31 May 2007 14:51:27 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Htpk6-00046k-HO for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 14:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htpk6-00046Z-7W for behave@ietf.org; Thu, 31 May 2007 14:51:26 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htpk4-0008Uo-SW for behave@ietf.org; Thu, 31 May 2007 14:51:26 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-3.cisco.com with ESMTP; 31 May 2007 11:51:24 -0700 X-IronPort-AV: i="4.14,599,1170662400"; d="scan'208"; a="489691625:sNHT46461660" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4VIpOnJ027749; Thu, 31 May 2007 11:51:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4VIp50K024945; Thu, 31 May 2007 18:51:23 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 14:51:17 -0400 Received: from 10.86.115.72 ([10.86.115.72]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Thu, 31 May 2007 18:51:17 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 14:51:20 -0400 Subject: Re: [BEHAVE] NAT Control STUN Usage From: Melinda Shore To: Philip Matthews Message-ID: Thread-Topic: [BEHAVE] NAT Control STUN Usage Thread-Index: AcejtK1I7BIwvg+nEdyhPwAKleNSdA== In-Reply-To: <1A2592B1-22EC-472A-8A4F-BEAB2F757993@magma.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 May 2007 18:51:17.0550 (UTC) FILETIME=[ABD2ACE0:01C7A3B4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1925; t=1180637484; x=1181501484; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=kLt2CG9xDSbpSyuHJGe+P+fBM6JhYk2ggH81IRp3mD4=; b=qIXUXuhdik3GoNRDgzvQ9rlx8JhnK+a5ohe8rZ4MczxNiGCnBsE1k5DuNtwJzPC7KhI9iLST eJbxEQzEYzN2D+p8AOQaVOoe0pCDkUEM3SSfKhfsMJGie6ScZWwGaafH; Authentication-Results: sj-dkim-7; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 5/31/07 2:12 PM, "Philip Matthews" wrote: > If I understand you correctly, STUN currently takes the first approach > by requiring a STUN server somewhere in the network. And you consider > this unreliable because there is nothing that forces someone to provide > a STUN server? Do I understand you correctly? It forces the STUN server to be 1) addressable (not so much of an issue), and 2) in a topologically-appropriate location. Problem 2) has led to the development of ICE, about which the less is said the better. > Some, but not all, of them are mitigated by the Shared Secret exchange, > but in practice not many people seem to implement this. Well, on the one hand the exchange is of really limited utility since it doesn't prove identity, but on the other hand it's the only protection (other than obscurity) against an attacker. Explicit signaling is always going to be more secure, *if* you can authenticate the NAT. > All he is proposing (as far as > I know), > is to discover the binding that a NAT has installed for a particular > local host and port, > and then either query the NAT for the timeout value associated with > the binding, or suggest a value to the NAT. > He is NOT proposing to use STUN to signal the connection, and the > only other > involvement of STUN will be as part of ICE to select a path for the > media. Look, STUN was "just" going to be used until midcom was finished. And then it was "just" to be used in cases where a NAT cannot be modified. And then BEHAVE was "just" going to define NAT behavior so that STUN would work across it. And now it's "just" putting a STUN server inside a NAT so that a NAT is basically a midcom device. Take another look at the draft - it's *definitely* defining on-path signaling to NATs, and it's doing it without referencing existing on-path signaling protocols. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 15:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqkV-0007pT-DL; Thu, 31 May 2007 15:55:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtqkU-0007pJ-4I for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 15:55:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqkT-0007pB-Qs for behave@ietf.org; Thu, 31 May 2007 15:55:53 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtqkT-00067e-HS for behave@ietf.org; Thu, 31 May 2007 15:55:53 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1HtqkT-0000cY-Kh; Thu, 31 May 2007 15:55:53 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D0AB88A-3A04-4E74-BAC1-E29E3D7F530E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [BEHAVE] NAT Control STUN Usage Date: Thu, 31 May 2007 15:55:50 -0400 To: Melinda Shore X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: behave@ietf.org, Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 31-May-07, at 14:51 , Melinda Shore wrote: > On 5/31/07 2:12 PM, "Philip Matthews" > wrote: >> If I understand you correctly, STUN currently takes the first >> approach >> by requiring a STUN server somewhere in the network. And you consider >> this unreliable because there is nothing that forces someone to >> provide >> a STUN server? Do I understand you correctly? > > It forces the STUN server to be 1) addressable (not so much > of an issue), and 2) in a topologically-appropriate location. > Problem 2) has led to the development of ICE, about which the > less is said the better. I still don't understand. As I see it, the biggest advantage of Dan's draft is that allows a client to discover NATs, and thus STUN servers can be placed in the most topologically-appropriate location of all: namely, the NAT itself. > >> Some, but not all, of them are mitigated by the Shared Secret >> exchange, >> but in practice not many people seem to implement this. > > Well, on the one hand the exchange is of really limited utility > since it doesn't prove identity, but on the other hand it's the > only protection (other than obscurity) against an attacker. > Explicit signaling is always going to be more secure, *if* > you can authenticate the NAT. Though you dismissed ICE above, to my mind the advantage of ICE is that it solves a lot of the security problems of STUN. That is why I am less worried about the STUN security problems. > >> All he is proposing (as far as >> I know), >> is to discover the binding that a NAT has installed for a particular >> local host and port, >> and then either query the NAT for the timeout value associated with >> the binding, or suggest a value to the NAT. >> He is NOT proposing to use STUN to signal the connection, and the >> only other >> involvement of STUN will be as part of ICE to select a path for the >> media. > > Look, STUN was "just" going to be used until midcom was finished. And > then it was "just" to be used in cases where a NAT cannot be modified. > And then BEHAVE was "just" going to define NAT behavior so that STUN > would work across it. And now it's "just" putting a STUN server > inside a NAT so that a NAT is basically a midcom device. Take another > look at the draft - it's *definitely* defining on-path signaling to > NATs, and it's doing it without referencing existing on-path signaling > protocols. I agree that there is not much comparison with other approaches in the draft. In fact, I confess to be pretty ignorant of other approaches myself. I guess I should go and read some Midcom documents. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 17:35:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsIg-0004Yu-Bx; Thu, 31 May 2007 17:35:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtsIf-0004YH-3B for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsIe-0004Y7-Ox for behave@ietf.org; Thu, 31 May 2007 17:35:16 -0400 Received: from www.implementers.org ([69.55.225.91]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtsIc-0000ni-Qd for behave@ietf.org; Thu, 31 May 2007 17:35:16 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 1E3543A02022; Thu, 31 May 2007 14:35:14 -0700 (PDT) Received: from [192.168.1.3] (localhost.localdomain [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id C00263A02020; Thu, 31 May 2007 14:35:12 -0700 (PDT) Message-ID: <465F3F90.9080305@acm.org> Date: Thu, 31 May 2007 14:35:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070520) MIME-Version: 1.0 To: Melinda Shore Subject: Re: [BEHAVE] NAT Control STUN Usage References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: behave@ietf.org, Philip Matthews , Dan Wing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Melinda Shore wrote: [snip] > > Look, STUN was "just" going to be used until midcom was finished. And > then it was "just" to be used in cases where a NAT cannot be modified. > And then BEHAVE was "just" going to define NAT behavior so that STUN > would work across it. And now it's "just" putting a STUN server > inside a NAT so that a NAT is basically a midcom device. Take another > look at the draft - it's *definitely* defining on-path signaling to > NATs, and it's doing it without referencing existing on-path signaling > protocols. > Tiny little Behave mutates and grows and can potentially replace big Midcom . Looks to me as evolution applied to protocol engineering. It works for operating systems[1], why not for network protocols? [1] http://kerneltrap.org/node/11 -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu May 31 17:41:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsP1-00013E-7K; Thu, 31 May 2007 17:41:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HtsOz-000134-Pa for behave-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 17:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsOz-00012u-Fe for behave@ietf.org; Thu, 31 May 2007 17:41:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtsOu-0002BE-Pw for behave@ietf.org; Thu, 31 May 2007 17:41:49 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 May 2007 14:41:44 -0700 X-IronPort-AV: i="4.16,370,1175497200"; d="scan'208"; a="157155513:sNHT41040513" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4VLfiHJ009237 for ; Thu, 31 May 2007 14:41:44 -0700 Received: from dwingwxp ([10.32.240.195]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VLfd20006630 for ; Thu, 31 May 2007 21:41:41 GMT From: "Dan Wing" To: Date: Thu, 31 May 2007 14:41:37 -0700 Message-ID: <057b01c7a3cc$7af59840$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcejyI+COOBSwHDfT4WnzrwvPetIoA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1002; t=1180647704; x=1181511704; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20STUN=20Control-02 |Sender:=20; bh=ybr4TjycFZhY3Kk/ePhJaF8805hX/MBe3oWZY+4rGYA=; b=k7mVWGVnNn+N5ujnz49klDYluXbYJ9wpPv5jzHmVQGk9W08yecSgeO4RwPzvCj5t/YFr3MTj pGkO2qhTgIHojT/n/u2pUdbn1Z72DNKh838/5CgDJgbscw22FRyJnDL1pKt7niAykI4lXTsNFj E6S//DDV76Z3hBK8iIZ574CKI=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [BEHAVE] STUN Control-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Based on feedback received I have finished a substantial rewrite of STUN Control. The new document now more clearly separates STUN Control into three functions: * discovery (learn your NATs and firewalls) * query (ask them what they're doing) * control (ask them to do something different) I have added two new discovery mechanisms: an "inside-out" technique and a tagging technique (useful for finding firewalls, a new feature requested). I also clarified the previously-described "outside-in" technique. I just submitted this as a new Internet Draft, but in the meantime you can view the new version at the URLs below. Comments welcome. -d ----- HTML: http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-behave-nat-contr ol-stun-usage-02.html http://tinyurl.com/ypppg6 Text: http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-behave-nat-contr ol-stun-usage-02.txt http://tinyurl.com/2czkug Diffs: http://tinyurl.com/344wcb _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave