From internet-drafts@ietf.org Tue Oct 9 08:29:44 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9F911E8114; Tue, 9 Oct 2012 08:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkHaVzucy230; Tue, 9 Oct 2012 08:29:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61421F85A2; Tue, 9 Oct 2012 08:29:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009152944.28008.14415.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 08:29:44 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-sctpnat-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 15:29:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-behave-sctpnat-07.txt Pages : 27 Date : 2012-10-09 Abstract: Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-sctpnat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-sctpnat-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-sctpnat-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From meng.wei2@zte.com.cn Tue Oct 9 18:26:26 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763CD1F0C5C for ; Tue, 9 Oct 2012 18:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJO9gpI3cWde for ; Tue, 9 Oct 2012 18:26:26 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A85011F0C4C for ; Tue, 9 Oct 2012 18:26:24 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E6C1B125B49B; Wed, 10 Oct 2012 09:18:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9A1QGxf010507; Wed, 10 Oct 2012 09:26:16 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> To: behave@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Wed, 10 Oct 2012 09:26:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-10 09:26:13, Serialize complete at 2012-10-10 09:26:13 Content-Type: multipart/alternative; boundary="=_alternative 0007E5DB48257A93_=" X-MAIL: mse02.zte.com.cn q9A1QGxf010507 Cc: wang.cui1@zte.com.cn, huj@ctbri.com.cn Subject: [BEHAVE] A draft about sharing pool among regions X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 01:26:26 -0000 This is a multipart message in MIME format. --=_alternative 0007E5DB48257A93_= Content-Type: text/plain; charset="US-ASCII" Dear all, We are very interested in Behave WG, we agree that several problems should be resolved in IETF. A draft about improving pool share-ratio had already been submitted to the Behave list in September. http://tools.ietf.org/html/draft-meng-behave-ip-resources-share-00 I appreciate your comments and other solutions, I will update the draft later. Hope we will move forward :-) Best wishes Wei-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0007E5DB48257A93_= Content-Type: text/html; charset="US-ASCII"
Dear all,

We are very interested in Behave WG, we agree that several problems should be resolved in IETF.

A draft about improving pool share-ratio had already been submitted to the Behave list in September.
http://tools.ietf.org/html/draft-meng-behave-ip-resources-share-00

I appreciate your comments and other solutions, I will update the draft later. Hope we will move forward :-)

Best wishes

Wei 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0007E5DB48257A93_=-- From ajs@crankycanuck.ca Fri Oct 26 11:26:27 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31A821F8575 for ; Fri, 26 Oct 2012 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAHoJ4CUZ+Jh for ; Fri, 26 Oct 2012 11:26:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7085721F8574 for ; Fri, 26 Oct 2012 11:26:26 -0700 (PDT) Received: from crankycanuck.ca (63-145-43-74.dia.static.qwest.net [63.145.43.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 341298A031 for ; Fri, 26 Oct 2012 18:26:25 +0000 (UTC) Date: Fri, 26 Oct 2012 14:26:18 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20121026182617.GA56687@crankycanuck.ca> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 27 Oct 2012 16:18:28 -0700 Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 18:26:27 -0000 Dear colleagues, As usual, a day late and a dollar short. On Thu, Sep 20, 2012 at 09:07:44PM +0000, Dave Thaler wrote: > All comments received during the first WGLC (on -09) have been > resolved. > > This email initiates another two-week Working Group Last Call > on draft-ietf-behave-nat64-discovery-heuristic-11, to conclude > Thursday October 4th. I have read -11. There are several uses of "NXRRSET". I have no idea what that means. It's not a term with which I'm familiar, so it probably needs defining. There is a typo of RFC 1034 for 1035 in item 2 of 3.1.2. Other than that, I can live with it. Best, A -- Andrew Sullivan ajs@crankycanuck.ca From dthaler@microsoft.com Sat Oct 27 16:27:44 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F52721F8509 for ; Sat, 27 Oct 2012 16:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb5xs0Vk7mHQ for ; Sat, 27 Oct 2012 16:27:43 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8407A21F8507 for ; Sat, 27 Oct 2012 16:27:43 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.545.8; Sat, 27 Oct 2012 23:27:41 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Sat, 27 Oct 2012 23:27:40 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sat, 27 Oct 2012 23:27:39 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.112]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Sat, 27 Oct 2012 16:27:39 -0700 From: Dave Thaler To: Andrew Sullivan , "behave@ietf.org" Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 Thread-Index: Ac2Xc7cV3cKg/vUUTUejTO5rsFUFEwcblkkAAC4GacA= Date: Sat, 27 Oct 2012 23:27:38 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20121026182617.GA56687@crankycanuck.ca> In-Reply-To: <20121026182617.GA56687@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(13464001)(377454001)(51704002)(3846001)(47976001)(50466001)(48376001)(47736001)(47776002)(74662001)(1076001)(15202345001)(4396001)(33656001)(44976002)(74502001)(50986001)(4196001)(46102001)(31966008)(47446002)(16696001)(51856001)(16826001)(16406001)(20776001)(53806001)(8716001)(49866001)(5343655001)(54316001)(54356001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0647963F84 Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 23:27:44 -0000 NXRRSET is RCODE 8, specified in RFC 2136 and listed in the DNS RCODE regis= try at http://www.iana.org/assignments/dns-parameters I believe it means the name exists but no records of the requested type exi= st. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Friday, October 26, 2012 11:26 AM > To: behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 11 >=20 > Dear colleagues, >=20 > As usual, a day late and a dollar short. >=20 > On Thu, Sep 20, 2012 at 09:07:44PM +0000, Dave Thaler wrote: > > All comments received during the first WGLC (on -09) have been > > resolved. > > > > This email initiates another two-week Working Group Last Call on > > draft-ietf-behave-nat64-discovery-heuristic-11, to conclude Thursday > > October 4th. >=20 > I have read -11. There are several uses of "NXRRSET". I have no idea wh= at > that means. It's not a term with which I'm familiar, so it probably need= s > defining. >=20 > There is a typo of RFC 1034 for 1035 in item 2 of 3.1.2. >=20 > Other than that, I can live with it. >=20 > Best, >=20 > A >=20 > -- > Andrew Sullivan > ajs@crankycanuck.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Sat Oct 27 20:08:45 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BF821F85C8 for ; Sat, 27 Oct 2012 20:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.649 X-Spam-Level: X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgf9Kpq79jTn for ; Sat, 27 Oct 2012 20:08:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3CC21F84C0 for ; Sat, 27 Oct 2012 20:08:44 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2EE1A8A031 for ; Sun, 28 Oct 2012 03:08:41 +0000 (UTC) Date: Sat, 27 Oct 2012 23:08:41 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20121028030840.GA56865@crankycanuck.ca> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20121026182617.GA56687@crankycanuck.ca> <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 03:08:45 -0000 On Sat, Oct 27, 2012 at 11:27:38PM +0000, Dave Thaler wrote: > NXRRSET is RCODE 8, specified in RFC 2136 and listed in the DNS RCODE registry at > http://www.iana.org/assignments/dns-parameters Doh, what an idiot. Of course it is. I knew that I'd seen the term before, but couldn't place it while sitting on the plane. It's a response that you normally only get in DNS Dynamic Update responses. I'm not sure how it's likely to apply to the use cases of this draft. I suppose there's no harm in leaving it it, but I bet others will be as puzzled by its inclusion as I was. > I believe it means the name exists but no records of the requested type exist. Only in a dynamic update context. In a standard query/response context, the response to a query for a name that exists, but without the RRTYPE you're requesting, will yield NOERROR (RCODE==0) and ANCOUNT of 0 -- an "empty answer", which is different from RCODE==3 (Name Error or NXDOMAIN). I _think_ what the -11 text is looking for either an NXDOMAIN or NODATA response. See RFC 2308 for the definition of the NODATA response, but basically it's the case where you get NOERROR and ANCOUNT == 0, and it's not a referral. You have to determine it algorithmically. Isn't DNS fun? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From teemu.savolainen@nokia.com Sun Oct 28 00:52:13 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040BE21F8858 for ; Sun, 28 Oct 2012 00:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqlf-C843-Nl for ; Sun, 28 Oct 2012 00:52:12 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1220321F87C5 for ; Sun, 28 Oct 2012 00:52:11 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9S7pwvE024551; Sun, 28 Oct 2012 09:51:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 28 Oct 2012 09:51:58 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.19]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0309.003; Sun, 28 Oct 2012 08:51:57 +0100 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 Thread-Index: AQHNtJln7Npi+rggpk6UTmOyci49rpfNqpMAgABOhoCAAFyQ2A== Date: Sun, 28 Oct 2012 07:51:56 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962044C0832@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20121026182617.GA56687@crankycanuck.ca> <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>, <20121028030840.GA56865@crankycanuck.ca> In-Reply-To: <20121028030840.GA56865@crankycanuck.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.115.224.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2012 07:51:58.0203 (UTC) FILETIME=[1B491CB0:01CDB4E1] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 07:52:13 -0000 The NXRRSET stuff originates from discussions on behave mailing list on Jun= e. Please see e.g. http://www.ietf.org/mail-archive/web/behave/current/msg1= 0459.html=0A= =0A= It is of course possible that the discussions ended in the draft partially = wrong and we got some regress in -10 when compared to -09.=0A= =0A= Looking at the instances of NXRRSET, I would think that in "3. Node Behavio= r" the first instance is ok (discuss about hijacking), but in the second an= d third instance we'd need improvements. Could we just be somewhat agnostic= and, for the case of second and third instance (both in same paragraph), j= ust say:=0A= --=0A= In the case of a negative or empty response, or a DNS query=0A= timeout: a DNS64 server is not available on the access network, the=0A= access network filtered out the well-known query, or something went=0A= wrong in the DNS resolution. All unsuccessful cases result in a node=0A= being unable to perform local IPv6 address synthesis. In the case of=0A= timeout, the node SHOULD retransmit the DNS query like any other DNS=0A= query the node makes [RFC1035]. In the case of a negative or empty=0A= response, the node MUST obey the Time-To-Live [RFC1035] of=0A= the response before resending the AAAA resource record query. The=0A= node MAY monitor for DNS replies with IPv6 addresses constructed from=0A= the WKP, in which case if any are observed the node SHOULD use the=0A= WKP as if it were learned during the query for the well-known name.=0A= --=0A= =0A= Best regards,=0A= =0A= Teemu=0A= ________________________________________=0A= From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of ext An= drew Sullivan [ajs@anvilwalrusden.com]=0A= Sent: Sunday, October 28, 2012 5:08 AM=0A= To: behave@ietf.org=0A= Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristi= c-11=0A= =0A= On Sat, Oct 27, 2012 at 11:27:38PM +0000, Dave Thaler wrote:=0A= > NXRRSET is RCODE 8, specified in RFC 2136 and listed in the DNS RCODE reg= istry at=0A= > http://www.iana.org/assignments/dns-parameters=0A= =0A= Doh, what an idiot. Of course it is. I knew that I'd seen the term=0A= before, but couldn't place it while sitting on the plane.=0A= =0A= It's a response that you normally only get in DNS Dynamic Update=0A= responses. I'm not sure how it's likely to apply to the use cases of=0A= this draft. I suppose there's no harm in leaving it it, but I bet=0A= others will be as puzzled by its inclusion as I was.=0A= =0A= > I believe it means the name exists but no records of the requested type e= xist.=0A= =0A= Only in a dynamic update context. In a standard query/response=0A= context, the response to a query for a name that exists, but without=0A= the RRTYPE you're requesting, will yield NOERROR (RCODE=3D=3D0) and ANCOUNT= =0A= of 0 -- an "empty answer", which is different from RCODE=3D=3D3 (Name=0A= Error or NXDOMAIN).=0A= =0A= I _think_ what the -11 text is looking for either an NXDOMAIN or=0A= NODATA response. See RFC 2308 for the definition of the NODATA=0A= response, but basically it's the case where you get NOERROR and=0A= ANCOUNT =3D=3D 0, and it's not a referral. You have to determine it=0A= algorithmically. Isn't DNS fun?=0A= =0A= Best,=0A= =0A= A=0A= =0A= --=0A= Andrew Sullivan=0A= ajs@anvilwalrusden.com=0A= =0A= _______________________________________________=0A= Behave mailing list=0A= Behave@ietf.org=0A= https://www.ietf.org/mailman/listinfo/behave=0A= From simon.perreault@viagenie.ca Sun Oct 28 14:36:30 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A62421F8566 for ; Sun, 28 Oct 2012 14:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uEV8pmx4HQh for ; Sun, 28 Oct 2012 14:36:29 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 73F0C21F8538 for ; Sun, 28 Oct 2012 14:36:23 -0700 (PDT) Received: from porto.nomis80.org (unknown [64.235.195.26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 57E6440096 for ; Sun, 28 Oct 2012 17:36:18 -0400 (EDT) Message-ID: <508DA54B.5010309@viagenie.ca> Date: Sun, 28 Oct 2012 17:36:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: behave@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20121026182617.GA56687@crankycanuck.ca> <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>, <20121028030840.GA56865@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962044C0832@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962044C0832@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 21:36:30 -0000 Le 2012-10-28 03:51, teemu.savolainen@nokia.com a écrit : > The NXRRSET stuff originates from discussions on behave mailing list > on June. Please see e.g. > http://www.ietf.org/mail-archive/web/behave/current/msg10459.html Andrew is right, of course. I meant NODATA. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From teemu.savolainen@nokia.com Mon Oct 29 03:05:33 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D148221F8495 for ; Mon, 29 Oct 2012 03:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqdP-FrFNu5M for ; Mon, 29 Oct 2012 03:05:32 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2821F8553 for ; Mon, 29 Oct 2012 03:05:30 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9TA4fLv019939; Mon, 29 Oct 2012 12:05:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Oct 2012 12:05:08 +0200 Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.19]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0309.003; Mon, 29 Oct 2012 11:05:07 +0100 From: To: , Thread-Topic: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 Thread-Index: AQHNtVRT5MYfHWWHpkSLr2zAaVdOTJfQDcDg Date: Mon, 29 Oct 2012 10:05:07 +0000 Message-ID: <916CE6CF87173740BC8A2CE443096962044C14B1@008-AM1MPN1-053.mgdnok.nokia.com> References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20121026182617.GA56687@crankycanuck.ca> <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>, <20121028030840.GA56865@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962044C0832@008-AM1MPN1-053.mgdnok.nokia.com> <508DA54B.5010309@viagenie.ca> In-Reply-To: <508DA54B.5010309@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ili3MCvCLXmrxYjzLlJRY6FHY/pHjF6tFjgSe2JwmNBmRPgvRO9PTHSy6iVyvbVrfjFTfBeIiJxDMl435gppXWKqLKKSlcswXZioS9afJF4H2/cxCI9dIxHF31fspsFWpmPfNqu3rwRI3l1WoZpHlNS9iMn4RVpQ1euWN+CvbsP5eJX5x/AmqxdadfHfKxS0cg7p9sPfjpc7ebxggpUV6wTNdUhUnu55flzWF3i9F8HW36pUeOgul6kO9Jsginvi3xnoTuhH+fIJiuqVWN/Jn1o= x-originating-ip: [10.163.161.139] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2012 10:05:08.0126 (UTC) FILETIME=[E0105BE0:01CDB5BC] X-Nokia-AV: Clean Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:05:34 -0000 So would these be correct pieces of text: -- (not changed) In some scenarios NXDOMAIN and NXRRSET hijacking performed by the access ne= twork may result in a false positive. -- and -- (changed slightly) In the case of a negative (NXDOMAIN) or empty response (NODATA), or a DN= S query timeout: a DNS64 server is not available on the access network, the access network filtered out the well-known query, or something went wrong in the DNS resolution. All unsuccessful cases result in a node being unable to perform local IPv6 address synthesis. In the case of timeout, the node SHOULD retransmit the DNS query like any other DNS query the node makes [RFC1035]. In the case of a negative or empty response, the node MUST obey the Time-To-Live [RFC1035] of the response before resending the AAAA resource record query. The node MAY monitor for DNS replies with IPv6 addresses constructed from the WKP, in which case if any are observed the node SHOULD use the WKP as if it were learned during the query for the well-known name. -- Best regards, Teemu > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of ext Simon Perreault > Sent: 28. lokakuuta 2012 23:36 > To: behave@ietf.org > Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuris= tic- > 11 > > Le 2012-10-28 03:51, teemu.savolainen@nokia.com a =E9crit : > > The NXRRSET stuff originates from discussions on behave mailing list > > on June. Please see e.g. > > http://www.ietf.org/mail-archive/web/behave/current/msg10459.html > > Andrew is right, of course. I meant NODATA. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Oct 29 08:49:28 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFCD21F873A; Mon, 29 Oct 2012 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2jOBM3w49Jn; Mon, 29 Oct 2012 08:49:27 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCBD21F8738; Mon, 29 Oct 2012 08:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3014; q=dns/txt; s=iport; t=1351525767; x=1352735367; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=sldByzodhNhZqC1lWwiAGTmZ3Umj1OqXZmRPg46+BAI=; b=hArMRjVKqVPdsWyIscHAPwkUUoJo39p9Cv1yhjDKMFczY3J8RmkGlUFm wnfkbXvpcsD5gI4b1JQBJBuvOPEo6Iv3xkmZNjkGJSx+vUqtbDSYy4W2M nv0LI9Dfa7f1Ue8OtD130x5+/3pZnHGRbrYCBzEstiNP61HmUNv2ev68M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAKAEOljlCrRDoI/2dsb2JhbABEwVkDgQmBCIIeAQEBAgEBAQEBBQIIAVsLBQcBAwIJEQQBAQEnBxkOHwkIAgQBEgsFEodeBQycMZ9mi3V5hWQDiFmFFYgGjleBa4MP X-IronPort-AV: E=Sophos;i="4.80,672,1344211200"; d="scan'208";a="60022835" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 Oct 2012 15:49:10 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9TFn9WX027966; Mon, 29 Oct 2012 15:49:10 GMT From: "Dan Wing" To: "=?iso-8859-2?Q?'Nejc_=A9koberne'?=" , References: <20121002115421.GY13776@Space.Net> <508C6CA5.4090406@skoberne.net> In-Reply-To: <508C6CA5.4090406@skoberne.net> Date: Mon, 29 Oct 2012 08:49:10 -0700 Message-ID: <03c801cdb5ec$efc1feb0$cf45fc10$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJy/YYJ47UjDhaVa+Vz5DmB82cpogEBpR7pAgsKZwYCLRbgr5ZcDkWA Content-Language: en-us Cc: behave@ietf.org Subject: Re: [BEHAVE] [v6ops] double nat X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:49:28 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Nejc =A9koberne > Sent: Saturday, October 27, 2012 4:22 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] double nat >=20 > Hi, >=20 > I am reviving this thread, as (AFAIK) nobody mentioned the following > issue: >=20 > "Other aspects of NAT behaviour, notably the NAT binding lifetime and > the form of NAT "cone behaviour" for UDP take on the more the more > restrictive of the two NATs in sequence. > The binding times are potentially problematical in that the two NATs = are > not synchronised in terms of binding behaviour. If the CGN has a = shorter > binding time, it is possible for the CGN to misdirect packets and = cause > application level hang ups. However this is not overly different to a > single level NAT environment where aggressively short NAT binding = times > will also run the risk of causing application level hang ups when the > NAT drops the binding for a active session that has been quiet for an > extended period of time." >=20 > (Geoff Huston, > http://www.potaroo.net/ispcol/2011-03/transtools-part2.pdf, page 7) >=20 > So binding lifetime desynch can be quite harmful here? Any real-world > experience on this? This question is probably better answered in BEHAVE, which I CC'd. Yes, short binding lifetimes can cause applications to fail. Consider, for example, an application lets its connection sit idle and the NAT clobbers the connection, and then re-uses that same IP address and port for another (fresh) connection. Eventually the application using the old connection will send data. Depending on if this was TCP or UDP, and if it was the device behind the NAT or on the Internet, all sorts of things could happen. As Geoff wrote, this occurs with one NAT, if that NAT times out a mapping before the hosts delete their mappings. Yes, this happens in the wild. But it is seldom diagnosed because=20 it is difficult to recreate. -d > Thanks, > Nejc >=20 > On 2.10.2012 13:54, Randy Bush wrote: > >>> so, is double nat really worse than single nat? is it formally > >>> different? except in the case of overlapping spaces, of course. > >> One of the problems with "someone else controls your NAT" is that = you > >> can't add port mappings. This seems to be an inevitable side = effect > >> of NAT444 (but can happen with single NAT44 as well, of course, > >> depending on where it's placed). > > i asked *formally*. i am not concerned with all the ops, social, > > stuff. and not about issues not directly connected to the nat. > > what does double translation do that single does not? > > > > randy > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dwing@cisco.com Mon Oct 29 09:49:36 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEBA21F86E7 for ; Mon, 29 Oct 2012 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL7zvH2TQhKO for ; Mon, 29 Oct 2012 09:49:36 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E709821F85FE for ; Mon, 29 Oct 2012 09:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2654; q=dns/txt; s=iport; t=1351529376; x=1352738976; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=lvuBiWS5PHqyhGD3PeVZVQciclXR+JvTvQXmG4B/fiY=; b=EQgkUFXQlZACX/lyCPMCRIaETypMUTNz6SuIjxyXF2OClyryoDkrocZQ LHKmNh0xolkGhLzgeFOh9g4WlZzkeUoFhtjuF/CgUtoNO5PgVroC6Qe1Y h/i6oYw81DiZfCtrXa3sgK3hl3clRy4xb728/5SqaBZr6U56N9TUIPt4c M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMJAHKyjlCrRDoI/2dsb2JhbABEwVUEBIEJgQiCHgEBAQMBCAIEBAEnKxQFBwEDAgkRBAEBKAcZLQkIAgQBEgsFCweHXgUMnCKfaot1GoZDA4hZhRWIBoEajT2Ba4MPgUQX X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="60026502" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 Oct 2012 16:49:31 +0000 Received: from DWINGWS01 ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9TGnUlM032136; Mon, 29 Oct 2012 16:49:30 GMT From: "Dan Wing" To: , References: <980973149D509B4AA117C3CE035BACA92F828A5F@SN2PRD0610MB372.namprd06.prod.outlook.com> In-Reply-To: Date: Mon, 29 Oct 2012 09:49:30 -0700 Message-ID: <03fd01cdb5f5$5de3d640$19ab82c0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQA2dG66CGL3v0MeD1YQ7Y0TzUYtC5r+/6Ng Content-Language: en-us Cc: wang.cui1@zte.com.cn, huj@ctbri.com.cn Subject: Re: [BEHAVE] A draft about sharing pool among regions X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 16:49:36 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of meng.wei2@zte.com.cn > Sent: Tuesday, October 09, 2012 6:26 PM > To: behave@ietf.org > Cc: wang.cui1@zte.com.cn; huj@ctbri.com.cn > Subject: [BEHAVE] A draft about sharing pool among regions > > > Dear all, > > We are very interested in Behave WG, we agree that several problems > should be resolved in IETF. > > A draft about improving pool share-ratio had already been submitted to > the Behave list in September. > http://tools.ietf.org/html/draft-meng-behave-ip-resources-share-00 > > > I appreciate your comments and other solutions, I will update the draft > later. Hope we will move forward :-) User's public IP addresses need to stay the same (or else existing sessions break), so I assume the intent is either (a) move only 'newly active users' (who have sent their first packet), or (b) assign users to a specific NAT when they join the network (via DHCP, PPPoE, etc.). The draft should be clearer on how that occurs. After that occurs, I don't see how a user's traffic is steered towards the appropriate NAT. That seems to depend on what sort of network exists between the subscriber and their NAT (DS-Lite tunnel, IPv4 routed network, NAT co-located with the first-hop router (e.g., CMTS)), and so on). That is critical for this idea to work, and the draft needs to constrain itself to the network topologies the authors are considering. Is there a need for multi-vender interoperability with this mechanism? That is, would an operator deploy a NAT from vendor A and another NAT from vendor B, and expect to load balance outgoing traffic, amongst subscribers, between those two NATs? The NATs will have different performance characteristics and different types of traffic will load them differently (e.g., one may have higher pps but low number of mappings; one might support IPsec Passthru while the other doesn't). -d > Best wishes > > Wei > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > (and any attachment transmitted herewith) is privileged and confidential > and is intended for the exclusive use of the addressee(s). If you are > not an intended recipient, any disclosure, reproduction, distribution or > other dissemination or use of the information contained is strictly > prohibited. If you have received this mail in error, please delete it > and notify us immediately. > > From simon.perreault@viagenie.ca Tue Oct 30 07:46:03 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9C421F859B for ; Tue, 30 Oct 2012 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoZqqTOHgbNB for ; Tue, 30 Oct 2012 07:46:02 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6A121F85A0 for ; Tue, 30 Oct 2012 07:46:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [81.80.150.116]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 96B2041A05; Tue, 30 Oct 2012 10:45:54 -0400 (EDT) Message-ID: <508FE81D.5070000@viagenie.ca> Date: Tue, 30 Oct 2012 15:45:49 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: teemu.savolainen@nokia.com References: <9B57C850BB53634CACEC56EF4853FF653B7C04CE@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20121026182617.GA56687@crankycanuck.ca> <9B57C850BB53634CACEC56EF4853FF653B8B7EE6@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>, <20121028030840.GA56865@crankycanuck.ca> <916CE6CF87173740BC8A2CE443096962044C0832@008-AM1MPN1-053.mgdnok.nokia.com> <508DA54B.5010309@viagenie.ca> <916CE6CF87173740BC8A2CE443096962044C14B1@008-AM1MPN1-053.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE443096962044C14B1@008-AM1MPN1-053.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic-11 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:46:03 -0000 Looks good! Simon Le 2012-10-29 11:05, teemu.savolainen@nokia.com a écrit : > So would these be correct pieces of text: > > -- (not changed) > In some scenarios NXDOMAIN and NXRRSET hijacking performed by the access network may result in a false positive. > -- > and > -- (changed slightly) > In the case of a negative (NXDOMAIN) or empty response (NODATA), or a DNS query > timeout: a DNS64 server is not available on the access network, the > access network filtered out the well-known query, or something went > wrong in the DNS resolution. All unsuccessful cases result in a node > being unable to perform local IPv6 address synthesis. In the case of > timeout, the node SHOULD retransmit the DNS query like any other DNS > query the node makes [RFC1035]. In the case of a negative or empty > response, the node MUST obey the Time-To-Live [RFC1035] of > the response before resending the AAAA resource record query. The > node MAY monitor for DNS replies with IPv6 addresses constructed from > the WKP, in which case if any are observed the node SHOULD use the > WKP as if it were learned during the query for the well-known name. > -- > > Best regards, > > Teemu > >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf >> Of ext Simon Perreault >> Sent: 28. lokakuuta 2012 23:36 >> To: behave@ietf.org >> Subject: Re: [BEHAVE] Last call: draft-ietf-behave-nat64-discovery-heuristic- >> 11 >> >> Le 2012-10-28 03:51, teemu.savolainen@nokia.com a écrit : >>> The NXRRSET stuff originates from discussions on behave mailing list >>> on June. Please see e.g. >>> http://www.ietf.org/mail-archive/web/behave/current/msg10459.html >> >> Andrew is right, of course. I meant NODATA. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From oeichenwei@gmail.com Wed Oct 31 00:07:10 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAAB21F8652 for ; Wed, 31 Oct 2012 00:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo2SN-MZcCLy for ; Wed, 31 Oct 2012 00:06:49 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A777021F864A for ; Wed, 31 Oct 2012 00:06:49 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so1192711oag.31 for ; Wed, 31 Oct 2012 00:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ns3ody5obKdGjQc5/dDTVbizqFfCJEHrQg1MIcTGSGY=; b=x76BupAf1uMVc02OwADyQ3UWWM4hMuDGAG+Aaov78D3kWPOomacr1HqMY+Q4fTUDsh 5z/MjTZKgYqkgiKEPdN9cKZC+9A+CNy2FCgx9+AGoWqLRAjn/DBg75C3XkT9GZCU//iR LLi1wp9xpmo9syaz5+Sm9JjRcZpO7DuVJN6LbhpYWn4hMpLC2Q7dthk6VTzagQn3WUgT kLZVY7xYhI3MQ1M5zIvGQRLhDQ8VH86pHnlA/T+tNQLUMihi1kU5npONoZaNh/rwAEUE 6ZyNh1YVF844tGTj3ECitCn8oxwCKZ34nBwTx7Vfk3cNeDhZpxKnqVnxNzCpl6uOrsYg gQhQ== MIME-Version: 1.0 Received: by 10.60.22.161 with SMTP id e1mr30335136oef.93.1351667209233; Wed, 31 Oct 2012 00:06:49 -0700 (PDT) Received: by 10.182.73.161 with HTTP; Wed, 31 Oct 2012 00:06:49 -0700 (PDT) Date: Wed, 31 Oct 2012 15:06:49 +0800 Message-ID: From: chen wilson To: behave@ietf.org Content-Type: multipart/alternative; boundary=e89a8f647a2bdc63dd04cd558b84 Subject: [BEHAVE] Some questions regarding RFC5766(TURN) authentication X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 07:07:10 -0000 --e89a8f647a2bdc63dd04cd558b84 Content-Type: text/plain; charset=ISO-8859-1 RFC5389(STUN) section 10 provides 2 ways to do authentication and integrity check while RFC 5766 only supports long-term credential. My question is how to integrate the long-term credential with SSO, for example, SAML mechanism? 2 typical user cases in my mind are: 1. Deploy TURN in enterprise just like HTTP proxy, in such a case, it would be better to authenticate with enterprise Active Directory; 2. Deploy TURN as a cloud service, the service providers would always have their own unified authentication server. Are these 2 user cases typical for TURN? Thanks, Wilson Chen --e89a8f647a2bdc63dd04cd558b84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
RFC5389(STUN) section 10 provides 2 ways to do authentication and=A0
integrity=A0check while RFC 5766 only supports long-term credentia= l.
My question is how to integrate the long-term credential with = SSO,=A0
for example, SAML=A0mechanism?

2 typical user= cases in my mind are:
1. Deploy TURN in enterprise just like HTT= P proxy, in such a case,=A0
it would be better to authenticate wi= th enterprise Active Directory;
2. Deploy TURN as a cloud service, the service providers would=A0
always have their own unified authentication server.
Are th= ese 2 user cases typical for TURN?

Thanks,
Wilson Chen

--e89a8f647a2bdc63dd04cd558b84--