From behave-bounces@ietf.org Mon Jan 5 17:55:31 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001C23A691A; Mon, 5 Jan 2009 17:55:30 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDEE3A677E for ; Mon, 5 Jan 2009 17:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjD8Ldz3EYDV for ; Mon, 5 Jan 2009 17:55:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DD0E63A68C1 for ; Mon, 5 Jan 2009 17:55:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,334,1228089600"; d="scan'208";a="224293104" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Jan 2009 01:55:17 +0000 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 n061tH1b004413; Mon, 5 Jan 2009 17:55:17 -0800 Received: from dwingwxp01 (sjc-vpn5-1294.cisco.com [10.21.93.14]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n061tFVW002960; Tue, 6 Jan 2009 01:55:16 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <200812281240.59847.simon.perreault@viagenie.ca> Date: Mon, 5 Jan 2009 17:55:15 -0800 Message-ID: <02df01c96fa1$d27b6610$78f6520a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclpE3cWnrfOAKUfQ7u8uE+5eyVh5wGhhgTg In-Reply-To: <200812281240.59847.simon.perreault@viagenie.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=853; t=1231206917; x=1232070917; 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]=20Running=20TLS=20and=20plain= 20STUN=20over=20the=20same=20TCP=20port |Sender:=20; bh=8cjyof2IKSJI1uKnQ9bUng55PdcNDzMY3nqJUbdUC5o=; b=i1LW122UsgGPIq0az6fPzQTu4XPi20/CNcRWrfpuCPFXn6QtprO2znxNGq oZurEzVXjr6uTx/nLW0ExyuS/OR27l4x2irv0LFdsc6LA9l5bZX7G4Ac1+Ib wCqkI0E6y9; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [BEHAVE] Running TLS and plain STUN over the same TCP port X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > I have a question related to the following excerpt from RFC5389: > > > Servers can run STUN over TLS on the same port as > > STUN over TCP if the server software supports > > determining whether the > > initial message is a TLS or STUN message. > > I can see two ways a server can determine that: > > 1. Static configuration. > 2. Evil heuristics. TLS and STUN can be demultiplexed by examining the first byte of the stream. Section 5.1.2 of draft-ietf-avt-dtls-srtp-06 shows how RTP, STUN, and DTLS can be demultiplexed on a UDP stream; demultiplexing STUN or TLS on a TCP stream would be similar. We should probably have provided a hint in RFC5389 that the first byte can be used to demultiplex STUN or TLS; that might be a worthwhile errata. -d > Is there a third way I have overlooked (e.g. STARTTLS)? _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 6 08:06:59 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9273A6774; Tue, 6 Jan 2009 08:06:59 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0183A6774 for ; Tue, 6 Jan 2009 08:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzo+oLUsjAry for ; Tue, 6 Jan 2009 08:06:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 982643A6405 for ; Tue, 6 Jan 2009 08:06:56 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 954CC29E1539; Tue, 6 Jan 2009 11:06:43 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 8DDB429E151D; Tue, 6 Jan 2009 11:06:43 -0500 (EST) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: "Dan Wing" Date: Tue, 6 Jan 2009 11:06:42 -0500 User-Agent: KMail/1.10.3 (Linux/2.6.27.7-134.fc10.x86_64; KDE/4.1.3; x86_64; ; ) References: <200812281240.59847.simon.perreault@viagenie.ca> <02df01c96fa1$d27b6610$78f6520a@cisco.com> In-Reply-To: <02df01c96fa1$d27b6610$78f6520a@cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901061106.43096.simon.perreault@viagenie.ca> Cc: behave@ietf.org Subject: Re: [BEHAVE] Running TLS and plain STUN over the same TCP port X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Monday 05 January 2009 20:55:15 Dan Wing wrote: > TLS and STUN can be demultiplexed by examining the first byte of the > stream. Section 5.1.2 of draft-ietf-avt-dtls-srtp-06 shows how RTP, STUN, > and DTLS can be demultiplexed on a UDP stream; demultiplexing STUN or TLS > on a TCP stream would be similar. > > We should probably have provided a hint in RFC5389 that the first byte can > be used to demultiplex STUN or TLS; that might be a worthwhile errata. Thanks for your reply! To summarize for the benefit of those reading the archives: We're assuming that no STUN method ID greater than 0x63 exists. This ensures that the first byte is always <= 2 for STUN messages. In ChannelData messages, the first byte is always > 0x40 by definition. TLS 1.x always sends 3 as the first byte. That's actually what "evil heuristics" was referring to because I didn't like making this assumption on my own. Now I know I'm in good company. :) Thanks, Simon -- Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 7 16:45:02 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCE43A6AB0; Wed, 7 Jan 2009 16:45:02 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B86663A6905; Wed, 7 Jan 2009 16:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090108004501.B86663A6905@core3.amsl.com> Date: Wed, 7 Jan 2009 16:45:01 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-nat-icmp-12.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : NAT Behavioral Requirements for ICMP protocol Author(s) : P. Srisuresh, et al. Filename : draft-ietf-behave-nat-icmp-12.txt Pages : 27 Date : 2009-01-07 This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-icmp-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-behave-nat-icmp-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-07163924.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --NextPart-- From behave-bounces@ietf.org Wed Jan 7 18:02:53 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF8E3A68A6; Wed, 7 Jan 2009 18:02:53 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077B03A6924 for ; Wed, 7 Jan 2009 18:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep50-Ou7YYL3 for ; Wed, 7 Jan 2009 18:01:17 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 222B43A681F for ; Wed, 7 Jan 2009 18:01:17 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so7935813rvf.49 for ; Wed, 07 Jan 2009 18:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=l/YtFvjjPOuvoGrQpHwKLukL78ynDTGTVQDhUF4m6ag=; b=PBbPNNVjKCl02xBKNMyAYtKgPawQxBDMcg4/xbDlqnjZ2Syj8BLSSSpbOG5oXnGq4P aK5erqZZh3A4Is6kEJHrEDmAbCgDcbKVSOt+seu1873zsXeL8TzkwR3xpkZdsDF0krCZ 04BCr1R4avLTsgFLFwe4Sqv5YLGTTA0kCWpKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=TWuJKhwzwpBrKtLbhmCKgHH0O8qgI2GG0wqp/pHDHco/FwqQDoccYFLYKgdyy+/T4g DI4YkflNyvUVqb8nn4WWvU1MM3yzXhQ3ipLZOWWm/p+gIQR7LPClxoeZlM/3sTqu0pIA Q2JCKmic68R6febT7jZlTPyz6YeqyBGLgM0H0= Received: by 10.142.221.11 with SMTP id t11mr9925219wfg.86.1231380063325; Wed, 07 Jan 2009 18:01:03 -0800 (PST) Received: by 10.142.200.14 with HTTP; Wed, 7 Jan 2009 18:01:03 -0800 (PST) Message-ID: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> Date: Wed, 7 Jan 2009 21:01:03 -0500 From: "Scott Godin" To: "Philip Matthews" , jdrosen@cisco.com, "Rohan Mahy" , "Behave WG" MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 500dc6cf4e9214bb Subject: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org I'm in the process updating reTurn (opensource Turn server in resiprocate project) to the latest turn-12, and have the following comments/typos after reviewing the draft. 1. section 1, 4th paragraph, "When the client send...." - should be "...sends..." 2. section 2.1, last paragraph, ".., the client may send and received packets..." - should be "...receive..." 3. section 2.6, list "The ECN field is may be reset..." - remove "is" 4. section 5, 3rd last paragraph indicates that username, password, realm and nonce are used to verify subsequent requests - but according to section 4 paragraph 6 the only information authentication information used to verify subsequent requests is the username. I think one of these sections needs to be re-worded to avoid confusion. Perhaps section 4 should indicate that username, realm and password should be stored and verified across all requests for an allocation - this will cover cases where the same username exists in two different realms. However note that if password hash is stored instead of the plain password, then we don't really need to store and compare realm, since it is hashed into the password. 5. section 6.2 - step 5 "... request contains a EVEN-PORT attribute..." - should be "...contains an EVEN-PORT attribute..." 6. section 7.2 - first step indicates that "the additional username check of section 4" should be complete. This comment needs to be brought inline with the wording decided for comment 4. 7. section 9, 2nd paragraph - missing space "... inSection..." 8. section 9.2 is missing the steps/checks to process similar to Allocate and Refresh requests - it would be good to add these for consistency. It should also include: Long Term Cred check, existing allocation check, and the required auth (username, etc.) checks. 9. section 10, 1st paragraph - "...for sending and receive data from..." - should read "...for sending and receiving data..." 10. section 10.2 - should include a step to ensure that an allocation exists for the 5-tuple, else message is dropped 11. section 10.2, 4th paragraph, last sentence - "...the server MUST NOT refresh the permission due to the receipt of the Send indication..." - should be removed since Send Indication never refresh permissions now 12. section 10 indicates that Data attribute is mandatory in a Send Indication - should we allow no data attribute to indicate that a 0 length UDP packet? Note the ChannelBinding section discusses sending a 0 length packet (section 11.6 last paragraph). Perhaps this could also be accomplished using a Data attribute containing a data length of 0 - but I think there should be some mention of this in section 10. 13. section 11, paragraph 5 - "...or may choose never to bind a channel it." - should be "...channel to it." 14. section 11.2 - check list should be numeric to be consistent with Allocate and Refresh requests. Should also contain Long Term Cred check, existing allocation check, and the required auth (username, etc.) checks 15. section 11.5 - I'm not sure I understand the need to pad the ChannelData message to a multiple of four bytes. TCP implementations are capable of reading in the exact right number of bytes from the stream. Can this requirement be removed? 16. Is there are reason we don't just make the default permission and channel binding lifetime the same, to facilitate use of the ChannelBind refresh to accomplish both refreshes without worrying about the difference? My apologies if my questions/suggestions have already been discussed. Thanks, Scott Godin _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 8 00:27:16 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC6D3A6A21; Thu, 8 Jan 2009 00:27:16 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF3C3A6A21 for ; Thu, 8 Jan 2009 00:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnFdMbn-pMr1 for ; Thu, 8 Jan 2009 00:27:14 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 5AAE53A683D for ; Thu, 8 Jan 2009 00:27:14 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jan 2009 09:27:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9716A.DFEA5B7C" Date: Thu, 8 Jan 2009 09:26:59 +0100 Message-ID: <6CF039C5B32037498B02251E11CDE6B007A29FCE@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-behave-bittorrent-portrange-01.txt thread-index: AclwxczN/rXEAh2xQrO7Eu+Cy94Y/AApQU1A From: To: X-OriginalArrivalTime: 08 Jan 2009 08:27:00.0023 (UTC) FILETIME=[E04AA470:01C9716A] Subject: [BEHAVE] TR: I-D Action:draft-boucadair-behave-bittorrent-portrange-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C9716A.DFEA5B7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 FYI. Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : mercredi 7 janvier 2009 13:45 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-behave-bittorrent-portrange-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Behaviour of BitTorrent service in an IP Shared = Address Environment Author(s) : M. Boucadair, et al. Filename : draft-boucadair-behave-bittorrent-portrange-01.txt Pages : 19 Date : 2009-01-07 This memo describes the behaviour of BitTorrent service in the context = of IP shared addresses. It provides an overview of the used testbed and = main results of the tests that have been conducted in order to assess = the limitations of an architecture based on shared IP addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-behave-bittorrent-por= trange-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. ------_=_NextPart_001_01C9716A.DFEA5B7C Content-Type: application/octet-stream; name="draft-boucadair-behave-bittorrent-portrange-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-behave-bittorrent-portrange-01.URL Content-Disposition: attachment; filename="draft-boucadair-behave-bittorrent-portrange-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItYmVoYXZlLWJpdHRvcnJlbnQtcG9ydHJhbmdlLTAxLnR4dA0K ------_=_NextPart_001_01C9716A.DFEA5B7C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ------_=_NextPart_001_01C9716A.DFEA5B7C-- From behave-bounces@ietf.org Sun Jan 11 18:39:51 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01183A68F9; Sun, 11 Jan 2009 18:39:51 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1B93A68F9 for ; Sun, 11 Jan 2009 18:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjO7IuGwzOAU for ; Sun, 11 Jan 2009 18:39:50 -0800 (PST) Received: from mail-07.primus.ca (mail10.primus.ca [216.254.141.177]) by core3.amsl.com (Postfix) with ESMTP id D80953A68E0 for ; Sun, 11 Jan 2009 18:39:49 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LMCi7-0003OD-2U; Sun, 11 Jan 2009 21:39:27 -0500 Message-Id: From: Philip Matthews To: Simon Perreault In-Reply-To: <200901061106.43096.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 11 Jan 2009 05:10:14 -0500 References: <200812281240.59847.simon.perreault@viagenie.ca> <02df01c96fa1$d27b6610$78f6520a@cisco.com> <200901061106.43096.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] Running TLS and plain STUN over the same TCP port X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Tue, 6-Jan-09, at 11:06 , Simon Perreault wrote: > On Monday 05 January 2009 20:55:15 Dan Wing wrote: >> TLS and STUN can be demultiplexed by examining the first byte of the >> stream. Section 5.1.2 of draft-ietf-avt-dtls-srtp-06 shows how RTP, >> STUN, >> and DTLS can be demultiplexed on a UDP stream; demultiplexing STUN >> or TLS >> on a TCP stream would be similar. >> >> We should probably have provided a hint in RFC5389 that the first >> byte can >> be used to demultiplex STUN or TLS; that might be a worthwhile >> errata. > > Thanks for your reply! > > To summarize for the benefit of those reading the archives: > > We're assuming that no STUN method ID greater than 0x63 exists. This > ensures I think you meant 127 (0x7F) and not 0x63. > > that the first byte is always <= 2 for STUN messages. In ChannelData > messages, > the first byte is always > 0x40 by definition. TLS 1.x always sends > 3 as the > first byte. > > That's actually what "evil heuristics" was referring to because I > didn't like > making this assumption on my own. Now I know I'm in good company. :) _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 12 05:27:37 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C785328C0F5; Mon, 12 Jan 2009 05:27:37 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F743A6803 for ; Mon, 12 Jan 2009 05:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsqbJkiRSf2k for ; Mon, 12 Jan 2009 05:27:35 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 70ECC3A67DB for ; Mon, 12 Jan 2009 05:27:35 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 2C62429E154E; Mon, 12 Jan 2009 08:27:20 -0500 (EST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 21E4229E1530; Mon, 12 Jan 2009 08:27:20 -0500 (EST) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Philip Matthews Date: Mon, 12 Jan 2009 08:27:14 -0500 User-Agent: KMail/1.10.3 (Linux/2.6.27.7-134.fc10.x86_64; KDE/4.1.3; x86_64; ; ) References: <200812281240.59847.simon.perreault@viagenie.ca> <200901061106.43096.simon.perreault@viagenie.ca> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901120827.15443.simon.perreault@viagenie.ca> Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] Running TLS and plain STUN over the same TCP port X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Sunday 11 January 2009 05:10:14 Philip Matthews wrote: > > We're assuming that no STUN method ID greater than 0x63 exists. This = =A0 > > ensures > > I think you meant 127 (0x7F) and not 0x63. Right. Why I wrote 0x63 is a complete mystery to me... -- = Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 13 07:52:38 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBAF3A6AF9; Tue, 13 Jan 2009 07:52:38 -0800 (PST) X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4C50E3A690A; Tue, 13 Jan 2009 07:52:36 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090113155237.4C50E3A690A@core3.amsl.com> Date: Tue, 13 Jan 2009 07:52:37 -0800 (PST) Cc: behave@ietf.org Subject: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14443&rfc_flag=0 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 13 08:31:49 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3497F28C0E6; Tue, 13 Jan 2009 08:31:49 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD3328C0E6; Tue, 13 Jan 2009 08:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzKswNweMd8B; Tue, 13 Jan 2009 08:31:46 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id B23CC3A6944; Tue, 13 Jan 2009 08:31:46 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so81839wfd.31 for ; Tue, 13 Jan 2009 08:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=DHedPdVEVedzTllbz1pvUUpj6gd5xXeuX6ONFTAJl2g=; b=FcFt3j+Nfo0lBdrfJRFKl3SgaPjG6A0MfXjUijrkXufe/ate36q+Ih0gDX+8B8i0Ru 8gFeQ3cP0oc1wFuLZbJ1xldWeellLTELYmvtB8sUgZnu0hezwvvU1LzSGRvmlBEZU0a+ vsBt+C6ImO4Ek4H7Gjh2JEzUKjVEPgZCB8P0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mch4qOMuaqo+Ccp/8UKSO4ngvyQIuhScHJeJ5FI1Q5Y1Al+USNOyOhZQTUNIAFBbgh 8Vp9qTxPZpooSjXq2rOFLTPN8h5k+q8vvgGiOMSnCf39R2HSWYoUjLj7zagmF80ciL8/ IFylLLVbTj/J9krB67zUkVTkTqOGNvmd6C1ec= MIME-Version: 1.0 Received: by 10.142.164.10 with SMTP id m10mr12934480wfe.184.1231864291182; Tue, 13 Jan 2009 08:31:31 -0800 (PST) In-Reply-To: <20090113155237.4C50E3A690A@core3.amsl.com> References: <20090113155237.4C50E3A690A@core3.amsl.com> Date: Tue, 13 Jan 2009 11:31:31 -0500 X-Google-Sender-Auth: 22abb3381c49a336 Message-ID: <82d15bd90901130831q3136aed6j7845e75601b4aba7@mail.gmail.com> From: Scott Godin To: ietf@ietf.org Cc: behave@ietf.org, IETF-Announce Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org FYI - I've submitted the following comments last week sometime, but I think they may be held up in the moderator queue: I'm in the process updating reTurn (opensource Turn server in resiprocate project) to the latest turn-12, and have the following comments/typos after reviewing the draft. 1. section 1, 4th paragraph, "When the client send...." - should be "...sends..." 2. section 2.1, last paragraph, ".., the client may send and received packets..." - should be "...receive..." 3. section 2.6, list "The ECN field is may be reset..." - remove "is" 4. section 5, 3rd last paragraph indicates that username, password, realm and nonce are used to verify subsequent requests - but according to section 4 paragraph 6 the only information authentication information used to verify subsequent requests is the username. I think one of these sections needs to be re-worded to avoid confusion. Perhaps section 4 should indicate that username, realm and password should be stored and verified across all requests for an allocation - this will cover cases where the same username exists in two different realms. However note that if password hash is stored instead of the plain password, then we don't really need to store and compare realm, since it is hashed into the password. 5. section 6.2 - step 5 "... request contains a EVEN-PORT attribute..." - should be "...contains an EVEN-PORT attribute..." 6. section 7.2 - first step indicates that "the additional username check of section 4" should be complete. This comment needs to be brought inline with the wording decided for comment 4. 7. section 9, 2nd paragraph - missing space "... inSection..." 8. section 9.2 is missing the steps/checks to process similar to Allocate and Refresh requests - it would be good to add these for consistency. It should also include: Long Term Cred check, existing allocation check, and the required auth (username, etc.) checks. 9. section 10, 1st paragraph - "...for sending and receive data from..." - should read "...for sending and receiving data..." 10. section 10.2 - should include a step to ensure that an allocation exists for the 5-tuple, else message is dropped 11. section 10.2, 4th paragraph, last sentence - "...the server MUST NOT refresh the permission due to the receipt of the Send indication..." - should be removed since Send Indication never refresh permissions now 12. section 10 indicates that Data attribute is mandatory in a Send Indication - should we allow no data attribute to indicate that a 0 length UDP packet? Note the ChannelBinding section discusses sending a 0 length packet (section 11.6 last paragraph). Perhaps this could also be accomplished using a Data attribute containing a data length of 0 - but I think there should be some mention of this in section 10. 13. section 11, paragraph 5 - "...or may choose never to bind a channel it." - should be "...channel to it." 14. section 11.2 - check list should be numeric to be consistent with Allocate and Refresh requests. Should also contain Long Term Cred check, existing allocation check, and the required auth (username, etc.) checks 15. section 11.5 - I'm not sure I understand the need to pad the ChannelData message to a multiple of four bytes. TCP implementations are capable of reading in the exact right number of bytes from the stream. Can this requirement be removed? 16. Is there are reason we don't just make the default permission and channel binding lifetime the same, to facilitate use of the ChannelBind refresh to accomplish both refreshes without worrying about the difference? My apologies if my questions/suggestions have already been discussed. Thanks, Scott Godin On Tue, Jan 13, 2009 at 10:52 AM, The IESG wrote: > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > > - 'Traversal Using Relays around NAT (TURN): Relay Extensions to > Session Traversal Utilities for NAT (STUN) ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-01-27. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-12.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14443&rfc_flag=0 > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 14 06:01:00 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FED3A6B5E; Wed, 14 Jan 2009 06:01:00 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7313528C101 for ; Wed, 14 Jan 2009 06:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ5oGENBH20H for ; Wed, 14 Jan 2009 06:00:59 -0800 (PST) Received: from mail-02.primus.ca (mail10.primus.ca [216.254.141.177]) by core3.amsl.com (Postfix) with ESMTP id 791A13A6B5D for ; Wed, 14 Jan 2009 06:00:59 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LMWmH-00084o-2T; Mon, 12 Jan 2009 19:05:05 -0500 Message-Id: <866ADCE0-6D57-4329-8D62-66103DA1A603@magma.ca> From: Philip Matthews To: Simon Perreault In-Reply-To: <200901120827.15443.simon.perreault@viagenie.ca> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 12 Jan 2009 17:54:37 -0500 References: <200812281240.59847.simon.perreault@viagenie.ca> <200901061106.43096.simon.perreault@viagenie.ca> <200901120827.15443.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] Running TLS and plain STUN over the same TCP port X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The good thing is that, so far, there hasn't been a lot of new STUN methods defined. So this trick seems likely to continue working for a while ... - Philip On Mon, 12-Jan-09, at 08:27 , Simon Perreault wrote: > On Sunday 11 January 2009 05:10:14 Philip Matthews wrote: >>> We're assuming that no STUN method ID greater than 0x63 exists. This >>> ensures >> >> I think you meant 127 (0x7F) and not 0x63. > > Right. Why I wrote 0x63 is a complete mystery to me... > > -- > Please try Numb, a STUN/TURN server implementation. > Free access at http://numb.viagenie.ca/. > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 14 10:39:46 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3AE3A6A33; Wed, 14 Jan 2009 10:39:46 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068C23A6A33 for ; Wed, 14 Jan 2009 10:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvH-LW0kfQrA for ; Wed, 14 Jan 2009 10:39:45 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id BE2C43A694D for ; Wed, 14 Jan 2009 10:39:44 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so539241yxg.49 for ; Wed, 14 Jan 2009 10:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=LmYlvuR+XrM3om/TkX4kJCipsio6TkSYUsouAbJIL74=; b=xGUFQVfxEl8mLS9olP7ARcnNI+L5CurvXVzfe/Wx0F6gXrXGWFBOiz3wfqulNncDQI wGL+Jn0jJORr/NRMPpM++zF1mDQQZ4pmEHXDfVgNNwpXZU8AXRUcjpxSdz7iNu32qCRV lYbtSxT0hgGyIcOVrKgDnvuYOWqwg5pRSBnFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=dVYDsh2NEANdPPVut3hZrbrKlaECq/qCeTDdhWSQ9mdyBMtg8di9uSNJiUNsNKoYOr Cg7ANFNAP+sYJtaTvlJPcEY5Y6m9B6T5CG2/GqApUuXWhcAyWh7ED/+n/RLGzXuOHlY8 G8aQm484/06CqRuNTxJSjQuj/B35itxuFoPac= MIME-Version: 1.0 Received: by 10.142.153.7 with SMTP id a7mr115661wfe.294.1231958369124; Wed, 14 Jan 2009 10:39:29 -0800 (PST) In-Reply-To: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> References: <82d15bd90901071801s751a6cc9m6a285e2de37cd6dd@mail.gmail.com> Date: Wed, 14 Jan 2009 13:39:29 -0500 X-Google-Sender-Auth: 621de914eef43247 Message-ID: <82d15bd90901141039v11c109b4scbad54d83e7d7664@mail.gmail.com> From: Scott Godin To: Philip Matthews , jdrosen@cisco.com, Rohan Mahy , Behave WG Subject: Re: [BEHAVE] TURN-12 Comments/Typos X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org A couple of additional notes: Section 11 - "To prevent race conditions, the client MUST wait 5 muntes after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number". I think this statement should be expanded to explicitly say that this is within the context of an allocation. The client should be able to re-use the transport address in a channel binding of a new allocation, anytime after the previous allocation that it was used in has been destroyed. Radical Ideal - In writing my client library, I would like to mask as many of the lower level TURN details as possible. This means that masking the details behind channel binding, and channel messaging vs Data/Send Ind data sending mechanism is desirable. I don't see any draw backs of using the channel binding mechanism over the Data/Send Ind method, and it uses lower bandwidth, so I'm considering that my client API will just always use this mechanism. This leads me to think - do we really need both mechanisms? Supporting only the Channel Binding mechanism would really simplify this draft, you would be able to get rid of the following concepts: Create/Refresh Permission (done explicily via Channel Binding), Data Indication sending/handling, Send Indication sending/handling. I'm not really understanding the value of offering both mechanisms. With previous versions (pre-Create Permission), it made sense to support both mechanisms in order to avoid having the queue data to send in the client waiting for the channel bind response, but now you need to wait for the permission to be installed before you send data, so some queuing will be required anyway. Thanks, Scott On Wed, Jan 7, 2009 at 9:01 PM, Scott Godin wrote: > I'm in the process updating reTurn (opensource Turn server in > resiprocate project) to the latest turn-12, and have the following > comments/typos after reviewing the draft. > > 1. section 1, 4th paragraph, "When the client send...." - should be > "...sends..." > > 2. section 2.1, last paragraph, ".., the client may send and received > packets..." - should be "...receive..." > > 3. section 2.6, list "The ECN field is may be reset..." - remove "is" > > 4. section 5, 3rd last paragraph indicates that username, password, > realm and nonce are used to verify subsequent requests - but according > to section 4 paragraph 6 the only information authentication > information used to verify subsequent requests is the username. I > think one of these sections needs to be re-worded to avoid confusion. > Perhaps section 4 should indicate that username, realm and password > should be stored and verified across all requests for an allocation - > this will cover cases where the same username exists in two different > realms. However note that if password hash is stored instead of the > plain password, then we don't really need to store and compare realm, > since it is hashed into the password. > > 5. section 6.2 - step 5 "... request contains a EVEN-PORT > attribute..." - should be "...contains an EVEN-PORT attribute..." > > 6. section 7.2 - first step indicates that "the additional username > check of section 4" should be complete. This comment needs to be > brought inline with the wording decided for comment 4. > > 7. section 9, 2nd paragraph - missing space "... inSection..." > > 8. section 9.2 is missing the steps/checks to process similar to > Allocate and Refresh requests - it would be good to add these for > consistency. It should also include: Long Term Cred check, existing > allocation check, and the required auth (username, etc.) checks. > > 9. section 10, 1st paragraph - "...for sending and receive data > from..." - should read "...for sending and receiving data..." > > 10. section 10.2 - should include a step to ensure that an allocation > exists for the 5-tuple, else message is dropped > > 11. section 10.2, 4th paragraph, last sentence - "...the server MUST > NOT refresh the permission due to the receipt of the Send > indication..." - should be removed since Send Indication never refresh > permissions now > > 12. section 10 indicates that Data attribute is mandatory in a Send > Indication - should we allow no data attribute to indicate that a 0 > length UDP packet? Note the ChannelBinding section discusses sending > a 0 length packet (section 11.6 last paragraph). Perhaps this could > also be accomplished using a Data attribute containing a data length > of 0 - but I think there should be some mention of this in section 10. > > 13. section 11, paragraph 5 - "...or may choose never to bind a > channel it." - should be "...channel to it." > > 14. section 11.2 - check list should be numeric to be consistent with > Allocate and Refresh requests. Should also contain Long Term Cred > check, existing allocation check, and the required auth (username, > etc.) checks > > 15. section 11.5 - I'm not sure I understand the need to pad the > ChannelData message to a multiple of four bytes. TCP implementations > are capable of reading in the exact right number of bytes from the > stream. Can this requirement be removed? > > 16. Is there are reason we don't just make the default permission and > channel binding lifetime the same, to facilitate use of the > ChannelBind refresh to accomplish both refreshes without worrying > about the difference? > > My apologies if my questions/suggestions have already been discussed. > > Thanks, > Scott Godin > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 14 17:44:06 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D6A3A6AA6; Wed, 14 Jan 2009 17:44:06 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0943A6A43 for ; Wed, 14 Jan 2009 17:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeZVpxlQTcDg for ; Wed, 14 Jan 2009 17:44:04 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D1A923A68A9 for ; Wed, 14 Jan 2009 17:44:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,265,1231113600"; d="scan'208";a="59592930" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Jan 2009 01:43:50 +0000 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 n0F1ho5C019685; Wed, 14 Jan 2009 17:43:50 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0F1hljJ011618; Thu, 15 Jan 2009 01:43:49 GMT From: "Dan Wing" To: Date: Wed, 14 Jan 2009 17:43:47 -0800 Message-ID: <00e701c976b2$b6cbde00$d312590a@cisco.com> MIME-Version: 1.0 X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclxuETcvNCPupucRASslmyMepJprwAFxkPAATgUu2A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Importance: High DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7152; t=1231983830; x=1232847830; 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:=20Announcement=20regarding=20RFC5378 |Sender:=20; bh=Smiqcb9ODCxOq2E1by06BlJwz5tUl9BlpWNqEkiT/m4=; b=J1E2hN9tMIEBcae8sAJtPIOVXczCCW8cXkeSAGPoqGhuzsK8iX/++OxPqk 8RhVWKuOIp/ye8h8WOQX0gPxcPzbfr8QfuP/EMzQvWEakcK7fM5+iUtHPRa3 w3tQK8VwmL; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] Announcement regarding RFC5378 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The WG Chairs have been asked to make their WG aware of this issue. This is a complicated subject, but the executive summary is that if you have an Internet-draft that quotes substantially from one or more older RFCs (ones with a publication date pre-November 11, 2008), and you did not write this earlier work yourself (or you wrote it while with another company), you need to be aware of the likely difficulty of obtaining RFC5378 clearances for your new work, and also to be aware that a work-around is on the way. The work-around should be in place to allow submissions to the San Francisco IETF well before the normal deadlines. See the attached text for more details. If you feel that you have a draft for which this will be a problem, please contact me or Dave Thaler. Please direct general followup questions to the main IETF list, ietf@ietf.org, and not to BEHAVE. Questions about specific WG drafts are of course on topic. -d -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ed Juskevicius Sent: Thursday, January 08, 2009 1:44 PM To: 'IETF Discussion'; ietf-announce@ietf.org; iesg@ietf.org; iab@iab.org; rfc-editor@rfc-editor.org; wgchairs@ietf.org Cc: 'Trustees' Subject: ANNOUNCEMENT: The IETF Trustees invite your review and comments on aproposed Work-Around to the Pre-5378 Problem Importance: High The purpose of this message is twofold: 1) To summarize the issues that some members of our community have experienced since the publication of RFC 5378 in November 2008, and 2) To invite community review and discussion on a potential work-around being considered by the IETF Trustees. Some I-D authors are having difficulty implementing RFC 5378. An example of the difficulty is as follows: - an author wants to include pre-5378 content in a new submission or contribution to the IETF, but - s/he is not certain that all of the author(s) of the earlier material have agreed to license it to the IETF Trust according to RFC 5378. If an I-D author includes pre-5378 material in a new document, then s/he must represent or warrant that all of the authors who created the pre-5378 material have granted rights for that material to the IETF Trust. If s/he cannot make this assertion, then s/he has a problem. This situation has halted the progression of some Internet-Drafts and interrupted the publication of some RFCs. The Trustees of the IETF Trust are investigating ways to implement a temporary work-around so that IETF work can continue to progress. A permanent solution to this "pre-5378 problem" may require an update to RFC 5378, for example new work by the community to create a 5378-bis document. The remainder of this message provides an outline of the temporary work- around being considered by the Trustees. RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the authority to develop legend text for authors to use in situations where they wish to limit the granting of rights to modify and prepare derivatives of the documents they submit. The Trustees used this authority in 2008 to develop and adopt the current "Legal Provisions Relating to IETF Documents" which are posted at: http://trustee.ietf.org/license-info/. The Trustees are now considering the creation of optional new legend text which could be used by authors experiencing the "pre-5378 problem". The new legend text, if implemented, would do the following: a. Provide Authors and Contributors with a way to identify (to the IETF Trust) that their contributions contain material from pre-5378 documents for which RFC 5378 rights to modify the material outside the IETF standards process may not have been granted, and b. Provide the IETF Trust and the community with a clear indication of every document containing pre-5378 content and having the "pre-5378 problem". So, how could the creation and use of some new legend text help people work-around the pre-5378 problem? The proposed answer is as follows: 1. Anyone having a contribution with the "pre-5378" problem should add new legend text to the contribution, to clearly flag that it includes pre-5378 material for which all of the rights needed under RFC 5378 may not have been granted, and 2. The IETF Trust will consider authors and contributors (with the pre-5378 problem) to have met their RFC 5378 obligations if the new legend text appears on their documents, and 3. Authors and contributors should only resort to adding the new legend text to their documents (per #1) if they cannot develop certainty that all of the author(s) of pre-5378 material in their documents have agreed to license the pre-5378 content to the IETF Trust according to RFC 5378. The proposed wording for the new legend text is now available for your review and comments in section 6.c.iii of a draft revision to the IETF Trust's "Legal Provisions Relating to IETF Documents" located at http://trustee.ietf.org/policyandprocedures.html. Please note that the above document also contains new text in section 5.c dealing with "License Limitations". If your review and feedback on this proposed work-around is positive, then the new text may be adopted by the Trustees in early February 2009, and then be published as an official revision to the Legal Provisions document. If so adopted, Internet-Drafts with pre-5378 material may advance within the Internet standards process and get published as RFCs where otherwise qualified to do so. Unless covered by sections 6.c.i or 6.c.ii, authors of documents in which there is no pre-5378 material must provide a RFC 5378 license with no limitation on modifications outside the IETF standards process. The IETF Trust will not grant the right to modify or prepare derivative works of any specific RFC or other IETF Contribution outside the IETF standards process until RFC 5378 rights pertaining to that document have been obtained from all authors and after compliance by the IETF Trust with RFC 5377. The Trustees will establish one or more mechanisms by which authors of pre-5378 documents may grant RFC 5378 rights. The Trustees hereby invite your review, comments and suggestions on this proposed work-around to the "pre-5378 problem". The period for this review is 30 days. Microsoft WORD and PDF versions of the proposed revisions are attached to this message. Copies are also available on the IETF Trust website under the heading "DRAFT Policy and Procedures Being Developed" at: http://trustee.ietf.org/policyandprocedures.html All feedback submitted before the end of February 7th will be considered by the Trustees. A decision on whether to move forward with this proposal will be made and communicated to you before the end of February 15th. Please give this your attention. Regards and Happy New Year ! Ed Juskevicius, on behalf of the IETF Trustees edj.etc@gmail.com _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 19 04:36:24 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE64C28C1AF; Mon, 19 Jan 2009 04:36:24 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D6C28C1AF for ; Mon, 19 Jan 2009 04:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-ndjD3asVX7 for ; Mon, 19 Jan 2009 04:36:22 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7769828C1AA for ; Mon, 19 Jan 2009 04:36:22 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FF46201B1; Mon, 19 Jan 2009 13:36:05 +0100 (CET) X-AuditID: c1b4fb3e-b0072bb00000429e-f7-497473b4e094 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E2D6F201E9; Mon, 19 Jan 2009 13:36:04 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 13:36:04 +0100 Received: from [147.214.183.23] ([147.214.183.23]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jan 2009 13:36:03 +0100 Message-ID: <497473B4.6060305@ericsson.com> Date: Mon, 19 Jan 2009 13:36:04 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: behave@ietf.org, draft-ietf-behave-turn@tools.ietf.org References: <20090113155237.4C50E3A690A@core3.amsl.com> In-Reply-To: <20090113155237.4C50E3A690A@core3.amsl.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 19 Jan 2009 12:36:03.0967 (UTC) FILETIME=[7E1EC8F0:01C97A32] X-Brightmail-Tracker: AAAAAA== Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi, Here is my IETF last call comments. 1. Section 2.6: " o Path MTU Discovery does not work, except in the limited way available using the DONT-FRAGMENT attribute (see below); and" I think it would be more correct to say: "ICMP based Path MTU DIsovery does not ..." 2. Section 9.1 and 9.2: These two sections doesn't as clearly as the other request chapters discuss the issue of authentication of the request. I think that CreatePermission is equally important to protect to the other management requests. 3. Section 11.2: " The server MAY also impose restrictions on the range of IP addresses and ports allowed in the XOR-PEER-ADDRESS attribute." How does one learn that this is happening from the response? Shouldn't there be an error code for "Administratively Prohibited" that is indicated to be return in this case? 4. Regarding the Fragmentation Question. I have raised this before and we didn't come to a conclusion. Below are a text proposal for including the thing I think is missing in the preferred behavior. I know this clearly requires OS level implementation but that is why there is alternative behavior and this only specified at should level. I do hope that we get some feedback on this proposal. I personally think it is important to indicate how it should be properly done, even if a number of implementation will not do it. My proposed text for the IPv4 Fragementation field: Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the DF bit in the outgoing IP header to 1. In all other cases when sending an outgoing packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), copy the DF bit from the DF bit of the incoming packet that contained the application data. Set the other fragmentation fields (Identification, MF, Fragment Offset) as appropriate for a packet originating from the server. For a packet that had the DF bit set on reception by the server, or was delivered to the server with a Send Indication including a DONT-FRAGMENT attribute and which require fragmentation when being sent from the server should result in a ICMP message (Type=3D3, Code=3D4 (Fragmentation needed and DF set)) towards the sender of the packet. Alternate Behavior: As described in the Preferred Behavior, except always assume the incoming DF bit is 0 and that no ICMP messages needs to be sent. In both the Preferred and Alternate Behaviors, the resulting packet may be too large for the outgoing link. If this is the case, then the normal fragmentation rules apply [RFC1122]. NITS: Section 2.6: Missing space: "still require this,TURN allows the client to request that the server" Section 5: Extra space before "." The username, realm, and nonce values are initially those used in the authenticated Allocate request that creates the allocation, though the server can change the nonce value during the lifetime of the allocation using a 438 (Stale Nonce) reply . -- = Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 19 04:50:05 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B0228C1C7; Mon, 19 Jan 2009 04:50:05 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7877828C1C7 for ; Mon, 19 Jan 2009 04:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.293 X-Spam-Level: X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDyUhb09z0eC for ; Mon, 19 Jan 2009 04:50:03 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D2BD128C1C4 for ; Mon, 19 Jan 2009 04:50:02 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n0JCnS6p020140 for ; Mon, 19 Jan 2009 14:49:41 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 14:49:37 +0200 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jan 2009 14:49:36 +0200 Received: from leon.remlab.net (esdhcp041160.research.nokia.com [172.21.41.160]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n0JCnY0L004901 for ; Mon, 19 Jan 2009 14:49:34 +0200 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Mon, 19 Jan 2009 14:49:45 +0200 User-Agent: KMail/1.10.3 (Linux/2.6.27.10; KDE/4.1.3; i686; ; ) References: <20090113155237.4C50E3A690A@core3.amsl.com> <497473B4.6060305@ericsson.com> In-Reply-To: <497473B4.6060305@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901191449.45566.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 19 Jan 2009 12:49:36.0604 (UTC) FILETIME=[627D59C0:01C97A34] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On Monday 19 January 2009 14:36:04 ext Magnus Westerlund, you wrote: > I have raised this before and we didn't come to a conclusion. Below are > a text proposal for including the thing I think is missing in the > preferred behavior. I know this clearly requires OS level implementation > but that is why there is alternative behavior and this only specified at > should level. I do hope that we get some feedback on this proposal. I > personally think it is important to indicate how it should be properly > done, even if a number of implementation will not do it. Side note: It does require OS-specific support. As far as this is UDP-only TURN, I = believe it could be done in (unprivileged) userland with very limited chang= es = to the IP stack. We just an option to pass DF via ancilliary data. This wou= ld = very similar to what IETF/POSIX have defined for TTL and DSCP in the = *Advanced* IPv6 socket API. On Linux, you can already set the DF bit (per UDP socket). However, at the = time of writing this email, you cannot "get" it from incoming packet. -- = R=E9mi Denis-Courmont Maemo Software, Nokia Devices R&D _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Mon Jan 19 23:23:34 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B223A6820; Mon, 19 Jan 2009 23:23:34 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0B23A6820 for ; Mon, 19 Jan 2009 23:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.357 X-Spam-Level: *** X-Spam-Status: No, score=3.357 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-6tivAX-TZ3 for ; Mon, 19 Jan 2009 23:23:32 -0800 (PST) Received: from softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 519303A67AD for ; Mon, 19 Jan 2009 23:23:32 -0800 (PST) Received: (qmail 15991 invoked by uid 0); 20 Jan 2009 16:16:33 +0900 Received: from unknown (HELO softfront.co.jp) (172.16.0.2) by mail.softfront.co.jp with SMTP; 20 Jan 2009 16:16:33 +0900 From: OKUMURA Shinji To: ietf@ietf.org Date: Tue, 20 Jan 2009 16:16:32 +0900 MIME-Version: 1.0 X-Mailer: HidemaruMail 5.13 (WinNT,501) In-Reply-To: <20090113155237.4C50E3A690A@core3.amsl.com> References: <20090113155237.4C50E3A690A@core3.amsl.com> Message-Id: <12C97ACF0547E8shin@softfront.co.jp> Cc: behave@ietf.org Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-turn (Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi. I have one comment. Page 51 "alerted or forged", it would be "altered or forged". Regards, Shinji The IESG >The IESG has received a request from the Behavior Engineering for >Hindrance Avoidance WG (behave) to consider the following document: > >- 'Traversal Using Relays around NAT (TURN): Relay Extensions to > Session Traversal Utilities for NAT (STUN) ' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2009-01-27. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-12.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14443& >rfc_flag=0 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 20 02:11:03 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2EAA3A6B1B; Tue, 20 Jan 2009 02:11:03 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048D53A69FA for ; Tue, 20 Jan 2009 02:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=-2.176, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qj6Yr9JCvXV for ; Tue, 20 Jan 2009 02:10:52 -0800 (PST) Received: from tyholt.uninett.no (imap.uninett.no [IPv6:2001:700:1::eecb]) by core3.amsl.com (Postfix) with ESMTP id 65B173A6974 for ; Tue, 20 Jan 2009 02:10:52 -0800 (PST) Received: from [195.98.238.114] (unknown [195.98.238.114]) by tyholt.uninett.no (Postfix) with ESMTP id DED772BACE8 for ; Tue, 20 Jan 2009 11:10:34 +0100 (CET) Message-ID: <4975A368.4040302@uninett.no> Date: Tue, 20 Jan 2009 11:11:52 +0100 From: Stig Venaas User-Agent: Thunderbird 2.0.0.18 (X11/20081126) MIME-Version: 1.0 To: behave@ietf.org Subject: [BEHAVE] Multicast translation draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org A while ago I submitted the draft draft-venaas-behave-mcast46-00 describing an IPv4 - IPv6 multicast translator solution. I would appreciate any feedback on the draft, Stig _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 20 02:47:34 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D603A698D; Tue, 20 Jan 2009 02:47:34 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE813A6802 for ; Tue, 20 Jan 2009 02:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SZVdN0uMpzP for ; Tue, 20 Jan 2009 02:47:31 -0800 (PST) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by core3.amsl.com (Postfix) with ESMTP id 70A563A698D for ; Tue, 20 Jan 2009 02:47:31 -0800 (PST) Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n0KAlEW5028651; Tue, 20 Jan 2009 19:47:14 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n0KAlDeB028648; Tue, 20 Jan 2009 19:47:13 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Tue, 20 Jan 2009 19:47:13 +0900 From: To: , Date: Tue, 20 Jan 2009 19:47:12 +0900 Thread-Topic: [BEHAVE] Multicast translation draft Thread-Index: Acl652lIk8Dfeou7SlGW3TxiGrMSxAABMbMg Message-ID: References: <4975A368.4040302@uninett.no> In-Reply-To: <4975A368.4040302@uninett.no> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 Subject: Re: [BEHAVE] Multicast translation draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Hi Stig, Sorry, I have not read it yet, but is it different idea of mine? http://www.ietf.org/internet-drafts/draft-miyata-v6ops-snatpt-02.txt See, 11.8 Multicast Translation Regards, ------------------------------------ Hiroshi Miyata, Ubiquitous Field Computing Research Center, Corporate R&D Headquaters, Yokogawa Electric Corp. > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Stig Venaas > Sent: Tuesday, January 20, 2009 7:12 PM > To: behave@ietf.org > Subject: [BEHAVE] Multicast translation draft > > A while ago I submitted the draft > draft-venaas-behave-mcast46-00 describing an IPv4 - IPv6 > multicast translator solution. > > I would appreciate any feedback on the draft, > > Stig > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 20 03:33:58 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543DA3A6BC1; Tue, 20 Jan 2009 03:33:58 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F443A6BC1 for ; Tue, 20 Jan 2009 03:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.243 X-Spam-Level: X-Spam-Status: No, score=-5.243 tagged_above=-999 required=5 tests=[AWL=1.356, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdtOmgQytGu6 for ; Tue, 20 Jan 2009 03:33:56 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CB36F3A67F2 for ; Tue, 20 Jan 2009 03:33:55 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (223.pool85-53-134.dynamic.orange.es [85.53.134.223]) by smtp03.uc3m.es (Postfix) with ESMTP id 9A3A8731AA1 for ; Tue, 20 Jan 2009 12:33:37 +0100 (CET) Message-ID: <4975B691.2040009@it.uc3m.es> Date: Tue, 20 Jan 2009 12:33:37 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Behave WG X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16412.007 Subject: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org The topic of this mail is the impact of the prefix type selected for representing the IPv4 addresses in the IPv6 Internet (from now called Pref64::/N) in the referral operations. A referral operation is when a host A passes the IP address of a Host B to a third Host C as application data. The host Host C will then initiate a communication towards the Host B using the IP address received. I understand this is not a rare operation in VoIP type of applications, but Dan will correct me if this is just a IP area legend (that, by the way, is used, sometimes, as an argument to build overly complex solutions :-) There are several referrals scenarios as described in this table: | Host A | Host B | Host C | --------------------------------------- Scenario 1 | v6 | v6 | v4 | --------------------------------------- Scenario 2 | v6 | v4 | v6 | --------------------------------------- Scenario 3 | v4 | v6 | v6 | --------------------------------------- Scenario 4 | v6 | v4 | v4 | --------------------------------------- Scenario 5 | v4 | v6 | v4 | --------------------------------------- Scenario 6 | v4 | v4 | v6 | --------------------------------------- Now, all the scenarios where Host A and Host C are in different IP version, they require a specific ALG, since the IP address information contained as application data must be translated, in order to be meaningful a the receiver (these are scenarios 1, 3, 4 and 6). OTOH, scenarios 2 and 5 could work without ALG. In addition, scenarios 1 and 5 where Host C is IPv4 and Host B is IPv6 will need some form of static NAT configuration (either the stateless mode of IVI or the manual configuration of bindings) to work cause they imply an IPv4 node initiating a communication towards and IPv6 node. So, let's consider the scenario 2, which should work in the dynamic binding case without ALGs first: **Scenario 2 is as follows +-----------------------------------------+ | IPv4 Internet | | +--------+ | | | Host B | | | | IPB | | | +--------+ | +-----------------------------------------+ | | | | +--|----------------------------------|---+ |+-|--------+ +-------+ +--------|--+| || Pref64_1 | | | | Pref64_2 || || | | | | || || +------+ | | | | +-------+ || || |Host A| |----| |---| |Host C | || || +------+ | | | | +-------+ || || Site1 | +-------+ | Site2 || |+----------+ +-----------+| | | | IPv6 Internet | +-----------------------------------------+ So, in this case, Host A will be sending Host B's address to Host C as application data. Now, in the eyes of Host A, Host B's address is Pref64_1:IPB:suffix (the suffix is optional, depending whether Pref64_1 is 96 bit long or shorter. Host C will receive then Pref64_1:IPB:suffix and will try to initiate a communication toward host B using that address. We now have two options depending if the prefix Pref64_1 is a single well known prefix or is allocated from the site's address block. - Case where the Pref64_1 is allocated from the site's address block (FWIW this what all drafts do as currently described) Host C sends a packet towards Pref64_1:IPB:suffix. The packet is routed towards Site 1 since Pref64_1 is part of site's 1 address block. Now Site 1 has 3 options, as discussed yesterday with Xing. Either forwards the packet to the IPv4 internet or drops it (it can drop it at the ingress or in the translator box). Now, as i understand it, it doens't make economical sense for site 1 to forward the packet towards the v4 internet, cause if it did so, it would be providing free v6 to v4 transit. So, as i understand it, it makes sense for site 1 to drop the packet (which is what i understand CERNET does (in their case it is a bit more complicated, cause they also have a the IVI addresses that they handle differently, but i think this applies in their case as well, modulo those addresses)) Now, if site1 drops packets addressed to Pref64_1 coming from the outside, referrals break. - Case where the Pref64_1 is a single well know prefix. In this case Pref64_1=Pref64_2=Pref64 So, HostA sends Pref64:IPB_suffix to Host C Host C now sends a packet to Pref64:IPB:suffix. In this case, the packet will flow through whatever route Site2 has to connect to the IPv4 Internet. In our scheme, site2 has its own translator, that then would announce a route towards Pref64, so the packet will flow through the direct route Site2 has to the IPv4 Internet. So, from this analysis, it seems that in this case, referrals would work if a single well know prefix is used. So, let's think a bit about the scenarios that require al ALG next. ** Scenarios 1, 3, 4 and 6 A general observation about these scenarios is that in the case a single well know prefix is used, it would be possible for the ALG to identify the IPv6 addresses containing an embedded IPv4 address and translate it, cause they could identify the well know prefix and know that are not general use IPv6 addresses. If the Pref64 is taken from the site's address block, it may be possible for the ALG to translate the address in the referral, as long as the translator is configured to know that this specific prefix is unsed to map IPv4 addresses. This basically implies that the translator must be in Site1 in the figure above, i.e. the site of the host sending the referral information. So, we can say that a single well known prefix is more likely to work with referral in the case that ALG is needed than the case of the prefix taken from the site's address block. *** So, we have scenario 5 to go Host A is v4, host B is v6 and host C is v4 In this case, we need a representation of Host B in the v4 world. In this case, the Pref64 seems hardly relevant. So, i think it is reasonable to say that a single well know prefix would result in better referral support. I wonder if this cannot be generalized for other applications. I mean after all the better support is simply due to the fact that using a single well know prefix results in a unique representation of the v4 addresses in v6 land, and allows to identify that irrespectivly where the translation is performed, the result is the same in terms of the address. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 20 04:00:41 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5553A6BC8; Tue, 20 Jan 2009 04:00:40 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B203A6889 for ; Tue, 20 Jan 2009 04:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9r7sMgCYlOp for ; Tue, 20 Jan 2009 04:00:38 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 07CDE3A686C for ; Tue, 20 Jan 2009 04:00:37 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.57]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n0KBwjP2048779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Jan 2009 12:58:46 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> From: Iljitsch van Beijnum To: marcelo bagnulo braun In-Reply-To: <4975B691.2040009@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 20 Jan 2009 13:00:13 +0100 References: <4975B691.2040009@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) Cc: Behave WG Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 20 jan 2009, at 12:33, marcelo bagnulo braun wrote: > A referral operation is when a host A passes the IP address of a > Host B to a third Host C as application data. The host Host C will > then initiate a communication towards the Host B using the IP > address received. I understand this is not a rare operation in VoIP > type of applications, but Dan will correct me if this is just a IP > area legend (that, by the way, is used, sometimes, as an argument to > build overly complex solutions :-) No, this happens all the time with BitTorrent. (By the way, the Pirate Bay just enabled IPv6 for their trackers and I did some testing, with less than favorable results: my not so recent BitTorrent clients wouldn't work anymore.) Note though that the situation is even worse than what you outline, because the server may either learn peer 1's address from what peer 1 says its address is, or from what it sees in the IP header in peer 1's packets. This gives us the following permutations with the peers (if they use v6) behind a NAT64: Server trusts peer: peer 1 peer 2 result public v4 public v4 works public v4 NAT works public v4 v6 works NAT public v4 fails NAT NAT fails NAT v6 fails v6 public v4 fails v6 NAT fails v6 v6 WORKS Server looks at header: peer 1 peer 2 result public v4 public v4 works public v4 NAT works public v4 v6 works NAT public v4 works (with NAT traversal) NAT NAT works (with NAT traversal) NAT v6 works (with NAT traversal) v6 public v4 depends on whether NAT64 supports traversal v6 NAT depends on whether NAT64 supports traversal v6 v6 depends on whether NAT64 supports traversal So the second mechanism works in more cases but requires more extra mechanisms and makes v6-v6 communication go through a translator. > Now, all the scenarios where Host A and Host C are in different IP > version, they require a specific ALG Isn't the policy to avoid ALGs? A dual stack server would solve the v6-to-v6 case but for the v6-to-v4 case the server would have to translate the IPv4 address into a pref64:: address so it would need to know the NAT64 prefix. That can only realistically work if the server is run by the same entity as the NAT64 (which could be the case in a fair number of VoIP deployments where the ISP runs the SIP gateway) or the pref64:: would have to be well-known. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 21 19:18:39 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9EE3A68B1; Wed, 21 Jan 2009 19:18:39 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06CD3A68B1 for ; Wed, 21 Jan 2009 19:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KYX-sV1IvMQ for ; Wed, 21 Jan 2009 19:18:36 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id CE71E3A67D6 for ; Wed, 21 Jan 2009 19:18:36 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so4616627wfd.31 for ; Wed, 21 Jan 2009 19:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wcMw4rkXfDX1uzbbIbJ2Bdv3NvF+HPDLPq91DXs1ySc=; b=v6sw8qVm4pKQbkn0JBMu5rOHqiP8Znf+eNabnPip6bpaCoAod0fEJJxjA2IuuFw2Q6 SOgMvgAJiY5enyJZf0ooedh2fLUH/eUfkKIJvbDKhsYsL/6e2qR3bQlL5oh7O6OtKv9S V/eYjmV2fJH59tjhBexvHDJ9YxgxZFjBNCjag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GRjS/34LVikGmhheLFPJemka8oG6LHnC8qnBFVvWGtG8B/nG+uLeVnsoa3wfTuTMWe 2EgYk3kiTO6k7or02hMlpJhjOcJeZKV3SEwRE7DlqHtzMcExcHvDa5NmxkBk0mXCLnkk nRti3sqXpksQO9yZ1aV9wqNKFEPTgAatj9G8U= Received: by 10.142.88.4 with SMTP id l4mr837290wfb.112.1232594299832; Wed, 21 Jan 2009 19:18:19 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm18004967wfi.47.2009.01.21.19.18.18 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 19:18:19 -0800 (PST) Message-ID: <4977E563.5060202@gmail.com> Date: Thu, 22 Jan 2009 16:17:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <4975B691.2040009@it.uc3m.es> <21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> In-Reply-To: <21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> Cc: Behave WG Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Iljitsch, I don't understand your "works" cases with NAT. If a third party hears about a NATted address/port pair as a referral, the NAT binding surely won't work for traffic to or from that third party, in the general case? Brian On 2009-01-21 01:00, Iljitsch van Beijnum wrote: > On 20 jan 2009, at 12:33, marcelo bagnulo braun wrote: > >> A referral operation is when a host A passes the IP address of a Host >> B to a third Host C as application data. The host Host C will then >> initiate a communication towards the Host B using the IP address >> received. I understand this is not a rare operation in VoIP type of >> applications, but Dan will correct me if this is just a IP area legend >> (that, by the way, is used, sometimes, as an argument to build overly >> complex solutions :-) > > No, this happens all the time with BitTorrent. (By the way, the Pirate > Bay just enabled IPv6 for their trackers and I did some testing, with > less than favorable results: my not so recent BitTorrent clients > wouldn't work anymore.) > > Note though that the situation is even worse than what you outline, > because the server may either learn peer 1's address from what peer 1 > says its address is, or from what it sees in the IP header in peer 1's > packets. This gives us the following permutations with the peers (if > they use v6) behind a NAT64: > > Server trusts peer: > > peer 1 peer 2 result > public v4 public v4 works > public v4 NAT works > public v4 v6 works > NAT public v4 fails > NAT NAT fails > NAT v6 fails > v6 public v4 fails > v6 NAT fails > v6 v6 WORKS > > Server looks at header: > > peer 1 peer 2 result > public v4 public v4 works > public v4 NAT works > public v4 v6 works > NAT public v4 works (with NAT traversal) > NAT NAT works (with NAT traversal) > NAT v6 works (with NAT traversal) > v6 public v4 depends on whether NAT64 supports traversal > v6 NAT depends on whether NAT64 supports traversal > v6 v6 depends on whether NAT64 supports traversal > > So the second mechanism works in more cases but requires more extra > mechanisms and makes v6-v6 communication go through a translator. > >> Now, all the scenarios where Host A and Host C are in different IP >> version, they require a specific ALG > > Isn't the policy to avoid ALGs? > > A dual stack server would solve the v6-to-v6 case but for the v6-to-v4 > case the server would have to translate the IPv4 address into a pref64:: > address so it would need to know the NAT64 prefix. That can only > realistically work if the server is run by the same entity as the NAT64 > (which could be the case in a fair number of VoIP deployments where the > ISP runs the SIP gateway) or the pref64:: would have to be well-known. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Thu Jan 22 04:37:51 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961523A6B6E; Thu, 22 Jan 2009 04:37:51 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8253628C17E for ; Thu, 22 Jan 2009 04:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weYhIihw0yrn for ; Thu, 22 Jan 2009 04:37:45 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 08C8428C165 for ; Thu, 22 Jan 2009 04:37:44 -0800 (PST) Received: from cl-1496.ams-04.nl.sixxs.net (cl-1496.ams-04.nl.sixxs.net [IPv6:2001:960:2:5d7::2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n0MCYZIj095507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 22 Jan 2009 13:34:36 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Brian E Carpenter In-Reply-To: <4977E563.5060202@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 13:36:09 +0100 References: <4975B691.2040009@it.uc3m.es> <21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Behave WG Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 22 jan 2009, at 4:17, Brian E Carpenter wrote: > Iljitsch, I don't understand your "works" cases with NAT. > If a third party hears about a NATted address/port pair as a > referral, the NAT binding surely won't work for traffic to or > from that third party, in the general case? That's why I included the caveat "with NAT traversal: >> Server looks at header: >> peer 1 peer 2 result >> NAT public v4 works (with NAT traversal) >> NAT NAT works (with NAT traversal) >> NAT v6 works (with NAT traversal) >> v6 public v4 depends on whether NAT64 supports traversal >> v6 NAT depends on whether NAT64 supports traversal >> v6 v6 depends on whether NAT64 supports traversal >> The point here is that the referral _can_ work because the server knows the correct address to give to a third party. It could still fail for NAT reasons. But if the server gives the third party 10.0.0.1 the referral is dead in the water. Another solution is that the server trusts the client, and the client tells the server its externally visible address. The advantage is that this can also work for the port, as the server can't deduce the port the third party should use from what it sees itself, like it can with the address. _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 23 09:51:30 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69533A6AFE; Fri, 23 Jan 2009 09:51:30 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6959D3A6AFE for ; Fri, 23 Jan 2009 09:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqzKmpEYmTIl for ; Fri, 23 Jan 2009 09:51:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A51FB3A691B for ; Fri, 23 Jan 2009 09:51:22 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,313,1231113600"; d="scan'208";a="235492533" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 23 Jan 2009 17:51:06 +0000 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 n0NHp58J025118; Fri, 23 Jan 2009 09:51:05 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0NHp5I0022904; Fri, 23 Jan 2009 17:51:05 GMT From: "Dan Wing" To: Date: Fri, 23 Jan 2009 09:51:05 -0800 Message-ID: <04c501c97d83$2a3e3f00$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl9gyoFqJQHahqfQE++MKFFnjVLlw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1021; t=1232733065; x=1233597065; 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:=20WGLC,=20draft-ietf-behave-nat-icmp-12 |Sender:=20; bh=bd6sVZTc/dQKxplnoOdSa/gJBmk7wTuPmGTx2V+h5AM=; b=eEb1ltOJZqZpQNXH43w+crWrff+0AMa8mIRNOATJAEYMp+ghLp2jNIUBxQ HMhITdUuXtF2xSTs1Iuyb1gyNHzdI4vG8lvWzpd2/mqIURyVz3Y8iOrRf9lg P/LlnmRbGk; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave-chairs@tools.ietf.org, draft-ietf-behave-nat-icmp@tools.ietf.org Subject: [BEHAVE] WGLC, draft-ietf-behave-nat-icmp-12 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Over a year ago we finished WGLC and forwarded draft-ietf-behave-nat-icmp-04 to the IESG for publication. It has now finished IESG review. During IESG review the document underwent a lot of revisions and we would like to make sure the BEHAVE working group is comfortable with these changes. The most recent version is available at: http://tools.ietf.org/html/draft-ietf-behave-nat-icmp-12 Side-by-side diffs from -04 (which went through WGLC) to -12 are at: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-behave- nat-icmp-04.txt&url2=http://tools.ietf.org/id/draft-ietf-behave-nat-icmp-12.tx t The IESG tracker of activity is at: https://datatracker.ietf.org/idtracker/draft-ietf-behave-nat-icmp/ We will hold this document for two weeks for further comments, after which we will release this document to the RFC editor. Please send comments to the BEHAVE mailing list and also CC the authors at draft-ietf-behave-nat-icmp@tools.ietf.org by FEBRUARY 6. Thanks, -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 23 10:21:27 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9373A69F1; Fri, 23 Jan 2009 10:21:27 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481D43A69F1 for ; Fri, 23 Jan 2009 10:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEWvmQ5tX8-j for ; Fri, 23 Jan 2009 10:21:25 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 39DAA3A68B8 for ; Fri, 23 Jan 2009 10:21:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,314,1231113600"; d="scan'208";a="235511007" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jan 2009 18:21:08 +0000 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 n0NIL84f021566; Fri, 23 Jan 2009 10:21:08 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0NIL8X6019939; Fri, 23 Jan 2009 18:21:08 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'Iljitsch van Beijnum'" References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> Date: Fri, 23 Jan 2009 10:21:08 -0800 Message-ID: <04fe01c97d87$5cac4320$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4977E563.5060202@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl8QB1pLWB3cXvFRZ+Yo2BZ96b0wgBRlSRw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4667; t=1232734868; x=1233598868; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=15OUH90VMG7lhJKJCl2y/gzstr6Y2bVpkEXT3Qirt9E=; b=HWHegLzjpWI1OcifQiMwZHVyd3astOm/Awz/zcCzUY1VtSrLWLnLjfdYHH Crn6xvMmLkRgS5ICuMvQPm1kwHMo98OI+15+gu6h5R0S7RU5iWVmIK/8MEuU x1RZ6Hd5VY; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Wednesday, January 21, 2009 7:18 PM > To: Iljitsch van Beijnum > Cc: Behave WG > Subject: Re: [BEHAVE] Pref64 nature and referral support. > > Iljitsch, I don't understand your "works" cases with NAT. > If a third party hears about a NATted address/port pair as a > referral, the NAT binding surely won't work for traffic to or > from that third party, in the general case? This is filtering behavior, and some IPv4 NATs do filter (block) packets that arrive from a different host. This is mentioned in RFC4787 with the following text: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. RFC4787 could only really describe current behavior and provide some guidance because NAT products predated RFC4787 by about a decade. I expect we could make stronger statements about the need for, and value of, Endpoint-Independent Filtering in a NAT64 device. -d > Brian > > On 2009-01-21 01:00, Iljitsch van Beijnum wrote: > > On 20 jan 2009, at 12:33, marcelo bagnulo braun wrote: > > > >> A referral operation is when a host A passes the IP > address of a Host > >> B to a third Host C as application data. The host Host C will then > >> initiate a communication towards the Host B using the IP address > >> received. I understand this is not a rare operation in VoIP type of > >> applications, but Dan will correct me if this is just a IP > area legend > >> (that, by the way, is used, sometimes, as an argument to > build overly > >> complex solutions :-) > > > > No, this happens all the time with BitTorrent. (By the way, > the Pirate > > Bay just enabled IPv6 for their trackers and I did some > testing, with > > less than favorable results: my not so recent BitTorrent clients > > wouldn't work anymore.) > > > > Note though that the situation is even worse than what you outline, > > because the server may either learn peer 1's address from > what peer 1 > > says its address is, or from what it sees in the IP header > in peer 1's > > packets. This gives us the following permutations with the peers (if > > they use v6) behind a NAT64: > > > > Server trusts peer: > > > > peer 1 peer 2 result > > public v4 public v4 works > > public v4 NAT works > > public v4 v6 works > > NAT public v4 fails > > NAT NAT fails > > NAT v6 fails > > v6 public v4 fails > > v6 NAT fails > > v6 v6 WORKS > > > > Server looks at header: > > > > peer 1 peer 2 result > > public v4 public v4 works > > public v4 NAT works > > public v4 v6 works > > NAT public v4 works (with NAT traversal) > > NAT NAT works (with NAT traversal) > > NAT v6 works (with NAT traversal) > > v6 public v4 depends on whether NAT64 supports traversal > > v6 NAT depends on whether NAT64 supports traversal > > v6 v6 depends on whether NAT64 supports traversal > > > > So the second mechanism works in more cases but requires more extra > > mechanisms and makes v6-v6 communication go through a translator. > > > >> Now, all the scenarios where Host A and Host C are in different IP > >> version, they require a specific ALG > > > > Isn't the policy to avoid ALGs? > > > > A dual stack server would solve the v6-to-v6 case but for > the v6-to-v4 > > case the server would have to translate the IPv4 address > into a pref64:: > > address so it would need to know the NAT64 prefix. That can only > > realistically work if the server is run by the same entity > as the NAT64 > > (which could be the case in a fair number of VoIP > deployments where the > > ISP runs the SIP gateway) or the pref64:: would have to be > well-known. > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 23 10:43:27 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFC023A6AC5; Fri, 23 Jan 2009 10:43:26 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCAA3A6AB0 for ; Fri, 23 Jan 2009 10:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBv5UPeqKS88 for ; Fri, 23 Jan 2009 10:43:24 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id CB19B3A6A6D for ; Fri, 23 Jan 2009 10:43:23 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (160.pool85-53-130.dynamic.orange.es [85.53.130.160]) by smtp02.uc3m.es (Postfix) with ESMTP id 09F09654724; Fri, 23 Jan 2009 19:43:04 +0100 (CET) Message-ID: <497A0FB7.4030903@it.uc3m.es> Date: Fri, 23 Jan 2009 19:43:03 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Dan Wing References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> <04fe01c97d87$5cac4320$c2f0200a@cisco.com> In-Reply-To: <04fe01c97d87$5cac4320$c2f0200a@cisco.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16420.001 Cc: 'Behave WG' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Dan Wing escribi=F3: > = > > = >> -----Original Message----- >> From: behave-bounces@ietf.org = >> [mailto:behave-bounces@ietf.org] On Behalf Of Brian E Carpenter >> Sent: Wednesday, January 21, 2009 7:18 PM >> To: Iljitsch van Beijnum >> Cc: Behave WG >> Subject: Re: [BEHAVE] Pref64 nature and referral support. >> >> Iljitsch, I don't understand your "works" cases with NAT. >> If a third party hears about a NATted address/port pair as a >> referral, the NAT binding surely won't work for traffic to or >> from that third party, in the general case? >> = > > This is filtering behavior, and some IPv4 NATs do filter (block) packets = that > arrive from a different host. This is mentioned in RFC4787 with the foll= owing > text: > > REQ-8: If application transparency is most important, it is > RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" > behavior. If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an "Address-Dependent > Filtering" behavior. > > a) The filtering behavior MAY be an option configurable by the > administrator of the NAT. > > RFC4787 could only really describe current behavior and provide some guid= ance > because NAT products predated RFC4787 by about a decade. > > I expect we could make stronger statements about the need for, and value = of, > Endpoint-Independent Filtering in a NAT64 device. > = but in order to support endpoint independent filtering the nat must have = endpoint independent mapping and there is an open discussion about = whether can afford that with the upcoming shortage of IPv4 addresses is there any conclusion about this discussion? Regards, marcelo > -d > > = >> Brian >> >> On 2009-01-21 01:00, Iljitsch van Beijnum wrote: >> = >>> On 20 jan 2009, at 12:33, marcelo bagnulo braun wrote: >>> >>> = >>>> A referral operation is when a host A passes the IP = >>>> = >> address of a Host >> = >>>> B to a third Host C as application data. The host Host C will then >>>> initiate a communication towards the Host B using the IP address >>>> received. I understand this is not a rare operation in VoIP type of >>>> applications, but Dan will correct me if this is just a IP = >>>> = >> area legend >> = >>>> (that, by the way, is used, sometimes, as an argument to = >>>> = >> build overly >> = >>>> complex solutions :-) >>>> = >>> No, this happens all the time with BitTorrent. (By the way, = >>> = >> the Pirate >> = >>> Bay just enabled IPv6 for their trackers and I did some = >>> = >> testing, with >> = >>> less than favorable results: my not so recent BitTorrent clients >>> wouldn't work anymore.) >>> >>> Note though that the situation is even worse than what you outline, >>> because the server may either learn peer 1's address from = >>> = >> what peer 1 >> = >>> says its address is, or from what it sees in the IP header = >>> = >> in peer 1's >> = >>> packets. This gives us the following permutations with the peers (if >>> they use v6) behind a NAT64: >>> >>> Server trusts peer: >>> >>> peer 1 peer 2 result >>> public v4 public v4 works >>> public v4 NAT works >>> public v4 v6 works >>> NAT public v4 fails >>> NAT NAT fails >>> NAT v6 fails >>> v6 public v4 fails >>> v6 NAT fails >>> v6 v6 WORKS >>> >>> Server looks at header: >>> >>> peer 1 peer 2 result >>> public v4 public v4 works >>> public v4 NAT works >>> public v4 v6 works >>> NAT public v4 works (with NAT traversal) >>> NAT NAT works (with NAT traversal) >>> NAT v6 works (with NAT traversal) >>> v6 public v4 depends on whether NAT64 supports traversal >>> v6 NAT depends on whether NAT64 supports traversal >>> v6 v6 depends on whether NAT64 supports traversal >>> >>> So the second mechanism works in more cases but requires more extra >>> mechanisms and makes v6-v6 communication go through a translator. >>> >>> = >>>> Now, all the scenarios where Host A and Host C are in different IP >>>> version, they require a specific ALG >>>> = >>> Isn't the policy to avoid ALGs? >>> >>> A dual stack server would solve the v6-to-v6 case but for = >>> = >> the v6-to-v4 >> = >>> case the server would have to translate the IPv4 address = >>> = >> into a pref64:: >> = >>> address so it would need to know the NAT64 prefix. That can only >>> realistically work if the server is run by the same entity = >>> = >> as the NAT64 >> = >>> (which could be the case in a fair number of VoIP = >>> = >> deployments where the >> = >>> ISP runs the SIP gateway) or the pref64:: would have to be = >>> = >> well-known. >> = >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> = >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> = > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > = _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 23 11:38:08 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34053A69A1; Fri, 23 Jan 2009 11:38:08 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441003A690D for ; Fri, 23 Jan 2009 11:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sb--Yjh9bUK for ; Fri, 23 Jan 2009 11:38:06 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 62D473A67B4 for ; Fri, 23 Jan 2009 11:38:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,314,1231113600"; d="scan'208";a="132905593" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Jan 2009 19:37:49 +0000 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 n0NJbn53029941; Fri, 23 Jan 2009 11:37:49 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0NJbnh7028206; Fri, 23 Jan 2009 19:37:49 GMT From: "Dan Wing" To: "'marcelo bagnulo braun'" References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> <04fe01c97d87$5cac4320$c2f0200a@cisco.com> <497A0FB7.4030903@it.uc3m.es> Date: Fri, 23 Jan 2009 11:37:49 -0800 Message-ID: <055801c97d92$133b4b40$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <497A0FB7.4030903@it.uc3m.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl9inDoxauvin4LT2qTOQARqlb5IQABrHCw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=791; t=1232739469; x=1233603469; 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]=20Pref64=20nature=20and=20refe rral=20support. |Sender:=20; bh=5PbrgfX27XLzY19Uw/lBZGheKdQg9AAc+A4zKpSU9z8=; b=O7Nju1nF9FD9U0EkPPfzWwD//qKYgr80gPnR4DkxDolL0s6Fyl9k3ygFxR sHu8ctGjk40+cMmPY1NSg7aU9Z7M97ze4h99K3AkvoOJA3wuvXLu3kFxAEUi yuvFeaRn2L; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > but in order to support endpoint independent filtering the > nat must have endpoint independent mapping True. > and there is an open discussion about > whether can afford that with the upcoming shortage of IPv4 addresses > > is there any conclusion about this discussion? No. I am aware of draft-wing-behave-dynamic-tcp-port-reuse (now expired), but I am not aware of a document that discusses Remi Despres' proposal (I think it was Remi, sorry if I have that wrong) to allow a NAT to purposefully do endpoint *dependent* mapping for traffic to certain destination ports (e.g., TCP/80, UDP/53 and TCP/53). As chair, I would certainly like to see documents that detail such proposals. A discussion of the trade-offs and benefits would be valuable. -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 23 13:46:43 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A848D3A6B36; Fri, 23 Jan 2009 13:46:43 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1AD3A6B36 for ; Fri, 23 Jan 2009 13:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPHefL0GngkT for ; Fri, 23 Jan 2009 13:46:42 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 0F9D73A6B3A for ; Fri, 23 Jan 2009 13:46:38 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1316524qwe.31 for ; Fri, 23 Jan 2009 13:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZeX4f96vD3znp9laWZYDlAoD5mEybv1IM9ZdjS3Gi+w=; b=Bnu55SWfmJu9j5BdkMUs3dXcnat7F9FkyxwoH0zb6Mt3Zor9kw0cyh6SUXA/B0BUJb uQBaAY5MxtEoB58HDieEMGCa1V9EEimswKa2cHCkiJOo9zQ8DnCNFzvi/cQmvuvLfYJd 6P09BTkKLD31QP5ME0xqirLT3nMDm7V+/ujiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=nAyNvyzPeIE19ZkSdepUO6HpMoGnYUvRRyLenR8R9Yb8f3880B4C4bM92zmWFAhvOo zU5LWS0y7QaC+l2+uRkCtW73BOE21Cg7sxJkiZ6iTYZ/saaufNECSFyeK0LLT/k3solE OJDhfoqL7mmYM0Tygf+4X5KxN27yuoKWjQIY8= Received: by 10.215.14.20 with SMTP id r20mr442485qai.189.1232747181354; Fri, 23 Jan 2009 13:46:21 -0800 (PST) Received: from ?10.1.1.4? (118-92-203-108.dsl.dyn.ihug.co.nz [118.92.203.108]) by mx.google.com with ESMTPS id 5sm945494yxt.51.2009.01.23.13.46.18 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Jan 2009 13:46:20 -0800 (PST) Message-ID: <497A3AA7.5000205@gmail.com> Date: Sat, 24 Jan 2009 10:46:15 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> <04fe01c97d87$5cac4320$c2f0200a@cisco.com> <497A0FB7.4030903@it.uc3m.es> <055801c97d92$133b4b40$c2f0200a@cisco.com> In-Reply-To: <055801c97d92$133b4b40$c2f0200a@cisco.com> Cc: 'Behave WG' Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org On 2009-01-24 08:37, Dan Wing wrote: >> but in order to support endpoint independent filtering the >> nat must have endpoint independent mapping > > True. > >> and there is an open discussion about >> whether can afford that with the upcoming shortage of IPv4 addresses >> >> is there any conclusion about this discussion? > > No. > > I am aware of draft-wing-behave-dynamic-tcp-port-reuse (now > expired), but I am not aware of a document that discusses Remi > Despres' proposal (I think it was Remi, sorry if I have that > wrong) to allow a NAT to purposefully do endpoint *dependent* > mapping for traffic to certain destination ports (e.g., TCP/80, > UDP/53 and TCP/53). > > As chair, I would certainly like to see documents that detail > such proposals. A discussion of the trade-offs and benefits > would be valuable. Also, the address+port style of fractional IPv4 addresses would cause extra difficulties in using referrals for any sort of port-agile application, if you happened to hit an unholy mixture of NAT64 and address+port usage. I fear that the dragons here are very hard to conquer. Brian _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jan 24 02:09:56 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E523A6980; Sat, 24 Jan 2009 02:09:56 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA6A28C26B for ; Sat, 24 Jan 2009 02:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlf13ofBR5I8 for ; Sat, 24 Jan 2009 02:09:53 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 285BC3A68EC for ; Sat, 24 Jan 2009 02:09:51 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 0AA0A8181EB; Sat, 24 Jan 2009 11:09:29 +0100 (CET) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp3-g21.free.fr (Postfix) with ESMTP id E140F81819E; Sat, 24 Jan 2009 11:09:25 +0100 (CET) Message-ID: <497AE857.8040701@free.fr> Date: Sat, 24 Jan 2009 11:07:19 +0100 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Brian E Carpenter References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> <04fe01c97d87$5cac4320$c2f0200a@cisco.com> <497A0FB7.4030903@it.uc3m.es> <055801c97d92$133b4b40$c2f0200a@cisco.com> <497A3AA7.5000205@gmail.com> In-Reply-To: <497A3AA7.5000205@gmail.com> Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Brian E Carpenter - le (m/j/a) 1/23/09 10:46 PM: > On 2009-01-24 08:37, Dan Wing wrote: >>> but in order to support endpoint independent filtering the nat >>> must have endpoint independent mapping >> True. >> >>> and there is an open discussion about whether can afford that >>> with the upcoming shortage of IPv4 addresses >>> >>> is there any conclusion about this discussion? >> No. >> >> I am aware of draft-wing-behave-dynamic-tcp-port-reuse (now >> expired), but I am not aware of a document that discusses Remi >> Despres' proposal (I think it was Remi, sorry if I have that wrong) >> to allow a NAT to purposefully do endpoint *dependent* mapping for >> traffic to certain destination ports (e.g., TCP/80, UDP/53 and >> TCP/53). Yes, I made this proposal in May 2008, and still believe it's worth consideration. AFAIK, the (minor) negative consequence would be that STUN servers, if they don't use their registered port 3478, should at least avoid using HTTP and DNS well known ports. The (major) expected benefit, as IPv4 addresses become scarce, would be that the address-multiplexing efficiency of NATs that do it would be much improved, especially on port 80. >> As chair, I would certainly like to see documents that detail such >> proposals. A discussion of the trade-offs and benefits would be >> valuable. To my knowledge, and for example, Teemu Savolainen ran a test in August 2008. It showed that a Google map use involved 4 server addresses in parallel. With port dependent mapping on port 80, the number of needed client ports would have been divided by 4 . > > Also, the address+port style of fractional IPv4 addresses would cause > extra difficulties in using referrals for any sort of port-agile > application, if you happened to hit an unholy mixture of NAT64 and > address+port usage. I fear that the dragons here are very hard to > conquer. Note that, i sec 3.2.3 of http://tools.ietf.org/html/draft-despres-sam-01, the proposed *port extended IPv4 addressing* uses only *dynamic ports* (49152 to 65535); Thus, interference with how NATs treat well known and registered ports (0 to 49151) is avoided. So far, I see no such unholy mixture, but agree that experiments are needed to check that, with port extended IPv4 addressing, no unexpected dragon gets out of a box . Best regards, RD _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Sat Jan 24 05:46:12 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C1F3A6ABD; Sat, 24 Jan 2009 05:46:12 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FBA3A6ABD for ; Sat, 24 Jan 2009 05:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03Db+MeDYr1V for ; Sat, 24 Jan 2009 05:46:10 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 11BA73A65A5 for ; Sat, 24 Jan 2009 05:46:08 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (160.pool85-53-130.dynamic.orange.es [85.53.130.160]) by smtp02.uc3m.es (Postfix) with ESMTP id 5C537659F1F; Sat, 24 Jan 2009 14:45:45 +0100 (CET) Message-ID: <497B1B89.3090407@it.uc3m.es> Date: Sat, 24 Jan 2009 14:45:45 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4975B691.2040009@it.uc3m.es><21AC353A-5C47-48CC-A02B-6AB425543E00@muada.com> <4977E563.5060202@gmail.com> <04fe01c97d87$5cac4320$c2f0200a@cisco.com> <497A0FB7.4030903@it.uc3m.es> <055801c97d92$133b4b40$c2f0200a@cisco.com> <497A3AA7.5000205@gmail.com> <497AE857.8040701@free.fr> In-Reply-To: <497AE857.8040701@free.fr> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16420.007 Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] Pref64 nature and referral support. X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org R=E9mi Despr=E9s escribi=F3: > Brian E Carpenter - le (m/j/a) 1/23/09 10:46 PM: >> On 2009-01-24 08:37, Dan Wing wrote: >>>> but in order to support endpoint independent filtering the nat must = >>>> have endpoint independent mapping >>> True. >>> >>>> and there is an open discussion about whether can afford that with = >>>> the upcoming shortage of IPv4 addresses >>>> >>>> is there any conclusion about this discussion? >>> No. >>> >>> I am aware of draft-wing-behave-dynamic-tcp-port-reuse (now = >>> expired), but I am not aware of a document that discusses Remi = >>> Despres' proposal (I think it was Remi, sorry if I have that wrong) >>> to allow a NAT to purposefully do endpoint *dependent* mapping for >>> traffic to certain destination ports (e.g., TCP/80, UDP/53 and = >>> TCP/53). > Yes, I made this proposal in May 2008, and still believe it's worth > consideration. > > AFAIK, the (minor) negative consequence would be that STUN servers, if > they don't use their registered port 3478, should at least avoid using > HTTP and DNS well known ports. > > The (major) expected benefit, as IPv4 addresses become scarce, would be > that the address-multiplexing efficiency of NATs that do it would be > much improved, especially on port 80. I think this approach is reasonable We could be very conservative in the list of ports we accept address = dependent mapping but as Remy says, even if we limit the list to port 80 = we would get significant gain imho Regards, marcelo > >>> As chair, I would certainly like to see documents that detail such >>> proposals. A discussion of the trade-offs and benefits would be = >>> valuable. > To my knowledge, and for example, Teemu Savolainen ran a test in August > 2008. It showed that a Google map use involved 4 server addresses in > parallel. With port dependent mapping on port 80, the number of needed > client ports would have been divided by 4 . > >> >> Also, the address+port style of fractional IPv4 addresses would cause >> extra difficulties in using referrals for any sort of port-agile = >> application, if you happened to hit an unholy mixture of NAT64 and = >> address+port usage. I fear that the dragons here are very hard to = >> conquer. > Note that, i sec 3.2.3 of > http://tools.ietf.org/html/draft-despres-sam-01, the > proposed *port extended IPv4 addressing* uses only *dynamic ports* = > (49152 to > 65535); Thus, interference with how NATs treat well known and registered > ports (0 to 49151) is avoided. > > So far, I see no such unholy mixture, but agree that experiments are > needed to check that, with port extended IPv4 addressing, no unexpected > dragon gets out of a box . > > Best regards, > > RD > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Tue Jan 27 19:53:07 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988E428C126; Tue, 27 Jan 2009 19:53:07 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19DF28C126 for ; Tue, 27 Jan 2009 19:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpm9Xijbu-Zb for ; Tue, 27 Jan 2009 19:53:05 -0800 (PST) Received: from mail-07.primus.ca (mail13.primus.ca [216.254.141.180]) by core3.amsl.com (Postfix) with ESMTP id 4611B3A6784 for ; Tue, 27 Jan 2009 19:53:05 -0800 (PST) Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1LS1Tj-0000jg-0Q for behave@ietf.org; Tue, 27 Jan 2009 22:52:39 -0500 Message-Id: From: Philip Matthews To: Behave WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 27 Jan 2009 22:52:46 -0500 X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] Subject: [BEHAVE] TURN status X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Just a note to all those who have sent in Last Call comments on TURN. I am sorry that I have been slow in replying to your comments. Unfortunately, I have not been able to put much time into TURN recently, due to other commitments. However, I do have your comments and I hope to get to them shortly. My apologies, and thanks for your comments and your patience. - Philip _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 28 05:01:06 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D34328C262; Wed, 28 Jan 2009 05:01:06 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66D428C262 for ; Wed, 28 Jan 2009 05:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK72WaWqdQf3 for ; Wed, 28 Jan 2009 05:01:04 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id B12F128C261 for ; Wed, 28 Jan 2009 05:01:03 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 14:00:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C98148.6E7622D8" Date: Wed, 28 Jan 2009 14:00:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-levis-behave-ipv4-shortage-framework-00.txt thread-index: AcmBRlhK0phamW+FRkOgMH4QjXkWdgAAZ/1A From: To: X-OriginalArrivalTime: 28 Jan 2009 13:00:44.0105 (UTC) FILETIME=[6E11AB90:01C98148] Subject: [BEHAVE] TR: I-D Action:draft-levis-behave-ipv4-shortage-framework-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C98148.6E7622D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I would like to draw your attention on the following draft. I'm looking forward to reading your comments. Regards Pierre -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : mercredi 28 janvier 2009 13:45 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-levis-behave-ipv4-shortage-framework-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : IPv4 Shortage Framework Author(s) : P. Levis, et al. Filename : draft-levis-behave-ipv4-shortage-framework-00.txt Pages : 15 Date : 2009-01-28 This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion. It would be valuable to assess each IPv4 address shortage solution with all these issues, to check to what degree they are concerned, how they handle each issue, and to what extent they resolve the pending problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levis-behave-ipv4-shortage-fram= ework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C98148.6E7622D8 Content-Type: application/octet-stream; name="draft-levis-behave-ipv4-shortage-framework-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-levis-behave-ipv4-shortage-framework-00.URL Content-Disposition: attachment; filename="draft-levis-behave-ipv4-shortage-framework-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1sZXZpcy1iZWhhdmUtaXB2NC1zaG9ydGFnZS1mcmFtZXdvcmstMDAudHh0DQo= ------_=_NextPart_001_01C98148.6E7622D8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ------_=_NextPart_001_01C98148.6E7622D8-- From behave-bounces@ietf.org Wed Jan 28 12:52:31 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197673A6956; Wed, 28 Jan 2009 12:52:31 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235FD3A6956 for ; Wed, 28 Jan 2009 12:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.559 X-Spam-Level: X-Spam-Status: No, score=-4.559 tagged_above=-999 required=5 tests=[AWL=2.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfjEyuzFWKgF for ; Wed, 28 Jan 2009 12:52:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 290443A68D0 for ; Wed, 28 Jan 2009 12:52:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,339,1231113600"; d="scan'208";a="238488213" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Jan 2009 20:52:11 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0SKqBUU024398; Wed, 28 Jan 2009 12:52:11 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n0SKqBci023353; Wed, 28 Jan 2009 20:52:11 GMT From: "Dan Wing" To: "'Stig Venaas'" , References: <4975A368.4040302@uninett.no> Date: Wed, 28 Jan 2009 12:52:11 -0800 Message-ID: <0a2c01c9818a$4ab44d50$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4975A368.4040302@uninett.no> Thread-Index: Acl652P31Gu7aDNiROqCNdIPCfXRmwGogPIQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1176; t=1233175931; x=1234039931; 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]=20Multicast=20translation=20dr aft |Sender:=20; bh=ATRCp5uvLyx5ZAwt2x7po3terGB/TEvjma41pPZpPHE=; b=BBFqnXvPFAi2+GoewPsVKvlCulXOxNMOI59QpjmvVIjKmw4dyMvE9uL4YQ qYj718Tsbhm4TpidJ2BFG9g0ECeC7a4VZW97gtNAJFXhK27kmzqUPDfv9jI/ SoML6nUHVq; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [BEHAVE] Multicast translation draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Stig Venaas > Sent: Tuesday, January 20, 2009 2:12 AM > To: behave@ietf.org > Subject: [BEHAVE] Multicast translation draft > > A while ago I submitted the draft draft-venaas-behave-mcast46-00 > describing an IPv4 - IPv6 multicast translator solution. > > I would appreciate any feedback on the draft, This draft feels quite complete. I wrote draft-wing-behave-learn-prefix-00.txt which was primarily aimed at the following problem: I imagine it could be common for the multicast application running on the IPv6-only host to only learn an IPv4 multicast address (via an electronic program guide, SDP, or whatever other means it might learn of multicast addresses). But the draft requires the IPv6-only host join the IPv6 multicast group which requires the IPv6-only host somehow know the IPv6 prefix associated with that IPv4 address and the SSM/ASM mapping between IPv6 and IPv4. If I'm on track with my imagination then a discussion of this might be helpful. BEHAVE working group: is there interest in this draft? -d _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Wed Jan 28 12:52:37 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 583303A6BF7; Wed, 28 Jan 2009 12:52:37 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DA83A6BF7 for ; Wed, 28 Jan 2009 12:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.579 X-Spam-Level: X-Spam-Status: No, score=-5.579 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhtKpu1YFOjX for ; Wed, 28 Jan 2009 12:52:35 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 05FFE3A6BE2 for ; Wed, 28 Jan 2009 12:52:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,339,1231113600"; d="scan'208";a="134784756" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 28 Jan 2009 20:52:17 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0SKqHYB024541; Wed, 28 Jan 2009 12:52:17 -0800 Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n0SKqHgm023359; Wed, 28 Jan 2009 20:52:17 GMT From: "Dan Wing" To: , , References: <4975A368.4040302@uninett.no> Date: Wed, 28 Jan 2009 12:52:17 -0800 Message-ID: <0a2d01c9818a$4e1cccb0$c2f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Thread-Index: Acl652lIk8Dfeou7SlGW3TxiGrMSxAABMbMgAad2etA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1560; t=1233175937; x=1234039937; 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]=20Multicast=20translation=20dr aft |Sender:=20; bh=97HKQToOIzGcaViE/DgF4moiiswYdXvvopDJtSN4NpE=; b=m5ASIipQ9glphZn/KwiIOhc7UGRsQljZNzCuq5Qato6HWzEm33k+CcU7+j koQeRxlNaZWdZjE5cxwY01rtb3idSQYJ/Y+gWi/RwrJAKfYQyb+IvktLJtqc 1PUoM++sA2; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [BEHAVE] Multicast translation draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org Yes, Stig's draft has more specific detail of the IPv4/IPv6 mapping between the multicast domains. -d > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of H.Miyata@jp.yokogawa.com > Sent: Tuesday, January 20, 2009 2:47 AM > To: stig.venaas@uninett.no; behave@ietf.org > Subject: Re: [BEHAVE] Multicast translation draft > > Hi Stig, > > Sorry, I have not read it yet, but is it different idea of mine? > > http://www.ietf.org/internet-drafts/draft-miyata-v6ops-snatpt-02.txt > > See, > > 11.8 Multicast Translation > > Regards, > > ------------------------------------ > Hiroshi Miyata, > Ubiquitous Field Computing Research Center, > Corporate R&D Headquaters, > Yokogawa Electric Corp. > > > > > -----Original Message----- > > From: behave-bounces@ietf.org > > [mailto:behave-bounces@ietf.org] On Behalf Of Stig Venaas > > Sent: Tuesday, January 20, 2009 7:12 PM > > To: behave@ietf.org > > Subject: [BEHAVE] Multicast translation draft > > > > A while ago I submitted the draft > > draft-venaas-behave-mcast46-00 describing an IPv4 - IPv6 > > multicast translator solution. > > > > I would appreciate any feedback on the draft, > > > > Stig > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From behave-bounces@ietf.org Fri Jan 30 02:13:53 2009 Return-Path: X-Original-To: behave-archive@optimus.ietf.org Delivered-To: ietfarch-behave-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944503A6B03; Fri, 30 Jan 2009 02:13:53 -0800 (PST) X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5213A6B05 for ; Fri, 30 Jan 2009 02:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwnRpKCbGKzf for ; Fri, 30 Jan 2009 02:13:51 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id A699C3A6A9B for ; Fri, 30 Jan 2009 02:13:50 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jan 2009 11:13:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C982C3.667879E7" Date: Fri, 30 Jan 2009 11:13:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-port-range-01.txt thread-index: AcmCvXIHWTn+rYi4RyezeLo5r/+i1AABIDoA From: To: X-OriginalArrivalTime: 30 Jan 2009 10:13:31.0117 (UTC) FILETIME=[66C4B1D0:01C982C3] Subject: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: behave-bounces@ietf.org Errors-To: behave-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C982C3.667879E7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to draw your attention on the following draft which is an = enhanced version based on the two following drafts previously submitted: Looking forward to reading your comments. Regards Pierre -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : vendredi 30 janvier 2009 10:30 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-port-range-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : IPv4 Connectivity Access in the Context of IPv4 = Address Exhaustion Author(s) : M. Boucadair, et al. Filename : draft-boucadair-port-range-01.txt Pages : 41 Date : 2009-01-30 This memo proposes a solution, based on fractional addresses, to face the IPv4 public address exhaustion. It details the solution and presents a mock-up implementation, with the results of tests that validate the concept. It also describes architectures and how fractional addresses are used to overcome the IPv4 address shortage. A comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions is also elaborated in the document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-port-range-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C982C3.667879E7 Content-Type: application/octet-stream; name="draft-boucadair-port-range-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-port-range-01.URL Content-Disposition: attachment; filename="draft-boucadair-port-range-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItcG9ydC1yYW5nZS0wMS50eHQNCg== ------_=_NextPart_001_01C982C3.667879E7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave ------_=_NextPart_001_01C982C3.667879E7--