From behave-bounces@ietf.org Mon Jun 2 08:26:34 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F293A6BEF; Mon, 2 Jun 2008 08:26:34 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF173A6BEF for ; Mon, 2 Jun 2008 08:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLMzpMxCxL7q for ; Mon, 2 Jun 2008 08:26:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id A8A8F3A69F8 for ; Mon, 2 Jun 2008 08:26:26 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1K3BvS0kMp-00047y; Mon, 02 Jun 2008 11:26:23 -0400 Message-ID: <0b5001c8c4c5$2cc41af0$6401a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com> <2F0D498F-B9BC-4B53-A 570-281BC0D2CC91@nokia.com> <0ac701c8bb6d$c4076ef0$a25b150a@cisco.com> <09c701c8bc37$83bb4310$1496150a@cisco.com><4836DEE5.4070901@sipeerior.com><4836F52D.7030809@it.uc3m.es> <48370975.8040307@sipeerior.com> <0af801c8bd09$860355e0$d8e9520a@cisco.com> Date: Mon, 2 Jun 2008 10:27:28 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Provags-ID: V01U2FsdGVkX19vnqUrtw7B5oYU9BpoIJlz82nEbq6EiHnhc74 RoiJE2A82e/SyQg0JQIZL6s76KJ6y67JDY4R6rUN1DpO7Yb+pQ syPGuVJWWX/LCmRzs7eVZfs83yO92XQNJi4G/V9Ktw= Subject: Re: [BEHAVE] Dynamic Port Reuse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org If I understand him correctly, I just want to reinforce what Dan's saying here... We've been doing port-agile protocols for years. It just seems wrong to me that suddenly paying MORE attention to port numbers now is the right thing to do, especially if this algorithm gets stuck in the next generation of Linksys boxes that we then can't upgrade until the year 2525... Given that there is a positive incentive for protocols to lie ("of COURSE I'm HTTP, why else would I be running on port 80 where the firewalls are passing traffic"), I don't expect this to end well. I wish I had a better suggestion, of course. Spencer > Using port numbers is, itself, non-deterministic. This is because > no two people will generate the same list ports that are safe to > re-use. If ports are used, then in 3 years, as NAT64 vendors find > value in optimizing re-use of other port numbers, the vendors will > begin diverging which ports are re-used. > > For example, here would be my list of ports that are safe to re-use: > TCP/80 (HTTP), TCP/110 (POP3), TCP/995 (POP3S), TCP/143 (IMAP), TCP/587 > (SUBMIT), TCP/25 (SMTP), TCP/22 (SSH), TCP/21 (FTP), TCP/23 (TELNET), > TCP/7 (ECHO), TCP/9 (DISCARD), TCP/993 (IMAPS). > > Are there non-IETF protocols that are used which would break with > port re-use? That is, that use UNSAF or use TCP S-O? > > > As BitTorrent has not registered their ports with IANA, I'm not sure > what could be said in an IETF document about its ports other than > some non-normative "and other ports that the NAT64 believes, to the > best of its knowledge, are used by client/server applications that > can safely have their TCP source ports re-used." Which brings us > to specify non-deterministic behavior for such a NAT64. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 2 15:11:55 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F343A67B3; Mon, 2 Jun 2008 15:11:55 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCEE28C118 for ; Mon, 2 Jun 2008 15:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3v6aGUraRM9 for ; Mon, 2 Jun 2008 15:11:53 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id A68073A67A6 for ; Mon, 2 Jun 2008 15:10:20 -0700 (PDT) Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m52M8iWB082999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2008 00:08:45 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum To: Spencer Dawkins In-Reply-To: <0b5001c8c4c5$2cc41af0$6401a8c0@china.huawei.com> X-Priority: 3 References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com> <2F0D498F-B9BC-4B53-A 570-281BC0D2CC91@nokia.com> <0ac701c8bb6d$c4076ef0$a25b150a@cisco.com> <09c701c8bc37$83bb4310$1496150a@cisco.com><4836DEE5.4070901@sipeerior.com><4836F52D.7030809@it.uc3m.es> <48370975.8040307@sipeerior.com> <0af801c8bd09$860355e0$d8e9520a@cisco.com> <0b5001c8c4c5$2cc41af0$6401a8c0@china.huawei.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 3 Jun 2008 00:08:59 +0200 X-Mailer: Apple Mail (2.924) Cc: behave@ietf.org Subject: Re: [BEHAVE] Dynamic Port Reuse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 2 jun 2008, at 17:27, Spencer Dawkins wrote: > We've been doing port-agile protocols for years. It just seems wrong > to me > that suddenly paying MORE attention to port numbers now is the right > thing > to do, especially if this algorithm gets stuck in the next > generation of > Linksys boxes that we then can't upgrade until the year 2525... We're talking about NATs that must scale to support thousands of users by having more than 64k sessions per public IPv4 address... I don't think Linksys makes these. > Given that there is a positive incentive for protocols to lie ("of > COURSE > I'm HTTP, why else would I be running on port 80 where the firewalls > are > passing traffic"), I don't expect this to end well. In this case, there is no incentive for lying other than to do a denial of service on the NAT if the vendor didn't think to include per- user limits. Ideally, we'd create a bunch of port numbers for applications that don't need endpoint independent addressing and another bunch of port numbers for applications that do. Unfortunately most applications have already settled on a well known port. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 2 16:18:28 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 501F43A69A7; Mon, 2 Jun 2008 16:18:28 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AE03A68A9 for ; Mon, 2 Jun 2008 16:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPeZSpSef+Ea for ; Mon, 2 Jun 2008 16:18:26 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0D9F23A6840 for ; Mon, 2 Jun 2008 16:18:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,579,1204531200"; d="scan'208";a="75008398" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2008 16:18:28 -0700 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 m52NISWL009524; Mon, 2 Jun 2008 16:18:28 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m52NIR4s004006; Mon, 2 Jun 2008 23:18:27 GMT From: "Dan Wing" To: "'Lars Eggert'" References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com><2F0D498F-B9BC-4B53-A570-281BC0D2CC91@nokia.com><0ac701c8bb6d$c4076ef0$a25b150a@cisco.com>

<011AF26D-87D8-4F4D-9974-B74C6590F8CB@nokia.com> Date: Mon, 2 Jun 2008 16:18:26 -0700 Message-ID: <09af01c8c506$f6b26060$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <011AF26D-87D8-4F4D-9974-B74C6590F8CB@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci/C/B3su++eQA2SH6DR0uEyhCvBwF+lyOA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1310; t=1212448708; x=1213312708; 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:=20RE=3A=20[BEHAVE]=20Dynamic=20Port=20Reuse |Sender:=20; bh=0aE/cYPUESd/+ppg8SfsR1Ldx+iIgI7dS1yHCEgxV/g=; b=nBmyf+2+JF1x4FAN7pvM2t+NL4fVi0ELzUFC/VHZeW2Sv9St/7KkJyDFAE grKLEDmf99tyIw23qg16JQ9B6ldPnFBT1MnsOKCNFafUWqQqJJQC572tEOIS 2sX/nNH+hliNLzRfU8YRoyN7rHNGBXhkqkKrk/1aTp/pRmQTZCfzs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] Dynamic Port Reuse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Monday, May 26, 2008 1:38 AM, Lars Eggert wrote: > sure, but we might be able to free up IPv4 addresses that so > far have been allocated to end users and use them to support the > NAT64 boxes. Unless users end up having 65K connections active, the > NAT will be more efficient at multiplexing, and there'll be a win. > > I'm curious to know if you'd think that this scenario isn't realistic? If that scenario becomes the reality it is true that we would not need to worry about schemes to aggressively re-use TCP ports. I would expect that if an ISP changed to providing IPv6-only connectivity for its subscribers and installed some kind of NAT64 functionality so those subscribers could still get access to the v4 Internet, that ISP itself would have plenty of v4 addresses to assign to its newly-installed NAT64 boxes -- because it just freed a bunch of v4 addresses from its subscribers and can re-use those addresses on its NAT64 boxes. However, an ISP that does not already have a bunch of v4 addresses would need to obtain a bunch of v4 addresses for its newly-installed NAT64 boxes, and would be interested in reducing the number of v4 addresses it would need to obtain for those NAT64 boxes. Such an ISP would be interested in aggressive TCP port re-use. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 2 16:32:24 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4367A3A6972; Mon, 2 Jun 2008 16:32:24 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E593A67A5 for ; Mon, 2 Jun 2008 16:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyF2ryr-LNsc for ; Mon, 2 Jun 2008 16:32:08 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id AAEE53A6972 for ; Mon, 2 Jun 2008 16:32:08 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 2 Jun 2008 16:32:10 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.1.240.5; Mon, 2 Jun 2008 16:32:10 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Mon, 2 Jun 2008 16:31:42 -0700 From: Christian Huitema To: Dan Wing , 'Lars Eggert' Date: Mon, 2 Jun 2008 16:32:01 -0700 Thread-Topic: [BEHAVE] Dynamic Port Reuse Thread-Index: Aci/C/B3su++eQA2SH6DR0uEyhCvBwF+lyOAAACCUzA= Message-ID: <8EFB68EAE061884A8517F2A755E8B60A0A9D833CC4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com><2F0D498F-B9BC-4B53-A570-281BC0D2CC91@nokia.com><0ac701c8bb6d$c4076ef0$a25b150a@cisco.com>

<011AF26D-87D8-4F4D-9974-B74C6590F8CB@nokia.com> <09af01c8c506$f6b26060$c5f0200a@cisco.com> In-Reply-To: <09af01c8c506$f6b26060$c5f0200a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Dynamic Port Reuse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > However, an ISP that does not already have a bunch of v4 addresses would > need to obtain a bunch of v4 addresses for its newly-installed NAT64 > boxes, and would be interested in reducing the number of v4 addresses > it would need to obtain for those NAT64 boxes. Such an ISP would be > interested in aggressive TCP port re-use. So, if that is what we are focusing on, we should maybe say so. An IPv6 ISP has many options, and IPv6-IPv4 NAT is only one of them. For example, the ISP might run a Teredo relay, effectively reducing the pressure to use NAT translation for peer-to-peer applications. It may also run a 6to4 relay... -- Christian Huitema _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 2 17:02:19 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EB63A6840; Mon, 2 Jun 2008 17:02:19 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0113A6903 for ; Mon, 2 Jun 2008 17:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W3+tg5qK+rs for ; Mon, 2 Jun 2008 17:02:17 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 298503A67F3 for ; Mon, 2 Jun 2008 17:02:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,580,1204531200"; d="scan'208";a="75021133" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2008 17:02:19 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5302J4p004348; Mon, 2 Jun 2008 17:02:19 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5302IAR007823; Tue, 3 Jun 2008 00:02:18 GMT From: "Dan Wing" To: "'Christian Huitema'" , "'Lars Eggert'" References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com><2F0D498F-B9BC-4B53-A570-281BC0D2CC91@nokia.com><0ac701c8bb6d$c4076ef0$a25b150a@cisco.com>

<011AF26D-87D8-4F4D-9974-B74C6590F8CB@nokia.com> <09af01c8c506$f6b26060$c5f0200a@cisco.com> <8EFB68EAE061884A8517F2A755E8B60A0A9D833CC4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 2 Jun 2008 17:02:17 -0700 Message-ID: <0a4001c8c50d$16df5180$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: <8EFB68EAE061884A8517F2A755E8B60A0A9D833CC4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci/C/B3su++eQA2SH6DR0uEyhCvBwF+lyOAAACCUzAAARvHkA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=973; t=1212451339; x=1213315339; 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:=20RE=3A=20[BEHAVE]=20Dynamic=20Port=20Reuse |Sender:=20; bh=M62CJXTb8hQNMFXpT0lb47fpBzDqJfho20O74VSulXI=; b=r/gw42Llwh4xTQy9QQ6pKOp8EfZshlgVbL3fwEN40aW2yutltB6s8gpt3P R21L3rF4aOvcnPiLm5hZnB0+1G2MxyWWvSoFBVG5mBo3L8s0tLqtWytjVLpr bgEzogS2YHo21N40KdkpfngeiFDyQB/CGFEPUMh6eiNS5lQbu6Ick=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] Dynamic Port Reuse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > > However, an ISP that does not already have a bunch of v4 > > addresses would > > need to obtain a bunch of v4 addresses for its newly-installed NAT64 > > boxes, and would be interested in reducing the number of v4 > > addresses > > it would need to obtain for those NAT64 boxes. Such an ISP would be > > interested in aggressive TCP port re-use. > > So, if that is what we are focusing on, we should maybe say > so. An IPv6 ISP has many options, and IPv6-IPv4 NAT is only > one of them. For example, the ISP might run a Teredo relay, > effectively reducing the pressure to use NAT translation for > peer-to-peer applications. It may also run a 6to4 relay... Those seem reasonable approaches if the ISP's subscribers have v6-capable hosts. Or were you considering putting Teredo or 6to4 into the subscriber's CPE, so that a v4-only subscriber would -- unbeknownst to them -- be getting access to v4 via their CPE's new functionality? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 2 17:37:05 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096AC3A6A0A; Mon, 2 Jun 2008 17:37:05 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18683A6A14 for ; Mon, 2 Jun 2008 17:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YcxLd15AwS8 for ; Mon, 2 Jun 2008 17:37:03 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id E6C5A3A6A0A for ; Mon, 2 Jun 2008 17:36:53 -0700 (PDT) Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 2 Jun 2008 17:36:56 -0700 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.88.97) with Microsoft SMTP Server id 8.1.240.5; Mon, 2 Jun 2008 17:36:55 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Mon, 2 Jun 2008 17:36:55 -0700 From: Christian Huitema To: Dan Wing , 'Lars Eggert' Date: Mon, 2 Jun 2008 17:36:54 -0700 Thread-Topic: [BEHAVE] Dynamic Port Reuse Thread-Index: Aci/C/B3su++eQA2SH6DR0uEyhCvBwF+lyOAAACCUzAAARvHkAABNBlA Message-ID: <8EFB68EAE061884A8517F2A755E8B60A0A9D833D60@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com><2F0D498F-B9BC-4B53-A570-281BC0D2CC91@nokia.com><0ac701c8bb6d$c4076ef0$a25b150a@cisco.com>

X-Google-Sender-Auth: 916ed83045307f50 Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This mail tries to sum-up the conversations of the WGLC and makes proposals for a next update of the draft. 1 - 0 bytes packets: There's a need to merge sections 4.1 and 4.2 and to generalize the section for any RTP-capable transport protocol. 2 - static payload There is no consensus to accept a static payload number for rtp-keepalive, so the draft will keep a dynamic payload type. 3 - Advertisement of rtp-keepalive with SDP There's some interest to declare support for rtp-keepalive in the SDP. Do we want to make it mandatory or recommended? Note that doing so requires the registration of additional media types (like audio/rtp-keepalive, video/rtp-keepalive, and text/rtp-keepalive, application/rtp-keepalive). In addition, it should also be noted the indication for rtp-keepalive support within an SDP offer is a declarative usage only, as the the local agent will use rtp-keepalive even if the peer does not support this format in the SDP answer. 4 - Security issues There's a need to discuss that RTP keepalive packets may be perceived as an attack by the peer and that the peer needs to react as described by RFC3550 by ignoring them. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 3 08:37:23 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56BDB3A6B54; Tue, 3 Jun 2008 08:37:23 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776633A6B24 for ; Tue, 3 Jun 2008 08:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+IoxF7+DlM3 for ; Tue, 3 Jun 2008 08:37:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 581BC3A6BCA for ; Tue, 3 Jun 2008 08:37:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,584,1204531200"; d="scan'208";a="107783578" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Jun 2008 08:37:15 -0700 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 m53FbFME027431; Tue, 3 Jun 2008 08:37:15 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m53FbElO012405; Tue, 3 Jun 2008 15:37:14 GMT From: "Dan Wing" To: "'Christian Huitema'" , "'Lars Eggert'" References: <03f801c8b5e6$12d6ed40$c3f0200a@cisco.com><2F0D498F-B9BC-4B53-A570-281BC0D2CC91@nokia.com><0ac701c8bb6d$c4076ef0$a25b150a@cisco.com>

<011AF26D-87D8-4F4D-9974-B74C6590F8CB@nokia.com> <09af01c8c506$f6b26060$c5f0200a@cisco.com> <8EFB68EAE061884A8517F2A755E8B60A0A9D833CC4@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <0a4001c8c50d$16df5180$c5f0200a@cisco.com> <8EFB68EAE061884A8517F2A755E8B60A0A9D833D60@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 3 Jun 2008 08:37:13 -0700 Message-ID: <027701c8c58f$b2eb0100$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci/C/B3su++eQA2SH6DR0uEyhCvBwF+lyOAAACCUzAAARvHkAABNBlAAB9FUrA= In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A0A9D833D60@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=754; t=1212507435; x=1213371435; 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:=20RE=3A=20[BEHAVE]=20Dynamic=20Port=20Reuse |Sender:=20; bh=cOd26aCJyXLPqbXQp0AfcLREADQtjnf5vsWbs7d8Yzw=; b=d8fSXBFwTykHd64uXoZYJmBeYvFu31Hh6zEUudRT9Z2HiT8eUVMOdSyjE/ PQqbm5k3qN8nSNxxeebAfbPY+N2CmkagJtXUBQ3lxwiyk+u+XKUT/GgDWnzM kpMCD1AHgaQT850dvhASCFBTz8MT1MofIZtMJ7d2UP4Kc2BwtU/j8=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] Dynamic Port Reuse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > One has to assume that if an ISP is going "IPv6 only", a > significant fraction of its subscribers will be IPv6 capable. It is my understanding that many subscribers have equipment or application software that cannot become v6 capable (it cannot be upgraded, or the user does not want to upgrade it [cost, fear of upgrade, lack of a neighbor kid or nephew to assist with the upgrade]). > If that was not the case, one could question the business > sense of the ISP... The goal, as I understand it, is to provide subscribers a service that looks, feels, and smells like the subscriber's current v4 Internet service. In this way, the subscriber's current v4 hosts and applications will work in much the same way as today. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 3 11:27:16 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1712E28C1CF; Tue, 3 Jun 2008 11:27:16 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0499E3A6875 for ; Tue, 3 Jun 2008 11:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTQs6iUKFsFi for ; Tue, 3 Jun 2008 11:27:14 -0700 (PDT) Received: from mail.sipeerior.com (mail.sipeerior.com [128.239.5.131]) by core3.amsl.com (Postfix) with ESMTP id C5B4D28C1BA for ; Tue, 3 Jun 2008 11:25:39 -0700 (PDT) Received: from vuelta.local (unknown [128.239.5.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sipeerior.com (Postfix) with ESMTP id 40B9F505A88; Tue, 3 Jun 2008 14:25:42 -0400 (EDT) Message-ID: <48458C9F.7080005@sipeerior.com> Date: Tue, 03 Jun 2008 14:25:35 -0400 From: Bruce Lowekamp User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <483A7598.4030408@free.fr> <483B649A.4030307@sipeerior.com> In-Reply-To: Cc: Behave WG Subject: Re: [BEHAVE] Degree of compatibility of BitTorrent with endpoint-independent mapping? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Iljitsch van Beijnum wrote: > On 26 mei 2008, at 22:32, Bruce Lowekamp wrote: > >> To the best of my knowledge (and I have not studied BitTorrent >> implementations extensively), they don't try to make any allowances for >> NAT behavior because there are enough hosts for which that is not an >> issue that the applications work if they try enough connections. > > No, that's not exactly true. In practice, you get much lower download > speeds with BitTorrent if you can't accept incoming connections. So > (some) clients implement UPnP and NAT-PMP to open up ports for incoming > sessions in the NAT, if present. It's also very common for BitTorrent > users to set up a mapping manually. > > So BitTorrent does often use NAT traversal, just not with any of the > mechanisms that the IETF is familiar with. :-) > You're right, I was thinking about techniques other than NAT control. More importantly, though, neither of those techniques work with multi-level NATs (or NATs on the other side of routers), so aren't really appropriate for the problem domain we're talking about here, as I understand it. Now I suppose we could work more on extensions to NAT control protocols, but I don't know if those would be well received in the ISP space. I wasn't involved in the midcom wg. Maybe things have changed, though... >> If NATs become even more common than they are now, BitTorrent >> applications may need to do more NAT traversal, so then TCP-SO would be >> more important. > > I don't see simultaneous open happen for BitTorrent very soon. They may > switch to UDP instead. > I suspect that if it worked reliably, it would be used. Bruce _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 3 11:49:55 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E1A3A698B; Tue, 3 Jun 2008 11:49:55 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EE93A6956 for ; Tue, 3 Jun 2008 11:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3gTC73bFaBJ for ; Tue, 3 Jun 2008 11:49:53 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 2CCA43A691C for ; Tue, 3 Jun 2008 11:49:51 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so180681yxg.49 for ; Tue, 03 Jun 2008 11:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=yaDOAPhiBNVlgBpOx1tBDqTyzPEMV6kLlosQX31Ovj4=; b=KPKteJmTesrdWb47N5hhhEvBZENmmplJYRSKj2uzFuO2PTfh+yhqMT/q7+lgyUhcmKx9U/wpGF1yUyk0mf72fI0Lpz4QM6Kf6nIwq0YOzP79xdZ+YWM11UzJtiiY1XKn2nlyE9j78uOHSn+P+bbDdV/Fn51Dvi2yBmDH3mquexk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Az7hKIQb0taaSRnZT/YYY6oLEEd231bZIoulMTeXirmA1C+tJp1mIHGhHsHwG52VQjShybB2WemILEAZiybUHi0iWHIACVUpMub/UmEKB0YBgL7IPhUnYJ2UY6YLNFk2FsmI4VYev6qqQ1+1qj8hedB06mz6q9kJG/6jphq2kL0= Received: by 10.143.16.9 with SMTP id t9mr4248316wfi.164.1212518994178; Tue, 03 Jun 2008 11:49:54 -0700 (PDT) Received: by 10.143.42.1 with HTTP; Tue, 3 Jun 2008 11:49:53 -0700 (PDT) Message-ID: <6d2996bb0806031149n24d4c6dcha052d22ce9b3fe43@mail.gmail.com> Date: Tue, 3 Jun 2008 20:49:53 +0200 From: "Saikat Guha" To: "Bruce Lowekamp" In-Reply-To: <48458C9F.7080005@sipeerior.com> MIME-Version: 1.0 Content-Disposition: inline References: <483A7598.4030408@free.fr> <483B649A.4030307@sipeerior.com> <48458C9F.7080005@sipeerior.com> X-Google-Sender-Auth: 9c83235ca409e74a Cc: Behave WG Subject: Re: [BEHAVE] Degree of compatibility of BitTorrent with endpoint-independent mapping? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, Jun 3, 2008 at 8:25 PM, Bruce Lowekamp wrote: > Iljitsch van Beijnum wrote: >> On 26 mei 2008, at 22:32, Bruce Lowekamp wrote: >>> If NATs become even more common than they are now, BitTorrent >>> applications may need to do more NAT traversal, so then TCP-SO would be >>> more important. >> >> I don't see simultaneous open happen for BitTorrent very soon. They may >> switch to UDP instead. >> > > I suspect that if it worked reliably, it would be used. FWIW, the stumbling block of using TCP traversal per Bram Cohen was the active signaling plane (where the tracker would have to relay the ICE or equiv. messages). UDP traversal is simpler in that (for many NATs -- NB=I, EF=I) once you punch one hole, you can keep that hole open indefinitely and publish the hole address in the tracker. If someone can implement a BT tracker that performs the ICE relaying at scale, I am sure BT clients would switch in a heartbeat. -- Saikat _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 3 14:29:19 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EF63A6A60; Tue, 3 Jun 2008 14:29:19 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3923D3A6A8F; Tue, 3 Jun 2008 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0cEXq2z33aS; Tue, 3 Jun 2008 14:29:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 37BB83A6A60; Tue, 3 Jun 2008 14:29:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,585,1204531200"; d="scan'208";a="52985948" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2008 14:29:20 -0700 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 m53LTKoc010730; Tue, 3 Jun 2008 14:29:20 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m53LTDr6016001; Tue, 3 Jun 2008 21:29:19 GMT From: "Dan Wing" To: "'Colin Perkins'" , "'Hadriel Kaplan'" References: <480F8629.8080202@rogers.com> <097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> <40799673-8425-476F-ABA4-2FC49297BFF2@csperkins.org>

Date: Tue, 3 Jun 2008 14:29:14 -0700 Message-ID: <003f01c8c5c0$e354b030$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Aciocs9vzuJp6reYSHu153WEJ61avgdLvfFA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2042; t=1212528560; x=1213392560; 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[AVT]=20Working=20Group=20LastCall=3A=0 9draft-ietf-avt-app-rtp-keepalive-03.txt |Sender:=20; bh=EAM+UoyM4qevYHrgEmeOdWtrdfjj2P3CZuBf0Bgd0Fw=; b=B8rU4ttxZJuEygd/kejQ2yYInyjcsbdDdMbyPTsayS1EFGY0Mn/FcnlC7x ABCJUvI/vfF4owH7jXl3fUrmHpX8nK7kxf/+bCcNWP5YYaztVzQuw1FzwTcJ YDrD3ZWPU1; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'MARJOU Xavier RD-MAPS-LAN' , behave@ietf.org, 'Tom Taylor' , 'IETF AVT WG' Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Sunday, April 27, 2008 7:27 AM > To: Hadriel Kaplan > Cc: Cullen Jennings; behave@ietf.org WG; Dan Wing; Tom > Taylor; IETF AVT WG; MARJOU Xavier RD-MAPS-LAN > Subject: Re: [AVT] Working Group LastCall: > draft-ietf-avt-app-rtp-keepalive-03.txt > > On 26 Apr 2008, at 17:11, Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> > >> Static payload types were deprecated over a decade ago. > Negotiating a > >> no-op payload type in SDP makes sense, but I really don't want to > >> revisit static assignments. > > > > Yeah, I knew you'd say that. :) > > I'd be happy if there were at least some SDP indication. Even if > > the sender ignores the lack of it in received SDP and sends empty > > RTP anyway, it would be useful to have it indicate support for it > > and its PT in the SDP it sends. > > Sure, I have no argument with that. > > >>> I find it odd that a WG BCP would recommend a mechanism (albeit a > >>> fallback one), that is not itself defined in a standards track doc > >>> anywhere. Maybe it's just me though. :) > >> > >> There were also concerns about having IPR on a no-op format, if I > >> remember correctly. https://datatracker.ietf.org/ipr/854/ > > > > I thought that was Cisco's classic defensive patent statement, > > which other IETF RFC's have been OK with. And I'm suggesting a > > different form of no-op: an empty one. Regardless, if an > > empty RTP is covered by that IPR, then so is this keepalive > > draft, no? > > Possibly - you'd have to ask Cisco. I checked with our in-house attorneys about our IPR declaration against draft-ietf-avt-app-rtp-keepalive, and we would keep that same IPR declaration even with an empty RTP no-op. The IPR declaration allows use of any of our patents necessary to implement no-op, so long as no-op becomes a standard. I hope that helps clarify things, -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 3 14:44:18 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560B03A6A3F; Tue, 3 Jun 2008 14:44:18 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418563A6A3F for ; Tue, 3 Jun 2008 14:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7jGb+2qZM4l for ; Tue, 3 Jun 2008 14:44:16 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 4702C3A6AAE for ; Tue, 3 Jun 2008 14:40:23 -0700 (PDT) Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m53Lcm0h005504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2008 23:38:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <24C2E8F3-B3D0-467E-88B0-6C93108F5865@muada.com> From: Iljitsch van Beijnum To: Bruce Lowekamp In-Reply-To: <48458C9F.7080005@sipeerior.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 3 Jun 2008 23:39:03 +0200 References: <483A7598.4030408@free.fr> <483B649A.4030307@sipeerior.com> <48458C9F.7080005@sipeerior.com> X-Mailer: Apple Mail (2.924) Cc: Behave WG Subject: Re: [BEHAVE] Degree of compatibility of BitTorrent with endpoint-independent mapping? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 3 jun 2008, at 20:25, Bruce Lowekamp wrote: >> So BitTorrent does often use NAT traversal, just not with any of >> the mechanisms that the IETF is familiar with. :-) > You're right, I was thinking about techniques other than NAT control. > More importantly, though, neither of those techniques work with > multi-level NATs (or NATs on the other side of routers), so aren't > really appropriate for the problem domain we're talking about here, > as I understand it. Now I suppose we could work more on extensions > to NAT control protocols, but I don't know if those would be well > received in the ISP space. I wasn't involved in the midcom wg. > Maybe things have changed, though... I was just explaining how BitTorrent is commonly used, not how it would work in a world with multiple layers of NAT (something that we should avoid, anyway). If I understand the endpoint independent mapping rationale correctly, the idea is that once a host uses a session using a certain source port, then the NAT will map that internal source port into an external source port and after that forward incoming sessions towards the external port to the internal host. BitTorrent applications could easily be modified to take advantage of that behavior. The side effect would be that they no longer use up excessive amounts of port numbers, so this would be win-win. >> I don't see simultaneous open happen for BitTorrent very soon. They >> may switch to UDP instead. > I suspect that if it worked reliably, it would be used. The current situation works quite well, as people are attributing more than half of all internet traffic to BitTorrent and friends, so there was no real need to change anything, until Comcast started sending fake TCP resets for BitTorrent sessions. Using UDP transport could help against that. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 4 00:25:19 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64CAC3A6BA9; Wed, 4 Jun 2008 00:25:19 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BF03A6B99 for ; Wed, 4 Jun 2008 00:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhvbDnMxx9bU for ; Wed, 4 Jun 2008 00:25:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id F09373A67C1 for ; Wed, 4 Jun 2008 00:25:16 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A6F9F20A71; Wed, 4 Jun 2008 09:25:19 +0200 (CEST) X-AuditID: c1b4fb3c-b009fbb00000193b-4f-4846435f512c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 81A1820649; Wed, 4 Jun 2008 09:25:19 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 09:25:19 +0200 Received: from [159.107.2.19] ([159.107.2.19]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 09:25:17 +0200 Message-ID: <48464358.9070107@ericsson.com> Date: Wed, 04 Jun 2008 10:25:12 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Philip Matthews References: <47F3FA30.2060403@acm.org> <200805021504.26754.remi.denis-courmont@nokia.com> <200805050923.50429.remi.denis-courmont@nokia.com> <48216376.7010305@ericsson.com> <482206A7.6050100@ericsson.com> <482279BE.5010805@ericsson.com> <07BC5FEF-84DF-4B37-B826-91A3223187C1@magma.ca> In-Reply-To: <07BC5FEF-84DF-4B37-B826-91A3223187C1@magma.ca> X-OriginalArrivalTime: 04 Jun 2008 07:25:18.0521 (UTC) FILETIME=[23F8C290:01C8C614] X-Brightmail-Tracker: AAAAAA== Cc: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= , Behave WG Subject: Re: [BEHAVE] IPv4/IPv6 relayed address allocation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, the details to be specified do not seem to be many. The relay would need to drop IP (v4 and v6) options and the IPv6 flow label. What else do you have in mind? Thanks, Gonzalo Philip Matthews wrote: > I really haven't spent any time thinking about it, but I am assuming > that the details of IPv4-to-IPv6 relaying will take a few pages to > specify, and there will be some design decisions to discuss, which will > take time. Because of this assumption, I am trying to push it out of the > base TURN spec. But perhaps I am wrong. Perhaps you would take a look > and let me know? > > - Philip > > On Wed, 7-May-08, at 23:55 , Gonzalo Camarillo wrote: >> Hi, >> >> I think we all agree this should be the behavior for clients and >> servers. However, if we move all the meat from TURN-IPv6 to base TURN >> (we already moved the address family definition a while ago), it may >> make sense to merge both specs. Specifying the IPv4-IPv6 mapping may >> not be trivial, but it's not a big deal either. >> >> The bottom line is that we are discussing an issue related to document >> structure. We seem to agree on the actual protocol behavior. >> >> Cheers, >> >> Gonzalo >> >> >> Philip Matthews wrote: >>> On Wed, 7-May-08, at 15:44 , Gonzalo Camarillo wrote: >>>> Hi, >>>> >>>>> If the base TURN spec does not include the REQUESTED-ADDRESS-TYPE >>>>> attribute, then we have to go with option (1). However, Remi >>>>> prefers option (2). >>>> >>>> but... what is the advantage of going with option 2? >>> Under option (1), a client sending an Allocate request over IPv4 >>> might get back an IPv6 relayed-transport-address, if the Allocate >>> request passed through a v4-to-v6 translator (as is currently being >>> considered in v6OPS). If the client is unable to handle this, it must >>> delete the allocation. >>> Under option (2), a client sending an Allocation request over IPv4 >>> can explicitly say that it wants an IPv4 relayed-transport-address. >>> Thus, if the Allocate request passes through a v4-to-v6 translator, >>> the server will detect that the request arrived over v6 but was for a >>> v4 relayed-transport-address, and thus reject the request. >>> - Philip >> >> > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jun 7 10:20:41 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EC33A6A95; Sat, 7 Jun 2008 10:20:41 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00693A6A95 for ; Sat, 7 Jun 2008 10:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gqo+Vssp6dC for ; Sat, 7 Jun 2008 10:20:39 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 382C63A6A77 for ; Sat, 7 Jun 2008 10:20:39 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 3F5517F02D8; Sat, 7 Jun 2008 17:20:52 +0000 (UTC) Received: from [192.168.1.3] (c-67-161-24-129.hsd1.ca.comcast.net [67.161.24.129]) by server.implementers.org (Postfix) with ESMTP id ACFA07F02D2 for ; Sat, 7 Jun 2008 17:20:50 +0000 (UTC) Message-ID: <484AC372.60107@acm.org> Date: Sat, 07 Jun 2008 10:20:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Behave WG References: <1879720d0804011545ib96dff0kd45c5c07cb7de199@mail.gmail.com> <6D4E88C6-D37E-44BF-87B2-AA7E91639A04@magma.ca> <47F3B3E1.6080607@acm.org> In-Reply-To: <47F3B3E1.6080607@acm.org> Subject: [BEHAVE] TURN dissector [was Re: Goals for the proposed conf call on TURN encapsulations] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Marc Petit-Huguenin wrote: > Philip Matthews wrote: >> First of all, thanks for having a mailing list discussion on all this. >> I am following the mailing list closely, and will make sure that any >> comments made on the list are carefully considered when deciding what >> to do with TURN. >> >> Regarding finishing TURN. Indeed, TURN has been very unstable for a >> long time, so it has not been a very good candidate for stable trial >> implementations. > > How a protocol can be proposed as a standard track RFC without > implementations is a mystery for me. I know that it is mandatory to > have independent implementations only when a standard is promoted to > Draft Standard, but as nobody seems to worry to promote standards > anymore, I think that the burden of the two implementations should be > moved to the Proposed Standard. > > Anyway even if everybody seems to have given up on TURN implementations, > I did not. On request I can provide an access to our TURN servers > (turn-05 and rfc3489bis-15 currently, working on upgrading to turn-07). > I can also provide a WIP patch for Wireshark. We now have a complete dissector for TURN-07 which also dissects RTP, RTCP, STUN, SIP and TFTP inside the channels and SEND/DATA indications. Send me a direct email if you are interested of testing it. Thanks. -- Marc Petit-Huguenin [ ] Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ] Work: marc@8x8.com [ ] [ 1d3de5282a3f2775d3110560129c1ca5 ] _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 9 19:00:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773263A6875; Mon, 9 Jun 2008 19:00:03 -0700 (PDT) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E20D53A6875; Mon, 9 Jun 2008 19:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080610020001.E20D53A6875@core3.amsl.com> Date: Mon, 9 Jun 2008 19:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-icmp-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org 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 : NAT Behavioral Requirements for ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-08.txt Pages : 27 Date : 2008-06-09 This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-behave-nat-icmp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-09185923.I-D@ietf.org> --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://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Tue Jun 10 08:03:07 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51F613A6A49; Tue, 10 Jun 2008 08:03:07 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB3A3A6A49 for ; Tue, 10 Jun 2008 08:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuhIQk+qs2aR for ; Tue, 10 Jun 2008 08:03:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C57D33A6839 for ; Tue, 10 Jun 2008 08:03:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,618,1204531200"; d="scan'208";a="78091527" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2008 08:03:28 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m5AF3SH9008331 for ; Tue, 10 Jun 2008 08:03:28 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m5AF3RNj010852 for ; Tue, 10 Jun 2008 15:03:28 GMT From: "Dan Wing" To: Date: Tue, 10 Jun 2008 08:03:27 -0700 Message-ID: <015201c8cb0b$2392a130$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcjLCyM/Hx7wgFHAQ2mCB/RMC7jwTg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1220; t=1213110208; x=1213974208; 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:=20draft-ietf-behave-nat-icmp-08.txt |Sender:=20; bh=Mey9f95qp1C6DWRDhE9BI8JtsqXw9gcJkUJm2o3+M34=; b=dBNloTrElFqNV+i5diFn0/Ux7cFwEsY+FdcjTeq9N4iwQq5T+NlzN2t6d4 80lXJcUBS/txFCed+3YTZ5FaACyYMqm3nYxekkXoNmT3+co7V5942T0qgv1U dJzpXnJGph; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [BEHAVE] draft-ietf-behave-nat-icmp-08.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org draft-ietf-behave-nat-icmp-08.txt was just posted. These changes address DISCUSS items raised during IESG review, which can be seen at https://datatracker.ietf.org/idtracker/draft-ietf-behave-nat-icmp/ Please review these changes and reply to the list. I need to determine if there is consensus for these changes so we can move the document forward. Side-by-side differences are at: http://www.tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/internet-drafts/d raft-ietf-behave-nat-icmp-08.txt Summary of the changes: * clarified ICMP 'query', 'error', and 'non-queryerror' message classifications * In REQ-9, previous version required NATs to comply with Section 4.3 of RFC1812, which is the ICMP section of router requirements document. Version -08 softened this requirement (from MUST to RECOMMENDED) because many deployed routers do not meet these requirements, but -08 does not enumerate the specific RFC1812 Section 4.3 requirements. * new REQ-9b which requires ICMP 'packet too big' error messages to always be forwarded. This is so that Path MTU Discovery will work. * new REQ-10, "A NAT MAY drop or appropriately handle Non-QueryError ICMP messages." -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 10 08:05:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE333A6AAD; Tue, 10 Jun 2008 08:05:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F8B3A6AAD for ; Tue, 10 Jun 2008 08:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5CY8ZRXTV9w for ; Tue, 10 Jun 2008 08:04:58 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DA7733A6A49 for ; Tue, 10 Jun 2008 08:04:57 -0700 (PDT) Received: from dhcp158.dagstuhl.de (dhcp158.dagstuhl.de [192.76.146.158])by smtp02.uc3m.es (Postfix) with ESMTP id C30C73C63B3for ; Tue, 10 Jun 2008 17:05:18 +0200 (CEST) Message-ID: <484E982E.6010603@it.uc3m.es> Date: Tue, 10 Jun 2008 17:05:18 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Behave WG Content-Type: multipart/mixed; boundary=------------060805000207010800060504 X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.0244 TC:1F TRN:40 TV:5.5.1026(15962.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-nat64-00.txt] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --------------060805000207010800060504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, We have submitted the following draft describing NATs for v6 to v4 translation. We would very much appreciate comments you may have Thanks, marcelo -------- Mensaje original -------- Asunto: I-D Action:draft-bagnulo-behave-nat64-00.txt Fecha: Tue, 10 Jun 2008 08:00:02 -0700 (PDT) De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Para: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64/DNS64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers Author(s) : M. Bagnulo, et al. Filename : draft-bagnulo-behave-nat64-00.txt Pages : 27 Date : 2008-06-10 NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. This document specifies NAT64 and DNS64, and gives suggestions on how they should be deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------060805000207010800060504 Content-Type: Message/External-body; name="draft-bagnulo-behave-nat64-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-bagnulo-behave-nat64-00.txt" Content-Type: text/plain Content-ID: <2008-06-10074947.I-D@ietf.org> --------------060805000207010800060504 Content-Type: text/plain; name="Parte del mensaje adjunto" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Parte del mensaje adjunto" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------060805000207010800060504 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://www.ietf.org/mailman/listinfo/behave --------------060805000207010800060504-- From behave-bounces@ietf.org Fri Jun 13 12:30:17 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78823A6851; Fri, 13 Jun 2008 12:30:17 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47EC3A6885 for ; Fri, 13 Jun 2008 12:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPNySit5Wl89 for ; Fri, 13 Jun 2008 12:30:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C484C3A6851 for ; Fri, 13 Jun 2008 12:30:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,641,1204531200"; d="scan'208";a="41204221" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2008 12:30:48 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5DJUmXm012763; Fri, 13 Jun 2008 12:30:48 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5DJUlaB009814; Fri, 13 Jun 2008 19:30:48 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <484E982E.6010603@it.uc3m.es> Date: Fri, 13 Jun 2008 12:30:47 -0700 Message-ID: <014401c8cd8b$fb67a100$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <484E982E.6010603@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjLC2r7/ZP/HNzoTx20m9/3flm50gCa+obA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3043; t=1213385448; x=1214249448; c=relaxed/simple; s=sjdkim4002; 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:=20comments=20on=20draft-bagnulo-behave-nat64-00 |Sender:=20; bh=7VPYTCoIdKvwW75pZe9ACQzOXaejayiFaCzYWsVPQ2w=; b=CV+T0FgjYgZFXhCPgZWNIeoYYrQbx6VSZ6eponxaJSeahinbEZRmtnQtek /X72lfFrf5GUTPpHVgVZIps7VoSfg7kyKgy2gO4tjVBXIc6mUDwMlJayaZTr zHhwN8vsXv; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' Subject: [BEHAVE] comments on draft-bagnulo-behave-nat64-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org (as an individual) I have a few comments about the draft: * The draft currently only talks of UDP/TCP/ICMP. It needs to also discuss, or at least have placeholeders for, - IPSec ESP tunnel mode - DCCP - SCTP * Can ASM or SSM multicast be supported with NAT64? * Should discuss preserving or remarking of DSCP bits across the v6/v4 boundary. * I know NAT-PT discussed an FTP-ALG and I see NAT64 does, too. However, in 2008 can we just rely on passive (PASV) support in the v6 FTP client and in the v4 FTP server so that NAT64 does not need to include an FTP ALG? I ask because a seemingly significant aspect of NAT64 is that there are no v4-initiated connections to v6 hosts; non-passive FTP data connections would break that aspect. I will send my nits separately to the authors. -d > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Tuesday, June 10, 2008 8:05 AM > To: Behave WG > Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-nat64-00.txt] > > Hi, > > We have submitted the following draft describing NATs for v6 to v4 > translation. > > We would very much appreciate comments you may have > > Thanks, marcelo > > > -------- Mensaje original -------- > Asunto: I-D Action:draft-bagnulo-behave-nat64-00.txt > Fecha: Tue, 10 Jun 2008 08:00:02 -0700 (PDT) > De: Internet-Drafts@ietf.org > Responder a: internet-drafts@ietf.org > Para: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : NAT64/DNS64: Network Address and > Protocol Translation from IPv6 Clients to IPv4 Servers > Author(s) : M. Bagnulo, et al. > Filename : draft-bagnulo-behave-nat64-00.txt > Pages : 27 > Date : 2008-06-10 > > NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and > vice-versa. DNS64 is a mechanism for synthesizing AAAA records from > A records. These two mechanisms together enable client-server > communication between an IPv6-only client and an IPv4-only server, > without requiring any changes to either the IPv6 or the IPv4 node, > for the class of applications that work through NATs. They also > enable peer-to-peer communication between an IPv4 and an IPv6 node, > where the communication can be initiated by either end using > existing, NAT-traversing, peer-to-peer communication techniques. > This document specifies NAT64 and DNS64, and gives suggestions on how > they should be deployed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jun 14 02:05:39 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343883A682D; Sat, 14 Jun 2008 02:05:39 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DF13A682D for ; Sat, 14 Jun 2008 02:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2Vq7a87Edod for ; Sat, 14 Jun 2008 02:05:37 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id BB52B3A6805 for ; Sat, 14 Jun 2008 02:05:36 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (144.45.217.87.dynamic.jazztel.es [87.217.45.144])by smtp03.uc3m.es (Postfix) with ESMTP id B48BD3DC6D9; Sat, 14 Jun 2008 11:02:12 +0200 (CEST) Message-ID: <48538914.1010605@it.uc3m.es> Date: Sat, 14 Jun 2008 11:02:12 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dan Wing References: <484E982E.6010603@it.uc3m.es> <014401c8cd8b$fb67a100$c5f0200a@cisco.com> In-Reply-To: <014401c8cd8b$fb67a100$c5f0200a@cisco.com> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-26.4327 TC:1F TRN:92 TV:5.5.1026(15970.006) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'Behave WG' Subject: Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Dan, thanks for the comments see replies in-line Dan Wing escribi=F3: > (as an individual) > > I have a few comments about the draft: > > * The draft currently only talks of UDP/TCP/ICMP. It needs to also > discuss, or at least have placeholeders for, > - IPSec ESP tunnel mode > - DCCP > - SCTP > > = right actually, the requirements defined in v6ops for v4-v6 translation make = the last two optional (i.e. SHOULD be supported) and the first one = (IPSec) must be supported but changes in the hosts are acceptable So, when doing this document we focused in the critical features, = TCP/UDP/ICMP support and we left out the SHOULDs. I mean, at thsi stage = we were exploring if we could make the basic features work, along with = dnssec and avoiding translated connectivity when native connectivity is = available, which are the reuqired features. We could add the support for DCCP and SCTP if people feel it is needed = in this document or we could make the analysis to make sure the nat64 = allows its support and define it somewhere else, i am ok either way W.r.t. IPSec, it will require to change the end hosts (at least one), so = i was thinking to define the changed required to the hosts in a = different spec (while making sure that the nat64 as defined is = compatible with that). This is the approach used in v4 nats, but again i = don't have a strong opinion on this neither > * Can ASM or SSM multicast be supported with NAT64? > > = similarly to the dccp and sctp, the requirement document says that this = should be supported and the previous comments apply there are also other protocols, like MIP that are in the same situation > * Should discuss preserving or remarking of DSCP bits across the > v6/v4 boundary. > > = good point haven't heard any discussion about this before, so i guess the issue is = open. I think it would make sense to preserve them > * I know NAT-PT discussed an FTP-ALG and I see NAT64 does, too. > However, in 2008 can we just rely on passive (PASV) support in the > v6 FTP client and in the v4 FTP server so that NAT64 does not need > to include an FTP ALG? I ask because a seemingly significant aspect > of NAT64 is that there are no v4-initiated connections to v6 hosts; > non-passive FTP data connections would break that aspect. > > = we had this discussion among the authors, and Phil mentioned that draft-ietf-behave-tcp says: REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP [RFC0959]) be disabled by default. Justification: The intent of this requirement is to prevents ALGs from interfering with UNSAF methods. The default state of a FTP ALG is left unspecified because of legacy concerns: as of writing this memo, a large fraction of legacy FTP clients do not enable passive (PASV) mode by default and require an ALG to traverse NATs. and then we decided to keep it and see what the wg feeling was. i am personally all for dropping this... Regards, marcelo > I will send my nits separately to the authors. > > -d > = > > = >> -----Original Message----- >> From: behave-bounces@ietf.org = >> [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun >> Sent: Tuesday, June 10, 2008 8:05 AM >> To: Behave WG >> Subject: [BEHAVE] [Fwd: I-D Action:draft-bagnulo-behave-nat64-00.txt] >> >> Hi, >> >> We have submitted the following draft describing NATs for v6 to v4 = >> translation. >> >> We would very much appreciate comments you may have >> >> Thanks, marcelo >> >> >> -------- Mensaje original -------- >> Asunto: I-D Action:draft-bagnulo-behave-nat64-00.txt >> Fecha: Tue, 10 Jun 2008 08:00:02 -0700 (PDT) >> De: Internet-Drafts@ietf.org >> Responder a: internet-drafts@ietf.org >> Para: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line = >> Internet-Drafts directories. >> >> Title : NAT64/DNS64: Network Address and = >> Protocol Translation from IPv6 Clients to IPv4 Servers >> Author(s) : M. Bagnulo, et al. >> Filename : draft-bagnulo-behave-nat64-00.txt >> Pages : 27 >> Date : 2008-06-10 >> >> NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and >> vice-versa. DNS64 is a mechanism for synthesizing AAAA records from >> A records. These two mechanisms together enable client-server >> communication between an IPv6-only client and an IPv4-only server, >> without requiring any changes to either the IPv6 or the IPv4 node, >> for the class of applications that work through NATs. They also >> enable peer-to-peer communication between an IPv4 and an IPv6 node, >> where the communication can be initiated by either end using >> existing, NAT-traversing, peer-to-peer communication techniques. >> This document specifies NAT64 and DNS64, and gives suggestions on how >> they should be deployed. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-bagnulo-behave-nat64-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> = > > > = _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jun 14 11:04:03 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AD83A698A; Sat, 14 Jun 2008 11:04:03 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 118FB3A6950 for ; Sat, 14 Jun 2008 11:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKppYeqXfJ1I for ; Sat, 14 Jun 2008 11:04:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B18953A698A for ; Sat, 14 Jun 2008 11:04:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,644,1204531200"; d="scan'208";a="32240101" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2008 11:04:37 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5EI4b1K030413; Sat, 14 Jun 2008 11:04:37 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m5EI4aUM006103; Sat, 14 Jun 2008 18:04:36 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <484E982E.6010603@it.uc3m.es> <014401c8cd8b$fb67a100$c5f0200a@cisco.com> <48538914.1010605@it.uc3m.es> Date: Sat, 14 Jun 2008 11:04:36 -0700 Message-ID: <002201c8ce49$1b8e6370$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48538914.1010605@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjN/eYL5ICG3kJ3QuC/60bsQM4Z4gAQgbtA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4888; t=1213466677; x=1214330677; c=relaxed/simple; s=sjdkim4002; 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]=20comments=20on=20draft-bagnul o-behave-nat64-00 |Sender:=20; bh=GhV6kOrRD1IwtOkzKWZWZaAExSP5BDQCJpLpGxac6TU=; b=cu6N22R5zHwDJH/n6ksDINIWup0WLOPdB73n234V7OiiiV+Z7tbzihk0qH clDZTuHMntHyN69tf09BcgTDuQb+Bx8tistiYXs/dnHzoKKkGNpOWYD+lXR5 8RSSujmAZy; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org = > -----Original Message----- > From: behave-bounces@ietf.org = > [mailto:behave-bounces@ietf.org] On Behalf Of marcelo bagnulo braun > Sent: Saturday, June 14, 2008 2:02 AM > To: Dan Wing > Cc: 'Behave WG' > Subject: Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00 > = > Hi Dan, > = > thanks for the comments > = > see replies in-line > = > Dan Wing escribi=F3: > > (as an individual) > > > > I have a few comments about the draft: > > > > * The draft currently only talks of UDP/TCP/ICMP. It needs to also > > discuss, or at least have placeholeders for, > > - IPSec ESP tunnel mode > > - DCCP > > - SCTP > > right > actually, the requirements defined in v6ops for v4-v6 = > translation = draft-bagnulo-behave-nat64-00 does not cite draft-ietf-v6ops-nat64-pb-statement-req-00 as its source of = requirements. If that is what nat64 is trying to meet, it would be useful to cite the v6ops problem statement document. > make the last two optional (i.e. SHOULD be supported) > and the first one = > (IPSec) must be supported but changes in the hosts are acceptable draft-ietf-v6ops-nat64-pb-statement-req-00 says: R11: IPsec support. The translator MUST support communication between IPv4 node and IPv6 node using UDP Encapsulation of IPsec ESP Packets as defined in [RFC3948] as applicable. RFC3948 should be interpreted as with the IPv6 side on the IPv6-IPv4 translator being the IPv4 private side of the conventional NAT. IPsec support MAY require updating also the IPv4 side. For approximately the last 8 years, v4v4 NAPTs have included "IPsec Passthrough", which allows IPsec ESP tunnel mode to work with those NAPTs, without any host changes whatsoever. This works for IPsec connections initiated from the 'inside' of the NAPT. NAT64 can = support this same functionality as this long-standing v4v4 NAPT = feature, and do so without host changes. > So, when doing this document we focused in the critical features, = > TCP/UDP/ICMP support and we left out the SHOULDs. I mean, at = > thsi stage = > we were exploring if we could make the basic features work, = > along with = > dnssec and avoiding translated connectivity when native = > connectivity is = > available, which are the reuqired features. > = > We could add the support for DCCP and SCTP if people feel it = > is needed = > in this document or we could make the analysis to make sure the nat64 = > allows its support and define it somewhere else, i am ok either way Ok. > W.r.t. IPSec, it will require to change the end hosts (at = > least one), I do not believe that is necessary. > so = > i was thinking to define the changed required to the hosts in a = > different spec (while making sure that the nat64 as defined is = > compatible with that). This is the approach used in v4 nats, = > but again i = > don't have a strong opinion on this neither > > * Can ASM or SSM multicast be supported with NAT64? > > > > = > = > similarly to the dccp and sctp, the requirement document says = > that this = > should be supported and the previous comments apply > > there are also other protocols, like MIP that are in the same = > situation > > * Should discuss preserving or remarking of DSCP bits across the > > v6/v4 boundary. > > > > = > good point > haven't heard any discussion about this before, so i guess = > the issue is open. I see the v6ops NAT64 requirement document is silent on DSCP. > I think it would make sense to preserve them > = > = > > * I know NAT-PT discussed an FTP-ALG and I see NAT64 does, too. > > However, in 2008 can we just rely on passive (PASV) support in the > > v6 FTP client and in the v4 FTP server so that NAT64 does not need > > to include an FTP ALG? I ask because a seemingly = > significant aspect > > of NAT64 is that there are no v4-initiated connections to = > v6 hosts; > > non-passive FTP data connections would break that aspect. > > > > = > we had this discussion among the authors, and Phil mentioned that > = > = > draft-ietf-behave-tcp says: > REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED > that all of those ALGs (except for FTP [RFC0959]) be disabled by > default. > = > Justification: The intent of this requirement is to prevents ALGs > from interfering with UNSAF methods. The default state of a FTP > ALG is left unspecified because of legacy concerns: as = > of writing > this memo, a large fraction of legacy FTP clients do not enable > passive (PASV) mode by default and require an ALG to traverse > NATs. > = > and then we decided to keep it and see what the wg feeling was. > = > i am personally all for dropping this... -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jun 15 14:45:51 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CA83A6975; Sun, 15 Jun 2008 14:45:51 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BD13A6978 for ; Sun, 15 Jun 2008 14:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRqzhydG9YRn for ; Sun, 15 Jun 2008 14:45:44 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 820763A683E for ; Sun, 15 Jun 2008 14:45:42 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4603556rvf.49 for ; Sun, 15 Jun 2008 14:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=GIwPFcXMEmORXSN0hnnOcRHKJjx+4/F77rzAc3D3X6s=; b=jOaxlXmozsTOzkfP9EE+BZTmyo9n3y6ZOxz01Bm3Hxj7fVBMuABzi2VC9Vdp8MHXZe uv7U2KGvxwkKvZtNk6U+28q2prhnxKoA18yX4MHNhBJqM6skpwwJH2tLPuKpZAJ0TYTc BZhvwxyVnZMQFVAhMVez6QYhgZy/ESlWdnrYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=x+wwLGiv7HyUG5cwP5CTQG362Tab6yOe0yz4GeOT0mC9U6PF/ssXGs8vCgvVGbCGR4 XOHlxliUcGo+46ZEGb9zuaLjgyK48PcJLqmcp/03t3J9SLOxoUAB5EWie4qr3Yxo8BId 1c6HOvcsI5fnYN3yTKopVgRwPc7uIytTgG0D0= Received: by 10.141.168.7 with SMTP id v7mr3278496rvo.66.1213566381196; Sun, 15 Jun 2008 14:46:21 -0700 (PDT) Received: by 10.141.198.10 with HTTP; Sun, 15 Jun 2008 14:46:21 -0700 (PDT) Message-ID: Date: Sun, 15 Jun 2008 14:46:21 -0700 From: "Derek MacDonald" To: "Philip Matthews" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 427cb6060c568c30 Cc: Behave WG Subject: Re: [BEHAVE] A few minor comments on draft-ietf-behave-nat-behavior-discovery-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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="===============0577743945==" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --===============0577743945== Content-Type: multipart/alternative; boundary="----=_Part_13148_12860121.1213566381191" ------=_Part_13148_12860121.1213566381191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Inline. On Mon, Apr 14, 2008 at 1:14 PM, Philip Matthews wrote: > I know this comes after WGLC, but here are a few minor comments on this > draft. Note that I haven't finished reading the document, but I am sending > these out now in case they are helpful. > > - Philip > > > * The wording of this draft seems to imply that it is an experimental > extension to draft-ietf-behave-rfc3489bis (and not, for example, RFC 3489). > Perhaps it would be good to make a definite statement about this in the > introduction section? > The intro states that this is a usage of bis. > > * From the draft: > 4.2. Determining NAT Mapping Behavior > > This will require at most three tests. In test I, the client > performs the UDP connectivity test. The server will return its > alternate address and port in OTHER-ADDRESS in the binding response. > If OTHER-ADDRESS is not returned, the server does not support this > usage and this test cannot be run. The client examines the XOR- > MAPPED-ADDRESS attribute. If this address and port are the same as > the local IP address and port of the socket used to send the request, > the client knows that it is not NATed and the effective mapping will > be Endpoint-Independent. > > What about the case of cascaded NATs where the address gets reused in a > different addressing domain? This will give the wrong result. > > This failure seems different than some other failures in that it is not the > NAT that is "faking out" the test, but rather a consequence of the network > topology. > Don't see how we could do anything here; what is being discovered is the effective mapping behaviour of the Nat(s) between the client and the stun server. The test will still return the effective mapping behavior. > > > * Is section 4 normative or informative? > Normative. > > * From the draft: > the server. Therefore, a client MUST be prepared for receiving a 420 > s/for receiving/to receive/ > > Fixed-thanks:) ------=_Part_13148_12860121.1213566381191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Inline.

On Mon, Apr 14, 2008 at 1:14 PM, Philip Matthews <philip_matthews@magma.ca> wrote:

I know this comes after WGLC, but here are a few minor comments on this draft. Note that I haven't finished reading the document, but I am sending these out now in case they are helpful.

- Philip

* The wording of this draft seems to imply that it is an experimental extension to draft-ietf-behave-rfc3489bis (and not, for example, RFC 3489). Perhaps it would be good to make a definite statement about this in the introduction section?

The intro states that this is a usage of bis.

* From the draft:
4.2. Determining NAT Mapping Behavior

This will require at most three tests. In test I, the client
performs the UDP connectivity test. The server will return its
alternate address and port in OTHER-ADDRESS in the binding response.
If OTHER-ADDRESS is not returned, the server does not support this
usage and this test cannot be run. The client examines the XOR-
MAPPED-ADDRESS attribute. If this address and port are the same as
the local IP address and port of the socket used to send the request,
the client knows that it is not NATed and the effective mapping will
be Endpoint-Independent.

What about the case of cascaded NATs where the address gets reused in a different addressing domain? This will give the wrong result.

This failure seems different than some other failures in that it is not the NAT that is "faking out" the test, but rather a consequence of the network topology.

Don't see how we could do anything here; what is being discovered is the effective mapping behaviour of the Nat(s) between the client and the stun server. The test will still return the effective mapping behavior.

* Is section 4 normative or informative?

Normative.

* From the draft:
the server. Therefore, a client MUST be prepared for receiving a 420
s/for receiving/to receive/

Fixed-thanks:)

------=_Part_13148_12860121.1213566381191-- --===============0577743945== 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://www.ietf.org/mailman/listinfo/behave --===============0577743945==-- From behave-bounces@ietf.org Sun Jun 15 14:48:08 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7844E3A6978; Sun, 15 Jun 2008 14:48:08 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753BD3A6978 for ; Sun, 15 Jun 2008 14:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UcB3Oq1e+Re for ; Sun, 15 Jun 2008 14:48:05 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id D8D303A6975 for ; Sun, 15 Jun 2008 14:48:05 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so4603860rvf.49 for ; Sun, 15 Jun 2008 14:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=HrId+wUmLIMlqG8qRBujDMURZZLu5UDN5ifmwW7pfiQ=; b=L6VOnLr4NwKqNy0dmtcG+3NB2lcz7v29PQSBlRgrPXbA/DA5yaq4uT/V53CpXgDb7V 558CeCkUY4KkQ1bdYfygJ3s0IAY4AsCeEx0RfU92m+nVqMGVX7quihW46k9jfhv709yc Ln/oRAnx5P+LAkaaF7Wx6UABVx2K/gh4Insjg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=qerC51XFAWBhu9DB6mtDp2mM405ZNY2VsomUxYnoJRFvhTV68kvmrvmbQZ2xK+5vJZ FF9DTgxCn9AlPzKDNENxrUNUgHmEHa5hP53pMc46OmpAxuKIDRy3dSBC9BlLBIX70Zwf AgAYXJkni0QcRf5O7K0BVPWyhPNLnSNAA2+7A= Received: by 10.140.131.7 with SMTP id e7mr3227057rvd.261.1213566521056; Sun, 15 Jun 2008 14:48:41 -0700 (PDT) Received: by 10.141.198.10 with HTTP; Sun, 15 Jun 2008 14:48:40 -0700 (PDT) Message-ID: Date: Sun, 15 Jun 2008 14:48:40 -0700 From: "Derek MacDonald" To: "Dan Wing" In-Reply-To: <04aa01c88b76$24d834d0$c5f0200a@cisco.com> MIME-Version: 1.0 References: <47D99773.60705@db.org> <074101c88a16$bf6a0890$c5f0200a@cisco.com> <47E3E93D.8040705@db.org> <04aa01c88b76$24d834d0$c5f0200a@cisco.com> X-Google-Sender-Auth: 69c8d418280d15d4 Cc: Behave WG , Philip Matthews Subject: Re: [BEHAVE] Determining NAT Filtering Behavior X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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="===============0212281086==" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --===============0212281086== Content-Type: multipart/alternative; boundary="----=_Part_13163_1974133.1213566521027" ------=_Part_13163_1974133.1213566521027 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline So, my take-away from this is that nothing needs to be changed? On Fri, Mar 21, 2008 at 10:08 AM, Dan Wing wrote: > > > > draft-ietf-behave-rfc3489bis-15, bottom of page 6: > > > > > > For request/response transactions, this transaction ID allows > > > the client to associate the response with the request that > > > generated it; for indications, this serves as a debugging aid. > > > > > > > so what you are saying is that, by default, the STUN Client > > does not check the source address of the STUN Response. > > I didn't see text in rfc3489bis that said the port of the response > needed to be checked. I believe behavior-discovery needs to > send response packets from different ports and from different > IP addresses in order to do some of its checks. > > > But it can be overridden by the usage, like e.g. ICE: > > > > > > > > 7.1.2.2. Success Cases > > > > A check is considered to be a success if all of the following are > > true: > > > > o the STUN transaction generated a success response > > > > o the source IP address and port of the response equals the > > destination IP address and port that the Binding > > Request was sent > > to > > > > o the destination IP address and port of the response match the > > source IP address and port that the Binding Request was > > sent from > > Right. > > > Is is specified in the TURN-07 draft that the TURN client should check > > the source address of any STUN Response, btw? > > I don't believe so. > > But, considering that TURN is most often used when the TURN client > is behind a 'symmetric' NAT, the TURN server needs to be very careful > and send the STUN Response using the source IP address of the STUN > request. Otherwise, the TURN server's response will not get through > the symmetric NAT at all. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > ------=_Part_13163_1974133.1213566521027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline So, my take-away from this is that nothing needs to be changed?

On Fri, Mar 21, 2008 at 10:08 AM, Dan Wing <dwing@cisco.com> wrote:

> > draft-ietf-behave-rfc3489bis-15, bottom of page 6:
> >
> > For request/response transactions, this transaction ID allows
> > the client to associate the response with the request that
> > generated it; for indications, this serves as a debugging aid.
> >
>
> so what you are saying is that, by default, the STUN Client
> does not check the source address of the STUN Response.

I didn't see text in rfc3489bis that said the port of the response
needed to be checked. I believe behavior-discovery needs to
send response packets from different ports and from different
IP addresses in order to do some of its checks.

> But it can be overridden by the usage, like e.g. ICE:
>
>
>
> 7.1.2.2. Success Cases
>
> A check is considered to be a success if all of the following are
> true:
>
> o the STUN transaction generated a success response
>
> o the source IP address and port of the response equals the
> destination IP address and port that the Binding
> Request was sent
> to
>
> o the destination IP address and port of the response match the
> source IP address and port that the Binding Request was
> sent from

Right.

> Is is specified in the TURN-07 draft that the TURN client should check
> the source address of any STUN Response, btw?

I don't believe so.

But, considering that TURN is most often used when the TURN client
is behind a 'symmetric' NAT, the TURN server needs to be very careful
and send the STUN Response using the source IP address of the STUN
request. Otherwise, the TURN server's response will not get through
the symmetric NAT at all.

-d

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

------=_Part_13163_1974133.1213566521027-- --===============0212281086== 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://www.ietf.org/mailman/listinfo/behave --===============0212281086==-- From behave-bounces@ietf.org Sun Jun 15 19:25:56 2008 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537E93A69F1; Sun, 15 Jun 2008 19:25:56 -0700 (PDT) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FBF3A683D for ; Sun, 15 Jun 2008 19:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpJtztEgXIqe for ; Sun, 15 Jun 2008 19:25:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 20A503A69F1 for ; Sun, 15 Jun 2008 19:25:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,649,1204531200"; d="scan'208";a="113728580" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2008 19:26:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5G2QZnj027193; Sun, 15 Jun 2008 19:26:35 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5G2QYJ3002218; Mon, 16 Jun 2008 02:26:34 GMT From: "Dan Wing" To: "'Derek MacDonald'" References: <47D99773.60705@db.org> <074101c88a16$bf6a0890$c5f0200a@cisco.com> <47E3E93D.8040705@db.org> <04aa01c88b76$24d834d0$c5f0200a@cisco.com> Date: Sun, 15 Jun 2008 19:26:34 -0700 Message-ID: <00b301c8cf58$659626f0$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjPMZT8aOb321/kTV+LH32f1im8tAAJsgnQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2550; t=1213583195; x=1214447195; c=relaxed/simple; s=sjdkim4002; 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]=20Determining=20NAT=20Filterin g=20Behavior |Sender:=20; bh=qncDMLE1sa5iRuWnERQZr06bIdiFcOCixq/zN19ox5s=; b=Oryp+PU5H1WXCka8op3Is2QCWxfZ8vgtszhf1cV14hqvz/h6LbcQbNM2sX epxft4geRUsSLMLSoD7jD8TrPzmgt4ZP4TCAE1FBJVZDYIrqf2Sx3k6hua4X Zzqs9V1eWm; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' , 'Philip Matthews' Subject: Re: [BEHAVE] Determining NAT Filtering Behavior X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: derek.macdonald@gmail.com > [mailto:derek.macdonald@gmail.com] On Behalf Of Derek MacDonald > Sent: Sunday, June 15, 2008 2:49 PM > To: Dan Wing > Cc: Alfred E. Heggestad; Behave WG; Philip Matthews > Subject: Re: [BEHAVE] Determining NAT Filtering Behavior > > So, my take-away from this is that nothing needs to be changed? That is my summary, yes. -d > On Fri, Mar 21, 2008 at 10:08 AM, Dan Wing wrote: > > > > > > draft-ietf-behave-rfc3489bis-15, bottom of page 6: > > > > > > For request/response transactions, this > transaction ID allows > > > the client to associate the response with the request that > > > generated it; for indications, this serves as a > debugging aid. > > > > > > > so what you are saying is that, by default, the STUN Client > > does not check the source address of the STUN Response. > > > I didn't see text in rfc3489bis that said the port of > the response > needed to be checked. I believe behavior-discovery needs to > send response packets from different ports and from different > IP addresses in order to do some of its checks. > > > > But it can be overridden by the usage, like e.g. ICE: > > > > > > > > 7.1.2.2. Success Cases > > > > A check is considered to be a success if all of > the following are > > true: > > > > o the STUN transaction generated a success response > > > > o the source IP address and port of the response > equals the > > destination IP address and port that the Binding > > Request was sent > > to > > > > o the destination IP address and port of the > response match the > > source IP address and port that the Binding Request was > > sent from > > > Right. > > > > Is is specified in the TURN-07 draft that the TURN > client should check > > the source address of any STUN Response, btw? > > > I don't believe so. > > But, considering that TURN is most often used when the > TURN client > is behind a 'symmetric' NAT, the TURN server needs to > be very careful > and send the STUN Response using the source IP address > of the STUN > request. Otherwise, the TURN server's response will > not get through > the symmetric NAT at all. > > -d > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 16 03:20:55 2008 Return-Path: