From behave-bounces@ietf.org Fri Jun 01 13:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAiq-0004kR-B3; Fri, 01 Jun 2007 13:15:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuAio-0004ib-Kh for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 13:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAio-0004h2-A1; Fri, 01 Jun 2007 13:15:30 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuAin-0008Gv-1H; Fri, 01 Jun 2007 13:15:30 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:56988) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HuAig-0007Vf-Ez; Fri, 01 Jun 2007 18:15:22 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 1 Jun 2007 18:15:23 +0100 To: IETF AVT WG , behave@ietf.org, mmusic X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Xavier Marjou , Tom Taylor , Joerg Ott , Jean-Francois Mule , "Dan Wing \(\(dwing\)\)" Subject: [BEHAVE] Moving draft-marjou-behave-app-rtp-keepalive to AVT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org There has been some private discussion on adopting the draft on Application Mechanisms for maintaining alive NAT mappings associated with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an AVT working group draft. This has previously been discussed in AVT, BEHAVE and MMUSIC. Opinions on whether this draft should become a working group draft, and on the appropriate home for it, are solicited by 8 June 2007. Colin (as AVT co-chair) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 01 14:09:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBYz-0005q8-Oi; Fri, 01 Jun 2007 14:09:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuBYx-0005pg-Kg for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBYx-0005pV-Ae; Fri, 01 Jun 2007 14:09:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuBYx-0006XO-1f; Fri, 01 Jun 2007 14:09:23 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2007 11:09:22 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="157623593:sNHT46360602" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l51I9M8m025733; Fri, 1 Jun 2007 11:09:22 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l51I9G20023088; Fri, 1 Jun 2007 18:09:16 GMT From: "Dan Wing" To: "'Colin Perkins'" , "'IETF AVT WG'" , , "'mmusic'" Date: Fri, 1 Jun 2007 11:09:16 -0700 Message-ID: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcekcHgB7Z2/vHEaSLOivZMtDF4I4gABfTZQ In-Reply-To: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1760; t=1180721362; x=1181585362; 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=20Moving=20draft-marjou-behave-app-rtp-keepalive=20to=2 0AVT |Sender:=20; bh=27wsY7m54nhgtgcQ6ZG99GA7h+ssM7bK44h6cpMNfGU=; b=tw4mAUjhG6RgV9K9h4gq66cbC8jALyBSZ+EXUrkAlqp0weiOOUl7Zdw8G4td11XmyQrg2OvO wj5eQ9tk1howHHa3ac5eaBOgn+ymsnOPhV1oyXM15oBtGOggOUvpA+8D; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Xavier Marjou' , 'Tom Taylor' , 'Joerg Ott' , 'Jean-Francois Mule' Subject: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > There has been some private discussion on adopting the draft on > Application Mechanisms for maintaining alive NAT mappings associated > with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an > AVT working group draft. This has previously been discussed in AVT, > BEHAVE and MMUSIC. Opinions on whether this draft should become a > working group draft, and on the appropriate home for it, are > solicited by 8 June 2007. > > Colin (as AVT co-chair) We need a document that consolidates NAT keepalive mechanisms for UDP-based protocols, most notably RTP (and, to a lesser extent, SIP). Currently this is spread in various documents and there is no consolidated guidance to implementtors on the strength or weakness of various approaches. Section 4 of Xavier's document shows the current state of the art -- 7 different keepalive techniques are in various levels of active use. Most of the keepalive techniques apply to RTP, and thus AVT seems the best home. There are a few exceptions which don't fit into AVT, such as the keepalive technique used by SIP Outbound (draft-ietf-sip-outbound), but I don't see the exceptions as significant enough to resist making this an AVT WG item. If we had an "RAIWG" (akin to TSVWG), it might fit best there, but we don't have one. It doesn't quite fit into BEHAVE, as NATs only care to see a UDP packet is occasionally sent to the peer and NATs don't care what sort of UDP packet is sent; however, the receiving peer may very much care if it's a STUN packet, a 0-byte packet, or the 5 other types of packets described in Xavier's document. I support adding a milestone to AVT for keepalives, and adopting that document to meet that milestone. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 01 15:12:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCXn-0005Ek-D4; Fri, 01 Jun 2007 15:12:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuCXm-0005Ef-5y for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:12:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCXl-0005EX-SZ for behave@ietf.org; Fri, 01 Jun 2007 15:12:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCXk-0005Ep-8A for behave@ietf.org; Fri, 01 Jun 2007 15:12:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2007 12:12:12 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="489996693:sNHT52767348" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l51JCB3V014067; Fri, 1 Jun 2007 12:12:11 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l51JCA20011999; Fri, 1 Jun 2007 19:12:10 GMT From: "Dan Wing" To: , Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Fri, 1 Jun 2007 12:12:10 -0700 Message-ID: <08ed01c7a480$c1adf200$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceiwoNlSHQDmUylSKG6h5EoqNHhCQABHgaAAG5GSGA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5527; t=1180725131; x=1181589131; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=HGrPiiaE2Bh6ScPlob4foVbaUubYreziAQJPIHFLj/E=; b=HQgsKxyLS6Y8LqWUNSPz/JebVeIHXQ+2AECgzPZY/LZPU5xo3GuDPYo0y3Y1261R7ti2iqUZ PSOhVA73mOAH5pa+mJ6YiZMsJ1MWm3zwiljRDiYDhvsDH5AIcH9q8B+D; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: behave@ietf.org, philip_matthews@magma.ca X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > I think STUN NAT control would be very valuable. > > Explicit NAT/FW control in general is important especially > for wireless devices, where keepalives (especially for UDP) > are really bad for battery consumption. This is not just a > nice-to-have optimization, but I believe that in practice > you could not use Internet-based VoIP/IM services over e.g. > HSDPA or WiMAX, if you had to do the keepalives in the > current way. > > What makes STUN interesting compared to e.g. NSIS is its > incremental deployment path. STUN is already supported in > many SIP and XMPP clients, and the popularity is increasing. > An existing STUN client implementation can be relatively > easily extended to support NAT control as well (small > thing compared to e.g. full ICE support). STUN NAT control > would then very well fit into the process how STUN is > otherwise used, so the cost would be quite small even if > there were no STUN-capable NATs on client's path. STUN- > capable NATs could then be gradually deployed to improve > the situation. Frankly, I don't see a similar deployment > potential for NSIS. > > In comparison to UPnP STUN has certain technical benefits > like the ability to deal with nested NATs. Also, UPnP is > quite limited to local area use and would not solve the wide- > area wireless access issue I mentioned in the beginning. > > To have best possible value, I think STUN NAT control should > also have a way to deal with firewalls without NATs, i.e. there > would have to be a way to discover if there are STUN capable > firewalls on the path. Thanks for your note of support. I added a capability to discover firewalls in the -02 document via a 'tagging' mechanism, which is similar to how NSIS/TIST/NLS find their on-path NSIS/TIST/NLS-aware devices, yet still provides the incremental deployment of STUN and STUN Control. It's in section 5.3 of the -02 version of the document (which appears to not have yet been posted), available at: http://svn.resiprocate.org/rep/ietf-drafts/dwing/draft-wing-behave-nat-contr ol-stun-usage-02.html#anchor7 > Of course, the more we add to the protocol the less obvious > the incremental deployment argument becomes. > > So, in summary: This is a pressing problem. None of the existing > solutions look promising for getting deployed. STUN NAT control has > certain aspects that would make the deployment more > incremental and thus easier. Thus, I am very supportive for the > approval of the BoF. Thanks again, -d > Regards, > Markus > > > > >-----Original Message----- > >From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >Sent: 30 May, 2007 16:57 > >To: Magnus Westerlund > >Cc: behave@ietf.org; Philip Matthews; Dan Wing > >Subject: Re: [BEHAVE] NAT Control STUN Usage > > > >Magnus Westerlund skrev: > >> Philip Matthews skrev: > >>> Sorry to be coming into this conversation late. > >>> I am just catching up on various mailing lists after > >finishing my drafts. > >>> > >>> BEHAVE is chartered to work on STUN. > >>> STUN requires STUN servers to work, and defined how they behave. > >>> Why shouldn't we recommend placing some of the servers > into NATs as > >>> this draft does? > >>> > >>> This draft is trying to address the problem of finding the > >allocated > >>> mappings for nested NAT cases. I think this problem is an > important > >>> one to solve, because nested NATs are becoming more and > more common. > >>> > >>> I think BEHAVE is a good place to work on a solution to > >this problem, > >>> and I think the proposed solution is reasonable. > >>> > >>> I think it would be silly to NOT solve this problem just > because of > >>> charter issues. > >>> > >> > >> The problem is that large parts of this problem already has been > >> solved in the numerous NAT control protocols. Even in IETF > >we have two > >> different WG currently chartered with solving NAT control issues, > >> MIDCOM and NSIS. Going in this new direction for BEHAVE needs IETF > >> wide consensus and also good arguments why previous > efforts are not > >> solving the problem. So if you are interested in this > issue, please > >> get together and start discussing having a BOF. > >> > > > >Hi, > > > >Dan has requested a BOF on this topic. But I still haven't > >seen much debate why we would need something other than what > >is already under development within the IETF. I would > >appreciate some discussion and clarification before making any > >decision if there should be an BOF or not. > > > >Magnus Westerlund > > > >IETF Transport Area Director & TSVWG Chair > >------------------------------------------------------------- > --------- > >Multimedia Technologies, Ericsson Research EAB/TVM/M > >------------------------------------------------------------- > --------- > >Ericsson AB | Phone +46 8 4048287 > >Torshamsgatan 23 | Fax +46 8 7575550 > >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >------------------------------------------------------------- > --------- > > > > > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www1.ietf.org/mailman/listinfo/behave > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 01 15:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCdO-0003Io-61; Fri, 01 Jun 2007 15:18:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuCdN-0003Ii-48 for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCdM-0003Ia-QY for behave@ietf.org; Fri, 01 Jun 2007 15:18:00 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCdL-0005ei-H5 for behave@ietf.org; Fri, 01 Jun 2007 15:18:00 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2007 12:17:59 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="489998989:sNHT45883998" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l51JHwRH021664; Fri, 1 Jun 2007 12:17:58 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l51JHwaI015035; Fri, 1 Jun 2007 19:17:58 GMT From: "Dan Wing" To: "'Melinda Shore'" , "'Magnus Westerlund'" Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Fri, 1 Jun 2007 12:17:58 -0700 Message-ID: <08ee01c7a481$90ab2460$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acei4GCTnxvYcA7TEdy+zwAKleNSdABoJ2+A In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1926; t=1180725479; x=1181589479; 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]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=IHl1T277YXQgfrITzVncM8kZJ7Epm1zD1wVGIgVIuAc=; b=R9j1ouy2N3zc296ZnuGoxCWu1k2452cK1QxGpshy1aFlu4MalhDLeP2mKz/Qepht/IOCvZsp 1YSnslI3Y6Ev8Xahoa1p7ReYNdvQTqCHICHG6cgcAVB35GQY6xpiGEQW; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: behave@ietf.org, 'Philip Matthews' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Melinda Shore [mailto:mshore@cisco.com] wrote: > On 5/30/07 9:57 AM, "Magnus Westerlund" > wrote: > > Dan has requested a BOF on this topic. But I still haven't seen much > > debate why we would need something other than what is already under > > development within the IETF. I would appreciate some discussion and > > clarification before making any decision if there should be > > an BOF or not. > > It seems dubious to me that yet another on-path signaling protocol is > needed, or particularly that yet another on-path NAT signaling > protocol is needed, when the problems that limit the deployability > of any on-path NAT signaling protocol in the first place remain > unsolved. > > I initially brought the on-path firewall/NAT signaling work > to the IETF lo, those many years ago because it solves some hard > problems around topology and ordering. Unfortunately, however, > it requires that at least one end of a "path" not be NATted, and > that either or both peers know that it's not NATted. ICE resolves that specific problem by using multiple candidates. > The solutions that have been proposed (when they've been proposed > - there's been a lot of hand-waving) are often worse than the > problem, involving throwing new elements into the network > or sending out an effectively unbounded number of messages to > do discovery. I believe you are, here, referring to ICE's use of candidates, which I know you find unappealing. ICE does bound the number of messages it sends, and it does prioritize the discovery messages in order to quickly find a useable candidate address. > The on-path stuff is extremely appealing but I think there are some > difficult problems that need to be solved before it can be > deployed, and it seems to me that it ought to be deployable > before developing a redundant protocol. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 01 16:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDOu-00046o-DK; Fri, 01 Jun 2007 16:07:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuDOt-00046d-E3 for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 16:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDOt-00046V-3e for behave@ietf.org; Fri, 01 Jun 2007 16:07:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuDOq-00015P-RW for behave@ietf.org; Fri, 01 Jun 2007 16:07:07 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2007 13:07:04 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="157688383:sNHT59587092" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l51K74AK005738; Fri, 1 Jun 2007 13:07:04 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l51K73aI021292; Fri, 1 Jun 2007 20:07:03 GMT From: "Dan Wing" To: "'Melinda Shore'" , "'Philip Matthews'" Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Fri, 1 Jun 2007 13:07:03 -0700 Message-ID: <099d01c7a488$6c2d3cc0$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcejlDE+b/UODg+HEdy+zwAKleNSdAA7Wgeg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8913; t=1180728424; x=1181592424; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=MGyfjtCR7UQ9q4Oiqx06qRE4R8DDeQVvfJVsFJpzj4Y=; b=W4PIT1AQhX8m1tTSa5oK9nWsNuiM54rkiZ40gAhgfK8UZNEzdZOk1uKNGLdRheg+Pww3AmJY yVwy8JwL/K7wHFc6pdeiSTkuHOUmeC11mLQHsxjfme6D/VvWUQ4C8xlU; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Melinda Shore [mailto:mshore@cisco.com] wrote: > On 5/30/07 5:32 PM, "Philip Matthews" > wrote: > > I would be interested in hearing what you see as the > > deployment problems. > > Sure: > > You need to have something that can turn the message around and > provide a reply, That would be a STUN server, in the case of today's STUN, and also in the case of draft-wing-behave-nat-control-stun-usage. > or else you need to receive responses back from > the middleboxes. > The first option is unreliable It is no more unreliable than other UDP-based protocols (e.g., DNS). > and the second > option leads to the possibilities of message proliferation and > message expansion (since you can no longer rely on packet rewriting > as a way of propagating topological information). Yep, and that's only necessary if the discovery process includes firewall discovery. It wasn't until -02 that firewall discovery was in draft-wing-behave-nat-control-stun-usage; prior to that the document only did NAT discovery which doesn't lead to expansion of the response message to discover on-path NATs. I'm not sure what you're referring to with 'message proliferation' -- is that in relation to discovery or control of multiple middleboxes, all of which need to be discovered and controlled separately causing proliferation of messages to each of them, or referring to something else? > You need to have some way to secure messages when you don't > know in advance who you'll be sending messages to/receiving > messages from, That is the substantial difference between draft-wing-behave-nat-control-stun-usage and previous attempts in this space (e.g., UPnP, MIDCOM, NSIS). With draft-wing-behave-nat-control-stun-usage, the security model is easier because you're using the same host port ('socket') to open the NAT binding as you're using to discover on-path NATs as you're using to request the NAT to extend its binding timeout. Most other approaches (e.g., MIDCOM and NSIS) do need a more involved security model because they need to create some association between the host and its NAT and what the host wants the NAT to do. To another extreme, other approaches (e.g., UPnP and NAT-PMP (Bonjour)) allow any internal host to request and open any NAT binding it wants -- for other hosts or for other ports on the same host. This makes STUN, and STUN Control, unique -- in order to open a binding for a port, you need to send a packet from that port, and in order to adjust its binding duration you need to send a packet from that same port and be able to respond to the NAT's nonce challange. This means to adjust someone's NAT binding using draft-wing-behave-nat-control-stun-usage the attacker needs to be on-path between the host and its NAT -- such an attacker is able to already cause much harm to existing protocols such as DNS and TCP which cannot adequately defend themselves from that same on-path attacker. > and you'll be doing it in situations where you're > trying to limit packet size (avoid UDP fragmentation) draft-wing-behave-nat-control-stun-usage only increases packet size with the new 'tagging' feature, added in -02 to support Markus' request for discovery of on-path firewalls. This discovery adds 12 bytes to the STUN Response packet for every firewall that wants to be separately controlled using STUN Control. The typical STUN Response packet is approximately 150 bytes (including IP and UDP headers). I think we're fine -- we can have about 30 on-path firewalls before exceeding 512 bytes. (I chose 512 bytes because that's what DNS chose and it seems reasonable.) > and limit computational load (public key operations in a > middlebox). We found that group keys are an excellent solution > for use within a single security domain, but are obviously > unsuitable for use in situations in which you might be crossing > arbitrary administrative boundaries and can't know in advance > who they'll be. STUN Control has no need for such heavy-handed security because each port on the host can only adjust its own bindings on the NAT. Crossing administrative boundaries isn't possible with typical NAPTs because a packet has to originate from behind the NAPT in order to create the binding on the NAPT. Anyway, handling authorization across domains isn't related to what draft-wing-behave-nat-control-stun-usage attempts to address because a host can only control NAT bindings that it, itself created with its own UDP port. As the host didn't create NAPT bindings on public interfaces of another administrative domain's NAT, it cannot control them. The other administrative domain is responsible for its own policy -- just as today they are responsible for whatever their NAT traversal scheme is (if any) and for keeping their NAT bindings alive (if any), their own HTTP proxies, and their own firewall policies and whatever else they like to run. > One end or the other end has to have a public address/presence. > If neither end has a public address or presence, that presence > has to be outsourced to some other device. That often means > dropping yet another box (a relay, for example) into both ends > of the network. The placement of the relay has to be topologically > appropriate to the endpoints or else the relay ends up being > a sort of SBC. > > If you do go with a relay, you have to have some way to associate > it with the endpoint and you have to have some way to publicize the > association. The way that's typically handled right now is through > telephony signaling. In fact, this whole thing is looking an > awful lot like a VoIP network, and it's not actually very useful > for other applications. (Presumably that's the reason for an > interest in using STUN rather than an actual signaling protocol, > as well). > > It's doable, but it's not doable in a general way and it's really > going to work only in very constrained environments. It's not an > 80/20 solution, but rather a 20/80 one. Your points in the above two paragraphs are related to ICE and if ICE determines (through its connectivity checks) that it needs a relay (a TURN server) or if ICE discovers (through its connectivity checks) if can establish connectivity without a relay using IP addresses learned via STUN. This is interesting but not germane to draft-wing-behave-nat-control-stun-usage. Further, the existing deployments of ICE, on the Internet, have demonstrated it works 100% of the time. I do hope the vendors that have shared that information with me privately are able to comment to that effect publicly in this thread. > And, by the way, STUN would probably need substantial changes > to the protocol machinery in order to handle state maintenance. > Packetization is really not that interesting (a little interesting, > but not a lot) - what matters is how the protocol behaves. "NAT > control" installs state in middleboxes - you'll need to be able > to handle errors like transmission failures, device reboots, > routing changes, and so on. You'll also need to be able to > delete the state you install. Merely sending a UDP or TCP packet across a NAT creates state -- the NAT binding. All draft-wing-behave-nat-control-stun-usage does is query the NAT for its binding duration and provide a way to adjust that duration -- and that query and control is only for the same IP address and same UDP port that created that initial state on the NAT. > By the time you're done tweaking it so > that it will be a useful state maintenance tool you'll have a > full-blown signaling protocol, only a quirky one that's not > very general and probably isn't very different from other signaling > protocols aside from packetization. (FWIW, a few years ago I > wrote up a "STUN-based Signaling" specification that uses the NLS > state machine but STUN packetization, and there should still be > copies floating around ID archives - it solves a political problem > but not a technical one and was rightly ignored). draft-wing-behave-nat-control-stun-usage avoids this complication by using the same IP address and UDP port on the host that created the NAT binding. > I could accept (and do accept) the argument that NSIS is not a > good choice for situations in which the substantial set up costs > can't be amortized well, but that's not the argument that's being > presented here. > > Anyway, the broader point is that we've already done on-path > signaling six ways from Sunday and the hard problems association > with NAT signaling remain unsolved. I have a hard time seeing why > it's a good idea to create yet another protocol while continuing to > avoid dealing with the problems associated with the architecture. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 01 16:22:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDdO-0006tG-M3; Fri, 01 Jun 2007 16:22:06 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuDdM-0006sa-JD for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 16:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDdM-0006sL-60 for behave@ietf.org; Fri, 01 Jun 2007 16:22:04 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuDdL-0003Gr-Oj for behave@ietf.org; Fri, 01 Jun 2007 16:22:04 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2007 13:22:04 -0700 X-IronPort-AV: i="4.16,373,1175497200"; d="scan'208"; a="376900644:sNHT49391716" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l51KM3qG024830; Fri, 1 Jun 2007 13:22:03 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l51KM2aI003807; Fri, 1 Jun 2007 20:22:02 GMT From: "Dan Wing" To: "'Melinda Shore'" , "'Philip Matthews'" Subject: RE: [BEHAVE] NAT Control STUN Usage Date: Fri, 1 Jun 2007 13:22:02 -0700 Message-ID: <099e01c7a48a$83f67e00$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcejtK1I7BIwvg+nEdyhPwAKleNSdAA0+YQg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4693; t=1180729323; x=1181593323; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT=20Control=20STUN=20Usage |Sender:=20; bh=BwyRIZF0Zaxgio2tgm+iVfKK64GRv/WOSXI59Aga+pQ=; b=BVHz9omNE6vCK8aTCKveRY81HcJbs7eWUI+9M1sjKNwE0BsmrQW/UzWxVmTL1217GXu/Q392 DBfqye1yfRlWy6CTGCe49otqGP27XKQhCC44JHnhvsC19tZ5cn11gYYk; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Melinda Shore [mailto:mshore@cisco.com] wrote: > On 5/31/07 2:12 PM, "Philip Matthews" > wrote: > > If I understand you correctly, STUN currently takes the > > first approach > > by requiring a STUN server somewhere in the network. And > > you consider > > this unreliable because there is nothing that forces > > someone to provide > > a STUN server? Do I understand you correctly? > > It forces the STUN server to be 1) addressable (not so much > of an issue), and 2) in a topologically-appropriate location. > Problem 2) has led to the development of ICE, about which the > less is said the better. > > > Some, but not all, of them are mitigated by the Shared > > Secret exchange, but in practice not many people seem to > > implement this. > > Well, on the one hand the exchange is of really limited utility > since it doesn't prove identity, but on the other hand it's the > only protection (other than obscurity) against an attacker. > Explicit signaling is always going to be more secure, *if* > you can authenticate the NAT. RFC3489's shared secret exchange only provides protection against an attacker who is on-path during subsequent UDP communications with your STUN server. The protection prevents that attacker from spoofing STUN responses; the attacker could spoof those responses in order to: 1. cause you to insert a victim's IP address into your subsequent SDP (in order to use you as a launchpad for a DoS attack against a victim), or to 2. give you an IP address they control so that you use it in your subsequent SDP (in order that they can guarantee they'll be one of the candidate IP addresses and increase the chance they'll be on-path for your subsequent communication) (1) was a significant attack when we had only RFC3489 (STUN). With the advent of ICE and ICE's connectivity checks, only 6 packets would be sent towards that victim machine (if the victim isn't listening for STUN packets); less if the victim is listening for STUN and sends a STUN error response. (2) the attacker was already on-path between the STUN client and its STUN server (in order to spoof the STUN response), so it's possible -- depending on where the attacker is located -- that they might not be on path for the natural communication with your peer. An attacker located next to the STUN server might be interested in this attack, for example; but an attacker in the same coffeeshop (on the same 802.11 network, for example) would not need to perform this active attack because they will still be on-path for your subsequent communication with your intended peer. (2) is also thwarted by using SRTP. > > All he is proposing (as far as > > I know), > > is to discover the binding that a NAT has installed for a > > particular > > local host and port, > > and then either query the NAT for the timeout value associated with > > the binding, or suggest a value to the NAT. > > He is NOT proposing to use STUN to signal the connection, and the > > only other > > involvement of STUN will be as part of ICE to select a path for the > > media. > > Look, STUN was "just" going to be used until midcom was finished. And > then it was "just" to be used in cases where a NAT cannot be modified. > And then BEHAVE was "just" going to define NAT behavior so that STUN > would work across it. And now it's "just" putting a STUN server > inside a NAT so that a NAT is basically a midcom device. draft-wing-behave-nat-control-stun-usage is outside of BEHAVE's current charter, which is why a BoF has been requested to discuss if and how draft-wing-behave-nat-control-stun-usage should be standardized in IETF. > Take another look at the draft - it's *definitely* defining on-path > signaling to NATs, Yes, it is. > and it's doing it without referencing existing on-path signaling > protocols. draft-wing-behave-nat-control-stun-usage's NAT discovery and especially its NAT Control technique works differently than previous NAT control techniques. All other techniques have involved a separate control channel (SNMP for MIDCOM; UPnP invented its own XML-based protocol), whereas draft-wing-behave-nat-control-stun-usage uses the same UDP port that originally opened the NAT binding in order to control that very same NAT binding's timeout. There is overlap with draft-wing-behave-nat-control-stun-usage-02's new "tagging" discovery technique with NSIS, TIST, and NLS; the new "tagging" discovery technique is used to find firewalls (not NATs). I included a reference to NSIS, TIST, and NLS when I added that new discovery technique. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 01 19:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGZ4-0007BG-4Z; Fri, 01 Jun 2007 19:29:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HuGZ2-000762-Vt for behave-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 19:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGZ2-00075r-M3 for behave@ietf.org; Fri, 01 Jun 2007 19:29:48 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGZ1-0008DK-BI for behave@ietf.org; Fri, 01 Jun 2007 19:29:48 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Jun 2007 16:29:47 -0700 X-IronPort-AV: i="4.16,374,1175497200"; d="scan'208"; a="376926299:sNHT46036488" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l51NTkHr021301; Fri, 1 Jun 2007 16:29:46 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l51NTktV014845; Fri, 1 Jun 2007 23:29:46 GMT From: "Dan Wing" To: "'Pyda Srisuresh'" , "'Cullen Jennings'" , "'Behave WG'" Subject: RE: [BEHAVE] ICMP type 3, code 13, one more time Date: Fri, 1 Jun 2007 16:29:45 -0700 Message-ID: <0a8d01c7a4a4$bd899250$10676b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcegLg2ShZKT+5mkRvG0YT1EBGlTNgEdpCcg In-Reply-To: <276840.78180.qm@web33304.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2370; t=1180740586; x=1181604586; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20ICMP=20type=203, =20code=2013, =20one=20more =20time=20 |Sender:=20; bh=e2Jy2pdPH+YYRqcxWOgKTDsop4Oo7Tj66szliaJ15nk=; b=QJbZMr+HqnRrmvMHw5ydjKFripjgOKrCSfPihb2OYhb1iC1SjupI8qE6M7YdeYazf9Qssxgk F8pdsdp/otG6axru5oCbryniPXMwO/xcwYDzaLAIQlfnVtR7OgVyq4n5; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Yes, it appears to be the WG's consensus that ICMP type 3, error code 13 is the way to go forward. -d > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: Sunday, May 27, 2007 12:10 AM > To: Dan Wing; 'Cullen Jennings'; 'Behave WG' > Subject: RE: [BEHAVE] ICMP type 3, code 13, one more time > > Dan, > > From the e-mails below, it seems, the use of ICMP type 3, > error code 13 for > REQ-8 has WG consensus. If my read is incorrect, please summarize the > consensus. I would appreciate that. > > This is the last of the outstanding comments on the draft, > AFAIK. Once I have > the closure on this, I will be happy to get the next rev of > the draft. I > believe, the next rev of the draft should be ready for a WGLC. > > Thanks. > > regards, > suresh > > > --- Dan Wing wrote: > > > > > > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > > Sent: Thursday, May 03, 2007 3:07 PM > > > To: Behave WG > > > Subject: [BEHAVE] ICMP type 3, code 13, one more time > > > > > > > > > I was having lunch today with Srisuresh and we came to an > > > interesting > > > inside on how to resolve this. The important thing is not > if a NAT > > > thinks it's a router, host, or power tool. The important > thing is > > > what does an applications that receives the ICMP error does. One > > > observation is that it might be that you want error codes > > > sent to the inside to be different than one sent to the outside. > > > > When the NAT can't create a new mapping, the ICMP error > would only be > > sent to the inside. Afterall, it's not possible to even create a > > new mapping from the outside. > > > > > The other > > > observation is that if 9,10,13 are all soft errors - do > we want a > > > soft or hard error here? > > > > A NAT that runs out of resources (say, runs out of UDP mappings) > > seems a transient event on par with a routing error such as > > 'network unreachable' (ICMP type=3, code=0), which is classified > > as a soft error. > > > > (as individual.) > > > > -d > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 04 03:39:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv79y-0005kf-8S; Mon, 04 Jun 2007 03:39:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hv79w-0005kH-Oy for behave-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 03:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv79t-0005k1-9o; Mon, 04 Jun 2007 03:39:21 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv79r-00067C-GX; Mon, 04 Jun 2007 03:39:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l547cvtY029761; Mon, 4 Jun 2007 10:39:07 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 10:38:53 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 10:38:52 +0300 Received: from [172.21.34.187] (esdhcp034187.research.nokia.com [172.21.34.187]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l547coL1003802; Mon, 4 Jun 2007 10:38:50 +0300 In-Reply-To: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> References: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT Date: Mon, 4 Jun 2007 10:38:39 +0300 To: ext Dan Wing X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 04 Jun 2007 07:38:52.0837 (UTC) FILETIME=[66270550:01C7A67B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Godred Fairhurst , Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , Colin Perkins , tsvwg chair X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0506303413==" Errors-To: behave-bounces@ietf.org --===============0506303413== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31-772056426; protocol="application/pkcs7-signature" --Apple-Mail-31-772056426 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-1, at 21:09, ext Dan Wing wrote: > We need a document that consolidates NAT keepalive mechanisms for > UDP-based protocols, most notably RTP (and, to a lesser extent, > SIP). Currently this is spread in various documents and there > is no consolidated guidance to implementtors on the strength > or weakness of various approaches. I'm wondering if it'd make sense to add this guidance as a section in http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? Lars --Apple-Mail-31-772056426 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MDQwNzM4MzlaMCMGCSqGSIb3DQEJBDEWBBQ3AprJIczkdHUp ni8ajjCJeBImUDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAGyyaVzI2wBbZlEYPdD/0EdWeZlAEAjaelavKYe5hZGBbxm9hroSL ZOkkqUjEwbge+A0fQTTLEr4o1aMAipM8jYdq8jxKzAjc7KEwYliu64EAUCtaRX9sYPK93Juf/ZwX X0i5Oo1m78WjfqMgmJbTC0LRc2urWWB2w1SoYTMACvdm1WE0d00mb7QM5jP4tLbkpawq5bDj8djO EBbP1oqYfDZj+jHS+qc8jGzzNJtQRPBUwK4WQNRSELzsEShAV9fDVxcJ0Rv5SsE+v/hSxtyevVqx 4UF2mqWuer4H4p1s4YJ7ufyKSO+qiwXlcihAe0l4c8CcY0P1zxPYLOPU91ZM5QAAAAAAAA== --Apple-Mail-31-772056426-- --===============0506303413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0506303413==-- From behave-bounces@ietf.org Mon Jun 04 16:41:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJMS-0001x6-8g; Mon, 04 Jun 2007 16:41:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvJMQ-0001wh-SX for behave-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJMQ-0001wO-Ij; Mon, 04 Jun 2007 16:41:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJMQ-00045w-6c; Mon, 04 Jun 2007 16:41:06 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 13:41:05 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="160770180:sNHT54685206" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l54Kf5Ov005235; Mon, 4 Jun 2007 13:41:05 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l54Kex07029042; Mon, 4 Jun 2007 20:41:00 GMT In-Reply-To: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> References: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DE8B4B0-B579-4FAA-9AB2-82E397AD13F9@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 4 Jun 2007 13:40:11 -0700 To: Dan Wing X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2500; t=1180989665; x=1181853665; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[AVT]=20RE=3A=20Moving=20draft-marjou-behave-app-rtp- keepalive=20to=20AVT |Sender:=20; bh=NWWhTaNLaS5PTFm+5mpf/qMbRp7zk2g0mkob446KcQk=; b=O+5Q1Fa0xI0DzjAAaXIhf8fTWnjMSg+EuwO/2pg9IGm79x09tLz+siD8v1YmGfh+1lcBkCx3 4zBEc8l/s7XVCz1EjPBfvSWnveuYM+jOnFj6EEv6h5AjTC/G70V6oiCY; Authentication-Results: sj-dkim-6; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: behave@ietf.org, 'mmusic' , 'Xavier Marjou' , 'IETF AVT WG' , 'Joerg Ott' , 'Tom Taylor' , 'Jean-Francois Mule' , 'Colin Perkins' Subject: [BEHAVE] Re: [AVT] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org I think that the AVT WG has the right people to review and recommend way(s) to do keep alive for RTP flows - so if we are doing this work anywhere, AVT would be my preferred WG to do it in. Now that Behave has published, RFC 4787, I think it is easy for the AVT group to ensure that whatever the recommendation is, it will work with NATs that are compliant with BEHAVE. This helps resolve the issues of making sure that enough NAT people are involved with the discussion. On Jun 1, 2007, at 11:09 AM, Dan Wing wrote: >> There has been some private discussion on adopting the draft on >> Application Mechanisms for maintaining alive NAT mappings associated >> with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an >> AVT working group draft. This has previously been discussed in AVT, >> BEHAVE and MMUSIC. Opinions on whether this draft should become a >> working group draft, and on the appropriate home for it, are >> solicited by 8 June 2007. >> >> Colin (as AVT co-chair) > > We need a document that consolidates NAT keepalive mechanisms for > UDP-based protocols, most notably RTP (and, to a lesser extent, > SIP). Currently this is spread in various documents and there > is no consolidated guidance to implementtors on the strength > or weakness of various approaches. Section 4 of Xavier's > document shows the current state of the art -- 7 different > keepalive techniques are in various levels of active use. > > Most of the keepalive techniques apply to RTP, and thus AVT seems > the best home. There are a few exceptions which don't fit into > AVT, such as the keepalive technique used by SIP Outbound > (draft-ietf-sip-outbound), but I don't see the exceptions as > significant enough to resist making this an AVT WG item. If we > had an "RAIWG" (akin to TSVWG), it might fit best there, but we > don't have one. It doesn't quite fit into BEHAVE, as NATs only > care to see a UDP packet is occasionally sent to the peer and > NATs don't care what sort of UDP packet is sent; however, the > receiving peer may very much care if it's a STUN packet, a > 0-byte packet, or the 5 other types of packets described in > Xavier's document. > > I support adding a milestone to AVT for keepalives, and adopting > that document to meet that milestone. > > -d > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 04 16:55:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJa1-0000j7-3g; Mon, 04 Jun 2007 16:55:09 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvJa0-0000iw-DG for behave-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJa0-0000iK-3J; Mon, 04 Jun 2007 16:55:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJZS-0006AJ-CT; Mon, 04 Jun 2007 16:54:35 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 13:54:33 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="160777649:sNHT49214277" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l54KsX4t009539; Mon, 4 Jun 2007 13:54:33 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l54KsVV1009178; Mon, 4 Jun 2007 20:54:32 GMT From: "Dan Wing" To: "'Lars Eggert'" Subject: RE: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT Date: Mon, 4 Jun 2007 13:54:29 -0700 Message-ID: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceme3lSljjfwKCrSgiInEGwlxLVWAAbigQw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1085; t=1180990473; x=1181854473; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20RE=3A=20Moving=20draft-marjou-behave-app-r tp-keepalive=20to=20AVT |Sender:=20; bh=v4oCKRhZr00gXsdQY/MtUNXXVDumdNrVvvNytpt7ZdM=; b=boi1Bs5fnaQIZ88Zh7QNPMZYVQeya5lmGY6yOE6MrzgobkTIQ5qze3yKsX90uSuxu4usQMka mQSsbYYpYbLmRoQB+9wWWYkvK0fTwtG3kTVHSdSUAfG9VdHvWfaEw8Ec; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'Godred Fairhurst' , draft-ford-behave-app@tools.ietf.org, 'Behave WG' , 'mmusic' , 'Xavier Marjou' , 'Tom Taylor' , 'Joerg Ott' , 'IETF AVT WG' , 'Jean-Francois Mule' , 'Colin Perkins' , 'tsvwg chair' X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > On 2007-6-1, at 21:09, ext Dan Wing wrote: > > We need a document that consolidates NAT keepalive mechanisms for > > UDP-based protocols, most notably RTP (and, to a lesser extent, > > SIP). Currently this is spread in various documents and there > > is no consolidated guidance to implementtors on the strength > > or weakness of various approaches. > > I'm wondering if it'd make sense to add this guidance as a > section in > http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? I agree "send periodic UDP traffic" would be good in that document. REQ-6 of draft-ford-behave-app-05 may provide the beginnings of some useful text (CC'ing the authors of that document). As with all applications on today's Internet, an RTP application needs to be robust and able to deal with whatever is sent to it, so perhaps you're right -- an application- specific keepalive document may well be overly specific and we should, rather, document what any UDP-based application should do to prevent middleboxes (such as NATs) from clobbering a flow. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 04 19:38:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvM7y-0006ZZ-91; Mon, 04 Jun 2007 19:38:22 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvM7w-0006W9-VJ for behave-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 19:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvM7w-0006UV-LO; Mon, 04 Jun 2007 19:38:20 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvM7v-0003SO-Am; Mon, 04 Jun 2007 19:38:20 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2007 16:38:18 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="160839924:sNHT41696505" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l54NcIXE024783; Mon, 4 Jun 2007 16:38:18 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l54NcIV1019793; Mon, 4 Jun 2007 23:38:18 GMT From: "Dan Wing" To: , Date: Mon, 4 Jun 2007 16:38:17 -0700 Message-ID: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1368; t=1181000298; x=1181864298; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20FW=3A=20WGLC=3A=20draft-ietf-behave-multicast-06.txt |Sender:=20; bh=VabptqPLNoJAKwsEFlOAr0+vM1aPXCZwMMIohnz7VcI=; b=Z3fy6N5LnKinWghQ9klVeg5BChOMgSs6YaBjE6PjB/9COkn/s2n5O6ZO/LGpa1jVOlq9ZpuU sGLPErfRqq00HV5k0jH3lTqTDZ0Y6uIYhHrOS+9Z5ShxH7wWXxZxKPWM; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'Behave WG' Subject: [BEHAVE] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org The BEHAVE working group concluded its WGLC of draft-ietf-behave-multicast-06 with no comments received. I would like MBONED and MAGMA to please take a look at this draft prior to its submission to IESG. Please send replies to behave@ietf.org. Thanks! -Dan Wing chair, BEHAVE working group > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, May 17, 2007 2:47 PM > To: 'behave@ietf.org' > Subject: WGLC: draft-ietf-behave-multicast-06.txt > > The working group last call is starting now for "Multicast > Requirements for a Network Address Port Translator (NAPT)", > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas > t-06.txt: > > This document specifies requirements for a Network Address > Translator (NAT) and Network Address and Port Translator (NAPT) > that supports any-source multicast or single-source multicast. A > multicast-capable NAPT device that adheres to the requirements of > this document can optimize the operation of multicast > applications that are generally unaware of multicast NAPT > devices. > > This WGLC will finish on Thursday, May 31 (two weeks from today). > > If this WGLC is successful, I will ask for review by the > MAGMA working group and mboned@lists.uoregon.edu prior to > submitting to IESG. > > -d > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 03:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTNV-0004fv-Jy; Tue, 05 Jun 2007 03:22:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvTNS-0004fL-Ib for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 03:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTNR-0004et-DW for behave@ietf.org; Tue, 05 Jun 2007 03:22:50 -0400 Received: from an-out-0708.google.com ([209.85.132.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTNP-0006U7-PG for behave@ietf.org; Tue, 05 Jun 2007 03:22:49 -0400 Received: by an-out-0708.google.com with SMTP id c17so398883anc for ; Tue, 05 Jun 2007 00:22:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=bMG5Lu9fS//GLptoDusb74u9/DEhLj55VjjnntwrFpJG76+pZ8OEMiEw50vTxAdsBRi3/QoXRz6ePx10uRTbD+QDH6YJ+3hJlbX090taA2sEQhZiVq+yj6UdSHkRNWVgeRFld2ekEtIkMqzdz53CaM0465RcadFQty4joivSpsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=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; b=Jc4RBYyrNwMN77ubFQ7+pPNfGtEy9Zc6d6hjRI0ECyQ5ZnpFrj766D0/Y7zlmgVrn4AVWy5E/hcoTXJxuRtxMFgr5lZ5/dsX9JZV5jYOBR/Gwj4hZpeBvw/0QFMgR/U475LaAgEAM6TGzazBRyCNfj93pbjryu3HzsTZ9zvfQIA= Received: by 10.100.141.13 with SMTP id o13mr3075886and.1181028167370; Tue, 05 Jun 2007 00:22:47 -0700 (PDT) Received: by 10.100.190.17 with HTTP; Tue, 5 Jun 2007 00:22:47 -0700 (PDT) Message-ID: <458913680706050022i6ede971bo748f451356c2ab04@mail.gmail.com> Date: Tue, 5 Jun 2007 09:22:47 +0200 From: "Xavier Marjou" To: "Lars Eggert" Subject: Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT In-Reply-To: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <089301c7a477$fadbf0d0$10676b80@amer.cisco.com> <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com> X-Google-Sender-Auth: 8d3e5b3b16cba61d X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Godred Fairhurst , Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , ext Dan Wing , Colin Perkins , tsvwg chair X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org If there was a consensus about using a very easy RTP-keepalive mechanism that could even be re-used for other UDP protocols than RTP itslef (eg: an empty UDP packet), I think it could be integrated in the tsvwg-udp-guidelines document. However, there is no consensus on such a mechanism and some of the possible mechanisms really need AVT people expertise. So I would also be in favor of moving the draft to AVT. Xavier On 6/4/07, Lars Eggert wrote: > On 2007-6-1, at 21:09, ext Dan Wing wrote: > > We need a document that consolidates NAT keepalive mechanisms for > > UDP-based protocols, most notably RTP (and, to a lesser extent, > > SIP). Currently this is spread in various documents and there > > is no consolidated guidance to implementtors on the strength > > or weakness of various approaches. > > I'm wondering if it'd make sense to add this guidance as a section in > http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? > > Lars > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > > > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 08:57:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYao-0002qS-0s; Tue, 05 Jun 2007 08:56:58 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvYam-0002em-Pr for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 08:56:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYam-0002by-EK; Tue, 05 Jun 2007 08:56:56 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYak-0007KH-So; Tue, 05 Jun 2007 08:56:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2007 15:57:45 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E77B3@IsrExch01.israel.polycom.com> In-Reply-To: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving draft-marjou-behave-app-rtp-keepalive to AVT Thread-Index: AcekcI3nU1nGOa0RQoq47/CcfLvnbgC/3a7Q From: "Even, Roni" To: "Colin Perkins" , "IETF AVT WG" , , "mmusic" X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I think that defining the keepalive for RTP that will not break RTP is an important work and can be done in AVT.=20 I read the draft and it looks like a good start. I support as having it an AVT working group draft Roni Even=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Friday, June 01, 2007 8:15 PM > To: IETF AVT WG; behave@ietf.org; mmusic > Cc: Even, Roni; Tom Taylor; Dan Wing ((dwing)); Cullen Jennings; Joerg > Ott; Xavier Marjou; Jean-Francois Mule; Magnus Westerlund > Subject: Moving draft-marjou-behave-app-rtp-keepalive to AVT >=20 > There has been some private discussion on adopting the draft on > Application Mechanisms for maintaining alive NAT mappings associated > with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an > AVT working group draft. This has previously been discussed in AVT, > BEHAVE and MMUSIC. Opinions on whether this draft should become a > working group draft, and on the appropriate home for it, are > solicited by 8 June 2007. >=20 > Colin (as AVT co-chair) _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 11:05:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvabD-000052-IW; Tue, 05 Jun 2007 11:05:31 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvabC-00004r-Gq for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 11:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvabC-0008WP-7M; Tue, 05 Jun 2007 11:05:30 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvab9-0005eW-SC; Tue, 05 Jun 2007 11:05:30 -0400 Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:62774 helo=[192.168.0.4]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1Hvab7-00056S-V8; Tue, 05 Jun 2007 16:05:26 +0100 In-Reply-To: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.cisco.com> References: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT Date: Tue, 5 Jun 2007 16:05:29 +0100 To: Lars Eggert , Dan Wing X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Godred Fairhurst , draft-ford-behave-app@tools.ietf.org, Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , tsvwg chair X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 4 Jun 2007, at 21:54, Dan Wing wrote: >> On 2007-6-1, at 21:09, ext Dan Wing wrote: >>> We need a document that consolidates NAT keepalive mechanisms for >>> UDP-based protocols, most notably RTP (and, to a lesser extent, >>> SIP). Currently this is spread in various documents and there >>> is no consolidated guidance to implementtors on the strength >>> or weakness of various approaches. >> >> I'm wondering if it'd make sense to add this guidance as a >> section in >> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines? > > I agree "send periodic UDP traffic" would be good in that > document. REQ-6 of draft-ford-behave-app-05 may provide the > beginnings of some useful text (CC'ing the authors of that > document). > > As with all applications on today's Internet, an RTP > application needs to be robust and able to deal with whatever > is sent to it, so perhaps you're right -- an application- > specific keepalive document may well be overly specific and > we should, rather, document what any UDP-based application > should do to prevent middleboxes (such as NATs) from > clobbering a flow. The udp-guidelines draft should probably outline what sort of keep alive mechanism is needed, but the implementation is likely protocol specific, and should be done by the group designing that protocol, I think. -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 11:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvagO-0001H5-N3; Tue, 05 Jun 2007 11:10:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvagN-0001Gj-AY for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 11:10:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvagN-0001Gb-0u; Tue, 05 Jun 2007 11:10:51 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvagL-0006bI-J4; Tue, 05 Jun 2007 11:10:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55FAITB020666; Tue, 5 Jun 2007 18:10:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:10:34 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:10:33 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:10:33 +0300 Received: from [172.21.39.184] (esdhcp039184.research.nokia.com [172.21.39.184]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55FAVKK006865; Tue, 5 Jun 2007 18:10:31 +0300 In-Reply-To: References: <05cf01c7a6ea$8cb552c0$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <73F566CA-38E1-4E83-958F-147D56283036@nokia.com> From: Lars Eggert Subject: Re: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT Date: Tue, 5 Jun 2007 18:10:19 +0300 To: "ext Colin Perkins" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 05 Jun 2007 15:10:33.0232 (UTC) FILETIME=[A9A8E100:01C7A783] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Godred Fairhurst , draft-ford-behave-app@tools.ietf.org, Behave WG , mmusic , Xavier Marjou , Tom Taylor , Joerg Ott , IETF AVT WG , Jean-Francois Mule , Dan Wing , tsvwg chair X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1534520620==" Errors-To: behave-bounces@ietf.org --===============1534520620== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-66-885556731; protocol="application/pkcs7-signature" --Apple-Mail-66-885556731 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-5, at 18:05, ext Colin Perkins wrote: > The udp-guidelines draft should probably outline what sort of keep > alive mechanism is needed, but the implementation is likely > protocol specific, and should be done by the group designing that > protocol, I think. Makes sense to me. Lars --Apple-Mail-66-885556731 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MDUxNTEwMjBaMCMGCSqGSIb3DQEJBDEWBBRbj05Hu7iAJBLQ 7bGQRy7UcNWDWzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAp1uwyPmKHMl8siPcSELxzVj6XfhFRWcVSxcaft3yD+5QNVuJ2rab ASyq+rULH1fzS81a6jW+A9g4YaKnexx8PvHYWQ6UAF1FHfqmnPL7D2exGYUUxpfqCtXjgVYu1UaD HUPRn50xzIm4bmQsnD59RBacjOQfNl3qEGsBjwJBYNpbcIEs3DR0XBIYqyqfntSuILFhQHaq1cHa PptT12kZEcPQ4+l1/r+ObHhMTKvIdH3muQtiCEuLx5MmZRji8NkQO+S2pGvdBJGcfwkCRBDnKhN+ RE1JU7AzsnN1lhTf5Zr5GJ3rqT4PUaFj4/S/mHJEWfCrPJ+2Il/5NBRlbs55XwAAAAAAAA== --Apple-Mail-66-885556731-- --===============1534520620== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1534520620==-- From behave-bounces@ietf.org Tue Jun 05 13:27:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcoB-0000EU-Pe; Tue, 05 Jun 2007 13:27:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvZc1-0004Qy-Go for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 10:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZc1-0004Qp-7I; Tue, 05 Jun 2007 10:02:17 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZbz-0002jB-SP; Tue, 05 Jun 2007 10:02:17 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l55E2EZC007676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2007 07:02:15 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l55E2Eom005163; Tue, 5 Jun 2007 07:02:14 -0700 (PDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l55E2D0I005134; Tue, 5 Jun 2007 07:02:14 -0700 (PDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:02:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2007 10:02:13 -0400 Message-ID: In-Reply-To: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gAB425SA= References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> From: "Manfredi, Albert E" To: , , X-OriginalArrivalTime: 05 Jun 2007 14:02:13.0612 (UTC) FILETIME=[1E1882C0:01C7A77A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Tue, 05 Jun 2007 13:27:03 -0400 Cc: Subject: [BEHAVE] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Monday, June 04, 2007 7:38 PM > To: mboned@ietf.org; magma@ietf.org > Cc: 'Behave WG' > Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt >=20 > The BEHAVE working group concluded its WGLC of > draft-ietf-behave-multicast-06 with no comments received. I=20 > would like > MBONED and MAGMA to please take a look at this draft prior to=20 > its submission > to IESG. >=20 > Please send replies to behave@ietf.org. Thanks! http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt:=20 What if the NAPT or NAT device just passed IGMP queries and reports through, changing only the source address of the reports, and let the multicast router outside do all the hard work? I'm wondering whether the IGMP aggregation function is mandatory in NAT/NATP. Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 13:27:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcoL-0000JO-02; Tue, 05 Jun 2007 13:27:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvRBw-0006ZT-2T for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 01:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRBv-0006ZL-Os for behave@ietf.org; Tue, 05 Jun 2007 01:02:47 -0400 Received: from kecgate03.infosys.com ([220.227.179.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvRBu-0001EA-Py for behave@ietf.org; Tue, 05 Jun 2007 01:02:47 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by Kecgate03.infosys.com with InterScan Message Security Suite; Tue, 05 Jun 2007 10:33:12 +0530 Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:32:44 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:32:44 +0530 Received: from [10.10.10.170] ([192.168.101.134]) by BLRKECMSG01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:32:44 +0530 From: Bharat Joshi To: behave@ietf.org In-Reply-To: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Tue, 05 Jun 2007 10:18:28 +0530 Message-Id: <1181018908.3830.22.camel@magadha> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 05:02:44.0411 (UTC) FILETIME=[C08C68B0:01C7A72E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Tue, 05 Jun 2007 13:27:11 -0400 Subject: [BEHAVE] Re: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Dan, I have couple of questions and suggestions: > The BEHAVE working group concluded its WGLC of > draft-ietf-behave-multicast-06 with no comments received. I would like > MBONED and MAGMA to please take a look at this draft prior to its submission > to IESG. > > Please send replies to behave@ietf.org. Thanks! * In section 4.2, why is it that a NAPT device implementing this draft needs to aggregate IGMP message only for IGMPv3? I think if it is implementing 'RFC4605', it will anyway do the aggregation. * In case of IGMPv3, why is it that aggregation is a MUST? Also I think when one of the hosts behind the NAPT generates LEAVE and another generates JOIN simultaneously, the session will be UP till the group-timer timesout and as JOIN is also received, it will be updated and so session will always be UP. Am I mixing the session created in NAPT with the state in upstream router? * Typo "lesaving the session" -> "leaving the session" * In section 4.4, though complete Multicast Range is 224/4 but out of this range 232/8 is used for Source Specific Multicast or Single-Source Multicast. So is the following statement syntactically correct "Any-sosurce multicast (ASM) uses the IP addresses in the 224.0.0.0 - 239.255.255.255 range [IANA-ALLOC]." What I meant is that it looks to be incorrect to call this range as ASM range. * In section 4.4, a. This UDP mapping SHOULD be destroyed when the host leaves that host group. How do we find out that host has left the group? Please correct me if I am wrong. We are talking about a host behind the NAPT device generating Multicast data traffic [UDP traffic]. A multicast host does not need to join the multicast group [By sending an IGMP join message] to send multicast traffic to that group. So how does NAPT finds out when it can destroy this mapping and so this mapping will have to timeout before it can be removed. Thanks & Regards, Bharat PS: I am not subscribed to 'behave' mailing list so please reply-all or include my id in your reply. > -Dan Wing > chair, BEHAVE working group > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Thursday, May 17, 2007 2:47 PM > > To: 'behave@ietf.org' > > Subject: WGLC: draft-ietf-behave-multicast-06.txt > > > > The working group last call is starting now for "Multicast > > Requirements for a Network Address Port Translator (NAPT)", > > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas > > t-06.txt: > > > > This document specifies requirements for a Network Address > > Translator (NAT) and Network Address and Port Translator (NAPT) > > that supports any-source multicast or single-source multicast. A > > multicast-capable NAPT device that adheres to the requirements of > > this document can optimize the operation of multicast > > applications that are generally unaware of multicast NAPT > > devices. > > > > This WGLC will finish on Thursday, May 31 (two weeks from today). > > > > If this WGLC is successful, I will ask for review by the > > MAGMA working group and mboned@lists.uoregon.edu prior to > > submitting to IESG. > > > > -d > > > > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www1.ietf.org/mailman/listinfo/mboned **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 13:27:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcoT-0000NA-84; Tue, 05 Jun 2007 13:27:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvUbv-0004TF-9I for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 04:41:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUbu-0004T7-Eg for behave@ietf.org; Tue, 05 Jun 2007 04:41:50 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUbq-0001Ng-SJ for behave@ietf.org; Tue, 05 Jun 2007 04:41:50 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ50076BMSFRO@szxga03-in.huawei.com> for behave@ietf.org; Tue, 05 Jun 2007 16:41:03 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ5002XCMSCBE@szxga03-in.huawei.com> for behave@ietf.org; Tue, 05 Jun 2007 16:41:03 +0800 (CST) Received: from prasant5129 ([10.18.25.52]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJ50014YMS7UN@szxml03-in.huawei.com> for behave@ietf.org; Tue, 05 Jun 2007 16:41:00 +0800 (CST) Date: Tue, 05 Jun 2007 14:10:54 +0530 From: Prashant Jhingran In-reply-to: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> To: behave@ietf.org Message-id: <000001c7a74d$3bd3dfd0$3419120a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gABLtCxA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Tue, 05 Jun 2007 13:27:20 -0400 Cc: dwing@cisco.com Subject: [BEHAVE] RE: [magma] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prashantj@huawei.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I have following comments on this draft: Comment 1: ------------ Since NAPT is not applicable to IPv6 [RFC2460] then no need to mention MLD along with IGMP in the draft. Comment 2: ------------ In Section 4.2, aggregation is made optional while in section 4.3 its mandatory. However the reason given for failure of not implementing 4.3 is also applicable when 4.2 is not implemented. Moreover, an IGMP device should perform aggregation for optimization purposes. Therefore REQ-2 & REQ-3 should be combined and aggregation should be made mandatory for all versions of IGMP. Comment 3: ------------ On Page 4 of the draft: "based on forwarding state established by the IGMP/MLP proxy routing." It should be Should be "IGMP/MLD" instead of typo "IGMP/MLP" Regards, Prashant Jhingran Huawei Technologies +91-80-41117676 Ext -5129 Mobile:+91-9448927814 ============================================ "Sing, dance, serve, meditate and celebrate" - Sri Sri Ravi Shankar www.artofliving.org ============================================ This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ========= -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Tuesday, June 05, 2007 5:08 AM To: mboned@ietf.org; magma@ietf.org Cc: 'Behave WG' Subject: [magma] FW: WGLC: draft-ietf-behave-multicast-06.txt The BEHAVE working group concluded its WGLC of draft-ietf-behave-multicast-06 with no comments received. I would like MBONED and MAGMA to please take a look at this draft prior to its submission to IESG. Please send replies to behave@ietf.org. Thanks! -Dan Wing chair, BEHAVE working group > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, May 17, 2007 2:47 PM > To: 'behave@ietf.org' > Subject: WGLC: draft-ietf-behave-multicast-06.txt > > The working group last call is starting now for "Multicast > Requirements for a Network Address Port Translator (NAPT)", > http://www.ietf.org/internet-drafts/draft-ietf-behave-multic as > t-06.txt: > > This document specifies requirements for a Network Address > Translator (NAT) and Network Address and Port Translator (NAPT) > that supports any-source multicast or single-source multicast. A > multicast-capable NAPT device that adheres to the requirements of > this document can optimize the operation of multicast > applications that are generally unaware of multicast NAPT > devices. > > This WGLC will finish on Thursday, May 31 (two weeks from today). > > If this WGLC is successful, I will ask for review by the > MAGMA working group and mboned@lists.uoregon.edu prior to > submitting to IESG. > > -d > _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 20:47:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvjfv-0001ej-J4; Tue, 05 Jun 2007 20:46:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hvjfu-0001eY-0w for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 20:46:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvjft-0001eQ-E1; Tue, 05 Jun 2007 20:46:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvjfs-0002pX-4L; Tue, 05 Jun 2007 20:46:57 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 05 Jun 2007 17:46:55 -0700 X-IronPort-AV: i="4.16,387,1175497200"; d="scan'208"; a="159466395:sNHT43179048" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l560kttM021362; Tue, 5 Jun 2007 17:46:55 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l560ksV1014075; Wed, 6 Jun 2007 00:46:54 GMT From: "Dan Wing" To: "'Manfredi, Albert E'" , , , Subject: RE: [BEHAVE] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Date: Tue, 5 Jun 2007 17:46:54 -0700 Message-ID: <0c4201c7a7d4$2e51b300$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gAB425SAAFpE1sA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1149; t=1181090815; x=1181954815; 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]=20RE=3A=20[MBONED]=20FW=3A=20WGLC=3A=20draft -ietf-behave-multicast-06.txt |Sender:=20; bh=Ha0QT86Lp56Oc1YJ+T64jeZW84W+7AUtG2p75bTseXc=; b=MWfk7mqA/eTOYthBOoV6bj4VkT1BE4NYsTlCpi1jUqebFBpZ+IGJrOjaC5MnXtkjjgGcFY06 2lipdETC873KUcpn9fW8j0RYdVATxrP2GSHUAUU/ea7fD6jcWevD00um2jZNWTJtTb5JMcglcY CTFid29FSQepfuXFobr7vZaCo=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas > t-06.txt: > > What if the NAPT or NAT device just passed IGMP queries and reports > through, changing only the source address of the reports, and let the > multicast router outside do all the hard work? I'm wondering > whether the IGMP aggregation function is mandatory in NAT/NATP. For IGMPv3, you would have the problem described in the document, namely: Failure to do this aggregation will cause undesired temporary blackholing of multicast traffic. For example, consider two hosts behind the same NAPT. If one host is joining a session at the same time another is lesaving the session, and the NAPT merely relays the join and leave upstream, the session will be terminated and the join and leave announcements do not comply with section 5 of [RFC3376]. Based on Prashant Jhingran's comment, , I'm trying to determine if this same problem exists for IGMPv1 and IGMPv2. If so, we will need to require aggregating all flavors of IGMP to avoid that problem. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 20:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvjh1-0002Tq-Rt; Tue, 05 Jun 2007 20:48:07 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hvjh0-0002Tl-Ao for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 20:48:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvjh0-0002Td-1E for behave@ietf.org; Tue, 05 Jun 2007 20:48:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvjgz-0002uy-EU for behave@ietf.org; Tue, 05 Jun 2007 20:48:06 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jun 2007 17:48:05 -0700 X-IronPort-AV: i="4.16,387,1175497200"; d="scan'208"; a="159466842:sNHT51613839" 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 l560m4cE024529; Tue, 5 Jun 2007 17:48:04 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l560m4V1014324; Wed, 6 Jun 2007 00:48:04 GMT From: "Dan Wing" To: "'Bharat Joshi'" , Subject: RE: [BEHAVE] Re: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Date: Tue, 5 Jun 2007 17:48:04 -0700 Message-ID: <0c4301c7a7d4$57b9d3d0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1181018908.3830.22.camel@magadha> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcenlsStn7P1nesASeuv0mRq8IaSYgAOv47A DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6294; t=1181090884; x=1181954884; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20[MBONED]=20FW=3A=20WGLC=3A=20draft -ietf-behave-multicast-06.txt |Sender:=20; bh=1Kp7bqijb3HovcktRfUYZ5JvZuMDpeZtPmRFhhrNeaE=; b=ciFm9YjYG1KquYULURlEtbPSbp2LkWDy8BjSJRcWDbixfQFgXi7wxRP+Ta+njf8BrtEEegFp bViMbelW1Qnd5hBodo6wrF8Dv7DRO0ttfQoAVvU8TDn0wx5cnTu5ThHM; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Monday, June 04, 2007 9:48 PM > To: behave@ietf.org > Subject: [BEHAVE] Re: [MBONED] FW: WGLC: > draft-ietf-behave-multicast-06.txt > > > Hi Dan, > > I have couple of questions and suggestions: Thanks for your comments! > > The BEHAVE working group concluded its WGLC of > > draft-ietf-behave-multicast-06 with no comments received. > > I would like > > MBONED and MAGMA to please take a look at this draft prior > . to its submission > > to IESG. > > > > Please send replies to behave@ietf.org. Thanks! > > * In section 4.2, why is it that a NAPT device implementing this draft > needs to aggregate IGMP message only for IGMPv3? I think if it is > implementing 'RFC4605', it will anyway do the aggregation. It's my understanding that things will work -- somewhat sub-optimally -- with IGMPv1 or IGMPv2 without the NAT doing aggregation of IGMPv1/v2 messages and blindly just forwarding them upstream. If my understanding is incorrect, please let me know (it may well be; multicast is not my expertise). > * In case of IGMPv3, why is it that aggregation is a MUST? > Also I think > when one of the hosts behind the NAPT generates LEAVE and another > generates JOIN simultaneously, the session will be UP till the > group-timer timesout and as JOIN is also received, it will be updated > and so session will always be UP. Am I mixing the session created in > NAPT with the state in upstream router? Slightly after that requirement in the document is this explanation: > > Failure to do this aggregation will cause undesired > temporary blackholing of multicast traffic. For example, > consider two hosts behind the same NAPT. If one host is > joining a session at the same time another is leaving the > session, and the NAPT merely relays the join and leave > upstream, the session will be terminated and the join and > leave announcements do not comply with section 5 of target="RFC3376">. > > * Typo "lesaving the session" -> "leaving the session" Thanks, fixed. > * In section 4.4, though complete Multicast Range is 224/4 but out of > this range 232/8 is used for Source Specific Multicast or > Single-Source > Multicast. So is the following statement syntactically correct > > "Any-sosurce multicast (ASM) uses the IP addresses in the 224.0.0.0 - > 239.255.255.255 range [IANA-ALLOC]." > > What I meant is that it looks to be incorrect to call this > range as ASM range. You're right. I pulled this from the Terminology section of RFC3569 ("An Overview of Source-Specific Multicast (SSM)"). I have adjusted my document so that it describes the ASM space as 224/8 through 231/8 and 233/8 through 239/8 (with a hole for 224/8). > * In section 4.4, > > a. This UDP mapping SHOULD be destroyed when the host leaves > that host group. > > How do we find out that host has left the group? Please > correct me if I am wrong. > We are talking about a host behind the NAPT device > generating Multicast data traffic [UDP traffic]. A multicast host does > not need to join the multicast group [By sending an IGMP join message] > to send multicast traffic to that group. So how does NAPT > finds out when > it can destroy this mapping and so this mapping will have to timeout > before it can be removed. Ah, good point which I hadn't considered. I have removed that requirement. > Thanks & Regards, > Bharat > > PS: I am not subscribed to 'behave' mailing list so please > reply-all or include my id in your reply. -d > > -Dan Wing > > chair, BEHAVE working group > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Thursday, May 17, 2007 2:47 PM > > > To: 'behave@ietf.org' > > > Subject: WGLC: draft-ietf-behave-multicast-06.txt > > > > > > The working group last call is starting now for "Multicast > > > Requirements for a Network Address Port Translator (NAPT)", > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas > > > t-06.txt: > > > > > > This document specifies requirements for a Network Address > > > Translator (NAT) and Network Address and Port Translator (NAPT) > > > that supports any-source multicast or single-source > multicast. A > > > multicast-capable NAPT device that adheres to the > requirements of > > > this document can optimize the operation of multicast > > > applications that are generally unaware of multicast NAPT > > > devices. > > > > > > This WGLC will finish on Thursday, May 31 (two weeks from today). > > > > > > If this WGLC is successful, I will ask for review by the > > > MAGMA working group and mboned@lists.uoregon.edu prior to > > > submitting to IESG. > > > > > > -d > > > > > > > _______________________________________________ > > MBONED mailing list > > MBONED@ietf.org > > https://www1.ietf.org/mailman/listinfo/mboned > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION > intended solely for the use of the addressee(s). If you are > not the intended recipient, please notify the sender by > e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents > to any other person and any such actions are unlawful. This > e-mail may contain viruses. Infosys has taken every > reasonable precaution to minimize this risk, but is not > liable for any damage you may sustain as a result of any > virus in this e-mail. You should carry out your own virus > checks before opening the e-mail or attachment. Infosys > reserves the right to monitor and review the content of all > messages sent to or from this e-mail address. Messages sent > to or from this e-mail address may be stored on the Infosys > e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 05 20:53:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvjmM-0006pX-7x; Tue, 05 Jun 2007 20:53:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvjmK-0006jP-MO for behave-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 20:53:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvjmK-0006hl-C5 for behave@ietf.org; Tue, 05 Jun 2007 20:53:36 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvjmJ-0004Oo-2t for behave@ietf.org; Tue, 05 Jun 2007 20:53:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2007 17:53:35 -0700 X-IronPort-AV: i="4.16,387,1175497200"; d="scan'208"; a="377430238:sNHT46633948" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l560rYm5029618; Tue, 5 Jun 2007 17:53:34 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l560rX06016949; Wed, 6 Jun 2007 00:53:34 GMT From: "Dan Wing" To: , Date: Tue, 5 Jun 2007 17:53:33 -0700 Message-ID: <0c5301c7a7d5$1c1d66b0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000001c7a74d$3bd3dfd0$3419120a@china.huawei.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gABLtCxAAIgIkQA== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1894; t=1181091214; x=1181955214; 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[magma]=20FW=3A=20WGLC=3A=20draft-ietf-behave-multica st-06.txt |Sender:=20; bh=7RIUeQbCfYhn63Y0zSOpvoz1jSUpzrteENcPoQSV1kA=; b=QEyfRaYRaqUXtk9DWC3rRKKuUJ0ST/eqc1Pp/YfZXuGjzGwVYp//IMwpMeFnuX0PsQzuqRU7 kJSLgL0jSX+OHhVZZvLD8+zQZa1OpJtim7r1DJ8jLlf8kb5kcmKW9NQU; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Subject: [BEHAVE] RE: [magma] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Prashant Jhingran [mailto:prashantj@huawei.com] > Sent: Tuesday, June 05, 2007 1:41 AM > To: behave@ietf.org > Cc: dwing@cisco.com > Subject: RE: [magma] FW: WGLC: draft-ietf-behave-multicast-06.txt > > > Hi, > > I have following comments on this draft: > > Comment 1: > ------------ > Since NAPT is not applicable to IPv6 [RFC2460] then no need > to mention MLD along with IGMP in the draft. Removed. Thanks. > Comment 2: > ------------ > In Section 4.2, aggregation is made optional while in > section 4.3 its mandatory. > However the reason given for failure of not implementing 4.3 > is also applicable when 4.2 is not implemented. I'll have to dig into that deeper. I was under the impression the same problem (loss of a multicast stream when different listners behind the same proxy left and joined) didn't occur with IGMPv1 or v2. > Moreover, > an IGMP device should perform aggregation for optimization > purposes. Agreed, and I'll add a suggestion to that effect. (Of course, if we find that IGMPv1-3 all require aggregation in order to avoid missing portions of multicast streams during leave/join by different hosts behind the NAT, I'll drop the suggestion as it'll become a hard MUST-level requirement.) > Therefore REQ-2 & REQ-3 should be combined and aggregation > should be made mandatory for all versions of IGMP. > > Comment 3: > ------------ > On Page 4 of the draft: > "based on forwarding state established by the IGMP/MLP proxy > routing." > > It should be Should be "IGMP/MLD" instead of typo "IGMP/MLP" I fixed the typo by deleting MLD. Thanks for your review. There is another thread, CC'd to magma and mboned, where the aggregation issue was also brought up; I'll probably consolidate the conversation about that point in that thread. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 01:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvoFF-0006Qs-RS; Wed, 06 Jun 2007 01:39:45 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvoFE-0006Qm-Cn for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 01:39:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvoFC-0006Np-LX for behave@ietf.org; Wed, 06 Jun 2007 01:39:42 -0400 Received: from kecgate03.progeon.com ([220.227.179.21] helo=Kecgate03.infosys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvoFB-0005C3-Ar for behave@ietf.org; Wed, 06 Jun 2007 01:39:42 -0400 Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by Kecgate03.infosys.com with InterScan Message Security Suite; Wed, 06 Jun 2007 11:09:59 +0530 Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:09:29 +0530 Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:09:29 +0530 Received: from osfr-170.local ([192.168.101.134]) by BLRKECMSG01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:09:28 +0530 Subject: RE: [BEHAVE] Re: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt From: Bharat Joshi To: Dan Wing In-Reply-To: <0c4301c7a7d4$57b9d3d0$c2f0200a@amer.cisco.com> References: <0c4301c7a7d4$57b9d3d0$c2f0200a@amer.cisco.com> Content-Type: text/plain Organization: Infosys Technologies Ltd Date: Wed, 06 Jun 2007 10:55:01 +0530 Message-Id: <1181107502.3830.90.camel@magadha> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2007 05:39:28.0562 (UTC) FILETIME=[0CBCE920:01C7A7FD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Dan, Please see my replies in line. Thanks, Bharat > > * In section 4.2, why is it that a NAPT device implementing this draft > > needs to aggregate IGMP message only for IGMPv3? I think if it is > > implementing 'RFC4605', it will anyway do the aggregation. > > It's my understanding that things will work -- somewhat sub-optimally -- > with IGMPv1 or IGMPv2 without the NAT doing aggregation of IGMPv1/v2 > messages and blindly just forwarding them upstream. > > If my understanding is incorrect, please let me know (it may well be; > multicast is not my expertise). > Things should work even if we do not aggregate IGMPv3 message also. Why we do aggregation is that we do not want to send multiple messages upstream? Because upstream would forward multicast data traffic if he knows that there is atleast one host interested in a group. Aggregating IGMPv3 is a little more complex than V1 and V2. I just wanted to point out that if an NAPT is implementing RFC 4605 than it should be aggregating all versions of IGMP. So why do you want to specifically mention the case for IGMPv3? > > * In case of IGMPv3, why is it that aggregation is a MUST? > > Also I think > > when one of the hosts behind the NAPT generates LEAVE and another > > generates JOIN simultaneously, the session will be UP till the > > group-timer timesout and as JOIN is also received, it will be updated > > and so session will always be UP. Am I mixing the session created in > > NAPT with the state in upstream router? > > Slightly after that requirement in the document is this explanation: > > > > > Failure to do this aggregation will cause undesired > > temporary blackholing of multicast traffic. For example, > > consider two hosts behind the same NAPT. If one host is > > joining a session at the same time another is leaving the > > session, and the NAPT merely relays the join and leave > > upstream, the session will be terminated and the join and > > leave announcements do not comply with section 5 of > target="RFC3376">. > > Thats exactly why I raised this question. How does this creates an issue? This can happen in a host as well. Lets say application just started and send a join and immediately after this because of some failure, it goes down and send a leave. I am not sure what the problem is. > > * In section 4.4, though complete Multicast Range is 224/4 but out of > > this range 232/8 is used for Source Specific Multicast or > > Single-Source > > Multicast. So is the following statement syntactically correct > > > > "Any-sosurce multicast (ASM) uses the IP addresses in the 224.0.0.0 - > > 239.255.255.255 range [IANA-ALLOC]." > > > > What I meant is that it looks to be incorrect to call this > > range as ASM range. > > You're right. I pulled this from the Terminology section of RFC3569 > ("An Overview of Source-Specific Multicast (SSM)"). I have adjusted > my document so that it describes the ASM space as 224/8 through > 231/8 and 233/8 through 239/8 (with a hole for 224/8). > I think this may not be completely correct. This is because 239/8 is available to administrator and they can use this for SSM within a given domain. > > * In section 4.4, > > > > a. This UDP mapping SHOULD be destroyed when the host leaves > > that host group. > > > > How do we find out that host has left the group? Please > > correct me if I am wrong. > > We are talking about a host behind the NAPT device > > generating Multicast data traffic [UDP traffic]. A multicast host does > > not need to join the multicast group [By sending an IGMP join message] > > to send multicast traffic to that group. So how does NAPT > > finds out when > > it can destroy this mapping and so this mapping will have to timeout > > before it can be removed. > > Ah, good point which I hadn't considered. I have removed that > requirement. > Ok. So now how do you remove that mapping? I guess only once that times out. Right? **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 11:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxBU-0005ze-DU; Wed, 06 Jun 2007 11:12:28 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvxBS-0005zM-Id for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 11:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxBS-0005zE-98; Wed, 06 Jun 2007 11:12:26 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvxBQ-0004pQ-VU; Wed, 06 Jun 2007 11:12:26 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l56FCNel004375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 08:12:24 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l56FCMBj001169; Wed, 6 Jun 2007 10:12:22 -0500 (CDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l56FCJhH001011; Wed, 6 Jun 2007 10:12:19 -0500 (CDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:12:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Date: Wed, 6 Jun 2007 11:12:18 -0400 Message-ID: In-Reply-To: <4666A5AA.4040902@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-Index: AceoNJnG4mpfSckbTZuPAcJfg9UuaQAF3wEg References: <0c4201c7a7d4$2e51b300$c2f0200a@amer.cisco.com> <4666A5AA.4040902@innovationslab.net> From: "Manfredi, Albert E" To: "Brian Haberman" , "Dan Wing" X-OriginalArrivalTime: 06 Jun 2007 15:12:19.0160 (UTC) FILETIME=[1335F580:01C7A84D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mboned@ietf.org, magma@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net]=20 > The main issue being that on the upstream interface of the NAPT, the > same source address will be used for the Report and Done message. So > depending on the order of those messages, traffic may stop temporarily > (until the router sends another Query). Except that, I thought, the multicast router has to send group-specific or group-and-source-specific queries before it stops forwarding multicast packets, in IGMPv2 (the former only) and v3. This is supposed to ensure that there are no members left in the group, before the multicast router stops forwarding the packets. So I'm not sure why there would be this gap in multicasts if everything is working as it should. Not that I have anything against aggregation. Just that it seems unnecessary. It would be nice if the NAT or NAPT device could be as transparent as possible, I think. Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 15:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0mn-0006R9-C9; Wed, 06 Jun 2007 15:03:13 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hw0ml-0006R1-TI for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 15:03:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0ml-0006Qs-Jn; Wed, 06 Jun 2007 15:03:11 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw0mk-0006oZ-CT; Wed, 06 Jun 2007 15:03:11 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l56J32J6011592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 14:03:10 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l56J324g022755; Wed, 6 Jun 2007 14:03:02 -0500 (CDT) Received: from XCH-NEBH-11.ne.nos.boeing.com (xch-nebh-11.ne.nos.boeing.com [128.225.80.27]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l56J2qFO022229; Wed, 6 Jun 2007 14:02:53 -0500 (CDT) Received: from XCH-NE-1V2.ne.nos.boeing.com ([128.225.80.43]) by XCH-NEBH-11.ne.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 15:02:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2007 15:02:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-Index: Aceoa8NrTFvfXGQ4RRyxo/xUBP1+sQAAIzqw References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> <4666DF5E.2070908@innovationslab.net><4666E587.1090602@innovationslab.net><9BCF88B8-5A51-442E-B6B9-38544881CF00@multicasttech.com><4666E854.8090004@innovationslab.net> From: "Manfredi, Albert E" To: "Marshall Eubanks" X-OriginalArrivalTime: 06 Jun 2007 19:02:52.0382 (UTC) FILETIME=[48741FE0:01C7A86D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mboned@ietf.org, behave@ietf.org Subject: [BEHAVE] RE: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com]=20 > On Jun 6, 2007, at 1:01 PM, Brian Haberman wrote: > > But it could be supported by having an administrator inside the NAPT > > assign different groups to all the SSM senders. That way, (S,G) > > collisions will not occur outside the NAPT. > > > > I don't see an easy, automated solution. >=20 > The NAPT knows what is SSM. Couldn't it also do a Multicast Group =20 > Translation for SSM groups ? Why > is this more difficult than, say, port translation ? Port translation is only important within the NAPT device itself. Whereas in multicast, the problem is how to advertize the address of the group, and how to make sure this address remain stable. I think manual configuration is probably a good bet, if not the only way. Bert _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b1-0003ar-Eb; Wed, 06 Jun 2007 18:03:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvuRp-0008Ku-RT for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 08:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuRp-0008Kj-HC; Wed, 06 Jun 2007 08:17:09 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvuRn-0001Vh-8b; Wed, 06 Jun 2007 08:17:09 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.33814708; Wed, 06 Jun 2007 08:16:43 -0400 Message-ID: <4666A5AA.4040902@innovationslab.net> Date: Wed, 06 Jun 2007 08:16:42 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt References: <0c4201c7a7d4$2e51b300$c2f0200a@amer.cisco.com> In-Reply-To: <0c4201c7a7d4$2e51b300$c2f0200a@amer.cisco.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: "'Manfredi, Albert E'" , mboned@ietf.org, magma@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas >> t-06.txt: >> >> What if the NAPT or NAT device just passed IGMP queries and reports >> through, changing only the source address of the reports, and let the >> multicast router outside do all the hard work? I'm wondering >> whether the IGMP aggregation function is mandatory in NAT/NATP. > > For IGMPv3, you would have the problem described in the document, namely: > > Failure to do this aggregation will cause undesired temporary > blackholing of multicast traffic. For example, consider two hosts > behind the same NAPT. If one host is joining a session at the same > time another is lesaving the session, and the NAPT merely relays the > join and leave upstream, the session will be terminated and the join > and leave announcements do not comply with section 5 of [RFC3376]. The main issue being that on the upstream interface of the NAPT, the same source address will be used for the Report and Done message. So depending on the order of those messages, traffic may stop temporarily (until the router sends another Query). > > Based on Prashant Jhingran's comment, > , I'm > trying to determine if this > same problem exists for IGMPv1 and IGMPv2. If so, we will need to require > aggregating all flavors of IGMP to avoid that problem. I would favor aggregation for all flavors of IGMP. The implementations of RFC 4605 that I have seen do this. Regards, Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b3-0003di-Bj; Wed, 06 Jun 2007 18:03:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hvysu-0003ir-1o for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 13:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvyst-0003ij-OY; Wed, 06 Jun 2007 13:01:23 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvyss-00033T-IR; Wed, 06 Jun 2007 13:01:23 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.31365573; Wed, 06 Jun 2007 13:01:09 -0400 Message-ID: <4666E854.8090004@innovationslab.net> Date: Wed, 06 Jun 2007 13:01:08 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Marshall Eubanks References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> <4666DF5E.2070908@innovationslab.net> <4666E587.1090602@innovationslab.net> <9BCF88B8-5A51-442E-B6B9-38544881CF00@multicasttech.com> In-Reply-To: <9BCF88B8-5A51-442E-B6B9-38544881CF00@multicasttech.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: mboned@ietf.org, Alvaro Fernandez , magma@ietf.org, behave@ietf.org, Marshall Eubanks Subject: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Marshall Eubanks wrote: >>>>> >>>>> >>>>> In the BEHAVE draft, REQ-4, if there is a host on the inside interface >>>>> sending UDP packets to a multicast group, the NAPT can change the >>>> source >>>>> address and the port but not the multicast group address. In this >>>> way, I >>>>> think the outside routers can not differentiate the two channels >>>> because >>>>> they have the same source (the public interface) and the same >>>>> multicast >>>>> group address. >>>>> >>>> >>>> Is it possible for the NAPT to have multiple external addresses to use >>>> as source addresses? >>>> >>> >>> Why would it need this ? ASM - (*,G) : SSM (S,G) ? >>> Or are you worried about 2 different SSM sources using the same G. >>> >> >> Yes, that is the scenario Alvaro described. Two senders using the same >> G both behind the same NAPT. >> > > This has to be supported IMHO. > But it could be supported by having an administrator inside the NAPT assign different groups to all the SSM senders. That way, (S,G) collisions will not occur outside the NAPT. I don't see an easy, automated solution. Regards, Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b1-0003b6-VV; Wed, 06 Jun 2007 18:03:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hvx0q-0005dV-IE for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 11:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx0q-0005dN-8b; Wed, 06 Jun 2007 11:01:28 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvx0m-00038t-19; Wed, 06 Jun 2007 11:01:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Jun 2007 16:59:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-Index: AceoQ+/+0fV/gqhcQL2tKuaVlpxjHgAB1BIh References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> From: "Alvaro Fernandez" To: "Brian Haberman" X-Spam-Score: 0.1 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: "Manfredi, Albert E" , mboned@ietf.org, magma@ietf.org, behave@ietf.org Subject: [BEHAVE] RE: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661617142==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============0661617142== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A84B.6CFF0E37" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A84B.6CFF0E37 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian: =20 My e-mail was not an answer to Albert, sorry for that,=20 =20 It is an idea regarding the BEHAVE Internet Draft and how the multicast = NAPT can allow outside multicast routers to uniquely identify different = multicast SSM channels (S,G) coming from inside interfaces in the case = two inside interfaces use the same multicast group. =20 In the BEHAVE draft, REQ-4, if there is a host on the inside interface = sending UDP packets to a multicast group, the NAPT can change the source = address and the port but not the multicast group address. In this way, I = think the outside routers can not differentiate the two channels because = they have the same source (the public interface) and the same multicast = group address. =20 Allowing the NAPT to change the multicast group address in the case two = sender behind the NAPT use the same group address in a similar way the = NATP changes a UDP port is a possible solution. There are other = possibilities. =20 Regards Alvaro ________________________________ De: Brian Haberman [mailto:brian@innovationslab.net] Enviado el: mi=E9 06/06/2007 16:06 Para: Alvaro Fernandez CC: Manfredi, Albert E; behave@ietf.org; mboned@ietf.org; magma@ietf.org Asunto: Re: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt Alvaro, I am not sure what problem this solves. Alfred's comments had to do with receivers behind the NAPT sending Report and Done messages that had to be aggregated at the NAPT in order to avoid having the external router stop the multicast stream. What you describe *appears* to put the senders behind the NAPT. Could you elaborate on what your concern = is? Regards, Brian Alvaro Fernandez wrote: > Hi all. > >=20 > > If you have two sources from two different inside interfaces sending > multicast data to the outside interface and both sources use the same > multicast address (G1) then outside routers, using for example PIM-SM, > will consider that there is only one multicast channel and will send = all > the traffic. Also hosts receiving all the traffic need to separate it. > >=20 > > One solution is to reserve an IP address range inside SSM range ( for > example 232.0.0.0 to 232.0.255.255) and let the NAPT change, not only > the source address of the sender, but also the multicast address of = the > sender to be unique in this range. In this way outside routers ( and > receivers ) will consider traffic as coming from different channels = (IP > public ,G2) and ( IP public, G3) with G2 and G3 inside the said range. > >=20 > > Best Regards > >=20 > > Alvaro > > > = ------------------------------------------------------------------------ > *De:* Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > *Enviado el:* mar 05/06/2007 16:02 > *Para:* behave@ietf.org; mboned@ietf.org; magma@ietf.org > *Asunto:* [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Monday, June 04, 2007 7:38 PM >> To: mboned@ietf.org; magma@ietf.org >> Cc: 'Behave WG' >> Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt >> >> The BEHAVE working group concluded its WGLC of >> draft-ietf-behave-multicast-06 with no comments received. I >> would like >> MBONED and MAGMA to please take a look at this draft prior to >> its submission >> to IESG. >> >> Please send replies to behave@ietf.org. Thanks! > > = http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: > > What if the NAPT or NAT device just passed IGMP queries and reports > through, changing only the source address of the reports, and let the > multicast router outside do all the hard work? I'm wondering whether = the > IGMP aggregation function is mandatory in NAT/NATP. > > Bert > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > > > = ------------------------------------------------------------------------ > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma ------_=_NextPart_001_01C7A84B.6CFF0E37 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt=0A= =0A= =0A= =0A=
=0A=
=0A=

Brian:

=0A=

 

=0A=

My e-mail was not an answer to Albert, sorry for that, =

=0A=

 

=0A=

It is an idea regarding the BEHAVE Internet Draft and how the = multicast NAPT can allow outside multicast routers to uniquely identify = different multicast SSM channels (S,G) coming from inside interfaces in = the case two inside interfaces use the same multicast group.

=0A=

 

=0A=

In the BEHAVE draft, REQ-4, if there is a host on the inside = interface sending UDP packets to a multicast group, the NAPT can change = the source address and the port but not the multicast group address. In = this way, I think the outside routers can not differentiate the two = channels because they have the same source (the public interface) and = the same multicast group address.

=0A=

 

=0A=

Allowing the NAPT to change the multicast group address in the = case two sender behind the NAPT use the same group address in a similar = way the NATP changes a UDP port is a possible solution. There = are other possibilities.

=0A=

 

=0A=

Regards

=0A=


Alvaro

=0A=

=0A=
=0A= De: Brian Haberman = [mailto:brian@innovationslab.net]
Enviado el: mi=E9 06/06/2007 = 16:06
Para: Alvaro Fernandez
CC: Manfredi, Albert E; = behave@ietf.org; mboned@ietf.org; magma@ietf.org
Asunto: Re: = [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt

=0A=
=0A=

Alvaro,
     I am not sure what = problem this solves.  Alfred's comments had to
do with receivers = behind the NAPT sending Report and Done messages that
had to be = aggregated at the NAPT in order to avoid having the external
router = stop the multicast stream.  What you describe *appears* to = put
the senders behind the NAPT.  Could you elaborate on what = your concern is?

Regards,
Brian


Alvaro Fernandez = wrote:
> Hi all.
>
> 
>
> If you have = two sources from two different inside interfaces sending
> = multicast data to the outside interface and both sources use the = same
> multicast address (G1) then outside routers, using for = example PIM-SM,
> will consider that there is only one multicast = channel and will send all
> the traffic. Also hosts receiving all = the traffic need to separate it.
>
> 
>
> = One solution is to reserve an IP address range inside SSM range ( = for
> example 232.0.0.0 to 232.0.255.255) and let the NAPT change, = not only
> the source address of the sender, but also the = multicast address of the
> sender to be unique in this range. In = this way outside routers ( and
> receivers ) will consider traffic = as coming from different channels (IP
> public ,G2) and ( IP = public, G3) with G2 and G3 inside the said = range.
>
> 
>
> Best = Regards
>
> 
>
> = Alvaro
>
>
> = ------------------------------------------------------------------------<= BR>> *De:* Manfredi, Albert E [mailto:albert.e.manfredi@boe= ing.com]
> *Enviado el:* mar 05/06/2007 16:02
> *Para:* = behave@ietf.org; mboned@ietf.org; magma@ietf.org
> *Asunto:* = [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt
>
>> -----Original = Message-----
>> From: Dan Wing [mailto:dwing@cisco.com]
>> = Sent: Monday, June 04, 2007 7:38 PM
>> To: mboned@ietf.org; = magma@ietf.org
>> Cc: 'Behave WG'
>> Subject: [MBONED] = FW: WGLC: draft-ietf-behave-multicast-06.txt
>>
>> The = BEHAVE working group concluded its WGLC of
>> = draft-ietf-behave-multicast-06 with no comments received.  = I
>> would like
>> MBONED and MAGMA to please take a = look at this draft prior to
>> its submission
>> to = IESG.
>>
>> Please send replies to = behave@ietf.org.  Thanks!
>
> = http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt:>
> What if the NAPT or NAT device just passed IGMP queries = and reports
> through, changing only the source address of the = reports, and let the
> multicast router outside do all the hard = work? I'm wondering whether the
> IGMP aggregation function is = mandatory in NAT/NATP.
>
> Bert
>
> = _______________________________________________
> magma mailing = list
> magma@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/magma
>
>
> = ------------------------------------------------------------------------<= BR>>
> _______________________________________________
> = magma mailing list
> magma@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/magma

------_=_NextPart_001_01C7A84B.6CFF0E37-- --===============0661617142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============0661617142==-- From behave-bounces@ietf.org Wed Jun 06 18:03:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b4-0003eg-Fq; Wed, 06 Jun 2007 18:03:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hw0bp-00034N-H3 for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 14:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0bp-00034F-7a; Wed, 06 Jun 2007 14:51:53 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw0bo-0004N9-1U; Wed, 06 Jun 2007 14:51:53 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6925744; Wed, 06 Jun 2007 14:51:51 -0400 In-Reply-To: <4666E854.8090004@innovationslab.net> References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> <4666DF5E.2070908@innovationslab.net> <4666E587.1090602@innovationslab.net> <9BCF88B8-5A51-442E-B6B9-38544881CF00@multicasttech.com> <4666E854.8090004@innovationslab.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Date: Wed, 6 Jun 2007 14:51:47 -0400 To: Brian Haberman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: mboned@ietf.org, Alvaro Fernandez , magma@ietf.org, behave@ietf.org, Marshall Eubanks Subject: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Jun 6, 2007, at 1:01 PM, Brian Haberman wrote: > > > Marshall Eubanks wrote: > >>>>>> >>>>>> >>>>>> In the BEHAVE draft, REQ-4, if there is a host on the inside >>>>>> interface >>>>>> sending UDP packets to a multicast group, the NAPT can change the >>>>> source >>>>>> address and the port but not the multicast group address. In this >>>>> way, I >>>>>> think the outside routers can not differentiate the two channels >>>>> because >>>>>> they have the same source (the public interface) and the same >>>>>> multicast >>>>>> group address. >>>>>> >>>>> >>>>> Is it possible for the NAPT to have multiple external addresses >>>>> to use >>>>> as source addresses? >>>>> >>>> >>>> Why would it need this ? ASM - (*,G) : SSM (S,G) ? >>>> Or are you worried about 2 different SSM sources using the same G. >>>> >>> >>> Yes, that is the scenario Alvaro described. Two senders using >>> the same >>> G both behind the same NAPT. >>> >> >> This has to be supported IMHO. >> > > But it could be supported by having an administrator inside the NAPT > assign different groups to all the SSM senders. That way, (S,G) > collisions will not occur outside the NAPT. > > I don't see an easy, automated solution. The NAPT knows what is SSM. Couldn't it also do a Multicast Group Translation for SSM groups ? Why is this more difficult than, say, port translation ? Marshall > > Regards, > Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b2-0003d3-UC; Wed, 06 Jun 2007 18:03:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvyhS-0007Wv-A0 for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 12:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyhS-0007Wn-0W; Wed, 06 Jun 2007 12:49:34 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyhQ-0005ux-Py; Wed, 06 Jun 2007 12:49:33 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.31364469; Wed, 06 Jun 2007 12:49:12 -0400 Message-ID: <4666E587.1090602@innovationslab.net> Date: Wed, 06 Jun 2007 12:49:11 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Marshall Eubanks References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> <4666DF5E.2070908@innovationslab.net> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: "Manfredi, Albert E" , Alvaro Fernandez , mboned@ietf.org, magma@ietf.org, behave@ietf.org Subject: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Marshall Eubanks wrote: > Hello; > > On 6/6/07, Brian Haberman wrote: >> >> >> Alvaro Fernandez wrote: >> > Brian: >> > >> > >> > >> > My e-mail was not an answer to Albert, sorry for that, >> > >> > >> > >> > It is an idea regarding the BEHAVE Internet Draft and how the multicast >> > NAPT can allow outside multicast routers to uniquely identify different >> > multicast SSM channels (S,G) coming from inside interfaces in the case >> > two inside interfaces use the same multicast group. >> > >> >> How prevalent do people expect the scenario of a SSM sender being >> located behind a NAPT? >> > > I would expect that this has the potential of being fairly common. > > - Enterprises use NATs a lot. (I am not going to get into the question > as to whether they should...) > > - Enterprises use multicast video > > - This video needs to go to remote offices, which are commonly behind > their own NATs. I assume you mean without utilizing a VPN connection? > > If that multicast moves to SSM then they will need NAT traversal. > > >> > >> > >> > In the BEHAVE draft, REQ-4, if there is a host on the inside interface >> > sending UDP packets to a multicast group, the NAPT can change the >> source >> > address and the port but not the multicast group address. In this >> way, I >> > think the outside routers can not differentiate the two channels >> because >> > they have the same source (the public interface) and the same multicast >> > group address. >> > >> >> Is it possible for the NAPT to have multiple external addresses to use >> as source addresses? >> > > Why would it need this ? ASM - (*,G) : SSM (S,G) ? > Or are you worried about 2 different SSM sources using the same G. > Yes, that is the scenario Alvaro described. Two senders using the same G both behind the same NAPT. Regards, Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b1-0003aw-Jn; Wed, 06 Jun 2007 18:03:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvvWo-0000Wk-77 for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 09:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvWn-0000UF-QB; Wed, 06 Jun 2007 09:26:21 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvvWj-0003vG-Ur; Wed, 06 Jun 2007 09:26:21 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 6 Jun 2007 15:22:26 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gAB425SAAMQ20uQ== References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> From: "Alvaro Fernandez" To: "Manfredi, Albert E" , , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: Subject: [BEHAVE] RE: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1158650788==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1158650788== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A83E.228D5886" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A83E.228D5886 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. =20 If you have two sources from two different inside interfaces sending = multicast data to the outside interface and both sources use the same = multicast address (G1) then outside routers, using for example PIM-SM, = will consider that there is only one multicast channel and will send all = the traffic. Also hosts receiving all the traffic need to separate it. =20 One solution is to reserve an IP address range inside SSM range ( for = example 232.0.0.0 to 232.0.255.255) and let the NAPT change, not only = the source address of the sender, but also the multicast address of the = sender to be unique in this range. In this way outside routers ( and = receivers ) will consider traffic as coming from different channels (IP = public ,G2) and ( IP public, G3) with G2 and G3 inside the said range. =20 Best Regards =20 Alvaro=20 ________________________________ De: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Enviado el: mar 05/06/2007 16:02 Para: behave@ietf.org; mboned@ietf.org; magma@ietf.org Asunto: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, June 04, 2007 7:38 PM > To: mboned@ietf.org; magma@ietf.org > Cc: 'Behave WG' > Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt > > The BEHAVE working group concluded its WGLC of > draft-ietf-behave-multicast-06 with no comments received. I > would like > MBONED and MAGMA to please take a look at this draft prior to > its submission > to IESG. > > Please send replies to behave@ietf.org. Thanks! http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: What if the NAPT or NAT device just passed IGMP queries and reports through, changing only the source address of the reports, and let the multicast router outside do all the hard work? I'm wondering whether the IGMP aggregation function is mandatory in NAT/NATP. Bert _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma ------_=_NextPart_001_01C7A83E.228D5886 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt=0A= =0A= =0A= =0A=
=0A=
=0A=

Hi = all.

=0A=

 

=0A=

If you have two sources from two different inside interfaces = sending multicast data to the outside interface and both sources use the = same multicast address (G1) then outside routers, using for example = PIM-SM, will consider that there is only one multicast channel and will = send all the traffic. Also hosts receiving all the traffic need to = separate it.

=0A=

 

=0A=

One solution is to reserve an IP address range inside SSM = range ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change, = not only the source address of the sender, but also the multicast = address of the sender to be unique in this range. In this way outside = routers ( and receivers ) will consider traffic as coming from different = channels (IP public ,G2) and ( IP public, G3) with G2 and G3 inside the = said range.

=0A=

 

=0A=

Best Regards

=0A=

 

=0A=

Alvaro

=0A=

=0A=
=0A= De: Manfredi, Albert E = [mailto:albert.e.manfredi@boeing.com]
Enviado el: mar = 05/06/2007 16:02
Para: behave@ietf.org; mboned@ietf.org; = magma@ietf.org
Asunto: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt

=0A=
=0A=

> -----Original Message-----
> From: Dan Wing = [mailto:dwing@cisco.com]
> = Sent: Monday, June 04, 2007 7:38 PM
> To: mboned@ietf.org; = magma@ietf.org
> Cc: 'Behave WG'
> Subject: [MBONED] FW: = WGLC: draft-ietf-behave-multicast-06.txt
>
> The BEHAVE = working group concluded its WGLC of
> = draft-ietf-behave-multicast-06 with no comments received.  = I
> would like
> MBONED and MAGMA to please take a look at = this draft prior to
> its submission
> to = IESG.
>
> Please send replies to behave@ietf.org.  = Thanks!

http://www.ietf.org/internet-drafts/draft-ietf-behave-mult= icast-06.txt:

What if the NAPT or NAT device just passed IGMP = queries and reports
through, changing only the source address of the = reports, and let the
multicast router outside do all the hard work? = I'm wondering whether the
IGMP aggregation function is mandatory in = NAT/NATP.

Bert

____________________________________________= ___
magma mailing list
magma@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/magma

------_=_NextPart_001_01C7A83E.228D5886-- --===============1158650788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1158650788==-- From behave-bounces@ietf.org Wed Jun 06 18:03:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b1-0003b1-PO; Wed, 06 Jun 2007 18:03:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hvw9w-0001dH-UY for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 10:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvw9w-0001d8-Kx; Wed, 06 Jun 2007 10:06:48 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvw9w-0003NE-BO; Wed, 06 Jun 2007 10:06:48 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.33824274; Wed, 06 Jun 2007 10:06:30 -0400 Message-ID: <4666BF65.7020407@innovationslab.net> Date: Wed, 06 Jun 2007 10:06:29 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Alvaro Fernandez References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: "Manfredi, Albert E" , mboned@ietf.org, magma@ietf.org, behave@ietf.org Subject: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Alvaro, I am not sure what problem this solves. Alfred's comments had to do with receivers behind the NAPT sending Report and Done messages that had to be aggregated at the NAPT in order to avoid having the external router stop the multicast stream. What you describe *appears* to put the senders behind the NAPT. Could you elaborate on what your concern is? Regards, Brian Alvaro Fernandez wrote: > Hi all. > > > > If you have two sources from two different inside interfaces sending > multicast data to the outside interface and both sources use the same > multicast address (G1) then outside routers, using for example PIM-SM, > will consider that there is only one multicast channel and will send all > the traffic. Also hosts receiving all the traffic need to separate it. > > > > One solution is to reserve an IP address range inside SSM range ( for > example 232.0.0.0 to 232.0.255.255) and let the NAPT change, not only > the source address of the sender, but also the multicast address of the > sender to be unique in this range. In this way outside routers ( and > receivers ) will consider traffic as coming from different channels (IP > public ,G2) and ( IP public, G3) with G2 and G3 inside the said range. > > > > Best Regards > > > > Alvaro > > > ------------------------------------------------------------------------ > *De:* Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > *Enviado el:* mar 05/06/2007 16:02 > *Para:* behave@ietf.org; mboned@ietf.org; magma@ietf.org > *Asunto:* [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt > >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com] >> Sent: Monday, June 04, 2007 7:38 PM >> To: mboned@ietf.org; magma@ietf.org >> Cc: 'Behave WG' >> Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt >> >> The BEHAVE working group concluded its WGLC of >> draft-ietf-behave-multicast-06 with no comments received. I >> would like >> MBONED and MAGMA to please take a look at this draft prior to >> its submission >> to IESG. >> >> Please send replies to behave@ietf.org. Thanks! > > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: > > What if the NAPT or NAT device just passed IGMP queries and reports > through, changing only the source address of the reports, and let the > multicast router outside do all the hard work? I'm wondering whether the > IGMP aggregation function is mandatory in NAT/NATP. > > Bert > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > > > ------------------------------------------------------------------------ > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b3-0003e1-K7; Wed, 06 Jun 2007 18:03:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hvz9L-0001f9-KQ for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 13:18:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvz9L-0001ew-Ah; Wed, 06 Jun 2007 13:18:23 -0400 Received: from mailhost.u-strasbg.fr ([2001:660:2402::151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvz9K-000124-Uo; Wed, 06 Jun 2007 13:18:23 -0400 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.13.8/jtpda-5.5pre1) with ESMTP id l56HILPD022393 ; Wed, 6 Jun 2007 19:18:21 +0200 (CEST) Received: from [IPv6:2001:660:4701:1001:20d:93ff:fec8:919c] ([IPv6:fe80::215:60ff:feaa:bdf0]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id l56HILg3037544 ; Wed, 6 Jun 2007 19:18:21 +0200 (CEST) Message-ID: <4666EC5D.9010201@crc.u-strasbg.fr> Date: Wed, 06 Jun 2007 19:18:21 +0200 From: Jean-Jacques Pansiot User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: mboned@ietf.org, magma@ietf.org, behave@ietf.org References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> <4666DF5E.2070908@innovationslab.net> <4666E587.1090602@innovationslab.net> <9BCF88B8-5A51-442E-B6B9-38544881CF00@multicasttech.com> <4666E854.8090004@innovationslab.net> In-Reply-To: <4666E854.8090004@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::151]); Wed, 06 Jun 2007 19:18:21 +0200 (CEST) X-Virus-Scanned: ClamAV 0.88.7/3367/Wed Jun 6 07:14:43 2007 on mr1.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,NO_RELAYS autolearn=disabled version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mr1.u-strasbg.fr X-Spam-Score: -2.8 (--) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: Subject: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Brian Haberman wrote: > Marshall Eubanks wrote: > > >>>>>> In the BEHAVE draft, REQ-4, if there is a host on the inside interface >>>>>> sending UDP packets to a multicast group, the NAPT can change the >>>>>> >>>>> source >>>>> >>>>>> address and the port but not the multicast group address. In this >>>>>> >>>>> way, I >>>>> >>>>>> think the outside routers can not differentiate the two channels >>>>>> >>>>> because >>>>> >>>>>> they have the same source (the public interface) and the same >>>>>> multicast >>>>>> group address. >>>>>> >>>>>> >>>>> Is it possible for the NAPT to have multiple external addresses to use >>>>> as source addresses? >>>>> >>>>> >>>> Why would it need this ? ASM - (*,G) : SSM (S,G) ? >>>> Or are you worried about 2 different SSM sources using the same G. >>>> >>>> >>> Yes, that is the scenario Alvaro described. Two senders using the same >>> G both behind the same NAPT. >>> >>> >> This has to be supported IMHO. >> >> > > But it could be supported by having an administrator inside the NAPT > assign different groups to all the SSM senders. That way, (S,G) > collisions will not occur outside the NAPT. > > In any case, receivers have to learn the public (S,G), so part of the problem is how receivers learn channel addresses. If channels are advertised by sources using SAP for example, the NAT box could translate S and G (SAP adrvertisement) on the fly (I dont know if this would be hard) so that they dont collide. If channels are advertised by other means (say a web site) it seems that the translation in the Nat box and the advertisement have to be closely coordinated. One way would be to use a special multicast address coding (for example use a hash or a suffix of the private source address as a part of the group address, so that they never collide. Obviously this works only if all private addresses behind the NAT are distinct) cheers Jean-Jacques > I don't see an easy, automated solution. > > Regards, > Brian > > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www1.ietf.org/mailman/listinfo/mboned > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3b2-0003cP-Fr; Wed, 06 Jun 2007 18:03:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HvyI2-0001Rs-9F for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 12:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyI1-0001Rk-W1; Wed, 06 Jun 2007 12:23:17 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyI0-00069l-PY; Wed, 06 Jun 2007 12:23:17 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.31361783; Wed, 06 Jun 2007 12:22:55 -0400 Message-ID: <4666DF5E.2070908@innovationslab.net> Date: Wed, 06 Jun 2007 12:22:54 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Alvaro Fernandez References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <4666BF65.7020407@innovationslab.net> In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Wed, 06 Jun 2007 18:03:13 -0400 Cc: "Manfredi, Albert E" , mboned@ietf.org, magma@ietf.org, behave@ietf.org Subject: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Alvaro Fernandez wrote: > Brian: > > > > My e-mail was not an answer to Albert, sorry for that, > > > > It is an idea regarding the BEHAVE Internet Draft and how the multicast > NAPT can allow outside multicast routers to uniquely identify different > multicast SSM channels (S,G) coming from inside interfaces in the case > two inside interfaces use the same multicast group. > How prevalent do people expect the scenario of a SSM sender being located behind a NAPT? > > > In the BEHAVE draft, REQ-4, if there is a host on the inside interface > sending UDP packets to a multicast group, the NAPT can change the source > address and the port but not the multicast group address. In this way, I > think the outside routers can not differentiate the two channels because > they have the same source (the public interface) and the same multicast > group address. > Is it possible for the NAPT to have multiple external addresses to use as source addresses? > > > Allowing the NAPT to change the multicast group address in the case two > sender behind the NAPT use the same group address in a similar way the > NATP changes a UDP port is a possible solution. There are other > possibilities. >From the global perspective, how does a receiver outside the NAPT know the (S,G) combination to join? Regards, Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3g1-0005Uy-6I; Wed, 06 Jun 2007 18:08:25 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hw3g0-0005Un-9J for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3fz-0005Uf-Vv; Wed, 06 Jun 2007 18:08:23 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3fy-00073T-LC; Wed, 06 Jun 2007 18:08:23 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2007 15:08:22 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="160071023:sNHT45814050" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l56M8MT7012320; Wed, 6 Jun 2007 15:08:22 -0700 Received: from dwingwxp (dhcp-128-107-163-30.cisco.com [128.107.163.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l56M8LtV020856; Wed, 6 Jun 2007 22:08:21 GMT From: "Dan Wing" To: "'Brian Haberman'" , "'Alvaro Fernandez'" Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Date: Wed, 6 Jun 2007 15:08:22 -0700 Message-ID: <03c101c7a887$3256f740$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4666DF5E.2070908@innovationslab.net> Thread-Index: AceohoOU8f2ISJf3QMOPitSyMQ3C3gAABykA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2214; t=1181167702; x=1182031702; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20[magma]=20RE=3A=20[MBONED]=20FW=3A =20WGLC=3Adraft-ietf-behave-multicast-06.txt |Sender:=20; bh=31bXgrwkFURIrfXIRCDqVljwfN2m2oDUJ9MKbzsn4WI=; b=MGKZLHt5RI+nO6LgkAPArO9brJ9di8OTCcrugAdaxlRJHGJekAeo5oPNu3pOCuZf56Rvco5G YJCDDXodcR3h02FPsCniJ+EWTska2MC4SIZ7Vo3PFutRVyq3qSCIs9nj; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "'Manfredi, Albert E'" , mboned@ietf.org, Toerless Eckert , magma@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > It is an idea regarding the BEHAVE Internet Draft and how > > the multicast > > NAPT can allow outside multicast routers to uniquely > > identify different > > multicast SSM channels (S,G) coming from inside interfaces > > in the case > > two inside interfaces use the same multicast group. > > How prevalent do people expect the scenario of a SSM sender being > located behind a NAPT? Not very prevalent with today's broadcast model for SSM where the broadcaster is the video service provider. However, we don't want to encourage proliferation of NATs which are compliant with a BCP that do not allow SSM senders behind those NATs. With today's bandwidth to the home we might consider someone running a 'radio station' from behind a NAT. With tomorrow's bandwidth, we might considering someone doing video sharing to their family from behind a NAT. Hard to say; I would like to do this once if we know how to do it today. > > In the BEHAVE draft, REQ-4, if there is a host on the > > inside interface > > sending UDP packets to a multicast group, the NAPT can > > change the source > > address and the port but not the multicast group address. > > In this way, I > > think the outside routers can not differentiate the two > > channels because > > they have the same source (the public interface) and the > > same multicast > > group address. > > > > Is it possible for the NAPT to have multiple external addresses to use > as source addresses? Some NAPTs do that, yes -- larger ones used by service providers and by enterprises. Your traditional residential-class NAPT doesn't do that, though. > > Allowing the NAPT to change the multicast group address in > > the case two > > sender behind the NAPT use the same group address in a > > similar way the > > NATP changes a UDP port is a possible solution. There are other > > possibilities. > > From the global perspective, how does a receiver outside the > NAPT know the (S,G) combination to join? -d > Regards, > Brian > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:13:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3ky-00033D-65; Wed, 06 Jun 2007 18:13:32 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hw3kw-000331-4a for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3kv-00032s-R8; Wed, 06 Jun 2007 18:13:29 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3kv-0007t3-GO; Wed, 06 Jun 2007 18:13:29 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2007 15:13:28 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="160073736:sNHT45824841" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l56MDSfb013158; Wed, 6 Jun 2007 15:13:28 -0700 Received: from dwingwxp (dhcp-128-107-163-30.cisco.com [128.107.163.30]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l56MDSaI002228; Wed, 6 Jun 2007 22:13:28 GMT From: "Dan Wing" To: "'Jean-Jacques Pansiot'" , , , Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Date: Wed, 6 Jun 2007 15:13:28 -0700 Message-ID: <03c201c7a887$e93e3d10$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4666EC5D.9010201@crc.u-strasbg.fr> Thread-Index: AceohoOUkJx0mlVDRl+gOfwm29DM8wAALcpA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2477; t=1181168008; x=1182032008; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20[magma]=20RE=3A=20[MBONED]=20FW=3A =20WGLC=3Adraft-ietf-behave-multicast-06.txt |Sender:=20; bh=ZQU+8zhjEpb3eOWurqDYA50vXhAGQz1bg20Nj0Xx8Gs=; b=CEG7G0fgnlauPH7rkJA8yJqDLKqkp3QPB/nK2856puxd85d5QhEMrLcwhI4c29pkcWh7XHWV eDXDMcqGnRwvBu0x9jrwgBNd67wAWnFjaFPDA1oNFy7YbUT7HzNspzy9; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Jean-Jacques Pansiot wrote: ... > > But it could be supported by having an administrator inside the NAPT > > assign different groups to all the SSM senders. That way, (S,G) > > collisions will not occur outside the NAPT. > > In any case, receivers have to learn the public (S,G), so part of the > problem is how receivers learn channel addresses. > If channels are advertised by sources using SAP for example, > the NAT box could translate S and G (SAP adrvertisement) on the fly > (I dont know if this would be hard) so that they dont collide. > > If channels are advertised by other means (say a web site) it > seems that the translation in the Nat box and the advertisement > have to be closely coordinated. Such rewriting of the destination IP address, which creates a different multicast realm, is complicated. It's out of scope in the current document, on purpose; it is fraught with problems (imagine if the session announcement arrived via email, for example, instead of via SAP -- the NAT couldn't rewrite it. Similarly if it was communicated via HTTPS (instead of HTTP)). The document currently says this in the introduction: As with normal NAPT operation for unicast flows, multicast packets received from the outside interface and forwarded to the inside interface do not have their source IP addresses changed. Such multicast packets do not need to have their destination IP address changed (unless the NAT device wishes to establish septate multicast domains, but this is not the typical operation). If this needs to be strengthened, please let me know. Perhaps we need to strongly discourage such an operation with requirements. -d > One way would be to use a special > multicast address coding (for example use a hash or a suffix of the > private source address as a part of the group address, > so that they never collide. Obviously this works only if all private > addresses behind the NAT are distinct) > > cheers > Jean-Jacques > > > > I don't see an easy, automated solution. > > > > Regards, > > Brian > > > > _______________________________________________ > > MBONED mailing list > > MBONED@ietf.org > > https://www1.ietf.org/mailman/listinfo/mboned > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 06 18:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3s7-0008AC-MW; Wed, 06 Jun 2007 18:20:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hw3s7-00089y-0q for behave-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:20:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3s6-00089p-Na; Wed, 06 Jun 2007 18:20:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3s4-0001JM-MG; Wed, 06 Jun 2007 18:20:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 06 Jun 2007 15:20:52 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="161368718:sNHT43318773" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l56MKp6D028707; Wed, 6 Jun 2007 15:20:51 -0700 Received: from dwingwxp (dhcp-128-107-163-30.cisco.com [128.107.163.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l56MKntV028352; Wed, 6 Jun 2007 22:20:51 GMT From: "Dan Wing" To: "'Marshall Eubanks'" , "'Brian Haberman'" Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Date: Wed, 6 Jun 2007 15:20:49 -0700 Message-ID: <03d201c7a888$f148b0c0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceohoVecJiRny4aTVKLSOquWsLgcwAAaQDw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=913; t=1181168451; x=1182032451; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Re=3A=20[magma]=20RE=3A=20[MBONED]=20FW=3A =20WGLC=3Adraft-ietf-behave-multicast-06.txt |Sender:=20; bh=RADt/N8j8WMzkbcKciosltJ65mybgdZdGcvWcmX+xbU=; b=mGShKqug7GGwkdpYV5hK4/dUIE9GsCiYogww6Y022nxLfxoOeJiCdyFXUsn2amsLKIFtaeeJ hsGX2jHCwZwiCFo7IHns5zM77iAVkYF+aRMo6SpLiwn6dgMFqIuZ27nW; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Toerless Eckert , behave@ietf.org, 'Marshall Eubanks' , 'Alvaro Fernandez' , mboned@ietf.org, magma@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > The NAPT knows what is SSM. Couldn't it also do a Multicast Group > Translation for SSM groups ? Why > is this more difficult than, say, port translation ? It may be fairly easy -- except for rewriting the advertisements in SAP, HTTP, HTTPS (a big problem there), email, SIP, RTSP, .... And NAPTs don't do that kind of rewriting today; draft-ietf-behave-multicast is only a BCP and trying to describe what a NAT should best be doing as of its date of publication. If we want NAPTs to do this, we would want a different document that was standards-track and that document would define how we wanted NAPTs to perform this function. However, I don't see a successful path if such an operation would require the NAPT to have an ALG for SAP, HTTP, SIP, and RTSP and requires the NAT also rewrite those packets. We'd need something else. ALGs don't work well for a variety of reasons. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 07 02:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwBi4-0003wK-NS; Thu, 07 Jun 2007 02:43:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwBi3-0003tN-7U for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 02:43:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwBi2-0003tF-Rv for behave@ietf.org; Thu, 07 Jun 2007 02:43:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwBi2-0002cL-Dk for behave@ietf.org; Thu, 07 Jun 2007 02:43:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2007 23:43:02 -0700 X-IronPort-AV: i="4.16,393,1175497200"; d="scan'208"; a="491348497:sNHT53276964" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l576h1lC015149; Wed, 6 Jun 2007 23:43:01 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l576h1aI010591; Thu, 7 Jun 2007 06:43:01 GMT From: "Dan Wing" To: Date: Wed, 6 Jun 2007 23:43:01 -0700 Message-ID: <04c301c7a8cf$17e7eac0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zw== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4842; t=1181198581; x=1182062581; 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:=20BoF=20request=3A=20STUN=20Control=20Usage |Sender:=20; bh=lxZ5DT/196STrqZoBacNG8Epyd9Fv1Hdfcvhiq0gAqY=; b=YnyXUvxwtX6dSnOTul15ntCSvligo5qESJiWJmZ3T6TGGejerzBMj5cE9891pfA3uICdCueq ohhXiQKQLD1pytwbS2Al74ksidnVhkgUcor62UzeaBld/lIfiHBGsFc5; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Subject: [BEHAVE] BoF request: STUN Control Usage X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org As individual contributor: I would like to summarize my reasons for calling this BoF, and the value I see STUN Control can bring. Hopefully this summary will tease out futher objections or further agreement for this BoF and discussion of draft-wing-behave-nat-control-stun-usage itself. 1. ICE works. This has been well demonstrated by its successful deployment on the Internet by millions of endpoints. It works without explicit support by subscriber's NATs or ISP's NATs. 2. A drawback of ICE (and STUN) is the chattiness of keepalive messages (primarily with SIP servers [draft-ietf-sip-outbound]) and the chattiness of binding discovery messages for each call (primarily due to ICE). STUN Control adds an optimization to STUN's existing areas of applicability by allowing an end host to negotiate and extend NAT binding lifetimes. This improves the performance of ICE and sip-outbound and any other protocols making use of STUN. In our draft, we don't compare STUN Control to other protocols, so here are some points: * STUN Control is inherently limited in the scope of control it provides. It only allows for extension of binding lifetimes, and only allows such extensions for the binding associated with the source IP/port the STUN Control request is coming from. Because of its fundamentally limited scope of control, the NAT can operate with a trivial authorization policy - a control message coming on its internal interface is always authorized to manage the binding lifetime for the private address and port the message comes from. This is, in fact, exactly the same authorization policies used by NATs today to authorize the creation and termination of bindings. STUN Control merely extends that authorization to make the termination more controlled. The trivial scope of control and authorization policy means that authentication, credentials, shared secrets, and so on, are not required. The need for such security measures in other, richer control protocols makes them hard to deploy. STUN Control is meant to be trivially deployable to solve a small but important problem. * STUN Control works with nested NATs; UPnP does not. * STUN Control is incrementally deployable. Other mechanisms are not (they require modifying end hosts and NATs, or else they fail or they fall back to other mechanisms). STUN Control is an optimization to ICE and sip-outbound. If a host or a NAT doesn't support STUN Control, ICE and sip-outbound continue to work -- albeit with more frequent keepalive messages and binding discovery messages sent to the STUN server (which is what they do today without STUN Control). Please send comments to behave@ietf.org. -d ----- (Below is my original BoF proposal. Chairs are still TBD. Since my original request, it has been suggested that one hour isn't sufficient, as we need to discuss deployment barriers to existing techniques, and optimizations that would be useful for sip-outbound and ICE). Description: ICE and its companion protocol STUN are emerging as a popular mechanism to traverse NATs without requiring deployment of new software in existing NATs. ICE has been specified for SIP, extended to Jabber/XMPP, and will work with RTSP. ICE is incrementally deployable, providing operation over any sort of NAT and any sort of firewall, without requiring upgrades to those NATs and firewalls. A successful Firewall or NAT control protocols needs to also be incrementally deployable so that applications can request enhanced services from firewalls and from NATs to permit certain flows towards a host and to the host's applications. Incremental deployment allows hosts to deploy the protocol without requiring NATs or firewalls in front of the host to be upgraded to enjoy basic operation, but after upgrading to enjoy enhanced operation. Draft-wing-behave-nat-control-stun-usage describes how STUN could be used to communicate with both NATs and firewalls to enhance the operation of those NATs and firewalls to allow certain flows or treat them differently. This BoF is intended to discuss one proposed technique, draft-wing-behave-nat-control-stun-usage as an incrementally-deployable NAT control mechanism and firewall control mechanism, and to determine if there is sufficient community interest to move this work forward in the IETF. Agenda: Agenda bash ............................................. 5 Summary of existing NAT traversal techniques ............ 20 (UPnP, NAT-PMP/Bonjour, MIDCOM techniques, NSIS GIST, ICE) STUN Control ............................................ 30 --------- total: 55 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 07 09:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHqH-0008HH-CH; Thu, 07 Jun 2007 09:15:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwHqF-0008Gx-Df for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 09:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwHqF-0008Fq-19; Thu, 07 Jun 2007 09:15:55 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwHqD-0007hy-7E; Thu, 07 Jun 2007 09:15:54 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.33937178; Thu, 07 Jun 2007 09:15:31 -0400 Message-ID: <466804F3.5040400@innovationslab.net> Date: Thu, 07 Jun 2007 09:15:31 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Dan Wing Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt References: <03d201c7a888$f148b0c0$c2f0200a@amer.cisco.com> In-Reply-To: <03d201c7a888$f148b0c0$c2f0200a@amer.cisco.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Toerless Eckert , behave@ietf.org, 'Marshall Eubanks' , 'Alvaro Fernandez' , 'Marshall Eubanks' , mboned@ietf.org, magma@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Dan Wing wrote: >> The NAPT knows what is SSM. Couldn't it also do a Multicast Group >> Translation for SSM groups ? Why >> is this more difficult than, say, port translation ? > > It may be fairly easy -- except for rewriting the advertisements in SAP, > HTTP, HTTPS (a big problem there), email, SIP, RTSP, .... > > And NAPTs don't do that kind of rewriting today; draft-ietf-behave-multicast > is only a BCP and trying to describe what a NAT should best be doing as of > its date of publication. > > > If we want NAPTs to do this, we would want a different document that was > standards-track and that document would define how we wanted NAPTs to > perform this function. However, I don't see a successful path if such an > operation would require the NAPT to have an ALG for SAP, HTTP, SIP, and RTSP > and requires the NAT also rewrite those packets. We'd need something else. > ALGs don't work well for a variety of reasons. Given that, I would suggest that the document state that administrators of the network behind the NAPT assign sub-ranges of the SSM space to their multicast sources. This could be done manually or *possibly* with the tools developed by the MALLOC WG. For the ma & pa type residential networks, I doubt you will see multiple machines behind a NAPT sourcing SSM. For more corporate types, the network admin can control the allocation of the SSM range. Regards, Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 07 12:55:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLG9-0003Jk-Qe; Thu, 07 Jun 2007 12:54:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwLG8-0003JT-QT for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:54:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLG8-0003JL-GW; Thu, 07 Jun 2007 12:54:52 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLG6-0003Jb-Aw; Thu, 07 Jun 2007 12:54:52 -0400 Content-class: urn:content-classes:message Subject: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt MIME-Version: 1.0 Date: Thu, 7 Jun 2007 18:53:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Thread-Index: AcepBfrdxgCJrUwsS22jtMOvaiXqQgAHlrkU References: <03d201c7a888$f148b0c0$c2f0200a@amer.cisco.com> <466804F3.5040400@innovationslab.net> From: "Alvaro Fernandez" To: "Brian Haberman" , "Dan Wing" X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: Toerless Eckert , behave@ietf.org, Marshall Eubanks , Marshall Eubanks , mboned@ietf.org, magma@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1504332650==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1504332650== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A924.8AB055B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A924.8AB055B7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian / Dan: =20 "Unicast" TCP/UDO sessions are uniquely identified by the tuple =20 ( source IP address, source TCP/UDP port, target IP address, target = TCP/UDP port ) =20 Routers use IP addresses to send and receive the information. NAPT can = change the insider interface IP and port and TCP/UDP sessions are ok. =20 Multicast routing is different because it uses also the multicast group = address for routing. I think at least this is a point to consider and = to debate when talking about a multicast NAPT. This was the reason of my = e-mail of yesterday with the example of the problem of two senders = behind NAPT using the same multicast group and how outside routers = consider this traffic as coming from only one source. =20 Ideally a multicast NAPT should do the same function of a unicast NAPT: = establish multicast sessions changing parameters that uniquely identify = each multicast session. =20 One problem is how the receiver will contact with the sender behind the = NAPT. But there is still the same problem if the NAPT don't change the = multicast address. I think this problem is out of the scope of the = BEHAVE draft. =20 I think it is difficult to know today how multicast sessions will be = used in the future and which parameters will be used to establish = sessions and how sessions will be started. One solution is to consider = this out of the scope of the document but I think is a good idea to = mention it. =20 Regards Alvaro ________________________________ De: Brian Haberman [mailto:brian@innovationslab.net] Enviado el: jue 07/06/2007 15:15 Para: Dan Wing CC: 'Marshall Eubanks'; mboned@ietf.org; Alvaro Fernandez; = magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; Toerless Eckert Asunto: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt Dan Wing wrote: >> The NAPT knows what is SSM. Couldn't it also do a Multicast Group=20 >> Translation for SSM groups ? Why >> is this more difficult than, say, port translation ? > > It may be fairly easy -- except for rewriting the advertisements in = SAP, > HTTP, HTTPS (a big problem there), email, SIP, RTSP, .... > > And NAPTs don't do that kind of rewriting today; = draft-ietf-behave-multicast > is only a BCP and trying to describe what a NAT should best be doing = as of > its date of publication. > > > If we want NAPTs to do this, we would want a different document that = was > standards-track and that document would define how we wanted NAPTs to > perform this function. However, I don't see a successful path if such = an > operation would require the NAPT to have an ALG for SAP, HTTP, SIP, = and RTSP > and requires the NAT also rewrite those packets. We'd need something = else. > ALGs don't work well for a variety of reasons. Given that, I would suggest that the document state that administrators of the network behind the NAPT assign sub-ranges of the SSM space to their multicast sources. This could be done manually or *possibly* with the tools developed by the MALLOC WG. For the ma & pa type residential networks, I doubt you will see multiple machines behind a NAPT sourcing SSM. For more corporate types, the network admin can control the allocation of the SSM range. Regards, Brian ------_=_NextPart_001_01C7A924.8AB055B7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt=0A= =0A= =0A= =0A=
=0A=
=0A=

Brian / Dan:

=0A=

 

=0A=

“Unicast” TCP/UDO sessions are uniquely identified = by the tuple

=0A=

 

=0A=

 ( source IP = address, source TCP/UDP port, target IP address, target TCP/UDP port = )

=0A=

 

=0A=

Routers use IP addresses to send and receive the information. = NAPT can change the insider interface IP and port and TCP/UDP sessions = are ok.

=0A=

 

=0A=

Multicast routing is different because it uses also the = multicast group address for routing.  I think at least this is a point to consider and to = debate when talking about a multicast NAPT. This was the reason of my = e-mail of yesterday with the example of the problem of two senders = behind NAPT using the same multicast group and how outside routers = consider this traffic as coming from only one = source.

=0A=

 

=0A=

Ideally a multicast NAPT should do the same function of a = unicast NAPT: establish multicast sessions changing parameters that = uniquely identify each multicast = session.

=0A=

 

=0A=

One = problem is how the receiver will contact with the sender behind the = NAPT. But there is still the same problem if the NAPT don’t change = the multicast address. I think this problem is out of the scope of the = BEHAVE draft.

=0A=

 

=0A=

I = think it is difficult to know today how multicast sessions will be used = in the future and which parameters will be used to establish sessions = and how sessions will be started. One solution is to consider this out of the scope of the = document but I think is a good idea to mention = it.

=0A=

 

=0A=

Regards

=0A=


Alvaro

=0A=

=0A=
=0A= De: Brian Haberman = [mailto:brian@innovationslab.net]
Enviado el: jue 07/06/2007 = 15:15
Para: Dan Wing
CC: 'Marshall Eubanks'; = mboned@ietf.org; Alvaro Fernandez; magma@ietf.org; behave@ietf.org; = 'Marshall Eubanks'; Toerless Eckert
Asunto: Re: [BEHAVE] Re: = [magma] RE: [MBONED] FW: = WGLC:draft-ietf-behave-multicast-06.txt

=0A=


=0A=

Dan Wing wrote:
>> The NAPT knows what is = SSM. Couldn't it also do a Multicast Group 
>> Translation = for SSM groups ? Why
>> is this more difficult than, say, port = translation ?
>
> It may be fairly easy -- except for = rewriting the advertisements in SAP,
> HTTP, HTTPS (a big problem = there), email, SIP, RTSP, ....
>
> And NAPTs don't do that = kind of rewriting today; draft-ietf-behave-multicast
> is only a = BCP and trying to describe what a NAT should best be doing as of
> = its date of publication.
>
>
> If we want NAPTs to do = this, we would want a different document that was
> = standards-track and that document would define how we wanted NAPTs = to
> perform this function.  However, I don't see a = successful path if such an
> operation would require the NAPT to = have an ALG for SAP, HTTP, SIP, and RTSP
> and requires the NAT = also rewrite those packets.  We'd need something else.
> ALGs = don't work well for a variety of reasons.

Given that, I would = suggest that the document state that administrators
of the network = behind the NAPT assign sub-ranges of the SSM space to
their multicast = sources.  This could be done manually or *possibly* with
the = tools developed by the MALLOC WG.  For the ma & pa type = residential
networks, I doubt you will see multiple machines behind a = NAPT sourcing
SSM.  For more corporate types, the network admin = can control the
allocation of the SSM = range.

Regards,
Brian

------_=_NextPart_001_01C7A924.8AB055B7-- --===============1504332650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1504332650==-- From behave-bounces@ietf.org Thu Jun 07 15:39:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNpW-0000Dl-4g; Thu, 07 Jun 2007 15:39:34 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwNpU-0000DT-Bg for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 15:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNpT-0000DG-Ig for behave@ietf.org; Thu, 07 Jun 2007 15:39:31 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwNpR-0006WN-4I for behave@ietf.org; Thu, 07 Jun 2007 15:39:31 -0400 Received: from lappy ([67.169.180.240]) by quinthar.com for ; Thu, 7 Jun 2007 12:39:25 -0700 From: "David Barrett" To: Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Thu, 7 Jun 2007 12:39:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <04c301c7a8cf$17e7eac0$c2f0200a@amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Message-Id: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Subject: [BEHAVE] BoF request: STUN Control Usage > > 1. ICE works. This has been well demonstrated by its successful > deployment on the Internet by millions of endpoints. It works > without explicit support by subscriber's NATs or ISP's NATs. Just curious, what statistics are available on ICE's real-world usage and NAT-penetration success rates? Specifically: - How did you come up with the "millions of endpoints" number? - What does "works" mean? (I'd suggest this be measured in "direct peer connectivity ratio" and "connection setup time", but any measure will do.) Granted, it might be a bit OT given that you're really trying to talk about STUN, but I'm always interested in new real-world statistics. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 07 18:58:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQwM-00013d-Kv; Thu, 07 Jun 2007 18:58:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwQwK-00013T-QA for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQwJ-00013E-Vm for behave@ietf.org; Thu, 07 Jun 2007 18:58:48 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQwH-0007Wq-KX for behave@ietf.org; Thu, 07 Jun 2007 18:58:47 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2007 15:58:44 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="2220329:sNHT581396538" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l57MwijX030456; Thu, 7 Jun 2007 15:58:44 -0700 Received: from dwingwxp (dhcp-128-107-163-30.cisco.com [128.107.163.30]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l57MwitV009552; Thu, 7 Jun 2007 22:58:44 GMT From: "Dan Wing" To: "'David Barrett'" , Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Thu, 7 Jun 2007 15:58:43 -0700 Message-ID: <02c601c7a957$66172430$d2dc46ab@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7gAAYpxOA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1685; t=1181257124; x=1182121124; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20BoF=20request=3A=20STUN=20Control=20Usage |Sender:=20; bh=Av/CUE4ydbTMfVjBDDga5EDIwrjsPmGiUsPYFgj53Kc=; b=QzK2CXn5T4si/XxEpPoviU7I4tYYmrNNgj4UE1esW2sSxJpm8ok6Rwy4w+HVtor2Yx2tUpFF Uxhk3j3vm7wGuEqEyG8U7CaQ3ts8Ae5C0yvbkUnLRQxr6GCP5jv8KT/M; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Subject: [BEHAVE] BoF request: STUN Control Usage > > > > 1. ICE works. This has been well demonstrated by its successful > > deployment on the Internet by millions of endpoints. It works > > without explicit support by subscriber's NATs or ISP's NATs. > > Just curious, what statistics are available on ICE's > real-world usage and NAT-penetration success rates? Specifically: > > - How did you come up with the "millions of endpoints" number? GoogleTalk's API, Google Talk itself, Microsoft's Windows Live Messenger (formerly called MSN), and Yahoo Messenger all use ICE. > - What does "works" mean? (I'd suggest this be measured in > "direct peer connectivity ratio" and "connection setup time", > but any measure will do.) I found this, "Improving ICE Service Selection in a P2P System using the Gradient Topology", http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf which includes the following quote: [...] Google's estimate that 8% of the GoogleTalk traffic is routed using relay nodes. which cites Google. Google talk, Accessed, Feb 22, 2007. http://code.google.com/apis/talk/libjingle which leads one to: http://code.google.com/apis/talk/libjingle/important_concepts.html > Granted, it might be a bit OT given that you're really trying > to talk about STUN, but I'm always interested in new real-world > statistics. It's a worthwhile discussion, even if a bit off topic. If STUN/ICE were more, or less, common on the Internet would you find a BoF on optimizing STUN more, or less, important? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 07 23:00:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUiS-00074H-Oe; Thu, 07 Jun 2007 23:00:44 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwUiQ-000746-W1 for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 23:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUiQ-00073s-Je for behave@ietf.org; Thu, 07 Jun 2007 23:00:42 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwUiO-0006j0-Jt for behave@ietf.org; Thu, 07 Jun 2007 23:00:42 -0400 Received: from lappy ([70.6.232.172]) by quinthar.com for ; Thu, 7 Jun 2007 20:00:31 -0700 From: "David Barrett" To: Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Thu, 7 Jun 2007 20:00:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7gAAYpxOAACJ0pgA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <02c601c7a957$66172430$d2dc46ab@amer.cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Message-Id: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Subject: [BEHAVE] BoF request: STUN Control Usage > > > > > > 1. ICE works. This has been well demonstrated by its successful > > > deployment on the Internet by millions of endpoints. It works > > > without explicit support by subscriber's NATs or ISP's NATs. > > > > Just curious, what statistics are available on ICE's > > real-world usage and NAT-penetration success rates? Specifically: > > > > - How did you come up with the "millions of endpoints" number? > > GoogleTalk's API, Google Talk itself, Microsoft's Windows Live > Messenger (formerly called MSN), and Yahoo Messenger all use > ICE. Ok, that's true, ICE code exists on millions of computers. I wonder what fraction of those clients actually use the VoIP features, however. It'd be neat to know how (or estimate) many ICE sessions are established daily, especially as a fraction of total P2P VoIP connections. Incidentally, do you know if it's possible to establish VoIP communications between these networks? Has it been demonstrated that these different ICE implementations are in fact compatible, or are they more "ICE-influenced"? > > - What does "works" mean? (I'd suggest this be measured in > > "direct peer connectivity ratio" and "connection setup time", > > but any measure will do.) > > I found this, "Improving ICE Service Selection in a P2P System > using the Gradient Topology", > http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf > which includes the following quote: > > [...] Google's estimate that 8% of the GoogleTalk traffic > is routed using relay nodes. Very cool, thanks! > > Granted, it might be a bit OT given that you're really trying > > to talk about STUN, but I'm always interested in new real-world > > statistics. > > It's a worthwhile discussion, even if a bit off topic. > > If STUN/ICE were more, or less, common on the Internet would you > find a BoF on optimizing STUN more, or less, important? Well, I don't know the answers to the above questions I pose, but I'd wager that the actual utility of ICE in the real world today is less dramatic than "millions of endpoints" would suggest. If that's true (and I have no data to suggest it is or isn't), I'd suggest that perhaps we should work on determining why ICE isn't more widely used and focus on that. For example, has it been proven that different ICE implementations interoperate as smoothly in practice as they should in theory? If not, what real-world lessons can be drawn and applied to perhaps improve practical interoperability going forward? 92% peer connectivity is pretty good -- perhaps there are bigger fish to fry than getting to 95% or 99%? And while I realize this is all about ICE, I think this might be relevant to STUN because there are a finite number of people in the IETF working on P2P, and their time is a scarce commodity. Given that ICE is STUN's primary customer, STUN's fortunes sink or swim with ICE's (just as ICE's fortunes sink or swim on SIP's). As such, until it's been demonstrated that ICE and SIP are already swimming (which they might be), I'd be hesitant to spend much energy on expanding STUN beyond the strict functionality required by ICE and would instead refocus that effort on making ICE and SIP more relevant in the real world. Said another way, until some measurable, significant fraction (25%?) of the world's P2P VoIP calls use a SIP/ICE/STUN stack, I think the focus should be on smoothing out the practical wrinkles that prevent greater adoption over improving the theoretical capabilities of an underutilized protocol. Reducing chattiness of STUN sounds great, but the amount of energy it'll take to not only standardize the protocol but push standard implementation into a significant portion of the world's NATs seems high. If we could measure all that energy into manhours, I wonder what better way those hours might be spent? -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 07 23:36:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVHP-0003Ez-VC; Thu, 07 Jun 2007 23:36:51 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwVHN-0003Eq-Pt for behave-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 23:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVHN-0003Ei-G6 for behave@ietf.org; Thu, 07 Jun 2007 23:36:49 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwVHL-0002WA-To for behave@ietf.org; Thu, 07 Jun 2007 23:36:49 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2007 20:36:47 -0700 X-IronPort-AV: i="4.16,397,1175497200"; d="scan'208"; a="491732564:sNHT50345828" 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 l583al6G003215; Thu, 7 Jun 2007 20:36:47 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l583aktV018324; Fri, 8 Jun 2007 03:36:46 GMT From: "Dan Wing" To: "'David Barrett'" , Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Thu, 7 Jun 2007 20:36:46 -0700 Message-ID: <004101c7a97e$3dceb980$1ea36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7gAAYpxOAACJ0pgAAB+rkA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5304; t=1181273807; x=1182137807; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20BoF=20request=3A=20STUN=20Control=20Usage |Sender:=20; bh=3jSMQ6U3WFKuju89KD8gVI3DBdD03cCRiUOM4f+cfMI=; b=iEOuJ+68cC8Syt+5yQm7wtPCqdLSvF8TWME4PfPQMUlwu3l1oe3JymcNkVBiBGQWzclMm4YV qdz/64wNsCfbgpcS2eMZ5DJQ6vL2bcDiFN7YZyP0MPkLnUKIr1931mna; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > > Just curious, what statistics are available on ICE's > > > real-world usage and NAT-penetration success rates? Specifically: > > > > > > - How did you come up with the "millions of endpoints" number? > > > > GoogleTalk's API, Google Talk itself, Microsoft's Windows Live > > Messenger (formerly called MSN), and Yahoo Messenger all use > > ICE. > > Ok, that's true, ICE code exists on millions of computers. I > wonder what fraction of those clients actually use the VoIP > features, however. Dunno. > It'd be neat to know how (or estimate) many ICE sessions are > established daily, especially as a fraction of total P2P > VoIP connections. > > Incidentally, do you know if it's possible to establish VoIP > communications between these networks? I don't know. I know Microsoft and Yahoo have collaborated with their IM systems, but I don't know if that includes VoIP. > Has it been demonstrated that these different ICE > implementations are in fact compatible, or are they more > "ICE-influenced"? ICE isn't finished, and early ICE versions are not compatible with each other. Thus, there isn't much hope those different networks would be compatible until until ICE has gone to RFC or if those networks had worked out a version of ICE they mutually agreed they would interoperate with (thus creating a defacto standard). > > > - What does "works" mean? (I'd suggest this be measured in > > > "direct peer connectivity ratio" and "connection setup time", > > > but any measure will do.) > > > > I found this, "Improving ICE Service Selection in a P2P System > > using the Gradient Topology", > > http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf > > which includes the following quote: > > > > [...] Google's estimate that 8% of the GoogleTalk traffic > > is routed using relay nodes. > > Very cool, thanks! > > > > > Granted, it might be a bit OT given that you're really trying > > > to talk about STUN, but I'm always interested in new real-world > > > statistics. > > > > It's a worthwhile discussion, even if a bit off topic. > > > > If STUN/ICE were more, or less, common on the Internet would you > > find a BoF on optimizing STUN more, or less, important? > > Well, I don't know the answers to the above questions I pose, > but I'd wager that the actual utility of ICE in the real world > today is less dramatic than "millions of endpoints" would suggest. > If that's true (and I have no data to suggest it is or isn't), > I'd suggest that perhaps we should work on determining why ICE > isn't more widely used and focus on that. > > For example, has it been proven that different ICE implementations > interoperate as smoothly in practice as they should in > theory? If not, what real-world lessons can be drawn and applied > to perhaps improve practical interoperability going forward? 92% > peer connectivity is pretty good -- perhaps there are bigger > fish to fry than getting to 95% or 99%? Google's analysis is based on their own (GoogleTalk) network, I would expect -- not GoogleTalk-to-something-else. I expect their 92% number is based on how often two users, each behind NATs with the 'Address and Port-Dependent Mapping' property (RFC4787) attempt to talk with each other (this property was formerly called 'symmetric NAT'). With ICE, since approximately ice-10, that is the only case that causes a media relay to be utilized. > And while I realize this is all about ICE, I think this might > be relevant to STUN because there are a finite number of people > in the IETF working on P2P, and their time is a scarce > commodity. Given that ICE is STUN's primary customer, STUN's > fortunes sink or swim with ICE's (just as ICE's fortunes > sink or swim on SIP's). > > As such, until it's been demonstrated that ICE and SIP are > already swimming (which they might be), I'd be hesitant to > spend much energy on expanding STUN beyond the strict > functionality required by ICE and would instead refocus that > effort on making ICE and SIP more relevant in > the real world. > > Said another way, until some measurable, significant fraction > (25%?) of the world's P2P VoIP calls use a SIP/ICE/STUN stack, > I think the focus should be on smoothing out the practical > wrinkles that prevent greater adoption over improving the > theoretical capabilities of an underutilized protocol. Not sure I follow -- all of the major Internet-based IM clients with voice and video capabilities use ICE (except Skype which uses its own techniques), even though ICE isn't even an RFC. The value is so great these products have utilized a pre-standard specification. This seems quite compelling to me, especially considering the difficulties usually incurred in implementing pre-standard specifications in commercial products. > Reducing chattiness of STUN sounds great, but the amount of > energy it'll take to not only standardize the protocol but > push standard implementation into a significant portion of > the world's NATs seems high. If we could measure all that > energy into manhours, I wonder what better way those hours > might be spent? Yes, that's the question. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 00:18:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVvq-00031S-0O; Fri, 08 Jun 2007 00:18:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwVvo-00031N-Nn for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 00:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwVvo-00031F-EM for behave@ietf.org; Fri, 08 Jun 2007 00:18:36 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwVvm-0007sm-R3 for behave@ietf.org; Fri, 08 Jun 2007 00:18:36 -0400 Received: from lappy ([70.0.118.176]) by quinthar.com for ; Thu, 7 Jun 2007 21:18:32 -0700 From: "David Barrett" To: Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Thu, 7 Jun 2007 21:18:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <004101c7a97e$3dceb980$1ea36b80@amer.cisco.com> Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7gAAYpxOAACJ0pgAAB+rkAAACgciA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Message-Id: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > > Google's analysis is based on their own (GoogleTalk) network, I > would expect -- not GoogleTalk-to-something-else. I expect their > 92% number is based on how often two users, each behind > NATs with the 'Address and Port-Dependent Mapping' property > (RFC4787) attempt to talk with each other (this property was > formerly called 'symmetric NAT'). With ICE, since approximately > ice-10, that is the only case that causes a media relay to be > utilized. Ah, ok, so it's a theoretical number. Does anyone know the real number? Until it's been measured empirically, at scale, in the real world, we simply don't know. In my experience, implementing the algorithms is easy, but tweaking them to work in the real world is very, very hard. > > Said another way, until some measurable, significant fraction > > (25%?) of the world's P2P VoIP calls use a SIP/ICE/STUN stack, > > I think the focus should be on smoothing out the practical > > wrinkles that prevent greater adoption over improving the > > theoretical capabilities of an underutilized protocol. > > Not sure I follow -- all of the major Internet-based IM clients > with voice and video capabilities use ICE (except Skype which > uses its own techniques), even though ICE isn't even an RFC. The > value is so great these products have utilized a pre-standard > specification. This seems quite compelling to me, especially > considering the difficulties usually incurred in implementing > pre-standard specifications in commercial products. It's no challenge to get an implementation of a protocol to interoperate with itself (well, it *is* challenging, but that's not the point). The real challenge is having multiple implementations of the same protocol "just work" without out-of-band coordination between the implementers. Saying "these networks support ICE but not each other" is exactly equivalent to saying "these networks have similar protocols -- all called ICE -- and its unknown how much work it'll take to make them speak the same protocol". > > Reducing chattiness of STUN sounds great, but the amount of > > energy it'll take to not only standardize the protocol but > > push standard implementation into a significant portion of > > the world's NATs seems high. If we could measure all that > > energy into manhours, I wonder what better way those hours > > might be spent? > > Yes, that's the question. I don't mean to bash on ICE, but merely to say that until we prove ICE works, ICE hasn't been proven to work. I'd suggest "prove" means "demonstrate in the real world at significant scale" and "work" means: a) Achieves some minimum level of peer connectivity (90%?) b) Is sufficiently unambiguous to interoperate without OOB coordination If it hasn't already been done (and hopefully it has been), these should be the focus. Until then, it's wishful thinking to assume all's in order and move on to something else. Said another way, I think we've certainly achieved "documenting algorithms that can be used to construct a proprietary protocol that achieves an unknown level of NAT penetration". But "standardizing a protocol that, when implemented, ensures a minimum level of effectiveness and a high degree of interoperation on a global scale" remains to be seen. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 02:44:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYCt-0003if-CR; Fri, 08 Jun 2007 02:44:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwYCs-0003iX-VY for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 02:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYCo-0003hq-RF for behave@ietf.org; Fri, 08 Jun 2007 02:44:19 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwYCn-0006W7-DW for behave@ietf.org; Fri, 08 Jun 2007 02:44:18 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l586iDI8025729; Fri, 8 Jun 2007 09:44:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:44:13 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:44:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Fri, 8 Jun 2007 09:44:12 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03CADB8F@esebe103.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] BoF request: STUN Control Usage Thread-Index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7gAAYpxOAACJ0pgAAINF7w References: <02c601c7a957$66172430$d2dc46ab@amer.cisco.com> From: To: X-OriginalArrivalTime: 08 Jun 2007 06:44:13.0558 (UTC) FILETIME=[6D33C160:01C7A998] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi,=20 >Given that ICE is STUN's primary customer, STUN's fortunes=20 >sink or swim with ICE's (just as ICE's fortunes >sink or swim on SIP's). =20 I think this statement is a bit exaggerated. There are already SIP VoIP UA implementations with RFC 3489 version of STUN but without ICE. They are succesfully deployed with environments where the NATs implement Endpoint-Independent Mapping behaviour. Thus fates of STUN and ICE are not as tightly connected to each other as you suggest. ICE provides added value for complex environments, but there are significant deployments which already work pretty well just with SIP combined with STUN. >As such, until it's been demonstrated that ICE and SIP are=20 >already swimming (which they might be), I'd be hesitant to=20 >spend much energy on expanding STUN beyond the strict=20 >functionality required by ICE and would instead refocus=20 >that effort on making ICE and SIP more relevant in the=20 >real world. For the deployments I am referring to, it would be useful to have STUN extended with a mechanism to control the required keepalive interval for NAT binding: - Extensions needed for the already deployed set of=20 protocols would be minimal. - There would be significant benefits both to the traffic in the network and the battery consumption of mobile VoIP devices. So I think this effort is valuable regardless on what happens to ICE. Regards, Erkki _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 03:13:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYfL-0008Ge-Eq; Fri, 08 Jun 2007 03:13:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwYfK-0008GU-KW for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 03:13:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwYfK-0008G8-7P for behave@ietf.org; Fri, 08 Jun 2007 03:13:46 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HwYfI-0007RO-DQ for behave@ietf.org; Fri, 08 Jun 2007 03:13:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D891621678; Fri, 8 Jun 2007 09:13:42 +0200 (CEST) X-AuditID: c1b4fb3e-ae1ebbb0000061ca-d0-466901a6042d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 981B921659; Fri, 8 Jun 2007 09:13:42 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:13:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Fri, 8 Jun 2007 09:13:41 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704EEA9C6@esealmw113.eemea.ericsson.se> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03CADB8F@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] BoF request: STUN Control Usage thread-index: Aceozxd7maRBaOC9RYiWa85MEQK9zwAajl7gAAYpxOAACJ0pgAAINF7wAAG/fYA= References: <02c601c7a957$66172430$d2dc46ab@amer.cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F03CADB8F@esebe103.NOE.Nokia.com> From: "Christer Holmberg (JO/LMF)" To: , X-OriginalArrivalTime: 08 Jun 2007 07:13:41.0685 (UTC) FILETIME=[8B168650:01C7A99C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I think that SIP outbound is as "primary" customer of STUN as ICE is. Regards, Christer > -----Original Message----- > From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 > Sent: 8. kes=E4kuuta 2007 9:44 > To: dbarrett@quinthar.com > Cc: behave@ietf.org > Subject: RE: [BEHAVE] BoF request: STUN Control Usage >=20 > Hi,=20 >=20 > >Given that ICE is STUN's primary customer, STUN's fortunes=20 > sink or swim=20 > >with ICE's (just as ICE's fortunes sink or swim on SIP's). >=20 > I think this statement is a bit exaggerated. There are=20 > already SIP VoIP UA implementations with RFC > 3489 version of STUN but without ICE. They are succesfully=20 > deployed with environments where the NATs implement=20 > Endpoint-Independent Mapping behaviour. >=20 > Thus fates of STUN and ICE are not as tightly connected to=20 > each other as you suggest. ICE provides added value for=20 > complex environments, but there are significant deployments=20 > which already work pretty well just with SIP combined with STUN. >=20 > >As such, until it's been demonstrated that ICE and SIP are already=20 > >swimming (which they might be), I'd be hesitant to spend=20 > much energy on=20 > >expanding STUN beyond the strict functionality required by ICE and=20 > >would instead refocus that effort on making ICE and SIP more=20 > relevant=20 > >in the real world. >=20 > For the deployments I am referring to, it would be useful to=20 > have STUN extended with a mechanism to control the required=20 > keepalive interval for NAT binding: >=20 > - Extensions needed for the already deployed set of > protocols would be minimal. >=20 > - There would be significant benefits both to the > traffic in the network and the battery consumption > of mobile VoIP devices. >=20 > So I think this effort is valuable regardless on what happens to ICE. >=20 > Regards, >=20 > Erkki >=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave >=20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 04:39:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwa05-0000qf-Qt; Fri, 08 Jun 2007 04:39:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwa03-0000qU-3H for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 04:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwa01-0000qL-Hn for behave@ietf.org; Fri, 08 Jun 2007 04:39:14 -0400 Received: from smtp3.wanadoo.co.uk ([193.252.22.156] helo=smtp3.freeserve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwa00-0004Dy-7i for behave@ietf.org; Fri, 08 Jun 2007 04:39:13 -0400 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3204.me.freeserve.com (SMTP Server) with ESMTP id 18F3F1C00086; Fri, 8 Jun 2007 10:39:09 +0200 (CEST) Received: from Codalogic (user-5444c8e7.lns1-c11.dsl.pol.co.uk [84.68.200.231]) by mwinf3204.me.freeserve.com (SMTP Server) with ESMTP id CE13D1C00085; Fri, 8 Jun 2007 10:39:08 +0200 (CEST) X-ME-UUID: 20070608083908844.CE13D1C00085@mwinf3204.me.freeserve.com Message-ID: <001201c7a9a8$7a5948a0$1300a8c0@Codalogic> From: "Pete Cordell" To: "David Barrett" , References: Subject: Re: [BEHAVE] BoF request: STUN Control Usage Date: Fri, 8 Jun 2007 09:38:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org ----- Original Message From: "David Barrett" > Reducing chattiness of STUN sounds great, but the amount of energy it'll > take to not only standardize the protocol but push standard implementation > into a significant portion of the world's NATs seems high. If we could > measure all that energy into man-hours, I wonder what better way those > hours > might be spent? Alas, IMO, nobody has a better idea of where such man-hours could be spent. I think STUN control is a small incremental piece of work and it makes sense to do it while the expertise is still present in the behave WG and all the various issues and interactions are current in peoples' minds. Also, for better or worse, things like STUN, ICE, outbound are all inter-related and it seems sensible to deliver them as a package rather than trying to bake one and then move onto the next. At least then, if, in the unlikely event that ICE requires a tweak to allow for STUN control, then it can be done. Finally, it's seemed obvious to me from day 1 that 'the' NAT would be the ideal location for the STUN server. So, IMO, the work should go ahead. Regards, Pete. -- ============================================= Pete Cordell Codalogic Ltd for XML Schema to C++ data binding visit http://www.codalogic.com/lmx/ ============================================= _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 06:24:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbdN-0003Xm-TT; Fri, 08 Jun 2007 06:23:57 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwbdM-0003XT-NB for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 06:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbdM-0003XG-BC; Fri, 08 Jun 2007 06:23:56 -0400 Received: from [80.81.115.248] (helo=soportemv.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwbdK-0005Ia-VE; Fri, 08 Jun 2007 06:23:56 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jun 2007 12:21:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gAB425SAAMQ20uQBbMscwAAMSieA= References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> <1E4CCB2441C5C0409AD8A929482A09F302AF4E46@S4DE9JSAAIG.ost.t-com.de> From: "Alvaro Fernandez" To: "Leymann, Nicolai" , , , , X-Spam-Score: 0.1 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: Subject: [BEHAVE] RE: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1299767673==" Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. --===============1299767673== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9B7.179BD85E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9B7.179BD85E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Leyman: =20 One possible solution ( out of the scope of the draft) =20 1. The sender behind the NAPT sends the channel (Si,Gj) using a random = Gj inside the multicast SSS range 2. Logically the sender expects that some one will be interested in the = data, so the sender sends a unicast message (for example http) to a = "multicast index portal" describing the content and the channel (Si,Gj) 3. The NAPT changes the internal Si into a IP public in both cases: the = unicast data and the multicast data using the same IP public. 4. The multicast portal knows the IP public and tries to connect with = the multicast channel ( IP public, Gj) If the multicast portal connects with ( IP public, Gj) there is no Gj = collision and the portal shows the channel (IP public, Gj) in its index. = Everybody can connect. 5. If after a few seconds the channel don't appears in the index, the = senders understands that there is a multicast Group collision and = changes the Gj into another randomly selected Gk. =20 Another business for the search engines. =20 Regards Alvaro ________________________________ De: Leymann, Nicolai [mailto:Nicolai.Leymann@t-systems.com] Enviado el: vie 08/06/2007 11:44 Para: Alvaro Fernandez; albert.e.manfredi@boeing.com; behave@ietf.org; = mboned@ietf.org; magma@ietf.org Asunto: AW: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt Hi Everybody, > Hi all. > If you have two sources from two different inside interfaces > sending multicast data to the outside interface and both > sources use the same multicast address (G1) then outside > routers, using for example PIM-SM, will consider that there > is only one multicast channel and will send all the traffic. > Also hosts receiving all the traffic need to separate it. Right. This is from my point of view not the solution you want. The reason for SSM is to have different senders (source) using the same group and to be able to route based on (S,G) information. > One solution is to reserve an IP address range inside SSM range > ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change, > not only the source address of the sender, but also the multicast > address of the sender to be unique in this range. In this way > outside routers ( and receivers ) will consider traffic as coming > from different channels (IP public ,G2) and ( IP public, G3) with > G2 and G3 inside the said range. The main problem is how to signal either the (S,G) channel or the multicast group if this information is changed by a NAPT device. E.g. in a typical IPTV scenario the signalling of the group or channel information is done out-bband using servers providing information about the IPTV channels. Clients are receiving this information from the server (http/xml) to join the appropriate IPTV channels. If a sender (S1) sends multicast traffic to a group (G1) the receiver joins (S1,G1) due to the information it got from the server. If the NAPT device changes this to (S2,G1) or (S1,G2) the receiver is not going to receive any traffic. I'm not sure if this problem can be solved without making to many assumptions about the applications deploying IP-Multicast. Regards Nic ________________________________ De: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Enviado el: mar 05/06/2007 16:02 Para: behave@ietf.org; mboned@ietf.org; magma@ietf.org Asunto: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt =20 =20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, June 04, 2007 7:38 PM > To: mboned@ietf.org; magma@ietf.org > Cc: 'Behave WG' > Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt > > The BEHAVE working group concluded its WGLC of > draft-ietf-behave-multicast-06 with no comments received. I > would like > MBONED and MAGMA to please take a look at this draft prior to > its submission > to IESG. > > Please send replies to behave@ietf.org. Thanks! =20 =20 http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: =20 What if the NAPT or NAT device just passed IGMP queries and reports through, changing only the source address of the reports, and let the multicast router outside do all the hard work? I'm wondering whether the IGMP aggregation function is mandatory in NAT/NATP. =20 Bert =20 _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma =20 ------_=_NextPart_001_01C7A9B7.179BD85E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt=0A= =0A= =0A= =0A=
=0A=
=0A=

Leyman:

=0A=

 

=0A=

One possible solution ( out of the scope of the = draft)

=0A=

 

=0A=

1. The sender behind the  NAPT sends the channel (Si,Gj) using a random Gj = inside the multicast SSS range

=0A=

2. Logically the sender expects that some one will be = interested in the data, so the sender sends a unicast message (for = example http)  to a = “multicast index portal” describing the content and the = channel (Si,Gj)

=0A=

3. The NAPT changes the internal Si into a IP public in both = cases: the unicast data and the multicast data using the same IP = public.

=0A=

4. The multicast portal knows the IP public and tries to = connect with the multicast channel ( IP public, = Gj)

=0A=

If the multicast portal connects with ( IP public, Gj) there = is no Gj collision and the portal shows the channel (IP public, Gj) in = its index. Everybody can connect.

=0A=

5. If after a few seconds the channel don’t appears in = the index, the senders understands that there is a multicast Group = collision and changes the Gj into another randomly selected = Gk.

=0A=

 

=0A=

Another business for the search = engines.

=0A=

 

=0A=

Regards

=0A=


Alvaro

=0A=

=0A=
=0A= De: Leymann, Nicolai = [mailto:Nicolai.Leymann@t-systems.com]
Enviado el: vie = 08/06/2007 11:44
Para: Alvaro Fernandez; = albert.e.manfredi@boeing.com; behave@ietf.org; mboned@ietf.org; = magma@ietf.org
Asunto: AW: [magma] RE: [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt

=0A=
=0A=

Hi Everybody,

> Hi all.
> If you have = two sources from two different inside interfaces
> sending = multicast data to the outside interface and both
> sources use the = same multicast address (G1) then outside
> routers, using for = example PIM-SM, will consider that there
> is only one multicast = channel and will send all the traffic.
> Also hosts receiving all = the traffic need to separate it.
Right. This is from my point of view = not the solution you want.
The reason for SSM is to have different = senders (source) using
the same group and to be able to route based = on (S,G) information.

> One solution is to reserve an IP = address range inside SSM range
> ( for example 232.0.0.0 to = 232.0.255.255) and let the NAPT change,
> not only the source = address of the sender, but also the multicast
> address of the = sender to be unique in this range. In this way
> outside routers ( = and receivers ) will consider traffic as coming
> from different = channels (IP public ,G2) and ( IP public, G3) with
> G2 and G3 = inside the said range.
The main problem is how to signal either the = (S,G) channel or the
multicast group if this information is changed = by a NAPT device.

E.g. in a typical IPTV scenario the signalling = of the group or
channel information is done out-bband using servers = providing
information about the IPTV channels. Clients are receiving = this
information from the server (http/xml) to join the = appropriate
IPTV channels.

If a sender (S1) sends multicast = traffic to a group (G1) the receiver
joins (S1,G1) due to the = information it got from the server. If the
NAPT device changes this = to (S2,G1) or (S1,G2) the receiver is not
going to receive any = traffic.

I'm not sure if this problem can be solved without = making to many
assumptions about the applications deploying = IP-Multicast.

  Regards

     = Nic

________________________________

   &nbs= p;    De: Manfredi, Albert E [mailto:albert.e.manfredi@boe= ing.com]
        Enviado el: = mar 05/06/2007 16:02
        Para: = behave@ietf.org; mboned@ietf.org; = magma@ietf.org
        Asunto: = [magma] RE: [MBONED] FW: = WGLC:
draft-ietf-behave-multicast-06.txt
    &n= bsp;  
       

&nb= sp;       > -----Original = Message-----
        > From: = Dan Wing [mailto:dwing@cisco.com]
 &nbs= p;      > Sent: Monday, June 04, 2007 7:38 = PM
        > To: = mboned@ietf.org; = magma@ietf.org
        > Cc: = 'Behave WG'
        > Subject: = [MBONED] FW: WGLC: = draft-ietf-behave-multicast-06.txt
      = ;  >
        > The = BEHAVE working group concluded its WGLC = of
        > = draft-ietf-behave-multicast-06 with no comments received.  = I
        > would = like
        > MBONED and MAGMA = to please take a look at this draft prior = to
        > its = submission
        > to = IESG.
        = >
        > Please send = replies to behave@ietf.org.  = Thanks!
       
  &nbs= p;    
http://www.ietf.org/internet-drafts/draft-i= etf-behave-multicast-06.txt:
       = ;
        What if the NAPT or NAT = device just passed IGMP queries = and
reports
        through, = changing only the source address of the reports, and
let = the
        multicast router = outside do all the hard work? I'm wondering
whether = the
        IGMP aggregation = function is mandatory in = NAT/NATP.
       
  &n= bsp;     = Bert
       
   &= nbsp;    = _______________________________________________
   &nbs= p;    magma mailing = list
        = magma@ietf.org
        https://www1.ietf.o= rg/mailman/listinfo/magma
      &nbs= p;

------_=_NextPart_001_01C7A9B7.179BD85E-- --===============1299767673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1299767673==-- From behave-bounces@ietf.org Fri Jun 08 10:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfIW-0005iI-Op; Fri, 08 Jun 2007 10:18:40 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwfIT-0005hD-KI for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 10:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfIT-0005h5-Ac for behave@ietf.org; Fri, 08 Jun 2007 10:18:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfIQ-00085u-Sk for behave@ietf.org; Fri, 08 Jun 2007 10:18:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2007 07:18:34 -0700 X-IronPort-AV: i="4.16,400,1175497200"; d="scan'208"; a="161730359:sNHT48865608" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l58EIYia009368; Fri, 8 Jun 2007 07:18:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l58EIYaI027616; Fri, 8 Jun 2007 14:18:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 07:18:34 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 07:18:33 -0700 Message-ID: <46696538.8090303@cisco.com> Date: Fri, 08 Jun 2007 10:18:32 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [BEHAVE] BoF request: STUN Control Usage References: <02c601c7a957$66172430$d2dc46ab@amer.cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F03CADB8F@esebe103.NOE.Nokia.com> <7374777208BDC7449D5620EF9423256704EEA9C6@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256704EEA9C6@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Jun 2007 14:18:33.0616 (UTC) FILETIME=[E5768100:01C7A9D7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3227; t=1181312314; x=1182176314; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BEHAVE]=20BoF=20request=3A=20STUN=20Control=20Usage |Sender:=20; bh=kOIwjJ6DecQods06tg4W4eciteMC6fY+WlJvQTpVq8Y=; b=ikoCIp9xCWV7AydN41JwvdxoyNZW2k/gBu25oe/39OqkNe40f5qiXvLBPtHhDOr4JfqaDmJ3 pDM8OAmZJQjs0+zgipQZWm1J7KSFbs4ZyQLaFYzr2iy0kB1/LqjY9Bo2; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: behave@ietf.org, Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org To take this a step further, I think sip-outbound is the primary benefactor of stun-control, not ICE. The big pain point today are these awful keepalives we need to constantly be sending for sip-outbound. WHen UDP is used, its every 20 or 30 seconds. That represents a huge load on the servers even when its STUN (though much better than REGISTER like what SBCs use today). With stun control, we could control this so that SIP servers would see reduction in stun volume by one or even two orders of magnitude. That is a real big bang for the buck. Also benefits wireless applications. -Jonathan R. Christer Holmberg (JO/LMF) wrote: > Hi, > > I think that SIP outbound is as "primary" customer of STUN as ICE is. > > Regards, > > Christer > > >>-----Original Message----- >>From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com] >>Sent: 8. kesäkuuta 2007 9:44 >>To: dbarrett@quinthar.com >>Cc: behave@ietf.org >>Subject: RE: [BEHAVE] BoF request: STUN Control Usage >> >>Hi, >> >> >>>Given that ICE is STUN's primary customer, STUN's fortunes >> >>sink or swim >> >>>with ICE's (just as ICE's fortunes sink or swim on SIP's). >> >>I think this statement is a bit exaggerated. There are >>already SIP VoIP UA implementations with RFC >>3489 version of STUN but without ICE. They are succesfully >>deployed with environments where the NATs implement >>Endpoint-Independent Mapping behaviour. >> >>Thus fates of STUN and ICE are not as tightly connected to >>each other as you suggest. ICE provides added value for >>complex environments, but there are significant deployments >>which already work pretty well just with SIP combined with STUN. >> >> >>>As such, until it's been demonstrated that ICE and SIP are already >>>swimming (which they might be), I'd be hesitant to spend >> >>much energy on >> >>>expanding STUN beyond the strict functionality required by ICE and >>>would instead refocus that effort on making ICE and SIP more >> >>relevant >> >>>in the real world. >> >>For the deployments I am referring to, it would be useful to >>have STUN extended with a mechanism to control the required >>keepalive interval for NAT binding: >> >>- Extensions needed for the already deployed set of >> protocols would be minimal. >> >>- There would be significant benefits both to the >> traffic in the network and the battery consumption >> of mobile VoIP devices. >> >>So I think this effort is valuable regardless on what happens to ICE. >> >>Regards, >> >>Erkki >> >> >>_______________________________________________ >>Behave mailing list >>Behave@ietf.org >>https://www1.ietf.org/mailman/listinfo/behave >> > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 10:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfTi-0004dy-Qq; Fri, 08 Jun 2007 10:30:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwfTh-0004dS-4C for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 10:30:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfTg-0004dJ-Qm; Fri, 08 Jun 2007 10:30:12 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfTf-0004vH-HW; Fri, 08 Jun 2007 10:30:12 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:60721) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1HwfTZ-0000o3-Pg; Fri, 08 Jun 2007 15:30:05 +0100 In-Reply-To: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> References: <289643F2-2529-4C24-B430-B9967B5DADD4@csperkins.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58FFB38C-B79B-4C13-A8D9-2CC7A5FC2EC0@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Fri, 8 Jun 2007 15:30:13 +0100 To: mmusic , Behave WG , IETF AVT WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Xavier Marjou , Tom Taylor , Joerg Ott , Jean-Francois Mule , "Dan Wing \(\(\(\(dwing\)\)\)\)" Subject: [BEHAVE] Re: [AVT] Moving draft-marjou-behave-app-rtp-keepalive to AVT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 1 Jun 2007, at 18:15, Colin Perkins wrote: > There has been some private discussion on adopting the draft on > Application Mechanisms for maintaining alive NAT mappings > associated with RTP flows (draft-marjou-behave-app-rtp- > keepalive-01.txt) as an AVT working group draft. This has > previously been discussed in AVT, BEHAVE and MMUSIC. Opinions on > whether this draft should become a working group draft, and on the > appropriate home for it, are solicited by 8 June 2007. There were several comments in favour of this proposal, and no objections. Accordingly, we will take this draft as an AVT work item. -- Colin Perkins http://csperkins.org/ _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 12:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwhE4-00044d-0i; Fri, 08 Jun 2007 12:22:12 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwb1Y-000787-Jq for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 05:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwb1X-00076Y-Rs; Fri, 08 Jun 2007 05:44:51 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwb1V-0003Zh-CC; Fri, 08 Jun 2007 05:44:51 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Fri, 8 Jun 2007 11:44:44 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 11:44:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 11:44:43 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F302AF4E46@S4DE9JSAAIG.ost.t-com.de> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Thread-index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gAB425SAAMQ20uQBbMscw References: <06b401c7a701$6e0a8ea0$c2f0200a@amer.cisco.com> From: "Leymann, Nicolai" To: , , , , X-OriginalArrivalTime: 08 Jun 2007 09:44:44.0009 (UTC) FILETIME=[A4A76D90:01C7A9B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Fri, 08 Jun 2007 12:22:11 -0400 Cc: Subject: [BEHAVE] AW: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Everybody, > Hi all. > If you have two sources from two different inside interfaces=20 > sending multicast data to the outside interface and both=20 > sources use the same multicast address (G1) then outside=20 > routers, using for example PIM-SM, will consider that there=20 > is only one multicast channel and will send all the traffic.=20 > Also hosts receiving all the traffic need to separate it. Right. This is from my point of view not the solution you want. The reason for SSM is to have different senders (source) using the same group and to be able to route based on (S,G) information. > One solution is to reserve an IP address range inside SSM range=20 > ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change,=20 > not only the source address of the sender, but also the multicast=20 > address of the sender to be unique in this range. In this way=20 > outside routers ( and receivers ) will consider traffic as coming=20 > from different channels (IP public ,G2) and ( IP public, G3) with=20 > G2 and G3 inside the said range. The main problem is how to signal either the (S,G) channel or the=20 multicast group if this information is changed by a NAPT device. E.g. in a typical IPTV scenario the signalling of the group or channel information is done out-bband using servers providing information about the IPTV channels. Clients are receiving this=20 information from the server (http/xml) to join the appropriate=20 IPTV channels. If a sender (S1) sends multicast traffic to a group (G1) the receiver joins (S1,G1) due to the information it got from the server. If the NAPT device changes this to (S2,G1) or (S1,G2) the receiver is not going to receive any traffic. I'm not sure if this problem can be solved without making to many assumptions about the applications deploying IP-Multicast. Regards Nic ________________________________ De: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] Enviado el: mar 05/06/2007 16:02 Para: behave@ietf.org; mboned@ietf.org; magma@ietf.org Asunto: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt =09 =09 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Monday, June 04, 2007 7:38 PM > To: mboned@ietf.org; magma@ietf.org > Cc: 'Behave WG' > Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt > > The BEHAVE working group concluded its WGLC of > draft-ietf-behave-multicast-06 with no comments received. I > would like > MBONED and MAGMA to please take a look at this draft prior to > its submission > to IESG. > > Please send replies to behave@ietf.org. Thanks! =09 =09 http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: =09 What if the NAPT or NAT device just passed IGMP queries and reports through, changing only the source address of the reports, and let the multicast router outside do all the hard work? I'm wondering whether the IGMP aggregation function is mandatory in NAT/NATP. =09 Bert =09 _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma =09 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 14:14:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiz2-0005Hm-Vi; Fri, 08 Jun 2007 14:14:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwiz1-00058p-B3 for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 14:14:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwiz1-00057U-0t for behave@ietf.org; Fri, 08 Jun 2007 14:14:47 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwiyz-0005Ua-He for behave@ietf.org; Fri, 08 Jun 2007 14:14:47 -0400 Received: from lappy ([68.127.106.232]) by quinthar.com for ; Fri, 8 Jun 2007 11:14:36 -0700 From: "David Barrett" To: "'Jonathan Rosenberg'" , "'Christer Holmberg \(JO/LMF\)'" Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Fri, 8 Jun 2007 11:14:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46696538.8090303@cisco.com> Thread-Index: Acep2BfCXoKQO6i2RGiCP828PeoBCgAHn+kw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Message-Id: Cc: behave@ietf.org, Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Subject: Re: [BEHAVE] BoF request: STUN Control Usage > > The big pain point today are these awful keepalives we need to > constantly be sending for sip-outbound. WHen UDP is used, its every 20 > or 30 seconds. That represents a huge load on the servers even when its > STUN (though much better than REGISTER like what SBCs use today). Again, just to push back on this a bit, how "huge" is a huge load? In my experience the keepalive traffic is the best kind: negligible, totally predictable, and scales linearly with userbase. All things being equal I'd prefer it weren't necessary, but it's certainly not on the radar as being a problem worth worrying about. (If traffic is really such a huge problem, let's just reduce the packet size -- a single packet is all that's really needed to get the job done.) Rather, the "cost" of unknown timeouts (the real problem STUN Control is meant to solve) is engineering to accommodate them. But unfortunately, until STUN Control has near universal deployment -- and especially given that there's no way to detect if a non-STUN-Control-compliant gateway is in place -- we'll all still need to code exactly as if the STUN-Control protocol didn't exist. (Indeed, it'll be *more* costly as now we need to support another protocol.) In effect, STUN Control has a value curve looking like a square wave of near-zero (even sub-zero) reduction of P2P software complexity up to something like 90% global deployment (at which point application developers are ok with just accepting a smaller userbase as the price of convenience). I don't mean to be negative, but it just seems like a huge burden to accomplish this and -- if I as a P2P software developer am meant to be the benefactor -- I'd suggest the gain isn't worth the cost. Personally, I would *much* rather that we just spend that same energy getting BEHAVE deployed faster, or getting SIP/ICE/STUN used more widely (starting with just quantifying how widely in fact they are being used). Otherwise I fear we'd just create a document describing a neat protocol that in theory does great things but in practice has limited (or unknown) utility. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 16:17:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwktJ-0000Pc-IS; Fri, 08 Jun 2007 16:17:01 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwktI-0000Oe-Bq for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 16:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwktH-0000Mz-Sn for behave@ietf.org; Fri, 08 Jun 2007 16:16:59 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwktH-0006l6-IG for behave@ietf.org; Fri, 08 Jun 2007 16:16:59 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2007 13:16:59 -0700 X-IronPort-AV: i="4.16,400,1175497200"; d="scan'208"; a="4616512:sNHT21501258" 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 l58KGxo5011984 for ; Fri, 8 Jun 2007 13:16:59 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l58KGwaI022999 for ; Fri, 8 Jun 2007 20:16:58 GMT From: "Dan Wing" To: Date: Fri, 8 Jun 2007 13:16:57 -0700 Message-ID: <023001c7aa09$f6d043a0$1ea36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcepgcS9vIs9PxaoQs648TrsEuJJLAAiCssw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1953; t=1181333819; x=1182197819; 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:=20FW=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=2 0the=2069th=20IETF=20=20Meeting=20in=20Chicago,=20IL,=20USA=20 |Sender:=20; bh=QPt1s8JxTwe/IGlUfI/ftkeJ3W1mVWYibfLmXQYJZVc=; b=j1DOAuWe1gQinDH+hdadBBi3ypqYww2FSbWuAT8WEVmKFEKM2Xrxsr0qJEs4UBXHPn5dz8bS KmqGq2XTCHKAJ9DjZLqq45DahdgRzVLGA0huJTA0Lh241ME53EZmCPQXAd3IN79vJ2rZF3PQzY D3oqRpVVgoGarThCHZPzQL6/8=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [BEHAVE] FW: Internet-Drafts Submission Cutoff Dates for the 69th IETF Meeting in Chicago, IL, USA X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org] > Sent: Thursday, June 07, 2007 9:00 PM > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 69th > IETF Meeting in Chicago, IL, USA > > > There are two (2) Internet-Draft cutoff dates for the 69th > IETF Meeting in Chicago, IL, USA: > > July 2nd: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted > by Monday, > July 2nd at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 25th at 9:00 AM ET. > > July 9th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be > submitted > by Monday, July 9th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 23rd at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other > significant dates > for the 69th IETF Meeting can be found at > http://www.ietf.org/meetings/cutoff_dates_69.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 16:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwkud-0001KC-7T; Fri, 08 Jun 2007 16:18:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwkub-0001Je-P2 for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 16:18:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwka1-0003Fj-9a for behave@ietf.org; Fri, 08 Jun 2007 15:57:06 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkZy-0003pK-DQ for behave@ietf.org; Fri, 08 Jun 2007 15:57:03 -0400 Received: by wx-out-0506.google.com with SMTP id t5so772643wxc for ; Fri, 08 Jun 2007 12:57:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LmU6Qeds/FkpLqNQuY/xKN97eTDGUUT3BcEDzn8P8+ioMZsUTbFavrwedlE9YtirXW4DLeDnJij6VKzy6hAJs5e/Y2m9seUy2uQ8fU/r9h97j9WK4PeusS7PHHT+tEMnwwxqsOupn4QG4jBQ6DQUVcYJ0mUe/fOs35+POp5lrBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PmuQ16/gY9iCMlwdrW2P2NKLQjrfoTtZoUbaYNvuoEmBANrBfA+yHLH+QPodFRu7lfeM2U1mVJaAzpQ7wsyTL7XqdtGG1/EyNKNE7prIAG7J2w9rhqjMYlPgYUl2I16cRk71P8OZCisLMRzmkyIBH4idoQoFu1dvH/Rf7Pz/1kQ= Received: by 10.90.83.14 with SMTP id g14mr2372901agb.1181332622100; Fri, 08 Jun 2007 12:57:02 -0700 (PDT) Received: by 10.90.56.13 with HTTP; Fri, 8 Jun 2007 12:57:02 -0700 (PDT) Message-ID: Date: Fri, 8 Jun 2007 15:57:02 -0400 From: "Adam Fisk" To: "Jonathan Rosenberg" Subject: Re: [BEHAVE] BoF request: STUN Control Usage In-Reply-To: <46696538.8090303@cisco.com> MIME-Version: 1.0 References: <02c601c7a957$66172430$d2dc46ab@amer.cisco.com> <8B1D53AEF7B03449A6D3771B3B7F850F03CADB8F@esebe103.NOE.Nokia.com> <7374777208BDC7449D5620EF9423256704EEA9C6@esealmw113.eemea.ericsson.se> <46696538.8090303@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Erkki.Koivusalo@nokia.com, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1556499936==" Errors-To: behave-bounces@ietf.org --===============1556499936== Content-Type: multipart/alternative; boundary="----=_Part_42754_20711238.1181332622062" ------=_Part_42754_20711238.1181332622062 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/8/07, Jonathan Rosenberg wrote: > > To take this a step further, I think sip-outbound is the primary > benefactor of stun-control, not ICE. Agreed. The big pain point today are these awful keepalives we need to > constantly be sending for sip-outbound. WHen UDP is used, its every 20 > or 30 seconds. That represents a huge load on the servers even when its > STUN (though much better than REGISTER like what SBCs use today). With > stun control, we could control this so that SIP servers would see > reduction in stun volume by one or even two orders of magnitude. That is > a real big bang for the buck. Also benefits wireless applications. Any idea how many of the deployed SIP servers use UDP? In my understanding, more and more implementations were switching to TCP because SIP messages were hitting up against the 1500 byte MTU limit for UDP. Maybe the wireless guys are using UDP? I never really considered using the UDP implementation myself just because I didn't see the point. I guess the point would be better performance, but the added complication doesn't seem worth it. I've even heard talk of excluding UDP altogether if we were to write SIP over again. I bring this up because the double CRLF keep alive for TCP with SIP outbound is a really trivial addition. If almost everyone's using TCP, then your reasoning above for STUN control breaks down. -Adam ------=_Part_42754_20711238.1181332622062 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/8/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
To take this a step further, I think sip-outbound is the primary
benefactor of stun-control, not ICE.

Agreed.

The big pain point today are these awful keepalives we need to
constantly be sending for sip-outbound. WHen UDP is used, its every 20
or 30 seconds. That represents a huge load on the servers even when its
STUN (though much better than REGISTER like what SBCs use today). With
stun control, we could control this so that SIP servers would see
reduction in stun volume by one or even two orders of magnitude. That is
a real big bang for the buck. Also benefits wireless applications.

Any idea how many of the deployed SIP servers use UDP?  In my understanding, more and more implementations were switching to TCP because SIP messages were hitting up against the 1500 byte MTU limit for UDP.  Maybe the wireless guys are using UDP?  I never really considered using the UDP implementation myself just because I didn't see the point.  I guess the point would be better performance, but the added complication doesn't seem worth it. 

I've even heard talk of excluding UDP altogether if we were to write SIP over again.  I bring this up because the double CRLF keep alive for TCP with SIP outbound is a really trivial addition.  If almost everyone's using TCP, then your reasoning above for STUN control breaks down.

-Adam


------=_Part_42754_20711238.1181332622062-- --===============1556499936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1556499936==-- From behave-bounces@ietf.org Fri Jun 08 16:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkwB-0001ku-6H; Fri, 08 Jun 2007 16:19:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwkw9-0001kp-WA for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 16:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwkw9-0001kh-Mn for behave@ietf.org; Fri, 08 Jun 2007 16:19:57 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwkw8-00089W-Cj for behave@ietf.org; Fri, 08 Jun 2007 16:19:57 -0400 Received: by wx-out-0506.google.com with SMTP id t5so777193wxc for ; Fri, 08 Jun 2007 13:19:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Uw7H2ihuwTAACht2vCUbmZliXxe87gnLof+DfduMVCEN8m4YOsxpTC71X5sEiEsL0h+SQLvHfMo/oO54kpO/s3Qzi04VIgaHEVHNrnstbqhNDb+wXiTVqkLpuz9rbA2QIE5JCswqYXp/TcyJ2EkUFuysPhfiIimam4SyWmZjQM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ZM668T2APNLjEM5k+bmOrBYpgXK8DMvYVFvTJl237vWdVF+lqrMp7IaO4s0uNOOlUcOGkLytb7KCMdpQhSljMigUe3O4j00lzhcLhgYIxhc6tVMXyGTgCdWGmlSCfoLdLQsup3+w+tHCt1YppGLs4+cryHWHpjcqGecnT0/5aiY= Received: by 10.90.63.16 with SMTP id l16mr3472295aga.1181333995552; Fri, 08 Jun 2007 13:19:55 -0700 (PDT) Received: by 10.90.56.13 with HTTP; Fri, 8 Jun 2007 13:19:55 -0700 (PDT) Message-ID: Date: Fri, 8 Jun 2007 16:19:55 -0400 From: "Adam Fisk" To: behave@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [BEHAVE] connect request in draft-ietf-behave-turn-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1386059243==" Errors-To: behave-bounces@ietf.org --===============1386059243== Content-Type: multipart/alternative; boundary="----=_Part_42974_6141704.1181333995423" ------=_Part_42974_6141704.1181333995423 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm unclear why the TURN server is expected to attempt to open up a TCP connection to the remote host when it receives a connect request. If the TURN server is able to successfully make the connection to the remote host, why in the world would the client be using TURN in the first place? Why wouldn't the client just bypass the costly relay and make the direct connection? Is this for highly controlled networks where clients may only have outgoing access to the TURN server and not the remote host? I can understand the allocating of permissions in response to a connect request. As such, it would make more sense to me that the connect request be a "permission request" where no outgoing connection attempt is made. As far as I can tell, that outgoing connection attempt is a waste of precious server resources in the vast majority of cases because it will almost always fail. Am I missing something? Thanks. -Adam Fisk ------=_Part_42974_6141704.1181333995423 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm unclear why the TURN server is expected to attempt to open up a TCP connection to the remote host when it receives a connect request.  If the TURN server is able to successfully make the connection to the remote host, why in the world would the client be using TURN in the first place?  Why wouldn't the client just bypass the costly relay and make the direct connection?  Is this for highly controlled networks where clients may only have outgoing access to the TURN server and not the remote host?

I can understand the allocating of permissions in response to a connect request.  As such, it would make more sense to me that the connect request be a "permission request" where no outgoing connection attempt is made.  As far as I can tell, that outgoing connection attempt is a waste of precious server resources in the vast majority of cases because it will almost always fail.

Am I missing something?

Thanks.

-Adam Fisk
------=_Part_42974_6141704.1181333995423-- --===============1386059243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1386059243==-- From behave-bounces@ietf.org Fri Jun 08 16:48:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlNL-0003Ej-Ho; Fri, 08 Jun 2007 16:48:03 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwlNK-0003Ec-F4 for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 16:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwlNK-0003EP-5Q for behave@ietf.org; Fri, 08 Jun 2007 16:48:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwlNH-0008K7-SN for behave@ietf.org; Fri, 08 Jun 2007 16:48:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 08 Jun 2007 13:47:59 -0700 X-IronPort-AV: i="4.16,401,1175497200"; d="scan'208"; a="4625319:sNHT20844732" 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 l58Klxbu016016; Fri, 8 Jun 2007 13:47:59 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l58KlwtV008193; Fri, 8 Jun 2007 20:47:58 GMT From: "Dan Wing" To: "'Adam Fisk'" , "'Jonathan Rosenberg'" Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Fri, 8 Jun 2007 13:47:58 -0700 Message-ID: <025901c7aa0e$4c428380$1ea36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceqCiuGHGbhoq5lSkGS8IOfrjvcuQAAazsw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1576; t=1181335679; x=1182199679; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20BoF=20request=3A=20STUN=20Control=20Usage |Sender:=20; bh=QZIn6Z7Id1JadFrwZ29FDcowl4aHnmsiKUwUH30tirM=; b=EiKpRKlsUCwMxK2Ak5oJjIHaoJEwhqze9vUU1cmTzjUNp8qwijRo/SBemqZbj9gOWOxQJJxl itdmSvauD/ZLmthp+gYm9lDes/U1+CUjNqo6LeKUcMXyM18cVrDMlV6p; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: behave@ietf.org, Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > Any idea how many of the deployed SIP servers use UDP? There is some information from SIPit 20, https://www.sipit.net/SIPit20_Summary but of course that lacks market share information. > In my > understanding, more and more implementations were switching > to TCP because SIP messages were hitting up against the 1500 > byte MTU limit for UDP. Based on that SIPit information, 71% claimed to work fine with fragmented UDP packets and 10% didn't know. I guess the remainder (19%) know they break with fragmented UDP. I dunno what those implementations plan to do -- maybe choose a better IP stack? Additionally, under high traffic rates from a single IP address (such as a bunch of SIP clients behind a single NAPT), draft-heffner-frag-harmful describes problems with reassembly which I doubt are sufficiently appreciated by those running SIP over UDP. > Maybe the wireless guys are using UDP? I never really considered > using the UDP implementation myself just because I didn't see the > point. I guess the point would be better performance, but the added > complication doesn't seem worth it. > > I've even heard talk of excluding UDP altogether if we were > to write SIP over again. I bring this up because the double > CRLF keep alive for TCP with SIP outbound is a really trivial > addition. If almost everyone's using TCP, then your > reasoning above for STUN control breaks down. To summarize, I believe you're saying if UDP keepalives create too much load on your server or network, just use TCP. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 17:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlcl-00022w-GB; Fri, 08 Jun 2007 17:03:59 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwlcj-0001z9-SP for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 17:03:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlcj-0001z1-Is for behave@ietf.org; Fri, 08 Jun 2007 17:03:57 -0400 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwlci-0006Dr-93 for behave@ietf.org; Fri, 08 Jun 2007 17:03:57 -0400 Received: by wx-out-0506.google.com with SMTP id t5so785614wxc for ; Fri, 08 Jun 2007 14:03:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QeFlmcwbgEj86SWwwLNpWKFAdT6UGBmFOHekjPrXAIBQOMMjVOBhkFj3AOLI+ERSKQG4qyTNoWduoz7MvlGPsXaqr5s2QtKKY8RU+8gZZmOWIMp2htAi5jxFBcLkEnWWS/ffw/ppPRfXTpYrVFBeI56sKryjiL/V6dZYChTa27Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZQTmmd7xZWDpxbeoS44WvIZzwUaEURypMZnBRCzpGZ+Bl5R7F7x3md38LNyQ3EjpJ64zNdHgkdNNUrbAwwovwUs2OQpBqoTHBpCb/O/bJlLRE/vGomDilSDCn6u7UlKvME6zaloHRcTwi2jEBao/5rUoKSpgzM50EmxTcz4XrxQ= Received: by 10.90.90.16 with SMTP id n16mr3466752agb.1181336635097; Fri, 08 Jun 2007 14:03:55 -0700 (PDT) Received: by 10.90.56.13 with HTTP; Fri, 8 Jun 2007 14:03:55 -0700 (PDT) Message-ID: Date: Fri, 8 Jun 2007 17:03:55 -0400 From: "Adam Fisk" To: "Dan Wing" Subject: Re: [BEHAVE] BoF request: STUN Control Usage In-Reply-To: <025901c7aa0e$4c428380$1ea36b80@amer.cisco.com> MIME-Version: 1.0 References: <025901c7aa0e$4c428380$1ea36b80@amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: behave@ietf.org, Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1727544411==" Errors-To: behave-bounces@ietf.org --===============1727544411== Content-Type: multipart/alternative; boundary="----=_Part_43322_9103357.1181336635050" ------=_Part_43322_9103357.1181336635050 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/8/07, Dan Wing wrote: > > > Any idea how many of the deployed SIP servers use UDP? > > There is some information from SIPit 20, > https://www.sipit.net/SIPit20_Summary but of course that > lacks market share information. Interesting. So it looks like most implementations support both. I wonder how many of those actually use the UDP implementation over the TCP in terms of what clients actually connect with. I know I wouldn't, but I wonder. > Additionally, under high traffic rates from a single IP > address (such as a bunch of SIP clients behind a single NAPT), > draft-heffner-frag-harmful describes problems with reassembly > which I doubt are sufficiently appreciated by those running > SIP over UDP. I would think there would be many issues along these lines. It has to be one of the thorniest parts of any implementation in any case. > To summarize, I believe you're saying if UDP keepalives create > too much load on your server or network, just use TCP. Basically. Put a slightly different way, if no one's using UDP in practice anyway, then the TCP keep alive mechanism doesn't seem too onerous. There unfortunately seems to be little way to get a solid answer to that question, though, so I'm not sure where to go with it. Thanks. -Adam ------=_Part_43322_9103357.1181336635050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/8/07, Dan Wing <dwing@cisco.com> wrote:
> Any idea how many of the deployed SIP servers use UDP?

There is some information from SIPit 20,
https://www.sipit.net/SIPit20_Summary but of course that
lacks market share information.

Interesting.  So it looks like most implementations support both.  I wonder how many of those actually use the UDP implementation over the TCP in terms of what clients actually connect with.  I know I wouldn't, but I wonder.


Additionally, under high traffic rates from a single IP
address (such as a bunch of SIP clients behind a single NAPT),
draft-heffner-frag-harmful describes problems with reassembly
which I doubt are sufficiently appreciated by those running
SIP over UDP.

I would think there would be many issues along these lines.  It has to be one of the thorniest parts of any implementation in any case.


To summarize, I believe you're saying if UDP keepalives create
too much load on your server or network, just use TCP.

Basically.  Put a slightly different way, if no one's using UDP in practice anyway, then the TCP keep alive mechanism doesn't seem too onerous.  There unfortunately seems to be little way to get a solid answer to that question, though, so I'm not sure where to go with it.

Thanks.

-Adam


------=_Part_43322_9103357.1181336635050-- --===============1727544411== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1727544411==-- From behave-bounces@ietf.org Fri Jun 08 18:18:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwmnI-0003wf-F2; Fri, 08 Jun 2007 18:18:56 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwmnG-0003wS-Gd for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 18:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwmnG-0003w5-6i for behave@ietf.org; Fri, 08 Jun 2007 18:18:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwmmw-0003GR-0E for behave@ietf.org; Fri, 08 Jun 2007 18:18:35 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Jun 2007 15:18:33 -0700 X-IronPort-AV: i="4.16,401,1175497200"; d="scan'208"; a="161459778:sNHT48790710" 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 l58MIXLi017941; Fri, 8 Jun 2007 15:18:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l58MITtZ019737; Fri, 8 Jun 2007 22:18:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 15:18:31 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 15:18:30 -0700 Message-ID: <4669D5B6.7090709@cisco.com> Date: Fri, 08 Jun 2007 18:18:30 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Behave WG , Gonzalo Camarillo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 22:18:31.0046 (UTC) FILETIME=[F2119A60:01C7AA1A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3293; t=1181341113; x=1182205113; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20STUN=20feature=20for=20v4/v6=20transition |Sender:=20; bh=auKYp4pERKO+Hcsixhw5Pc8L6EwL/fQNzaa1haO8SDI=; b=HBC9KlBvTiu+TH1M+TDORNcFc7lZ3Djn9LWvPJlcQyfw5Qd4LacGL6uSSU9LxXOLuBzY5LhB Bu8BCnYpdSoF0nfbCggKAZBlZfBX8kVh05RPpwVFFU9gSuXzCgDprf8n; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [BEHAVE] STUN feature for v4/v6 transition X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org STUNbis has some mysterious text in it, dealing with v4/v6 and mapped addreses. It says this: It is possible for an IPv4 host to receive a MAPPED-ADDRESS containing an IPv6 address, or for an IPv6 host to receive a MAPPED- ADDRESS containing an IPv4 address. Clients MUST be prepared for this case. The spec is entirely unclear on what it means to be prepared for this. Indeed, when would this even happen? Here is the deployment model envisioned for this case: Please view in a fixed-width font such as Courier. +-----------+ | v4 | | STUN | | Server | | | +-----------+ +----------+ | | | v4-only | | host | v4 Internet | | +----------+ +-----------------+ | v4 to v6 NAT | +-----------------+ v6 local net +----------+ | | | v6-only | | host | | | +----------+ There is a v6-only host behind a NAT. This NAT is v6 on the private side and v4 on the public side. It does twice-NAT; for packets outbound from the private to public sides, it converts the v6 source IP to a v4 IP/port from a pool on the v4 public Internet side. It also converts the destination addresses from v6 to v4; the v6 address would need to be a v4-encapsulated v6 address or something for which there is a static mapping. So the v6 only host sends a STUN request to a v6 destination. This goes through the NAT, which allocates the host a v4 binding and translates the destination to the corresponding v4 destination - the STUN server. The STUN server returns the v4 mapped address in the MAPPED-ADDRESS. Now, this v6 host is going to get a STUN response that has a MAPPED-ADDRESS that is v4. If we consider the usage of STUN binding indication without ICE as a simple example, the v6-only host would include the v4 address into the SDP of an INVITE, and send it out. If the target host is v4-only as in the picture, the media will work from the v4-only host to the v6 host. The story is similar with ICE and it works quite well in fact. None of this requires the v6-only host to have a v4 address, it just needs to 'be prepared' to use a v4 address in this way. Now, there are lots of other things you need to assume are working in this story for the whole thing to come together, but this is the envisioned use case. So, are people interested in this use case? Is this a valid transition scenario? If not, we can remove this vague text from 3489bis. If so, we need to add some clarity about what it means. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 21:07:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwpPy-0005BY-9N; Fri, 08 Jun 2007 21:07:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwpPx-0005BN-S8 for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 21:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwpPx-0005BF-IV; Fri, 08 Jun 2007 21:07:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwpPw-0006PB-9t; Fri, 08 Jun 2007 21:07:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 08 Jun 2007 18:07:00 -0700 X-IronPort-AV: i="4.16,401,1175497200"; d="scan'208"; a="378217902:sNHT49794066" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5916xlH011008; Fri, 8 Jun 2007 18:06:59 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5916v20022668; Sat, 9 Jun 2007 01:06:58 GMT From: "Dan Wing" To: "'Leymann, Nicolai'" , , , , , Subject: RE: [BEHAVE] AW: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt Date: Fri, 8 Jun 2007 18:06:57 -0700 Message-ID: <034f01c7aa32$7afe95a0$1ea36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F302AF4E46@S4DE9JSAAIG.ost.t-com.de> Thread-Index: AceYzOw7nFJSOn2lSRa/y6yfCmDnbgOM7s8gAB425SAAMQ20uQBbMscwACH1yUA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3648; t=1181351219; x=1182215219; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20AW=3A=20[magma]=20RE=3A=20[MBONED]=20FW=3A =20WGLC=3Adraft-ietf-behave-multicast-06.txt |Sender:=20; bh=ZJJr5BECVMrwwEOpbP8wMOzi+pCX2YAJlNSUp2PRhjE=; b=b9fyO/BD3r5NCjwTYazX+z44Rfk+03/RfEPl5u8gcgHEUN+CfTJtm3tUB+eLXCdKBUnln+ID zWdN7kNmODmFVQdO6Wc/ewqww2I4lUwB2h1oIeYFeukGMGLoPZ0kxRzi; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > Hi Everybody, > > > Hi all. > > If you have two sources from two different inside interfaces > > sending multicast data to the outside interface and both > > sources use the same multicast address (G1) then outside > > routers, using for example PIM-SM, will consider that there > > is only one multicast channel and will send all the traffic. > > Also hosts receiving all the traffic need to separate it. > > Right. This is from my point of view not the solution you want. > The reason for SSM is to have different senders (source) using > the same group and to be able to route based on (S,G) information. > > > One solution is to reserve an IP address range inside SSM range > > ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change, > > not only the source address of the sender, but also the multicast > > address of the sender to be unique in this range. In this way > > outside routers ( and receivers ) will consider traffic as coming > > from different channels (IP public ,G2) and ( IP public, G3) with > > G2 and G3 inside the said range. > > The main problem is how to signal either the (S,G) channel or the > multicast group if this information is changed by a NAPT device. > > E.g. in a typical IPTV scenario the signalling of the group or > channel information is done out-bband using servers providing > information about the IPTV channels. Clients are receiving this > information from the server (http/xml) to join the appropriate > IPTV channels. > > If a sender (S1) sends multicast traffic to a group (G1) the receiver > joins (S1,G1) due to the information it got from the server. If the > NAPT device changes this to (S2,G1) or (S1,G2) the receiver is not > going to receive any traffic. > > I'm not sure if this problem can be solved without making to many > assumptions about the applications deploying IP-Multicast. I agree, and I'll leave such a recommendation out of the -07 revision of this document. I expect to have -07 ready next week. -d > Regards > > Nic > > ________________________________ > > De: Manfredi, Albert E [mailto:albert.e.manfredi@boeing.com] > Enviado el: mar 05/06/2007 16:02 > Para: behave@ietf.org; mboned@ietf.org; magma@ietf.org > Asunto: [magma] RE: [MBONED] FW: WGLC: > draft-ietf-behave-multicast-06.txt > > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Monday, June 04, 2007 7:38 PM > > To: mboned@ietf.org; magma@ietf.org > > Cc: 'Behave WG' > > Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt > > > > The BEHAVE working group concluded its WGLC of > > draft-ietf-behave-multicast-06 with no comments received. I > > would like > > MBONED and MAGMA to please take a look at this draft prior to > > its submission > > to IESG. > > > > Please send replies to behave@ietf.org. Thanks! > > > http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas > t-06.txt: > > What if the NAPT or NAT device just passed IGMP queries and > reports > through, changing only the source address of the reports, and > let the > multicast router outside do all the hard work? I'm wondering > whether the > IGMP aggregation function is mandatory in NAT/NATP. > > Bert > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 08 21:09:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwpSg-0005GN-JE; Fri, 08 Jun 2007 21:09:50 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HwpSf-0005GF-8D for behave-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 21:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwpSe-0005G7-Ur for behave@ietf.org; Fri, 08 Jun 2007 21:09:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwpSc-0007Ob-B6 for behave@ietf.org; Fri, 08 Jun 2007 21:09:48 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2007 18:09:45 -0700 X-IronPort-AV: i="4.16,401,1175497200"; d="scan'208"; a="161855012:sNHT58360545" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5919jGA013616; Fri, 8 Jun 2007 18:09:45 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5919itV017999; Sat, 9 Jun 2007 01:09:45 GMT From: "Dan Wing" To: "'Bharat Joshi'" Subject: RE: [BEHAVE] Re: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt Date: Fri, 8 Jun 2007 18:09:44 -0700 Message-ID: <035001c7aa32$ddf7cdc0$1ea36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1181107502.3830.90.camel@magadha> Thread-Index: Acen/Q9ipbd9stoeRcqRCADjJvfrtAAVgS+w DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9201; t=1181351385; x=1182215385; 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]=20Re=3A=20[MBONED]=20FW=3A=20WGLC=3A=20draft -ietf-behave-multicast-06.txt |Sender:=20; bh=b+W+ByBcvArYnWMcQAiTip8d7eey40o5tSR/Ols/xbo=; b=cN7S2lGVzu8SeUoJGsfm2NX/4ijSQBz3rq6q3sQy/YHpM6+cq9SiOEIJUgPMKRqTJ0cg2xbq /LESB42wHnCIV2ML+dUje+hXQ9FyBs7ygVDyQ7FTrgIjWYPPhyQ71jqLK8ZIUrFy6bbC3EAR67 bEsPqSoUdDpuT6MxcNHM1XQKs=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Toerless Eckert , behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > > * In section 4.2, why is it that a NAPT device > > > implementing this draft > > > needs to aggregate IGMP message only for IGMPv3? I think if it is > > > implementing 'RFC4605', it will anyway do the aggregation. > > > > It's my understanding that things will work -- somewhat > > sub-optimally -- > > with IGMPv1 or IGMPv2 without the NAT doing aggregation of IGMPv1/v2 > > messages and blindly just forwarding them upstream. > > > > If my understanding is incorrect, please let me know (it > > may well be; multicast is not my expertise). (By the way, to address that weakness, I have recently added Toerless Eckert as a co-author.) > Things should work even if we do not aggregate IGMPv3 message > also. Why we do aggregation is that we do not want to send multiple > messages upstream? Because upstream would forward multicast data > traffic if he knows that there is atleast one host interested in > a group. But if blind forwarding is done, with no aggregation, the upstream router will see arrival and leave packets arrive in the wrong order. We adjusted the text in -07 and I think it should be clearer now. It now reads: *** 4.3. IGMPv3 NAPT When a IGMPv3 proxying device receives an IGMP membership on an inside interface, it creates its own IGMP proxying membership state and its own IGMP forwarding table. It then creates an independent IGMP membership report on its outside interface reporting the multicast groups/channels -- but there is no direct relationship or "relaying" of IGMP membership reports or queries across the interfaces. The NAPT device will subsequently receive a multicast data packet on the outside ('public') interface and forward the multicast packet to inside ('internal') interfaces based on its IGMP forwarding table. By performing NAPT on IGMPv3 membership reports, the membership reports appear to originate from a single IGMPv3 reporter instead of different reporters. Because IGMPv3 has different types of membership reports differentiating between status (IS_INCLUDE, IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if a NAPT were to interleave reports from two or more reporters (joining and leaving the same groups) the NAPT would create a sequence of packets that are incompliant with an IGMPv3 reporter [RFC3376]. For this reason, REQ-4: If a NAPT supports IGMPv3, the NAPT MUST implement [RFC4605]. Such compliance causes the NAPT to aggregate the IGMPv3 membership reports and report only the aggregated information upstream. Failure to do this aggregation will cause undesired temporary blackholing of multicast traffic. For example, consider two hosts behind the same NAPT. If one host is joining a session at the same time another is leaving the session, and the NAPT were to merely relay the join and leave upstream, the session will be terminated, and the join and leave announcements would not comply with section 5 of [RFC3376]. *** > Aggregating IGMPv3 is a little more complex than V1 and V2. Yes, agreed. > I just wanted to point out that if an NAPT is implementing > RFC 4605 than it should be aggregating all versions of IGMP. > > So why do you want to > specifically mention the case for IGMPv3? But IGMPv1 and IGMPv2 predated RFC4605, and there have been and still are IGMPv1/v2-aware NATs that should "work" (but perhaps not optimally) without implementing RFC4605. I have removed the old REQ-1 in -07 for this reason (and based on some other feedback). In -07, I adjusted the requirements so that RFC4605 is only a requirement for NATs that support IGMPv3, and not a requirement for NATs that only do IGMPv1 or only IGMPv2. I expect to publish -07 in the middle of next week. > > > * In case of IGMPv3, why is it that aggregation is a MUST? > > > Also I think > > > when one of the hosts behind the NAPT generates LEAVE and another > > > generates JOIN simultaneously, the session will be UP till the > > > group-timer timesout and as JOIN is also received, it > > > will be updated > > > and so session will always be UP. Am I mixing the session > > > created in > > > NAPT with the state in upstream router? > > > > Slightly after that requirement in the document is this explanation: > > > > > > > > Failure to do this aggregation will cause undesired > > > temporary blackholing of multicast traffic. For example, > > > consider two hosts behind the same NAPT. If one host is > > > joining a session at the same time another is leaving the > > > session, and the NAPT merely relays the join and leave > > > upstream, the session will be terminated and the join and > > > leave announcements do not comply with section 5 of > > target="RFC3376">. > > > > > Thats exactly why I raised this question. How does this creates an > issue? This can happen in a host as well. Lets say application just > started and send a join and immediately after this because of some > failure, it goes down and send a leave. I am not sure what the problem > is. If it's a single host, it brought this behavior on itself. I believe this is identical to the behavior without a NAPT. > > > * In section 4.4, though complete Multicast Range is > > > 224/4 but out of > > > this range 232/8 is used for Source Specific Multicast or > > > Single-Source > > > Multicast. So is the following statement syntactically correct > > > > > > "Any-sosurce multicast (ASM) uses the IP addresses in the > > > 224.0.0.0 - > > > 239.255.255.255 range [IANA-ALLOC]." > > > > > > What I meant is that it looks to be incorrect to call this > > > range as ASM range. > > > > You're right. I pulled this from the Terminology section > > of RFC3569 > > ("An Overview of Source-Specific Multicast (SSM)"). I have adjusted > > my document so that it describes the ASM space as 224/8 through > > 231/8 and 233/8 through 239/8 (with a hole for 224/8). > > > > I think this may not be completely correct. This is because 239/8 is > available to administrator and they can use this for SSM > within a given domain. Is there some other way a NAT could make this determination? Perhaps, (see below) the NAT could determine the host is doing ASM because the host is sending to the same multicast group; that may well be far easier anyway... Although, with SSM, RTP fixed this problem (in draft-ietf-avt-rtcpssm, where it suggests identifying hosts using information other than the source transport address), thus with SSM traffic the NAT doesn't need to keep the UDP binding open for 60 minutes. It's ASM RTP applications which don't follow draft-ietf-avt-rtcpssm's suggestions for identifying hosts that are the reason that requirement exists in draft-ietf-behave-multicast. > > > * In section 4.4, > > > > > > a. This UDP mapping SHOULD be destroyed when the host leaves > > > that host group. > > > > > > How do we find out that host has left the group? Please correct > > > me if I am wrong. We are talking about a host behind the NAPT > > > device generating Multicast data traffic [UDP traffic]. A > > > multicast host does not need to join the multicast group [By > > > sending an IGMP join message] to send multicast traffic to that > > > group. So how does NAPT finds out when it can destroy this > > > mapping and so this mapping will have to timeout before it can > > > be removed. > > > > Ah, good point which I hadn't considered. I have removed that > > requirement. Sorry -- while making this edit, I remembered the genesis of the problem for RTP. The problem only occurs when a host is receiving the same multicast stream that it is also sending to. Specifically, when the host is receiving an RTP stream it will occasionally send RTCP reports. With ASM, these RTCP reports are sent to the multicast address (so that all participants can see all other participants RTCP reports and adjust some RTP behaviors according to the size of the group). If a host is only sending packets into an ASM stream (such as sending RTP packets) and isn't also listening to the stream, we don't have this problem with RTP. So we don't need to require a NAT to have this 60-minute timeout. So, I'm going to leave this requirement in -07, and have tried to adjust the discussion/justification to describe why this requirement is only necessary when a host is both a member of the multicast group _and_ sends traffic to that same multicast group. Related, I have previously received pushback for this 60-minute timer being a MUST, because the difficulties this causes RTP aren't sufficiently significant to flat-out break interoperability if a NAT didn't implement that MUST. I tend to agree with this comment, but would sure like to hear from others before I adjust it. -d > Ok. So now how do you remove that mapping? I guess only once > that times out. Right? _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jun 09 03:52:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwvju-0002Bk-IQ; Sat, 09 Jun 2007 03:52:02 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hwvjt-0002Bf-6z for behave-confirm+ok@megatron.ietf.org; Sat, 09 Jun 2007 03:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwvjp-00024d-Gs for behave@ietf.org; Sat, 09 Jun 2007 03:51:57 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwvjo-00033l-Le for behave@ietf.org; Sat, 09 Jun 2007 03:51:57 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9712B21190; Sat, 9 Jun 2007 09:51:55 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-25-466a5c1bcacf Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 65F6220489; Sat, 9 Jun 2007 09:51:55 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 09:51:54 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 09:51:53 +0200 Received: from [131.160.126.1] (rvi2-126-gw.lmf.ericsson.se [131.160.126.1]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 197FF2358; Sat, 9 Jun 2007 10:51:49 +0300 (EEST) Message-ID: <466A5C12.4070402@ericsson.com> Date: Sat, 09 Jun 2007 10:51:46 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jonathan Rosenberg References: <4669D5B6.7090709@cisco.com> In-Reply-To: <4669D5B6.7090709@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2007 07:51:53.0581 (UTC) FILETIME=[0B93D9D0:01C7AA6B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Behave WG Subject: [BEHAVE] Re: STUN feature for v4/v6 transition X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I think we should remove the text from the STUNbis spec. We should talk about these issues in draft-ietf-behave-turn-ipv6-02.txt. We have had some good discussions on this draft on this list and I will be putting together a new revision reflecting our conclusions as soon as I can (right now, I am on the road). Regarding the use case you provide in your email, note that the NAT-PT spec is being moved to Historic. Therefore, you are right to question if that is a valid transition scenario: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-historic-00.txt In any case, I agree with you that the STUNbis spec is not the place to deal with those issues. If we wanted to cover the few legacy networks using NAT-PT for v4/v6 transition directly in the STUNbis spec, we could say that a client receiving an address whose address family it understands, it can use it. If the address family, and thus the address itself, is not understood, it is discarded. Cheers, Gonzalo Jonathan Rosenberg wrote: > STUNbis has some mysterious text in it, dealing with v4/v6 and mapped > addreses. It says this: > > It is possible for an IPv4 host to receive a MAPPED-ADDRESS > containing an IPv6 address, or for an IPv6 host to receive a MAPPED- > ADDRESS containing an IPv4 address. Clients MUST be prepared for > this case. > > > The spec is entirely unclear on what it means to be prepared for this. > Indeed, when would this even happen? Here is the deployment model > envisioned for this case: > > > Please view in a fixed-width font such as > Courier. > > > > +-----------+ > | v4 | > | STUN | > | Server | > | | > +-----------+ +----------+ > | | > | v4-only | > | host | > v4 Internet | | > +----------+ > > > > > > > > +-----------------+ > | v4 to v6 NAT | > +-----------------+ > > > v6 local net > > > +----------+ > | | > | v6-only | > | host | > | | > +----------+ > > > > There is a v6-only host behind a NAT. This NAT is v6 on the private side > and v4 on the public side. It does twice-NAT; for packets outbound from > the private to public sides, it converts the v6 source IP to a v4 > IP/port from a pool on the v4 public Internet side. It also converts the > destination addresses from v6 to v4; the v6 address would need to be a > v4-encapsulated v6 address or something for which there is a static > mapping. > > So the v6 only host sends a STUN request to a v6 destination. This goes > through the NAT, which allocates the host a v4 binding and translates > the destination to the corresponding v4 destination - the STUN server. > The STUN server returns the v4 mapped address in the MAPPED-ADDRESS. > > Now, this v6 host is going to get a STUN response that has a > MAPPED-ADDRESS that is v4. If we consider the usage of STUN binding > indication without ICE as a simple example, the v6-only host would > include the v4 address into the SDP of an INVITE, and send it out. If > the target host is v4-only as in the picture, the media will work from > the v4-only host to the v6 host. > > The story is similar with ICE and it works quite well in fact. > > None of this requires the v6-only host to have a v4 address, it just > needs to 'be prepared' to use a v4 address in this way. Now, there are > lots of other things you need to assume are working in this story for > the whole thing to come together, but this is the envisioned use case. > > So, are people interested in this use case? Is this a valid transition > scenario? If not, we can remove this vague text from 3489bis. If so, we > need to add some clarity about what it means. > > Thanks, > Jonathan R. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sun Jun 10 10:20:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxOHa-0000DL-Qv; Sun, 10 Jun 2007 10:20:42 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HxOHZ-0000DD-8v for behave-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 10:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxOHY-0000D5-UT for behave@ietf.org; Sun, 10 Jun 2007 10:20:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxOHX-0000D2-AH for behave@ietf.org; Sun, 10 Jun 2007 10:20:40 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2007 07:20:39 -0700 X-IronPort-AV: i="4.16,405,1175497200"; d="scan'208"; a="492276194:sNHT52849456" 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 l5AEKcrc005466; Sun, 10 Jun 2007 07:20:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5AEKctV015352; Sun, 10 Jun 2007 14:20:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 07:20:38 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 10 Jun 2007 07:20:38 -0700 Message-ID: <466C08B5.8010002@cisco.com> Date: Sun, 10 Jun 2007 10:20:37 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo References: <4669D5B6.7090709@cisco.com> <466A5C12.4070402@ericsson.com> In-Reply-To: <466A5C12.4070402@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2007 14:20:38.0396 (UTC) FILETIME=[84A9EBC0:01C7AB6A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4920; t=1181485238; x=1182349238; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20STUN=20feature=20for=20v4/v6=20transition |Sender:=20; bh=1ULLbc4vG2m8rzB4Vp4sQQvi9EQC9cJaP537SXIWT08=; b=clBv5FkFE17OUFcuh+m8LBMKe6IuIm0jxH6zzoPCUYBSoOq2znBdg7SGNUFeY9pOJebCpOPv +miP85D8YLm9eQaCvJu7djrd1FJaKeGFCF4NwTFFKRryRyRB/aV0gPf6; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Behave WG Subject: [BEHAVE] Re: STUN feature for v4/v6 transition X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org OK, so suggest that perhaps the text say that handling of a mapped-address using a different address family is outside the scope of this specification, and clients that don't know what to do with it, should treat it as an error. -Jonathan R. Gonzalo Camarillo wrote: > Hi, > > I think we should remove the text from the STUNbis spec. We should talk > about these issues in draft-ietf-behave-turn-ipv6-02.txt. We have had > some good discussions on this draft on this list and I will be putting > together a new revision reflecting our conclusions as soon as I can > (right now, I am on the road). > > Regarding the use case you provide in your email, note that the NAT-PT > spec is being moved to Historic. Therefore, you are right to question if > that is a valid transition scenario: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-historic-00.txt > > > In any case, I agree with you that the STUNbis spec is not the place to > deal with those issues. If we wanted to cover the few legacy networks > using NAT-PT for v4/v6 transition directly in the STUNbis spec, we could > say that a client receiving an address whose address family it > understands, it can use it. If the address family, and thus the address > itself, is not understood, it is discarded. > > Cheers, > > Gonzalo > > > > Jonathan Rosenberg wrote: > >> STUNbis has some mysterious text in it, dealing with v4/v6 and mapped >> addreses. It says this: >> >> It is possible for an IPv4 host to receive a MAPPED-ADDRESS >> containing an IPv6 address, or for an IPv6 host to receive a MAPPED- >> ADDRESS containing an IPv4 address. Clients MUST be prepared for >> this case. >> >> >> The spec is entirely unclear on what it means to be prepared for this. >> Indeed, when would this even happen? Here is the deployment model >> envisioned for this case: >> >> >> Please view in a fixed-width font such as >> Courier. >> >> >> >> +-----------+ >> | v4 | >> | STUN | >> | Server | >> | | >> +-----------+ +----------+ >> | | >> | v4-only | >> | host | >> v4 Internet | | >> +----------+ >> >> >> >> >> >> >> >> +-----------------+ >> | v4 to v6 NAT | >> +-----------------+ >> >> >> v6 local net >> >> >> +----------+ >> | | >> | v6-only | >> | host | >> | | >> +----------+ >> >> >> >> There is a v6-only host behind a NAT. This NAT is v6 on the private >> side and v4 on the public side. It does twice-NAT; for packets >> outbound from the private to public sides, it converts the v6 source >> IP to a v4 IP/port from a pool on the v4 public Internet side. It also >> converts the destination addresses from v6 to v4; the v6 address would >> need to be a v4-encapsulated v6 address or something for which there >> is a static mapping. >> >> So the v6 only host sends a STUN request to a v6 destination. This >> goes through the NAT, which allocates the host a v4 binding and >> translates the destination to the corresponding v4 destination - the >> STUN server. The STUN server returns the v4 mapped address in the >> MAPPED-ADDRESS. >> >> Now, this v6 host is going to get a STUN response that has a >> MAPPED-ADDRESS that is v4. If we consider the usage of STUN binding >> indication without ICE as a simple example, the v6-only host would >> include the v4 address into the SDP of an INVITE, and send it out. If >> the target host is v4-only as in the picture, the media will work from >> the v4-only host to the v6 host. >> >> The story is similar with ICE and it works quite well in fact. >> >> None of this requires the v6-only host to have a v4 address, it just >> needs to 'be prepared' to use a v4 address in this way. Now, there are >> lots of other things you need to assume are working in this story for >> the whole thing to come together, but this is the envisioned use case. >> >> So, are people interested in this use case? Is this a valid transition >> scenario? If not, we can remove this vague text from 3489bis. If so, >> we need to add some clarity about what it means. >> >> Thanks, >> Jonathan R. > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 02:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdia-0003kJ-Cc; Mon, 11 Jun 2007 02:49:36 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HxdiZ-0003cL-1h for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 02:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxdiV-0003Xh-Kt for behave@ietf.org; Mon, 11 Jun 2007 02:49:31 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxdiU-0001TG-6h for behave@ietf.org; Mon, 11 Jun 2007 02:49:31 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5B6nFDq019485; Mon, 11 Jun 2007 09:49:25 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:49:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:49:17 +0300 Received: from esdhcp041245.research.nokia.com ([172.21.41.245]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:49:16 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] BoF request: STUN Control Usage Date: Mon, 11 Jun 2007 09:49:53 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706110949.53897.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jun 2007 06:49:16.0833 (UTC) FILETIME=[A1351910:01C7ABF4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 08 June 2007 21:14:34 ext David Barrett wrote: > Again, just to push back on this a bit, how "huge" is a huge load? In my > experience the keepalive traffic is the best kind: negligible, totally > predictable, and scales linearly with userbase. Handling keep-alives may well be totally neglectible on a modern and=20 well-implemented SIP server. And it is of course of neglectible CPU cost to= a=20 client. *But* it is a HUGE battery W-h sink for mobile devices that have to wake-up= =20 their radio every 30 seconds to send something. VoIP is not going to fly if= =20 battery life is 5 times less than circuit-switched... (...) > Personally, I would *much* rather that we just spend that same energy > getting BEHAVE deployed faster, or getting SIP/ICE/STUN used more widely > (starting with just quantifying how widely in fact they are being used). > Otherwise I fear we'd just create a document describing a neat protocol > that in theory does great things but in practice has limited (or unknown) > utility. STUN control puts no extra requirement to the server side, and is entirely= =20 optional on the client side, so I would not see it as a problem if you thin= k=20 you do not need it. =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 02:56:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdp9-00061J-Nv; Mon, 11 Jun 2007 02:56:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hxdp8-00061E-Bq for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 02:56:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdp8-000615-2F for behave@ietf.org; Mon, 11 Jun 2007 02:56:22 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxdp6-0002m9-6k for behave@ietf.org; Mon, 11 Jun 2007 02:56:22 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5B6uG4h012676; Mon, 11 Jun 2007 09:56:17 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:56:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:56:09 +0300 Received: from esdhcp041245.research.nokia.com ([172.21.41.245]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 09:56:08 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] connect request in draft-ietf-behave-turn-03.txt Date: Mon, 11 Jun 2007 09:56:46 +0300 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706110956.46198.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jun 2007 06:56:08.0797 (UTC) FILETIME=[96C1D0D0:01C7ABF5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Friday 08 June 2007 23:19:55 ext Adam Fisk wrote: > I'm unclear why the TURN server is expected to attempt to open up a TCP > connection to the remote host when it receives a connect request. If the > TURN server is able to successfully make the connection to the remote hos= t, > why in the world would the client be using TURN in the first place? The other side could be using TURN too. If TURN servers were not capable of= =20 actively connecting, there'd be a dead-lock. > Why wouldn't the client just bypass the costly relay and make the direct > connection? If the either side does not implement ICE-TCP, it is typically not possible= to=20 negociate this properly; TURN becomes the only catch-all connectivity=20 solution. This is particularly true when you act as the offerer, know that active=20 connections to you might not work, and have no idea what the answerer=20 situation is. Or then we need to specify that the answerer must not use TURN when the=20 offerer does (or more generally when the offerer can be connected to). But then... > Is this for highly controlled networks where clients may only > have outgoing access to the TURN server and not the remote host? =2E..that would still be a problem. =2D-=20 R=C3=A9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 03:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdur-0007GL-0i; Mon, 11 Jun 2007 03:02:17 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hxdup-0007GG-Da for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 03:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdup-0007G8-2J for behave@ietf.org; Mon, 11 Jun 2007 03:02:15 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxdun-0003nx-Km for behave@ietf.org; Mon, 11 Jun 2007 03:02:15 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5B71j5c023353; Mon, 11 Jun 2007 10:02:09 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 10:01:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 10:01:52 +0300 Received: from esdhcp041245.research.nokia.com ([172.21.41.245]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 10:01:52 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: Nokia TP-SP-SWD To: behave@ietf.org Subject: Re: [BEHAVE] STUN feature for v4/v6 transition Date: Mon, 11 Jun 2007 10:02:29 +0300 User-Agent: KMail/1.9.6 References: <4669D5B6.7090709@cisco.com> In-Reply-To: <4669D5B6.7090709@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200706111002.29572.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 11 Jun 2007 07:01:52.0438 (UTC) FILETIME=[63954560:01C7ABF6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Gonzalo Camarillo X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Saturday 09 June 2007 01:18:30 ext Jonathan Rosenberg wrote: > STUNbis has some mysterious text in it, dealing with v4/v6 and mapped > addreses. It says this: > > It is possible for an IPv4 host to receive a MAPPED-ADDRESS > containing an IPv6 address, or for an IPv6 host to receive a MAPPED- > ADDRESS containing an IPv4 address. Clients MUST be prepared for > this case. > > > The spec is entirely unclear on what it means to be prepared for this. > Indeed, when would this even happen? My main concern with this text is that it breaks terribly whenever the serv= er=20 sends a redirect to another server, as the client has no idea how to send=20 traffic to a server that has a different address family than the one it is= =20 using. That being said, while v6/v6 NATs are not supposed to be used (so that IPv6= =20 binding discovery should not be ever needed, though keep-alives might well= =20 be), there are v6-to-v4 NATs. I just do not know if we need to care about=20 them, since I assume they are pretty scarce. There might also be v4-to-v6=20 NATs later on to connect legacy devices, but I guess they won't handle IPv6= =20 addresses from STUN properly anyway. Therefore, I am overall fine with suppressing the sentence. Regards, =2D-=20 R=E9mi Denis-Courmont _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 05:40:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgNm-000441-6q; Mon, 11 Jun 2007 05:40:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HxgNk-00042W-Sd for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 05:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxgNk-0003zi-GE for behave@ietf.org; Mon, 11 Jun 2007 05:40:16 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxgLA-0002J3-UB for behave@ietf.org; Mon, 11 Jun 2007 05:37:38 -0400 Received: from lappy ([67.169.180.240]) by quinthar.com for ; Mon, 11 Jun 2007 02:37:32 -0700 From: "David Barrett" To: =?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?= , Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Mon, 11 Jun 2007 02:37:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200706110949.53897.remi.denis-courmont@nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acer9KwJASbL6emsTqSCtnY5F/UR7QAEeIVw X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Message-Id: Cc: Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com] > Subject: Re: [BEHAVE] BoF request: STUN Control Usage >=20 > Handling keep-alives may well be totally neglectible on a modern and > well-implemented SIP server. And it is of course of neglectible CPU = cost > to a client. I'm glad you agree that for non-mobile applications, keepalives are negligible for clients and servers alike. Is there anyone else who = thinks keepalive traffic presents real-world CPU or bandwidth problems for non-mobile applications (and can show some kind of reality-based math to back up the assertion), or can we lay the matter to rest? > STUN control puts no extra requirement to the server side, and is = entirely > optional on the client side, so I would not see it as a problem if you > think you do not need it. The problem is its existence takes energy away from other incomplete, higher-priority projects. Even worse, merely discussing another = reinvention of STUN adds further delays to BEHAVE and SIP/ICE/STUN adoption as = everyone who might have considered it thinks "Whelp, I'll just do my own thing = and wait another year or so until they figure out what I'm supposed to do." To repeat, I'd love it to exist and be widely deployed. But until this solution is deployed in a standard form with >90% coverage of all the world's NAT's, it offers near zero value because every P2P application = would still need to build the exact same technology as today to accommodate unknown timeouts. Furthermore, to obtain >90% penetration of NATs will take *a lot* of = time and hard work. This is a project that won't see the light of day for a decade, at best. I'd prefer those years of diligent, hard work were = instead focused on just getting BEHAVE more widely deployed in its current form, = or even just focused on increasing SIP/ICE/STUN's overall adoption. -david _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 10:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxkhw-0003sD-5d; Mon, 11 Jun 2007 10:17:24 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hxkhr-0003p7-OV for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 10:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxkhr-0003oz-Ev for behave@ietf.org; Mon, 11 Jun 2007 10:17:19 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxkhp-0002ii-R7 for behave@ietf.org; Mon, 11 Jun 2007 10:17:19 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BB2A1208F8 for ; Mon, 11 Jun 2007 16:17:16 +0200 (CEST) X-AuditID: c1b4fb3c-a94ecbb0000073d5-ee-466d596c77b0 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AC61B208FF for ; Mon, 11 Jun 2007 16:17:16 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 16:17:16 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 16:17:16 +0200 Message-ID: <466D596C.6090306@ericsson.com> Date: Mon, 11 Jun 2007 16:17:16 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: behave@ietf.org Subject: Re: [BEHAVE] BoF request: STUN Control Usage References: <04c301c7a8cf$17e7eac0$c2f0200a@amer.cisco.com> In-Reply-To: <04c301c7a8cf$17e7eac0$c2f0200a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2007 14:17:16.0287 (UTC) FILETIME=[369C48F0:01C7AC33] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I have decided to not approve this BOF for Chicago. The main reason is that we should focus on getting the all the proposals currently in the pipe out of it. BEHAVE for example has a number of things, including STUN-BIS and TURN that we should get out in the near future. Having this BOF will be a distraction for this. I also expect MIDCOM and NSIS to have made progress towards publishing their solutions as RFCs. I would recommend the proponents, interested and people seeing issue to keep a dialog and continue to prepare for a future BOF. I think the next IETF meeting in Vancouver in the fall will be a more suitable time for discussing the general topic on NAT control and any further work in IETF on this topic. Regards Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 16:07:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqAg-0000Bs-2O; Mon, 11 Jun 2007 16:07:26 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HxqAf-0000Bn-8L for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:07:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqAe-0000Bd-Sw for behave@ietf.org; Mon, 11 Jun 2007 16:07:24 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxqAd-0006tt-Ai for behave@ietf.org; Mon, 11 Jun 2007 16:07:24 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5BK6uaZ009074; Mon, 11 Jun 2007 23:07:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 23:07:17 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 23:07:17 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2007 23:07:16 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NAT control and STUN - some thoughts Thread-Index: Acer9KwJASbL6emsTqSCtnY5F/UR7QAEeIVwABXLwKA= References: <200706110949.53897.remi.denis-courmont@nokia.com> From: To: , X-OriginalArrivalTime: 11 Jun 2007 20:07:17.0051 (UTC) FILETIME=[1C0A90B0:01C7AC64] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [BEHAVE] NAT control and STUN - some thoughts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, Even if the BoF for IETF 69 was not approved, I think it's useful to continue the discussion. Here are some thoughts I have about NAT/FW control and STUN usage for it. - As methodologies such as ICE and real-world applications such as Skype or GoogleTalk have shown, NAT/FW traversal *can* be done relatively effectively in general. For fixed devices and networks even the constant keepalives to maintain state in the middleboxes is not an issue. However, for wireless devices and networks the situation is quite different. Keepalives, especially for UDP, consume the battery relatively fast, as the radio transmitter/receiver needs to wake up periodically to send otherwise unneeded packets. In practice any application that needs to maintain a UDP mapping/pinhole, could not be sustained for more than a few hours (as opposite to few days) in any wide area cellular network, such as WCDMA/HSDPA or WiMAX (802.16e). TCP already works much better, so its use e.g. for SIP is highly recommended, but it still has the same problem in general. - Most difficult are applications, where always-on connectivity needs to be maintained. Examples include VoIP/IM/Presence. SIP, XMPP, Skype all share the same problem, although typically SIP would be worst as UDP is often used as the transport. Also, any protocols relying on UDP encapsulation and maintaining always-on/long sessions, have the same issues. For instance IPSec VPNs, Mobile IP, Teredo, ... - The solution space is very challenging. The impact of IPv6 is still very minor, also it has the same basic problem with firewalls. Of course, the NAT/FW devices in cellular access could be configured with longer timeouts (another useful idea in addition to TCP usage), but there is no trivial way for applications to detect this. - Something like STUN NAT control would be tempting for wireless devices to implement, *if* some of the NAT box vendors would support it too, so there would be at least some deployment potential. The biggest use cases for UDP control would be in my opinion: - 1. Controlling the mappings for protocols using UDP encapsulation such as IPSec, Mobile IP and Teredo. If the "path to the public address space" could be controlled, these kind of protocols could allow quite powerful connectivity with just a single UDP mapping. - 2. ICE optimization. Gathering candidates before sending offer or answer can cause some delay. With STUN control, at least one candidate could be maintained quite cheaply just waiting for a call to be made/received, so that the offer/answer could be generated immediately. - I'm not so sure on SIP outbound. TCP should be used for that. More later on. - Another useful thing would be something that would work for TCP, since that would help apps like SIP, e-mail etc. I'm not sure how feasible STUN control would be. I guess in principle the tagging method in -02 draft would work, but also the TCP peer (server) would need to run a STUN server in the same port as the app protocol and mux the two. Current deployment of STUN would not help in bootsraping this. (Actually SIP outbound had the muxing stuff for TCP in an earlier version. I was against if for different reasons. I don't want to go and open that anymore, but certainly the debate can now be seen in a bit differet light too.) - The biggest problem I see (in addition to usual issues with deployment, topologies etc.) is that of a non-STUN capable firewall on the path. This could not be detected. So, it would be hard to know when you really have the path under control and can reduce the keepalive messages. Personally I think we should continue the work in this area, I don't see the problem going away for the next few years, actually it will probably hit the headlines sooner or later as wireless broadband starts to become available and people notice that they still can't really run their Skype, Gizmo or Gtalk clients in the way they would want. Some say that the ISPs should just go for v6, but I'm doubtful. Regards, Markus =20 _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 16:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqJp-00044h-9y; Mon, 11 Jun 2007 16:16:53 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HxqJn-00044O-Mz for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqJn-00044G-Db for behave@ietf.org; Mon, 11 Jun 2007 16:16:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxqJl-0008Pc-UV for behave@ietf.org; Mon, 11 Jun 2007 16:16:51 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5BKGasd032753; Mon, 11 Jun 2007 23:16:47 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 23:16:42 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 23:16:42 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Mon, 11 Jun 2007 23:16:42 +0300 Message-ID: In-Reply-To: <466D596C.6090306@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] BoF request: STUN Control Usage Thread-Index: AcesM0aaW4gEaQBoQOqbAUrdTvQ8swAMR7sg References: <04c301c7a8cf$17e7eac0$c2f0200a@amer.cisco.com> <466D596C.6090306@ericsson.com> From: To: , X-OriginalArrivalTime: 11 Jun 2007 20:16:42.0816 (UTC) FILETIME=[6D437400:01C7AC65] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi Magnus, I can understand your reasoning. I just hope that we don't end up in a situation where there is the formally agreed solution X that no-one implements and whose only function would be to block the development of solutions Y and Z, which perhaps could have more implementation interest.=20 Instead of a BoF, I think it would still be useful to have slot in BEHAVE to discuss the proposal. A bar BoF should definitely be held, at least ;) Markus =20 >-----Original Message----- >From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 >Sent: 11 June, 2007 17:17 >To: behave@ietf.org >Subject: Re: [BEHAVE] BoF request: STUN Control Usage > >Hi, > >I have decided to not approve this BOF for Chicago. The main=20 >reason is that we should focus on getting the all the=20 >proposals currently in the pipe out of it. BEHAVE for example=20 >has a number of things, including STUN-BIS and TURN that we=20 >should get out in the near future. Having this BOF will be a=20 >distraction for this. I also expect MIDCOM and NSIS to have=20 >made progress towards publishing their solutions as RFCs. > >I would recommend the proponents, interested and people seeing=20 >issue to keep a dialog and continue to prepare for a future=20 >BOF. I think the next IETF meeting in Vancouver in the fall=20 >will be a more suitable time for discussing the general topic=20 >on NAT control and any further work in IETF on this topic. > >Regards > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM/M >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www1.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 16:59:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqzN-0007vm-UH; Mon, 11 Jun 2007 16:59:49 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HxqzM-0007vQ-DQ for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 16:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxqzM-0007vH-3l for behave@ietf.org; Mon, 11 Jun 2007 16:59:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxqzK-0001l8-Rt for behave@ietf.org; Mon, 11 Jun 2007 16:59:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Jun 2007 16:59:47 -0400 X-IronPort-AV: i="4.16,409,1175486400"; d="scan'208"; a="123326923:sNHT45396460" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5BKxkW5025331; Mon, 11 Jun 2007 16:59:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5BKxkBe019065; Mon, 11 Jun 2007 20:59:46 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 16:59:40 -0400 Received: from 10.86.115.74 ([10.86.115.74]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Jun 2007 20:59:40 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 11 Jun 2007 16:59:39 -0400 Subject: Re: [BEHAVE] NAT control and STUN - some thoughts From: Melinda Shore To: , , Dan Wing Message-ID: Thread-Topic: [BEHAVE] NAT control and STUN - some thoughts Thread-Index: Acer9KwJASbL6emsTqSCtnY5F/UR7QAEeIVwABXLwKAAA2vrOg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jun 2007 20:59:40.0543 (UTC) FILETIME=[6DB560F0:01C7AC6B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=981; t=1181595586; x=1182459586; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mshore@cisco.com; z=From:=20Melinda=20Shore=20 |Subject:=20Re=3A=20[BEHAVE]=20NAT=20control=20and=20STUN=20-=20some=20th oughts |Sender:=20 |To:=20, =20, =20Dan=20Wing=20; bh=1neJC6jyv+1wHXu6hue3sNgBdaUqGGEGNzXe3KK5Lu8=; b=MAmMXFD9KS7aQ1em+yt86FDGJeanTHgbSTSMwynaqka2T2vgS1i7OZae9pWGo6ldyswk3cF8 hGqGFnxcdZDZi1nKJDEgOneRkoak9zll1oTWaW2JWHfWPA3Lp9QdLO4b; Authentication-Results: rtp-dkim-2; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 6/11/07 4:07 PM, "Markus.Isomaki@nokia.com" wrote: > - As methodologies such as ICE and real-world applications such as Skype > or GoogleTalk have shown, NAT/FW traversal *can* be done relatively > effectively in general. One quick point - Skype in particular works by bypassing firewall access control decisions, and that isn't a good thing. This is one area in which the distinction between firewall and NAT matters a great deal. Firewalls enforce access policies, occasionally very complex access policies. NATs, to the extent they deal with policy at all, deal with address policy, and in the pure NAT case you're not dealing with authorization questions as you are with firewalls. Anything that goes through a firewall without giving the firewall adequate opportunity to say "yes" or "no" is probably not okay, and consequently it's important to draw distinctions between firewalls and NATs in this context. Melinda _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 17:08:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr83-0003ow-SS; Mon, 11 Jun 2007 17:08:47 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hxr82-0003nA-PL for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 17:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxr82-0003mT-FI for behave@ietf.org; Mon, 11 Jun 2007 17:08:46 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxr80-0003iR-3m for behave@ietf.org; Mon, 11 Jun 2007 17:08:46 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] ([IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l5BL5qZg079617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2007 23:05:53 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <025901c7aa0e$4c428380$1ea36b80@amer.cisco.com> References: <025901c7aa0e$4c428380$1ea36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06A7DDF2-FE57-4BE7-B982-731036F40D36@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [BEHAVE] BoF request: STUN Control Usage Date: Mon, 11 Jun 2007 23:07:11 +0200 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-0.9 required=3.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: behave@ietf.org, Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On 8-jun-2007, at 22:47, Dan Wing wrote: > Based on that SIPit information, 71% claimed to work fine > with fragmented UDP packets and 10% didn't know. I guess the > remainder (19%) know they break with fragmented UDP. I dunno > what those implementations plan to do -- maybe choose a > better IP stack? A problem with fragmentation is that the port numbers are only in the first fragment so fragmented packets often have trouble getting by firewalls. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 11 22:20:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxvzp-0002C0-3U; Mon, 11 Jun 2007 22:20:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hxvzn-0002Bv-9J for behave-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 22:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxvzm-0002Bn-Vt for behave@ietf.org; Mon, 11 Jun 2007 22:20:34 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxvzk-0005xm-My for behave@ietf.org; Mon, 11 Jun 2007 22:20:34 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2007 19:20:33 -0700 X-IronPort-AV: i="4.16,409,1175497200"; d="scan'208"; a="378571730:sNHT42518692" 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 l5C2KTUi011638; Mon, 11 Jun 2007 19:20:29 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5C2KStV022627; Tue, 12 Jun 2007 02:20:28 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" Subject: RE: [BEHAVE] BoF request: STUN Control Usage Date: Mon, 11 Jun 2007 19:20:27 -0700 Message-ID: <049701c7ac98$3ea53790$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcesbIiBhanCqu6YT+O5bs39nggABwAK3zTA In-Reply-To: <06A7DDF2-FE57-4BE7-B982-731036F40D36@muada.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=765; t=1181614829; x=1182478829; 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]=20BoF=20request=3A=20STUN=20Control=20Usage |Sender:=20; bh=lgq4HnrDe0qJ6KBxUkagYT11QIu/6voLwiuoZ01a3Fc=; b=EjcipnawJ6fOcsDjoJ1Lzxzr9f4I/nx2yKyWnzE6MF8mR1oVdEHKDi4YvZSU4HGYbsa5CYfw 8sKVm7DK8HgqaUq5Mw+slqZuicUbyJwb72dncxItg65niUCktGZ7/9Vo; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: behave@ietf.org, Erkki.Koivusalo@nokia.com X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > Based on that SIPit information, 71% claimed to work fine > > with fragmented UDP packets and 10% didn't know. I guess the > > remainder (19%) know they break with fragmented UDP. I dunno > > what those implementations plan to do -- maybe choose a > > better IP stack? > > > > A problem with fragmentation is that the port numbers are > only in the > first fragment so fragmented packets often have trouble getting by > firewalls. > > Good point, thanks for delurking briefly. NATs have a similar difficultly. I don't know if the ~20% of stacks reported at SIPit that are known to break with fragmented UDP were considering a firewall (or NAT) between their stack and their next-hop SIP device, though. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jun 12 04:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1JW-0001P9-F9; Tue, 12 Jun 2007 04:01:18 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hy1JT-0001Oh-9B for behave-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 04:01:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1JS-0001OL-8z; Tue, 12 Jun 2007 04:01:14 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1JQ-0007HB-It; Tue, 12 Jun 2007 04:01:14 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C80i90007537; Tue, 12 Jun 2007 11:01:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:01:08 +0300 Received: from [172.21.35.94] (esdhcp03594.research.nokia.com [172.21.35.94]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C816jm023828; Tue, 12 Jun 2007 11:01:07 +0300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Date: Tue, 12 Jun 2007 11:01:04 +0300 To: tsvwg WG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 08:01:08.0418 (UTC) FILETIME=[D5868220:01C7ACC7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Behave WG , IETF AVT WG , mmusic Subject: [BEHAVE] draft-ietf-tsvwg-udp-guidelines-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg WG List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1546204042==" Errors-To: behave-bounces@ietf.org --===============1546204042== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--682882164; protocol="application/pkcs7-signature" --Apple-Mail-9--682882164 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Gorry and me just submitted a new -01 version of the "UDP Usage Guidelines for Application Designers" draft that TSVWG is putting together as a BCP. Compared to the -00 version, this draft adds a new Section 3.5 that gives middlebox traversal guidelines. (I'm cross-posting to AVT, MMUSIC and BEHAVE, because this addition was triggered by the recent discussion around draft-marjou-behave-app- rtp-keepalive. Please discuss draft-ietf-tsvwg-udp-guidelines on the TSVWG list; I'm setting the reply-to accordingly.) We'd be interested in comments, both from TSV folks but especially from RAI people, who might not have had this on their radar. Lars --Apple-Mail-9--682882164 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MTIwODAxMDRaMCMGCSqGSIb3DQEJBDEWBBTioSuoUwcZjUaQ E3XWTcgn3290IzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAyElFq8OXQqqtH/+fJytFT+6ri6pRz9Ze1P+nXrBA2Qhk6TZ8QvLN TJC21TB4NrgZ696G002aUbwLNB0/6J/pGmOtGdWANUyNU5hn/kbs3a5JfDUMLDAZsDm/EZ5QiaE5 eQs+u0qI1GeHWzJuEmgdnx8RVP8Pup/sqMkyX+2QIS4ZCpZRFlAIEpGwZhswpcA5CO9Ag0hENMg7 kZp2sGkZD5zLzNBCd2MnmklRuSsn2D7c1wOcUdffSJ1p8Gy7jVk7ZxtYcGm5m8wLJpQSDBpxC1zI kJyhXvgedxXFpZU+yfYjtxCsQLmG0bpF+uPVLYGtnHWIUSzD8zQu2QiHYW4geAAAAAAAAA== --Apple-Mail-9--682882164-- --===============1546204042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --===============1546204042==-- From behave-bounces@ietf.org Tue Jun 12 04:33:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1oG-0002u3-0j; Tue, 12 Jun 2007 04:33:04 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hy1oE-0002tW-8M for behave-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 04:33:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy1oD-0002pX-Fw for behave@ietf.org; Tue, 12 Jun 2007 04:33:01 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy1nu-0007H0-Q4 for behave@ietf.org; Tue, 12 Jun 2007 04:33:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5C8WVNV028855; Tue, 12 Jun 2007 11:32:39 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:32:12 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:32:12 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BEHAVE] NAT control and STUN - some thoughts Date: Tue, 12 Jun 2007 11:32:12 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] NAT control and STUN - some thoughts Thread-Index: Acer9KwJASbL6emsTqSCtnY5F/UR7QAEeIVwABXLwKAAA2vrOgAX5aSw References: From: To: , , X-OriginalArrivalTime: 12 Jun 2007 08:32:12.0796 (UTC) FILETIME=[2CC803C0:01C7ACCC] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, Yes, understood and agreed. For a client vendor/implemeter it's an interesting dilemma whether to support something like HTTP/TLS "tunneling". On one hand it would make your client work in more environments (users would typically see this as a good thing), while on the other hand you are giving tools to break network policies (enterprise/network admins see this as a bad thing). Markus =20 >-----Original Message----- >From: ext Melinda Shore [mailto:mshore@cisco.com]=20 >Sent: 12 June, 2007 00:00 >To: Isomaki Markus (Nokia-SIR/Espoo); behave@ietf.org; Dan Wing >Subject: Re: [BEHAVE] NAT control and STUN - some thoughts > >On 6/11/07 4:07 PM, "Markus.Isomaki@nokia.com"=20 > >wrote: >> - As methodologies such as ICE and real-world applications such as=20 >> Skype or GoogleTalk have shown, NAT/FW traversal *can* be done=20 >> relatively effectively in general. > >One quick point - Skype in particular works by bypassing=20 >firewall access control decisions, and that isn't a good=20 >thing. This is one area in which the distinction between=20 >firewall and NAT matters a great deal. Firewalls enforce=20 >access policies, occasionally very complex access policies. =20 >NATs, to the extent they deal with policy at all, deal with=20 >address policy, and in the pure NAT case you're not dealing=20 >with authorization questions as you are with firewalls. > >Anything that goes through a firewall without giving the=20 >firewall adequate opportunity to say "yes" or "no" is probably=20 >not okay, and consequently it's important to draw distinctions=20 >between firewalls and NATs in this context. > >Melinda >=20 > _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 14 05:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylzY-0005Kf-A4; Thu, 14 Jun 2007 05:51:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1HylzX-0005KV-ID for behave-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:51:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylzX-0005KM-6E for behave@ietf.org; Thu, 14 Jun 2007 05:51:47 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylzV-0002aZ-CK for behave@ietf.org; Thu, 14 Jun 2007 05:51:47 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DC88420A89; Thu, 14 Jun 2007 11:51:44 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-c7-46710fb0c9dd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C77DE20A09; Thu, 14 Jun 2007 11:51:44 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:51:44 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:51:43 +0200 Message-ID: <46710FA6.40407@ericsson.com> Date: Thu, 14 Jun 2007 11:51:34 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Subject: Re: [BEHAVE] BoF request: STUN Control Usage References: <04c301c7a8cf$17e7eac0$c2f0200a@amer.cisco.com> <466D596C.6090306@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2007 09:51:43.0971 (UTC) FILETIME=[9D730B30:01C7AE69] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Markus.Isomaki@nokia.com skrev: > Hi Magnus, > > I can understand your reasoning. I just hope that we don't end up in a > situation where there is the formally agreed solution X that no-one > implements and whose only function would be to block the development of > solutions Y and Z, which perhaps could have more implementation > interest. This is clearly one of the topics that a future BOF to some degree will need to deal with. There are already developed solutions, and the question that any proponent needs to answer is why they aren't working. I think STUN control have some appealing arguments, but I don't think this is the end of the discussion. > > Instead of a BoF, I think it would still be useful to have slot in > BEHAVE to discuss the proposal. A bar BoF should definitely be held, at > least ;) > No, not a slot in BEHAVE. As I said, lets focus BEHAVE on the WG's current issues. We also have requested a new mailing list to move the STUN control discussion too. It will be announced as soon it is working. A Bar BOF is fine and in fact encouraged. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 14 14:26:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu23-0006Ms-6Q; Thu, 14 Jun 2007 14:26:55 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hyu21-0006Mk-Kj for behave-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 14:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyu21-0006Mc-B9; Thu, 14 Jun 2007 14:26:53 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyu21-0003t1-0o; Thu, 14 Jun 2007 14:26:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 14 Jun 2007 11:26:52 -0700 X-IronPort-AV: i="4.16,421,1175497200"; d="scan'208"; a="162578647:sNHT42311988" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5EIQq4o030252; Thu, 14 Jun 2007 11:26:52 -0700 Received: from dwingwxp (dhcp-128-107-163-66.cisco.com [128.107.163.66]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5EIQpaI011492; Thu, 14 Jun 2007 18:26:51 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , Subject: announcing SAFE mailing list [was: RE: [BEHAVE] BoF request: STUN Control Usage] Date: Thu, 14 Jun 2007 11:26:52 -0700 Message-ID: <018201c7aeb1$947a0ea0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46710FA6.40407@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceuaaXPQ4y/HNUJRsam/N046TRQXwARsNtA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1105; t=1181845612; x=1182709612; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20announcing=20SAFE=20mailing=20list=20[was=3A=20RE=3A=20[BEHAV E]=20BoF=20request=3A=20STUN=20Control=20Usage] |Sender:=20; bh=CeeBE8JuZ9r7pEPXGxyk4vFVwrxm+q16HnuSFQSZWG4=; b=IuRgUrlEBbg9B+U0rf98vqIbBNvbtpOerraPk+Nvd4aWAtiPvKMVAAr/0m3U5WL5YmRlKp5J tjenasnBusfqi98O0vWZyIBfmvOXgIHaROo+kB41F/6wip9PCS2hwTRv; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: safe@ietf.org, behave@ietf.org X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Magnus Westerlund wrote: > Markus.Isomaki@nokia.com skrev: ... > > Instead of a BoF, I think it would still be useful to have slot in > > BEHAVE to discuss the proposal. A bar BoF should definitely be > > held, at least ;) > > No, not a slot in BEHAVE. As I said, lets focus BEHAVE on the WG's > current issues. We also have requested a new mailing list to move > the STUN control discussion too. It will be announced as soon it is > working. The new mailing list has been created, "Self-Address Fixing Evolution" (SAFE): Evolution of the protocol and procedures of RFC3489 and draft-ietf-behave-rfc3489bis, so that middleboxes can be discovered, queried, and controlled. Subscribe at: https://www1.ietf.org/mailman/listinfo/safe Please join the SAFE mailing list if you are interested in this topic. > A Bar BOF is fine and in fact encouraged. I'll schedule that in a few days on the SAFE mailing list. I am leaning towards Monday or Thursday for that, after dinner (Tuesday is the social and a SPIT bar BoF has been called for Wednesday). -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jun 16 13:28:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzc4k-0001ra-Ae; Sat, 16 Jun 2007 13:28:38 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1Hzc4j-0001rS-0O for behave-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 13:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzc4i-0001rK-N3 for behave@ietf.org; Sat, 16 Jun 2007 13:28:36 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzc4h-0003AK-Cr for behave@ietf.org; Sat, 16 Jun 2007 13:28:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2007 10:28:35 -0700 X-IronPort-AV: i="4.16,430,1175497200"; d="scan'208"; a="166525128:sNHT39267738" 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 l5GHSYVX004453 for ; Sat, 16 Jun 2007 10:28:34 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5GHSYtV021809 for ; Sat, 16 Jun 2007 17:28:34 GMT From: "Dan Wing" To: Date: Sat, 16 Jun 2007 10:28:33 -0700 Message-ID: <000001c7b03b$c4414780$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcewNyQt5Qd1Dm1QTIGt259hb7srOgABIq4g DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=758; t=1182014914; x=1182878914; 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:=20need=20more=20Nomcom=202007-8=20volunteers |Sender:=20; bh=CflvlKgMnh3Wg78Yynfv444GPTVgHA04HjwOGrcpdFw=; b=JUndhDYxi/bqlOGjlPZLekEfGEqZbcCyn6643w46MGlQJ499pzyCieEZ8+P/G6mi2JkQVWya pmSUPQpud8Zkj9v08bOFW8SVaCo4i0r+KERu9nVp18WduMlQu1105zcN; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [BEHAVE] need more Nomcom 2007-8 volunteers X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org If you're selected, it's typically only a few hours of effort. -d > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Saturday, June 16, 2007 9:55 AM > To: wgchairs@ietf.org; irsg@isi.edu; bofchairs@ietf.org > Subject: Request to forward the Nomcom 2007-8 Announcement to > lists youmanage > > Folks, > > We have around 50 volunteers so far for Nomcom 2007-8 voting member > selection. We need a lot more! Not everyone subscribes to the > IETF-Announce list. Could you please forward the announcement > https://datatracker.ietf.org/public/show_nomcom_message.cgi?id > =1234 to > WG, RG, BoF, Area lists that you manage? > > Thanks in advance. > > best regards, > Lakshminath _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jun 20 12:45:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13J3-0005bl-Px; Wed, 20 Jun 2007 12:45:21 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I13J2-0005bf-Bb for behave-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13J2-0005bX-2B for behave@ietf.org; Wed, 20 Jun 2007 12:45:20 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13J0-0004Os-N3 for behave@ietf.org; Wed, 20 Jun 2007 12:45:20 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2007 18:45:16 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KGjFuH017631 for ; Wed, 20 Jun 2007 18:45:15 +0200 Received: from dwingwxp ([10.32.240.194]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5KGjEDR009120 for ; Wed, 20 Jun 2007 16:45:15 GMT From: "Dan Wing" To: Date: Wed, 20 Jun 2007 09:45:13 -0700 Message-ID: <10a001c7b35a$60c54cc0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcezBVJHiVgVEndrSHSxZHYGNk9xCAAVQekw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2208; t=1182357916; x=1183221916; c=relaxed/simple; s=amsdkim1002; 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:=20FW=3A=20Nomcom=202007-8=3A=20Notes=20on=20Voting=20Member=20T ime=20Commitment |Sender:=20; bh=5fBZMLawljfHXbSZcFVqU5rB5ra0vzpBlycBsCDhrYE=; b=ih1qbV8hndTe7tK18YHSJlWetGL9dd/woOsQTxEvkreBsoPqgfLqVy21Ido3u9O2yfU0ALpB KvPZpF5LFv4x+E88E0SECne6CoEFAgs7bjA1cRd+SFeQ+kiNBufxl6pp; Authentication-Results: ams-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [BEHAVE] FW: Nomcom 2007-8: Notes on Voting Member Time Commitment X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Tuesday, June 19, 2007 11:35 PM > To: ietf-announce@ietf.org > Subject: Nomcom 2007-8: Notes on Voting Member Time Commitment > > Folks > > Some of you have asked for clarifications on the time commitments of > voting members. BCP 10 has the details of the process and > the role of > the voting and non-voting members. Here are some notes for > your quick > reference on how it might be in practice: > > If all goes well with the selection process, the members begin their > work at the Chicago IETF meeting. The plan is for the > members to attend > the Chicago and Vancouver IETF meetings to interview and/or gather > feedback and input from the community, including people in leadership > positions: WG and RG chairs, the IAOC, the IAB and the IESG. We can > address exceptional circumstances on a case-by-case basis, > but that is > the general expectation. > > The Nomcom will then spend about a month (4-5 weeks) self-organizing. > There will be 1-2 hrs per week of conference calls and BCP 10 as the > reading assignment. As with anything IETF, there will be some email > traffic too. > > Subsequent to that, the candidate selection phase begins which lasts > about 4 months. During that phase there is a good amount of reading: > especially candidate statements and community feedback. > There will also > be discussions and deliberations via 2 hrs per week of > conference calls > and email. That's under normal operating conditions. If there are > interim openings, there will be slightly additional work. > > We (the entire nomcom) can make efforts to distribute the work evenly > over that period of 5 months, so as to be as non-disruptive > to our day > jobs as possible. > > If you have any specific questions or requests for clarifications, > please do not hesitate to contact me. > > thanks, > Lakshminath > Nomcom 2007-8 Chair > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jun 21 15:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Sg4-0005FC-0h; Thu, 21 Jun 2007 15:50:48 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I1SfM-0003db-FA for behave-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 15:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SfL-0003d5-IZ; Thu, 21 Jun 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1SfL-0001aN-5i; Thu, 21 Jun 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E73FC26E91; Thu, 21 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I1SfK-0000tM-Ga; Thu, 21 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 21 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: behave@ietf.org Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-multicast-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Multicast Requirements for a Network Address (and port) Translator (NAT) Author(s) : T. Eckert, D. Wing Filename : draft-ietf-behave-multicast-07.txt Pages : 15 Date : 2007-6-21 This document specifies requirements for a Network Address (and port) Translator (NAT) that supports any source multicast or source specific IP multicast. A multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of multicast applications that are generally unaware of multicast NAT devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-behave-multicast-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-behave-multicast-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-21130235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-behave-multicast-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-behave-multicast-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-21130235.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Thu Jun 21 20:18:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Wr1-0002is-Gv; Thu, 21 Jun 2007 20:18:23 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I1Wr0-0002hv-VM for behave-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 20:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Wr0-0002hn-Lr; Thu, 21 Jun 2007 20:18:22 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Wqy-0007Wc-BD; Thu, 21 Jun 2007 20:18:22 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jun 2007 02:18:18 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFKyekaQ/uCKh2dsb2JhbACPJAIJDiw X-IronPort-AV: i="4.16,449,1175464800"; d="scan'208"; a="146221356:sNHT27371106" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5M0IH1E017789; Fri, 22 Jun 2007 02:18:17 +0200 Received: from dwingwxp (dhcp-128-107-163-120.cisco.com [128.107.163.120]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5M0IGTC015231; Fri, 22 Jun 2007 00:18:16 GMT From: "Dan Wing" To: , Date: Thu, 21 Jun 2007 17:18:15 -0700 Message-ID: <1d0c01c7b462$d4c148a0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace0YtOhtzS6gCiiQkmvBKD7ohFyDQ== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1084; t=1182471497; x=1183335497; c=relaxed/simple; s=amsdkim1002; 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:=20multicast=20senders=20behind=20an=20IGMP=20Proxy |Sender:=20; bh=fGYORB7HjjFpmFA1mBiqIg/J5hjoMC8dIDgHoyGLrJ0=; b=QDMCDUMh/imvQGd35y5o7NoOCSgnj0CoLo1IV0leddI1T9sm7tEUiCTURDobAVjy9aUzZLLS 8ox9mKJIGQ3gH3r1FY/wTY3o5ay+1IkUHv9M+ZNdWujvwjdD/6/iooCh; Authentication-Results: ams-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [BEHAVE] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org During WGLC, there was clear consensus from MAGMA and MBONED that supporting multicast senders behind the IGMP Proxy device was desirable. However, while wrapping up draft-ietf-behave-multicast-07, Toerless pointed out a problem with multicast senders behind an IGMP Proxy device (any IGMP Proxy device -- not just an IGMP Proxy in a NAT). The problem is that any multicast flows generated behind the IGMP proxy will be forwarded up the access link towards the Internet -- even for flows that you want to keep within your network. Concrete examples of generating multicast within a home network include: * sending audio to all of your IP-enabled speakers distributed throughout your house, * IP-enabled intercom system, * HD video to multiple telvision sets (kitchen and living room). In each case, you "could" do unicast, but especially for HD one might easily envision not having sufficient bandwidth or not wanting to waste the bandwidth (which might be used for other things). Does anyone have suggestions on how this might be resolved? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 22 01:05:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1bKW-0006Al-Iu; Fri, 22 Jun 2007 01:05:08 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I1bKV-00068k-8V for behave-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 01:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1bKU-00068c-SQ for behave@ietf.org; Fri, 22 Jun 2007 01:05:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1bKT-00071m-Jc for behave@ietf.org; Fri, 22 Jun 2007 01:05:06 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jun 2007 07:05:03 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAB/1ekaQ/uCKh2dsb2JhbACPJgIJDiw X-IronPort-AV: i="4.16,449,1175464800"; d="scan'208"; a="146228351:sNHT33993848" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5M552KO021846 for ; Fri, 22 Jun 2007 07:05:02 +0200 Received: from dwingwxp ([10.32.240.194]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5M54xTC020249 for ; Fri, 22 Jun 2007 05:05:01 GMT From: "Dan Wing" To: Date: Thu, 21 Jun 2007 22:04:58 -0700 Message-ID: <1daf01c7b48a$e41534b0$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace0iuFBXpgp1qXwQyGHSk7IlIIt7w== DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=315; t=1182488702; x=1183352702; c=relaxed/simple; s=amsdkim1002; 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:=20multicast-07 |Sender:=20; bh=+hDf1pxWFoqpdVKXzLgtO6sXWJOXLrvRBGAg0oUD7HI=; b=GqtfCz8xdrj+NkUntltvIcCYE0xiwRis3u04NNb3g3WpvfifuWpTPvyjpv94wcsIzReXtau1 CksvLFVNIOwfc6WKiyPJ3wODxERtGaXJ3bD3BM5WNLoumcbvxu+ysA1S; Authentication-Results: ams-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [BEHAVE] multicast-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org A day after submitting -07, I noticed there is some confusing text with IGMPv3 (REQ-7)'s ASM/SSM send/receive requirements and the transport protocol requirements (REQ-9/REQ-10). I will be clarifying this by moving some text around, so please don't waste your time with -07. -08 will be out shortly. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 22 06:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fy4-000276-5e; Fri, 22 Jun 2007 06:02:16 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I1fy2-00026r-Bg for behave-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 06:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1fxz-00026f-70; Fri, 22 Jun 2007 06:02:11 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1fxt-0003EY-UF; Fri, 22 Jun 2007 06:02:11 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK100GOV7UCUK@szxga03-in.huawei.com>; Fri, 22 Jun 2007 18:01:24 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK100CON7U9KB@szxga03-in.huawei.com>; Fri, 22 Jun 2007 18:01:24 +0800 (CST) Received: from prasant5129 ([10.18.23.95]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK100FRM7U4K2@szxml03-in.huawei.com>; Fri, 22 Jun 2007 18:01:21 +0800 (CST) Date: Fri, 22 Jun 2007 15:31:16 +0530 From: Prashant Jhingran In-reply-to: <1d0c01c7b462$d4c148a0$c2f0200a@amer.cisco.com> To: 'Dan Wing' , behave@ietf.org, magma@ietf.org Message-id: <000601c7b4b4$46c224f0$5f17120a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0YtOhtzS6gCiiQkmvBKD7ohFyDQAUEzsg X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [BEHAVE] RE: [magma] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prashantj@huawei.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Hi, I would like to suggest following methods to resolve this issue: - TTL scoping can be used to control the distribution of multicast traffic with the objective of easing stress on scarce resources viz. bandwidth. - Another way (and probably a preferred choice) would be to use administratively scoped IP multicast [rfc2365]. Moreover, these methods can (to a certain extent) help in achieving privacy. PS: "sending audio to all of your IP-enabled speakers distributed throughout your house" seems to be very ambitious usage of multicast :-) Regards, Prashant Jhingran Huawei Technologies +91-80-41117676 Ext -7175 +91-9448927814 "Sing, dance, serve, meditate and celebrate" - www.artofliving.org -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Friday, June 22, 2007 5:48 AM To: behave@ietf.org; magma@ietf.org Cc: Toerless Eckert Subject: [magma] multicast senders behind an IGMP Proxy During WGLC, there was clear consensus from MAGMA and MBONED that supporting multicast senders behind the IGMP Proxy device was desirable. However, while wrapping up draft-ietf-behave-multicast-07, Toerless pointed out a problem with multicast senders behind an IGMP Proxy device (any IGMP Proxy device -- not just an IGMP Proxy in a NAT). The problem is that any multicast flows generated behind the IGMP proxy will be forwarded up the access link towards the Internet -- even for flows that you want to keep within your network. Concrete examples of generating multicast within a home network include: * sending audio to all of your IP-enabled speakers distributed throughout your house, * IP-enabled intercom system, * HD video to multiple telvision sets (kitchen and living room). In each case, you "could" do unicast, but especially for HD one might easily envision not having sufficient bandwidth or not wanting to waste the bandwidth (which might be used for other things). Does anyone have suggestions on how this might be resolved? -d _______________________________________________ magma mailing list magma@ietf.org https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 22 08:02:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hqm-0003Fp-Ce; Fri, 22 Jun 2007 08:02:52 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I1hql-0003Ff-EB for behave-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 08:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1hql-0003FX-4h; Fri, 22 Jun 2007 08:02:51 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1hqh-0000La-SW; Fri, 22 Jun 2007 08:02:51 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.32975896; Fri, 22 Jun 2007 08:02:21 -0400 Message-ID: <467BBA4D.2080705@innovationslab.net> Date: Fri, 22 Jun 2007 08:02:21 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: prashantj@huawei.com References: <000601c7b4b4$46c224f0$5f17120a@china.huawei.com> In-Reply-To: <000601c7b4b4$46c224f0$5f17120a@china.huawei.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: magma@ietf.org, behave@ietf.org, 'Dan Wing' Subject: [BEHAVE] Re: [magma] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org In IPv6, the scoping can be accomplished simply with the existing scope bits without having to rely on the Hop Count. The home router simply acts as a scope border and does not forward traffic to the Internet. Regards, Brian Prashant Jhingran wrote: > Hi, > > I would like to suggest following methods to resolve this > issue: > > - TTL scoping can be used to control the distribution of > multicast traffic with the objective of easing stress on > scarce resources viz. bandwidth. > > - Another way (and probably a preferred choice) would be to > use administratively scoped IP multicast [rfc2365]. > > Moreover, these methods can (to a certain extent) help in > achieving privacy. > > PS: "sending audio to all of your IP-enabled speakers > distributed throughout your house" seems to be very > ambitious usage of multicast :-) > > Regards, > Prashant Jhingran > > Huawei Technologies > +91-80-41117676 Ext -7175 > +91-9448927814 > > "Sing, dance, serve, meditate and celebrate" > - www.artofliving.org > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 22, 2007 5:48 AM > To: behave@ietf.org; magma@ietf.org > Cc: Toerless Eckert > Subject: [magma] multicast senders behind an IGMP Proxy > > During WGLC, there was clear consensus from MAGMA and MBONED > that supporting > multicast senders behind the IGMP Proxy device was > desirable. However, > while wrapping up draft-ietf-behave-multicast-07, Toerless > pointed out a > problem with multicast senders behind an IGMP Proxy device > (any IGMP Proxy > device -- not just an IGMP Proxy in a NAT). > > The problem is that any multicast flows generated behind the > IGMP proxy will > be forwarded up the access link towards the Internet -- even > for flows that > you want to keep within your network. Concrete examples of > generating > multicast within a home network include: > > * sending audio to all of your IP-enabled speakers > distributed > throughout your house, > * IP-enabled intercom system, > * HD video to multiple telvision sets (kitchen and living > room). > > In each case, you "could" do unicast, but especially for HD > one might easily > envision not having sufficient bandwidth or not wanting to > waste the > bandwidth (which might be used for other things). > > Does anyone have suggestions on how this might be resolved? > > -d > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jun 22 08:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1i37-0003BS-Ci; Fri, 22 Jun 2007 08:15:37 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I1i36-0003BJ-Pk for behave-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 08:15:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1i36-0003BA-GB; Fri, 22 Jun 2007 08:15:36 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1i34-0004Tv-1n; Fri, 22 Jun 2007 08:15:36 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK100BGAE0IJV@szxga02-in.huawei.com>; Fri, 22 Jun 2007 20:14:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK10033HE0HNX@szxga02-in.huawei.com>; Fri, 22 Jun 2007 20:14:42 +0800 (CST) Received: from prasant5129 ([10.18.23.95]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK1009GJE0CCS@szxml04-in.huawei.com>; Fri, 22 Jun 2007 20:14:41 +0800 (CST) Date: Fri, 22 Jun 2007 17:44:36 +0530 From: Prashant Jhingran In-reply-to: <467BBA4D.2080705@innovationslab.net> To: 'Brian Haberman' Message-id: <000301c7b4c6$e71a8e30$5f17120a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0xUc7k8yv1RnaQUOQEMS0qQTImQAAOYYg X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: magma@ietf.org, behave@ietf.org, 'Dan Wing' Subject: [BEHAVE] RE: [magma] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prashantj@huawei.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org Oh yes, multicast link-local addressing scheme should be good enough to tackle this issue for IPv6. My suggestions were applicable for IPv4 alone. Regards, Prashant Jhingran Huawei Technologies +91-80-41117676 Ext -7175 +91-9448927814 "Sing, dance, serve, meditate and celebrate" - www.artofliving.org -----Original Message----- From: Brian Haberman [mailto:brian@innovationslab.net] Sent: Friday, June 22, 2007 5:32 PM To: prashantj@huawei.com Cc: 'Dan Wing'; behave@ietf.org; magma@ietf.org; 'Toerless Eckert' Subject: Re: [magma] multicast senders behind an IGMP Proxy In IPv6, the scoping can be accomplished simply with the existing scope bits without having to rely on the Hop Count. The home router simply acts as a scope border and does not forward traffic to the Internet. Regards, Brian Prashant Jhingran wrote: > Hi, > > I would like to suggest following methods to resolve this > issue: > > - TTL scoping can be used to control the distribution of > multicast traffic with the objective of easing stress on > scarce resources viz. bandwidth. > > - Another way (and probably a preferred choice) would be to > use administratively scoped IP multicast [rfc2365]. > > Moreover, these methods can (to a certain extent) help in > achieving privacy. > > PS: "sending audio to all of your IP-enabled speakers > distributed throughout your house" seems to be very > ambitious usage of multicast :-) > > Regards, > Prashant Jhingran > > Huawei Technologies > +91-80-41117676 Ext -7175 > +91-9448927814 > > "Sing, dance, serve, meditate and celebrate" > - www.artofliving.org > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 22, 2007 5:48 AM > To: behave@ietf.org; magma@ietf.org > Cc: Toerless Eckert > Subject: [magma] multicast senders behind an IGMP Proxy > > During WGLC, there was clear consensus from MAGMA and MBONED > that supporting > multicast senders behind the IGMP Proxy device was > desirable. However, > while wrapping up draft-ietf-behave-multicast-07, Toerless > pointed out a > problem with multicast senders behind an IGMP Proxy device > (any IGMP Proxy > device -- not just an IGMP Proxy in a NAT). > > The problem is that any multicast flows generated behind the > IGMP proxy will > be forwarded up the access link towards the Internet -- even > for flows that > you want to keep within your network. Concrete examples of > generating > multicast within a home network include: > > * sending audio to all of your IP-enabled speakers > distributed > throughout your house, > * IP-enabled intercom system, > * HD video to multiple telvision sets (kitchen and living > room). > > In each case, you "could" do unicast, but especially for HD > one might easily > envision not having sufficient bandwidth or not wanting to > waste the > bandwidth (which might be used for other things). > > Does anyone have suggestions on how this might be resolved? > > -d > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma > > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www1.ietf.org/mailman/listinfo/magma _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 25 00:48:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2gUp-00044P-8S; Mon, 25 Jun 2007 00:48:15 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I2gUn-00042u-T5 for behave-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 00:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2gUn-00042m-9r; Mon, 25 Jun 2007 00:48:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2gUm-0006P1-0p; Mon, 25 Jun 2007 00:48:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2007 21:48:11 -0700 X-IronPort-AV: i="4.16,457,1175497200"; d="scan'208"; a="4618209:sNHT20692728" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5P4mBiB009990; Sun, 24 Jun 2007 21:48:11 -0700 Received: from dwingwxp (sjc-vpn2-302.cisco.com [10.21.113.46]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5P4m9ka014999; Mon, 25 Jun 2007 04:48:09 GMT From: "Dan Wing" To: "'John Zwiebel'" Date: Sun, 24 Jun 2007 21:48:08 -0700 Message-ID: <00b901c7b6e4$07ec8bd0$2e71150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <335A081E-E440-4BE7-9C71-F828267B8FB9@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace2zqwW8eMb9mSpQsGuORzguHvIhgAFQskw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1379; t=1182746891; x=1183610891; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[magma]=20multicast=20senders=20behind=20an=20IGMP=20 Proxy |Sender:=20; bh=96DeGYmhqfIRS/7K2v2OUBgJ115BuWJn3GKnqnJXySM=; b=LKQzBRwj2U74bTbeUd9d9cNiQ0x8GREWY7vL/cfYwGThrecjIhfu+wpQ3M4zPNRSLQh5xvCW Yzu5hfOzZMX94FPSLUVg+WzGL7aJ3z31uLuw49dyV6vPHh35miPsvIat; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: magma@ietf.org, behave@ietf.org Subject: [BEHAVE] RE: [magma] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org > > Concrete examples of generating > > multicast within a home network include: > > > > * sending audio to all of your IP-enabled speakers distributed > > throughout your house, > > * IP-enabled intercom system, > > * HD video to multiple telvision sets (kitchen and living room). > > > > I have a difficult time imagining a home network that would have to > be subnetted. > > And although I can imagine 2 HDTVs watching the same channel > sometimes, I don't believe it will happen often enough that > there would be any BW saving inside one's home. So you're saying nobody would use multicast within their own network? Here is what we plan on adding to the next revision of the NAT Multicast document: As many NATs are located adjacent to bandwidth-constrained access links, it is important that multicast senders communicating with multicast receivers behind the NAT not have their flows consume bandwidth on the access link. This is accomplished by applications using administratively scoped IP addresses. REQ-6: A NAT MUST NOT forward administratively scoped multicast traffic (239/8) [RFC2365] from its 'inside' interface(s) to its 'outside' interface, unless the NAT has been configured to do so. Please let me know if you object to that text. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jun 25 13:37:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sV0-0006xa-GE; Mon, 25 Jun 2007 13:37:14 -0400 Received: from behave by megatron.ietf.org with local (Exim 4.43) id 1I2e6q-0007n2-3V for behave-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 22:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2e6p-0007mu-Pp; Sun, 24 Jun 2007 22:15:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2e6o-0001Hh-GF; Sun, 24 Jun 2007 22:15:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2007 19:15:18 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAATCfkarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,457,1175497200"; d="scan'208"; a="497257870:sNHT42857132" 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 l5P2FHql014758; Sun, 24 Jun 2007 19:15:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5P2FHmo000960; Mon, 25 Jun 2007 02:15:17 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Jun 2007 19:15:17 -0700 Received: from [192.168.1.10] ([10.21.81.108]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Jun 2007 19:15:16 -0700 In-Reply-To: <1d0c01c7b462$d4c148a0$c2f0200a@amer.cisco.com> References: <1d0c01c7b462$d4c148a0$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <335A081E-E440-4BE7-9C71-F828267B8FB9@cisco.com> Content-Transfer-Encoding: 7bit From: John Zwiebel Date: Fri, 22 Jun 2007 20:59:37 -0700 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 25 Jun 2007 02:15:16.0885 (UTC) FILETIME=[AC049C50:01C7B6CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=595; t=1182737717; x=1183601717; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[magma]=20multicast=20senders=20behind=20an=20IGMP=20 Proxy |Sender:=20; bh=LIARTXCfUsyBDcJaIYzBg5G4yLiGb0Ck3BMTbzKUah4=; b=CK91kZcSFOk2l1X63QIGWk3mhz6zexftpDalvuuf3XQ9G49PDxfFcf4/Jm0Xz5m3Lnhl/GgZ KM119nCdm15ilOZkhjzXl+OhApQKJVF3o9vopSMMJ0cQKyuakRAQK4rKof5d8QPhS1KJe9ksIB Ikzy5UrSH+NDKkFehsHZ9+oJg=; Authentication-Results: sj-dkim-1; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Mon, 25 Jun 2007 13:37:13 -0400 Cc: John Zwiebel , magma@ietf.org, behave@ietf.org Subject: [BEHAVE] Re: [magma] multicast senders behind an IGMP Proxy X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: behave-bounces@ietf.org On Jun 21, 2007, at 5:18 PM, Dan Wing wrote: > Concrete examples of generating > multicast within a home network include: > > * sending audio to all of your IP-enabled speakers distributed > throughout your house, > * IP-enabled intercom system, > * HD video to multiple telvision sets (kitchen and living room). > I have a difficult time imagining a home network that would have to be subnetted. And although I can imagine 2 HDTVs watching the same channel sometimes, I don't believe it will happen often enough that there would be any BW saving inside one's home. _______________________________________________ Behave mailing list Behave@ietf.org https://www1.ietf.org/mailman/listinfo/behave